Gabriel Franciscon

O evento de cancelamento vem sem a manifestação do destinatário. Então supondo do exemplo que o destinatário recebe o resumo hoje com a situação da nota autorizada e no outro dia o emitente cancela essa NFe. Será gerado um novo NSU com o evento de cancelamento e o mesmo será disponibilizado para o destinatário mesmo que ele ainda não realizado nenhum evento de manifestação. Como pode ver nesse exemplo: Abaixo vou deixar um trecho de como conseguir capturar o evento de cancelamento no momento que estiver processando os NSU's. for i := 0 to Pred(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count) do begin LDocZip := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip[i] if (LDocZip.schema = schprocEventoNFe) then begin if LDocZip.procEvento.RetinfEvento.tpEvento = teCancelamento then begin Justificativa := LDocZip.procEvento.detEvento.xJust; Data := LDocZip.procEvento.RetinfEvento.dhRegEvento; Protocolo := LDocZip.procEvento.RetinfEvento.nProt; end; end; end;

O método de distribuição só retorna 50 NSU por vez. Ou seja, você precisará executar o mesmo método várias vezes até que o número de NSU que você tem gravado é o mesmo que retorna no MasNSU. De uma olhada nessa resposta que fiz em outro tópico, lá eu coloquei um exemplo de como utilizar o método de DistribuicaoDFe da melhor forma.

No Paraná aceita (mesmo não sendo correto). Você pode fazer o teste em ambiente de homologação no seu estado se autorizar, no ambiente de produção também vai.

