Itens

O módulo Item é o 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 (e treinamento) de quem cadastra os itens.
• A empresa pode deve associar os tipos de itens às categorias de produtos criada pela empresa, assim uma vez que o tipo de item foi informado, o usuário não consegue errar a categoria. As vantagens são que 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] 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 automaticamente. Para tal tarefa devemos disparar um evento que dispara uma tarefa para realizar a atualização em background. O usuário não deve ficar aguardando essa tarefa ser completada.

• [ve0002] Ao alterar o status do Tipo de Item, é preciso marcar/desmarcar os itens para revisão - Quando um tipo de item é marcado como desativado, os itens que estão utilizando esse tipo de item precisam ser marcados para serem revistos. Ao mesmo, se um tipo de item volta a ser marcado como ativo, os itens marcados para revisão por esse motivo precisam ser desmarcados.

• [ve0003] Ao alterar os campos de um Tipo de Item, itens precisam ser revistos - Quando os campos do tipo de item sofrerem alteração, é preciso revalidar se os itens associados continuam válidos em relação ao preenchimento do formulário, uma vez que a definição correta da tributação a ser utilizada depende destas informações.

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.

As categorias de item são definidas individualmente por cada empresa do sistema.

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 poderá ser definido nesta categoria. Note que na hierarquia das categorias, uma categoria pode aceitar itens, ou pode ter categorias filhas. Uma categoria não pode ser um "nó" (ser pai de outras categorias) e ao mesmo tempo ter itens atribuídos à ela.
• MarkUp: Define o markup que deve ser utilizado nos códigos que forem alocados nesta categoria.
• MarkUp Min: Define um markup mínimo que o item deve manter. O sistema monitora os itens que tem um markup mínimo definido, e sempre que o item estiver praticando um markup menor que o mínimo o sistema marca o item para revisão do usuário.
• 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.

Sobreposição dos Grupos de Itens Note que apesar das definições de congelamento e de arredondamentos de preços, o sistema pode atribuir preços diretamente nos produtos ignorando essas regras quando a definição é feita a partir do Grupo de Itens. Isso ocorre porque o Grupo de Itens garante que todos os itens do grupo terão o mesmo preço final definido, mas se eles tiverem regras diferentes definidas teremos conflito. Para solucionar o conflito, o Grupo de Itens forçará o preço do item que está sendo alterado em todos os outros do grupo sem olhar para as suas regras de Categoria.

Validações

• [ve0001] Não permite que uma categoria tenha o mesmo nome "debaixo do mesmo pai". - Valida os nomes das categorias "irmãs" garantindo que a categoria tem um nome único na estrutura.
• [ve0002] Não permite que uma categoria que permita itens tenha filhos. - O sistema deve realizar validações para garantir que uma categoria não tenha itens associados e categorias filhas ao mesmo tempo.

• Não Validar: Caso a categoria já tenha itens associados deve ser permitido mudar a categoria para 'Não Permitir Itens'. Assim o usuário pode impedir que novos itens sejam adicionados à esta categoria no futuro. O validador de cadastro deve verificar itens que estão em categorias sem permissão e marcar os itens para serem revistos.
• Uma categoria pode ter itens e subcategorias simultaneamente sem problemas. Uma categoria pode até ter itens excluídos, etc.

• [ve0003] Valida se os campos MarkUp, FreezePolicy e RoundPolicy estão preenchidos caso a categoria permita itens. - Quando uma categoria é definida para permitir itens, o sistema deve validar os campos MarkUp, FreezePolicy e RoundPolicy, que se tornam obrigatórios.

• Não Valida: o caso contrário. Se uma categoria não permite itens, os campos MarkUp, FreezePolicy e RoundPolicy podem ou não estar preenchidos. Pois a opção de não permitir itens é só em relação a novos itens , a categoria pode ter itens anteriores e até excluídos que não impedem que a categoria seja alterada para não receber novos itens.

• [ve0004] Hierarquia Cíclica. - Garantir que durante a atualização de uma categoria não passa a apontar "como pai" uma categoria que está abaixo dela na hierarquia, criando um relacionamento cíclico.

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 se sobrepondo as definições individuais.

Requisitos

• Nome - Todo 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 ou mais códigos de itens. Códigos de um mesmo item podem fazer parte do mesmo grupo.
• Política de Definição - Ao se criar/alterar um grupo, sua lista de códigos associados podem ser alteradas. Ao confirmar a alteração do grupo de item o sistema deve solicitar ao usuário algumas definições de como o BIS deve proceder para equalizar o preço de todos os itens do grupo:
  • Copiar o Preço de um dos Códigos do Grupo - Nesta opção o usuário deve apontar o código de item que servirá como base, e o preço definido nele será aplicado para todos os demais itens do grupo. Os itens que já estavam no grupo já devem estar com o mesmo preço e não sofrerão qualquer alteração, mas itens recém associados terão seus preços atualizados.

    Obs1 - Para que esta política funcione o Grupo precisa ter pelo menos 1 código associado, para que seja apontado como o código base. Se o Grupo não tiver nenhum item associado essa política não poderá ser utilizada por falta de um "Código Base".

  • Definir um Valor Manualmente - Nesta política permite que o usuário informe o preço de venda que deseja aplicar a todos os códigos associados no grupo.

