Itens

O módulo Item é o módulo responsável por cadastrar os itens de consumo, produtos de revenda, fabricação própria para venda ou consumo, etc., e no futuro também serviços. Este módulo oferecerá um cadastro com controle de preços, markups, custos, entre outras funcionalidades que servirão de suporte para diversos outros módulos, como PDV, Controle de Estoques, Base de Custos para Planilhas de Cálculos, etc.

Para oferecer todo o conceito o módulo é dividido nos seguintes cadastros:

Tipo do Item

O tipo do item tem a finalidade de agrupar todos os itens de um mesmo tipo. Entende-se por tipo de produto "o que o produto é", por exemplo: Refrigerante, Água, Suco, Pasta de Dente, Pão de Queijo, etc. Não faz parte do tipo a marca, embalagem, quantidades etc. Marca, quantidade, códigos, preços, etc. são atributos do item, e serão preenchidos no cadastro do Item e não do tipo.

Outra questão importante é que o tipo do item é padronizado pelo sistema, sendo um cadastro único para todo o domínio.

As vantagens de se utilizar o tipo de item para organizar o cadastro são:

• Orientar e até obrigar o usuário que cadastra os itens a fornecer as informações relevantes sobre um determinado tipo de produto sem deixar nenhuma para trás. Como o tipo de item apresenta um formulário de campos para serem preenchidos, o usuário não se esquece das informações relevantes.
• Temos um cadastro final bem organizado. Isso porque a descrição do item é gerada com base nas informações do campo, e sempre na mesma ordem.
• Vários campos específicos, como tipo de embalagem e conteúdo do pacote ajudam a filtrar entre as entradas das regras tributárias de cada produto. Simplificando a vida de quem cadastra os itens.
• Os tipos de itens são associados a categorias específicas da empresa, assim uma vez que o tipo de item foi informado usuário não consegue errar a categoria, por exemplo, informando que o tipo de item é uma "Vassoura", e esse tipo estando associado somente a categoria "Bazar" o usuário não consegue coloca-lo na categoria "Bebidas" ou qualquer outra.

Requisitos

• Tipo do Item: O nome do tipo de item é usado para identificar o cadastro. Deve ser único.
• Prefixo: O prefixo é um "começo" da descrição, que será usada em todos os itens desse mesmo tipo. Ao forçar que todos os itens comecem com o mesmo prefixo ajuda na organização do cadastro do banco de dados.
• Estado: A definição de estado indica se o tipo de item está ou não ativo. Tipos de itens inativos não pode ser utilizados por itens. Itens que estão utilizando tipos de itens que foram desabilitados devem ter seu tipo de item substituído.
• Campos Dinâmicos: Os campos dinâmicos tem a finalidade de criar campos que se tornarão campos de cadastro quando o usuário cadastrar o item. Por exemplo, para um determinado produto é esperado que o usuário informe na descrição do produto a Marca do produto. Neste caso, criamos um campo dinâmico com o título 'Marca', do tipo texto, com um limite de X caracteres, de preenchimento obrigatório para que o usuário forneça a marca do item sendo cadastrado.

Validações

• [ve0001] Categoria em Uso por Itens continua Disponível - Quando um tipo de item é alterado, é preciso validar se os itens desse tipo atualmente cadastrados não ficarão inválidos caso a categoria não esteja mais associada ao tipo de item. Ou seja, quando um item associado a esse tipo de item já estiver utilizando determinada categoria ela não pode ser excluída do tipo de item. Somente Atualização
• [ve0002] Alteração do Prefixo reflete nos itens existentes - Caso o prefixo seja alterado, todos os itens deste tipo de item devem ter seu nome atualizado de acordo com o novo prefixo. Somente Atualização
• [ve0003] Verifica Definições de Impostos para cada empresa - Verifica a definição dos impostos para cada empresa existente.
• [ve0004] Tipo e Alíquota no ECF igual à Alíquota Efetiva - Verifica se o tipo do ICMS definido no tipo de item e a alíquota efetiva do do cálculo é coerente com os valores cadastrados no objeto ICMSVO, usado no momento de venda do ECF.
• [ve0005] Natureza da Receita e Tabela são obrigatórios para os CSTs 02, 03, 04, 05, 06, 07, 08 e 09 - Para todos esses CSTs, os campos de Natureza da Receita e Tabela ser validado.
• [ve0006] Verificar se a tabela é valida para o CST de Saída informado - Quando a tabela é informada, ela deve ser coerente com o código do CST de saída informado.
• [ve0007] Verificar se o Natureza é válida para a Tabela informada - Ao informar um código da Natureza da Receita o BIS deve verificar se o código da Receita é válido para a tabela sendo usada.
• [ve0008] Tipo de Item Sendo Usado no Momento - Antes de excluir o tipo de item é preciso verificar se ele não está em uso no momento. Lembrando que essa validação não pode ser feita pelo BISValidator uma vez que o Item tem o "estado" apagado, e não é excluído fisicamente do banco de dados.

