João Paulo Müller
-
Total de ítens
326 -
Registro em
-
Última visita
-
Days Won
2
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por João Paulo Müller
-
-
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.
-
Em 20/08/2019 at 11:31, Lucas Schatz disse:
Por enquanto estou removendo essas notas
é crédito a menos p/ o cliente 
...
OU, conseguir todo o histórico tributário da mercadoria... (ferrou)
CitarPORTARIA 254 SEF, DE 14-8-2019(PE-SEF DE 26-8-2019)
O SECRETÁRIO DE ESTADO DA FAZENDA, no uso das atribuições estabelecidas no inciso I do art. 7º da Lei Complementar nº 381, de 7 de maio de 2007,
RESOLVE:
Art. 1º O Registro 2131 do Bloco 2 do Anexo Único da Portaria SEF nº 378, de 2018, passa a vigorar com a seguinte redação:
“REGISTRO 2131 ......................................................................
......................................................................................................
O preenchimento deste registro passa a ser obrigatório para os demonstrativos dos períodos de referência a partir de janeiro de 2020.
............................................................................................” (NR)
Art. 2º Esta Portaria entra em vigor na data de sua publicação.PAULO ELI
Secretário de Estado da Fazendahttp://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.
-
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?wsdlAnteriormente 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.
-
Olá pessoal,
Alguém está entregando a declaração?
-
15 minutos atrás, Leonardo de Alice disse:
Legal @adilsonpazzini, mas eu fiquei com outra dúvida.
No link da TecnoSpeed ele diz que o vICMSSubstituto deve receber o vICMS da nota de entrada, mas eu não vejo sentido nisso, porque eu posso comprar 10 unidades de meu fornecedor e fazer 5 vendas de 2 unidades, para clientes diferentes.
Outra coisa, a empresa pode ter comprado de mais de um fornecedor, com alíquotas diferentes. Deve ser feita uma média? Ou pegar a última?
Tá bem complicado entender o que a SEFAZ quer.
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.
-
1
-
-
Olá pessoal, tenho uma dúvida com relação ao Responsável Técnico.
Na NT cita o seguinte:
CitarNão informado o grupo de informações do responsável técnico Observação: Implementação a critério da UF Observação: Implementação futura, exceto as UF AM, MS, PE, PR, SC e TO, nas quais estas regras já estão em vigor em ambiente de teste na data da publicação da versão 1.30 desta NT, e entrarão em vigor em ambiente de produção no dia 03 de junho de 2019
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
-
1 hora atrás, Mauricio Elias disse:
Entendi.
E como pegar essa informação de uma nota de entrada de Remetente indireto (Recebido de repasse - CST 60 CSOSN 500) ?
Teria que ser por estes mesmos campos recebidos né? Pq não virá cálculo algum nela ?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.
-
2
-
-
15 horas atrás, rafa_frantz disse:
Bom...ai entramos na questão de entendimento:
ALTERAÇÃO 4.027 - O art. 26 do Anexo 3 passa a vigorar com a seguinte redação:
"Art. 26. .....
§ 1º O DRCST será encaminhado:
I - para o período de referência em que ocorrer as situações previstas nos incisos I e II do caput do art. 25 deste Anexo;
II - para o período de referência em que ocorrer a compensação prevista no § 32 do art. 25-C deste Anexo; e
III - quando requisitado pela fiscalização.
.....
§ 3º O contribuinte que efetuar o recolhimento a título de complementação de ICMS-ST sem a entrega do DRCST deverá manter à disposição do Fisco, no mínimo pelo prazo decadencial, arquivo magnético contendo a apuração dos valores devidos a título de complementação.
§ 4º Na hipótese do § 3º deste artigo, deverá ser utilizada a metodologia de cálculo prevista nesta Seção." (NR)
Oque vc entende dessa alteração?
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.
-
4 minutos atrás, rafa_frantz disse:
Aceita sim....pode testar....
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.
-
2
-
-
19 horas atrás, BigWings disse:
Experimente substituir o xsd de schema com o anexo.
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?
-
32 minutos atrás, rafa_frantz disse:
Gerar no registro 2130 com indicador 2 - Remetente indireto, obriga a geração do registro 2131, inclusive apresenta essa inconsitência no momento da geração.
Essas informações da NFe que houve a retenção não vem no XML da NFE de entrada, logo, deve-se solicitar ao cliente que entre em contato com o seu fornecedor e pergunte.
E até então ninguém vai conseguir essas informações para então transmitir a DRCST nessa condição. E então paramos por ai. Pois por ser uma informação obrigatória não é possível a entrega do DRCST.
Agora olhando essas últimas alterações meio que por cima, há a possibilidade de caso exista apenas a complementação, de então efetuar o recolhimento desse valor calculado sem a transmissão da DRCST. Oque em teoria permite que os clientes ao menos paguem o valor que entendem por devido.
Mas para o caso de solicitação de restituição ou ressarcimento, obriga ao contribuinte a transmissão do DRCST, fazendo então a lógica de todas as informações que até então temos, do decreto 1818 e correio circular 48/2018.
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.
-
1
-
-
Boa tarde Pessoal, publicado no dia 05.04.2019 as alterações 4023° a 4033°:
-
-
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.
-
Erro ao enviar lote para Blumenau/SC
em ACBrNFSe
Postado · Editado por João Paulo Müller
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?