Preços Definidos pelo Grupo Não Respeitam Congelamento Quando o preço de ItemCode for alterado através do Grupo de Código, o preço será definido conforme a política escolhida pelo usuário, mas o valor nunca fica congelado. Em caso de alteração do preço, o ItemCode terá seu preço corrigido diretamente e qualquer preço congelado do ItemCodeVO será descartado. Se não houver diferença entre o preço sendo aplicado e o preço de venda já existente, nenhuma alteração é realizada no ItemCodeVO. Isto é, se ele tinha algum preço congelado, ele continuará lá.

Validações Extra

• [ve0001] Códigos de Itens já associados a outros grupos - Durante a inserção ou atualização, um código não pode estar associado à mais de um grupo. Por isso quando um código de item for associado ao grupo, o sistema deve se certificar de que ele será removido de quaisquer outros grupos.
• [ve0002] Não é permitido incluir códigos de itens inativos - Validar se todos os códigos associados ao Grupo são de itens que estão ativos.

Item

A entidade Item representa um produto/serviço qualquer da empresa. Esse produto/serviço por ser um insumo, uma matéria prima ou um produto de venda (ou revenda), um item do ativo imobilizado, um serviço, etc..

Requisitos

• Definição do Tipo de Item - O item pode estar associado à um tipo de item. Quando associado à um tipo de item, o item deve completar todos os campos e definições do Tipo de Item para obter todos os benefícios citados nos requisitos 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. Que deverá ser a medida de contabilização de estoques. 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.

  A unidade de medida padrão do item não pode ser alterada! Uma vez que o item foi criado, sua unidade de medida padrão não pode mais ser alterada. Isso porque precisamos de uma constância da unidade de medida para a escrita contábil. Alterar a unidade de medida principal do item causará problemas na contabilização do estoque, inconsistências entre as quantidades reportadas no SPED ou mesmo problemas em relação a quantidade vendidas no PDV.

• Custo - Todo Item tem um custo único padrão. O custo é sempre 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.
• Pacotes:
  • Múltiplos Pacotes - Cada item pode ter mais que um pacote definido. Pacotes são utilizados para definir como um item é vendido (quantidade do pacote, preço de venda, unidade de medida, etc.). Normalmente cada pacote tem uma identificação única (o "código"), que é normalmente numérica para ser referenciada em terminais e leitores de código de barras, mas pode ser alfanumérica. O código não deve ser de preenchimento obrigatório. Um item pode ter um pacote 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 hora movimentados por Kilos hora por Unidades.
  • Grupos de Pacotes - os pacotes de um item podem ser agrupados dentro dos grupos de pacotes (ou grupo de códigos). Veja detalhes nos requisitos do Grupo de Item.
• Categoria do Item - O pacote do 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. A categoria trás algumas definições que serão aplicadas no pacote, como, por exemplo, o markup, congelamento de preços, arredondamentos, etc.
• Item Precisa de Revisão (review*) - O item deve ter um conjunto de flags para que o sistema os revise e os marque para uma revisão do usuário. As situações e flags que marcam um item para revisão são:
  • Alteração no Formulário do Tipo de Item (reviewItemType) - Sempre que um Tipo de Item sofrer alteração no seu formulário (adicionando ou removendo algum campo) ou tiver mudança no seu estado, deixando o item incompatível com as definições do Tipo de Item, o item deve ser marcado para revisão.
  • Preço de Venda Abaixo do Markup Mínimo (reviewPrice) - Quando algum de seus pacotes estiver vendendo abaixo com preço abaixo do markup mínimo (flags do ItemCodeVO belowMinimumMarkup = TRUE).

Validações Extras

• [ve0001] Descrição do Item - Valida se a descrição do item é única entre os itens ativos no momento.
• [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] Itens de Produtos Acabados e para Revenda precisam ter um pacote para venda do Item - Produtos cuja finalidade for venda precisam ter um pacote definido. Não necessariamente um código numérico, embora desejável. E definir o preço de venda. Produtos como matéria prima, ou produtos intermédios, etc. não necessitam a definição de um código, uma vez que seu custo e estoque pode ser calculado sem o cadastro de pacotes.
• [ve0009] Valida se o Tipo de Vendedor é adequado para o campo Fabricação do Produto - Quando a fabricação do produto é de terceiros o tipo de vendedor não pode ser algo como "Produtor", "Industria", "Manufatura", pois trata-se de terceiros, assim quando a fabricação é própria o tipo de vendedor não pode ser "Revendendor", "Importador", "Distribuidor", etc.
• [ve0010] 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.
• [ve0011] Validar finalidades de itens incompatíveis entre elas - Alguns tipos de finalidade do item não podem ser definidas ao mesmo tempo, são elas:
  • Produto Acabado - Não pode ser definido junto com Matéria Prima
