Junior Salzano

Fala galera Bom dia, td certo ? Galera estou verificando uma situação do provedor de JoinVille-SC, Esse provedor utiliza o padrão abrasf 2.03, pelo que reparei não tem implementado a questão do campo ValorIssRetido, como tinha na versão 1. Estou incluindo esses campos porem estou recebendo o seguinte retorno: <MensagemRetornoLote> <Codigo>E11</Codigo> <Mensagem>Rps Serie/Numero: A/18759 - O Valor do ISS nao confere. Valor do ISS: 34,04, valor informado: 0 | O Valor do ISS nao confere. Valor do ISS: {0}, valor informado: {1}</Mensagem> </MensagemRetornoLote> Essa nota não valor de iss, apenas valor de ISSRetido. Alguem teria um xml de exemplo para eu dar uma olhada de como ficaram as tags; Muito obrigado Abraço!

Fala Italo, Obrigado pelo retorno, Vou retomar esse assunto novamente agora. E vou fazer os testes aqui. A assinatura é diferente, possui uns campso de hash a mais que na assinatura padrão não utiliza. O componente do acbr esta preparado para realizar essa assinatura ? Desculpa refazer a pergunta, mais acabei não compreendendo.

Fala Italo, Que isso man, Obrigado pelo retorno. Italo topzera vou alterar aqui e vou inciar os testes, e do um retorno para encerrarmos o tópico. Agora só para confirmar, vc viu o padrão da assinatura é diferente, o componente ja esta preparado ? Valeu Italo, muito obrigado pelo retorno, Abraço!

Fala Italo, obrigado pelo retorno, Então Italo na verdade precisa sim.... o que pode confundir é que o provedor IPM eles permitem que a prefeitura decida se vai exigir assinatura no arquivo ou não. E para o caso de cachoeirinha por exemplo que foi migrado agora, será utilizado a assinatura digital no arquivo. A assinatura é exatamente essa que mandei acima, que eu retirei de um arquivo de exemplo deles. Então o provedor de cachoeirinha-RS não esta sendo masi enviado pelo Thema, e sim pelo IPM, exigindo a assinatura digital no arquivo. Caso surgir alguma coisa para dar uma força pra gente implementar isso da um salve. Valeu galera, obrigado pela contribuição.

Fala man, bom dia.... então man, mas o padrão da assinatura é diferente. vou fazer uns testes aqui e retorno. Se alguém souber alguma coisa, pois eu vi uns tópicos aew a galera falando sobre isso. Não vi nenhum com solução. Vc viu o padrão da assinatura que eu postei a cima aew ?

Pelo que vi aqui no arquivo de cidades.ini não foi atualizado o provedor de cachoeirinha-rs esta configurado para o Thema ainda, Essa mudança de provedor é recente.

