Análise

Projeto

Proposta

Integrar Checkout4g com dispositivo SAT para permitir emissão de CF-e em todo o estado de SP.

Visão Geral do SAT

CF-e-SAT significa Cupom Fiscal Eletrônico do Sistema Autenticador e Transmissor.

O SAT é um dispositivo capaz de validar, armazenar e enviar CF-e para o SEFAZ de SP.
O sistema que interage com ele não precisa ser homologado no PAF-ECF.

SEFAZ prevê que sistema deverá utilizar a NFC-e como contingência para o SAT.
Mas somente no caso do aparelho estar incapacitado de processar as vendas.
Porém, algumas empresas estão fazendo o contrário, utilizando o SAT como contingência para o NFC-e.

O SAT pode armazenar as vendas por até 10 dias. Após esse período, se ele não conseguir conexão com o SEFAZ, ele automaticamente se bloqueia.

É possível ligar vários aparelhos de SAT em um único PC.
Cada aparelho se comunica através de uma porta COM virtual criada via interface USB.
Para que mais de um PDV possa utilizá-lo, é necessário desenvolver uma camada de software para lidar com as requisições.
Essa camada também precisa ser responsável por escolher para qual SAT mandar a requisição.

Como o ECF, ele também só permite cancelamento do último CF-e emitido, e dentro do prazo de 30 minutos.

Em cada requisição feita ao SAT, o AC (aplicativo comercial) gera um número de sessão aleatório de 6 dígitos.
Esse não pode ser repetido por 100 comunicações.

Sistema deve guardar cópia do XML das vendas e cancelamentos pelo prazo definido na regulamentação de ICMS.

Links Úteis

Regulamentação:

• Portaria CAT-147, de 05-11-2012

Site oficial:

• www.fazenda.sp.gov.br/sat

Vídeos:

• www.fazenda.sp.gov.br/educacao_fiscal/pages/Materiais_Didáticos/solucoes.shtm

Ato Cotepe/ICMS:

• http://www.fazenda.sp.gov.br/sat/legislacao/vigentes.asp#COTEPE

Tabela de Atos Cotepes existe no controle de versões do manual de orientação do SAT.

Manuais:

• http://www.fazenda.sp.gov.br/sat/downloads/vigentes.asp#Manuais

Manual de Orientação AC SAT SEFAZ:

• http://www.fazenda.sp.gov.br/sat/downloads/Manual_Orientacao_SAT_v_MO_2_12_12.pdf

Especificação Técnica de Requisitos:

• http://www.fazenda.sp.gov.br/sat/downloads/Arquivo/Especificacao_SAT_v_ER_2_4_20.pdf

Perguntas e respostas dos contribuintes:

• http://www.fazenda.sp.gov.br/sat/duvidas_frequentes/contribuintes.asp

Perguntas e respostas dos desenvolvedores:

• http://www.fazenda.sp.gov.br/sat/duvidas_frequentes/desenvolvedores.asp

Visão geral do processo:

• Quantos pontos de venda um equipamento SAT CFe suporta?

Uso de ECF na Emissão de Documentos Fiscais:

• www.pfe.fazenda.sp.gov.br/guia_procedimentos_ecf_06.shtm#6

Aplicativos Úteis

O SEFAZ-SP desenvolveu alguns softwares para auxiliar no desenvolvimentos das aplicações:

Aplicativo Comercial: simula o aplicativo comercial emissor das vendas.

Emulador SAT-CFe: emula um aparelho SAT. Ele é off-line, ou seja, não faz comunicação com o SEFAZ.

Ativação SAT-CFe: programa que interage com o emulador no intuito de efetuar os comandos mais burocráticos, como configurações, ativação, etc.

Cada fabricante de SAT também faz o mesmo. No caso da Tanca, que nos forneceu o SDK, temos as seguintes aplicações:

InteliSAT: demonstra os comandos e respostas do SAT feito por eles.

SAT Ativação: faz a configuração e ativação do SAT deles. Esse programa o cliente utilizará ao comprar o SAT da Tanca para fazer autenticação no SEFAZ.
Na opção "Associar Aplicativo Comercial" ele precisará do código Base64 gerado pela Totali com o CNPJ dele.

