Italo Giurizzato Junior

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

Boa tarde Alexandre, Notei dois erros 1. o XML do CTe foi enviado segundo a versão 4, já o envio da carta de correção esta na versão 3. 2. no XML do CTe não existe o grupo do Recebedor, somente o grupo de Remente e do Destinatário. Acho que isso explica o erro que você esta tendo.

Boa tarde Gladston, As mensagens de erro não tem nada haver com o ItemListaServico. E sim esta se referindo aos dados informados em: NFSe.Servico.CodigoCnae e NFSe.Servico.CodigoTributacaoMunicipio.

Wesley, Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Boa tarde Tiago, Já esta no SVN.

Boa tarde Paulo, Já esta no SVN.

Boa tarde João, Já esta no SVN.

Boa tarde Felipe, Já esta no SVN.

Boa tarde Jaidomini, Já esta no SVN.

Boa tarde Silva, No arquivo (33-lista-nfse-sinc.xml) temos o numero do protocolo que é 33/2023 que você deve usar para consultar o lote, com isso acredito que será retorna do o XML da NFS-e.

Boa tarde Sandro, Você esta usando o Fast ou o Fortes Report?

Boa tarde Wesley, Já inclui na minha lista de tarefas para analise do problema. TK-4393

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

Boa tarde Paula, Achei, além deles incluírem a tag ValorTotalRecebido, trocaram a tag MunicipioPretacao de lugar. Já inclui na minha lista de tarefas para atualizar os schemas e fazer as devidas alterações no componente. TK-4390

Boa tarde Souza, Esse erro é devido a instabilidade na API do Padrão Nacional. Os caras não esperavam uma quantidade gigantesca de emissões logo no primeiro dia.

Bom dia Souza, Faz quanto tempo que você não atualiza todos os fontes de todas as pastas do ACBr? Ocorreu uma atualização dos schemas do padrão nacional no dia 02/01/2023. Esse erro de validação que você esta tendo é porque esta usando schemas antigos.

Bom dia Max, O componente ACBrNFSeX, a DLL ACBrLibNFSe e o ACBrMonitor Plus já estão aptos a emitir NFS-e segundo o Padrão Nacional. No caso do Padrão Nacional não temos um WebService Soap e sim uma API Rest. Independente da forma como é recepcionado o XML do Rps ou DPS (no caso do Padrão Nacional) as 3 soluções do ACBr estão preparadas para se conectar com um WebService ou API Rest.

Boa tarde Rafael, Já esta no SVN.

Boa tarde Antonio, Favor anexar a unit alterada para que possamos validar ela e estando tudo OK enviaremos para o SVN. Desde já muito obrigado pela colaboração.

Boa tarde Silva, Favor configurar o componente para salvar os arquivos Soap. Faça um novo teste e anexe os XMLs (soap) para que possamos analisar.

Boa tarde Wesley, Noto que o envio do Rps ocorreu, mas ele foi rejeitado pelo provedor por conter informações incorretas. Cabe agora você informar os dados corretos para que o RPS seja processado com sucesso. Lembre-se que no programa exemplo, mais precisamente na procedure que alimenta o componente, as informações são fictícias. Por conta disso o retorno com esses erros são normais. Por outro lado se você informar os dados corretos, com certeza esses erros não vão ocorrer.

Boa tarde Brajan, Esse prestador já chegou a emitir alguma nota via Portal? Se não emitiu, favor emitir. Estou achando que sem se cadastrar no Portal para emitir nota via Web, você não consegue emitir via API. Em contato com o pessoal que esta cuidando da API anotaram o seu problema, mas já me adiantaram que só vão conseguir parar para analisar só segunda feira. Paciência.

Paula, Uma coisa é uma nota emitida pelo Site, outra coisa é uma nota emitida pelo webservice. Esses Schemas não verdade são da versão 1. E neles não consta essa tag. Os caras devem ter pego os schemas errados e zipados como sendo os da versão 2. Favor entrar em contato com eles e questiona-los se realmente existe uma versão 2 dos schemas.

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

Boa tarde Jéter, Já esta no SVN.