Fala Juliomar, Obrigado pelo retorno man, Cara poderia ser sim, sem problemas. Mas eu dei uma olhada rapidamente na assinatura e não encontrei algumas tags que possuim nessa assinatura, aew me gerou essa duvida. Segue padrão da assinatura> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="#nota"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/> <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <ds:XPath>not(ancestor-or-self::ds:Signature)</ds:XPath> </ds:Transform> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>r/BejOKrCf3zUpxoWMTrfRfUabY=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> RAl46i84+jxyJVmvCJopg1PAVjQXPKMdh4XADgmlxly/q1uZgtNyMo7XgZi68jYETXOtbyW7vRCz x4E+kjtgDFbG7TflRtP5VvJpyuJarnusejACGDph9VQlLUWjo+rkTZP/H9SiP/L+BFrVkEVPqcdZ n5KhTvu6L4WRMTDeBfGQvdoSWhtCylCBFqC8Mn/O0jA+UQXK4DcmKwqCkrGvdpKjl2nOhO+q6bUa lmpnGDQbugdFW/75p3W4zossD77jeOjwoo4zynbP/6vUBR6R2ow4xwHFIJmTCq1AohKQAsgxYyvF hhB5w5E/gpb21bTl+JT8W0dPirq/NsCJXMDrYg== </ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> MIIFGDCCBIGgAwIBAgICCFgwDQYJKoZIhvcNAQEFBQAwgZwxCzAJBgNVBAYTAkJSMQswCQYDVQQI DAJTQzEWMBQGA1UEBwwNRkxPUklBTk9QT0xJUzEhMB8GA1UECwwYQVVUT1JJREFERSBDRVJUSUZJ Q0FET1JBMRwwGgYDVQQKDBNCUlkgVEVDTk9MT0dJQSBTLkEuMScwJQYDVQQDDB5BQyBCUlkgTVVM VElQTEEgLSBERU1PTlNUUkFDQU8wHhcNMTMwNzMxMTc1NzE5WhcNMTQwNzMxMTc1NzE5WjCBmzEL MAkGA1UEBhMCQlIxCzAJBgNVBAgMAlNDMRMwEQYDVQQHDApSSU8gRE8gU1VMMS4wLAYDVQQLDCVB VVRPUklEQURFIENFUlRJRklDQURPUkEgREVNT05TVFJBQ0FPMRwwGgYDVQQKDBNCUlkgVEVDTk9M T0dJQSBTLkEuMRwwGgYDVQQDDBNNQVJJTyBDRVNBUiBTQ0hFUkVSMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAoBUgDgyTjfFTf37wDUHcJkjfyGxa6ejlzDhSmaBKqbOiEyfTqkIZoanL qbulxMAZYOjZXRUrvlBZHk7hyOnr+A02G5zlEn4AomiVTmbWregKJVsSpiU9+bq6THZ33bkqMw8J N7tl6n+fQHXviCxk2nF5aq2vXSBiK4l0YGbtT4kB/8xFo91avS/NbBz5c/q1HZN/Fa92uHQdnEBY WYdNmQaLAtPiZzMZWkImYehr725IbI6FxObOQSWOhecBeY3ICUX+jMmk+W0s5zlR7SNqz8zW08fR c6H5Vmmasd+OO8NTHZwRRg2KCftRw0bjCIyYGm6JtNVgDcOKOSZsFZV+fwIDAQABo4IB4jCCAd4w HwYDVR0jBBgwFoAUCv1uuBMO50e6IFpX/M+vEpADFzkwHQYDVR0OBBYEFAAdtRyiubeyKI/FHsP2 VHOr54RtMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCBeAwCQYD VR0TBAIwADBaBgNVHR8BAQAEUDBOMEygSqBIhkZodHRwOi8vaWNwLmJyeS5jb20uYnIvcmVwb3Np dG9yaW8vbGNyL2FjX2JyeV9tdWx0aXBsYV9kZW1vbnN0cmFjYW8uY3JsMIGdBgNVHREEgZUwgZKg PQYFYEwBAwGgNAQyMjcxMTE5NzY2MTIwOTIxMDk1OTAwMDAwMDAwMDAwMDAwMDAwMDAyNjIwMTY0 U1NQU0OgHgYFYEwBAwWgFQQTMDAwMDAwMDAwMDAwMDAwMDAwMKAXBgVgTAEDBqAOBAwwMDAwMDAw MDAwMDCBGG1hcmlvLnNjaGVyZXJAaXBtLmNvbS5icjBmBgNVHSAEXzBdMFsGCysGAQQB9H8BAwEB MEwwSgYIKwYBBQUHAgEWPmh0dHA6Ly9pY3AuYnJ5LmNvbS5ici9yZXBvc2l0b3Jpby9wYy9wY19h MV9hY19icnlfbXVsdGlwbGEucGRmMA0GCSqGSIb3DQEBBQUAA4GBAIlATZvfwlT25jn1ObZNt9bN +YTmjKRP2zC9y95Qlf3Rq/FT9Bmts892v0Llv55kPom6BbVrdY+V+SsGqPWnF/bY7Tcz5nD+VA47 rVsoW54ym/5e6Ko/ZeBb8HNI3HQQ1EnQo6cZ3V7AdTwriWjPb1zQk9AcMizl2Cjz/RXAD+5C </ds:X509Certificate> </ds:X509Data> <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> oBUgDgyTjfFTf37wDUHcJkjfyGxa6ejlzDhSmaBKqbOiEyfTqkIZoanLqbulxMAZYOjZXRUrvlBZ Hk7hyOnr+A02G5zlEn4AomiVTmbWregKJVsSpiU9+bq6THZ33bkqMw8JN7tl6n+fQHXviCxk2nF5 aq2vXSBiK4l0YGbtT4kB/8xFo91avS/NbBz5c/q1HZN/Fa92uHQdnEBYWYdNmQaLAtPiZzMZWkIm Yehr725IbI6FxObOQSWOhecBeY3ICUX+jMmk+W0s5zlR7SNqz8zW08fRc6H5Vmmasd+OO8NTHZwR Rg2KCftRw0bjCIyYGm6JtNVgDcOKOSZsFZV+fw== </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue> </ds:KeyInfo> </ds:Signature> essa estrutura não encontrei nas assinaturas do acbr, me corrija se eu estiver errado, por favor.; <ds:KeyValue> <ds:RSAKeyValue> <ds:Modulus> oBUgDgyTjfFTf37wDUHcJkjfyGxa6ejlzDhSmaBKqbOiEyfTqkIZoanLqbulxMAZYOjZXRUrvlBZ Hk7hyOnr+A02G5zlEn4AomiVTmbWregKJVsSpiU9+bq6THZ33bkqMw8JN7tl6n+fQHXviCxk2nF5 aq2vXSBiK4l0YGbtT4kB/8xFo91avS/NbBz5c/q1HZN/Fa92uHQdnEBYWYdNmQaLAtPiZzMZWkIm Yehr725IbI6FxObOQSWOhecBeY3ICUX+jMmk+W0s5zlR7SNqz8zW08fRc6H5Vmmasd+OO8NTHZwR Rg2KCftRw0bjCIyYGm6JtNVgDcOKOSZsFZV+fw== </ds:Modulus> <ds:Exponent>AQAB</ds:Exponent> </ds:RSAKeyValue> </ds:KeyValue>

