Diego Foliene

Olá pessoal! Nos últimos dias temos recebidos diversos relatos de membros de nossa comunidade com problemas para realizar o processo de Manifestação do Destinatário, seja realizando o envio de evento ou a consulta de DistribuicaoDFe. Todos os relatos tinham em comum o fato de estarem conseguindo consumir os webservices de transmissão da NF-e normalmente, mas estarem recebendo as mensagens: Erro Interno: -2146893815 Erro HTTP: 0 URL: https://www.nfe.fazenda.gov.br/NFeRecepcaoEvento4/NFeRecepcaoEvento4.asmx Erro: 2148073481 Ou: Erro: WebService Distribuição DFe: - Inativo ou inoperante tente novamente. Erro interno: -2146893815 Erro HTTP: 0 URL: https://www1.nfe.fazenda.gov.br/NFeDistribuicaoDFe/NFeDistribuicaoDFe.asmx Erro: 2148073481 - Em casos assim, é sempre válido abrir um Fale Conosco junto ao fisco para que o mesmo fique ciente de que há algo errado. Abaixo reproduzido na íntegra temos a resposta que foi fornecida pelo membro de nossa comunidade @Jhonathan na qual ele demonstra um passo a passo que executou para resolver um erro semelhante que havia enfrentado anteriormente com NFC-e e que também de acordo com múltiplos relatos de colegas da comunidade resolveu o problema agora com a manifestação do destinatário: 1- Vá até o Painel de Controle do Windows. 2- Escolha a Opção "Opções da Internet"; 3- Vá até a aba “Avançadas”; 4- No bloco “Configurações”, vá até as últimas opções e deixe configurado como na imagem abaixo: 5- Vá em executar, digite certlm.msc para abrir a interface de certificados, caso esse comando não funcione, utilize o comando certmgr.msc. Remova estes certificados listados na imagem abaixo: 6- Execute como Administrador o InstaladorCadeias_1.0.2.0.exe, clique em Instalar e aguarde até que o processo seja finalizado. 7- Execute o FixCrypto_TLS1_2_Windows.reg. 8- Descompacte o CA.zip e execute o ac soluti ssl ev.cer e o Raiz-icp-brasil v10.cer. 9- Reinicie a máquina e teste novamente a comunicação com a Sefaz.

Disponibilize o Log gerado pelo ACBrMonitorPLUS para análise.

Bom dia! Entendi. Mas para este caso, o comportamento me parece estar correto. Veja como é a rotina que faz a substituição: function ChangeLineBreak(const AText: String; const NewLineBreak: String = ';'): String; begin Result := AText; if Trim(Result) <> '' then begin // Troca todos CR+LF para apenas LF Result := StringReplace(Result, CRLF, LF, [rfReplaceAll]); // Se existe apenas CR, também troca os mesmos para LF Result := StringReplace(Result, CR, LF, [rfReplaceAll]); { Agora temos todas quebras como LF... Se a Quebra de linha final for diferente de LF, aplique a substituição } if NewLineBreak <> LF then Result := StringReplace(Result, LF, NewLineBreak, [rfReplaceAll]); end end; Fazendo um teste aqui em meu ambiente com o valor sLineBreak definido na configuração de quebra de linha, quando a string entra na rotina e também quando sai ela tem o valor: 'Teste do envio de carta de correcao com '#$D#$A'quebra '#$D#$A'de '#$D#$A' linha' E eu recebo a seguinte validação de: Mesma coisa se utilizo o #13 e utilizando o #10 o NewLineBreak tem o mesmo valor de LF. Portanto, você precisa definir um caractere específico para que seja feita a substituição mesmo. Ai pode ser o ; o | \r\n ou qualquer outro caractere ou sequência de caracteres que julgar fazer mais sentido.