Categoria do Item

A categoria do item tem a finalidade de organizar e agrupar os itens de acordo com suas categorias. Mutias vezes a categoria é o corredor em que as mercadorias são agrupadas, como "Bazar", "Açougue", "Produtos de Limpeza", etc.

• Requisitos:
  • Estrutura Hierárquica: As categorias são uma estrutura hierárquica, isto é, permite que uma categoria seja adiciona dentro da outra.
  • Nomes Únicos 'por Pai': Os nomes das categorias são únicos dentro do mesmo pai. Em outras palavras, os nomes das categorias só podem se repetir se estiverem em pontos diferentes da estrutura hierárquica.
  • Permite Itens: Esta opção define se os itens podem ser alocados nesta categoria ou não. Quando a opção estiver desmarcada nenhum código de item deverá ser definido nesta categoria. Esta função permite que um determinado tipo de item possa ser alocado nesta categoria, mas força que os itens tenham que ser alocados nas subcategorias.
  • Congelamento de Preços: Este atributo define se os preços dos itens nesta categoria devem permanecer congelados quando forem editados ou houver uma entrada de NFe.
  • Arredondamento de Preços: Permite definir uma regra de arredondamento dos preços de venda de todos os itens que estão nesta categoria. Uma vez definida, nenhum item deverá ter um preço diferente do arredondamento definido.

• Validações Extras:
  • [ve0004] Validar a estrutura de uso por Itens e Tipo de Itens quando a categoria pai for alterada. - A categoria pai de uma categoria não pode ser alterada se algum item estiver associado à ela ou à alguma subcategoria enquanto que o seu tipo de item aponta para a categoria pai. Em outras palavras, caso ao alterar a categoria de posição na hierarquia se não invalidará as condições do tipo de item.
  • [ve0005] Hierarquia Cíclica. - Garantir que durante a atualização uma categoria não passa a apontar "como pai" uma categoria que está abaixo dela na hierarquia, criando um relacionamento cíclico.
  • [ve0007] Validar se temos exatamente 1 ItemCategoryCompanyVO por Empresa - Validar se o temos exatamente 1 definição de dados por empresa. Não devemos ter nem duplicadas, nem faltando. (BUG: 270)
  • [ve0008] Categoria de Item Sendo Usado Por Código do Item, Tipo do Item ou outra Categoria de Item - Antes de excluir uma categoria é preciso confirmar se ela não está em uso por outro objeto. Ela pode estar em uso por um código de item (verificar se o Item está ativo), ser referenciada pelo Tipo de Item (também verificar se o mesmo está ativo) ou ser pai de outra categoria (que também precisa verificar se ainda esta ativa). Lembrando que essa validação não pode ser feita pelo BISValidator uma vez que o Item tem o "estado" apagado, e não é excluído fisicamente do banco de dados.
  • [ve0010] Markup, Congelamento de Preços e Arredondamento de Preços são Obrigatórios quando a Categoria permite que itens sejam adicionados. - Validar se estão preenchidos quando a categoria permitir itens, validar se estão nulos quando a categoria não permitir itens. Quando a categoria não permitir itens, o campo MarkUp Mínimo também deve ser nulo.

ItemCodeGroup

O Grupo de Código de Item tem a finalidade de agrupar diferentes códigos de itens e fazer com que SEMPRE tenham o mesmo preço de venda. Independente de custo, categorias markups, arredondamentos, etc. Uma vez que um preço de venda de um item for alterado, os demais vão segui-lo fielmente.

• Requisitos:
  • Nome - Tudo grupo de código deve ter um nome para facilitar a identificação dos itens que fazem parte do grupo.
  • Lista de Còdigos - Dentro de um mesmo grupo podem ser associados 0+ códigos de itens. Códigos de um mesmo item podem fazer parte do mesmo grupo.
  • Sempre o mesmo preço de venda - Independente das diferentes configurações que um código de item pode ter dentro do mesmo grupo, como diferentes categorias, MarkUps, Custos, definições de arredondamento, package ratios, etc.. O preço de venda de todos os itens do grupo devem ter exatamente o mesmo valor. Mesmo que para isso tenha que desrespeitar qualquer outra regra do sistema (como arredondamento, ou cálculo de package, etc.)
