UC00099 - Integração Java/ECF
Conteúdo |
Objetivo
Atores
- Usuário
Pré-requisitos
- Considerar documento Padrões de desenvolvimento.
Resultado esperado
Diagrama de classes
Fluxo de eventos
Fluxos principais
Fluxo 1:
Fluxos alternativos
Fluxo 1: Com os parâmetros de ECF da filial logada configurados como IMPORTA SERVIÇO = Sim e OPERAÇÃO DO PAF = NFC-e, o usuário faz um pedido no Resulth WEB que contem produtos e serviços e em seguida tenta importa-lo no ECF.
- O ECF importará o pedido normalmente, mas considerará somente os produtos do mesmo. Enquanto OPERAÇÃO DO PAF = NFC-e os serviços serão desprezados na importação de pedidos.
Fluxo 2: Usuário acessa no Resulth WEB o cadastro de operações de saída e entra em modo de alteração em uma das operações listadas na regra de negócio RN01 alterando somente o estado do parâmetro Gera contabilidade e acionando o botão [Salvar] em seguida.
- Desde que tenha sido alterado somente o estado do parâmetro Gera contabilidade na aba Movimentos, o sistema irá atualizar o cadastro da operação em questão.
Fluxos de exceção
Fluxo 1: Usuário inicializa o módulo ECF, sendo que ele possui em uma determinada filial dois ou mais ECF´s cujas configurações estão diferentes uma da outra.
- Se nos parâmetros da filial as configurações de todos os ECF´s/PDV´s não forem exatamente iguais para a filial logada, será emitida ao usuário a seguinte mensagem de alerta: Para a filial XXX - XXXXXX existem um ou mais ECF´s cujas configurações diferem dos demais. É altamente recomendado que todos os ECF´s utilizem a mesma configuração. Onde X corresponde ao código e nome da filial.
- A mensagem será apenas um alerta e não impedirá o usuário de prosseguir com seu fluxo.
Fluxo 2: No Resulth WEB o usuário acessa o cadastro de operação de saída entrando em modo de alteração em uma das operações listadas na regra de negócio RN01 alterando configurações que sejam diferentes do parâmetro Gera contabilidade acionando o botão [Salvar] em seguida.
- Sistema aborta a operação e emite ao usuário a seguinte mensagem de alerta: Não é permitido alterar as configurações desta operação, pois suas configurações são definidas por padrão no sistema e a mesma é utilizada na sincronização de dados com o módulo ECF.
Fluxo 3: No Resulth WEB o usuário acessa o cadastro de operação de saída e tenta excluir uma das operações listadas na regra de negócio RN01.
- Sistema aborta a operação e emite ao usuário a seguinte mensagem de alerta: Não é permitido excluir esta operação, pois a mesma é utilizada na sincronização de dados com o módulo ECF.
Regras de negócio
RN01 - Operações
VENDA DIRETA NO ECF
Operação padrão do sistema para vendas realizadas diretamente no ECF que serão sincronizadas/enviadas para o Resulth WEB. Esta operação terá as seguintes características:
- Ativa = Sim
- Considera em vendas = Sim
- Considera em comissão = Sim
- Devolução de compras = Não
- Gera contabilidade = Opcional
- Gera estoque = Sim
- Gera financeiro = Sim
- Saída corresponde a uma NF feita manualmente = Não
- Nota fiscal de ajuste = Não utiliza
- Gera livros fiscais = Sim
- Permite bonificação = Não
- Calcula ICMS = Sim
- Calcula PIS = Sim
- Calcula COFINS = Sim
- Destacar/Informar ST manualmente = Não
- Calcula IPI/Destacar = Não
VENDA NO ECF IMPORTANDO PDV
Operação padrão do sistema para vendas no ECF através da importação de PDV (não será utilizada na importação de DAV) que serão sincronizadas com o Resulth WEB. Esta operação terá as seguintes características:
- Ativa = Sim
- Considera em vendas = Não
- Considera em comissão = Não
- Devolução de compras = Não
- Gera contabilidade = Opcional
- Gera estoque = Sim
- Gera financeiro = Não
- Saída corresponde a uma NF feita manualmente = Não
- Nota fiscal de ajuste = Não utiliza
- Gera livros fiscais = Sim
- Permite bonificação = Não
- Calcula ICMS = Sim
- Calcula PIS = Sim
- Calcula COFINS = Sim
- Destacar/Informar ST manualmente = Não
- Calcula IPI/Destacar = Não
VENDA DIRETA NO ECF OU IMPORTAÇÃO DE PEDIDO PARA EMISSÃO DE NFC-e
Tanto vendas diretas no ECF quanto importação de PDV´s que resultem na emissão de NFC-e, na sincronização com o Resulth WEB será gerado um documento fiscal de saída e para este deverá ser utilizada uma operação com as seguintes características:
- Ativa = Sim
- Considera em vendas = Não
- Considera em comissão = Não
- Devolução de compras = Não
- Gera contabilidade = Opcional
- Gera estoque = Não
- Gera financeiro = Não
- Saída corresponde a uma NF feita manualmente = Não
- Nota fiscal de ajuste = Não utiliza
- Gera SPED Contribuições = Sim
- Gera livros fiscais = Sim
- Permite bonificação = Não
- Calcula ICMS = Sim
- Calcula PIS = Sim
- Calcula COFINS = Sim
- Destacar/Informar ST manualmente = Não
- Calcula IPI/Destacar = Não
Para pedidos do tipo OS não será necessário ter uma operação padrão definida uma vez que as movimentações de estoque e geração do financeiro já foram realizados.
Em outras palavras, o cupom gerado para um pedido de OS não movimentará estoque nem gerará financeiro.
Pedidos do tipo DAV não podem movimentar estoque e nem gerar financeiro. Sendo assim, quando importados no ECF, as movimentações serão geradas quando o cupom for
sincronizado com o Resulth WEB a exemplo de como ocorre com a venda direta no ECF.
Operações padrão para integração com o ECF não podem ser alteradas ou excluídas pelo usuário.
RN02 - Sincronização
PDV´s importados para o ECF
Ao importar PDV´s para o ECF as seguintes regras devem ser observadas:
- PDV´s que já movimentaram estoque: Estes pedidos serão listados no ECF junto com os demais pedidos que ainda não movimentaram estoque, porém não poderão ser importados para emissão do cupom. Caso usuário informe diretamente o código ou selecione na filtragem um PDV que já movimentou estoque, o ECF abortará a importação do mesmo e emitirá ao usuário a seguinte mensagem de alerta: A emissão de cupom fiscal a partir da importação de um PDV é configurada por padrão para movimentar estoque e portanto o pedido selecionado não poderá ser importado, uma vez que ele já movimentou estoque de seus itens.
- Formas de pagamento: As formas de pagamento utilizadas no encerramento do cupom deverão ser compatíveis com as formas de pagamento do PDV importado. Para isto, quando um PDV for importado para o ECF, o sistema (ECF) deverá desabilitar todas as formas de pagamento e preencher automaticamente os valores de cada uma conforme as formas de pagamento utilizadas no PDV.
- Se o ECF estiver configurado para não importar serviço e um determinado PDV conter serviço(s), para esta importação em específico as regras acima deverão ser desconsideradas.
- Caso no PDV tenha sido utilizada a forma de pagamento financeira, ao preencher automaticamente as formas de pagamento no encerramento do cupom o sistema considerará o total financiado como dinheiro.
Os cupons dos PDV´s importados para o ECF serão enviados para o Resulth WEB, e neste ponto será gerado o movimento de estoque dos itens de cada cupom utilizando a operação VENDA NO ECF IMPORTANDO PDV conforme regra de negócio RN01.
Vendas diretas e DAV´s importados
Os cupons dos DAV´s importados e das vendas feitas diretamente no ECF serão enviados para o Resulth WEB, e neste ponto serão gerados os movimentos de estoque dos itens e também o financeiro de acordo com as formas de pagamento informadas em cada cupom utilizando a operação VENDA DIRETA NO ECF conforme regra de negócio RN01.
Antes de gerar o financeiro para os cupons sincronizados, o sistema deverá verificar nos parâmetros do PDV:
- Gerar movimento de caixa para as vendas? Se este parâmetro estiver marcado como Sim, com o subcaixa informado para centralizar vendas do PDV (logo à direita do parâmetro em questão) serão gerados movimentos de caixa para cada cupom com o subcaixa informado.
- Utiliza fechamento de caixa? Se este parâmetro estiver marcado como Sim, com o subcaixa do operador que emitiu os cupons serão gerados movimentos de caixa.
- Independente se Gerar movimento de caixa para as vendas? = Sim ou Utiliza fechamento de caixa? = Sim, ao gerar movimento de caixa será considerado:
- Se a opção Para todas as vendas estiver marcada como Sim, na conta caixa informada logo à sua direita será gerado o movimento de caixa com o valor total de cada cupom utilizando o subcaixa que centraliza as vendas do PDV ou o subcaixa do operador que emitiu os cupons.
- Caso uma ou mais formas de pagamento esteja(m) marcada(s) como Sim, na(s) conta(s) caixa informada(s) será(ão) gerado(s) movimento(s) de caixa com o(s) valor(es) da(s) respectiva(s) forma(s) de pagamento de cada cupom utilizando o subcaixa que centraliza as vendas do PDV ou o subcaixa do operador que emitiu os cupons. Se houver em um determinado cupom um forma de pagamento que está marcada nos parâmetros do PDV como Não e que não possui uma conta caixa informada, não será gerado movimento de caixa com o valor da mesma.
NFC-e
A sincronização entenderá que os procedimentos de NFC-e deverão ser realizados quando nos parâmetros da filial logada, para o número de um determinado PDV/ECF, estiverem marcados os parâmetros OPERAÇÃO DO PAF = NFC-e e AMBIENTE NFC-e = Produção.
Uma vez que o sistema identificou que ao invés de cupom fiscal será sincronizada a NFC-e, o procedimento será o seguinte:
- Quando o ECF consumir o webservice de sincronização ao invés de popular o objeto DadosCupomDelphi com os dados do cupom a partir das tabelas VENDPDV e ENCERRA, ele deverá popular o objeto DadosNFCeDelphi com os dados do pedido da NFC-e (tabelas PEDIDOC e PEDIDOI), com os dados fiscais da mesma (tabelas NFSAIDI e NFSAIDC) e também com os dados eletrônicos complementares (tabela COMPLNFCE).
- Com o objeto DadosNFCeDelphi populado, será utilizada a classe MontaCupomFiscalImportacaoServiceImpl para preparar um objeto do tipo CupomFiscal e persisti-lo no banco de dados gravando no Resulth WEB o pedido da NFC-e exatamente na mesma estrutura onde é gravado o cupom fiscal.
- O pedido da NFC-e deverá ser gravado no Resulth WEB com o mesmo código gerado pelo Delphi na tabela PEDIDOC.
- Para NFC-e no atributo tipoCupom da classe CupomFiscal deverá ser informada a opção NFC-E. Este atributo foi criado para diferenciar o pedido da NFC-e do pedido do Cupom Fiscal e deverá ser criado com o valor padrão CUPOM_FISCAL para registros já existentes no banco de dados dos clientes.
- Em seguida deverá ser gerado um documento fiscal de saída para o pedido da NFC-e que fora gravado. Para isto poderá ser utilizada a classe PedidoNotaServiceImpl.
- Para preencher o documento fiscal o Resulth WEB não calculará nenhum imposto. Estes serão preenchidos a partir do XML da NFC-e que será sincronizado também. Para isto pode ser reaproveitado um recurso existente na importação de XML da nota de entrada, que preenche um objeto a partir de um arquivo XML que tenha a mesma estrutura da NF-e.
RN03 - Integração com controle de caixa/checkouts
Para vendas serem consideradas pelo controle de caixa, independente de sua origem, deverão ser observados:
- Caso de uso UC00066 - Abertura de caixa.
- Caso de uso UC00067 - Controle de caixa.
- Regra de negócio RN03 do caso de uso UC00064 - Parâmetros do PDV.
- Caso de uso UC00072 - Ponto de venda.
Importação de PDV e OS para o ECF
Pedidos do tipo 55 e 65 importados para o ECF serão considerados pela rotina de controle de caixa descartando a existência do cupom fiscal uma vez que a geração do financeiro só pode ser realizada pelo PDV. Em outras palavras, OS´s e PDV´s serão considerados pelo controle de caixa normalmente (se o PDV for configurado para tal) independente deles terem sido importados para o ECF ou não.
Se o PDV gera financeiro, movimento no subcaixa do operador que possui caixa aberto será gerado pelo Resulth WEB.
Importação de DAV e venda direta no ECF
Partindo do pré-suposto que o DAV não movimenta estoque nem gera financeiro, após importado para o ECF o mesmo será tratado como uma venda direta ao sincronizar seu cupom com o Resulth WEB. Para vendas diretas no ECF o movimento de estoque e a geração do financeiro serão realizados quando os respectivos cupons forem sincronizados com o Resulth WEB.
Antes de cada venda direta ou a importação de um DAV, o sistema (ECF) deverá:
- Verificar se o retaguarda (Resulth WEB) utiliza fechamento de caixa: Na aba Faturamento dos parâmetros do PDV deverá ser verificado o estado do parâmetro Utiliza fechamento de caixa?. Se o parâmetro em questão estiver como Não, os demais passos deverão ser ignorados e a venda direta ou importação do DAV procederá normalmente. Se o parâmetro estiver como Sim, executar os próximos passos.
- Verificar se o caixa do operador foi/está aberto: Para que um determinado operador consiga vender ou importar DAV no ECF é necessário que seu caixa esteja aberto no retaguarda (Resulth WEB). Caso o caixa do operador não esteja aberto o sistema (ECF) deverá abortar a venda ou importação do DAV e emitir ao usuário uma mensagem de alerta com a não conformidade.
- Caso não exista no retaguarda caixa aberto para o usuário/operador logado no ECF, exibir a mensagem: O sistema de retaguarda (Resulth WEB) está configurado para utilizar fechamento de caixa e não ha caixa aberto para o operador logado. Faça a abertura do caixa do operador em questão e tente novamente.
- Caso o caixa do usuário/operador já tenha sido fechado, exibir a mensagem: O caixa do operador logado já foi fechado e portanto o mesmo não poderá realizar vendas.
RN04 - NFC-e
Em resumo a NFC-e será tratada/sincronizada como um cupom fiscal no Resulth WEB, ou seja, os dados de um pedido de NFC-e serão visualizados e considerados da mesma maneira que um pedido de cupom fiscal. O que irá diferenciar um pedido de cupom fiscal de um pedido de NFC-e no Resulth WEB será a existência de um documento fiscal (a NFC-e propriamente dita), que será criado para todas as NFC-e´s sincronizadas para o Resulth WEB e considerado também em rotinas fiscais como SPED e livros de saída.
No Resulth WEB o documento fiscal da NFC-e será contabilizado somente em rotinas/relatórios fiscais, ou seja, não será possível visualizar ou manipular a NFC-e
em qualquer outra rotina do sistema. Para isto o usuário deverá utilizar os recursos do módulo ECF.
Todas as regras e validações já existentes para cupom fiscal deverão ser mantidas para NFC-e, seja na venda direta ou na importação de pedido.
Visualização/Impressão do CUPOM/DANFE
Conforme citado acima, quaisquer operações pertinentes a NFC-e deverão ser realizadas no módulo ECF, inclusive a visualização ou impressão da DANFE. Em função disso nas rotinas do Resulth WEB onde hoje é gerado um preview do cupom fiscal, para NFC-e o procedimento será o seguinte:
- Na emissão de NFC-e, o módulo ECF deverá gravar em seu banco de dados o link para consulta da DANFE da NFC-e já com o respectivo HASH do QRCode. Note que o link de consulta da DANFE poderá variar de acordo com a UF onde a NFC-e foi emitida.
- Quando a NFC-e for sincronizada para o Resulth WEB, o webservice deverá transportar o link de acesso à DANFE para o atributo linkAcessoDANFE da classe DadosNFCeDelphi.
- Ao gravar o pedido da NFC-e no banco de dados do Resulth WEB o link de acesso à DANFE da NFC-e deverá ser gravado no atributo linkAcessoDanfeNFCe da classe CupomFiscal.
- Nas consultas do Resulth WEB onde hoje é exibido o preview do cupom, para NFC-e, quando usuário clicar no ícone será aberta uma nova aba no navegador com o link de consulta da DANFE.
Validações e regras de sincronização
- Somente serão sincronizadas para o Resulth WEB NFC-e´s cujo status junto a SEFAZ é Autorizada ou Cancelada.
- A sincronização de NFC-e´s de status Cancelada deverá excluir completamente tanto o pedido quanto o documento fiscal de saída gerados no Resulth WEB desfazendo as respectivas movimentações financeiras e de estoque.
- Caso nos parâmetros da filial logada o ECF esteja configurado como IMPORTA SERVIÇO = Sim e OPERAÇÃO DO PAF = NFC-e, para pedidos realizados no Resulth WEB que contenham produtos e serviços importados para o ECF, serão considerados somente produtos.
DadosNFCeDelphi
| Atributo da classe DadosNFCeDelphi | TABELA BD ECF | CAMPO | OBSERVAÇÃO |
| chaveAcesso | COMPLNFCE | CHAVEACESSO | |
| dadoAdicionalNF | NFSAIDC | DADOSADIC | |
| dataEmissao | NFSAIDC | DT_EMISSAO | |
| dataSaida | NFSAIDC | DATASAIDA | |
| horaSaida | NFSAIDC | HORASAIDA | |
| motivoCancelamento | COMPLNFCE | MOTIVOCANC | |
| numeroNFCe | COMPLNFCE | NUMNFCE | |
| numeroPedidoNFCe | PEDIDOC | CODPEDIDO | |
| serie | COMPLNFCE | SERIE | |
| status | COMPLNFCE | STATUS | |
| tipoAmbiente | COMPLNFCE | TIPOAMBIENTE | |
| valorNF | NFSAIDC | TOTALNF | |
| xmlNFCe | -- | -- | Utilizar informação que vem no webservice. |
Equivalência dos dados de documento fiscal
Cabeçalho da NFC-e
| Atributo da classe DocumentoSaida extends DocumentoFiscal | TABELA BD ECF | CAMPO | OBSERVAÇÃO |
| filial | NFSAIDC | CODEMPRESA | Código da filial do ECF correspondente a uma filial do Resulth WEB |
| pessoa | NFSAIDC | CODCLIENTE | |
| numero | NFSAIDC | NUMNF | |
| dataEmissao | NFSAIDC | DT_EMISSAO | |
| serie | COMPLNFCE | SERIE | |
| modeloNotaFiscal | -- | -- | Utilizar modelo 65, ou seja, NFC-e - Nota Fiscal Eletrônica ao Consumidor Final |
| especieNotaFiscal | -- | -- | Utilizar o modelo NFC-e, //Nota Fiscal Eletrônica ao Consumidor Final |
| observacaoLivrosFiscais | NFSAIDC | OBSLIVROFISCAL | |
| pagamento | -- | -- | Será gerado se no encerramento da NFC-e foi gerado contas a receber ou parcelas avulsas. |
| valorNF | NFSAIDC | TOTALNF | |
| observacao | NFSAIDC | OBSERVACAO | |
| numDocOrig | -- | -- | Armazena os documentos a receber gerados caso existam. |
| transportador | NFSAIDC | CODTRANSPT | |
| notaFiscalEletronica | -- | -- | |
| portalFiscalPrefeitura | -- | -- | |
| pagamentosRetencoes | -- | -- | |
| operacao | -- | -- | |
| itens | NFSAIDI | -- | Ver tabela Itens da NFC-e. |
| dataSaida | NFSAIDC | DATASAIDA | |
| horaSaida | NFSAIDC | HORASAIDA | |
| cancelada | NFSAIDC | CANCELADO | |
| notaManual | -- | -- | |
| dadoAdicionalNF | NFSAIDC | DADOSADIC | |
| pedidos | -- | -- | Utilizar o CupomFiscal -> DoctoPedidoDevolucao gerado na sincronização do pedido NFC-e para o Resulth WEB. |
| encerramento | -- | -- | Não gerar. O encerramento ficará na CupomFiscal -> DoctoPedidoDevolucao. |
| notasRetencaoPisCofinsCsll | -- | -- | |
| pisCofinsCsllRetidoFonte | -- | -- | |
| idNotaAdevolver | -- | -- |
Itens da NFC-e
| Atributo da classe ItemNota | TABELA BD ECF/Tag XML NFCe | CAMPO | OBSERVAÇÃO |
| nota | -- | -- | Utilizar objeto gerado para o cabeçalho da NFC-e. |
| item | NFSAIDI | CODPROD | |
| grade | NFSAIDI | CODGRADE | Irrelevante, pois o webservice de sincronização irá devolver o ID do RrelacionamentoGrade. |
| sequencia | -- | -- | Gerado automaticamente para notas digitadas. |
| cfop | <prod> | CFOP | |
| quantidade | <prod> | qCom | |
| quantidadeConvertida | -- | -- | |
| unidade | <prod> | uCom | |
| preco | <prod> | vUnCom | |
| precoConvertido | -- | -- | |
| iss | <ISSQN> |
|
Inicialmente, a NFC-e (no ECF) não irá conter serviços. |
| ipi | <IPI> |
|
|
| icm | <ICMSXX> |
|
Lembrando que o XX ao fim do nome da Tag do XML refere-se aos dois últimos dígitos do CST correspondente. Exemplo: <ICMS10> está para CST´s terminados em 10; <ICMS20> está para CST´s terminados em 20. |
| st | <ICMSXX> |
|
Lembrando que o XX ao fim do nome da Tag do XML refere-se aos dois últimos dígitos do CST correspondente. Exemplo: <ICMS10> está para CST´s terminados em 10; <ICMS20> está para CST´s terminados em 20. |
| stForaNF | -- | -- | |
| pis | <PIS> |
|
|
| cofins | <COFINS> |
|
|
| aproveitamentoCredito | -- | -- | |
| descontoItem | <prod> | vDesc | |
| totalItem | NFSAIDI | QUANTIDADE * PRECOUNIT | |
| totalRateado | NFSAIDI | TOTALRATEADO | |
| cst | NFSAIDI | CODTRIBUT | |
| csosn | <ICMSSNXXX> |
|
Lembrando que o XXX ao fim do nome da Tag do XML refere-se aos três últimos dígitos do CSOSN correspondente. Exemplo: <ICMSSN101> está para CSOSN´s terminados em 101; <ICMSSN102> está para CSOSN´s terminados em 102. |
| rateio | -- | -- | |
| seriaisDigitados | CONTSER | ||
| lotesDigitados | -- | -- | |
| itensNotaEntradaSerial | -- | -- | |
| itensNotaEntradaLote | -- | -- | |
| complemento | -- | -- | |
| original | -- | -- | |
| itemBonificado | -- | -- |
Dados eletrônicos da NFC-e
| Atributo da classe NotaFiscalEletronica | TABELA BD ECF | CAMPO | OBSERVAÇÃO |
| tipoNotaEletronica | -- | -- | Utilizar a opção NFC-e. |
| ambiente | -- | -- | Uma vez que serão sincronizadas somente NFC-e´s emitidas em ambiente de produção, utilizar a opção PRODUÇÃO. |
| chaveAcesso | COMPLNFCE | CHAVEACESSO | Alterar o tamanho deste campo no banco do Resulth WEB de 44 para 50. |
| codigoStatus | COMPLNFCE | STATUSPROC | Se neste campo estiver vazio ou nulo, utilizar a informação do campo STATUS da mesma tabela. |
| status | -- | -- | A descrição referente ao stauts informado no campo codigoStatus deverá ser passada para o webservice de sincronização em tempo de execução, uma vez que estas informações não ficam salvas no banco de dados, mas dentro do próprio código fonte do Delphi na unit GerarXMLNFe. Atenção para qual status será preenchido, levando em consideração que temos Status da ComplNFe e CÓDIGO RESULTADO DO PROCESSAMENTO DA SOLICITACAO (retorno SEFAZ) |
| recibo | COMPLNFCE | RECEBIMENTOXML | |
| dataHoraRecibo | COMPLNFCE | DATAHORAPROTOCOLO | |
| motivoCancelamento | COMPLNFCE | MOTIVOCANC | |
| statusInterno | -- | -- | |
| enviouCartaCorrecao | -- | -- | Utilizar padrão false. |
| imprimiuDanfe | COMPLNFCE | IMPDANFE | S = true; N = false. |
| enviouEmail | -- | -- | |
| falhaComunicacao | -- | -- | |
| statusDisponibilizacao | -- | -- | |
| nfse | -- | -- | |
| xmlNFCe | -- | -- | Popular este objeto a partir das informações do atributo xmlNFCe da classe DadosNFCeDelphi. |
| xmlNFe | -- | -- | |
| xmlNFSe | -- | -- | |
| cartaCorrecao | -- | -- |