É necessário realizar o preenchimento dessas tags. Aqui no Paraná, se enviar sem terá uma rejeição (em ambiente de homologação) - Produção está aceitando com ou sem os campos por enquanto. Um detalhe importante, essas validações são a critério da UF. Por tanto é necessário verificar com a SEFAZ do estado se eles vão ou não aderir essas novas validações. Caso a UF em questão implementará, verifique a propriedade nova no ACBr ForcarGerarTagRejeicao938. Pois em algumas UF mesmo os valores sendo zerados e a tag sendo facultativa é necessário informar. Veja mais detalhes no tópico abaixo. (nesse mesmo tópico tem uma resposta da SEFAZ-MG explicando qual valor informar nessas tag's novas)

Infelizmente pode acontecer, existe um delay entre a SEFAZ-Autorizadora enviar a nota para o Ambiente Nacional e o mesmo disponibilizar a nota com um NSU novo. Quando você consulta uma NFe no portal nacional, observe que no grupo de eventos tem; Data autorização (data que foi enviado o evento/autorização para o órgão responsável (SEFAZ-Estado/A.N) Data inclusão A.N (data que o Ambiente Nacional recebeu a nota/evento) Como você mesmo citou que depois a nota veio com o último NSU. Da mais certeza ainda que demorou para o ambiente nacional receber e liberar. Quando o A.N recebeu a nota, foi criado um NSU e disponibilizado para o download. Ou seja, Você faz uma consulta hoje e pode ter como resultado; (difícil de acontecer, mas não impossível) NSU = 10 - Nota emitida hoje NSU = 11 Nota emitida ontem

Aqui eu salvo tudo... Até mesmo pra ter todo histórico. Vai que amanhã ou depois essa nota é cancelada ou criam uma carta de correção. Dessa forma eu tenho o evento de cancelamento, com a justificativa e a CCe com a correção. Porém falando de arquivo XML em si eu gravo apenas os XML's essenciais: XML completo, CCe e cancelamento. Faço um "mestre-detalhe" nas informações. (como esse exemplo de nota que tem vários eventos)

Use o método DistribuicaoDFePorUltNSU. Nele você passe o NSU = 0. Com isso, você terá como resposta os NSU's dos últimos 90 dias. Detalhe: O DistribuicaoDFePorUltNSU retorna apenas 50 NSU's por vez. Então caso tenha mais do que 50 você terá que executar mais de uma vez. E a cada execução, você passa o último NSU que você recebeu. Aí você me pergunta; como eu sei que tem mais do que 50 pra eu baixar? Simples, existe uma propriedade que consta o número máximo de NSU que tem no WebService. Então resumindo a lógica seria mais ou menos assim: iUltimoNSUGravado := GetUltimoNSUGravado; repeat ACBrNFe1.DistribuicaoDFePorUltNSU(IdEstado, aCNPJ, iUltimoNSUGravado); cStat := ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.cStat; if cStat = 138 then {Documentos encontrados} begin iMaxNSUWebService := StrToIntDef(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.maxNSU, 0); for i := 0 to Pred(ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.docZip.Count) do begin {Aqui você processa NSU por NSU. Inclusive grava o NSU no banco de dados} end; end; iUltimoNSUGravado := GetUltimoNSUGravado; until (iUltimoNSUGravado = iMaxNSUWebService);

O destinatário da nota é OBRIGADO a realizar a manifestação para ter acesso ao XML completo Já a transportadora e/ou citados na tag <AutXML> recebem o XML completo logo de cara, ou seja. Não existe resumo, vai baixar o XML completo. Mesmo que o destinatário não tenha realizado nenhuma manifestação.

Isso mesmo... E sim, é difícil falar com eles

Entrei em contato com a SEFAZ-PR e por telefone tirei 2 dúvidas a respeito ao Boletim Informativo 014/2019: Essas duvidas foram respondidas pela atendente Clarisse que por sua vez consultou um outro setor para retornar com as respostas. 1: Na nota Técnica diz que o prazo para implementação é de até 03/06/2019 porém no B.I diz que será 06/06/2019. Qual será a data correta para o PR? Resposta: Deve-se respeitar a Nota Técnica e que a SEFAZ-PR irá disponibilizar um errata corrigindo essa data. Ou seja, será 03/06/2019! 2: No B.I diz que serão implementadas validações facultativas, como mostra a citação abaixo: Esses dois grupos serão facultativos? ou a frase se refere que a Nota Técnica são facultativos porém a SEFAZ-PR irá sim validar como regra? Resposta: São grupos facultativos na nota técnica porém a SEFAZ-PR irá validar e obrigar esses dois grupos a partir de 03/06/2019.

Em contato com a SEFAZ-PR a respeito desse problema a mesma confirmou que estava com problemas e foi normalizado ontem mesmo às 18h:37min Para as notas que foram rejeitadas por esse motivo, basta corrigir a data de emissão/saída e reenviar a nota.

Primeiro você precisa entender como funciona todo o fluxo desse webservice. O método DistribuicaoDFePorNSU deve ser utilizado quando você já sabe o NSU. Mas imagine o exemplo: Você tem um resumo da nota com o NSU 123456. Você realiza a manifestação do destinatário em cima desse resumo O AN criará um novo NSU, agora para a nota completa. Qual será esse novo NSU? (Não tem como você saber, pois o NSU que o AN irá criar provavelmente não será um número a mais do NSU do resumo. Já que entre o resumo e a manifestação poderá ter outros resumos/notas/eventos) Para você saber qual será o NSU que o AN criou com a nota completa, você só tem 2 caminhos: DistribuicaoDFePorUltNSU (passando o último NSU que VOCÊ tem gravado no seu banco de dados) - Nesse caso você terá como retorno os NSU's que foram gerados após o NSU que você passou (podem vir resumos/notas/eventos) DistribuicaoDFePorChaveNFe - Aqui retorna TODOS os NSU's vinculado a chave de acesso em questão. Se a nota foi manifestada, você terá o NSU com a nota completa, caso contrário não terá. Leia a nota técnica Leia o tópico do Italo Veja o exemplo feito por um membro Veja o exemplo do ACBr: ...\Exemplos\ACBrDFe\ACBrNFe\DistribuicaoDFe.txt

Deem uma olhada nesse post que o @Italo Jurisato Junior criou... Nele explica o funcionamento desse WebService.

Sim! Independente do método utilizado, o destinatário da nota só tem acesso ao XML completo após a manifestação do destinatário.

sendo simples na resposta, sim é possível. Desde que você passe o NSU da nota completa e não do resumo (que é o que está fazendo). Reafirmando ainda que para ter acesso ao XML completo é necessário realizar a manifestação do destinatário antes.

Opa, boa tarde. Você está consultando um NSU de um resumo. Por isso está obtendo o XML de resumo. Primeiramente deverá realizar a manifestação do destinatário. Feito isso o Ambiente Nacional irá gerar um novo NSU, agora com o XML da nota. Ou seja, depois que você realizar a manifestação, um novo NSU será gerado. É a partir desse novo NSU que você vai obter o XML completo da nota fiscal. Eu particularmente não utilizo esse método DistribuicaoDFePorNSU pois eu preciso saber qual será o NSU que eu desejo consultar. Se eu já sei o NSU, significa que eu já tenho os dados pertinente aquele NSU. Aqui eu utilizo o método DistribuicaoDFePorUltNSU, nele é passado um NSU "base" e com o isso retorna os NSU's que foram criados depois do que você passou como base. Exemplo: se eu passar zero, retorna todos os NSU's dos últimos 90 dias. Quando eu recebo esses NSU's eu armazeno no banco de dados e a próxima consulta eu passo o último NSU que eu tenho gravado no banco de dados... Com os NSU's em mãos, realizo a manifestação do destinatário e executo o método DistribuicaoDFePorUltNSU novamente ou o método DistribuicaoDFePorChaveNFe

Teoria 1: Utilizam api's pagas disponibilizadas pela SERPRO Teoria 2: Fazem um "traking" na página de consulta da SEFAZ e monta o XML. Tem um membro aqui no fórum que fez algo assim Mas como eu falei, apenas teorias... Ah, vou deixar um outro tópico aqui onde está sendo discutido isso "Como conseguem?"

Atualmente eu faço isso também... Se der algum exception de conexão com o WebService eu tento novamente. Controlando o tempo de espera para tentar novamente e o quantas vezes irá tentar. Em resumo, a questão de TimeOut é "quase" nula aqui. Por padrão no aplicativo vai os seguintes parâmetros: TimeOut: 30 segundos (sim é um valor alto, mas esse WebService é complicado). Número Tentativas: 10 tentativas. Tempo de espera entre as tentativas: 5 segundos.

Opa, Se você não utiliza capicom e/ou MSXML. Vá até: .../Fontes/ACBrComum/ Abra o arquivo ACBr.inc. Descomente as diretivas abaixo (retirando o ponto do início). Salve o arquivo. De um build no seu projeto. {.$DEFINE DFE_SEM_CAPICOM} {.$DEFINE DFE_SEM_MSXML}

Boa tarde, @Eduardo Santana! Nota fiscal emitida pelo seu próprio cliente: não tem como recuperar apenas com a chave de acesso. É necessário carregar o componente ACBrNFe com todos os dados da nota fiscal novamente. Vou deixar um outro tópico aqui embaixo onde eu explico melhor sobre essa questão, com exemplos:

Exatamente! Inclusive eu acabei de testar aqui e o EMITENTE recebe o "Evento completo" da manifestação do destinatário. E o tpEvento são exatamente esses que você citou. Um detalhe importante: Na prática o método DistribuicaoDFe funciona de forma cronológica, ou seja; sempre terá o resumo da nota fiscal antes de um evento (já que a nota sempre será emitida antes de um evento ser criado). Porém poderá ter casos (esse que você está citando) onde serão retornados eventos que não são relacionados a notas fiscais recebidas e sim emitidas pela própria empresa que está executando o método. Então você deverá tratar esses casos onde o método DistribuicaoDFe retorna apenas um evento e que esse evento se refere a uma uma NFe que o EMITENTE criou e não a uma NFe que foi DESTINADA ao EMITENTE. Exemplo: Empresa ABC emite uma nota para a empresa DFG. Empresa DFG realiza a manifestação do destinatário. Empresa ABC recebe um NSU/evento (através do DistribuicaoDFe) com a manifestação da empresa DFG. O sistema deverá relacionar esse evento com a nota fiscal que foi EMITIDA pela empresa ABC.

Opa, Quando o DESTINATÁRIO da nota realiza o processo de manifestação o EMITENTE (apenas o emitente) da nota recebe um XML contendo evento criado. Podendo assim o EMITENTE controlar se o destinatário da nota fiscal realizou alguma manifestação. Um dica legal é: avisar o emitente caso algum destinatário realize um evento de manifestação com: Desconhecimento ou Operação Não Realizada. Pois nesses 2 casos alguma coisa deu errada.

Aqui temos um verificador de updates rodando com o Windows em todas as máquinas e notificando caso encontre uma nova atualização. (não é necessário estar em todos os PC's. Mas como isso é instalado junto com o sistema e na prática não muda muita coisa. Deixamos assim) Quando o usuário clica para instalar a atualização em uma máquina qualquer, exibe uma janela com as melhorias, novidades, correções... Após o término do download do update, é gravado em um banco de dados especifico e temporário as informações do update, como: Nome, versão/build, data, novidades, MD5. Também gravamos o executável do InstallShield nesse banco (sim, gravamos um arquivo de mais de 700MB). Conforme print abaixo. Quando termina a instalação do update e o usuário inicia o sistema, os scripts necessários para o funcionamento da nova versão/build são rodados no SQL Server. (não precisa ser o servidor) Depois do banco de dados também estar atualizado, as demais máquinas "acusam" diferentes versões entre o executável e o banco de dados, possibilitando a atualização do sistema nesses outros computadores. Nesse momento ao invés de baixar o update novamente, acessamos o banco de dados temporário onde tem o arquivo já baixado e apenas instalamos. Quando o usuário abrir o sistema, os scripts não serão rodados pois já foram. Observação 01: Não importa se mais de um computador baixar a atualização ao mesmo tempo, antes de gravar o arquivo do InstallShield no banco, é verificado se ele já não existe. Observação 02: Os updates são controlados por CNPJ, UF... Já que as vezes é necessário uma correção imediata apenas no estado X. E ainda verificamos se o cliente está apto a receber o update já que o mesmo pode ter problemas financeiros, contrato de manutenção cancelado (não dando direitos a updates de versão, apenas build dentro da versão que o cliente adquiriu). Observação 03: Depois de todos os PC's atualizados, os dados da versão nova e o arquivo da versão são apagado desse banco de dados temporário. Observação 04: Existem atualizações criticas, nesse caso não fica a critério do usuário a instalação. O próprio atualizador, se encarrega de baixar e executar a instalação. Observação 05: Após o término da atualização no PC, solicitamos o registro da licença novamente para controlarmos qual é a versão que o cliente está utilizando. (de forma online e transparente já que as licenças são controladas por um HWID e não por um serial previamente cadastrado). Aqui controlamos por MD5. Ou seja, ao executar o sistema e algum arquivo (bpl, exe, dll..) não bater com o MD5 do executável. Não será possível executar o sistema.

Supondo que o responsável técnico é a empresa que desenvolve o sistema (Software House). Então pela lógica, tem que ter o CNAE de desenvolvimento de software. (Veja mais detalhes sobre quem é o responsável técnico) Observação: Se o Software é da própria empresa, ou seja uma empresa de varejo mas que desenvolve o próprio sistema, logo ela será o responsável técnico e terá que ter um CNAE de desenvolvimento* *Pela lógica a empresa tem que ter um CNAE conforme a atividade que exerce. Essa possível validação poderá acontecer sim mas irá variar de estado para estado. No estado do Paraná já existe uma verificação em relação ao CNAE, conforme o exemplo abaixo. Exemplo: Atualmente no Paraná para emitir qualquer documento fiscal eletrônico o cliente deve informar qual é o sistema que está utilizando para SEFAZ (mais conhecido como Pedido de uso). Depois do pedido de uso realizado, a software house tem que realizar o "aceite" desse cliente. Apenas após esse procedimento o cliente consegue emitir um documento fiscal. Ou seja, na SEFAZ-PR já existe um cadastro de; Fornecedor de software (software house); Sistemas desenvolvidos pelo fornecedor de software; E para se tornar um Fornecedor de software no PR deve sim ter CNAE relacionado a desenvolvimento de sistemas, conforme as regras. Como provavelmente aqui no PR o cadastro do responsável técnico (pessoa que responde pelo sistema dentro da empresa que fornece o software) será vinculado ao fornecedor de software. A questão de ter um CNAE especifico já será verificado quando a software house for cadastrada na SEFAZ e não quando for cadastrado um responsável técnico.

Opa! Se a NFe foi autorizada pela SEFAZ não existe nenhum problema no seu software ou no ACBr. Como você já fez o teste de enviar o XML baixado pelo portal da SEFAZ e mesmo assim deu problema. Significa o site/sistema da GoodCard não está preparado para aceitar NFe com esses campos novos. Em poucas palavras, os schemas que a GoodCard está utilizando são obsoletos.