Gerador Código Vinculação TS-1000: programa permite que usuário informe CNPJ do cliente e da empresa, certificado A1 e gere assinatura Base64 para ativação do SAT.

Organização das Documentações do SAT

Os PDFs e demais anexos devem ser guardados em pasta específica do Anexos_PRJ.
Atualmente, já temos alguns documentos organizados da seguinte forma:

Documentos obtidos no site do SEFAZ:

\\ttadm\Anexos_PRJ\Totali\SAT\SEFAZ-SP

Documentos referentes ao SAT da Tanca:

\\ttadm\Anexos_PRJ\Totali\SAT\Tanca

Documentos referentes ao SAT da Sweda:

\\ttadm\Anexos_PRJ\Totali\SAT\Sweda

Documentos obtidos na Internet de fontes diversas:

\\ttadm\Anexos_PRJ\Totali\SAT\OutrosMateriais

Arquitetura

Para melhor entendimento de integração com o SAT, precisamos entender bem como funciona a arquitetura do Checkout 4G.

Na imagem abaixo temos como seria um cliente padrão.
Apenas exageramos um pouco no número de SATs da matriz, para demonstrar que o sistema suportará a utilização de mais SATs para melhor desempenho dos caixas.

Banco do Commerce: é o servidor (PC) onde está instalado o banco de dados principal do Totali Commerce. Nele está instalado o banco de dados do Totali Commerce, que é aquele que atualizamos com o Wizard e acessamos normalmente com o DBExp. Esse PC pode ser tanto Windows como Linux, e o banco pode ser Oracle ou PostgreSQL.

Totali Commerce: Módulos básicos (Backoffice, Order, Delivery, etc.). As máquinas de retaguarda que possuem sua instalação foram omitidas. Também pode ser instalado no servidor principal, caso ele seja WTS.

Servidor Principal: Em um outro servidor (que poderia ser uma máquina de frente de caixa em um cliente bem pequeno) teremos instalado o Middleware Matriz. E é na máquina onde está instalado o Middleware que os SATs precisam estar conectados.

Middleware Matriz: será um serviço de Windows único em todo o cliente. Ele se comunicará com todos os Checkout 4G fornecendo a carga e recebendo as transações. Além desse papel central, ele também pode fazer o papel de Middleware Filial.

Middleware Filial: É o mesmo serviço de Windows do Middleware Matriz, porém, sem acesso a base do Totali Commerce. Ele terá uma base local chamada Guarda para gravar operações, configurações, etc. É esse serviço que será responsável por autenticar CF-e-SAT, NFC-e e NF-e (quando esta for implementada).

Checkout 4G: O Checkout 4G nesse diagrama é o conjunto de Apache Tomcat, aplicação Checkout 4G, um PostgreSQL e o Middleware Local. Ele é tratado como um pacote porque seu instalador será responsável por todas essas aplicações.

Middleware Local: Será um serviço de Windows (como o Tomcat) e fornecerá via webservices acesso a recursos locais como impressora, ECF e XML de NFC-e assinada. Esse Middleware não terá acesso ao banco da Guarda e nem ao banco do Totali Commerce.

Configurador do Middleware: Programa Windows que permite visualizar e editar configurações do Middleware (Matriz ou Filial).

Banco (PostgreSQL) da Guarda: É um banco de dados local instalado junto com o Middleware (Matriz ou Filial). Ele armazena todos os XMLs de NF-e, NFC-e e CF-e, bem como o status de cada operação.

Detalhamento

Ativar SAT

Após o cadastro do contribuinte no portal do SAT, ele poderá utilizar a opção de ativação fornecida pelo software do fabricante para ativar o SAT para seu CNPJ.

Usuário deverá acionar o suporte da Totali para obter a assinatura dos CNPJs na Base64.
Suporte utilizará o aplicativo da Tanca para gerar essa assinatura que consiste na concatenação do CNPJ da Totali com o CNPJ do cliente, assinado com o certificado A1 da Totali.

Configuração de um SAT no Sistema

No Config, usuário deverá cadastrar uma nova série modelo 59 na tabela TD_SER.
As configurações de série poderão influenciar as observações fiscais emitidas no CF-e-SAT.

