Italo Giurizzato Junior

Boa noite Hugo, As URLs de produção e homologação da referida cidade que usamos no componente ACBrNFSeX são: [2408003] Nome=Mossoro UF=RN Provedor=Tinus ProRecepcionar=http://www.tinus.com.br/csp/mossoro/WSNFSE.RecepcionarLoteRps.cls ProConsultarSituacao=http://www.tinus.com.br/csp/mossoro/WSNFSE.ConsultarSituacaoLoteRps.cls ProConsultarLote=http://www.tinus.com.br/csp/mossoro/WSNFSE.ConsultarLoteRps.cls ProConsultarNFSeRps=http://www.tinus.com.br/csp/mossoro/WSNFSE.ConsultarNfsePorRps.cls ProConsultarNFSe=http://www.tinus.com.br/csp/mossoro/WSNFSE.ConsultarNfse.cls ProCancelarNFSe=http://www.tinus.com.br/csp/mossoro/WSNFSE.CancelarNfse.cls ProGerarNFSe=http://www.tinus.com.br/csp/mossoro/WSNFSE.GerarNfse.cls ProRecepcionarSincrono=http://www.tinus.com.br/csp/mossoro/WSNFSE.RecepcionarLoteRpsSincrono.cls ; HomRecepcionar=http://www2.tinus.com.br/csp/testemos/WSNFSE.RecepcionarLoteRps.cls HomConsultarSituacao=http://www2.tinus.com.br/csp/testemos/WSNFSE.ConsultarSituacaoLoteRps.cls HomConsultarLote=http://www2.tinus.com.br/csp/testemos/WSNFSE.ConsultarLoteRps.cls HomConsultarNFSeRps=http://www2.tinus.com.br/csp/testemos/WSNFSE.ConsultarNfsePorRps.cls HomConsultarNFSe=http://www2.tinus.com.br/csp/testemos/WSNFSE.ConsultarNfse.cls HomCancelarNFSe=http://www2.tinus.com.br/csp/testemos/WSNFSE.CancelarNfse.cls HomGerarNFSe=http://www2.tinus.com.br/csp/testemos/WSNFSE.GerarNfse.cls HomRecepcionarSincrono=http://www2.tinus.com.br/csp/testemos/WSNFSE.RecepcionarLoteRpsSincrono.cls

Boa noite Gabriel, O provedor Bauhaus pelo fato dele exigir que os dados do Rps sejam enviados em Json e não em Xml o mesmo esta em desenvolvimento. Caso queira contribuir com o desenvolvimento do mesmo ficaremos gratos. Lembrando que as implementações tanto para gerar o Json quanto para ler o seu conteúdo tem que serem compatíveis com o Lazarus e com Delphi 7 em diante.

Boa noite Ramalho, Esse é o XML de envio do lote que contem o Rps, se eles pediram o XML de envio é esse ai, pois ele contem o Rps e o Lote ambos assinados.

Boa noite Danio, O pedido de cancelamento é gerado e validado conforme os schemas disponibilizados pelo provedor SpeedGov. Se o XML esta errado então precisamos dos schemas atualizados desse provedor para que possamos identificar o que precisa ser alterado. Sem os novos schemas não temos como adivinhar o que esta faltando ou o que esta a mais no XML do pedido de cancelamento.

Boa noite, O Rps de numero 149 foi enviado para o webservice do provedor? Se sim qual foi o retorno? Você poderia anexar os XMLs de envio e de retorno desse Rps para o webservice?

Boa noite Fernando, Por que você esta querendo ler esse arquivo? Esse arquivo não deve ser distribuído junto com a aplicação. Na pasta dos fontes do componente que originalmente consta esse arquivo, você notou que existe também o arquivo de mesmo nome mas com a extensão RES ? O arquivo ACBrNFSeXServicos.res é incorporado ao executável da aplicação assim que ela é compilada, pelo menos é assim que funciona do Windows. O arquivo ACBrNFSeXServicos.ini esta no formato ANSI, talvez ele deveria esta no formato UTF-8.

Boa noite Dercide, Muito obrigado pela colaboração, já inclui na minha lista de tarefas. TK-2341