• Validações Extra:
  • [ve0001] Códigos de Itens já associados a outros grupos - Durante a inserção ou atualização, um grupo não deve permitir que um código de item já associado à outro grupo seja associado a este. Em outras palavras, um código de item não pode estar associado em mais de um grupo ao mesmo tempo.

Item

A entidade Item representa um produto qualquer da empresa. Esse produto por ser um insumo, uma matéria prima ou um produto de venda (ou revenda).

• Requisitos:
  • Definição do Tipo de Item - O item pode estar associado à um tipo de item. Quando associado à um tipo de item, o item tem a possibilidade de importar toda a definição de tributos do tipo de item, ou sobrescrever e utilizar definições próprias. No entanto, uma vez vinculado ao Tipo de Item a descrição do item deverá seguir os parâmetros configurados no cadastro do Tipo de Item.
  • Dimensão e Unidade de Medida Padrão - Todo item tem uma dimensão (Massa, Unidades, Volume, Cumprimento, etc.) e uma unidade de medida (Kg, Unidades, Litros, Metros, etc.) a que se refere o item. Essa unidade identifica a unidade de quantização padrão desse item. A unidade em que por padrão esse item é comprado, vendido e movimentado. Outras unidades diferentes para venda do item podem ser definidas em códigos diferentes.
  • Custo - Todo Item tem um custo único padrão. Sempre é o custo pela unidade padrão definido no cadastro do item. O mesmo custo é utilizado para o cálculo da venda de todos os pacotes de venda.
  • Códigos dos Itens:
    • Múltiplos Códigos - Cada item pode ter mais que um código definido, ou seja, uma lista de códigos. Códigos são a maneira de definir uma quantidade, preço de venda, pacote, etc. de um determinado Item. Normalmente tem uma identificação única (e normalmente numérica, embora não obrigatória) para ser referenciada em terminais, notas, códigos de barras, etc. No entanto a identificação única não deve ser obrigatória. Um item pode ter um código para definir uma determinada quantidade de movimentação de entrada ou saída, ou simplesmente para definir uma nova unidade de medida. Por exemplo, produtos identificados hora por Kilos hora por Unidades.
    • Categoria do Item - O código de item deve ser alocado em uma categoria, para que seja recuperada as definições de categorias de produtos. As categorias podem ser "filtradas" de acordo com o Tipo de Item já escolhido. As categorias podem definir quais tipos de itens elas aceitam. As categorias carregas algumas definições como markup, congelamento de preços, arredondamentos, etc.

• Validações Extras:
  • [ve0002] Validar inconsistência entre Fabricação do Produto e Origem do Item - Se o produto for de fabricação própria, ele não pode ter uma das opções de importado definida em Origem do Item.
  • [ve0003] Validar finalidade do item - Todo item deve ter no mínimo 1 finalidade definida em seu cadastro.
  • [ve0004] Preenchimento completo dos campos do Tipo de Item - Quando definido o tipo de item, temos de validar se os campos obrigatórios do Tipo de Item estão completos.
  • [ve0005] Não permite que um Item tenha dois códigos iguais definidos - Validar se o item sendo inserido/alterado não tem definido duas vezes o mesmo código.

    Validar inclusive entre outros ItemCodes ativos. Como os produtos não são excluídos, mas sim desativados, temos que verificar a unicidade do código apenas entre os Itens Ativos.

  • [ve0006] Os códigos de item só podem ser associados às categorias permitidas para o tipo de item (quando definido) - Validar se a categoria enviada no ItemCodeVO é uma das categorias liberadas para o ItemTypeVO definido. Os códigos ficam limitados a usarem apenas as categorias permitidas (ou suar filhas) de acordo com o tipo de item.
  • [ve0007] Validar se a Categoria do Item permite a associação dos itens - Os códigos de itens não podem ser associados às categorias que não permitem a associação de itens.
  • [ve0008] Validar Finalidade do Item - O campo de finalidade não pode ter alguns alguns valores de acordo os valores definidos nos outros campos, conforme as seguintes regras:
    • Revenda: Não pode ser definido quando o produto for de Fabricação Própria.
    • Produto Acabado: Não pode ser definido quando o produto for Produzido por Terceiros.
  • [ve0010] Descrição do Item - Valida se a descrição do item é única entre os itens ativos no momento.
  • [ve0011] Itens de Revenda não podem ser Descartáveis - Valida se o item tiver o propósito como revenda, não permite que seja do tipo descartável.

