Análise

Análise

Projeto 1522

Data da Análise: 21/07/2015

Análise

Projeto 2284

Data da Análise: 21/07/2015

Ao detalhar o projeto 2284 foi verificado que seria mais interessante fazer o processo na web utilizando a estrutura do produto novo (Checkout4g).
Devido ao fato dessa estrutura não estar pronta, foi necessário criar um novo nó no projeto 1522 para implementá-la.
Esse artigo de análise descreve de maneira geral (incluindo os dois projetos) o que será feito para atender às necessidades do cliente.

Projeto

Proposta

Atualmente o sistema quando devolve uma nota de fatura (5922) que possui uma remessa vinculada (5117) emite as duas notas de devolução forma automática.
Porém com o regime especial que a Carneiro conseguiu agora podemos ter uma fatura de um CNPJ e a remessa de outro CNPJ.
Fiscalmente não é permitido que se devolva a nota de uma filial em outra. Assim o sistema não poderá emitir as duas notas com o mesmo CNPJ.

Como o Checkout não é preparado para imprimir notas que não sejam da filial que foi configurado, a opção seria devolver a Simples Fatura em um Checkout da filial Matriz e a simples remessa em outro Checkout configurado para o CD.

Para automatizar este processo estaremos alterando o Checkout para que o mesmo possa gerar a devolução de remessa do CD juntamente com a devolução da fatura da matriz como é feito hoje. Sendo que cada nota sairá com com seu CNPJ respectivo.
Será necessário que esta devolução seja feita na filial que gerou a fatura já que o pagamento e a parte financeira foi feita na mesma.

Para a devolução da remessa o Checkout irá utilizar o certificado A1 da outra filial bem como a numeração de nota deverá seguir a sequencia da outra filial.

Para otimizar isto então termos vários Checkout Nfs instalador em cada filial para fazer a devolução das notas das outras filiais.
Deverá ser criada para isto uma configuração que indique em qual filial o Chekout efetivamente está instalado. E deverá ser criada uma transferência automática semelhante à feita quanto se faz orçamentos reservados em outra filial para ajustar o estoque de acordo com o que foi feito efetivamente.

Segue exemplo:

Vamos supor que o cliente chegue na loja 002 com notas 5117 emitidas parcialmente no CNPJ da 001 e o restante no CNPJ da 002.

Como foi fixado que a operação deve ser feita no Checkout do faturamento, então teremos que usar o Checkout da 001 tanto na própria loja 001, como na loja 002.