Fala galera, Bom dia, td certo ? Galera vi alguns tópicos falando desse assunto, porem não vi conclusão em nenhum deles, sendo assim estou iniciando uma nova discussão. Tenho duas prefeituras diferente utilizando o provedor IPM, a prefeitura de cachoeirinha-RS migrou agora para utilizar também o provedor IPM, com uma restrição diferente dos outros que conheço que seria a assinatura digital nos arquivos enviados. Utilizei a assinatura padrão utilizando a capicom porem eu vi que esse padrão são 3 tags que recebem a assinatura. Temos essa assinatura implementada nos componentes atualizados do ACBR ? Valeu galera, obrigado pelo tempo e atenção; Abraço!

Fala Italo, Boa tarde, Obrigado pelo retorno, Italo eu consegui entender o problema certinho agora. Esse provedor da esse retorno quando falta alguma informação no XML, ele retorna que o xml esta em desconformidade. Nesse caso do xml enviado, faltava o CNPJ de um tomador, Foi difícil pra descobrir isso com um erro genérico. Pode finalizar o tópico, esse erro trata-se de desconformidade no XML, ou seja. alguma tag obrigatória esta faltado. Muito obrigado pela atenção. Abraço!

Fala Italo, Boa noite, Italo... Realizando alguns testes aqui eu pude nodar o seguinte... Encontrei esse post>: https://suporte.wolterskluwer.com.br/hc/pt-br/articles/360015449231-E19-Rejeição-NFSe-O-documento-xml-de-entrada-do-serviço-esta-fora-do-padrão-especificado Resolução Rejeição ocorre pois a situação utilizada para NFSe difere das seguintes opções: S - Normal ou C - Cancelada. 1- Verifique a situação utilizada para NFSe 2- Realize a emissão novamente Verificando o meu caso, as notas já estavam autorizadas, A prefeitura esta retornando esse erro de forma generica, sinceramente não pude entender muito tem. Porem... realizando o processamento de outros lotes no mesmo ambiente de homologação, os lotes foram autorizados com sucesso! Minha conclusão é que realmente não existe um erro na rotina, e sim na tratativa de retorno da prefeitura. Se descobrir algo diferente do meu entendimento, me informe por favor. Muito obrigado pela atenção.