Boa noite Tiago, Isso esta ocorrendo com o novo componente: ACBrNFSeX ? Esse erro também ocorre usando o programa exemplo? Se sim, quais são as configurações da aba Certificado e WebService?

Boa noite Flavio, Analisando os XMLs que você anexou notei o seguinte: 1. O lote foi enviado e o numero do protocolo foi retornado. 2. A consulta ao lote foi executada informando o numero do protocolo e foi retornado a situação 2 que indica que o lote esta na fila de processamento, inclusive consta na tag <Mensagem> a informação que o Rps ainda não foi convertido em NFS-e e na tag <Correcao> um pedido para que se aguarde um tempo e faça uma nova consulta. Eu não sei se você realizou um nova consulta ou se depois dessa consulta acessou o site da prefeitura e constatou que o Rps foi rejeitado pelo fato do numero do mesmo ser inválido. Mas uma coisa é certa, se o numero do Rps é inválido com certeza ele esta fora de uma sequencia ou o provedor exige que seja liberado uma faixa de numeração, por exemplo: o contribuinte solicita a liberação de 1 a 1000 (numeração do Rps) quando emitir o Rps de numero 1000 deve-se solicitar a liberação de 1001 até 2000 e assim por diante. Vai ser necessário entrar em contato com a prefeitura ou com o provedor para que eles digam o real motivo dessa rejeição.

Boa noite Danilo, Onde aparece essa mensagem, no XML da NFS-e ou no DANFSE?

Boa tarde, Esta semana do dia 7 pretendemos liberar uma alteração no componente que acreditamos que vai resolver o problema de codificação. Antes estávamos trabalhando em uma única rotina para resolver o problema de todos os provedores, mas vimos que o caminho não estava correto, mudamos de ideia e agora cada provedor vai ter a sua própria rotina para fazer os devidos ajustes. Como isso, o ajuste promovido no provedor A não vai gerar um efeito colateral nos demais provedores.

Boa tarde Douglas, O meu receio é que com isso o programa exemplo se torne um emissor de NFS-e que por sinal não é o objetivo dele.

Boa tarde Chico, Muito obrigado pela colaboração, mas me diga uma coisa esses espaços reservados para impressão das informações "pintados" de cinza, acredito que algumas transportadoras não vão gostar pois isso ao meu ver vai acarretar um consumo maior de toner, você não acha?

Boa tarde Regis, Vou precisar o XML do Rps e o da NFS-e, para poder analisar.

Boa tarde, Já inclui na minha lista de tarefas para analisar o problema. TK-2340

Boa tarde, Eu pedi o XML de envio de lote e não do Rps.

Bom dia Marcos, Acabei de fazer um teste usando o programa exemplo, mais precisamente o botão [Imprimir DANFSE]. Testei os dois XMLs que você anexou, veja o resultado: Arquivo Carregado de: C:\Users\Italo\Downloads\xmlOld.xml Nota Numero: 202100000001097 Código de Verificação: 975dcf10 Data de Emissão: 17/11/2021 Arquivo Carregado de: C:\Users\Italo\Downloads\xmlnew.xml Nota Numero: 202200000000007 Código de Verificação: 00000000 Data de Emissão: 03/02/2022 3121113240271800010956202100000001097-nfse.pdf 3122023240271800010956202200000000007-nfse.pdf

Bom dia, Você tem o XML de envio do lote do RPS de numero 265? Se sim, favor anexar.

Boa tarde Marcos, Muito obrigado pela colaboração, já inclui na minha lista de tarefas para analisar o que foi feito. TK-2336

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

Bom dia Gilson, Estamos reunindo a equipe ACBr para juntos analisar o problema e buscar uma solução.

Boa tarde Juliomar, O conteúdo do XML é exatamente igual, independente de usar msXml ou libXml2 o DigestValue e a SignatureValue não deveriam ser exatamente iguais? Ou será que cada um tem o seu método para calcular esses campos?

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

Flavio, Você esta fazendo confusão. Essa mensagem deve ser do envio e não da consulta. Favor realizar um novo teste de envio e anexe os XMLs gerados.

Flavio, Nos XMLs que você anexou se refere a consulta e nela consta a mensagem: "Não existe na base de dados uma NFS-e emitida para o número de RPS informado." Através do programa exemplo essa mensagem não aparece?