Sandro Felipe Adad

'<?xml version="1.0" encoding="ISO-8859-1"?><retorno>'#9'<mensagem>'#9#9'<codigo>00001 - Sucesso</codigo>'#9'</mensagem>'#9#9'<numero_nfse>13</numero_nfse>'#9'<serie_nfse>1</serie_nfse>'#9'<data_nfse>25/08/2021</data_nfse>'#9'<hora_nfse>17:06:05</hora_nfse>'#9'<situacao_codigo_nfse>1</situacao_codigo_nfse>'#9'<situacao_descricao_nfse>Emitida</situacao_descricao_nfse>'#9'<link_nfse>https://migracao.atende.net/?pg=autoatendimento&cidade=treina_guarapuava_integracao#!/tipo/servico/valor/213/padrao/1/load/1/identificador/7583738026207714738720220825082021183606</link_nfse>'#9'<cod_verificador_autenticidade>7583738026207714738720220825082021183606</cod_verificador_autenticidade></retorno>'

Sim, repeti o processo duas vezes pra conferir. o Erro ocorre antes de verificarareposta, na procedure LoadFromXml da unit ACBrXmlDocument; procedure TACBrXmlDocument.LoadFromXml(AXmlDocument: string); -> loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument))); 28-rec.xml 28-rec-soap.xml

Resolveu o problema do Acces Violation da forma de pagamento - blz. Mas ao ler o xml de retorno ainda com erro na msg: Modo de Envio : Enviar Lote Numero do Lote: 26 Data de Envio : 30/12/1899 Numero do Prot: Sucesso : True Modo de Envio : Enviar Lote Numero do Lote: 26 Data de Envio : 30/12/1899 Numero do Prot: Sucesso : True Erro(s): Código : X999 Mensagem: EntityRef: expecting ';' Correção: --------- <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="ISO-8859-1"?><retorno> <mensagem> <codigo>00001 - Sucesso</codigo> </mensagem> <numero_nfse>9</numero_nfse> <serie_nfse>1</serie_nfse> <data_nfse>25/08/2021</data_nfse> <hora_nfse>16:16:41</hora_nfse> <situacao_codigo_nfse>1</situacao_codigo_nfse> <situacao_descricao_nfse>Emitida</situacao_descricao_nfse> <link_nfse>https://migracao.atende.net/?pg=autoatendimento&cidade=treina_guarapuava_integracao#!/tipo/servico/valor/213/padrao/1/load/1/identificador/7583738026207714738720220825082021160642</link_nfse> <cod_verificador_autenticidade>7583738026207714738720220825082021160642</cod_verificador_autenticidade> </retorno>

o Erro ocorre em procedure TACBrXmlDocument.LoadFromXml(AXmlDocument: string); var loadedDoc: xmlDocPtr; loadedRoot: xmlNodePtr; begin loadedDoc := xmlParseDoc(PAnsiChar(ansistring(AXmlDocument))); ao ler este documento abaixo: <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="ISO-8859-1"?> <retorno> <mensagem> <codigo>00001 - Sucesso</codigo> </mensagem> <numero_nfse>6</numero_nfse> <serie_nfse>1</serie_nfse> <data_nfse>25/08/2021</data_nfse> <hora_nfse>15:59:32</hora_nfse> <situacao_codigo_nfse>1</situacao_codigo_nfse> <situacao_descricao_nfse>Emitida</situacao_descricao_nfse> <link_nfse>https://migracao.atende.net/?pg=autoatendimento&cidade=treina_guarapuava_integracao#!/tipo/servico/valor/213/padrao/1/load/1/identificador/7583738026207714738720220825082021151933</link_nfse> <cod_verificador_autenticidade>7583738026207714738720220825082021151933</cod_verificador_autenticidade> </retorno>

ACBrNFSeX -> deixei em comentario (access violation aqui) {if (NFSe.Status = srNormal) and (TACBrNFSeX(FAOwner).Configuracoes.Geral.Provedor in [proIPM_110, proIPM_120]) then begin xmlNode := GerarCondicaoPagamento; NFSeNode.AppendChild(xmlNode); end; } Deu certo o envio com exceção do ajuste IPM.GravarXML que postei acima que deixem em comentario. A nota foi aceita e convertida. no programa exemplo apenas deu um erro na mensagem Modo de Envio : Enviar Lote Numero do Lote: 23 Data de Envio : 30/12/1899 Numero do Prot: Sucesso : True Modo de Envio : Enviar Lote Numero do Lote: 23 Data de Envio : 30/12/1899 Numero do Prot: Sucesso : True Erro(s): Código : X999 Mensagem: EntityRef: expecting ';' Correção: --------- :