• [ve0012] Validar Régua de Equivalências - A régua de equivalências do Item, se definida, deve ter no mínimo 2 entradas válidas e a unidade de medida padrão do item deve ser obrigatoriamente uma delas.
• [ve0013] Contraste entre as informações do ItemCodeVO e ItemCodeConsumerTaxesVO - Garantir que os valores só sejam definidos no ItemCodeConsumerTaxesVO se estiver definido como Override no ItemCodeVO, e vice-versa. Além de validar se os dados que foram preenchidos no ItemCodeConsumerTaxesVO estão adequadamente preenchidos.

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_Definition(...)

Este método é o inicial (1° passo), e sua única função é preparar o preço recebido conforme as regras de precificação definidas no código do item (congelamento, arredondamento, etc.).

Ele deve ser chamado quando estamos atualizando o preço de venda do código de item diretamente, assim fazemos respeitar suas regras. Normalmente chamado quando editamos um item diretamente e alteramos seu preço de venda, ou em uma entrada de nota, que afeta diretamente o custo de um item e em seguida o preço de venda de seus códigos.

updateItemCodePrice_GroupDisssminate(...)

Este método é o seguinte da lógica (2° passo). Este já recebe o preço como deve ser e a definição se vamos ou não manter esse preço congelado ou efetivado. Deste ponto em diante não se verifica mais as configurações do ItemCode.

A principal função deste método é garantir que o preço e sua condição de congelamento seja aplicada em todos os ItemCode que estiverem no mesmo grupo. Em outras palavras, esse método verifica se há um grupo no ItemCode e, havendo, chama o próximo passo para todos os ItemCode do grupo, garantindo que todos terão a venda por igual.

O ItemCodeVO inicial não é persistido Note que este método busca o grupo e chama o próximo passo para todos os itens que estão no grupo, e se o próximo passo retornar true, este método já persiste cada ItemCodeVO. No entanto, o ItemCodeVO que foi recebido como parâmetro no método não será persistido. Ele também será passado para o próximo passo, mas mesmo que o próximo passo retorne true, o VO não será persistido aqui, mas o retorno do próximo passo será retornado igual. Fazemos isso pq não cabe a esse método decidir se é o melhor momento de persistir esse objeto. Por exemplo, ele pode não ter um ID ainda, ou ter ItemVO sem ID (caso de cadastro de Item novo). O objeto pode ser proveniente de uma alteração e estar ou não no grupo na versão original. Assim, para um funcionamento mais constante e previsível, além de evitar operações repetidas no banco de dados, o objeto recebido não é persistido dentro do método, só os demais do Grupo.

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 recuperada antes que ocorra qualquer persistência do novo objeto. 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.

Chamada Final Não Verifica o Grupo É preciso tomar cuidado ao chamar este método. É importante entender os três passos da definição para saber em qual passo uma atualização dos preços será executada. Por exemplo, se ao atualizar os preços de um grupo chamarmos o primeiro passo, entraremos em loop infinito por que a cada atualização vamos disparar uma nova atualização do grupo, e dependendo das regras de cada item do grupo ainda teremos a definição de preços arredondados de formas diferentes em cada ciclo. Por outro lado, chamar diretamente o último passo pode fazer com que somente um item seja atualizado sem respeitar as regras do grupo (deixando itens com preços de vendas diferentes).

Tributação do Item

A tributação do item é definida no Pacote do Item. O motivo é que dependendo do tamanho/quantidade do pacote e as vezes até da embalagem, a tributação pode ser diferente.

Em geral a tributação das operações é orientada pelas Regras Tributárias do sistemas TaxRules, porém cada Pacote do Item deve ter a opção de se "sobrepor" as definições do sistema. Desta forma permitimos que o usuário tenha autonomia de definir a tributação como precisar. Principalmente quando as TaxRules não estiverem completas ou são inadequadas para o item.

A tributação a ser definida no cadastro do pacote é sempre foco na venda direta para o consumidor, em geral no próprio estabelecimento. Ou seja, as vendas feitas no PDV da loja. Essas definições precisam estar definidas no cadastro do item pois o operador do checkout não deve se preocupar isso. Outras operações, que são emitidas por NFe (mesmo as vendas a consumidor também) terão as opções de definição da tributação preenchidas no momento de preenchimento do documento NFe.

No futuro, se for conveniente, até podemos permitir que a tributação de outras operações já sejam salvas dentro do item, mas para agora não vejo nenhum benefício nessa complexidade.