Módulo Fiscal

O módulo Fiscal do BIS tem a finalidade de gerenciar e dar suporte para o tratamento de documentos fiscais, como NFe e NFCe.

O módulo Fiscal pode ser utilizado por outros módulos para gerar ou obter informações desses documentos, por exemplo, o módulo de compras pode usar o módulo fiscal para obter dados da NFe sem que tenha que conhecer sobre XML da NFe, assim como o módulo de vendas, ou de PDV pode solicitar a emissão de um cupom ou NFe sem ter de conhecer a integração com o SEFAZ ou trabalhar com os certificados digitais.

Bibliografia e Referências

• RFW.SEFAZ: https://wiki.rodrigogml.eng.br/index.php?title=P%C3%A1gina_principal#RFW_-_Sefaz

• Projeto utilizado como base para comunicação com a SEFAZ, abstraíndo toda a comunicação e muita implementação relacionada a SEFAZ. A documentação sobre a SEFAZ deve ser feita apenas no projeto RFW.SEFAZ, aqui devem ser feitas apenas a documentação relacionada ao BIS e como ele trata os documentos internamente.

Requisitos e Implementação

O novo módulo fiscal, sendo implementado a partir da migração do SAT para o NFCe utiliza o RFW.SEFAZ como base para a comunicação com a SEFAZ e os objetos oferecidos SEFAZ*VO para armazenar os dados dos documentos fiscais. Por ser uma representação do XML da SEFAZ, esses objetos se assemelham em estrutura e formato de dados ao próprio XML do documento, com excessão de algumas otimizações para persistir no banco de dados.

Esses VOs do RFW.SEFAZ vêm com o schema padrão _RFW.SEFA e tabelas com o prefixo sefaz_. Os mesmos nomes de tabela sugeridos pelo módulo são utilizadas no BIS, já o Schema é corrigido através de um DAOResolver.

Uma vez que os VOs oferecidos por RFW.SEFAZ não podem ser alterados para inclusão de outros atirbutos e relacionamentos que atendam a lógica de funcionamento do ERP, uma estrutura 'paralela' foi desenvolvida para atender as necessidades de negócio, deixando os objetos ofercidos pelo módulo estritamente responsáveis por armazenas os documentos, eventos e resultado de comunicações.

Convenções importantes adotadas sobre os documentos fiscais:

• Todo documento fiscal do BIS será representado pelo DocFiscal. Este objeto representará todo e qualquer documento fiscal, servindo de raiz para todas as derivações de documento fiscais existentes. Este VO além de ter as informações principais do documento fiscal (comuns a qualquer documento emitido), e atributos de controle (incluindo subobjetos) pode ter a referência para o SEFAZNFeVO ou para o objeto/arquivo do SAT/ECF ou qualquer outro documento fiscal a ser implementado no futuro.
• DocFiscal concentrará todos os objetos relacionados ao documento fiscal, por exemplo, além de objetos de sua definição, pode conter objetos relacionado a entrada do documento no sistema, ou a lista de eventos e histórico do documento, outros objetos/documentos relacionados (como carta de correção, nota de cancelamento, etc.), vínculos entre o item do documentos e do cadastro do sistema em documentos emitidos, etc.
• Alguns relacionamentos do DocFiscal poderão ser Composição, outros Associação, conforme o caso e estratégia de implementação.

DocFiscalVO

O DocFiscalVO - e sua estrutura DocFiscal*VO - é utilizada para representa um documento fiscal qualquer dentro do sistema. Seja uma NFe, NFCe, CTe, etc..

O DocFiscaoVO apresenta uma enumeration (DocFiscalStatus)para definir seu estado, são eles:

• SELLING - Indica que o documento está em processo de venda, registro dos itens, rascunho. Esse status é utilizado, por exemplo, nos terminais quando a venda ainda está sendo montada.
• STORED - Indica que o conteúdo do documento fiscal iniciado (SELLING) foi desfeita porque a venda foi guardada em um token. Uma venda que foi guardada depois será contabilizada como cancelada ou finalizada em algum PDV. No entanto neste momento contabilizamos apenas que a venda foi 'guardada' para efeitos de controle da emrpesa.
• SOLD - Indica que a venda foi realizada e que o documento fiscal foi emitido com êxito.
• CANCELLING - Estado que indica que o documento está em processo de cancelamento, porém ainda não foi completamente cancelado. O processo de cancelamento pode exigir uma coleção de estados próprios para o processo de cancelamento do documento, por exemplo: como o estorno/devolução de pagamentos em cartão, solicitação de cancelamento na SEFAZ, entre outros.
• CANCELED - Indica que a que a venda foi cancelada! Tendo ou não cupom já emitido. A difereça entre ter o documento já emitido ou não pode ser avaliada, por exemplo, pela presença dos XMLs ou de número/serie atribuídos ao objeto.
• SEFAZVALIDATING - Informa que a venda e pagamentos foram finalizados, e que o cupom foi enviado para a SEFAZ e estamos agora aguardando sua autorização ou negação.
• SEFAZPROBLEM - Informa que a venda foi enviada para a SEFAZ mas foi rejeitada.
• ERROR - Significa que o cupom terminou em erro e por algum motivo o sistema não conseguiu recuperar ou obter informações sobre essa venda. Em geral esse erro indica que nem a comunicação com a SEFAZ foi realizada.
• ERROR_SYNC - Finalizado com erro e falta de sincronia. Erro em que o sistema não tem certeza no que ocorreu com o DF se foi registrado ou não. Precisará de avaliação e correção Manual.