Depois, usuário deverá cadastrar o aparelho na nova tabela TD_SAT.
Nessa tabela o usuário deverá informar também a filial onde será utilizado o aparelho, e para qual série modelo 59 serão realizadas as vendas.

Ainda no Config, usuário deverá determinar na TD_FIL ou na TD_ECF qual modelo fiscal será adotado para Venda ao Consumidor e qual será adotado para Contingência de Venda ao Consumidor.
Ela poderá escolher entre as seguintes opções:

Opção A	Opção B	Opção C	Opção D
2D - Cupom Fiscal	65-NFC-e	59-CF-e-SAT 65-NFC-e	65-NFC-e 59-CF-e-SAT

E quando utilizar 65-NFC-e, poderá marcar se utiliza contingência off-line.

Usuário deverá espetar o aparelho na máquina onde possui Middleware Filial instalado.
Utilizando o Configurador do Middleware Filial, ele deverá definir as seguintes configurações:

• Número de Série
• Código de Ativação
• Assinatura dos CNPJs
• Localização da DLL
• Porta COM da DLL (para caso do Middleware precisar se comunicar com mais de um SAT)
• Método de acesso a DLL (Nenhum, SDTCLASS ou CLECL)
• Codificação (Usa UTF-8 Sim ou Não)
• Página de Codificação (para caso de usar UTF-8)

Com essas configurações realizadas, Checkout 4G precisará estar online para buscar dados da série e SAT na carga.

Será importante que o usuário configure todos os SATs que ele possui assim que possível, pois no caso de um Checkout 4G ficar offline, ele só poderá utilizar os SATs que ele possui a série.

As mesmas séries poderão ser utilizadas em filiais diferentes.
Com isso, o cliente não precisará cadastrar um número exagerado de séries no sistema.

Venda com SAT

Ao finalizar a venda, Checkout 4G passará XML da transação para o serviço de autenticação do Middleware Filial.
Nesse mesmo XML, Checkout 4G passará a lista dos SATs que ele conhece.
Isso é necessário porque o Middleware Filial não pode utilizar um SAT que o Checkout 4G não possua série.
Checkout 4G utilizará como numeração provisória para nota o ID da transação.

No Middleware Filial o XML da transação será convertido em XML do governo.
Os dois XMLs serão materializados no banco de dados da Guarda.
Também será materializado um número de sessão gerado aleatoriamente.

Após isso, o Middleware Filial submeterá o XML para o SAT.
Após obter retorno, gravará o retorno na Guarda e repassará informação ao Checkout 4G.
Além do status, o Middleware Filial deve retornar para o Checkout 4G o número de série do SAT e numeração da nota.

Checkout 4G passará XML do governo para Middleware Local realizar a impressão, se usuário solicitar que seja feita.

Venda com Contingência

Ao finalizar a venda, Checkout 4G mandará para o Middleware Filial o modelo fiscal de Venda ao Consumidor. Caso tenha uma opção de Contingência, deve ser mandada essa segunda opção também.

Com isso, o Middleware Filial será responsável por tentar com o primeiro rota, e em caso de falha, tentar a segunda.
Ele retornará para o Checkout 4G o status de cada tentativa.

Se na rota tiver contingência da NFC-e, por exemplo, o Checkout 4G ficará responsável por efetuar a operação caso a autenticação retorne falha.

Venda com Múltiplos SATs

No XML da transação o Checkout 4G passará a lista dos SATs conhecidos.
Caso o Middleware Filial esteja configurado para trabalhar com mais de um SAT ele deverá escolher sequencialmente, dentre os SATs passados na transação, o SAT para realizar a venda.

Recuperação da Venda

Em caso de queda de energia, o Checkout 4G recuperará a venda que estava sendo feita.
Caso tenha sido gerado número da sessão, mas o SAT não teve tempo de responder, o Middleware Filial poderá consultar a situação da operação através desse número que ficou armazenado.
Com isso, ele poderá tomar a decisão de efetuar a venda, tentar segunda opção de modelo fiscal, ou apenas retornar o status da operação realizada.

Será necessário alterar o ACBr para aceitar o número de sessão enviado pelo Middleware Filial, já que ele gera um número aleatória a cada comando.
O Middleware Filial precisará guardar o histórico dos últimos 100 números utilizados para não enviar um número repetido.
O motivo para ele ter que gerar o número antes é poder registrar no banco da Guarda para caso ocorra queda de energia.