Mas a config de quebra de linha foi respeitada? Apenas para garantir que estamos falando do mesmo caso. Quando você mencionou seu problema, eu fiz um teste de emissão de uma carta de correção, onde na propriedade xCorrecao eu alimentei desta foram: xCondUso := 'Teste do envio de carta de correcao com'+sLineBreak+'quebra'+sLineBreak+'de'+sLineBreak+'linha'; e vi que independente do valor que colocava em TWebServicesConf.QuebraDeLinha, ele sempre gerava meu XML com: <xCorrecao>Teste do envio de carta de correcao com ;quebra ;de ; linha</xCorrecao> Depois de aplicada a correção mencionada nas revisions, ele passou a substituir o sLineBreak pelo caractere de quebra de linha que eu defini. Isso não está ocorrendo para você?

@NovoRJ, por favor, veja este tópico:

Boa tarde @MarcosRWeimer e @NovoRJ. Por favor, atualizem seus fontes e façam um novo teste.

Enviei ao SVN nas revisions 35102 e 35103 ajustes visando corrigir o problema. Por favor, queira atualizar seus fontes, reinstalar o ACBr para realizar novos testes e reportar qualquer problema.

Bom dia! Por favor: Antes de fazer a transmissão do CTe certifiquem-se de que a versão configurada é a 4.00 enviando o comando CTe.SerVersaoDF("4.00"). Certifiquem-se de estar enviando no comando que estão utilizando para transmissão o parâmetro para que o modo de envio seja síncrono. Usando o CTe.CriarEnviarCTe como exemplo: CTE.CRIARENVIARCTE("SeuArquivoINI",,,,,,,0)

Bom dia! Sim, foi possível reproduzir o problema. Estou atuando em uma correção para o mesmo.

Boa tarde! Estou verificando esta questão. Fornecerei um parecer neste tópico na medida que for descobrindo mais informações. #TK-5866-2

Situação resolvida no tópico abaixo:

Boa tarde @fredsmartfull! Altere seu arquivo ACBrNFSeXServicos.ini adicionando uma linha Params para que fique desta forma: [3525904] ; Atualizado em 03/01/2024 Nome=Jundiai UF=SP Params=Dividir100:|Aliquota4Casas: Provedor=Giss Versao=2.04 ProRecepcionar=https://ws-jundiai.giss.com.br/service-ws/nf/nfse-ws Informe a alíquota no arquivo INI sem dividir por 100: [Valores] ValorServicos = 25,00 BaseCalculo = 25,00 Aliquota = 02.01 ValorIss = 0,50 ISSRetido = 2 Veja se o resultado fica conforme o solicitado pelo provedor.

ISS+NomedoMunicípio significa que a administração municipal é a responsável pelo web service. Tente contato na prefeitura.

Olá pessoal! Foi compartilhado no canal #sefaz em nosso Discord, no dia 29/08/2024, o seguinte aviso que apareceu ao acessar a página https://portalsped.fazenda.mg.gov.br/spedmg/: Atualização: O aviso foi removido. Então não temos certeza se a manutenção ainda está planejada.

Olá pessoal! Foi publicada a Portaria SEFAZ Nº 159 DE 19/08/2024 que estabelece a internalização do ECONF para o estado do Mato Grosso. A portaria acrescenta nas já existentes portarias n° 160/2021-SEFAZ, de 15/09/2021 e n° 177/2021-SEFAZ, de 3/09/2021 que dispõe sobre as condições, as regras e os procedimentos para utilização e os obrigados ao uso da NF-e e da NFC-e respectivamente, adicionando novos artigos relacionados ao ECONF. Os efeitos da portaria passam a vigorar na data de sua publicação. Lembrando que as soluções ACBr estão de acordo com as implementações para que seja utilizado o ECONF conforme exposto no tópico abaixo, permitindo assim que atendam a legislação para o MT. EDIT 08/10/2024: Recebemos novas informações de que o a portaria em questão na verdade internaliza o E-CONF no estado. Portanto o ECONF é opcional no estado, com portaria estabelecendo a obrigatoriedade ainda a ser publicada.

