Project

General

Profile

Bug #30

Sistema não pode aceitar cadastrar um lote caso já exista um com o mesmo número [RPROJ 4240]

Added by Maurício Dos Santos almost 13 years ago. Updated over 12 years ago.

Status:
Closed
Priority:
Normal
Target version:
Start date:
Due date:
% Done:

0%

Spent time:
Componente:
Medicamentos

Description

O sistema está permitindo a gravação de lotes com números de lote iguais, o que gera inconsistência e erros de exibição. O sistema deve seguir a lógica abaixo:

Ao gravar um novo lote, caso o lote já exista para aquele medicamento (ou outros medicamentos - VERIFICAR COM A CRIS);
Caso o lote não exista, então grava normalmente como é feito hoje;
Caso o lote já esteja cadastrado, o sistema deve alertar o usuário, com uma opção para lançar a quantidade no lote já existente;
Caso o usuário aceite entrar com a quantidade no lote já existente, o sistema exibirá uma tela com o lote já pré-selecionado, onde o usuário apenas confirmará a quantidade informada anteriormente.
O sistema fará o lançamento da quantidade informada, porém para o lote já existente;

[IMPORTADO DO RPROJ - 4240]

History

#1 Updated by Ricardo Memoria almost 13 years ago

  • Target version deleted (Version 2.1)

#2 Updated by Maurício Dos Santos almost 13 years ago

  • Status changed from New to In Progress
  • Start date set to 08/01/2012

#3 Updated by Maurício Dos Santos over 12 years ago

Tornar o campo de laboratorio obrigatorio
colocar observação para nao abreviar o nome dos laboratorios.

TAREFA DUPLICADA EM #42
"
CRISTIANE
O caminho para o cadastro de lotes do sistema deveria ser:

1) Cadastrar o lote/validade/preço unitário/fabricante de um medicamento em algum link dentro do próprio módulo de medicamentos (disponível apenas para o gestor do nível central).

2) Ao cadastrar um novo estoque de algum medicamento o sistema deverá exibir um drop down onde vou selecionar o medicamento e outro drop down onde vou vou selecionar o lote (automaticamente o sistema traz as informações de validade, preço unitário e fabricante daquele lote.

3) Por fim eu vou inserir a informação da quantidade em estoque.

Quando eu enviar um pedido de medicamento para uma unidade o sistema deverá agrupar lotes iguais, ou seja, se eu enviar um lote que a Unidade já tenha em estoque, o sistema deverá somar as duas quantidades e a exibição deverá ser única.

Meninos, se não ficou claro me falem que eu explico melhor pessoalmente.
"

#4 Updated by Maurício Dos Santos over 12 years ago

  • Assignee changed from Maurício Dos Santos to Cristiane Angeli David
  • % Done changed from 0 to 30

Ricardo,

Acho que temos 3 opções.

1- Deixar o campo de laboratorio do jeito que esta hoje, mas refinar o que ja esta cadatrado.
A cris topa ajustar os valores, acho que eu poderia gerar uma planilha pra ela e ela atualizar os nomes nessa planilha, depois só montar uma query.
E ao cadastrar o sistema poderia sugerir enquando o usuario vai digitando.

2- Criar uma entidade
Acredito que mesmo assim seria necessária a refinação dos dados pra poder cadastrar os labs que ja estao no sistema, alem de mudar a estrutura das tabelas. Causa mais impacto, mas é a que garante a consistencia da informação.

3- Deixar o campo de laboratorio do jeito que esta hoje
O sistema sugere o nome na tentativa de manter essa informação consistente. Na minha opinião é resolver um problema criando outro.

Falando com a Cris ela topa tentar atualizar o nome de cada laboratorio e refinar

#5 Updated by Ricardo Memoria over 12 years ago

  • Assignee changed from Cristiane Angeli David to Maurício Dos Santos

Acho que a opção 2 seria a ideal, mas para fazer isso é necessário antes passar pela etapa de ajuste de dados que você descreveu na etapa 1.

Faz o seguinte, comece com a 1, e a gente conversa sobre a 2 na quarta/quinta feira. Mas para não ter problemas de comunicação, vamos passar a chamar a entidade de fabricante (Manufacturer) ao invés de laboratório. Já existe uma entidade laboratório, e isso pode causar confusão.

#6 Updated by Maurício Dos Santos over 12 years ago

  • % Done changed from 30 to 50

