flaviorealtec

Versão do relatório: 6.9.14 Sim, usamos o FastReport.

Inclusão de campos do tipo de operação e DFe referenciado nas compras governamentais com entrada em homologação em 06/04/26 porem ainda não disponíveis no ACBR;

Inclusão dos códigos 23 e 24 na Tabela de Meios de Pagamento com entrada em homolagacao em 02/04 porem ACBR ainda nao esta atualizado.

Criação do grupo de informações da vinculação da transação de pagamento do DFe com entrada em homologação em 06/04 porem ainda não contempladas no ACBR.

Bom dia, ja saiu esse manual?

Certo, aí no caso você fez a correção por conta própria? Pois no relatório da ACBr está a seguinte regra de cálculo: De acordo com o fórum e a regra que você disponibilizou esse cáculo da ACBr está incorreto?

Prezados, boa tarde. Usamos o layout de impressão da ACBr para a NFSe Padrão Nacional, porém alguns de nossos clientes estão questionando sobre a junção e o cálculo dos valores das Retenções Federais no relátorio da NFSe, conforme print abaixo: Layout ACBr: Ao analisar o layout do próprio Portal Nacional, nos deparamos com o seguinte: Gostaríamos de saber se há possibilidade de alteração para seguir com o modelo proposto pelo Padrão Nacional. Desde já, agradeço.

Deu certo, removi os WITH e deu outra rejeição onde mostrou realmente onde estava o problema. Obrigado.

Boa tarde. Estou tentando realizar o envio de uma NFS-e pelo Padrão Nacional, porém estou com problema nos valores da prestação de serviços, onde não estão sendo passadas as tags: <valores> <vBC></vBC> <vAliqApli></vAliqApli> <vISSQN></vISSQN> <vTotalRet></vTotalRet> <vLiq></vLiq> No código da ACBr tem o seguinte: with infNFSe.valores do begin BaseCalculo := fRSItemServico.fBaseISS; Aliquota := fRSItemServico.fAliqISS; ValorIss := fRSItemServico.fValorISS; ValorLiquidoNfse := fRSItemServico.fsomaTotalLiquidoServ; end Contudo não estão sendo consideradas no XML, houve alguma alteração referente a isso? Desde já agradeço.

Prezados, bom dia. Estou implementando a integração do boleto com o banco Itaú e encontrei uma situação específica ao tentar cancelar o desconto de um boleto. A função ATitulo.ValorDesconto exige que o valor seja maior que 0, mesmo pra condição tdNaoConcederDesconto. Essa exigência vai de contramão a documentação do Itaú, conforme regra abaixo: Teria como revisar tal condição para que não exija a obrigação de informar um valor ao tentar cancelar um desconto? Desde já agradeço.

A UF é MG.

Boa tarde, Estou com o mesmo problema, segue o print da rejeição presente na Nota Técnica v1.11

Os municípios de Patos de Minas - MG, Araxá - MG e Patrocínio - MG, irão aderir ao novo Portal Nacional para emissão de NFS-e á partir do dia 01/01/2026, segue as alterações: [3148004] Nome=Patos de Minas UF=MG Provedor=PadraoNacional [3104007] Nome=Araxa UF=MG Provedor=PadraoNacional [3148103] Nome=Patrocinio UF=MG Provedor=PadraoNacional Link contendo a data de alteração do munícipio de Patos de Minas: https://www.patosdeminas.mg.gov.br/portal/secretarias-paginas/76/nfs-e-nacional/ Os demais comunicados estão em anexo. Desde já agradeço.

Prezados, bom dia. Estou implementando a integração com o Sicredi e encontrei uma situação específica ao tentar cancelar o desconto de um boleto. Durante o processo, a alteração de desconto aciona a procedure ATitulo.OcorrenciaOriginal.ComplementoOutrosDados, que por sua vez chama a rotina RequisicaoAlteraDesconto. Dentro dessa requisição existem validações que tornam obrigatório informar ValorDesconto ou DataDesconto, mesmo quando a intenção é apenas cancelar o desconto. Caso nenhum desses campos seja enviado, é gerada a exceção: raise EACBrBoletoWSException.Create(ClassName + 'Para requisições de alteração de desconto é necessário informar ao menos um dos campo de desconto!'); As regras internas exigem que: ValorDesconto > 0 DataDesconto > 01/01/2000 Minha dúvida é: qual a justificativa para obrigar o envio de valor e/ou data de desconto mesmo quando se trata de um cancelamento de desconto? Não faria sentido permitir a ausência desses campos nesse cenário?

