Painel de líderes

Olá pessoal! Desde a ativação no ambiente de produção das regras de validação da Nota Técnica 2023/004, alguns membros de nossa comunidade tem relatado estar recebendo a rejeição: Essa rejeição é devolvida quando é informado na nota o tipo de pagamento Cartão de Crédito (tPag=03), Cartão de Débito (tPag=04) ou Pagamento Instantâneo (PIX) - Dinâmico (tPag=17) e não é informado o grupo card. Conforme regra de validação da própria rejeição: Considerando os múltiplos relatos em diferentes Sefaz e o fato de a implementação da regra ser opcional a critério da UF. Nossos colegas da AFRAC buscaram mais informações, entrando em contato com as Sefaz de PB, PE, MG e RJ questionando sobre a ativação desta regra em específico, obtendo as seguintes respostas: Sefaz de MG: “Vamos retornar à regra anterior, ou seja, sem ativar a validação em questão, portanto, apenas para cartão. Para isso, teremos que subir uma versão da aplicação. Enquanto isso, a opção é usarem o código 20 ao invés do 17." Sefaz da PB: “Quem informava o código 17 para Pix estático deve informar o código 20. Iremos publicar no site oficial da Sefaz ainda hoje (01/07) após às 17h." Portanto, para evitar a rejeição, o Pix deverá ser informado no código 20 e, assim, evitar o preenchimento do código de autorização desse formato de pagamento. Em tempo, irão realizar pedido à SVRS para desativar temporariamente a regra de validação Y04-10 para o estado da Paraíba. A expectativa é que a SVRS faça isso até amanhã pela manhã (02/07), portanto, no momento, a solução é informar o código 20 no Pix para não obrigar a informar o grupo de cartões, onde terá que informar o E2dID Sefaz de PE: Aguardando resposta. Sefaz do RJ: "Isso ocorreu porque as empresas estavam acostumadas a informar o código 17 para o PIX. Agora elas devem informar o código 20 se for PIX estático. Se continuarem a informar o código 17 é o PIX dinâmico e a regra de validação exige informar o grupo card, pelo menos o código de autorização do PIX (endToEndId - e2eid ). A AFRAC encaminhou pedido de reavaliação para desativação dessa regra de validação nas UF´s que não disciplinaram a interligação dos pagamentos tal como realizado no RS e MT." Este tópico foi feito baseado em comunicado publicado no Radar AFRAC e que pode ser encontrado na íntegra AQUI.

Boa tarde Juliomar. Na empresa onde trabalho usamos a linguagem C# no desenvolvimento do nosso sistema ERP. Nós não utilizamos as libs fornecidas pela ACBR, porém fazemos algumas pesquisas aqui no fórum esporadicamente, pois sabemos que vocês fornecem valiosas informações. Eu havia pesquisado sobre esse erro na MDF-e aqui, e como vi que também haviam outras pessoas com o mesmo problema sem uma aparente solução, resolvi compartilhar a solução que encontramos. Espero que ajude.

// Parâmetros do método Enviar: // 1o = Número do Lote // 2o = Se True imprime automaticamente o DAMDFE // 3o = Se True o envio é no modo Síncrono, caso contrario Assíncrono. // Obs: no modo Síncrono só podemos enviar UM MDF-e por vez. ACBrMDFe1.Enviar(StrToInt(vNumLote), True, True);

Bom dia Italo ! Mas essa URL é a que eu estou usando desde o princípio, inclusive comentei que precisei fazer essa alteração porque a atual no ACBrNFSeXServicos.ini não é válida. A princípio coloquei o ACBrNFSeXServicos.ini na mesma pasta do exe, para que após a resolução do problema possamos fazer a alteração definitiva nessa URL. Grato.

Bom dia a todos, tive um problema de imprimir um boleto do tipo (carne), porém a impressão estava quebrando o terceiro boleto e apareciam dois na folha e espaço em branco abaixo. Fiz uma modificação no fortes report para que issACBrBoletoFCFortesFr.dfmo não acontece, estava acontecendo por causa do tamanho do campo. Segue ajuste para analise:

