João Paulo Müller

Boa tarde, Este sistema de migração consigo consumir pelo próprio ACBr? Fiz testes alterando o provedor do cidades.ini para NotaBlu, mas recebo erro 12029 - Conexão com o Servidor Falhou.

Estou tentando enviar por WS em homologação, mas retorna o erro 12029 - Conexão com o Servidor Falhou. Será que tem relação com o que o @Moacir Ezequiel Lamego comentou?

Bom dia. Pessoal, utilizando o envio pelo padrão do antigo provedor (NotaBlu) está funcionando em produção?

Pessoal, também estou nessa situação e estou disposto a colaborar no que foi preciso. Enviei um e-mail hoje pela manhã questionando o erro de Assinatura de Hash incorreto, que é o que está pegando aqui. Abriram um chamado, mas até o momento não obtive respostas.

http://www.substituicaotributaria.com/SST/substituicao-tributaria/noticia/?id=4511 Dia 26/08/2019 foi publicado a alteração na portaria na qual estabelece que o registro 2131 deixa de ser obrigatório até Janeiro de 2020. Da mesma forma em Janeiro de 2020 vamos ter o mesmo problema. No meu ponto de vista vamos ter que disponibilizar campos para o usuário fornecer as informações relativa as notas do substituto, pois as informações que o registro exige não constam no XML da nota.

Bom dia, Certo Italo, Obrigado! Referente a Lib, estou mantendo a Sec pois nos demais módulo do sistema é utilizado essa lib. Na verdade não fui muito a fundo ainda para entender a diferença entre as duas e possivelmente realizar a migração. Para utilizar a Xml2 preciso alterar apenas as Dlls da aplicação? Quais seriam as vantagens da xml2?

Boa tarde Italo, obrigado pelo retorno. Segue em anexo os arquivos. ISSJoinville.ini ACBrDFeXsXmlSec.pas

Voltei a analisar essa situação e consegui autorizar o cancelamento, no entanto, gostaria de trocar uma ideia para ver a forma correta de resolver essa situação, pois da forma que fiz foi apenas um teste. 1) ALTERADO ARQUIVO ISSJoinville.ini [Cancelar] IncluiEncodingCab=0 IncluiEncodingDados=0 DocElemento=Pedido InfElemento=InfPedidoCancelamento //Adicionei esta linha Texto1=<soapenv:Envelope xmlns="%NameSpace%/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> Texto2=<soapenv:Body> Texto3=%DadosMsg% Texto4=</soapenv:Body> Texto5=</soapenv:Envelope> Suspeitei que o erro strdup function failed ocorria pelo fato de não ter o <!DOCTYPE Teste> no XML, portanto inclui o InfElemento para ser adicionado o DOCTYPE, coforme o metodo de assinatura (TDFeSSLXmlSignXmlSec.Assinar) /*cDTD é a constante do DOCTYPE*/ if InfElement <> '' then begin IdAttr_temp := IfEmptyThen(IdAttr, 'Id'); DTD := StringReplace(cDTD, '&infElement&', InfElement, []); DTD := StringReplace(DTD, '&IdAttribute&', IdAttr_temp, []); AXml := InserirDTD(AXml, DTD); end; Resolveu o erro strdup function failed, porém, o WS estava retornando erro de assinatura. Analisando o XML assinado pude verificar que a TAG de assinatura estava sendo colocado no local errado, estava sendo inserida dentro da tag <CancelarNfseEnvio>, porém deveria ser dentro da TAG <Pedido> (docElement). OBS: Em anexo consta o XML com a assinatura na TAG correta e a assinatura sendo inserida na TAG incorreta. Ao depurar mais a fundo as rotinas encontrei a função XmlSecSign, onde verifica se já existe a TAG de assinatura no XML, caso contrario cria uma nova. Na função para criar o node de assinatura (AdicionarNode) é encontrado o elemento para ser inserido a assinatura através do parâmetro docElement. function TDFeSSLXmlSignLibXml2.AdicionarNode(var aDoc: xmlDocPtr; const ConteudoXML: String; docElement: String): xmlNodePtr; Var NewNode, DocNode: xmlNodePtr; memDoc: xmlDocPtr; NewNodeXml, vdocElement: String; begin {$IFNDEF COMPILER23_UP} Result := nil; {$ENDIF} NewNode := nil; memDoc := nil; try NewNodeXml := '<a>' + ConteudoXML + '</a>'; memDoc := xmlReadMemory(PAnsiChar(AnsiString(NewNodeXml)), Length(NewNodeXml), nil, nil, 0); NewNode := xmlDocCopyNode(xmlDocGetRootElement(memDoc), aDoc.doc, 1); DocNode := xmlDocGetRootElement(aDoc); { Se docElement possui prefixo o mesmo tem que ser removido } vdocElement := copy(docElement, Pos(':', docElement) + 1, Length(docElement)); if (vdocElement <> '') then DocNode := LibXmlLookUpNode(DocNode, vdocElement); if (DocNode = nil) then raise EACBrDFeException.Create(cErrElementsNotFound); Result := xmlAddChildList(DocNode, NewNode.children); finally if NewNode <> nil then begin NewNode.children := nil; NewNode.last := nil; xmlFreeNode(NewNode); end; if (memDoc <> nil) then xmlFreeDoc(memDoc); end; end; O erro esta ocorrendo pois na chamada da função AdicionarNode não é passado o docElement (Pedido), por este motivo é inserido a tag de assinatura na TAG <CancelarNfseEnvio> ao invés da tag <Pedido>. SignNode := LibXmlFindSignatureNode(aDoc, SignatureNode, SelectionNamespaces, infElement); if (SignNode = nil) then SignNode := AdicionarNode(aDoc, SignatureElement(URI, True, IdSignature, FpDFeSSL.SSLDgst)); Para fazer um teste alterei o ultimo parâmetro da função passando o DocElement (Pedido) que seria a TAG onde a assinatura deveria ser inserida. SignNode := AdicionarNode(aDoc, SignatureElement(URI, True, IdSignature, FpDFeSSL.SSLDgst),'Pedido'); Dessa forma conseguir autorizar o cancelamento, porém tenho total certeza que não é a forma certa de resolver, gostaria de uma sugestão dos entendidos no assunto, estou tentando o possível aqui. Grato! XML Com assinatura no local errado.xml XML assinatura no local certo.xml

