bnobre

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.

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

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

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?

Se não houver problemas, quero deixar o tópico aberto para que alguém que emita NFCes e siga a orientação do Manual de Contingência, me diga ... Como lidam com os contadores/clientes nos casos de Inutilizações ocorridas sem XML por falha de internet? Desde já agradeço a atenção de todos

Pena que pelo site não tem como resgatar o XML, ou tem?

Na verdade é NFCe Italo... E como eu disse não seria pra envio de nota e sim pra Inutilização, afim de realizar o procedimento recomendado pelo Manual de Contingência.

Olá Italo O fato é que mesmo se o componente tivesse a opção de salvar os eventos atrelados a nota de forma separada, a inutilização não seria um deles. A contingência foi criada para suprir necessidades oriundas de falhas da internet e existe um manual de contingência orientando como a mesma deve ser realizada. A ironia é que o manual manda realizar um procedimento (inutilizar a faixa de numeração) que em caso de falha de internet temos que "sentar e chorar"... Eles não resolveram nada e criaram um outro problema, grande problema... Pois a numeração vai pular, o contador vai me perguntar porque pulou e eu terei que dizer que houve uma inutilização e o XML se perdeu... Como os contadores de seus clientes reagem quando vocês dizem isso??? E seus clientes?

Entendi... O problema é o seguinte... Estou montando uma rotina para contingência seguindo as orientações do manual (inutilizando ou cancelando a nota que ficou pendente de tratamento). Mas sabemos que problemas de internet ocorrem, e se no momento em que eu for inutilizar a faixa de numeração da nota pendente eu tiver uma falha na internet, a inutilização pode ocorrer e eu não conseguir obter o retorno do XML da mesma, meu aplicativo vai achar que a inutilização não ocorreu, vai tentar inutilizar dinovo e aí BABOU... Faixa já inutilizada e não tenho o XML. Só vai me restar marcar que a Inutilização ocorreu sem puxar o XML, o que está longe de ser o ideal. Como você trata essas ocorrências?

Olá a todos, Supondo que enviei um evento de cancelamento de uma NFe/NFCe, o cancelamento foi realizado e não obtive o retorno do XML do mesmo por falha de internet, como recuperar esse XML? E no caso de uma inutilização de faixa realizada e sem retorno do XML da mesma por falha de internet, como recupero esse XML? Desde já agradeço a atenção de todos

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?

Olá meu amigo... Sou do RJ e estou enviando normalmente o cancelamento por substituição.

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?

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?

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?

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

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?

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): 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

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.

Olá a todos... Com essa Nota Técnica 2018.005 - v 1.00 - Publicada em 02/01/2019 poderá vir a ser exigido por alguns estados esse tal CSRT. Meu receio é voltar aquela burocracia e gastos para a homologação do software como na época do PAF-ECF. Alguém tem alguma notícia desse sentido aqui no RJ? Desde já agradeço a atenção de todos

Então, foi isso que eu pensei quando eu vi UN1, pensei que era um padrão DELE, porque não tem lógica UN1. Já, logo em seguida, quando eu vi o CX6 eu pensei que realmente poderia ser "Caixa com 6 unidades" mesmo antes de você me enviar essa planilha, mas o "UN1" acabou com toda a lógica de ficar mais organizado como você citou. De qualquer forma agradeço a dica e ajustarei o meu banco. PS: É o primeiro caso de XML com números nas unidades de medida que surge pra mim... Com você é mais frequente?

Putz... Essa não sabia, vou ajustar meu banco... Obrigado pela dica BigWings... Mas seguinte, se o número ao lado quer dizer a quantidade como no caso das caixas... Então o que quer dizer UN1??? Unidade com 1 Unidade???

Olá a todos, Hoje fui surpreendido com um cliente que tentava importar os produtos que comprou do seu fornecedor através do XML, pois no mesmo a tag <uCom> vinha com valores como os abaixo: UN1 PC40 PC20 CX6 PC12 PC4 PC6 Observem que são as unidades tradicionalmente usadas (UN, PC e CX) seguidas de um número inteiro. Meu sistema não aceitou pois trabalho apenas com uma coluna unidade de 2 caracteres e tive que fazer uma adaptação no código para que puxasse somente as letras. Com isso resolvi o problema, mas surgiu a dúvida: Alguém sabe porque essa empresa ou qualquer outra usaria unidades com números ao lado? Deve haver uma razão interessante, pois a receita aceita (e eu não sabia até então) tais valores no XML. PS: O fornecedor em questão é a DPC DISTRIBUIDOR ATACADISTA S/A.

Perfeito meu amigo, obrigado. Que pena que a NT deixou "no ar", pois "outro documento legal" ficou muito genérico. Na emissão das NFC-es em meu PDV eu pretendo gravar em uma coluna chamada "documento" o CPF, CNPJ ou idEstrangeiro do cliente. Como estou usando apenas uma coluna para gravação do documento, se eu precisar em uma busca diferenciar o CPF do CNPJ basta olhar o tamanho, mas para o idEstrangeiro não tem como diferenciar já que ele pode ter qualquer valor de 5-20.

Eu já tinha lido esses textos, infelizmente não constam quais documentos podem ser usados para o preenchimento da tag idEstrangeiro na emissão de uma NFC-e.