Italo Giurizzato Junior

Bom dia, A data e hora de emissão do CT-e é uma coisa, a data e hora da entrega da mercadoria é outra e a data e hora do envio do evento de comprovante de entrega também é outra. Vamos a regra de validação M08: Rejeição 873 - Rejeitar se a data/hora do hash do comprovante da entrega for inferior a data de emissão do CT-e ou superior a data/hora atual. É obvio que a data e hora do hash do comprovante da entrega não pode ser inferior a data de emissão do CT-e viso que primeiro temos que emitir o CT-e, transportar a mercadoria e realizar a entrega e esse processo pode levar dias. E também não pode ser superior a data e hora atual, se a data atual é 26/12/2019 10:06 não faz sentido a data e hora do hash do comprovante de entrega ser posterior, pois neste caso você estaria informando uma data e hora futura. No evento note que temos 3 data e hora: dhEvento - data e hora que o evento foi gerado e enviado para a SEFAZ; dhEntrega - data e hora que a entrega foi realizada, ou seja, a mercadoria foi entregue para o destinatário; dhHashEntrega - se refere a data e hora que foi gerado o hashEntrega. Como o evento é gerado e enviado após a entrega e para ser enviado o evento é preciso gerar o hashEntrega então temos o seguinte: dhEntrega < dhHashEntrega < dhEvento <= data e hora atual (data e hora do relógio do computador).

Bom dia Davidson, Se você tem o XML assinado que foi enviado mas por algum motivo o protocolo de autorização não foi retornado e consequentemente o XML esta sem essa informação, a solução é muito simples. 1. Carregar o XML usando o método LoadFromFile (se o XML esta salvo em disco) ou LoadFromStream (se o XML esta salvo no banco de dados). 2. Executar o método Consultar. Se executarmos o método Consultar sem antes carregar o XML da nota, não vai ocorrer a atualização do mesmo. Se a intensão é atualizar o XML através do método Consultar, é preciso carrega-lo antes e o mesmo tem que estar assinado.

Bom dia Sandro, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção de apagar arquivos antigos marcada? Se sim, esta usando o programa exemplo? Se esta usando a sua aplicação, você esta usando os arquivos INI atualizados que se encontra na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI ?

Bom dia Fernando, O XML que você anexou não consta o protocolo de autorização e foi enviado para o ambiente de homologação. Ficaria melhor documentado se você anexasse um XML enviado para o ambiente de produção e que contenha o protocolo de autorização e a portaria SECEX Nº 349, DE 21 DE MARÇO DE 2017 . Outra coisa importante, no Manual de Orientação ao Contribuinte Versão 7.02 - Visão Geral, página 129 temos a regra I53-10 que diz: Número do registro de exportação inválido (tag:detExport/exportInd/nRE) Essa regra se aplica somente ao modelo 55 a sua implementação é obrigatória nas SEFAZ-Autorizadora e a nota é rejeitada com a mensagem: 341 - Rejeição: Número do registro de exportação inválido. Note que a regra não diz: Se informado o nRE, ...... Realmente existe uma discordância entre o Manual e o Schema. Portanto levando em consideração o Manual e a regra de validação, o nRE deve ser informado sim, ou seja, ele é obrigatório, mas ainda não achei nada onde diz que ele por ser composto por zeros, pelo contrario. Na NT 2013/005 versão 1.00 e 1.01 apresenta a composição do nRE: A composição deste identificador é: "AANNNNNNNSSS", onde: AA = Ano corrente da geração do documento; NNNNNNN = Número sequencial dentro do Ano (7 dígitos); SSS = Sufixo do RE. Número sequencial que serve para identificar uma série de RE, que foram identificados pelo mesmo RE (anexos ou adições). O RE original é sempre identificado com o sufixo "001". Validação Possível: Campo Numérico, com 12 posições (considerar que o Ano pode começar por "zero"); AA: Ano maior do que o Ano atual, ou muito antigo (considerar tolerância de 1 ano em relação ao Ano atual); SSS: Deve ser maior do que 0 (zero). Com base nas validações acima poderíamos ter um nRE igual a 000000000001 mas não 000000000000. Fico com receio em aceitar a sua contribuição e acabar gerando um efeito colateral para outras UF.

