Painel de líderes

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.

https://acbr.sourceforge.io/ACBrMonitor/MDFeEnviarMDFe.html bAssincrono - Por padrão o envio é Assíncrono, informa "False" para envio Sincrono

Diferenças sobre o fpPagamentoInstantaneo e fpPagamentoInstantaneoEstatico:

bastando trocar para False o bAssincrono

não leia bem o nome do parametro ACBrMDFe1.Enviar(NextValue('SEQ_LOTE'),False, True)

Encontrei: (nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] )

as novas versões do FastReport, permitem gerar o relatório como Imagem, em SVG ou PNG

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Amigo, resolvi informando a propriedade tpIntegra := tiNaoInformado; PROBLEMA RESOLVIDO

Não faz diferença o tipo de envio, síncrono ou assíncrono, a rejeição diz que o CTe não existe, então provavelmente está informando a chave errada, ou o CTe informado ainda não foi recepcionado pela SEFAZ. O evento é enviado direto para a SEFAZ autorizadora do emitente, então não tem nada o que sincronizar entre as SEFAZ e ambiente nacional, então é mais um indício que a chave não existe. A única explicação era estar enviado em ambientes diferentes. Isso não faz nenhum sentido, o método Enviar é para envio de CTe, então o componente vai pegar o XML que está carregado e tentar autorizar o CTe como se fosse seu (não o evento de prestação em desacordo), óbvio que vai dar erro.

Quero compartilhar um feedback...... Tenho uma rotina para enviar as notas em massa para qualquer destinatário de e-mail. E alguns clientes querem ter a possibilidade de enviar XML e PDF. Ela gera os arquivos em um pasta temporária, compacta, anexa no e-mail, envia e apaga a pasta temporária. Com pouco mais de 100 notas e base de dados em nuvem, o procedimento que antes demorava em torno de 1minuto e 20 segundos, passou para 8 segundos. Isso apenas trocando o motor do gerador para ACBrNFeDANFeFPDF. Obrigado equipe ACBr que proporciona tudo isso para nós.

Olá pessoal! Foi publicado no dia 28/06/2024 uma notícia confirmando a publicação de portaria conjunta que aprova o leiaute do eSocial em sua versão S-1.3. Essa nova versão finaliza os ajustes necessários para substituição da DIRF. Além do novo leiaute foi publicada uma nova versão da Nota Técnica nº04/2024 revisada que traz os ajustes necessários no eSocial para o projeto eConsignado. As datas para implementação são: Nota Técnica 04/2024 - Revisada - Itens 3.2 e 3.3: Implantação no ambiente de produção restrita: 08/07/2024. Implantação no ambiente de produção: 01/08/2024. Versão S-1.3 do eSocial: Implantação no ambiente de produção: 02/12/2024 Convivência entre a versão S-1.2 e a versão S-1.3: até 02/02/2025* *Eventos S-1210 (S-5002) e S-2501 devem ser enviados exclusivamente na versão S-1.3 a partir do período de apuração 01/2025. E como fica o ACBr? A nova versão do leiaute e nota técnica fazem com que seja necessário alterações nos fontes do ACBr para implementação das mesmas. Foi criado em nosso backlog a #TK-5666 para adequação a NT04/2024 e a #TK-5666-1 para adequação a versão S-1.3 Leia a notícia na íntegra AQUI. A versão revisa da NT04/2024, do leiaute S-1.3 e também do Manual de Orientação do eSocial podem ser encontradas AQUI.

Boa tarde Era o client_secret que estava errado. A última letra que deveria estar maiúscula e estava minúscula. Obrigado pela ajuda @EliasCesar

Boa tarde, Deu certo obrigado

Já se passou muito tempo neste tópico, porém pode ser relevante: GitHub - anlopes123/ExpertDelphiReplaceComponente: Experte para trocar componente quickreport para fortes reporte

Boa tarde @samdella, O provedor SiapNet possui 3 formas de envio: Envio em Lote Assíncrono, Envio em Lote Síncrono e Envio Unitário. Esse problema ocorre com as 3 formas de envio? Configurando o componente para salvar os arquivos Soap, é salvo o arquivo soap de retorno do envio?

Boa tarde, estou enviando no modo síncrono mas esta retornando a mensagem de recepção desativada. Migrar para recepção sincrona Estou usando o comando : ACBrMDFe1.Enviar(NextValue('SEQ_LOTE'),False) Pelo que sei, o false já indica síncrono

Obrigado pela orientação, mudei para ACBrMDFe1.Enviar(NextValue('SEQ_LOTE'),False,true) e funcionou!

Boa tarde @Carlos Paiva, Sim, tem que manter sempre atualizado, para que essas alterações promovidas pela SEFAZ surtem efeito.

Não bate o que tu está a pensar pois ele fica aguardando o pagamento e para isso tem que ser o dinamico com informações. o estático ele só vai exibir e pronto . não vai ficar e nem tem como validar no POS se recebeu ou não a não ser que acesse a conta para verificar

Boa tarde Eu estava recebendo o Erro: 10060 Http_code=0 em Produção hoje de manhã mas agora normalizou, pode ser alguma instabilidade no inter Porem em produção. Att Ralty

Olá amigo, tudo bom? Vai passar sempre, pois a rejeição não faz menção ao tPag = 20. Cuidado com a sua interpretação de resolve o problema, pois pode gerar outro no futuro. Pois com isso seu cliente está afirmando que o QRCode dessa venda é do tipo Estático. Eu abri um tópico a respeito do tema, mas está na parte do ACBr Pro... Pedi para eles migrarem, se possível, para o fórum aberto. Depois da migração eu cito o mesmo pra você. Abraços

Olá... Poderiam jogar esse tópico na parte do Fórum Aberto?!?! Desde já agradeço a atenção

Problema resolvido. Precisei reinstalar o componente e deu certinho. Obrigado pessoal. Podemos encerrar.

Bom dia, Verifique as informações do topico abaixo:

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

Olá Bom dia, Resolvido o problema de autenticação com a Bling V3, precisei usar o componente Edge como navegador e um arquivo PHP numa seção oculta em nosso site para obter o Access Token e baixar em txt(baixa direto) e converter para ini para continuar o processo das requisições seguintes usando o Access Token obtido na autenticação. -- Att, Moysés A. Silva. Águia Sistemas - Gestão e Automação Empresarial.

Lembrando que o tpintegra=2 é quando não é via TEF ou PSP integrado quer dizer o cliente pagou lendo um qrCode fixo por exemplo ou usou um POS senão tem que ser 1 e informar os demais dados conforme o tppag

O XML consta o cpf do tomador e não consta a inscrição municipal, pois não informei realmente. Já solicitei à contabilidade do nosso cliente que verificasse com a prefeitura. Obrigado pela atenção. Assim que tiver o retorno eu devolvo aqui resposta. Grato Geazi

Bom dia Juliomar Muito obrigado, vou usar sua resposta para o cliente assim ele sossega rsrs.

Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

perdão agora que me lembrei o seguinte ao invés de tu informar o arquivo tu carrega no banco e carrega de lá para os campos a seguir:

Bom dia meu amigo Onde seria o aqui contigo?!?! Em relação a regra de validação YA04-10, agora é necessário informar o grupo de cartões para o pagamento 17. Observar também que agora temos 2 Pagamentos Instantâneos: Pagamento Instantâneo Dinâmico - 17 - Antes só Pagamento Instantâneo, agora renomeado Pagamento Instantâneo Estático - 20 - Esse é novo Sugiro ler a Nota Técnica 2023.004 versão 1.11 para maiores detalhes. Abraços

notei aqui. que depois de 15 minutos a nota é enviada

Olá pessoal! Foi publicado Ato Diat Nº031/2024. O mesmo altera artigo 3º do Ato DIAT Nº059/2023 que define obrigatoriedade para os campos vICMSDeson e e motICMSDeson na emissão de NF-e e NFC-e para o estado de Santa Catarina. A nova redação do artigo ficou como: Na prática prorrogando a obrigatoriedade dos campos para a data estabelecida.

Olá pessoal! Foi publicada a versão 4.0.4 do Programa Validador de Escrituração Digital EFD ICMS IPI. A nova versão traz as seguintes alterações: Fonte: http://sped.rfb.gov.br/pagina/show/7450

Olá pessoal! Na página Sobre o SAT da Sefaz de São Paulo, consta um recado informando que no dia 12/08/2024 a partir das 08h30 a Sefaz vai iniciar o processo de desligamento do protocolo SSL 3.0, com previsão inicial de o processo durar 2 horas. Durante esse período pode ocorrer instabilidade da comunicação com a Sefaz e por isso orienta que a ativação de novos SATs sejam feitos fora deste período. Também é lembrado que: Após este processo, os somente os SATs que se comunicam usando o protocolo SSL 3.0 não vão mais conseguir realizar comunicação. Esse processo já foi previamente comunicado pela Sefaz em aviso no dia 15/03/2024 (noticiado em nosso fórum no tópico Desligamento dos protocolos SSL 3.0 e TLS 1.0 para SAT nos próximos meses no dia 28/03/2024 e também no tópico ATENÇÃO!!! Desativação de Protocolos inseguros na comunicação dos SATs SSL3.0 e TLS1.0 no dia 13/06/2024). A tabela abaixo mostra os modelos de SAT afetados por este processo: Fabricante Modelo de SAT Versões de Software Básico de SAT Há atualizações de SAT para versão mais segura? ControlID S@t-Id 01.02.00 SIM Kryptus EASYS@T 01.00.02 e 01.00.04 NÃO Sweda SS-1000 02.00.01 SIM

Olá pessoal! Ao conferir no painel Situação SVC, é possível confirmar que a Sefaz de Goiás está com a contingência ativada desde às 02h10 do dia 29/06/2024, com previsão de permanecer ativada até às 08h00 do dia 01/07/2024 Para utilizar as soluções ACBr em contingência durante este período, siga as orientações do tópico abaixo:

Olá pessoal! Foi publicada a versão 1.21 desta Nota Técnica. A nova versão trás uma correção na documentação do evento "Ator Interessado" esclarecendo que o CNPJ informado no evento não receberá o evento de Comprovante de entrega na NF-e Cancelamento(foi alterado de "SIM" para "NÃO" a última coluna da última linha da tabela anexada no tópico acima). As datas permanecem as mesmas da versão 1.20. A versão 1.21 da NT pode ser encontrada na íntegra AQUI.

Olá pessoal! A Sefaz de Minas Gerais ativou novamente a contingência às 15h37 do dia 29/06/2024, com previsão de permanecer ativa até às 12h00 do dia 30/06/2024.

Foi publicada a versão 24.1.F das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/06/2024 até 30/07/2024 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto" foi, não se esqueça de realizar a atualização de seus clientes. Fonte : De Olho no Imposto

Referente ao PenseBank vamos verificar se conseguimos credencial de homologação juntamente a eles. Referente ao código 204, vamos retornar o código 400, porem você pode testar a lista se o count é > 0 o Sicoob está no SVN

QR Code estático O QR Code estático pode ser usado para diversas transações e, segundo o Banco Central, permite: Que o recebedor defina um valor fixo para um produto; E também a inserção de um valor pelo pagador. Na prática, um QR Code estático é como uma etiqueta de preço único. Ele não muda, e você pode usar ele para cobrar o mesmo valor de várias pessoas. Ele é, portanto, mais flexível. A recomendação do BC é de que ele é mais apropriado pra pessoas físicas, pequenos varejistas e prestadores de serviços. QR Code dinâmico Diferente do anterior, o QR Code dinâmico é exclusivo para cada transação. Isso significa que ele só pode ser usado uma vez- para fazer uma segunda cobrança usando um QR Code, é necessário gerar um novo. Além disso, também é possível incluir outros dados e informações no QR Code, como a identificação do recebedor. Por ser exclusivo para cada transação e gerado por um sistema, a expectativa é de que este tipo de QR Code seja mais usado em compras online, por e-commerces, ou cobranças mais formais. Quando se fala de Midware, Pos, Tef, eu vejo como Pix Dinâmico, pois ele vai ter uma única transação para aquele QR Code (EMV), indiferente se é integrado com uma solução de automação comercial ou não. o Tipo do QR Code não é ligado diretamente se tem integração com soluções comerciais, mas se ele é Dinâmico ou Estático.

suspeito que QRCode Dinâmico... observe que ele nunca é igual... e está associado a venda...

Para SAT SP, se eu não estou enganando, pelo menos em teste aqui com um SAT desenvolvedor EPSON, o layout 0.08 não garante que esta forma de pagamentos esta disponivel, então "Joguei" isto para versão 0.09. Outro detalhe Não encontrei mpPix, então usei Pagamento instantaneo ficou como no trecho: with SAT.CFe.Pagto.New do begin if SAT.Config.infCFe_versaoDadosEnt >= 0.09 then cMP := mpPagamentoInstantaneo else cMP := mpOutros; vMP := Valor; end; Será que esta correto ?

Esta propriedade, DANFEClassOwner.ACBrNFe deve estar nula. Veja se está alimentando ACBrNFe1.DANFE.

Tentei fazer igual a você @MarceloDev, mas aqui em GO em Homologação a rejeição continua, sendo que para a forma de pagamento Cartão com menos informação passa de boa, mas para PIX não. Exemplo de preenchimento em GO a Cartão e funciona normal (um POS sem integração): Então, fiz o que o @Juliomar Marchetti sugeriu e mandei o questionamento para a Sefaz, agora é esperar a boa vontade deles responder. Se é falha no ambiente de homologação, ou quais campos serão exigidos, se passará para produção... enfim... esperar a resposta.

Atualize o SVN e depois reconstrua a IDE do Lazarus. Só isso.

Bom dia, nome da API do Boleto PIX Itaú.....Recebimentos Pix - API exclusiva Itaú, depois vc vai na opção bolecode (Clientes), mais para isso você tem ativar e assinar o certificado digital, mesmo processo feito na API de Cobrança v2.