Histórico da Página

(Obrigatório)

Informações Gerais

   Legenda: 1 – Inovação 2 – Manutenção (Os demais campos devem ser preenchidos para ambos os processos). 

(Obrigatório)

Objetivo

Desenvolver no sistema Data collection, gerenciamento de entrada de produtos controlador por IUMs.

Conforme resolução RDC 54, de 10 de dezembro de 2013, origina sobre a implantação do sistema de controle de medicamentos e os mecanismos e procedimentos para rastreamento de medicamentos na cadeia dos produtos farmacêuticos e dá outras providências.

A rastreabilidade deste está relacionada a um processo de registro de código únicos (IUM) gerados de forma sistemática que serão impressos em formato DATAMAX nas embalagens de medicamentos e suas embalagens de movimentação.

(Obrigatório)

Definição da Regra de Negócio

O processo de entrada de produtos serão realizados pelo TOTVS ERP, seguindo os processos padrões. O sistema Data collection deverá realizar o processo de coleta dos SSCC e IUMs recebidos para a geração do check-in de entrada.

O processo deverá ser realizado via coletor de dados, utilizando uma frame que será desenvolvida, para realizar a coleta dos SSCC IUMs recebidos.

Finalizado o processo de coleta, será executada API para geração do arquivo com as informações necessárias para geração do processo de checki-in.

1          Coleta

Processo de coleta das etiquetas SSCC e IUMs, para registro destas visando gerar o processo de confirmação de recebimento (Check-in).

1.1. 

Densenvolver para montagem de pallets.

Desenvolver programa utilizando as funções padrões do data collection, seguindo as funções/frames descritas abaixo:

1.1.1.    Frame 1 – Informações iniciais de acesso.

Frame com definições padrões do Data Collection de usuário, senha, estabelecimento e deposito.

Protótipo 1 – Frame 1 Dados para acesso.

Campo: Estabelecimento

Formato: Like wm-etiqueta.cod-estabel

Habilitar: Sempre

Campo: Deposito

Formato: Like wm-etiqueta.cod-depos

Habilitar: Sempre

1.1.2.    Frame 2 – Seleção do movimento.

Frame para informar o tipo de documento, nota fiscal ou ordem de produção.

Protótipo de tela – Frame 2 Seleção do Movimento.

Campo: Codigo do Tipo de Entrada

Formato: Inteiro (9)

Habilitar: Sempre

1.1.3.    Frame 3 – Informações do movimento

Frame para informar os dados necessários de nota fiscal para a continuação do processo de recebimento dos produtos. Os dados digitados deverão ser validados conforme regras já existentes no produto ERP.

Protótipo de tela – Frame 3 informações do movimento (Nota fiscal).

Campo: Número NF

Formato: nota-fiscal.nr-nota-fis

Habilitar: Sempre

Campo: Série

Formato: nota-fiscal.serie

Habilitar: Sempre

Campo: Emitente

Formato: nota-fiscal.cod-emitente

Habilitar: Sempre

1.1.4.    Frame 4 – Informação da Ordem de produção.

Frame para informar os dados necessários de ordem de produção para a continuação do processo de recebimento dos produtos. Os dados digitados deverão ser validados conforme regras já existentes no produto ERP.

Protótipo de tela – Frame 4 informações do movimento (Ordem de produção).

Campo: Ordem de Produção

Formato: ord-prod.num-ord-produ

Habilitar: Sempre

1.1.5.    Frame 5 – Campo para informar os SSCC e IUM.

Frame para informar os SSCC e IUMs recebidos. O processo de leitura o operador deverá formar os níveis de estrutura de acondicionamento dividido em SSCC e os IUMs associados, assim como os níveis de acondicionamento dos volumes.

Ex:

Foi recebido um pallet com SSCC 1-123456 composto por 2 caixas a primeira identificada com SSCC 2-12345-1 com os IUMS 5-001 e 5-002 associados a esta. A segunda caixa esta identificada o  SSCC 2-12345-2 com os IUMS 5-003 e 5-004 associados a esta.

Para os processos de montagem de pallets o operador deverá efetuar a leitura da etiqueta SSCC e o IUMs que o compõem. Os níveis de acondicionamento devem ser montados conforme a os comandos de 888888 – Próximo nível e o encerramento do volume (777777- encerra volume), seguindo a tabela anterior, podemos continuar a explicação:

- Efetuar a leitura da etiqueta 1-123456, efetuar o comando 888888.

- Efetuar a leitura da etiqueta 2-12345-1 e as etiquetas 5-001 e 5-002, efetuar o comando 777777 - encerra volume e iniciar a leitura das 2-12345-2 e as etiquetas 5-001 e 5-002 efetuar o comando 777777 e 555555 - finalizar o pallet. Se existir mais de um pallet para o documento, inicia-se a operação, caso contrário 999999 – Finaliza conferencia.

Protótipo de tela – Frame 5 informa SSCC e IUM.

1.2. Desenvolver Tela de Consulta e Manutenção das etiquetas coletadas

Tela de consulta e manutenção de etiquetas coletadas

2          Geração de Interface de check-in

Desenvolver processo de geração de layout de check-in como padrão relatório, possibilitando executar este em RPW.