O sistema ja esta recuperando quando o lote ja esta cadastrado, ams algumas questões precisam ser dicutitas com o Ricardo.

No meu entendimento, informações como quantidade recebida, valor em real recebido, preço unitario, nao fazem parte do contexto Lote e sim do contexto LoteRecebido (acredito que representado no sistema por BatchQuantity) mas no sistema não esta assim, por favor me corrija se estiver errado.

Por exemplo o preço unitario do lote X hoje pode custar R$3,00 mas amanha por alguma razao pode passar a ter outro valor...

public class Batch implements Serializable {
    private static final long serialVersionUID = -7099327398266493703L;

    @Id
    @GeneratedValue(strategy=GenerationType.AUTO)
    private Integer id;

    @NotNull
    @Temporal(TemporalType.DATE)
    private Date expiryDate;

    @Column(length=30)
    @NotNull
    private String batchNumber;

    @Column(length=80)
    private String manufacturer;

    @ManyToOne
    @JoinColumn(name="MEDICINE_ID")
    @NotNull
    private Medicine medicine;

    private Container container;
    private int quantityReceived;
    private int quantityContainer;
    private float unitPrice;
}

Acredito que precisaremos melhorar essa parte. Sendo assim, o que está pendente para a conclusão dessa tarefa é:
- Reestruturar as classes Batch e BatchQuantity para melhorar a questão de que informação deve ficar em que contexto.
- Analisar as informações do banco de dados e preencher os registros que não possuem o nome do fabricante.
- Criar a entidade Fabricante.
- Popular a tabela da entidade Fabricante e lincar cada registro ao registro de recebimento de lote.
- Refazer a query que busca o lote quando o usuario tenta registrar um novo lote.
- Também acho conveniente renomear o botão "Novo lote", pois o sistema nao vai cadastrar um novo lote e sim vai registrar o recebimento de um lote (que pode ser novo ou pode ja estar cadastrado)

#7 Updated by Maurício Dos Santos over 12 years ago

Algumas outras questoes:

O campo container não esta sendo utilizado, este campo é um ENUM do tipo Container [Box, Bottle]... Continuamos sem usar? Seria melhor deixar isso no contexto do Lote ou do Lote Recebido?

A quantidade por container pode variar pro mesmo lote? É a quantidade por caixa? Pelo que avaliei superficialmente do banco de dados essa quantidade nao varia pro mesmo lote. (Cris, pode ajudar?)

A quantidade recebida nao depende do lote e sim do recebimento, entao deveria sair do contexto de Lote e ir para um contexto de Lote Recebido.

O lote 2041 prova a questao do preço unitario em um dos registro o preço é 2,92 e os outros registros sao 2,94. Tem outros exemplos.

Receivingitem_id é um campo que 23 registros de (442) estao populados e nao existe mais no modelo lógico. Nao consegui identificar o que é para tentar definir se fica no contexto de Lote ou de Lote Recebido.

#8 Updated by Maurício Dos Santos over 12 years ago

  • Assignee changed from Maurício Dos Santos to Ricardo Memoria

#9 Updated by Maurício Dos Santos over 12 years ago

  • % Done changed from 50 to 40

Bem,

Esclarecidas as duvidas o decidido foi:

O sistema ira localizar no sistema, assim que o usuario preenche os campos medicamento, numero do lote e fabricante, se a unidade já possui medicamentos daquele lote. Se possui o sistema nao deixa o usuario adicionar aquele lote como novo lote.

Se nao possui o sistema verifica se ja existe algum lote com aqueles campos chave (medicamento, numero de lote e nome de fabricante), se existe preenche os campos com as informações desse lote que ja esta cadastrado e permite ao usuario inserir aquele lote para a unidade selecionada.

Ricardo, me corrija se estiver errado... Ainda falta:
- Encapsular Fabricante em uma entidade.
- Garimpar e melhorar os dados de batch e relacionar os batchs que ficarem com batchquantity.
- Cadastrar os fabricantes ja existentes e relacioná-los com batch.
- Garimpar e melhorar os dados de batchquantity a fim de remover as inconsistencias de dados (mais de um batchquantity para um lote e uma unidade)

#10 Updated by Maurício Dos Santos over 12 years ago

  • Due date set to 08/14/2012
  • Status changed from In Progress to Resolved
  • % Done changed from 40 to 100

#11 Updated by Maurício Dos Santos over 12 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF