Tratamento da Contingência - Ajuste SINIEF n. 13/2018

bnobre · 28 Fevereiro, 2019

Olá a todos,

Dado o Ajuste SINIEF n. 13/2018, teremos que utilizar séries exclusivas para as notas em contingência, além de uma numeração sequencial e sem quebras para a mesma.

Com isso estou desenvolvendo um tratamento específico para suprir tal necessidade e gostaria de compartilhar com os colegas a rotina que estou usando, para saber se meu pensamento está correto ou até mesmo se alguém pode acrescentar algo mais sobre o assunto em si.

Observem o exemplo abaixo. PDV com Série Normal = 1 e Cupom Normal iniciando em 100. Série Contingência = 890 e Cupom Contingência iniciando em 1.

1º - Usuário tenta a emissão de um cupom normal (1 - 100), dado falha de internet gera uma contingência (890 - 1).

2º - Dado a falha na nota 1-100, não se sabe se a mesma foi realmente autorizada ou não, por isso marco essa nota e verifico posteriormente se cancelo por substituição de contingência ou inutilizo tal numeração.

3º - Usuario tenta a emissão de um novo cupom normal (1-101), dado falha de internet gera uma contingência (890 - 2).

4º - Dado a falha na nota 1-101, não se sabe se a mesma foi realmente autorizada ou não, por isso marco essa nota e verifico posteriormente se cancelo por substituição de contingência ou inutilizo tal numeração.

5º - Usuário tenta a emissão de um novo cupom normal (1-102) e consegue.

6º - Usuário tenta a emissão de um novo cupom normal (1-103) e consegue.

7º - E por aí vai...

Como podem observar no processo que quero criar cada tentativa de emissão de NFCe normal com falha irá gerar uma NFCe de Contingência de valores e itens iguais, e portanto precisa ser tratada posteriormente, com um cancelamento ou uma inutilização.

Meu pensamento está correto? Alguém tem uma visão mais simplória sobre essa rotina?

Desde já agradeço a atenção de todos.

ALA · 28 Fevereiro, 2019

Acho que sim, tb estou fazendo dessa forma. Mas parece que a mudança da serie deve ser feita so a partir do final de março, e deve ser publicado uma NT confirmando isso..Se mandar antes da data prevista a SEFAZ pode reclamar...

bnobre · 28 Fevereiro, 2019

23 minutos atrás, ALA disse:

Acho que sim, tb estou fazendo dessa forma. Mas parece que a mudança da serie deve ser feita so a partir do final de março, e deve ser publicado uma NT confirmando isso..Se mandar antes da data prevista a SEFAZ pode reclamar...

Obrigado pelo retorno ALA...

Eu tenho uma grande dúvida ... Atualmente o manual de contingência da NFCe orienta o seguinte (observar imagem em anexo):

Citar

Para aquela que ficou pendente de retorno (a nota n° 20 desse exemplo):

inutilizar a numeração, se não autorizada; ou

cancelar, se autorizada

Fonte: http://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=YbZEjEHCuHQ=

Atualmente se seguirmos essa orientação, vamos supor que a nota 20 tenha sido emitida, a contingência 21 é gerada em substituição da 20 e o posterior tratamento da nota 20 não possa ser feito em até 24 horas (o que é bem comum atualmente dado falhas de internet)... Basicamente o cliente terá que pagar dois impostos... Como você previne isso atualmente nos seus clientes? É uma grande curiosidade que tenho, pois não sigo essa orientação do manual.

Nesse novo padrão de séries específicas para contingência(890 a 989) seguirei essa orientação de inutilizar ou cancelar a nota que ficou pendente, mas mesmo com o cancelamento por substituição de NFCe em contingência e seu prazo do cancelamento de 168 horas, em tese o problema pode continuar caso o cliente fique 7 dias sem internet... Portanto insisto na pergunta, como prevenir isso de forma a evitar que o cliente pague o imposto duplicado?

Desde já agradeço a sua participação

Editado 28 Fevereiro, 2019 por doidopb
Melhor posicionar a imagem

ALA · 28 Fevereiro, 2019

Não sei se entendi bem a sua duvida. Mas estou desenvolvendo da seguinte forma. Tentei enviar a nota 10, não consegui recebe o retorno da SEFAZ por qualquer motivo. Gero a nota 11 igual a nota 10 mas em contingencia. Libero o cliente com a nota 11. Quando o problema for resolvido consulto a nota 10, se estiver autorizada cancelo, se não estive inutilizo a numeração....

Parece que nos estados que a NFC-e ja esta funcionando vc consegue enviar/cancelar em um prazo maior que 24 hrs....

Editado 28 Fevereiro, 2019 por ALA

bnobre · 28 Fevereiro, 2019

7 minutos atrás, ALA disse:

Não sei se entendi bem a sua duvida. Mas estou desenvolvendo da seguinte forma. Tentei enviar a nota 10, não consegui recebe o retorno da SEFAZ por qualquer motivo. Gero a nota 11 igual a nota 10 mas em contingencia. Libero o cliente com a nota 11. Quando o problema for resolvido consulto a nota 10, se tiver autorizada cancelo, se não estive inutilizo a numeração....

Perfeito... Agora suponha que a nota 10 foi autorizada, seu cliente ficou mais de 24 horas sem internet e ao tentar cancelar a nota 10 teve o erro "PRAZO DE CANCELAMENTO SUPERIOR AO EMITIDO"... Como você procede?

ALA · 28 Fevereiro, 2019

Hai tem que verificar com a SEFAZ, mas pelo que tenho visto isso não esta acontecendo. A SEFAZ esta permitindo cancelar apos 24hrs..

bnobre · 28 Fevereiro, 2019

3 minutos atrás, ALA disse:

Hai tem que verificar com a SEFAZ, mas pelo que tenho visto isso não esta acontecendo. A SEFAZ esta permitindo cancelar apos 24hrs..

Ok... Mas vamos supor que aconteça, qual o procedimento que seu programa faz nesses casos?

ALA · 28 Fevereiro, 2019

Se a SEFAZ não permite o cancelamento não tem com fazer nada, ai passamos a bola para o contador resolver. Mas a retaguarda pode tratar isso e não dar baixa duplicada no estoque. Na nota que gerei primeiro 10 eu gravo o numero da nota 11 que gerei em contingencia, dessa forma sei que a 10 gerou a 11.

bnobre · 28 Fevereiro, 2019

Perfeito então cara...

Você está com o mesmo pensamento que eu...

Criei um campo ID_CONTINGÊNCIA onde eu gravo o ID da contingência gerada... Como no seu exemplo a nota 10 fica com o ID da 11.

A nota 10 não faz nenhuma ação de venda(saida de estoque, financeiro, etc)... Ela só fica PENDENTE aguardando eu Cancelar ou Inutilizar...

Para a nota 11 (em contingência) ser enviada eu pretendo OBRIGAR o programa realizar o tratamento da 10 primeiro (cancelando ou inutilizando) que é vinculada a nota 11... Mas ai nos casos em que o Cancelamento superar o prazo limite eu serei obrigado a marcar a nota 10 como AUTORIZADA para então enviar a 11...

Entendeu a logística que quero fazer?

Editado 28 Fevereiro, 2019 por doidopb

ALA · 1 Março, 2019

Bom dia. Não estou pensando em parar a venda ate o usuário resolver o problema, pq senão, vai parar os caxias toda hora... Vou realizar esse procedimento de verificar as notas com problema quando o usuário tentar fechar o caixa, sair ou entrar no sistema.. Todos os meus caixas tem um BD local e temos um programa que fica rodando na memoria para enviar/receber os dados do BD centralizado. Esse programa só envia as NFC-e que estão sem pendencia para o servidor.... Nesse caso a nota 10 estará pendente de resolução, caso o nosso PDV não consiga cancela/inutilizar a mesma automaticamente....

bnobre · 1 Março, 2019

Oi ALA...

Tudo bom? Nosso papo está rendendo, isso é bom

Vamos lá, acho que me expressei mal, eu não vou e nem posso parar a venda, vou explicar melhor.

Pelo jeito minha estrutura é exatamente igual a sua, cada PDV tem um BD próprio (para continuar vendendo caso o retaguarda caia), e envio para o retaguarda somente a carga das vendas concluídas (autorizadas ou contingências já enviadas), no meu caso esse envio ocorre cada vez que abre o PDV, é realizado uma venda ou fecha o PDV.

Já para o envio das notas em contingência, cada PDV tem um aplicativo próprio que tenta realizar esse envio de 5 em 5 minutos, sem atrapalhar ou parar o PDV. A questão que coloquei foi que agora antes de enviar uma nota em contingência, tratarei antes a nota pendente vinculada a ela (inutilizando ou cancelando sua numeração). O PDV não pode parar nunca de vender, por isso esse tratamento ocorre em paralelo.

Sendo que, no exemplo que estamos, para eu enviar a 11 vou tratar a 10 primeiro, se a 10 não autorizou eu inutilizo a mesma e apago da lista de vendas, se autorizou eu cancelo, mas se passou o prazo do cancelamento vou ter que marcar como AUTORIZADA e AMBAS serão enviadas para o retaguarda... Uma dessas 3 coisas vai ter que acontecer e aí então eu mandarei a 11... Com isso mando ambas para o retaguarda, pois a 11 foi enviada e a 10 tratada...

Entendeu? Se sim, como você marcará essa nota que não pode cancelar dado o prazo superior?

ALA · 1 Março, 2019

Bom dia. E o seguinte, estou pensando em fazer o cancelamento por substituição dessas notas, o prazo e de 168 horas. A nota 11 substitui a nota 10.

Editado 1 Março, 2019 por ALA

bnobre · 1 Março, 2019

3 minutos atrás, ALA disse:

Bom dia. E o seguinte, estou pensando em fazer o cancelamento por substituição dessas notas, o prazo e de 168 horas. A nota 11 substitui a nota 10.

Com certeza, na verdade nem pensei em fazer o cancelamento normal, só farei por substituição.

Só quero me preparar para os casos em que o cliente mesmo assim conseguir ficar 7 dias sem internet, e não diga que é impossível pois sabemos como são os clientes e a infraestrutura dessa país, aqui no RJ a internet é péssima...

Hoje minhas notas tem 3 status: AUTORIZADA, CANCELADA e CONTINGÊNCIA... Estou pensando em criar um quarto, chamado DUPLICADA (que seria o caso da 10 se passasse os 7 dias de prazo de cancelamento)

Dessa forma resolvo a pendência, envio a 11 e deixo o cliente CIENTE do problema de duplicação.

O que acha dessa logística?

ALA · 1 Março, 2019

Boa tarde. Tb estou fazendo assim. Você poderia postar um exemplo de como da sua rotina p gerar/enviar a NFC-e em produção/homologação. E com vc esta fazendo para enviar o Cancelamento por Substituição.

Obs.: O maior problema que estou enfrentando e quando gerar em contingencia e quando enviar normal.....

*************************

Para enviar Normal/Contingencia estou fazendo assim:

if DMXML.CDS_VENDA.FieldByName( 'VEN_TPEMIS' ).AsInteger = dmco_NFCe_TipoEmissao_OffLine then
begin
ACBrNFe.NotasFiscais.Assinar;
lcbo_EnviouNFe := True;
g.Registra_Log( dmco_Log_Aviso + ' NFC-e número: ' + DMXML.CDS_VENDA.FieldByName( 'VEN_NUMERO' ).AsString + ' chave: '+ ACBrNFe.NotasFiscais.Items[0].NFe.infNFe.ID + ' enviada em CONTIGENCIA OFF LINE', EmptyStr, EmptyStr, True, dmst_NumeroCupom );
end
else
begin
lcbo_EnviouNFe := ACBrNFe.Enviar(DMXML.CDS_VENDA.FieldByName( 'VEN_NUMERO' ).AsString,True,True);
end;