depois do primeiro envio, retorna sempre o mesmo identificador: <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="ISO-8859-1"?> <retorno> <mensagem> <codigo>00209 - Já consta uma NFSe para o referido prestador de serviço com o mesmo IDENTIFICADOR de arquivo </codigo></mensagem> </retorno> IPM.Provider.pas 21-rec.xml 21-rec-soap.xml temp.xml 21-env-lot.xml 21-env-lot-soap.xml Não, ao meu ver o problema ésta na forma ne anexar o arquivo, não é padrao rest, é padrão multiform. Se voce observar no proprio exemplo do postman que coloque nos comentarios acima pelo log dele.

Alterei no IPM.Provider.pas, de rest pra multipart - linha 51 para suportar o formato multi-part. TACBrNFSeXWebserviceRest -> TACBrNFSeXWebserviceMulti TACBrNFSeXWebserviceIPM = class(TACBrNFSeXWebserviceMulti) o webservice recebeu o xml incorporado do ACBR e começou a responder no programa de exemplo.

LOG do Postman Console do caso de sucesso: POST https://migracao.atende.net/atende.php?pg=rest&service=WNERestServiceNFSe&cidade=treina_guarapuava_integracao200 497 ms POST /atende.php?pg=rest&service=WNERestServiceNFSe&cidade=treina_guarapuava_integracao HTTP/1.1 Authorization: Basic NzcuMTQ3LjM4Ny8wMDAxLTM4OlBlckA3NzE0Nw== User-Agent: PostmanRuntime/7.28.0 Accept: */* Cache-Control: no-cache Postman-Token: 81781a09-b2c4-4646-9e9c-91a834f8b050 Host: migracao.atende.net Accept-Encoding: gzip, deflate, br Connection: keep-alive Content-Type: multipart/form-data; boundary=--------------------------841383869900214019996528 Cookie: PHPSESSID=nvb5gd8vtue44ko8mmm5b60575; cidade=treina_guarapuava_integracao Content-Length: 1707 ----------------------------841383869900214019996528 Content-Disposition: form-data; name="XML"; filename="20210824165514-env-lot.xml" <20210824165514-env-lot.xml> ----------------------------841383869900214019996528-- HTTP/1.1 200 OK Date: Tue, 24 Aug 2021 19:55:40 GMT Server: Apache X-Frame-Options: sameorigin Set-Cookie: cidade=treina_guarapuava_integracao; path=/; samesite=lax Expires: Mon, 26 Jul 1997 05:00:00 GMT Cache-Control: no-cache, must-revalidate Pragma: no-cache Data-Servidor: 1629834940000 Connection: close Content-Encoding: none X-XSS-Protection: 1; mode=block X-Content-Type-Options: nosniff Content-Security-Policy: object-src 'self' data: blob: https://*.atende.net https://*.ipm.com.br https://nfs-e.net; block-all-mixed-content; form-action 'self' *.nfs-e.net https://*.ipm.com.br https://*.atende.net https://*.acesso.gov.br; frame-ancestors 'self' https://*.nfs-e.net https://*.ipm.com.br https://*.atende.net; Strict-Transport-Security: max-age=31586000; includeSubDomains; preload Transfer-Encoding: chunked Content-Type: application/json <?xml version="1.0" encoding="ISO-8859-1"?><retorno> <mensagem> <codigo>00001 - Sucesso</codigo> </mensagem> <numero_nfse>4</numero_nfse> <serie_nfse>1</serie_nfse> <data_nfse>24/08/2021</data_nfse> <hora_nfse>16:55:40</hora_nfse> <situacao_codigo_nfse>1</situacao_codigo_nfse> <situacao_descricao_nfse>Emitida</situacao_descricao_nfse> <link_nfse>https://migracao.atende.net/?pg=autoatendimento&cidade=treina_guarapuava_integracao#!/tipo/servico/valor/213/padrao/1/load/1/identificador/7583738025207714738720220824082021169541</link_nfse> <cod_verificador_autenticidade>7583738025207714738720220824082021169541</cod_verificador_autenticidade> </retorno>

