Túlio de Pádua

Que erro?

Resolvido. Algumas dependências estavam em uma unidade mapeada e isso era o problema. Colocando um net use no script para mapear novamente a unidade de rede funcionou.

Pessoal, alguém usa Jenkins mas com projetos em Delphi 7? Com as versões mais recentes a integração é mais tranquila usando MSBuild, mas com Delphi 7 não sei qual o melhor caminho. O projeto é um bpg, e via linha de comando usando make funciona. Tentei o Jenkins configurando o passo de linha de comando do Windows, mas dá falta de dependências. Essas dependências já estão configuradas no arquivo dcc32.cfg, e chamando via linha de comando (o make, que por sua vez dispara o dcc para cada projeto do bpg), ele consegue buscar de lá certo e compilar. Já o Jenkins não consegue, ou estou eu fazendo algo incorreto claro. Se alguém trabalha assim e possui alguma informação que possa ser útil eu agradeço.

Houve alteração nos webservices do SVC-AN, por enquanto em homologação, conforme aviso da RFB: ACBrNFeServicos.ini

Complementando, hoje foi publicada a versão 1.11 dessa NT e realmente houve adiamento. Nesse link tem ela.

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: Minha 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: Ou seja, parece que vai ser adiado.

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. ACBrNFSeXServicos.ini

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.

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.

Pessoal, se alguém estiver com problemas para o CTe 4.0 em MG, eles estão trabalhando nisso ainda, apenas avisando:

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. ACBrCTeWebServices.pas

Alguns problemas, nesse tópico tem informações.

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?

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; ACBrCTeWebServices.pas

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?

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.

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. ACBrNFSeXServicos.ini eReceita.Provider.pas

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.

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.

Anexado, sobre os schemas eu não alterei nada não. ACBrNFeWebServices.pas pcnInutNFe.pas pcnRetInutNFe.pas