Cancelamento da Venda

Ao cancelar um CF-e-SAT o Checkout 4G deverá passar para único SAT possível o SAT que realizou a venda.
O cancelamento de CF-e ganha uma numeração própria pelo SAT.
Ela será sempre o número seguinte a emissão do CF-e.

Reinício da Numeração

Quando a numeração da série atingir 999.999 ela voltará a 1.
No XML da transação, Checkout 4G passará ao Middleware Filial o contador de reinício de operação de cada série.
Caso este seja superior ao existente no banco da Guarda, a numeração mais alta prevalecerá.
Ao receber o retorno da autenticação, Middleware Filial passará ao Checkout 4G o contador de reinício daquela venda.
Caso a numeração tenha girado, o contador será incrementado no banco da Guarda.
Com isso, caso o Middleware Filial precise ser instalado em outra máquina por quebra no servidor, uma nova Guarda poderá continuar a contagem de reinício de operação corretamente.

Exportação dos XMLs de Venda e Cancelamento

Configurador do Middleware terá uma tela para exportar em arquivo os XMLs das vendas e cancelamentos.
Sistema deve exportar arquivo XML de cada operação respeitando as seguintes regras:

• Cupom de movimento: AD<chave de acesso>.xml;
• Cupom de cancelamento: ADC<chave de acesso>.xml

A portal do SAT orienta o usuário a compactar as cópias de segurança na extensão ".zip" observando as seguintes regras:

• Deve ser menor que 300KB;
• Não pode ter cupons de cancelamento e de movimento no mesmo arquivo;
• Não deve ter caminhos, pastas ou subpastas salvos nele;
• Não pode estar particionado ou dividido em volumes;
• Não pode ter encriptação ou senha;
• Deve conter no mínimo 1 e no máximo 50 CF-e-SAT.

Bloquear SAT

Para o cliente deixar de usar um SAT, ele precisará que o AC bloqueie o SAT.
Para isso, ele utilizará o mesmo programa de ativação do software do fabricante que ele usou para ativar o SAT.

Mudar SAT de Filial

Sistema prevê a possibilidade de reutilização do SAT em outro filial.
A regra do SAT prevê que seja feita desativação do SAT na filial atual, e posterior ativação na outra filial.
Sendo que, um SAT não poderá ser ativado novamente na mesma filial.

Após esse procedimento, usuário deverá cadastrar um novo registro na TD_SAT, informando a nova filial.
Deverá efetuar nova configuração no Middleware Filial da nova filial.

Não haverá risco de um Checkout 4G efetuar vendas por engano para aquele SAT na filial antiga porque o Middleware Filial não terá mais como se comunicar com ele.
E as vendas na nova filial só poderão ser realizadas após a carga do Checkout.

Reimpressão de CF em NF

Por não ser um documento válido para acobertar algumas operações, os clientes podem precisar fazer reimpressão de CF-e em nota.
Por enquanto, esse processo será feito pelo Checkout atual.

Nota:

O Cupom Fiscal não é documento hábil para acobertar entrada de mercadoria, remessa para demonstração, transferência, venda interestadual,

remessa para depósito no estado, simples remessa, remessa para industrialização, suspensão, diferimento, venda para entrega futura, para

documentar estorno de crédito etc, sendo neste caso, como regra, adotada a Nota Fiscal Eletrônica – NF-e ou a NF modelo 1 ou 1A.

A Nota Fiscal, com destaque de ICMS, se a operação for tributada, será entregue ao adquirente da mercadoria e o Cupom Fiscal ficará anexo

à via fixa (grampeado).

Essa Nota Fiscal emitida deve conter o CFOP 5.929, caso o adquirente seja de SP, ou 6.929, caso o adquirente seja de outro Estado. Ela deve

ser toda preenchida, sendo a sua escrituração feita com valores zerados, já que o débito será feito pelo cupom, Assim, no livro Registro de

Saídas deve ser registrado para esta nota apenas a coluna "Observações", onde serão indicados o seu número e a sua série.

(Uso do ECF na Emissão de Documentos Fiscais)

Configurar SAT

