Túlio de Pádua
-
Total de ítens
104 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Túlio de Pádua
-
-
Complementando, hoje foi publicada a versão 1.11 dessa NT e realmente houve adiamento. Nesse link tem ela.
-
2
-
-
Vi agora que já havia um tópico aberto, mas sem solução também:
-
Pessoal, recentemente algumas mensagens do ACBr estão ficando com problemas em strings acentuadas, por exemplo, a imagem abaixo é uma exceção da transmissão de uma carta de correção para o CTe, mas também ocorreu em outros DFes.
Pelo que vi o motivo foi uma alteração na unit ACBrUtil.XMLHTML, conforme essa nota no change-log:
Citar01/03/2024
-- ACBrUtil.XMLHTML --
[*] Alteração no ParseText pois o mesmo ao receber um XML no formato UTF-8
estava devolvendo-o no formato ANSI de forma indevida.
por: DSAMinha dúvida é, há um efeito colateral conhecido para justificar essa mudança, e então necessito em cada consumo de mensagens, logs etc, que são gerados pelo ACBr, fazer um tratamento para que sejam exibidas corretamente?
Ou se não não há, eu poderia fazer uma alteração local para deixar essa função como era antes (claro, eu controlaria isso localmente para que ao atualizar o ACBr isso fosse refeito).
Grato por qualquer ajuda.
-
Resposta da Sef/MG recebida hoje:
CitarBom dia, Túlio!
A NT2023.004 tem previsão aqui em MG de entrar em homologação na data de 25.03 e produção 01.07, onde será publicado um novo schema para essa NT.
Gentileza acompanhar no Portal NacionalOu seja, parece que vai ser adiado.
-
1
-
-
Já tem muito tempo, mas a base do ICMS comum também sofreu a redução de 61,11%. Aplicando essa redução nessa base o valor fecha.
-
Alteração nas URLs de homologação para as cidades de Monte Carmelo/MG e de Coromandel/MG, ambas utilizam eReceita.
-
Utilizando o seu exe eu consegui ver o problema em um dos campos. Recompilando com uma versão do Delphi mais recente (10), o problema não ocorria mais. Fora isso não aprofundei muito não, mas pode ser então algum problema da versão do Delphi e/ou Firedac pelo visto.
-
20 horas atrás, jose geraldo disse:
Boa Tarde Pessoal
Alguém conseguiu transmitir algum CT-e homologação ou produção para MG?
Não na versão 4.00, problema do retorno em branco. Abri um chamado lá há uns dias e me responderam isso abaixo. Imagino que o problema ainda se estenda.
-
1
-
-
Pessoal, se alguém estiver com problemas para o CTe 4.0 em MG, eles estão trabalhando nisso ainda, apenas avisando:
-
2
-
-
48 minutos atrás, Italo Giurizzato Junior disse:
Boa tarde Jeanny,
Já esta no SVN.
Italo, tive que fazer mais duas mudanças nesse arquivo para que funcionasse o status de serviço e o envio para o CTe-OS.
-
1
-
-
Alguns problemas, nesse tópico tem informações.
-
4 minutos atrás, JeannyPaiva disse:
SEF MG finalmente respondeu dizendo que eles estão certos e os demais que estão errados.
No manual realmente consta dessa forma
Ou seja, não irão alterar.
Alterei novamente a o fonte que havia enviado anteriormente apenas como teste para atender ao envio para MG e também para contingência (a versão anterior tinha atrapalhado o envio para SVC-SP).
* A rejeição do envio de eventos já foi realmente corrigida.
Que coisa, estou aguardando uma resposta deles, certamente mandarão essa mesma. Eu já tinha alterado localmente também para atender aos testes aqui, vou ver o seu se também como está. Uma pergunta, está conseguindo fazer o envio do CTe-OS?
-
1
-
-
Pois é, fiz outros testes aqui e até agora só MS está diferente, validando sem o hífen.
-
Realizando testes com esse evento o ACBr estava gerando um erro de schema: Falha na validação dos dados do Evento: --> 1845 - Element 'evCancPrestDesacordo': No matching global declaration available for the validation root.
Verificando, a rotina DefinirDadosMsg estava sem tratamento para esse evento ao gerar o trecho que é validado. Adicionei essas linhas no arquivo e tudo funcionou:
schevCancPrestDesacordo: begin AXMLEvento := '<evCancPrestDesacordo xmlns="' + ACBRCTE_NAMESPACE + '">' + Trim(RetornarConteudoEntre(AXMLEvento, '<evCancPrestDesacordo>', '</evCancPrestDesacordo>')) + '</evCancPrestDesacordo>'; end;-
1
-
-
Iniciei testes para o CTe 4.0, e ao transmitir tive a rejeição abaixo:
<?xml version="1.0" encoding="UTF-8"?> <retCTe xmlns="http://www.portalfiscal.inf.br/cte" versao="4.00"> <tpAmb>2</tpAmb> <cUF>50</cUF> <verAplic>MS_0.0.126</verAplic> <cStat>649</cStat> <xMotivo>Rejeicao: CTe emitido em ambiente de homologacao com Razao Social do destinatario diferente de CTE EMITIDO EM AMBIENTE DE HOMOLOGACAO - SEM VALOR FISCAL</xMotivo> </retCTe>
Conferindo no anexo I do MOC4.0, realmente está diferente, sem o hífen no "CTE":
No MOC da versão 3.0 já é com o hífen:
Para conseguir prosseguir com os testes eu alterei a constante "xRazao" lá na unit "pcteConsts", deixando conforme o layout do 4.0 espera:
Eu não fiz alteração para anexar aqui, pois nesse caso deve ser pensado em relação à versão 3.0, pois ela também deve ser mantida para compatibilidade. Então deve ser pensada uma maneira melhor para implementação, aqui nessa unit não há acesso à versão do componente que está sendo utilizada para chavear isso, então seria melhor criar outra constante, algo como "XRazao_3" e "xRazao_4"? Implementar direto na escrita do XML e conferir lá a versão?
-
1
-
-
Mesmo problema. MG não deve ter inicializado essa versão para homologação ainda, o jeito é aguardar ou testar com outra UF caso tenha certificado.
-
1
-
-
A cidade de Monte Carmelo/MG vai passar a utilizar o provedor eReceita a partir de 22/08/2022. Adicionei em anexo o arquivo ini com a alteração das URLs.
Eu também precisei fazer uma alteração no arquivo 'eReceita.Provider', pois o arquivo de envio do lote RPS não estava sendo assinado e eu estava recebendo rejeição, apenas ao alterar esse arquivo o envio passou a ser assinado. Sobre essa questão, se houver outra forma de utilização me informe por favor.
-
Bom, no meu caso era algo que se observado com mais critério eu poderia ter descoberto bem facilmente.
Esse usuário fez uma consulta no ano passado e passou vários dias sem fazer uma nova consulta. Logo, pela NT 2014.002 alguns documentos emitidos contra ele não tiveram NSUs associados pois ficaram além do prazo de 60d. Quando esse usuário voltou a fazer consultas, foram listados os documentos emitidos dentro do prazo de 60d, e os documentos emitidos após ele voltar a fazer as consultas.
-
1
-
-
14 minutos atrás, Túlio de Pádua disse:
Para fins de estatística, estou com o mesmo problema em um usuário. Abri um chamado pra tentar descobrir se era problema com as notas, mas pelo visto deve ser algo da Sefaz mesmo.
Se responderem coloco aqui.
Inclusive, olhando sua chave de acesso, e as minhas, elas foram emitidas pela mesma UF, PA.
-
Para fins de estatística, estou com o mesmo problema em um usuário. Abri um chamado pra tentar descobrir se era problema com as notas, mas pelo visto deve ser algo da Sefaz mesmo.
Se responderem coloco aqui.
-
1
-
-
Anexado, sobre os schemas eu não alterei nada não.
-
1
-
-
Deu certo, o conteúdo da tag 'Id' estava incorreto. Realmente estão aceitando inutilização de NFe para pessoa física.
Anexei os arquivos XML de envio e retorno da inutilização. A diferença é o nome da tag que mudou de 'CNPJ' para 'CPF' e recebe 11c. Mas no 'Id' o CPF deve ser formatado com 14c (zeros à esquerda).
Pra testar isso eu fiz uma alteração grosseira nos fontes mesmo. Posso tentar implementar seguindo o padrão dos fontes do ACBr e anexar aqui, ou se a própria equipe quiser fazer a implementação também.
51210000522637817355920000000001000000001-inu.xml 51210000522637817355920000000001000000001-ped-inu.xml
-
4
-
-
Pessoal, boa tarde, alguém tá sabendo algo sobre a inutilização de numeração de NFe para produtor rural em MT?
Segundo a Sefaz de lá isso já está implementado no servidor deles, aqui nesse link tem um resumo do que é esperado para o envio.
Eu fiz uns testes, e até forcei a alteração do nome da tag de 'CNPJ' para 'CPF' conforme sugere a orientação deles, mas sem sucesso (retornam erro de schema):
Estranho que eles não liberaram schema para download, nem NT alguma foi criada:
Trocamos alguns email com eles, mas a orientação deles é muito ruim. No último email enviamos os arquivos XMLs que foram gerados conforme esse "schema" que eles publicaram, aguando uma resposta ainda.
Mas estranhei isso ser publicado dessa forma, sem liberação de schema, sem NT, sem liberação por outras UFs.
-
Em 11/10/2021 at 14:28, Renato Rubinho disse:
Duas ideias:
Confirma a versão do midas.dll.
Mesmo sendo valores "inteiros", confirma as configurações regionais, pois podem estar com erro em separador decimal, por exemplo. Tenta forçar uma nova configuração.
Era a midas. Havia uma dll dessa lá na pasta system diferente da dll presente na pasta do sistema.
-
2
-
Alteração dos endereços para SVC-AN em homologação
em ACBrNFe
Postado
Houve alteração nos webservices do SVC-AN, por enquanto em homologação, conforme aviso da RFB:
ACBrNFeServicos.ini