if not lcbo_EnviouNFe then
begin
dmme_RetornoWS := ACBrNFe.NotasFiscais.Items[0].XML;
Abort;
end
else
begin
Memo.Lines.Text := ACBrNFe.WebServices.Enviar.RetWS;
memo_Recibo.Lines.Text := ACBrNFe.WebServices.Enviar.RetornoWS;
LoadXML(ACBrNFe.WebServices.Enviar.RetWS, mRecebido);
Memo.Lines.Add('');
Memo.Lines.Add('Envio NFCe');
Memo.Lines.Add('tpAmb: ' + TpAmbToStr(ACBrNFe.WebServices.Enviar.TpAmb ));
Memo.Lines.Add('verAplic: ' + ACBrNFe.WebServices.Enviar.verAplic );
Memo.Lines.Add('cStat: ' + IntToStr(ACBrNFe.WebServices.Enviar.cStat ));
Memo.Lines.Add('cUF: ' + IntToStr(ACBrNFe.WebServices.Enviar.cUF ));
Memo.Lines.Add('xMotivo: ' + ACBrNFe.WebServices.Enviar.xMotivo );
Memo.Lines.Add('Recibo: ' + ACBrNFe.WebServices.Enviar.Recibo );

// Registra no Log //
//if IntToStr(ACBrNFe.WebServices.Enviar.cStat ) <> 107 then
//begin
// g.RegistraLog();
//end;

// ** //
dmme_RetornoWS := ACBrNFe.NotasFiscais.Items[0].XML;
lcst_Chave := util.Retorna_Numeros( ACBrNFe.NotasFiscais.Items[0].NFe.infNFe.ID );

bnobre · 2 Março, 2019

20 horas atrás, ALA disse:

Boa tarde. Tb estou fazendo assim. Você poderia postar um exemplo de como da sua rotina p gerar/enviar a NFC-e em produção/homologação. E com vc esta fazendo para enviar o Cancelamento por Substituição.

Obs.: O maior problema que estou enfrentando e quando gerar em contingencia e quando enviar normal.....

*************************

Para enviar Normal/Contingencia estou fazendo assim:

if DMXML.CDS_VENDA.FieldByName( 'VEN_TPEMIS' ).AsInteger = dmco_NFCe_TipoEmissao_OffLine then
begin
ACBrNFe.NotasFiscais.Assinar;
lcbo_EnviouNFe := True;
g.Registra_Log( dmco_Log_Aviso + ' NFC-e número: ' + DMXML.CDS_VENDA.FieldByName( 'VEN_NUMERO' ).AsString + ' chave: '+ ACBrNFe.NotasFiscais.Items[0].NFe.infNFe.ID + ' enviada em CONTIGENCIA OFF LINE', EmptyStr, EmptyStr, True, dmst_NumeroCupom );
end
else
begin
lcbo_EnviouNFe := ACBrNFe.Enviar(DMXML.CDS_VENDA.FieldByName( 'VEN_NUMERO' ).AsString,True,True);
end;