O SEFAZ recomenda que a empresa compre pelo menos dois SATs, mantendo um deles guardado.
Os dois SATs devem ser cadastrados no Config.

Especificação Técnica

1. Criar tabela TD_SAT (Aparelhos SAT) para cadastrar aparelhos SAT.

TD_SAT (Aparelhos SAT) CODTAB NUMBER(5) PK | Código DESSAT VARCHAR(40) NOT NULL | Descrição SATATI VARCHAR(1) NOT NULL Default 'T' | Ativo? SAT_NUMSER NUMBER(9) NOT NULL | Número de Série (sem dígito) SAT_CODFIL CHAR(3) NOT NULL | Filial SAT_CODSER CHAR(2) NOT NULL | Série SAT_CNT_RO NUMBER(5) NOT NULL DEFAULT 0 | Contador de Reinício de Operação

Constraints:

• CK para permitir "T" ou "F" em SATATI.
• FK de SAT_CODFIL com PK da TD_FIL.
• FK de SAT_CODSER com PK da TD_SER.
• Criar UQ com as colunas SAT_NUMSER e SAT_CODFIL para não permitir que um SAT seja cadastrado duas vezes para mesma filial.
• Criar UQ com as colunas SAT_CODFIL e SAT_CODSER para não permitir utilizar a mesma série duas vezes para a mesma filial.
• CK para obrigar SAT_CNT_RO >= 0.

2. Criar interface no Config para nova tabela em um novo nó na "Venda".
Fazer as validações de UQ criadas para a tabela.
Incluir a seguinte validação:

• Não permitir que o mesmo número de série esteja ativo em mais de uma filial.

Isso servirá para obrigar o usuário a desativar o SAT na filial original ou mudar o SAT de filial.

3. Tratar para não permitir alteração da série e filial depois que tiver vendas para esse SAT nessa filial.

Especificação para tarefa(s): 97618 97619

Sequência dos Modelos Fiscais

Sistema terá configuração para definir qual será o modelo fiscal adotado para Venda ao Consumidor.
E também terá uma opção de contingência.
Essas configurações serão disponibilizadas por filial e ECF, sendo que quando não houver definição por ECF, será utilizada a da filial.

Especificação Técnica

1. Criar colunas na TD_FIL para informar modelo fiscal e contingência.

Na TD_FIL, criar:

ck4g_modfis_vc VARCHAR(2) | Modelo Fiscal para Venda ao Consumidor ck4g_modfis_vc_cont VARCHAR(2) | Modelo Fiscal (1ª Contingência) ck4g_usa_cont_offline VARCHAR(1) | Usa Contingência de 65-NFC-e Offline?

2. Criar colunas na TD_ECF para informar modelo fiscal e contingência.

Na TD_ECF, criar:

ck4g_modfis_vc VARCHAR(2) | Modelo Fiscal para Venda ao Consumidor ck4g_modfis_vc_cont VARCHAR(2) | Modelo Fiscal (1ª Contingência) ck4g_usa_cont_offline VARCHAR(1) | Usa Contingência de 65-NFC-e Offline?

3. Criar interface para modelo fiscal na TD_FIL.

Na tela TD_FIL, na guia Checkout 4G, criar guia Fiscal com as 3 novas colunas:

ck4g_modfis_vc VARCHAR(2) | Modelo Fiscal para Venda ao Consumidor ck4g_modfis_vc_cont VARCHAR(2) | Modelo Fiscal (1ª Contingência) ck4g_usa_cont_offline VARCHAR(1) | Usa Contingência de 65-NFC-e Offline?

4. Criar interface para modelo fiscal na TD_ECF.

Na tela TD_ECF, na guia Checkout 4G, criar groupbox Fiscal com as 3 novas colunas:

ck4g_modfis_vc VARCHAR(2) | Modelo Fiscal para Venda ao Consumidor ck4g_modfis_cont VARCHAR(2) | Modelo Fiscal (1ª Contingência) ck4g_usa_cont_offline VARCHAR(1) | Usa Contingência de 65-NFC-e Offline?

Para campo padrão o combo deve ter as seguintes possibilidades:

• 2D - Cupom Fiscal
• 65 - NFC-e
• 59 - CF-e-SAT

No campo de contingência deve ter somente:

• 65 - NFC-e
• 59 - CF-e-SAT