Ciclo de Vida Documento Fiscal

O ciclo de vida do documento fiscal pode ser visualidado pela imagem a seguir:

Estados de Erros Os estados de erros não foram representados abaixo pois eles podem ocorrer a partir de qualquer um dos estados.

---

!!!!!!DOCUMENTAÇÃO AGUARDANDO REVISÃO!!!!!!

Gerenciamento de NFe

Um dos documentos fiscais gerenciado pelo módulo são as Notas Fiscais eletrônicas (NFe) recebidas de fornecedores, notas de compras. Tendo assim uma tela onde é possível enviar para o sistema arquivos .XML de notas para cadastra-las no sistema. Essa nota ficará armazenada no sistema por tempo indeterminado, e pode ser encontrada e visualizada sempre que necessário. O arquivamento feito no BIS pode ser utilizado para fins de arquivamento pelo prazo legal.

Importação de NFe a partir E-mail

Na tela de configurações do módulo deverá ser possível configurar se deseja que o módulo busque por NFe nos e-mails recebidos. A principio o módulo não fará distinção entre caixas de e-mail, se selecionado ele buscará em todas. No futuro pode-se estudar a funcionalidade, se necessário, de especificar as caixas de e-mail que quer que o sistema verifica a existência de NFes ou não.

Entrada de Custos a partir de NFe

Uma vez que as notas estiverem no sistema, o sistema será capaz de abrir e dar entrada dos custos dessas notas. A partir de qualquer nota que já esteja no sistema, o usuário poderá seleciona-la e forçar o sistema a dar entrada dessa NFe. A partir de critérios explicados mais a baixo o sistema mapeará os itens da NFe com os itens do sistema e deixará a entrada sugerida cadastrada no sistema. A partir de outra tela (de gerenciamento de entradas de custos) o usuário poderá confirmar, negar ou alterar as entradas sugeridas pelo sistema.

O sistema deve ter nas configurações do módulo dois campo em porcentagem. Neles o usuário poderá configurar qual a alteração mínima que um preço de venda deve ter para que o sistema sugira autera-lo. Caso o usuário dê a entrada do item e informe que não deve alterar o preço de venda, apenas o custo é alterado para questões de histórico custo deste item.

Nesta tela (de gerenciamento de entrada de custos) devem ser exibidos uma lista de todas as entradas realizadas, as com alterações sugeridas, com alterações negadas e as que não foram mapeadas. Abaixo os botões com as opções:

• Confirmar Mapeados - tentará confirmar a entrada de todos os itens que estão pendentes e já foram mapeados. Os itens que não foram mapeados não serão confirmados.
• Excluir Não Mapeados - Excluí todos os itens que não estão mapeados a nenhum item.
• Excluir - Exclui os itens selecionados.

O sistema deve ter uma opção nas configurações que informe se o BIS deve efetuar entrada de notas das notas que chegarem automaticamente por e-mail.

Alerta de alteração de custo O sistema deve deixar o preço do item em modo de alerta, e alertar o usuário quando a alteração do preço for muito grande. Para definir o que é "muito grande" deve-se ter essa configuração na tela de configurações do módulo.

Mapeamento dos Itens da NFe e os Itens do Sistema

Para tentar mapear os itens da NFe e do sistema o BIS usará as seguintes técnicas na ordem abaixo para sugerir o item certo:

Busca sempre pelo Emissor da NFe Quando utilizamos a busca de histórico para associar um item da nota ao item do sistema, levamos sempre em consideração o emissor da nota. Pois para mesmo produto e diferentes emissores (fornecedores) as quantidades e consequentemente os valores calculados tendem a serem diferentes.

1. Busca no histórico por Descrição da NFe e Unidade Comercial - Busca no histórico se há entrada de nota com a mesma descrição e unidade comercial. Leva em consideração ambos os argumentos pois o mesmo fornecedor pode usar a mesma descrição do item, mas vender uma caixa e/ou um fardo o que troca a quantidade de venda, e consequentemente o divisor do sistema.
2. Busca no histórico pelo EAN Comercial (caso disponível na NFe) - Busca no histórico de entrada de notas se há alguma entrada do mesmo emissor da nota e mesmo código EAN escrito na nota. Se tiver um histórico verificamos qual foi o item associado na última entrada e utilizamos o mesmo divisor.
3. Busca pelo EAN Comercial (caso disponível na NFe) - e tenta mapear no item do sistema.

Dependência com Outros Módulos

• Item