Opcional

Protótipo de Tela

Protótipo 01

Protótipo 02

Protótipo 03

Protótipo 04

Protótipo 05

Opcional

Fluxo do Processo

Não se aplica.

Opcional

Dicionário de Dados

Não se aplica.

Arquivo ou Código do Script: AAA – Negociação Financeira / *Versao=CP.2014.12_03*/

Campo

<AAA_PERESP>

Tipo

<N>

Tamanho

<6>

Valor Inicial

(

Descrição

<Referência Mínima para Cálculo>

Título

<Ref.Calc.>

Picture

<@E999.99>

Help de Campo

<Informar o % que o aluno pagará em dinheiro. Esse % poderá ser alterado durante a negociação>

(Opcional)

Grupo de Perguntas

Não se aplica. 

Nome: FINSRF2

(Opcional)

Consulta Padrão

Não se aplica.

Consulta: AMB

(Opcional)

Estrutura de Menu

Não se aplica. 

Procedimentos

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Módulo

Programa base

Nome Menu

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Registro padrão

Sim

Sim

Sim

Sim/Não

Sim/Não

Sim/Não

Release de Liberação

Não se aplica. 

Programas

Programa

Descrição

(Max 40 posições)

(Max 40 posições)

(Max 40 posições)

Nome Externo

Nome Menu/Programa

(Max 32 posições)

(Max 32 posições)

(Max 32 posições)

Nome Verbalizado[1]

(Max 254 posições)

(Max 254 posições)

(Max 254 posições)

Template

(Verificar lista de opções no man01211)

(Verificar lista de opções no man01211)

Tipo[2]

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Consulta/Manutenção/ Relatório/Tarefas

Interface

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

GUI/WEB/ChUI/Flex

Categoria[3]

Executa via RPC

Sim/Não

Sim/Não

Sim/Não

Registro padrão

Sim

Sim

Sim

Outro Produto

Não

Não

Não

Visualiza Menu

Sim/Não

Sim/Não

Sim/Não

Query on-line

Sim/Não

Sim/Não

Sim/Não

Log Exec.

Sim/Não

Sim/Não

Sim/Não

Rotina (EMS)

Sub-Rotina (EMS)

Localização dentro da Sub Rotina (EMS)

Compact[4]

Sim/Não

Sim/Não

Sim/Não

Home[5]

Sim/Não

Sim/Não

Sim/Não

Posição do Portlet[6]

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

0 – Top Left

1 – Top Right

2 – Bottom Left

3 – Bottom Right

Informar os papeis com os quais o programa deve ser vinculado

Cadastro de Papéis

<O cadastro de papéis é obrigatório para os projetos de desenvolvimento FLEX a partir do Datasul 10>.

<Lembrete: o nome dos papeis em inglês descrito neste ponto do documento, devem ser homologados pela equipe de tradução>.

Não se aplica.

Cadastro de Papéis

Não se aplica.

[6] Obrigatório quando o projeto for FLEX

Casos de Testes

Um caso de teste contém informações gerais que determinam como testes anteriormente especificado pelo Plano de Testes devem ser conduzidos. Geralmente, eles são agrupados por requisito. Entretanto, é possível agrupar casos de teste por conjunto de requisitos, caso os testes estejam verificando integradamente os requisitos que pertencem a esse conjunto.

Os casos de testes mencionados abaixo devem ser executados para garantir a qualidade do produto, atendendo a finalidade do projeto e os resultados esperados.

(Obrigatório)

1. 1.       Caso(s) de Testes Reusável(is)

Neste tópico deverão ser identificados os Casos de Testes Reusáveis, isto é, casos de testes existentes para outras rotinas e que podem ser executados nesta rotina. Esta é apenas uma identificação. O detalhamento dos novos casos, assim como a revisão destes deve ser realizado no template Casos de Testes.>

(Opcional)

1. 2.       Caso(s) de Testes Específico(s) do Projeto

<Neste tópico deverão ser identificados os Casos de Testes Não Reusáveis, isto é, testes que serão executados somente neste projeto, exemplo: teste de interface. Esta é apenas uma identificação. O detalhamento dos  casos de testes devem ser feitos na própria especificação.

Caso de Testes

<Informe o nome do caso de testes>

Finalidade Testes

<Defina qual será a finalidade deste caso de teste >

Estimativas

<Informar o valor total para execução deste caso de teste, considerando o tempo das pré-condições e pós-condições descritas abaixo>

Teste do Programador

( ) Sim  ( ) Não

Recomendações

<Informe particularidades que devem ser consideradas neste caso de testes. Exemplo: executar esse caso de testes duas vezes, um com a versão atual da rotina e outra com a versão desse desenvolvimento para garantir que não ocorram diferenças além das solicitadas por este desenvolvimento>

Pré-condições

<Relacione os requisitos que devem ser consideradas quando este caso de teste for executado>

Pós-condições

<Relacione as saídas do caso de teste que devem ser consideradas após a execução dos testes>

Como verificar os resultados

<Detalhe como deverão ser verificados os resultados dos testes>

Procedimentos

Resultados Esperados

<Relacione os passos que devem ser executados para a realização dos testes >