Definição do Preço de Venda

Definição do Novo Preço Quando desejamos definir um novo preço para um item devemos colocar o valor sempre no campo price. O Core irá avaliar o valor desse campo, e se for diferente do valor original na base de dados, fará todo o processo abaixo. E caso o item tenha definição de congelamento de preço, o Core IMPEDE que o preço seja aplicado, passando o novo valor para o campo freezePrice e retornando o valor original para o campo price. Caso algum valor seja escrito no campo freezePrice, o valor passará normalmente e será salvo na base como o preço congelado do item. No entanto, caso o valor de price também seja alterado, como citado acima, o valor de freezePrice será sobrescrito com o valor de price. Para itens com definição de congelamento de preços, a única maneira de efetivar o preço congelado deverá sendo utilizando o método de descongelamento (citado no fluxo abaixo). Caso contrário o preço sempre deverá terminar congelado.

Há vários fatores sobre a lógica de calcular definir um novo preço de venda. Como as políticas de arredondamento, congelamento de preço, replicação do preço para outros códigos do mesmo grupo, a movimentação de novos preços para histórico, etc.

A ordem das operações lógicas a serem aplicadas sobre o ItemCodeVO devem ser conforme a ordem dos métodos listados abaixo. Cada método executa a operação a partir de um determinado ponto. Isso permite que diferentes eventos que causam a alteração do preço de venda possam acionar o ciclo a partir de diferentes pontos.

Diagrama do fluxo da lógica de alteração do preço de venda de um Código de Item. E entrada dos eventos que causam essas alterações.

updateItemCodePrice_Apply(...)

O método final da lógica de definição do preço de venda. Responsável por "executar as alterações conforme mandado". Este método faz as seguintes operações:

• Compara o objeto original (versão do banco antes do começo da operação) com os parâmetros de preço e congelamento recebidos.
• Há alteração no preço ou no preço congelado?
  • SIM
    • Persiste um novo objeto de Histórico de Preços do Código com os valores atuais lidos do objeto atual
    • Atualiza as informações do "novo" ItemCodeVO recebido com os todos os novos valores, deixando-o pronto para se persistido.
    • Retorna true, indicando que houve alterações e que o "novo" ItemCodeVO precisa ser persistido.
  • NÃO
    • Copia todos os atributos referente ao preço do ItemCodeVO "original" para o ItemCodeVO "novo", de forma que mesmo que ele seja persitido, nenhuma alteração será efetivada.
    • Retorna false, indicando que o objeto não precisa ser persistido.

Ordem da persistência do ItemCodeVO Observe que este método está no fim da cadeia de definição do preço e ele depende do ItemCodeVO "original" (versão do banco de dados antes do começo da operação). Por isso, para um funcionamento correto a versão original do ItemCodeVO precisa ser salva antes que qualquer persistência do novo objeto ocorra. O método de Apply retorna true/false para indicar se o objeto precisa ser persistido (em casos de alteração). Caso ele retorne false o objeto não precisa, mas pode, ser persistido. Em casos que estamos manipulando o ItemCodeVO diretamente conseguimos evitar o update no banco. Mas caso estejamos manipulando o ItemVO por exemplo, o ItemCodeVO é persistido em cascata, por isso o método garante que o novo objeto terá as informações do VO original ao retornar.

• updateItemCodePrice_Definition(ItemCodeVO) - Primeiro passo. Este método não faz nenhuma alteração no banco de dados, e deve receber o ItemCodeVO também antes que este seja salvo no banco. Este método comparará o objeto recebido com os valores no banco. Verificará se o preço deve ou não ficar congelado (baseado nas definições de categoria do objeto recebido, e não do existente em banco de dados). E fará as seguintes análises:

1. Há Regras de Arredondamento?
   1. SIM: Aplique as regras tanto em price quanto em freezePrice.
2. Há diferença entre o preço recebido e o preço na base de dados?
   1. SIM: Há definição de congelamento de preço na categoria do item?
      1. SIM: Passa o valor de price para freezePrice e retorna o valor original de price conforme na base de dados. "AlteraPreço = NÃO"
      2. NÃO: Definimos freezePrice como nulo. "AlteraPreço = SIM"
3. 3. Se (freezePrice == price) Define freezePrice = nulo.
4. 4. Se (AlteraPreço == SIM) Cria registro do histórico de mudança no preço de venda.
5. 5. Retorna "AlteraPreço".

• Depois de chamar o updateItemCodePrice_Definition(...) para todos os ItemCodeVO do objeto, o objeto principal sendo salvo (Ex. ItemVO) deve ser persistido. Assim este item já estará com seus preços e definições corrigidos.