Validar que o campo padrão seja diferente da contingência.
Não permitir contingência caso modelo seja 2D.

Só permitir marcar "Usa Contingência de 65-NFC-e Offline?" se 65-NFC-e tiver sido escolhido.

Especificação para tarefa(s): 97620 97621 97622 97624

Configurações do Middleware

No configurador do Middleware será criada uma nova guia específica para o SAT.
Essa guia terá todos os dados necessários para fazer com que o Middleware consiga operar com 1 ou mais aparelhos SAT.

Especificação Técnica

1. Criar uma nova guia no WSMiddleware contendo uma lista de SATs. Criar tela de inclusão/edição com os seguintes campos:

• Número de série do SAT (Integer; Padrão 0) Obrigatório
• Assinatura do AC (String; Padrão "") Obrigatório
• Código de ativação (String; Padrão "") Obrigatório
• Local da DLL (String; padrão c:\SAT\sat.dll) Obrigatório
• Porta COM da DLL (string; padrão "")
• Acesso a DLL (Integer; 0-nenhum, 1-cdecl ou 2-stdcall; Padrão 2) Obrigatório
• Versão do layout (Real; Padrão 0.06) Obrigatório
• UTF-8 (Boolean; Padrão False)
• Página de código do UTF-8 (Integer: Padrão 0)
• Ambiente (Integer: 0-Produção ou 1-Homologação; Padrão 0) Obrigatório

2. Configurador deve ter um botão para testar a comunicação com o SAT, através do método ConsultaSat.
Botão deve estar na tela de edição.

Especificação para tarefa(s): 97625

Serviço de Autenticação no Middleware

O serviço de autenticação de NFC-e deverá ser reestruturado para ser um serviço de autenticação de documentos eletrônicos genérico.

Ele recebe filial, ECF e o XML da transação.

Ele precisa converter o XML da transação em DocEmitidoEletronico.
Abandonaremos a ideia de usar de classes específicas para NF-e, NFC-e e CF-e porque elas possuiriam pouca diferença entre si, e o sistema precisará em algum momento converter de um tipo para outro por causa do processo de contingência.

XML da transação passará a ter modelos fiscal e modelo fiscal em contingência.
Serviço deverá tentar efetuar a autenticação com um, e se falhar, com o outro.
Esse processo de conversão do tipo e interação com Autentica DocEmitidoEletronico é demonstrada no diagrama abaixo.

O serviço Autentica DocEmitidoEletronico deverá receber um objeto a ser autenticado.
Esse objeto já terá um modelo fiscal definido, o que fará com que o serviço definirá:

• XML que precisa ser gerado.
• Se autenticará no SAT ou no SEFAZ.

Todo o processo deverá ser gravado no banco da Guarda.
E esse serviço não pode ter acesso ao banco do Commerce.

Na tabela de Guarda precisaremos de alguns dados a mais do que são gravados hoje:

• Modelo fiscal
• Operação (Venda/Cancelamento).
• Deve gravar também o XML da transação.
• Chave de Acesso Gerada.
• Número da Sessão (quando tiver).

Processo é descrito no diagrama abaixo.

O serviço precisará de alguns cuidados extras que devem ser definidos pelo programador com testes.
Mas recomenda-se partir da seguinte ideia:

• Objeto que representará o SAT (SEFAZ) deverá ser singleton.
• Deverá ser instanciado quando o serviço do Middleware Filial for iniciado, e consequentemente será único.
• Esse objeto deve ter a lista dos SATs configurados, e um atributo que armazene qual foi o último SAT utilizado.
• No XML da transação, Checkout 4G passará quais são os números de série que poderão ser utilizados na operação.
• Objeto singleton deve escolher sequencialmente os SATs de sua lista.
• A rotina que escolhe e interage com o SAT deve ser Synchronized, para que dois processos não chamem o mesmo SAT ao mesmo tempo.
• Mas o processo deve ser feito de maneira que mais SATs funcionem em paralelo.
• Se SAT estiver ocupado por outra requisição vai retornar ocupado, então outra opção é tentar até conseguir.

Quando for autenticar um CF-e-SAT, serviço deve gerar um número de sessão aleatório.
Ele não pode ser igual a um número gerado para aquele SAT nas últimos 100 requisições.
O componente do ACBr precisará ser modificado para aceitar esse número de sessão que vamos mandar para ele.