Olá @Cleber Ferreira Tudo bom?! Independente da resposta dos órgãos, eu creio que é mais vantagem seguir logo essa regra. Pois se a UF não obrigar, também não irá impedir que seja seguida... E lá no futuro já estaremos atendendo, caso a mesma volte atrás quanto a sua obrigatoriedade.

Oi meu amigo... Como você adicionou o tpIntegra = 2, o componente cria o grupo card e joga o mesmo lá dentro. Dessa forma você passa pela validação YA04-10.

nosso amigo @Diego A. Folieni fez uma postagem a respeito. Vamos acompanhar por lá os desdobramentos. Aparentemente alguns estados estão validando e outros não.

Também recebemos relatos de que a Sefaz do Paraná devolveu está rejeição no dia 02/07/2024 pela manhã. Por volta das 12:15 e 12:25 ao tentar emitir era recebido Notas emitidas após este período foram autorizadas, dando a entender que a UF do PR também havia ativado a regra e a desativou após relatos de problemas. Um agradecimento ao membro de nossa comunidade @VagnerBegnini por compartilhar a informação conosco.

Problema resolvido. Já voltei a emitir o MDFe. Obrigado pela orientação.

Atualizei os fontes e agora informando a tpintegra como 2 passa em homologação e produção. Foi acionado uma novo meio de pagamento instantâneo também. Mais usando o 17 funciona perfeitamente agora

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde @Diego Reckziegel, Já esta no SVN.

boa tarde, o instalador normal para delphi e lazaru, desculpa meu erro, era só passar o parametro de false , tinha esquecido. obrigado a todos

Muito obrigado Victor, atualizei aqui e deu certo....

seus fontes estão desatualizados. favor verificar novamente fazer update ou revert no svn e depois rodar o instalador

Basta abrir o exemplo e mandar gerar marcando a opção salvar e tu vai ter um xml do soap e um completo de mdfe

Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo

Bom dia, Criada a TK-5677 para avaliação. Obrigado pela contribuição!!!

Você esta usando componente ACBrMDFe, ACBrLibMDFe ou ACBrMonitorPLUS ?

Bom dia @samdella, Ontem fiz um teste e tive o mesmo erro 500. Ai alterei as URLs ficando da seguinte forma: [3513405] ; Atualizado em 01/07/2024 Nome=Cruzeiro UF=SP Provedor=SiapNet Versao=2.00 ProRecepcionar=https://pmcruzeiro.geosiap.net.br/pmcruzeiro/issonline/ws/index.php HomRecepcionar=https://pmcruzeiro.geosiap.net.br/teste/issonline/ws/index.php Segui as orientações que se encontra no inicio do arquivo ACBrNFSeXServicos.ini O erro 500 desapareceu e o webservice do provedor passou a responder da forma correta. Te aconselho a fazer o mesmo, altere as URL segue a orientação que esta no inicio do arquivo e repita os testes.

Bom dia @NVTech, O melhor a fazer é entrar em contato com o contador dessa transportadora e questionar ele sobre o CFOP mais indicado para esse tipo de transporte.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado Bom dia, Acredito que o melhor caminho é consultar o contador responsável pela empresa para a correta orientação. Outros pontos. Seu cliente é transportadora? Ele que emite o CT-e? um caminho seria a informação da remessa constar nas NFe emitidas com o CFOP correspondente a remessa de transferencia e o CTe ser emitido normalmente, ou seja, quem vai identificar a operação é a NFe e não o CTe.

You can report the matter here, feel free.

só preencher o componente ACBrNFSeX e estará gerado. lembrando que o subforum é pra tratar relativo ao componente ACBrNFSeX

deu certo... brigaduuuuuuuuu

Sim é só tu colocar pra enviar no modo sincrono mas já faz um tempo que o sefaz está a avisa. no ACBrMDFe muda o terceiro parametro pra true

no svn