Bom dia @fredsmartfull. Foi gerada uma nova compilação da Lib, por favor, queira atualizar a lib para realizar novos testes e reportar qualquer problema.

Olá pessoal! Conferindo no Portal da NFe é possível observar que a Sefaz de São Paulo está com contingência agendada para o dia 08/09/2024, com previsão de início às 06h00 e término às 20h00 do mesmo dia. Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo: Um agradecimento ao membro de nossa comunidade @Felipe Mariano por compartilhar a informação no canal #sefaz em nosso Discord.

Boa tarde! Não basta apenas alterar o .so. Também existe uma diferença na forma como você faz o bind e a chamada dos métodos, pois na Lib MT, você precisa passar um ponteiro como Handle. Mais detalhes em ACBrLib e MultiThread

Boa tarde! Muito obrigado! Eu abri o arquivo schema e realmente consta a informação, não estava encontrando antes devido a um erro no filtro que eu estava usando para buscar nos arquivos. Enviei ao SVN na Rev-30518 uma alteração modificando na rotina de configuração o parâmetro do número de ocorrências para código pais do grupo serviço de -1 (não adicionar no XML) para 0 (adicionar no XML quando informado). Vou verificar possibilidade uma nova compilação da Lib junto ao time responsável. Caso não seja possível, na próxima compilação oficial deve englobar a alteração.

Bom dia. Vou verificar. Conforme mencionei antes, não tem o campo no arquivo, então precisaria alterar no schema também. Por favor, pode disponibilizar a mensagem de erro na íntegra para confirmarmos e conferirmos se ela exibe qual campo deve ser informado?(Há um CodigoPais no grupo de serviço e também um no grupo do tomador).

Olá pessoal! Foi publicado no dia 26/08/2024 Correio Eletrônico Circular SEF/DIAT/Nº 13 / 2024 reforçando aos contribuintes de Santa Catarina o início da obrigatoriedade da emissão de NFCom a partir de 01/04/2025. Também é reforçado que todas as empresas prestadores de serviço de comunicação já estão credenciadas no ambiente de homologação para realizar testes de emissão e o contribuinte pode realizar o credenciamento voluntário no ambiente de produção desde que observe: Artigos 2° e 7°-C, do Anexo 7 ao RICMS/SC (necessidade de Autorização de Uso de Processamento de Dados – AUPD). ATO DIAT n° 31/2023 que define as regras para credenciamento de empresa desenvolvedora de sistema eletrônico. ATO DIAT nº 32/2023 que define os requisitos técnicos para os programas aplicativos utilizados para a emissão dos documentos fiscais modelos 21, 22 e 62. ATO DIAT nº 44/2023 que define, nos termos do § 5º do art. 198 do Anexo 11 do RICMS/SC-01, o cronograma, a forma e os requisitos de credenciamento para a emissão da Nota Fiscal Fatura de Serviços de Comunicação Eletrônica-NFCom.

Conferindo nos fontes nativos, realmente, não é informado o <CodigoPais>. Tanto que se você abrir a pasta dos schemas do provedor e buscar pelo termo CodigoPais, não vai encontrar nenhuma menção. Será necessário uma alteração nos fontes para que seja adicionada a tag.

Boa tarde! Um momento, por favor, vou buscar mais informações a respeito.

Olá pessoal! No dia 26/08/2024 foi publicada a versão 1.04 desta nota técnica. A nova versão corrige o nome do Webservice do CTe simplificado incluindo o V4 no final, mudando efetivamente o nome do serviço de CTeRececpcaoSimp para CTeRecepcaoSimpV4. Também nesta nova versão é alterado o texto da regra de validação G043, corrigindo as menções de vRec e vPrest para vTRec e vTPrest, dando a regra a seguinte redação: As datas de implementação em homologação e em produção permanecem as mesmas. Leia a versão 1.04 desta nota técnica AQUI.