Fala Italo, Rapaiz... com uma nota vai de boa, consegui enviar lote ate com 16notas foi também. O problema esta apresentando em apenas alguns lotes com 20 rps, 19 rps, Segue xml; Untitled12.xml

Fala Italo, Obrigado pelo retorno, Italo, com uma nota estou enviando com sucesso! Passou a dar problemas ao aumentar o numero de rps, Estou enviando em ambiente de homologação, pensei isso também, que no ambiente de produção pudesse estar ok, Vou fazer uns testes aqui e retorno. Muito obrigado Abraço!

Bom dia, Assim que eu descobrir eu posto a solução aqui, Se alguém já passou pro isso, da um salve aew. Valeu

Fala galera, boa tarde! Estou realizando envios de nfse para a prefeitura de Porto Alegre, provedor proBHISS, estou recebendo o seguinte retorno de vários envios: <Codigo>E181</Codigo> <Mensagem>O documento XML de entrada do serviço esta fora do padrão especificado. (Expected type CHARACTERS, current type END_ELEMENT at [row,col {unknown-source}]: [1,81412]) </Mensagem> O lote possui 20 rps, substitui todas observações procurando por caracteres invalidos, Estou recendo o erro tanto pelo delphi, pelo soapUI, e pelo NODE. Envio o xml por aplicações diferente, Me retorna a mesma rejeição, em ambiente de homologação do provedor, não testei em produção. Alguém já objete esse retorno ? Valeu galera Abraço!.; Edson Junior

Fala galera! Descobri aqui, Esta dando esse erro pq o provedor não tem o cancelamento ativo ainda. Desculpa abrir o tópico, podemos dar como concluído. Valeu abraço!

Fala galera, Boa tarde. Tudo certo ? Galera eu vi que tinha um tópico falando desse provedor estava fechado, não consegui incluir o questionamento no mesmo. Seguinte, to validando a rotina de envio, estou com um problema no cancelamento. Estou com o seguinte retorno <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="http://nfse.abrasf.org.br"> <SOAP-ENV:Body> <ns1:CancelarNfseResponse> <outputXML/> </ns1:CancelarNfseResponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Ta estranho. hehe Alguém tem um xml de exemplo aew para o cancelamento. Valeu galera! Abraço!

Fala galera, Bom dia. Vi alguns tópicos falando sobre esse provedor, que já existe implementado no componente e tudo mais... Inclusive já estou com o componente em mãos. Alguém sabe me dizer se esse provedor existe um wsdl, não estou conseguido encontrar. Alguém teria um xml de exemplo assinado por favor? Agradeço atenção de todos. Abraço!

Massa, muito boa! Entendi. é isso mesmo! Então o campo cNF presenta o código numero, vou deixar o próprio componente gerar já o campo nNF é de fato o código da Nfe para atrelar ao meu sistema, correto ? Muito obrigado pelo retorno. Abraço!

Fala galera Bom dia, Estou com a seguinte rejeição no envio de NF-e Alguém poderia dar alguma sugestão, sobre o problema ? <cStat>897</cStat> <xMotivo>Rejeicao: Codigo numerico em formato invalido</xMotivo> chave gerada; 43191100773639003800550010000016831000016830

Fala galera, Bom dia, tudo certo? Estou integrando o componente de envio de NF-e do ACBR, Percebi que os envios são realizado sempre por lote, existe uma forma de enviar sem ser por lote ? Muito obrigado. Abraço!

