Italo Giurizzato Junior

Boa tarde @johni, Que cabeçalho? Você se refere a declaração de encoding: <?xml version="1.0" encoding="UTF-8"?> ? Se sim, onde ele deve ser informado?

Boa tarde Diogo, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e inicie os testes de preferencia com o programa exemplo.

Boa tarde Felipe, Já implementei o provedor e enviei para o SVN. Essa implementação só foi feita no novo componente: ACBrNFSeX. Atualize todos os fontes de todas as pastas e reinstale o ACBr. Abra o arquivo ACBrNFSeXServicos.ini e veja o que eu escrevi na seção que se refere a Uberlândia/MG Caso deseje realizar testes, no inicio desse arquivo INI existe uma instrução de como proceder.

Olá Pessoal, O componente ACBrNFSeX conta com mais dois provedores: Isaneto que segue a versão 2.03 do layout da ABRASF e até o momento atende a cidade de Castanhal/PA e PRODAUB que segue a versão 2.04 do layout da ABRASF que atende a cidade de Uberlândia/MG (o ambiente de produção vai ser liberado em 01/03/2024).

Bom dia Felipe, Esse é o Schema (XSD) e não o XML. Fique tranquilo, achei o problema aqui.

Bom dia Sergio, O componente ACBrNFSeX já esta atualizado para essas duas cidades (Vila Velha e Cariacica). Precisamos saber das URLs da cidade de Serra/ES. O manual que você anexou de Vila Velha para nós não tem utilidade, pois ele se refere a emissão da NFS-e via site e não via webservice, não existe sequer as URLs do webservice, por outro lado o manual de Cariacica traz as URLs do webservice.

Diogo, Se você conseguir a lista de cidades atendidas pelo provedor com as respectivas URLs seria muito bom.

Bom dia Diogo, Muito obrigado pela colaboração, já inclui na minha lista de tarefas para implementar o provedor. TK-4992

Boa tarde @Vagner Amorim, Complementando o que o @Juliomar Marchetti já lhe passou, o XML da NFS-e é gerado pelo webservice do provedor e baixado por uma consulta por exemplo. Uma coisa é a informação constar no XML e o componente não estar lendo ela, outra coisa é o XML não ter a informação. Se o XML da NFS-e esta faltando informações, você deve entrar em contato com a prefeitura/provedor e expor o problema.

Felipe, Veja se você consegue com o pessoal dessa empresa um exemplo de de envio onde consta o XML do cabeçalho e de dados (XML do RPS).

Boa tarde Felipe, Muito obrigado pela colaboração, já incluir na minha lista de tarefas para implementar o provedor. TK-4991 A implementação do novo provedor será realizada somente no novo componente ACBrNFSeX. Se você ainda usa o componente antigo, lhe convido a iniciar os testes com o novo componente de emissão de NFS-e: ACBrNFSeX O componente antigo: ACBrNFSe não está mais tendo manutenção. Faça os testes usando o programa exemplo do novo componente. Manual de Migração https://www.projetoacbr.com.br/forum/topic/63017-manual-de-migração-para-o-novo-componente-de-emissão-de-nfs-e/

Boa tarde Glauber, Pela URL o provedor é Pronim. Você sabe me informar qual é a versão utilizada por essa cidade?

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

Boa tarde Marcos, Os programas exemplos são uma fonte de informações de como proceder. Em vez de você ficar quebrando a cabeça tentado descobrir como é que a coisa funciona, porque não dar uma olhadinha nos programas exemplos? Não sei qual é a linguagem que você trabalha, pode ser que até tenha um programa exemplo com a sua linguagem, caso tenha é só estudar como é feito e replicar na sua aplicação.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Bom dia Kleber, O programa exemplo não é um emissor de CT-e. Ele tem por finalidade lhe mostrar como configurar o componente, como alimentar o componente e uma codificação bem simples de como usar cada método implementado no componente. O programa exemplo não se utiliza de um banco de dados, é por isso que a configuração do mesmo é salva em disco em um arquivo INI e os dados fictícios passados para o componente estão presentes no código em vez de ler de uma tabela do banco de dados. Por ser dados fictícios é de se esperar que o CT-e gerado e enviado para a SEFAZ seja rejeitar. Uma coisa posso lhe garantir o componente funciona, basta configurar ele corretamente e passar os dados corretos. Dica, ao testar em homologação só informe a chave de uma NF-e se esta tenha sido também emitida em homologação, se você não tiver uma, em vez de informar os dados da NF-e (chave) informe os dados de um outro tipo de documento (infOutro) como por exemplo uma carta remessa de mercadoria. Vide o Manual que contem o layout do CT-e.