O município de São Gotardo - MG irá aderir ao novo Portal Nacional a partir do dia 01/01/2026, segue a alteração: [3162104] Nome=Sao Gotardo UF=MG Provedor=PadraoNacional Segue o link do portal da prefeitura informando a alteração: https://www.saogotardo.mg.gov.br/midia_publicacao.php?codmidia=336

Olá, pessoal. Estou realizando a integração da API de boletos Sicredi utilizando o ACBrBoleto, e me deparei com uma limitação no momento das consultas. Atualmente, a consulta de boletos é feita pelo método tpConsulta, que retorna corretamente os boletos com situação "LIQUIDADOS". Porém, para boletos em outras situações (como "EM ABERTO", "BAIXADOS" etc.), é necessário utilizar o método tpConsultaDetalhe. O problema é que o tpConsultaDetalhe realiza a busca boleto a boleto, o que torna o processo mais lento e ineficiente, principalmente em casos com grande volume de títulos, além de não permitir filtragem por data ou intervalo de lançamentos. Em contato com o suporte da PJ Tech Sicredi, fui informado sobre um endpoint que permite realizar consultas em lote e filtradas por data e situação, o que resolveria perfeitamente essa limitação. Seguem as informações repassadas: Endpoint: https://api-parceiro.sicredi.com.br/cobranca/v1/cobranca-financeiro/movimentacoes/ HEADERS: Authorization x-api-key Content-Type: application/x-www-form-urlencoded PARAMS: pagina codigoBeneficiario cooperativa posto dataLancamento tipoMovimento posto Esse endpoint retorna os boletos conforme os parâmetros informados, permitindo uma consulta muito mais rápida e eficiente, ideal para integrações com grande volume de dados. Sugestão: Avaliar a possibilidade de incluir no ACBrBoleto um novo método que utilize esse endpoint para consultas em lote e por data de lançamento, mantendo a compatibilidade com o padrão atual de retorno. Acredito que essa melhoria traria ganhos significativos de performance e simplificaria o processo de sincronização de boletos com a API Sicredi. Desde já, agradeço a atenção e fico à disposição para compartilhar mais detalhes ou exemplos do corpo JSON utilizado nessa requisição.

Bom dia Já está valendo, segue abaixo o comunicado feito pela prefeitura: 25/07/2025 - COMUNICADO OFICIAL: EMISSÃO DE NOTA FISCAL DE SERVIÇO ELETRÔNICA - PADRÃO NACIONAL. A PREFEITURA MUNICIPAL DE RIO PARANAÍBA - MG INFORMA AOS CONTRIBUINTES QUE, EM CONFORMIDADE COM AS DIRETRIZES ESTABELECIDAS PELA RECEITA FEDERAL DO BRASIL, A PARTIR DO DIA 1º DE AGOSTO DE 2025, A EMISSÃO DA NOTA FISCAL DE SERVIÇO ELETRÔNICA (NFS-e) - PADRÃO NACIONAL DEVERÁ SER REALIZADA EXCLUSIVAMENTE POR MEIO DO PORTAL DA RECEITA FEDERAL, DISPONÍVEL NO ENDEREÇO ELETRÔNICO: HTTPS://WWW.NFSE.GOV.BR. RESSALTAMOS QUE, A PARTIR DESTA DATA, NÃO SERÁ MAIS POSSÍVEL EMITIR NFS-e POR MEIO DOS SISTEMAS ATUALMENTE UTILIZADOS NO ÂMBITO MUNICIPAL. A MUDANÇA VISA À PADRONIZAÇÃO NACIONAL DA EMISSÃO DE DOCUMENTOS FISCAIS DE SERVIÇOS, PROPORCIONANDO MAIOR SEGURANÇA, INTEGRAÇÃO E CONTROLE FISCAL. RECOMENDA-SE QUE OS PRESTADORES DE SERVIÇO REALIZEM, COM ANTECEDÊNCIA, O SEU CREDENCIAMENTO JUNTO AO AMBIENTE NACIONAL DA NFS-e, A FIM DE EVITAR TRANSTORNOS OU INTERRUPÇÕES NAS EMISSÕES. PARA MAIS INFORMAÇÕES, ORIENTAÇÕES TÉCNICAS E MANUAIS DE UTILIZAÇÃO, ACESSE O PORTAL ACIMA.

O município de Rio Paranaíba - MG aderiu ao novo Portal Nacional, segue a alteração [3155504] ; Incluído em 15/05/2024 Nome=Rio Paranaiba UF=MG Provedor=PadraoNacional

Houve uma alteração na URL de acesso no portal de Rio Paranaíba - MG Segue a alteração: [3155504] ; Incluído em 15/05/2024 Nome=Rio Paranaiba UF=MG Provedor=Governa Versao=1.01 Params=VersaoArquivo:4|VersaoImpressao:5 ProRecepcionar=http://179.189.86.42:1001/wsgoverna/eSiat.asmx Desde já agradeço.

Correção: o município é em Goiás, portanto Cristalina/GO.

Boa tarde, a cidade de Cristalina-MG alterou recentemente o provedor de NFS-e, mudando do Sigep para o CENTI, segue abaixo a configuração que já se encontra funcionando em nossos clientes [5206206] Nome=Cristalina UF=GO Provedor=Centi Versao=2.02 ProRecepcionar=* ProConsultarNFSeRps=https://api.centi.com.br/nfe/consultar/rps/go/cristalina ProCancelarNFSe=https://api.centi.com.br/nfe/cancelar/go/cristalina ProGerarNFSe=https://api.centi.com.br/nfe/gerar/go/cristalina HomRecepcionar=* HomConsultarNFSeRps=https://api.centi.com.br/nfe/consultar/homologacao/rps/go/cristalina HomCancelarNFSe=https://api.centi.com.br/nfe/cancelar/homologacao/go/cristalina HomGerarNFSe=https://api.centi.com.br/nfe/gerar/homologacao/go/cristalina ProLinkURL=https://api.centi.dev.br/portal/nfse/go/cristalina/%CodVerif% HomLinkURL=https://api.centi.dev.br/portal/nfse/go/cristalina/%CodVerif%

Olá, Recentemente, o município de Cristalina-GO alterou o provedor de NFS-e para a plataforma CENTI. Ao tentar homologar o Webservice para emissão de NFS-e em nosso ERP, utilizando as URLs das APIs disponibilizadas pelo provedor, estamos enfrentando um erro HTTP 500. O Webservice retorna um XML vazio, impossibilitando a emissão das notas fiscais. Segue abaixo a URL utilizada para a requisição: [5206206] Nome=Cristalina UF=GO Provedor=Centi Versao=2.02 ProRecepcionar=* ProConsultarNFSeRps=https://api.centi.com.br/nfe/consultar/rps/go/cristalina ProCancelarNFSe=https://api.centi.com.br/nfe/cancelar/go/cristalina ProGerarNFSe=https://api.centi.com.br/nfe/gerar/go/cristalina HomRecepcionar=* HomConsultarNFSeRps=https://api.centi.com.br/nfe/consultar/homologacao/rps/go/cristalina HomCancelarNFSe=https://api.centi.com.br/nfe/cancelar/homologacao/go/cristalina HomGerarNFSe=https://api.centi.com.br/nfe/gerar/homologacao/go/cristalina ProLinkURL=https://api.centi.dev.br/portal/nfse/go/cristalina/%CodVerif% HomLinkURL=https://api.centi.dev.br/portal/nfse/go/cristalina/%CodVerif% Em anexo, envio o XML de requisição para análise. 1493-ger-nfse.xml 1493-ger-nfse-soap.xml

estamos com essa mesma situacao aqui desde ontem tb.

bom dia. O ACBR será ou ja foi adequado ao layout da NFF?

Bom dia. Conforme manual de Orientacao de Preenchimento da NF-e - versao 1.05 fornecido pela receita onde o mesmo cita que o layout para a TAG do grupo de Pis e Cofins deverá ter o seguinte formato: <PISOutr> <CST>99</CST> <qBCProd>0.0000</qBCProd> <vAliqProd>0.0000</vAliqProd> <vPIS>0.00</vPIS> </PISOutr> <COFINSOutr> <CST>99</CST> <qBCProd>0.0000</qBCProd> <vAliqProd>0.0000</vAliqProd> <vCOFINS>0.00</vCOFINS> </COFINSOutr> o Componente do ACBR possui a seguinte Unit abaixo: Unit: pcnNFeW Função: GerarDetImpostoPIS if nfe.Det.Imposto.PIS.CST in [pis49, pis50, pis51, pis52, pis53, pis54, pis55, pis56, pis60, pis61, pis62, pis63, pis64, pis65, pis66, pis67, pis70, pis71, pis72, pis73, pis74, pis75, pis98, pis99] then begin if (NFe.Det.Imposto.PIS.vBC + NFe.Det.Imposto.PIS.pPIS > 0) and (NFe.Det.Imposto.PIS.qBCProd + NFe.Det.Imposto.PIS.vAliqProd > 0) then Gerador.wAlerta('Q05', 'PISOutr', DSC_PISOUTR, 'As TAG <vBC> e <pPIS> não podem ser informadas em conjunto com as TAG <qBCProd> e <vAliqProd>'); if (NFe.Det.Imposto.PIS.qBCProd + NFe.Det.Imposto.PIS.vAliqProd > 0) then begin Gerador.wGrupo('PISOutr', 'Q05'); Gerador.wCampo(tcStr, 'Q06', 'CST ', 02, 02, 1, CSTPISTOStr(nfe.Det.Imposto.PIS.CST), DSC_CST); Gerador.wCampo(tcDe4, 'Q10', 'qBCProd ', 01, 16, 1, nfe.Det.Imposto.PIS.qBCProd, DSC_QBCPROD); Gerador.wCampo(tcDe4, 'Q11', 'vAliqProd', 01, 15, 1, nfe.Det.Imposto.PIS.vAliqProd, DSC_VALIQPROD); Gerador.wCampo(tcDe2, 'Q09', 'vPIS ', 01, 15, 1, nfe.Det.Imposto.PIS.vPIS, DSC_VPIS); Gerador.wGrupo('/PISOutr'); end else begin Gerador.wGrupo('PISOutr', 'Q05'); Gerador.wCampo(tcStr, 'Q06', 'CST ', 02, 02, 1, CSTPISTOStr(nfe.Det.Imposto.PIS.CST), DSC_CST); Gerador.wCampo(tcDe2, 'Q07', 'vBC ', 01, 15, 1, nfe.Det.Imposto.PIS.vBC, DSC_VBC); Gerador.wCampo(tcDe2, 'Q08', 'pPIS ', 01, 05, 1, nfe.Det.Imposto.PIS.pPIS, DSC_PPIS); Gerador.wCampo(tcDe2, 'Q09', 'vPIS ', 01, 15, 1, nfe.Det.Imposto.PIS.vPIS, DSC_VPIS); Gerador.wGrupo('/PISOutr'); end; end; Neste caso, o componente somente irá gerar no formato do layout, caso a base de pis/cofins e aliquota sejam > 0. Como o roteiro cita base e aliquota = 0 será gerado no seguinte formato pelo ACBR: Gerador.wCampo(tcStr, 'Q06', 'CST ', 02, 02, 1, CSTPISTOStr(nfe.Det.Imposto.PIS.CST), DSC_CST); Gerador.wCampo(tcDe2, 'Q07', 'vBC ', 01, 15, 1, nfe.Det.Imposto.PIS.vBC, DSC_VBC); Gerador.wCampo(tcDe2, 'Q08', 'pPIS ', 01, 05, 1, nfe.Det.Imposto.PIS.pPIS, DSC_PPIS); Gerador.wCampo(tcDe2, 'Q09', 'vPIS ', 01, 15, 1, nfe.Det.Imposto.PIS.vPIS, DSC_VPIS); minha dúvida é se ja foi corrigido ou saíra versão do ACBR contemplando este layout. att. Flávio Ribeiro