Olá pessoal! No dia 01/07/2024, alguns membros de nossa comunidade começaram a relatar que ao tentar emitir uma NF-e ou NFC-e estão recebendo a rejeição: Está rejeição foi introduzida na Nota Técnica 2023/001 em sua versão 1.00, no entanto, a mesma foi removida logo na versão 1.10 permanecendo assim até a sua versão 1.51 que é a mais atual. Hoje, dia 01/07/2024, está entrando em vigor no ambiente de produção a Nota Técnica 2023/004 que coincidentemente adiciona a seguinte rejeição: PORTANTO, se você está recebendo a rejeição 963 com a mensagem de Alíquota adrem, verifique se informou no tPag da respectiva nota valor diferente de 03, 04, 10, 11, 12, 13, 15, 17 e 18 e adicionou o grupo card. Se o fez, remova o grupo card, conforme Regra de Validação da própria rejeição: Aprovada a nota, também é muito importante que abram um Fale Conosco junto a respectiva Sefaz, relatando que a mensagem que está sendo devolvida está incorreta.

Boa tarde a todos, A troca do provedor já foi enviada para o SVN.

No svn

Por acaso você poderia compartilhar o código que usou para resolver o desafio? Na documentação deles tem apenas um exemplo em java.

Bom dia a todos Fiz atualização do ACBr dia 20/05/2024 e quando mando imprimir um danfe, ele imprime normalmente. Mas se eu clicar no botão de imprimir danfe novamente, ele imprime o mesmo danfe 2 vezes. Eu voltei o backup da ACBr que eu estava usando (atualizei em 12/09/2023) e funcionou normalmente. Testei também na demo/ACBr mudando o componente de impressão para o ACBrNFeDANFEFR e acontece o mesmo. Cada vez que eu mando imprimir o danfe, ele imprime o conteúdo do XML atual e mais o(s) anterio(es) na mesma impressão. Alguém mais está com esse problema?

No log do SVN consta como já corrigida essa questão. Então atualize novamente os fontes, e teste.

Olá pessoal! No dia 06/03/2024 foi divulgada a versão 1.50 da Nota Técnica 2020/001. A nova versão visa atender ao que foi disposto no Ajuste Sinief 43/23, mais especificamente o § 2º da cláusula décima quinta-C. Permitindo agora que os eventos de manifestação conclusivos, sejam eles Confirmação da Operação, Desconhecimento da Operação ou Operação Não Realizada possam ser registrados até duas vezes, sendo válido apenas o último registro. Então agora, conforme exemplo dado na própria NT, o destinatário pode confirmar uma operação, depois desconhecê-la e por fim confirmá-la novamente. É importante reforçar que o envio desses eventos devem ocorrer dentro do prazo de 180 dias a partir da data de emissão da NFe. A regra de validação da rejeição 594 foi alterada e passa a vigorar com a seguinte redação: Previsão de Implementação por parte da Sefaz Implantação Teste: 01/07/2024 Implantação Produção: 01/08/2024 Para quem utiliza as soluções ACBr, não precisa se preocupar com alterações, visto que é alteração do lado da SEFAZ/AN 91. Porem um ponto de atenção : Sistemas de monitoramento podem gerar conflitos de eventos, visto que o documento foi confirmado, depois houve o registro de operação não realizada pelo operador do sistema, caso algum sistema passar registrando o evento automático, por exemplo sistema de busca de XML e registrar novamente o evento de confirmação da operação, agora a SEFAZ irá acatar o evento novamente, não retornando duplicidade de registro de evento. E a validade é do ultimo evento conclusivo registrado. Então é importante que verifiquem se não há ferramenta que possa estar consultando em concorrência realizando a manifestação automaticamente antes da consulta. Leia a NT na íntegra AQUI.

Bom dia, O Banco precisa estar selecionado como: cobBancoDoBrasilAPI Ou se for passar via arquivo, "IndiceACBr=36" [Banco] IndiceACBr=36 CNAB=0 NumeroCorrespondente=0 VersaoArquivo=0 VersaoLote=0