Aplicação da Política de Arredondamento Para centralizar o código de aplicação da política, a efetiva aplicação do arredondamento fica na classe utilitária ItemUtils no método applyRoundPricePolicy(). Podendo ser acessado de qualquer ponto, como classes da UI.

• Disseminação do Preço de Venda pelo Grupo - Caso o ItemCodeVO cujo preço de venda que foi alterado faça parte de um grupo, este preço de venda deverá ser disseminado para todos os membros do Grupo.

  updateItemCodePrice_GroupDisseminate() - Recebe o ID do grupo, o preço a ser aplicado e o preço congelado e aplica igualmente a todos os membros do grupo. Este método não faz qualquer processamento no valor, apenas verifica os códigos envolvidos no grupo e aplica o valor, congelado ou não conforme informado via parâmetros). O valor será aplicado a todos do grupo conforme recebido, "passando por cima" das configurações de arredondamento e políticas de congelamento de cada código. Para todos os preços ou preços congelados que forem alterados o histórico de preços do item ganha um novo registro informando que foi alterado pelo grupo.

Eventos de Alteração do Preço de Venda

• Cadastro/Alteração de Itens - Quando um item é cadastrado ou alterado ele tem definições de códigos e consequentemente de preços de vendas. Neste caso avaliamos as seguintes condições para cada código:
  • Para cara ItemCodeVO existente:
    • Se Tem um grupo associado e Devemos copiar o valor atual sendo praticado no grupo - Neste caso vamos buscar o valor de qualquer código do grupo (afinal devem ser todos iguais) e copiamos o seu preço, e jogamos nulo no preço congelado. e Continuamos
    • Chamamos o _Definition()
  • Salvamos o objeto ItemVO.
  • Novamente para cara ItemCodeVO existente:
    • Se Tem um grupo associado e Devemos definir novos valores para o código e para o grupo - Se devemos associar novos valores para o grupo deste código, chamamos o _GroupDisseminate() que jogará os valores de venda diretamente para o grupo todo.
• Descongelar o Preço de Venda - Descongelar significa efetivar o preço que está congelado como o preço praticado para venda. Para evitar qualquer reprocessamento no valor, mas ainda assim garantir que o novo valor efetivo de venda será definido em todos os códigos do mesmo grupo este método chama o _GroupDisseminate().
• Descartar Preço Congelado - Quando não queremos que o preço congelado entre em vigor podemos simplesmente descartar o preço congelado, e manter o código com o mesmo preço que já tinha. Neste caso queremos que todos os códigos do mesmo grupo descartem seu preço congelado e que continuem mantendo o preço já praticado. Para evitar o processamento dos valores mas ainda realizar a operação em todos os códigos do grupo chamamos o _GroupDisseminate().

Definição da Tributação

O BIS mantém separado as caraterísticas do produto (Cadastro do Item) e as definições tributárias brasileiras. Entende-se por definição tributária as caraterísticas dos impostos, sejam eles federais, estaduais ou municipais, suas diferenças entre os estados ou municípios do emissor ou receptor, se a ação é uma venda, revenda ou devolução, todas as demais peculiaridades dos impostos brasileiros. Atualmente a definição tributária está definida exclusivamente no tipo de item.

De acordo com as informações tributárias cadastradas no tipo do item, com os dados cadastrados no item (como NCM, volume da embalagem, etc), do endereço do emissor da nota, do endereço do destinatário, da operação sendo realizada, entre outras informações pertinentes a situação, o BIS deverá definir as alíquotas e outras condições a serem utilizadas automaticamente.

Durante a definição da tributação a ser utilizada o BIS deve fazer as seguintes validações para garantir uma "escolha" mais correta da tributação e evitar erros de cadastro e lançamento de notas.

• [ve0001] Valida Item de Fabricação Própria em Tipo de Substituição - Valida se o Item é de produção própria e está em um tipo de item com a tributação de ICMS definida como Substituição Tributária.

  No momento estou considerando o BIS focado em padaria, onde nada que é produzido é tributado como substituição, já que só vendemos ao consumidor final a produção, mesmo sujeitas a substituição. Caso o BIS cresça mais, o ideal seria ter uma flag no cadastro da empresa (algo como um perfil, similar ao perfil do investidor das corretoras que perguntam e definem peculariedades de cada um), que informasse se empresa fabrica produtos sujeitos a recolher o ICMS por substituição, e se realiza operações sujeitas a esse recolhimento.