if not lcbo_EnviouNFe then
begin
dmme_RetornoWS := ACBrNFe.NotasFiscais.Items[0].XML;
Abort;
end
else
begin
Memo.Lines.Text := ACBrNFe.WebServices.Enviar.RetWS;
memo_Recibo.Lines.Text := ACBrNFe.WebServices.Enviar.RetornoWS;
LoadXML(ACBrNFe.WebServices.Enviar.RetWS, mRecebido);
Memo.Lines.Add('');
Memo.Lines.Add('Envio NFCe');
Memo.Lines.Add('tpAmb: ' + TpAmbToStr(ACBrNFe.WebServices.Enviar.TpAmb ));
Memo.Lines.Add('verAplic: ' + ACBrNFe.WebServices.Enviar.verAplic );
Memo.Lines.Add('cStat: ' + IntToStr(ACBrNFe.WebServices.Enviar.cStat ));
Memo.Lines.Add('cUF: ' + IntToStr(ACBrNFe.WebServices.Enviar.cUF ));
Memo.Lines.Add('xMotivo: ' + ACBrNFe.WebServices.Enviar.xMotivo );
Memo.Lines.Add('Recibo: ' + ACBrNFe.WebServices.Enviar.Recibo );

// Registra no Log //
//if IntToStr(ACBrNFe.WebServices.Enviar.cStat ) <> 107 then
//begin
// g.RegistraLog();
//end;

// ** //
dmme_RetornoWS := ACBrNFe.NotasFiscais.Items[0].XML;
lcst_Chave := util.Retorna_Numeros( ACBrNFe.NotasFiscais.Items[0].NFe.infNFe.ID );

Cara...Então, seu código não tem comentários, portanto vou descrever o que eu entendi dele e você me corrige se eu estiver errado:

1º - Você verifica através de um campo na sua tabela ( 'VEN_TPEMIS' ) se o tipo de emissão é normal ou offline, e dependendo do resultado emite normal ou em contingência.

2º - Se emitiu em contingencia ou obteve retorno positivo do envio normal você mostra o retorno em um Memo e salva o ACBrNFe.NotasFiscais.Items[0].NFe.infNFe.ID em "lcst_Chave".

Parece que isso é um protótipo de um código, não parece ser o código final de um PDV, visto que não teria necessidade de um Memo para isso...

De qualquer maneira a sua dúvida foi "O maior problema que estou enfrentando e quando gerar em contingencia e quando enviar normal....."... Vamos falar sobre ela, realmente não entendi porque no início do seu código você tem um campo no seu banco que diz se vai emitir normal ou em contingência, e como tem a ver com a sua dúvida eu vou explicar como eu faço:

Você sempre tenta enviar normal, sempre... Só se houver uma falha de internet você tem que gerar a nota em contingência e deixar a pendente para tratamento posterior

try
    ACBrNFe1.Enviar(cupom, False, True)
except
    on E : Exception do
        if (pos('requisição não enviada', LowerCase(E.Message)) <> 0) or (pos('tempo limite', LowerCase(E.Message)) <> 0)
           (pos('erro http', LowerCase(E.Message)) <> 0) or (pos('webservice', LowerCase(E.Message)) <> 0) Then
            begin
                ACBrNFe1.NotasFiscais.Clear;
                ACBrNFe1.Configuracoes.Geral.FormaEmissao := teOffLine ;
                GerarNFCe(serie, IntToStr(cupom), True);
                ACBrNFe1.NotasFiscais.Assinar;
                ACBrNFe1.NotasFiscais.Validar;
            end;
	else
    	begin
            if (pos('falha na validação dos dados da nota', LowerCase(e.Message)) <> 0) then
            	mensagemexcecao := ACBrNFe1.NotasFiscais.Items[0].ErroValidacaoCompleto
            else mensagemexcecao := e.Message;

            messageBox(handle,Pchar(mensagemexcecao),'Erro!',MB_ICONERROR+mb_OK);

            Exit;
        end;
end;

Como pode observar eu verifico o tipo de erro que acontece no envio, se for erro de falha de internet eu configuro a nota para contingencia e gero novamente o XML, caso contrário eu exibo o erro para o operador verificar e proceder a correção (NCM invalido, CFOP X CSOSN, GTIN invalido, etc).

Em relação a fazer o cancelamento por substituição, segue exemplo abaixo:

ACBrNFe1.EventoNFe.Evento.Clear;
with ACBrNFe1.EventoNFe.Evento.Add do
    begin
        infEvento.chNFe := chave_pendente;
        infEvento.CNPJ   := Emitente_CNPJCPF;
        infEvento.dhEvento := now;
        infEvento.tpEvento := teCancSubst;
        infEvento.detEvento.xJust := 'CANCELAMENTO POR SUBSTITUIÇÃO DE NFCE SÉRIE ' + serie + ' NÚMERO ' + cupom;
        infEvento.detEvento.nProt := ACBrNFe1.NotasFiscais.Items[0].NFe.procNFe.nProt;
        infEvento.detEvento.cOrgaoAutor := codigo_uf;
        infEvento.detEvento.verAplic := '1.0';
        infEvento.detEvento.chNFeRef := chave_contingencia;
    end;
ACBrNFe1.EnviarEvento(cupom_pendente);

Ficou alguma dúvida?

Editado 2 Março, 2019 por doidopb

ALA · 7 Março, 2019

Muito obrigado doidopb pela resposta...

Duvida:Quando vc envia a nota e ocorre o erro de internet

    if (pos('requisição não enviada', LowerCase(E.Message)) <> 0) or (pos('tempo limite', LowerCase(E.Message)) <> 0)
           (pos('erro http', LowerCase(E.Message)) <> 0) or (pos('webservice', LowerCase(E.Message)) <> 0) Then

vc apenas troca os dados do componente para enviar em contigencia ? Eu estou fazendo um pouco diferente, a nota 10 que eu tentei enviar e não consegui por problemas de internet, deixo gravada como pendente no meu BD e gero a nota 11 em contingencia com base na nota 10. Então no meu BD fica gravada a nota 10 pendente e 11 gerada em contingencia. Depois quando vou realizar o fechamento de caixa verifico qual o status da nota 10 se enviada, cancelo por substituição, se não enviada inutilizo a numeração.

bnobre · 8 Março, 2019

7 horas atrás, ALA disse:
Muito obrigado doidopb pela resposta...

Duvida:Quando vc envia a nota e ocorre o erro de internet
    if (pos('requisição não enviada', LowerCase(E.Message)) <> 0) or (pos('tempo limite', LowerCase(E.Message)) <> 0)
           (pos('erro http', LowerCase(E.Message)) <> 0) or (pos('webservice', LowerCase(E.Message)) <> 0) Then
    
vc apenas troca os dados do componente para enviar em contigencia ? Eu estou fazendo um pouco diferente, a nota 10 que eu tentei enviar e não consegui por problemas de internet, deixo gravada como pendente no meu BD e gero a nota 11 em contingencia com base na nota 10. Então no meu BD fica gravada a nota 10 pendente e 11 gerada em contingencia. Depois quando vou realizar o fechamento de caixa verifico qual o status da nota 10 se enviada, cancelo por substituição, se não enviada inutilizo a numeração.

Então... Acho que não ficou claro, isso que você faz(não reaproveitar o número da nota pendente e cancelar ou inutilizar a mesma) é o que o manual da contingência orienta e eu realmente não FAZIA, por isso abri o tópico pra explicar como pretendo fazer pra ver se estou seguindo corretamente o manual... Da maneira que está fazendo é igual a que eu FAREI, então tivemos a mesma lógica em relação ao manual. Ok? Prosseguindo...

Só postei esse código pois você disse que sua grande dúvida era "quando gerar em contingência"... Deu a entender que fosse em relação ao momento, por isso botei em caso dessas falhas de internet, mas você está certo em relação a não reaproveitar o número do cupom pendente de tratamento (10) e gerar um novo número para o cupom em contingência (11).