Olá pessoal, Estou realizando a integração NFS-e com o município de Joinville e ao realizar os testes foi constatado que a URL de Homologação está incorreta e o arquivo do provedor não segue o padrão dos demais. Realizei as seguintes alterações para corrigir a URL e padronizar com os demais arquivos: Alterado URL de Homologação no arquivo arquivo Cidades.ini [4209102] Nome=Joinville UF=SC Provedor=ISSJoinville NomeURL_H=nfemwshomologacao NomeURL_P=nfemws Padronizado o arquivo ISSJoinville.ini para utilizar as variáveis de URL definidas no arquivo Cidades.ini [URL_P] RecepcaoLoteRPS=https://%NomeURL_P%.joinville.sc.gov.br/NotaFiscal/Servicos.asmx?wsdl [URL_H] RecepcaoLoteRPS=https://%NomeURL_H%.joinville.sc.gov.br/NotaFiscal/Servicos.asmx?wsdl Anteriormente estava da seguinte forma [URL_P] RecepcaoLoteRPS=https://nfemws.joinville.sc.gov.br/NotaFiscal/Servicos.asmx?wsdl [URL_H] RecepcaoLoteRPS=https://nfewshomologacao.joinville.sc.gov.br/NotaFiscal/Servicos.asmx?wsdl Segue em anexo os arquivos alterados. Cidades.ini ISSJoinville.ini

Olá pessoal, Alguém está entregando a declaração?

No meu entendimento você deve armanenar todos os valores unitário e na hora de fazer a venda realizar a multiplicação. No caso, se o vICMS do fornecedor foi R$: 120,00 para 10 unidades você teria que armazenar o R$12,00 para usar na venda. Portanto se fazer uma venda de 5 unidades estaria informando R$:60,00 (12 * 5). Isso para os demais campos (ST Base, ST Valor, FCP ST Base, FCP ST Valor). Minha maior duvida até o momento é como preencher o campo pST. É a aliquota de ICMS do fornecedor (pICMS)? Outra questão é se deve ser pego o valor da ultima entrada ou pela Média? Estou implementando no sistema uma configuração para disponibilizar as duas opção, ai o cliente/contador informa qual deve ser utilizado.

Olá pessoal, tenho uma dúvida com relação ao Responsável Técnico. Na NT cita o seguinte: A dúvida é a seguinte essas UF que serão validadas, são a UF do emitente ou a UF do destinatário? Exemplo: Estou enviando uma NFe onde o emitente é de SC (Exige Responsável Técnico) para o destinatário de RJ (Não exige Responsável Técnico) neste caso teria que enviar os dados pois é validado o emitente? No caso SC?