Guarda deve materializar o contador de reinício de operação de cada SAT.
Esse também será mandado via XML pelo Checkout 4G junto com o número de série do SAT.
Caso a numeração vire (999.999 para 000.001) serviço deve incrementar o contador.

Serviço deve devolver ao Checkout 4G o status de cada tentativa (modelo fiscal e contingência), o número de série do SAT, a numeração gerada pelo SAT e o contador de reinício de operação.

Especificação para tarefa(s): 97626

Serviço de Cancelamento no Middleware

É o serviço de cancelamento de NFC-e implementado atualmente.
A mais terá apenas a gravação da operação na base da Guarda.

O Checkout 4G será responsável por mandar o número de série do SAT que emitiu a venda para aumentar as chances de cancelamento do CF-e-SAT.

Especificação para tarefa(s): 97627

Serviço de Restrição de Modelos Fiscais

Criar no Middleware do Checkout 4G (WSLocal) um serviço que receba UF e uma chave e retorne se pode ou não gerar.
A classe responsável por essa verificação deverá ser isolada e disponível para todos os módulos.
As chaves estão especificadas entre colchetes na tabela abaixo.

UF	Permite 2D - Cupom Fiscal? [2D_CUPOM_FISCAL]	Permite 65 - NFC-e? [65_NFCE]	Permite 65 - NFC-e offline? [65_NFCE_OFFLINE]	Permite 59 - CF-e-SAT? [59_CFE_SAT]
AC	True	F	F	F
AL	True	F	F	F
AP	True	F	F	F
AM	True	True	True	F
BA	True	F	F	F
CE	True	F	F	F
DF	True	F	F	F
ES	True	F	F	F
GO	True	F	F	F
MA	True	F	F	F
MS	True	F	F	F
MG	True	F	F	F
PA	True	F	F	F
PB	True	F	F	F
PR	True	F	F	F
PE	True	F	F	F
PI	True	F	F	F
RJ	True	F	F	F
RN	True	F	F	F
RS	True	F	F	F
RO	True	F	F	F
RR	True	F	F	F
SC	True	F	F	F
SP	F	True	F	True
SE	True	F	F	F
TO	True	F	F	F

Deixar bem claro na documentação da classe onde ficarão as regras de que essas regras servem para proteger a Totali de configurações indevidas.
O objetivo é não permitir que o cliente gere algum tipo de documento fiscal que ele está proibido e que a software não deveria permitir.

Tratar no Config para não permitir configurar para TD_ECF e nem para TD_FIL modelos fiscais inválidos para a UF do cliente.
O Config deve acessar as classes diretamente para consultar o que pode e o que não pode.

Especificação para tarefa(s): 97628

Venda e Cancelamento no Checkout 4G

Alterar XML da transação do Checkout 4G incluindo os seguintes dados:

• Modelo fiscal para venda ao consumidor.
• Modelo fiscal de Contingência para venda ao consumidor.
• Modelo fiscal efetivamente utilizado na operação.
• Lista de SATs contendo Número de Série e Contador de Reinício de Operação de cada SAT conhecido.

Com isso, poderá ser dado prosseguimento nas tarefas de criação de serviços.

Checkout 4G precisará ser alterado para contemplar os itens listados abaixo:

• Receber na carga os dados da TD_SAT.
• Receber na carga modelo fiscal e contingência do ECF (e da filial não tiver por ECF).
• Ao realizar Venda ao Consumidor, deverá observar a Modelo Fiscal configurado e contingência.
• Se modelo fiscal ou contingência forem 59-CF-e-SAT, deverá enviar na transação da venda a lista de número de séries de SAT que ele conhece com seus respectivos contadores de reinício de operação.
• Deve utilizar mesmo serviço de NFC-e para vender CF-e.
• Deve gerar numeração fictícia para as vendas do SAT.
• Deve calcular e passar valor aproximado dos tributos do produto ou serviço – Lei 12.741/12.
• Deve obter do retorno da venda número de série do SAT utilizado, número, contador de reinício de operação e resultado da operação e da contingência, caso houver.
• Deve perguntar ao usuário se ele deseja imprimir o CF-e-SAT.
• Deve utilizar mesmo serviço de cancelar NFC-e para cancelar o CF-e.
• Deve passar o número de série do SAT que efetuou a venda na transação do cancelamento.
• Deve tratar retorno com erros, para o caso da venda não possa ser cancelada pelo SAT.
• Deve avisar usuário se o SAT estiver bloqueado ou com algum outro erro.
• Deve avisar contribuinte se o SAT estiver há mais de 3 dias sem se comunicar com o SEFAZ.
• Deve tratar contingência offline de NFC-e conforme configuração.
• Tratar restrição de modelos fiscais consultando os modelos configurados no Serviço de Restrição de Modelos Fiscais.
• Deve passar modelo fiscal utilizado efetivamente na venda no XML de transação para que o Middleware materialize esse dado.