Essa lógica do manual é muito "bonitinha" (não reaproveitar o número do cupom pendente e cancelar/inutilizar o mesmo) mas tem um problema sério que o manual não contempla, observe... Vamos supor que a 10 (pendente) precisa ser inutilizada... Você autoriza a 11 (contingência vinculada a 10) e tenta inutilizar a 10... Perfeito, só que na hora que inutilizou a 10 deu uma falha de internet que impossibilitou o recebimento desse XML de inutilização e teu sistema não soube se inutilizou ou não.... Aí tu tenta inutilizar novamente, o sistema vai acusar que aquela faixa de numeração JÁ FOI inutilizada e você não consegue mais obter o XML dessa inutilização, pois a SEFAZ não fornece... Como tu resolve isso? Fala o que para seu cliente ou o contador dele?

Editado 8 Março, 2019 por doidopb

ALA · 8 Março, 2019

Bom dia. Nesse caso de inutilizar e não receber o protocolo, vc pode consultar a nota, se mesmo assim não retornar o protocolo, eu oriento o cliente a entrar no site da SEFAZ e pegar o protocolo, ai permito ele colocar o protocolo manualmente na nota. Utilizo essa regra para NFe, não sei se para NFC-e vai funcionar...

Editado 8 Março, 2019 por ALA

bnobre · 8 Março, 2019

2 horas atrás, ALA disse:

Bom dia. Nesse caso de inutilizar e não receber o protocolo, vc pode consultar a nota, se mesmo assim não retornar o protocolo, eu oriento o cliente a entrar no site da SEFAZ e pegar o protocolo, ai permito ele colocar o protocolo manualmente na nota. Utilizo essa regra para NFe, não sei se para NFC-e vai funcionar...

De acordo com o Italo, você "senta e chora", o webservice de consulta da SEFAZ não fornece nada de inutilização...

Acho o fato da SEFAZ não disponibilizar o XML da inutilização tão "amador", pois a mesma sugere inutilizar a nota em caso de falhas de internet, e ao mesmo tempo não PENSOU que tal falha também pode ocorrer na hora de inutilizar?!?!? Loucura isso.

De qualquer maneira, nunca tive esse problema pois até então nunca usei a recomendação do Manual de Contingência (inutilizar ou cancelar o número do cupom pendente de tratamento) e reaproveitava o número do cupom pendente pra gerar a contingência, mas agora com esse Ajuste SINIEF n. 13/2018 seremos todos obrigados a usar tal recomendação do manual, pois as notas em contingência terão séries específicas...

Por isso uso esse tópico aqui pra perguntar aos que já trabalham com contingência há anos de acordo com o Manual da Contingência(inutilizando ou cancelando a o número da nota pendente de tratamento)... O que vocês fazem quando não obtêm o XML da Inutilização pois houve falha de internet exatamente no momento em que inutilizaram? O que falam para seus clientes/contadores fazer?

Desde já agradeço a atenção de todos

ALA · 8 Março, 2019

Bom dia, doidoph. Tenho outra duvida sobre esse processo de reutilização de numeração. No meu PDV utilizo a seguinte forma para geração de numeração, quando o usuairo clica em abrir CF-e eu gero o numero 01 serie 01. Hai o mesmo tenta transmitir mas ocorre um problema de validação dos dados ou o usuario desiste da compra. Então essa "pre venda" ja esta gravado no BD, eu altero a serie dela para "P", numero 01 serie "P" e cancelo apenas no sistema, não foi transmitido nada para SEFAZ. Na proxima venda eu gero novamente o numero 01 serie 01 para outro cliente outros itens e transmito para SEFAZ.

Vai ficar registrado no meu BD a mesa numeração duas vezes. 001 serie 01, 001 serie P. Será que isso pode dar algum problema com a SEFAZ.. A serie P fica registrada no sistema apenas para controle interno, pois se o caixa realizar esse procedimento e o sistema não deixar registrado pode ocorrer fraudes, do caixa receber e sumir com a venda....

bnobre · 8 Março, 2019

29 minutos atrás, ALA disse:

Bom dia, doidoph. Tenho outra duvida sobre esse processo de reutilização de numeração. No meu PDV utilizo a seguinte forma para geração de numeração, quando o usuairo clica em abrir CF-e eu gero o numero 01 serie 01. Hai o mesmo tenta transmitir mas ocorre um problema de validação dos dados ou o usuario desiste da compra. Então essa "pre venda" ja esta gravado no BD, eu altero a serie dela para "P", numero 01 serie "P" e cancelo apenas no sistema, não foi transmitido nada para SEFAZ. Na proxima venda eu gero novamente o numero 01 serie 01 para outro cliente outros itens e transmito para SEFAZ.

Vai ficar registrado no meu BD a mesa numeração duas vezes. 001 serie 01, 001 serie P. Será que isso pode dar algum problema com a SEFAZ.. A serie P fica registrada no sistema apenas para controle interno, pois se o caixa realizar esse procedimento e o sistema não deixar registrado pode ocorrer fraudes, do caixa receber e sumir com a venda....

Cara... Tu está dando "a volta ao mundo a toa"... Porque você não gera essa numeração SÓ e somente SÓ quando finalizar a venda e for fazer o envio do XML pra autorização??? Muito mais simples

ALA · 8 Março, 2019

Sim, mas estou partindo do ponto que existe hj, se o cx informou um carrinho de 500 itens, a energia cai, quando retorna eu tenho como recuperar a ultima venda pendente e colocar na tela para o cliente continuar de onde parou, por isso gravo os dados..

bnobre · 8 Março, 2019

11 minutos atrás, ALA disse:

Sim, mas estou partindo do ponto que existe hj, se o cx informou um carrinho de 500 itens, a energia cai, quando retorna eu tenho como recuperar a ultima venda pendente e colocar na tela para o cliente continuar de onde parou, por isso gravo os dados..

No meu sistema também eu tenho como recuperar os 500 itens quando a energia cai, mas eu puxo pela chave primária da venda (id_vendas) que é uma coluna diferente da que guarda o número do cupom (cupom)...

A coluna cupom fica NULL aguardando o envio pra SEFAZ, só depois atribuo o número do cupom, chave e XML. Pelo visto você está usando como chave_primária ou referência a coluna cupom, aí seu trabalho fica muito maior.

Editado 8 Março, 2019 por doidopb

ALA · 8 Março, 2019

Isso, mesmo... A duvida que tenho e apenas se a SEFAZ pode reclamar sobre o meu procedimento de serie "P", essa rotina ja esta pronta e funcionando para o SAT,.... A desculpe não ter te respondido pelo ZapZap, mas o meu telefone esta uma "b...."

bnobre · 8 Março, 2019

1 minuto atrás, ALA disse:

Isso, mesmo... A duvida que tenho e apenas se a SEFAZ pode reclamar sobre o meu procedimento de serie "P", essa rotina ja esta pronta e funcionando para o SAT,.... A desculpe não ter te respondido pelo ZapZap, mas o meu telefone esta uma "b...."

kkkkkkkk... sem problemas meu amigo, é sempre melhor conversarmos por aqui pois todos ficam cientes dos procedimentos e podem opinar para melhoria, mas observei que o tópico fugiu um pouco do assunto, por isso sugeri o ZapZap...

Mas sobre a sua dúvida, a resposta é bem simples, a SEFAZ nem vai saber desse "P", você não enviou e muito menos gerou contingência, pra ela tanto faz.

De repente tu só vai ter que explicar para um possível fiscal que visite o seu cliente essa sua lógica do "P" e demonstrar pra ele porque tu faz assim e que não há fraude alguma nisso.

Entrar

Sobre nós...

Tratamento da Contingência - Ajuste SINIEF n. 13/2018

Recommended Posts

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

ALA

bnobre

Crie uma conta ou entre para comentar

Criar uma conta

Entrar

Links Rápidos

Links Rápidos

ACBr Pro

SOBRE

Sobre nós...

Informação Importante