Fiz outro teste, gerei o xml pelo programa de exemplo e tentei o envio pelo Postman, ai começou a validar o xml. Removi da geração do ACBR os dados do rps pois com as informações da RPS não aceitava o XML e dava um erro maluco. { IdentificacaoRps.Numero := FormatFloat('#########0', StrToInt(NumDFe)); IdentificacaoRps.Serie := '1'; IdentificacaoRps.Tipo := trRPS;// TnfseTipoRPS = ( trRPS, trNFConjugada, trCupom ); DataEmissaoRPS := Now; } Pelo postman foi aceito o arquivo gerado pelo ACBR, e gerou a nota, creio que no ACBR seja a forma de adição do XML o problema. Outra coisa que me chamou a atenção foi o formato de codificação: <?xml version="1.0" encoding="ISO-8859-1"?> e no ACBR vem em UTF-8. Retorno pelo envio pelo ACBR: <?xml version="1.0" encoding="UTF-8"?><?xml version="1.0" encoding="ISO-8859-1"?> <retorno> <mensagem> <codigo>9999 - Arquivo XML da Nota Fiscal de Serviço Eletrônica não enviado!</codigo> </mensagem> </retorno> Retorno do Envio pelo PostMan: <?xml version="1.0" encoding="ISO-8859-1"?><retorno> <mensagem> <codigo>00001 - Sucesso</codigo> </mensagem> <numero_nfse>4</numero_nfse> <serie_nfse>1</serie_nfse> <data_nfse>24/08/2021</data_nfse> <hora_nfse>16:55:40</hora_nfse> <situacao_codigo_nfse>1</situacao_codigo_nfse> <situacao_descricao_nfse>Emitida</situacao_descricao_nfse> <link_nfse>https://migracao.atende.net/?pg=autoatendimento&cidade=treina_guarapuava_integracao#!/tipo/servico/valor/213/padrao/1/load/1/identificador/7583738025207714738720220824082021169541</link_nfse> <cod_verificador_autenticidade>7583738025207714738720220824082021169541</cod_verificador_autenticidade> </retorno>

Boa tarde, tambem tenho um cliente que irá emitir notas em Guarapuava (Empresa de Transportes Perola do Oeste), hoje iniciei a atualização do meu ACBR para inicio no componente novo ACBRNFSeX. 1) Fiz um teste de envio e obtive inicialmente erro de autenticação, mas tinha que habilitar para o meu usuario no site da prefeitura o envio por webservices. 2) Feito isso, ao enviar pelo programa de testes novo ACBRNFSeX, retornou um xml com o seguinte conteudo: <codigo>9999 - Arquivo XML da Nota Fiscal de Serviço Eletrônica não enviado!</codigo> o que reparei é que no Json gerado no xml pelo ACBR: "usuario": "xxx", "senha": "xxx"} e no exemplo da IPM em PHP: Os parâmetros POST esperados pelo web service, na requisição HTTP, com Content-Type: multipart/form-data, são: Campo Tipo Descrição username Text CPF/CNPJ do emissor da NFS-e password Password Senha de acesso ao sistema. Authorization Text base64_encode(username:password) As informações de username e password devem ser passadas junto ao cabeçalho da requisição por meio do Authorization, sendo username:password em formato base64. Exemplo: base64_encode('admin:admin').

Creio que o problema é com alguma configuração do ACBR que antes era default e agora não é mais. ACBRNFSE.Configuracoes.Geral.SSLLib := libCustom; ACBRNFSE.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; ACBRNFSE.Configuracoes.Geral.SSLHttpLib := httpWinHttp; ACBRNFSE.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; ACBRNFSE.SSL.SSLType := LT_TLSv1_2; Consegui efetuar a consulta no programa de exemplo, com esta configuração acima, e teve exito.

0182950002710624-con-lot-soap.xml0182950002710624-con-lot.xml3107-rec-soap.xml3107-rec.xml0182950002710624-lista-nfse-soap.xml0182950002710624-lista-nfse.xml1197709-env-lot-soap.xml1197709-env-lot.xml1197709-rec-soap.xml1197709-rec.xml1197710-env-lot-soap.xml1197710-env-lot.xml 1197709 é o envio com o novo trunk e novo delphi. 1197710 é o envio com o antigo trunk e antigo delphi. Visualmente não encontrei diferença... pode ser alguma codificação do arquivo diferente?

Testei enviando sem o encoding, aquilo e não funcionou também.... estranho que se tento acessar pelo browser a url https://sync.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php?eletron=1 obtenho o mesmo erro: Usuário ou senha inválido(s).