O diagrama abaixo demonstra como será a interação do Checkout 4G com o serviço de autenticação do Middleware.
E também demonstra a execução da contingência de NFC-e pelo Checkout 4G.

Especificação para tarefa(s): 97635 97629

Materialização do Modelo da Nota

Passaremos a materializar o modelo fiscal da tabela de vendas [TT_VEN].

Para isso, criar coluna:
MODNOT VARCHAR(2) | Modelo Fiscal

E fazer tratamento no Middleware para gravar o dado que veio no XML de transação.

Especificação para tarefa(s): 97632 97633

Exportação dos XMLs de Venda e Cancelamento

Criar uma tela no Configurador do Middleware para usuário informar número de série do SAT e intervalo de dados e gravar em uma pasta definida os arquivos XMLs de Venda e Cancelamento gravados na Guarda.

Para isso, criar um serviço que receba Número de série do SAT, Intervalo de Dados e caminho.
E grave no caminho os arquivos de XML de Vendas e cancelamentos registrados na Guarda para modelo "59".
Sistema deve exportar arquivo XML de cada operação respeitando as seguintes regras:

• Cupom de movimento: AD<chave de acesso>.xml;
• Cupom de cancelamento: ADC<chave de acesso>.xml

Especificação para tarefa(s): 97630

Bloquear Série de SAT no Checkout e Tratar Reimpressão de Cupom Fiscal em Nota

Por não ser um documento válido para acobertar algumas operações, os clientes podem precisar fazer reimpressão de CF-e em nota. Por enquanto, esse processo será feito pelo Checkout atual.

• Tratar para não permitir vender com séries que tenham modelo "65" e "59".
• Permitir escolher CF-e-SAT na tela de reimpressão de CF em NF.

Os CF-e-SAT são documentos que possuem as seguintes características:

• A TT_VEN estará relacionada com uma TD_SER cujo modelo é "59".
• O número de série utilizado na impressão da observação fiscal é o número de série do SAT, obtido através do select de qual TD_SAT ativa combina com CODFIL e CODSER do CF-e.
• Para simplificar isso, materializamos na TT_VEN a coluna MODNOT. Pode-se conferir por ela, lembrando de que ela pode ser nulo.

Especificação para tarefa(s): 97631

Exportação Fiscal

No SPED Fiscal:

• Gerar Registro Cupom Fiscal Eletrônico - CF-e (Código 59) - C800
• Gerar Registro Analítico do CF-e (Código 59) - C850
• Gerar Identificação do equipamento SAT-CF-e (Código 59) - C860
• Gerar Resumo diário de CF-e (Código 59) por equipamento SAT-CF-e - C890
• Gerar Registro CUPOM FISCAL ELETRÔNICO REFERENCIADO - C116

No SPED Contribuições:

• Registro C860 - Identificação do Equipamento SAT-CF-e
• Registro C870: Resumo Diário de Documentos Emitidos por Equipamento SAT-CF-e (código 59) – PIS/PASEP e COFINS
• Registro C880: Resumo Diário de Documentos Emitidos por Equipamento SAT-CF-e (código 59) – PIS/PASEP e COFINS Apurado por Unidade de Medida de Produto

A partir de Maio/2015, na versão 2.11 do PVA, o SAT foi retirado do registro C490 para ter registro próprio C860.
Vamos implementar só dessa forma, porque não teremos movimento anterior a essa data.

Especificação para tarefa(s): 97634