Galera... Boa tarde. Estou trabalhando na implementação no provedor Elotech - Ponta Grossa -PR. No qual o ACBR não tem implementado esse provedor nos componentes. Porem estou implementando em delphi, e gostaria da ajuda de algum de vocês que já tem esse provedor rodando em seus sistemas. Estou usando esse padrão para fazer o envelop> result := '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:nfse="http://shad.elotech.com.br/schemas/iss/nfse_v2_03.xsd">'+ '<soapenv:Header>'+CabMsg+'</soapenv:Header>'+ '<soapenv:Body>'+ '<tem:RecepcionarLoteRps>'+ '<tem:xmlEnvio><![CDATA['+DadosMsg+']]></tem:xmlEnvio>'+ '</tem:RecepcionarLoteRps>'+ '</soapenv:Body>'+ '</soapenv:Envelope>'; porem... sem sucesso. Me da um erro 400 ao consumir o serviço. Acredito que o problema esteja no envelop, alguém tem um exemplo desse envelpo ae para dar uma força! Vlw galera! Abraço!

Fala Italo, Boa tarde, tudo certo ? Obrigado pelo retorno, Sendo assim, não temos desenvolvido isso pelo componente da ACBR, correto ? Vou dar continuidade na implementação desse provedor por conta então.. se tiver para contribuir com a ACBR eu publico aqui o fonte, Pois se não encontrar essa assinatura em delphi, tentar desenvolver em C#, como foi feito para o provedor de Blumenau proNotaBlu, esta funcionando perfeitamente, Muito obrigado pela atenção Italo, Um abraço ! Valeu!

Fala Italo, Obrigado pelo retorno, Italo.. Na verdad eu olhei sim ... Porem la esta apontando que seria este provedor -> fintelISS E segundo informações o provedor correto seria ELOTECH, Onde eu obtive informações dizendo que a ACBR não implementou a layout para este provedor, ele possui uma assinatura um pouco diferente do padrão. Ae como gerou duvidas decidi criar o tópico com o intuito de encontrar alguém que já faz o envio para esta prefeitura. Vou inciar meus teste, se alguém tiver alguma informação será muito bem vinda. Muito obrigado pela atenção.

Boa tarde galera, Galera... eu vi que existem outros tópicos falando sobre esse assunto, porém não encontrei nenhum atual e com solução, Sendo assim gostaria de fazer um levantamento de informações sobre esse provedor de Ponta-Grossa -PR. Primeira duvida é referente ao provedor seria o fintelISS ou ELOTECH, estamos falando da mesma coisa ? O componente da ACBR tem implementado envio de nfse para esse provedor ? Estou verificando uma demanda para implementar o provedor dessa prefeitura, porem em poucas informações que busquei, me parece ser um provedor um pouco diferente da maioria e com um padrão de assinatura diferente. Alguém poderia me passar informações que pudessem me orientar ? Muito obrigado pela atenção galera, Um Abraço!;

Fala galera, Boa tarde... Fiz o comentário, porem realmente ninguém tem a obrigação de responder meu questionamento, porem também acredito que questionamentos como este são validos para o forum, pois posso estar com o mesmo problemas entre outros, sendo assim tornando um forum fico em contudo, assim como tenho esse pensando sobre o mesmo. Então acredito que minha forma de contribuição não esteja somente nas respostas, mais também nos questionamentos. Acredito não estar beneficiando apenas a mim. Mais desculpe caso eu criei algum tipo de discórdias de opiniões; E para deixar um respaldo sobre a situação caso exista outro interessado. Entrei em contato com a prefeitura, já que me retorno não existe nenhum alerta de mensagem de erro, O numero de protocolo eles consideram o mesmo numero do lote <NumeroLote>0</NumeroLote> Porem o mesmo vem zerado. A rotina já esta preparada para considerar o numero de lote como numero de protocolo, Agora so preciso entender o porque esta retando zerado ja que não existe nenhuma mensagem de alerta de erro. Galera muito obrigado pela atenção de todos. Valeu Abraço