Bom dia @m5sistemas, Quanto a primeira postagem, caso não queira baixar todos os documentos que com certeza vai levar um tempo considerável, uma vez que o serviço de DistribuicaoDFe por Ultimo NSU retorna um lote de até 50 documentos. Lembrando que esses Documentos podem ser XML de NF-e e também podem ser XML de Eventos, eventos estes indicando que a nota foi cancelada, eventos de registro de passagem do caminhão por um local como fronteira entre Estados ou Pedágio ou Fiscalização Eletrônica. Se você dividir 31690 por 50 vai ter uma ideia de quantidade de vezes que deverá executar o DistribuicaoDFe para baixar tudo e considere um tempo de uns 3 minutos entre uma execução e outra, você vai ter uma ideia do tempo que vai levar. Eu em particularmente não vejo problema em baixar os 100 últimos por exemplo. Quanto a sua segunda postagem, lembre-se que se a empresa ficar 60 dias ou mais sem usar o serviço de DistribuicaoDFe, ao usar vai ser retornado essa mensagem mesmo tendo documentos a serem baixados. A recomendação da SEFAZ é que aguarde 1 hora e tente novamente. Dica importante: Armazene no Banco de Dados a data e hora e o status da ultima execução do DistribuicaoDFe, desta forma você consegue calcular o tempo já decorrido da ultima execução em relação a nova solicitação de execução. Com isso você pode impedir que o usuário execute novamente antes do prazo estabelecido. Você pode estabelecer esses prazos. Exemplo: Se retornar que não tem mais documentos, você define um prazo de 65 ou 70 minutos, uma margem de segurança de 5 a 10 minutos a mais do exigido pela SEFAZ. Se retornar os documentos e o ultNSU é menor que maxNSU, você define um prazo de 3 ou 5 minutos. Se retornar os documentos e o ultNSU é igual a maxNSU, você define um prazo de 65 ou 70 minutos. Com essas regras para a próxima execução o seu cliente nunca vai ser barrado por consumo indevido. O status que eu me refiro na dica é: 1 - aguardar tempo curto (3 ou 5 minutos) 2 - aguardar tempo longo (65 ou 70 minutos) Espero ter ajudado.

Bom dia Bruno, Já esta no SVN.

@xim.logan, Os da imagem é o retorno da consulta e não do envio.

@xim.logan, Você não tem os XMLs de envio e retorno salvo em disco?

Boa tarde Bruno, Muito obrigado pela colaboração, já inclui na minha lista de tarefas.TK-4988

Boa tarde @xim.logan, O envio do RPS foi usando o modo de envio em Lote Assíncrono, ou envio de Lote Síncrono ou Unitário? No primeiro modo você tem como retorno o numero do protocolo, de posse do protocolo podemos Consultar o Lote. No segundo e terceiro modos de envio, já temos no retorno o resultado do processamento. Se o numero/série do RPS estão corretos e ao Consultar a NFS-e por RPS, você tem como retorno o erro que acusa que o RPS não se encontra na base de dados do provedor, isso significa que esse RPS foi processado com falhas. Para saber quais são essas falhas (erros) precisamos dos XMLs de retornos.

Bom dia @xim.logan, Esse 52 deve ser de alguma nota que você carregou antes. Veja o primeiro erro que aparece na lista de erros, diz que não encontrou o RPS referente ao numero informado.

Bom dia Lucas, Chegou a testar com o programa exemplo do componente ACBrNFSeX? Caso não tenha feito um teste de envio com o programa exemplo, faça. Configure o mesmo para salvar os Envelope Soap.

Entre em contato com eles e pergunte sobre as URLs de homologação e de produção para emissão das notas via webservice (não serve as de via site). Questione se ocorreu também a troca de empresa contratada pela prefeitura ou se continua a mesma (SmarAPD).