Olá Pessoal, Estou obtendo o erro strdup function failed ao realizar a assinatura do pedido de cancelamento utilizando XmlSec . Testando com msXml consigo realizar o pedido de cancelamento e funciona perfeitamente. Pelo que pude conferir a estrutura do XML está correta, conforme o exemplo disponibilizado pelo provedor, inclusive o atributo Id. Segue em anexo os XML de exemplo, cancelamento autorizado(msXml) e cancelamento com erro (XmlSec) . Caso alguém tiver alguma sugestão fico agradecido. Exemplo Cancelamento.xml Cancelamento erro assinatura.XML Cancelamento Autorizado.xml

Isso mesmo, pelos mesmos campos de ST Retido.

Não é apenas para combustível. Note que nos grupos ICMS60 e ICMSSN500 também possui esses campos de repasse. Há estados que estão começando a exigir essas informações com o objetivo de controlar melhor sonegações e pedidos de Ressarcimento, Restituição e Complementação. Dessa forma seria possível identificar qual foi o valor de ICMS-ST pago no inicio da cadeia e qual realmente foi o valor que chegou na operação final, com isso é possível saber se os pedidos de Restituição e Complemento estão corretos.

Bom dia, deve ser informado os dados de ST Retido no momento que for realizar a operação de saída da mercadoria na qual foi adquirida com ICMS-ST. Tanto mercadoria adquiridas por Remetente direto (Recebida da industria) quando Remetente indireto (Recebido de repasse - CST 60 CSOSN 500) Referente ao ICMS Efetivo, não sei se alguma UF está solicitando essa informação. O mistério desse grupo é: Como realizar o cálculo? Se basear na última entrada? Média Ponderada? Aqui há contabilidade exigindo a informação se baseando na última entrada, já outras contabilidades exigem pela Média Ponderada. Como não há nenhuma base legal informando como deve ser realizado o cálculo, vamos implementar as duas formas e disponibilizar uma configuração para o cliente parametrizar conforme a contabilidade solicitar.

Entendo que se o contribuinte tiver valor a complementar poderá entregar a declaração sem o uso do DRCST, ou seja, através do arquivo magnético. Porém, pelo que pude compreender, se tiver valor a restituir/ressarcir deverá entregar a DRCST. Pra mim isso também é besteira, pois terá que ser feito todo o levantamento para saber se tem valor a complementar ou restituir/ressarcir, então se já fez todo o levantamento pode tranquilamente entregar a DRCST, pois o processo vai ser o mesmo para calcular o ressarcimento/restituição e complemento.

Portanto, no meu ver o jeito é entregar a declaração sem essa informação, pois a hora que passar a exigir essa informação, já era a DRCST, vai ser difícil algum cliente que vai ter acesso a essa informação.

Prezados, Apenas repassando um detalhe: Estive realizando alguns testes de envio de RPS hoje para Joinville e obtive o mesmo erro citado pelo Fernando. Realizando alguns testes pude perceber que o erro estava ocorrendo pelo fato de possuir acentuação em uma string do XML. Então apenas para deixar relatado, caso mais alguém passar por este problema verifique também se não há acentuação no XML. Bom trabalho a todos.

Bom dia BigWings, Testei com esse xsd e funcionou corretamente, tanto em OpenSSL quanto WinCrypt. Esse xsd não está no repositório? Pois com o xsd do repositório está ocorrendo o erro. O correto não seria trocar o xsd do repositório por este em anexo?

Vamos realizar alguns testes aqui pra verificar se o validador aceita declaração sem o registro 2131, caso aceitar, talvez podemos concluir o desenvolvimento sem o preenchimento deste registro.

Boa tarde Pessoal, publicado no dia 05.04.2019 as alterações 4023° a 4033°: https://www.legisweb.com.br/legislacao/?id=376463

Segue XML em anexo teste.xml Esse outro XML em anexo (aut.xml) consegue autorizar, porém sem o uso de OPENSSL. aut.xml

Boa tarde BigWings, Não seria este o caso, não estou lendo os arquivos da rede, estou lendo do D:\. Inclusive alterei de diretório para verificar se resolveria o problema, mas persiste.

Boa tarde pessoal, estou obtendo o seguinte erro ao validar o XML para o provedor ISSJoinville: Erro na validação: the schema itself is not valid Detalhe: O erro ocorre somente utilizando OPENSSL. Alguém teria alguma sugestão? Estou com os fontes e schemas atualizados, já troquei o diretório dos schemas para certificar e conferi as permissões.