Comparei e parecem exatamente similares. FPRetornoWS := FPDFeOwner.SSL.Enviar(FPEnvelopeSoap, FPURL, FPSoapAction, FPMimeType, FPAuthorizationHeader); Debugando o ACBrDFeWebService, me confirma se esta correto a variavel FPURL estar vindo assim antes do envio: <?xml version="1.0" encoding="UTF-8"?>http://sync.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php?eletron=1 Não estaria sobrando <?xml version="1.0" encoding="UTF-8"?>

Após migrarmos do Delphi XE6 para o novo Delphi 10.4, migramos também o ACBR para a nova versão do trunk2. Este cliente meu é de SC, município de Rio Negrinho, com o mesmo user e senha estava enviando e recebendo notas normalmente até antes de atualizarmos para o novo delphi. Após obter os novos fontes do ACBR, alterei o IPM.INI para assinar o RPS neste municipio, como ja era feito anteriormente e peguei as novas configurações no cidades.ini tambem. [4215000] Nome=Rio Negrinho UF=SC Provedor=IPM NomeURL_H=sync NomeURL_P=sync ; Para algumas cidades devemos mudar o valor do campo RPS para 1, pois existe que seja assinado RPS=1 Lote=0 URI=1 ConsSit=0 ConsLote=0 ConsNFSeRps=0 ConsNFSe=0 Cancelar=0 ; Para algumas cidades devemos mudar o valor do campo RpsGerar para 1, pois existe que seja assinado RpsGerar=1 LoteGerar=0 Substituir=0 [URL_P] RecepcaoLoteRPS=http://%NomeURL_P%.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php?eletron=1 [URL_H] RecepcaoLoteRPS=http://%NomeURL_H%.nfs-e.net/datacenter/include/nfw/importa_nfw/nfw_import_upload.php?eletron=1 Alterei a senha para xxx apenas. Preciso alterar algo mais? Segue em anexo os logs de envio. 0182950002710624-con-lot.xml 0182950002710624-con-lot-soap.xml 0182950002710624-lista-nfse.xml 0182950002710624-lista-nfse-soap.xml

Deu certo, removi o excedente ( xmlns:ws="http://ws.pc.gif.com.br/) e fiz o teste de envio, passou, deu outros erros na conversão da nota devido aos dados de teste, mas o lote foi enviado com sucesso! Este layout Infiscv11 é usado apenas por Garibaldi? Obrigado.

A geração do XML deu cewrto, porém o envio deu erro na assinatura. Reparei que tem uma pequena diferença no início do arquivo (não sei se isto influencia na validação de assinatura): Antes/Agora: -<envioLote versao="1.0"> -<envioLote versao="1.0" xmlns:ws="http://ws.pc.gif.com.br/"> O Lote 10 é o que gerei agora e apresentou erro e o 5046 é o antigo que funciona. (em anexo) 10-env-lot.xml 10-lot-rps.xml 10-rec.xml 5046-env-lot.xml 5046-env-lot-soap.xml

Italo, conseguiu dar uma olhada no caso?

Ok Italo, estarei testando junto ao cliente e lhe informo, desde já muito obrigado, Abraço.

Atualizei tudo mas não resolveu, tentei tirar a validação de schema para testar o envio, e ai ocorre erro na assinatura.

Efetuada atualização das pastas de schemas e ini agora e fiz novo teste. O Erro que ocorre agora:

Inclusão de nova cidade. [4312385] Nome=Monte Belo do Sul UF=RS Provedor=Tecnos NomeURL_H=montebelo NomeURL_P=montebelo.nfse-tecnos.com.br

Bom dia, estou com problema ao tentar gerar um lote de notas para o provedor INFISC-V11 após atualizar os fontes do ACBR, no municipio de 4308607-Garibaldi/RS. Creio que foi alterado o schema do provedor e o ABCR esta acusando erro ao clicar no botão "Gerar Lote RPS" no programa de exemplo "ACBR_NFSE - Programa Exemplo" : "element "Emit: This element is not expected. Expected is (prest)". Mas não sei se deve-se alterar o infiscv11.ini para correção(já que é usado por diversas cidades) como são feitos os ajustes? No cidades.ini, precisa ser alterado o ambiente de homologação para: garibaldi-homol.infisc.com.br. https://nfse.garibaldi.rs.gov.br/site/manuais/ schemaNFS.xsd

Fast.zip Fonte para impressão do bpe no fastreport, para sua analise.

Obrigado, era isso mesmo que eu precisava realizar. Sim, mas não tinha subido ainda ao repositório quando efetuei a alteração.