Italo Giurizzato Junior

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

Bom dia Ricardo, Se você esta com o componente configurado para usar o libWinCrypt experimente mudar para libCapicom e faça um novo teste de cancelamento.

Bom dia, Chegou a verificar junto a prefeitura se a mesma não trocou de provedor? Ou se ocorreu a troca de URL?

Bom dia Alexandre, A solução é muito simples. Como não é você que paga o provedor e sim a prefeitura, o jeito é pedir para os seus clientes (que emitem a NFS-e) protocolar uma reclamação na prefeitura. Uma coisa é você reclamar para corrigir a sua aplicação, outra coisa é dezenas de empresas que usam a sua aplicação reclamarem com a prefeitura. Você vai ver que dessa forma a coisa vai ser resolvida o mais rápido possível.

Bom dia Filipe, É muito estranho validar o XML contra o Schema usando o libCapicom e não validar usando o libWinCrypt. É sabido que erros podem ocorrer usando o libOpenSSL, mas com o libWinCrypt não. Qual é a mensagem exata do erro?

Boa tarde Magnu, Foram feitas melhorias na impressão do DABPE, na próxima versão do Monitor vai constar as alterações. Sendo assim, gostaria que você atualiza-se o Monitor na segunda-feira dia 30 e faça novos testes. Gostaria da sua opinião.

Bom dia Adryelle, Tenta entrar em contato com o provedor e questione se essa situação é valida para todas as cidades atendidas por eles. Desde já muito obrigado.

Bom dia Filipe, Se manter o valor 1, ou seja, validar antes do envio o que ocorre? O XML esta sendo gerado de forma diferente para que possa ser processado com sucesso pelo provedor, portanto o schema esta errado?

Sandro, O provedores (empresas contratadas pelas prefeituras) não dão o valor que deveriam ao ambiente de homologação. Temos provedores que só funciona de forma decente o ambiente de produção, sem falar naqueles que só possuem o ambiente de produção. Infelizmente.

Bom dia Lucas, As BPL que se referem ao ACBr, por exemplo a que aparece na mensagem de erro: ACBr_CTeDACTeRL.bpl

Bom dia Graça, Posso estar enganado, mas a resposta a sua primeira e segunda pergunta esta no seguinte trecho: "o cadastramento da Operação de Transporte e correspondente geração do CIOT é aplicável a todos os transportadores"; No que se refere a quantidade de veículos, segundo a resolução temos: XIII - Transportador Autônomo de Cargas - TAC: pessoa física que exerce, habitualmente, atividade profissional de transporte rodoviário remunerado de cargas, por sua conta e risco, como proprietária, coproprietária ou arrendatária de até três veículos automotores de cargas; e XIV - TAC-equiparado: as Empresas de Transporte Rodoviário de Cargas - ETCs que possuírem até três veículos automotores de carga em sua frota registrada no RNTRC, considerados na data do cadastramento do CIOT ou, na sua ausência, no início da viagem, e todas as Cooperativas de Transporte Rodoviário de Cargas - CTCs. No meu entendimento veiculo automotor é aquele que é capaz de se locomover por meios proprios, se ser puxado ou empurrado. Desta forma um caminhão conectado a uma carreta, apesar de possuírem placas diferentes temos somente um veiculo automotor, o caminhão.

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.

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