Italo Giurizzato Junior

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.

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.