Alex Heinen

Boa Tarde, conferido, pode fechar.

Boa Tarde, favor adicionar no arquivo ACBrNFSeXServicos.Ini a cidade de Três Barras do Paraná [4127957] ; Atualizado em 07/02/2025 Nome=Tupassi UF=PR Provedor=IPM Versao=1.01 ProRecepcionar=https://tupassi.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe&cidade=padrao&eletron=1 HomRecepcionar=

Está ok pode fechar a thread

Boa Tarde conferido e está ok, pode fechar a thread. Obrigado!

Boa Tarde, favor adicionar no arquivo ACBrNFSeXServicos.Ini a cidade de Três Barras do Paraná [4127858] Nome=Três Barras do Parana UF=PR Provedor=Pronim Versao=2.03 ProRecepcionar=http://tresbarras.govbr.cloud/nfse.portal.integracao/services.svc HomRecepcionar=

Boa Tarde, prefeitura de Palmas no PR alterou o endereço webservice da FlyBetha antes era 1.00 agora é 2.02, segue endereço atualizado. [4117602] Nome=Palmas UF=PR Provedor=Betha Versao=2.02 ProRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-ws/nfseWS HomRecepcionar=http://e-gov.betha.com.br/e-nota-contribuinte-test-ws/nfseWS

Bom Dia, Eu implementei no componente e passei para o meu cliente até que a TK seja avaliada.

Boa Tarde, Conferido e está ok pode fechar a Thread. Obrigado

Bom Dia, prefeitura de Quatro Pontes e Lindoeste - PR mudou de provedor de Betha para Publica, segue novos links [4120853] Nome=Quatro Pontes UF=PR Provedor=Publica ProRecepcionar=https://nfse-quatropontes.e-publica.net/quatropontes_nfse_integracao/Services HomRecepcionar=http://nfse-teste.publica.inf.br/homologa_nfse_integracao/Services [4113452] Nome=Lindoeste UF=PR Provedor=Publica ProRecepcionar=https://nfse1.publica.inf.br/lindoeste_nfse_integracao/Services?wsdl HomRecepcionar=http://nfse-teste.publica.inf.br/homologa_nfse_integracao/Services

Ok, Muito Obrigado! fico no aguardo

Bom Dia, Algum parecer sobre a possibilidade de implementar a alteração citada acima no ProtocoloB da balança toledo?

Sim Analisei vários manuais da balança Toledo e testei as comunicação P05, P05A e P06 somente funcionou o protocolo P05A por isso acredito que no protocolo B deveria ter essa validação wStatus2 := aResposta[9]; if TestBit(Ord(wStatus2), 3) then { Bit 3 de wStatus2 ligado = 2 casas decimais } fpDecimais := 100; Que existe no protocolo A

Boa Tarde, A comunicação funciona sim conforme primeira imagem que enviei o problema é que está retornando o peso errado. Essa balança usa o protocolo de comunicação B porém o divisor neste caso está 1000 e deveria se 100. Criei essa Unit separada porque não sei o impacto que pode ocorrer com outras balanças. Se olhar no protocolo A também muda o divisor para 100.

Bom Dia Senhores, Entrei em contato com o suporte da Toledo Balanças Brasil atrás de mais informações, porque a balança é antiga e não encontrei manual. Segundo o suporte a balança que tenho aqui é uma Toledo 9098 Modelo 2098/61 nem mesmo eles não tem manual da referida balança. Então para resolver o meu problema desenvolvi a comunicação da balança, segue em anexo o arquivo. ACBrBALToledo2098.pas

Boa Tarde, Estou configurando uma balança Toledo 9098 porém estou tendo divergência nas casas decimal do peso. Veja que no aplicativo o peso está 0,708. porém o correto é 7,08. Analisando dentro do ACBrBalToledo.pas percebi que essa balança esta usando o protocolo B onde o valor da variável do fpDecimais está 1000 acredito que deveria ser 100 igual ocorre no protocolo A.

Conferido aqui está OK pode fechar a thread

Bom Dia, Prefeitura de Pato Bragado no Paraná teve alteração de provedor. Segue configurações abaixo [4118451] Nome=Pato Bragado UF=PR Provedor=IPM Versao=2.04 ProRecepcionar= https://patobragado.atende.net/?pg=services&service=WNENotaFiscalEletronicaNfe Não tem ambiente de Homologação somente produção.

Consegui Resolver o GravarXML do acbr faz isso corretamente dentro dele ele adiciona a TAG <?xml version="1.0" encoding="UTF-8"?> e depois manda salvar. Segui a mesma regra. Obrigado. Pode fechar a thread

Atualmente para salvar o XML eu pego os valores da seguinte variável FACBrNFSeX.NotasFiscais.Items[0].XmlNfse E nela está vindo com os caracteres especiais bagunçado. De que lugar eu deveria buscar o XML?

Bom Dia, Segue configurações utilizadas. [5003702] Nome=Dourados UF=MS Provedor=ISSNet Versao=2.04 ProRecepcionar=https://nfse.issnetonline.com.br/abrasf204/dourados/nfse.asmx HomoRecepcionar=https://www.issnetonline.com.br/apresentacao/df/webservicenfse204/nfse.asmx

Bom Dia Italo, Realizei os testes conforme suas orientações e ao fazer o LoadFromFile ocorreu o seguinte erro Extra content at the end of the document Segue os arquivos em anexo. NFSe-599-ULTRA INFORMATICA LT.xml 59913-rps.xml 14687-env-lot-sinc-soap.xml 59913-con-nfse-rps-soap.xml 59913-comp-nfse-soap.xml 599-nfse.xml

Consegui fazer da seguinte maneira, mas não sei se funciona no Delphi 7. Porém depois disso tive outro erro: Input is not proper UTF-8, indicate encoding ! Bytes: 0xC3 0x4F 0x20 0x47 Acho que teria que indicar no xml o encoding.

Boa Tarde, Antes de abrir a Thread já tinha visto isso e feito estes procedimentos. Atualmente estou na revisão 29222 Mesmo assim o problema persiste.

Italo fiz o seguinte teste baixei o xml direto do site da prefeitura. XML em anexo. Fiz com esse xml o mesmo processo que o ACBR faz. Veja o Resultado foi o mesmo que venho tendo no ACBR. Se abrir o xml verá que o mesmo está correto. 1589008_NFSeNotaFiscaldeServicosEletronica_000597.xml

Nós entramos em contato com a ISSNet antes mesmo de abrir a thread aqui no ACBR e recebemos o seguinte parecer. Que outros sistemas nunca tiveram problemas com isso. E que, inclusive a informação dentro dela esta tabelada no sistema deles também com acentuação e vem assim no retorno também. O Mais curioso que se olhar dentro da varável HttpClient.DataResp que é do tipo TMemoryStream o formato UTF-8 está correto.