Bom dia, Qual é a cidade para qual você deseja emitir a NFS-e?

Bom dia Alex, Que eu saiba não existe nada que nos retorne o numero do ultimo lote enviado. Acredito que a solução seria entrar em contato com o provedor e solicitar o numero do ultimo lote enviado.

Bom dia Paulo, Isso é muito estranho, pois as linhas que geram essa tag é a mesma para ambos os ambientes.

Bom dia Joabe, O componente responsável por imprimir o DACTE feito em Fortes Report se encontra na pasta: ...\Fontes\ACBrDFe\ACBrCTe\DACTE\Fortes Note que não existe nenhuma Unit que traga alguma menção a Paisagem somente Retrato, por exemplo: ACBrCTeDACTeRLRetrato.pas. Apesar de existe a propriedade de configuração tiPaisagem não temos implementado esse modelo. Se desejar contribuir com o projeto e implementar ficaremos gratos.

Bom dia, A tabela completa das rejeições e suas descrições estão nos manuais, que eu saiba não existe uma tabela em TXT ou Excel para facilitar a sua importação para um banco de dados.

Bom dia Jonathan, É uma NF-e ou NFC-e? Qual é o valor que você atribuiu para indFinal ?

Bom dia Rene, Por favor entre em contato com a Prefeitura e solicita um XML de exemplo. O XML que necessito é o que contem o a tag Envelope e não o XML do RPS, pois este o componente esta gerando e validando sem nenhum problema.

Ricardo, Nos arquivos em anexos não tem um XML de exemplo de cancelamento. Dessa forma fica difícil de descobrir o que esta errado.

Boa tarde Rogério, Já esta tudo no repositório.

Boa tarde Fernando, Vamos procurar seguir as regras do fórum, se tratando de XML favor anexar e não postar como você fez. Pois dessa forma fica complicado para quem pretende lhe ajudar poder baixar o XML para fazer uma analise. Desde já muito obrigado pela compreensão.

Boa tarde Junior, Com o EscPos o QR-Code é impresso normalmente, temos relatos no fórum de outras pessoas já utilizando em produção em seus clientes. Caso você queira contribuir com o projeto e criar o componente para imprimir o DABPE em Fortes e ou Fast ficaremos gratos.

Boa tarde Adryelle, Você me dizer se a geração da alíquota mesmo zerada tem que ser gerada a TAG da mesma para todas as cidades atendidas pelo provedor Pronimv2 ?

Boa tarde Filipe, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Boa tarde Marcos, Os arquivos se encontram na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI Você atualizou todos os fontes de todas as pastas?

Boa tarde Daniel, O conteúdo do XML que você anexou na sua primeira postagem se refere a consulta que você fez usando o componente? Pois olhando para o XML e para o exemplo que agora você anexou eles são iguais. Inclusive as informações referente a assinatura digital.

Boa tarde Alex, Eu usaria um numero de lote sequencial. Outra coisa quem gera o numero da NFS-e é o provedor e quem gera o numero RPS (que deve ser sequencial) é a sua aplicação. Sendo assim você deve usar o numero do RPS como numero do Lote e não da nota que foi retornada pelo envio anterior. Porque devemos usar um numero sequencial para o Lote independente do numero do RPS? Simples, tem provedor que permite o envio em lote de até 50 notas, neste caso teríamos por exemplo: Lote = 1 contendo os RPS de números 1 até 50 Lote = 2 contendo os RPS de números 51 até 100 e assim por diante.

Bom dia Alexandre, Entre em contato com eles e pede esclarecimento desse erro.

Bom dia Ricardo, Pelo Schema a assinatura esta sendo gerada no local correto. É preciso descobrir o porque a validação acusa que a assinatura é invalida.

Bom dia Rogério, Muito obrigado pela colaboração, quanto a unit pcnGerador já foi enviada para o repositório. Com relação a unit pnfsNFSeW_SP ainda vou verificar se existem mais contribuições referente a NFS-e para poder enviar tudo de uma vez.

Bom dia a todos, Favor atualizar os fontes e façam novos testes.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.