Precisamos que de alguma forma o sistema leia onde está sendo realizada a operação, ou seja, que o Checkout da Matriz está sendo usado na loja 002, sendo assim o físico está todo lá, e com isso transfira automaticamente os produtos que foram ?devolvidos? no procedimento da 001 para a loja 002. (De onde deu entrada no estoque com a devolução, (001) para onde está o físico de verdade(002).

A mesma coisa deve acontecer se a pessoa viesse na matriz, os produtos que a devolução deu entrada no CD deveriam ser transferidos automaticamente para onde fez a operação e está o físico, ou seja, de 002 para a 001.

Deverá ser tratado também a rotina de cancelamento para aceitar cancelar as notas que foram emitidas no Checkout e que forem de outro CNPJ.

Detalhamento

Criaremos uma nova tela no Commerce Web para efetuar devoluções de qualquer filial. Com isso, não serão necessárias as instalações extras de Checkouts em cada máquina.

Bastará ao usuário acessar via navegador o Commerce Web, e proceder com a devolução. A filial logada no Commerce Web definirá onde o usuário se encontra fisicamente.

As notas de devolução serão emitidas com dados das filiais de suas respectivas notas de origem. Inclusive, utilizando o certificado A1 de cada filial.

O Commerce Web precisará ter acesso ao NUMNOT.dbf de todas as lojas para efetuar a operação. Caso o acesso esteja comprometido, o sistema apresentará mensagem indicando a ocorrência.

Tela permitirá devolução de notas ou cupons fiscais, mas sempre gerando NF-e em série previamente configurada.

A autenticação no SEFAZ dessas notas será feita pelo EmiteNF-e, por isso, Commerce Web precisará também ter acesso aos diretórios de integração de NF-e para poder gerar os arquivos .ERP da operação.

A parte de impressão de DANFE e envio de email também ficará por conta do EmiteNF-e como é hoje.

E por fim, se o local do usuário for diferente da filial da remessa, sistema contabilizará o item no processo de transferência automática.

Por exemplo, se a venda e entrega eram da filial 001 e logamos na 002, a nota sai com CNPJ 001, devolve estoque na 001 e transfere automaticamente para 002.

Essas notas poderão ser canceladas normalmente no Backoffice. E sistema gerará transferência automática reversa em caso de cancelamento da devolução feita pela nova tela que tenha sido recebida em filial diferente.

Como o Commerce Web não possui conceito de caixa, todas as devoluções que tiverem valores a serem devolvidos para o cliente gerarão crédito em C/C. Depois da devolução, cliente deverá se dirigir ao caixa caso se queira fazer a devolução do dinheiro.

O diagrama abaixo dá uma visão geral da integração entre os módulos do sistema e demais componentes da solução de NF-e.

Nota: Diagrama extraído de totalianalise\Analise\Totali\Projetos\1522 - Checkout 4G\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\Devolucao-middleware.eap

Tela de Devolução do Commerce Web

Tela terá permissão especial para acesso.

Para evitar erros operacionais, tela solicitará autorização especial quando a nota a ser devolvida for de outra filial.

O usuário poderá informar Filial, ECF, Série e Número da nota e prosseguir com a devolução.

Caso ele não saiba a nota, ele poderá fazer pesquisa de notas do cliente.

Pesquisa de Notas do Parceiro

Semelhante à tela do Checkout, usuário poderá informar o código do cliente, ou fazer uma pesquisa de cliente.

Após definir o cliente, sistema apresentará a lista das notas que podem ser devolvidas.

Ao escolher a nota, sistema voltará para a tela de devolução com a nota definida.

Requisitos

Checkout

Nada será feito nele.

Commerce Web

Requisitos Funcionais:

• Terá tela de devolução de NF-e.
• Deverá permitir consulta de notas por cliente.
• Deverá permitir consulta de notas pela identificação da nota.
• Deverá passar filial logada para o serviço.
• Sistema deverá habilitar tela de devolução mediante permissão do usuário.
• Sistema deverá levar em consideração configuração para permitir devolução de nota de outra filial.
• Sistema deverá solicitar autorização para devolver uma nota de outra filial.

Requisitos Não-Funcionais:

• Por ser web poderá ser usada em qualquer caixa de qualquer filial.
• Dependerá que o Middleware Matriz consiga conexão com o arquivo numnot.dbf da filial de origem da nota devolvida.

Regras de Negócios:

• Filial logada local onde a mercadoria está sendo entregue.
• Essa tela de devolução será para devolução integral de fatura.

Middleware

Requisitos Funcionais:

• Deverá permitir configurações para várias filiais (lista de filiais).
• Deverá ter configuração de NF-e (aproveitando as configurações de NFC-e).
• Terá serviço para fornecer lista de notas fiscais emitidas por cliente.
• Terá serviço para fornecer dados de uma nota fiscal emitida pela chave.
• Terá serviço para devolver uma nota fiscal emitida.
• Deverá efetuar a devolução das remessas vinculadas a fatura, caso houver.
• Deverá pegar numeração de NF-e no arquivo numnot.dbf de cada filial.
• Deverá sequencia de números de NF-e de acordo com a quantidade de notas emitidas para aquela filial.
• Deverá gerar arquivo .ERP com o layout do governo para cada nota emitida.
• Deverá gerar arquivo de inutilização para as numerações obtidas que não forem utilizadas.
• Serviço deve gerar crédito na C/C do cliente ao devolver a fatura.

Regras de Negócio:

• Gerar uma devolução de remessa para cada nota de remessa vinculada.
• Filial de origem das devoluções de remessas deverá ser a mesma da nota de remessa.
• Deverá gravar a filial onde foi devolvida a mercadoria nas devoluções de remessa.
• Número de notas deve ser sequencial para cada filial.

Backoffice

• Sistema terá uma permissão nova para permitir acesso a tela de devoluções de NF-e do Commerce Web.
• Sistema terá uma permissão nova para devolver notas de outras filiais.

Config

• Sistema terá uma configuração para devolver notas de outras filiais.
• Sistema terá uma configuração por filial para definir a série da devolução.

Banco de Dados

• Sistema terá uma coluna no item da venda para armazenar a filial em que foi feita recebida a devolução.
• Sistema registrará no processo de transferência automática a movimentação da filial de origem para a filial em que foi recebido o item da devolução.
• Sistema registrará transferência automática reversa em caso de cancelamento da devolução feita pela nova tela.

Filial Onde Devolução foi Recebida

Será criada coluna para guardar filial onde a devolução foi recebida.

Especificação Técnica

Criar coluna na TT_IVE.
Filial em que foi feita a devolução.
FILDEV CHAR(3).
FK com PK da TD_FIL.

Especificação para tarefa(s): 97424

Configuração para Permitir Devolução de Nota de Outra Filial

Será criada configuração para permitir devolução de nota de outra filial. O único módulo que poderá devolver notas de outras filiais por enquanto é o Commerce Web.

Especificação Técnica

Na TT_CFG, criar coluna:
DEVFIL VARCHAR(1) Default "T" | Devolve nota fiscal apenas na mesma filial?
Criar CK permitindo "T" ou "F".

Criar interface no Config em:

Ambiente >>> N.F. Emitidas >>> Diversos

Devolver notas de outras filiais.

Especificação para tarefa(s): 97425 97426

Configuração de Série Padrão de Devolução por Filial

Será criada configuração na tabela de filiais para definir qual será a série padrão para devolução.
Por enquanto, essa série somente será utilizada no Commerce Web nas devoluções.

Especificação Técnica

Na TD_FIL, criar coluna:
SERDEV CHAR(2) | Série Padrão para Devolução
Criar FK relacionando coluna com PK da TD_SER.

Criar interface no Config em:

Outros >>> Filiais, na guia Identificação, junto ao campo Série Padrão.

Série Padrão para Devolução.

Especificação para tarefa(s): 97615 97616

Permissão para Tela de Devolução no Commerce Web

Sistema terá uma permissão nova para permitir acesso a tela de devoluções de NF-e do Commerce Web.

Especificação Técnica

Criar permissão 407-Acessar Tela de Devoluções de NF-e no Commerce Web.

Especificação para tarefa(s): 97427

Permissão para Devolver Notas de Outras Filiais

Sistema terá uma permissão nova para devolver notas de outras filiais.

Especificação Técnica

Criar permissão 408-Devolver Notas Emitidas em Outras Filiais.

Especificação para tarefa(s): 97428

Configurações de NF-e por CNPJ no Middleware

O configurador do Middleware possui uma guia onde o usuário pode configurar emissão de NFC-e. Essa guia precisa ser trabalhada para permitir configurações gerais de NF-e. E também precisa permitir configuração para mais de uma filial, já que o sistema emitirá as devoluções usando as configurações da filial da nota.

Especificação Técnica

1. Guia "Configurações NFCe" deve se transformar em "Configurações NFe".

2. Nessa guia deve ter uma tela com um grid para permitir configurações por CNPJ.
No grid deverá ter apenas alguns dados readonly básicos que devem ser melhorados no futuro. Por enquanto poderá ter apenas CNPJ e se a configuração está ativa.
Ao dar um duplo clique na linha (poderia ter um botão Editar também) sistema deverá abrir um novo form parecido com que é hoje a guia "Configurações NFCe".

3. Criar novo form de configurações com as mesmas opções da guia "Configurações NFCe", exceto por:

• Deve ter um campo principal em destaque na parte superior (acima das guias) para definir o CNPJ.
• Na guia "Geral", remover GroupBox "Forma de Emissão".
• Também com destaque (na parte superior) deve ter um checkbox para indicar se a configuração está "Ativada".

4. Com essa modificação, os serviços do Middleware precisarão de uma reestruturação para mandar o CNPJ quando for o caso.

Em TServicoNFeREST, os métodos getToken, getTokenID e getSenhaCertificado precisarão do CNPJ como parâmetro.

5. Esse item não precisará de alteração no Middleware. Serve apenas para deixar documentado.
Checkout4g faz o download do certificado como se fosse um arquivo de recursos (imagem, css, etc.) da página do Middleware.
Ele faz isso acessando a pasta certificado onde o executável do Middleware está rodando.
Devemos passar a usar o CNPJ como nome do arquivo, permitindo assim, vários arquivos naquela pasta.

Especificação para tarefa(s): 97429

Serviço Consulta de Devoluções do Parceiro

Será criado um serviço no Middleware para fornecer as devoluções de um parceiro.
O serviço retornará apenas as notas dos documentos, ou seja, não trará os itens e seus vínculos.

Como será o primeiro serviço de NF-e necessitará de uma pequena reestruturação nos objetos de NFC-e.

Especificação Técnica

Criar um serviço no Middleware que receba uma chamada REST com chave primária do parceiro no formato JSON e retorne uma lista de objetos das devoluções que podem ser devolvidas desse parceiro.

Requisição:

• Filial logada (CODFIL)
• ECF (NUMECF)
• Usuário logado (FILUSU e CODUSU)
• Parceiro (FILCLI e CODCLI)
• Somente eletrônicas? (Parâmetro indicando True ou False)

Resposta:

• Representação em JSON de uma lista baseada na classe TDocEmitido.

Os objetos referentes a devolução das notas devem conter apenas os dados principais, não necessitando dos itens e vínculos.
A consulta que esse serviço deve fazer para retornar as devoluções, deve ser parecida com o select do Checkout atual.

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\select-checkout-notas-cliente.txt

Tratar parâmetro Somente eletrônicas filtrando NF-es pelo modelo (55).

A partir das classes relacionadas no diagrama abaixo, reestruturar para usar uma classe única para documentos eletrônicos chamada TDocEmitidoEletronico.

Em alguns casos onde utilizamos TNFCe devemos utilizar TNFe. São os casos em que o documento manipulado é eletrônico e precisa interagir com o SEFAZ.
Para algumas classes onde no futuro podemos manipular uma nota qualquer, devemos utilizar TDocEmitido para sermos mais genéricos.
Modelo deve ser um atributo de TDocEmitido.

Especificação para tarefa(s): 97431

Serviço Consulta Nota de Devolução

Também será criado um serviço para consultar a nota de devolução pelo seus campos de identificação (filial, ECF, série e número).

Especificação Técnica

1. Criar um serviço no Middleware que receba uma chamada REST no formato JSON com a chave alternativa da nota e responda se a fatura e existe, e devolva um objeto com os dados da fatura para permitir consulta.

Requisição:

• Filial logada (CODFIL)
• ECF (NUMECF)
• Usuário logado (FILUSU e CODUSU)
• Nota (CODFIL, NUMECF, CODSER e NUMNOT)
• Somente eletrônicas? (Parâmetro indicando True ou False)

Resposta:

• Representação em JSON de uma classe TDocEmitido -> TDocEmitidoItem.

Não é necessário carregar os vínculos dos itens.
Fazer select semelhante ao serviço de devoluções por parceiro.
Tratar parâmetro Somente eletrônicas filtrando NF-es pelo modelo (55).

A consulta que esse serviço deve fazer para retornar as devoluções, deve ser parecida com o select do Checkout atual.

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\select-checkout-devolver-nota.txt

Especificação para tarefa(s): 97432

Serviço Processa Devolução

E finalmente, será necessário criar um serviço para devolver efetivamente a nota. Esse serviço só poderá devolver NF-e, bem como, a devolução será sempre integral.
Para emissão, gravaremos a nota no banco e depois faremos a emissão baseando-se dos dados gravados no banco.

Especificação Técnica

1. Criar um serviço no Middleware que receba uma chamada REST no formato JSON com a chave primária da nota e gere a NF-e de devolução.
Caso se trate de uma fatura, deve devolver primeiro (de forma automática) suas respectivas remessas.

Requisição:

• Filial logada (CODFIL)
• ECF (NUMECF)
• Usuário logado (FILUSU e CODUSU)
• Nota (CODFIL e SEQUEN)

Retorno:

• Status da gravação no banco.
• Mensagem de retorno da gravação no banco.
• Status da autenticação no SEFAZ.
• Mensagem de retorno da autenticação no SEFAZ.
• Status da gravação no banco do retorno do SEFAZ.
• Mensagem de retorno da gravação no banco do retorno do SEFAZ.

Implementar serviço conforme diagrama abaixo.

Nota: Diagrama extraído de totalianalise\Analise\Totali\Projetos\1522 - Checkout 4G\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\Devolucao-middleware.eap

O serviço deve verificar se a nota pode ser devolvida. Pode fazer isso, consultando novamente o serviço de notas devolvidas. E verificando também se ele é uma nota modelo 55.

Deve-se criar uma configuração de para informar endereço absoluto do numnot.dbf nas configurações da nota, por filial. Se numnot.dbf não estiver acessível deve abortar a operação.

Ele deve devolver primeiro as notas vinculadas, e depois a nota que foi efetivamente acionada para a devolução. Entretanto, ele deve fazer tudo isso em apenas uma transação de banco.

Usar a Série Padrão para Devolução nas novas notas.

Sistema deve gravar a filial logada na coluna FILDEV da TT_IVE.

A gravação da nota de devolução deve ser baseada na rotina do Checkout. Deve-se tratar todas as tabelas e campos baseando-se nos scripts abaixo, e tratar para que os valores da nota de origem sejam replicados na nota de destino, levando em consideração regras que podem modificar CFOP, CST, sinal do valor, etc.

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\script-checkout-devolucao-simples.txt

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\script-checkout-devolucao-com-remessas.txt

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\script-checkout-devolucao-em-cc.txt

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\regras-cfop-fonte-checkout.txt

\\ttadm\Anexos_PRJ\Totali\Checkout4g\Devolução de Fatura e Remessa pelo Middleware e Commerce Web\regras-devolucao-outras-fonte-checkout.txt

Serviço deverá gravar arquivo para EmiteNfe no formato do governo.

O processo de inutilização das notas deverá ser executado de tempos em tempos na mesma rotina que já tenta reenviar as NFC-es em contingência.
Nesse processo deverá pegar os NUMNOTs gerados no dia anterior que não possuem respectivas vendas na tabela da Guarda.

Especificação para tarefa(s): 97433

Tela de Devolução de NF-e no Commerce Web

Commerce Web terá uma tela para fazer devoluções de NF-e. Ela permitirá consulta pela chave da nota (filial, ECF, série e número) ou consulta das notas de um parceiro.
Seu acesso será controlado por permissão [407].
Ela permitirá devolução de notas de outras filiais mediante configuração da base, e autorização de usuário com permissão específica [408].

Especificação Técnica

1. Criar nova tela no Commerce Web para permitir devolver uma NF-e.

Sistema deve permitir consulta de uma nota informando os campos:

• Filial
• ECF
• Série
• Número

Utilizar o serviço de consulta nota de devolução pela chave do Middleware.

A tela deve ter um botão para fazer pesquisa de devoluções de um parceiro.

2. Criar Tela Consulta de Notas do Parceiro.

Essa tela deve solicitar cliente (obrigatoriamente)

• Filial
• Código

Utilizar o serviço de consulta notas de devolução do parceiro do Middleware.

3. Chamar serviço para realizar a devolução.

Depois que o usuário escolher a nota ele deve solicitar que seja devolvida.

Utilizar o serviço de devolução de notas do Middleware.
Tela deve apresentar o resultado do que aconteceu (autenticado no SEFAZ, gravado no banco, etc.).

• 

  Consulta de Parceiros

• 

  Consulta Nota

• 

  Devolução

Especificação para tarefa(s): 97437

Transferência Automática ao Devolver Itens de Outra Filial

Sistema registrará no processo de transferência automática a movimentação da filial de origem para a filial em que foi recebido o item da devolução.
Sistema registrará transferência automática reversa em caso de cancelamento da devolução feita pela nova tela.

Especificação Técnica

Ao gravar uma devolução de remessa [TT_IVE.LANEST = "C" / QTDMOV < 0], caso FILDEV esteja preenchido, sistema deve gerar uma transferência automática da filial que registrou a devolução [TT_IVE.CODFIL] para filial onde está a mercadoria [TT_IVE.FILDEV].

Ao cancelar o item ele deve fazer a transferência inversa.

Especificação para tarefa(s): 97440

Categorias