Painel de líderes

Olá comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente postergando a entrada em vigor do fim da NFCe para CNPJ para 05/01/2026. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O Ajuste SINIEF Nº 28, de 3 de Outubro de 2025 altera o Ajuste SINIEF Nº 12 de 29 de Abril que definiu as modificações feitas na NFe para ser usada no lugar da NFCe para CNPJ, efetivamente mudando sua cláusula que define sua entrada em vigor para: O Ajuste SINIEF Nº 30, de 3 de Outubro de 2025 altera o Ajuste SINIEF Nº 11 de 29 de Abril que definiu a proibição da NFCe para CNPJ, efetivamente mudando sua cláusula que define sua entrada em vigor para:

Olá, comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente adicionando a necessidade da geração de um MDF-e por UF unidade federada. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O AJUSTE SINIEF Nº 27, de 3 de Outubro de 2025 altera o Altera o Ajuste SINIEF nº 21, de 10 de dezembro de 2010 que institui o MDF-e, modificando a redação do § 2º da cláusula terceira para: Este mesmo ajuste também acrescenta o § 2º-A na mesma cláusula:

Olá, comunidade ! Ao acessar a seção de Avisos nos Portais de Documentos Fiscais da Sefaz Virtual do Rio Grande do Sul (SVRS), observamos um comunicado importante. Visando coibir o uso indevido das informações para a criação de Data Lakes e o treinamento de Inteligências Artificiais (IAs), a SVRS implementou novas regras de autenticação. O login para Pessoas Jurídicas será feito exclusivamente via e-CNPJ, enquanto o acesso para Pessoas Físicas será realizado através da plataforma Gov.br. Esta medida substitui o uso do Recaptcha, que estava perdendo sua eficácia contra rotinas automatizadas. O aviso também pode ser lido na íntegra direto da fonte AQUI.

Nao compreendi se é bem isso que você precisa... Mas temos um Curso sobre Distribuição DFe https://projetoacbr.com.br/cursos/dfe/

Projeto ACBr e compatibilização do Android 15+ Projeto ACBr está atualizando as bibliotecas Android para compatibilizar com alinhamento de páginas de 16 kB nos Android 64 bits. A Google determinou que a partir de 01/11/2025, todos os novos aplicativos (e atualizações) destinados ao Android 15 +(Google Play) devem ser recompilados com essa configuração. Por isso o Projeto ACBr recompilou a LibXML2 e OpenSSL para atender essa determinação. Nossas bibliotecas nativas e AAR também foram ajustados. A partir de 14/10/2025, todos os AAR e ACBrLib Android ARM64 serão compiladas com alinhamento de 16 KB por padrão. O que você precisa fazer para se adequar ? ACBrLib Android Recomendações gerais Se você usa bibliotecas nativas de terceiros, é importante verificar se elas estão alinhadas corretamente. Se você compila bibliotecas, terá que recompilar com o alinhamento de 16 KB Android Nativo (Java e Kotlin) Atualizar o plugin AGP (Android Gradle Plugin) para versão>= 8.6 (Mínimo recomendado é 8.5.1, mas usamos a versão 8.6.0) Se usa uma de nossas bibliotecas (AAR) deve atualizar o JNA para versão >= 5.17 SDK Mínimo : Android API 24 (Android 7.0) //build.gradle do módulo app implementation net.java.dev.jna:jna:5.17.0@aar //configuração do build.gradle.kts implementation("net.java.dev.jna:jna:5.17.0@aar") Recomendamos a remoção das seguintes linhas no build.gradle: android { ... packagingOptions { jniLibs { useLegacyPackaging true } } } React Native React Native, a versão mínima com suporte a 16 KB é 0.77 Aplicam-se as mesmas configurações que o Android Nativo Flutter Flutter oferece suporte a partir da versão 3.27 https://docs.flutter.dev/release/release-notes/release-notes-3.27.0 Aplicam-se as mesmas configurações que o Android Nativo Componentes ACBr (Delphi FMX) A Libxml2 foi recompilada com alinhamento de 16 KB Já a OpenSSL compilamos a versão 1.1.1w, https://svn.code.sf.net/p/acbr/code/trunk2/DLLs/Android/OpenSSL/openssl-1.1.1w/aarch64-linux-android/Dynamic/ Componentes que usam a OpenSSL, devem usar essa versão, exemplo: ACBrCEP, ACBrConsultaCNPJ, ACBrNFe, entre outros ... Delphi 12.3 já oferece suporte a alinhamento de páginas de 16 KB Referências https://docs.flutter.dev/release/release-notes/release-notes-3.27.0 https://android-developers.googleblog.com/2025/05/prepare-play-apps-for-devices-with-16kb-page-size.html https://developer.android.com/guide/practices/page-sizes?hl=pt-br#alignment-use-tools

Para NFSe, por favor, veja o seguinte tópico:

na unit : ACBrNFe.XmlWriter; linha 4240 if (IBSCBS.gCredPresOper.cCredPres <> cpNenhum) then Result.AppendChild(Gerar_IBSCBS_gCredPresOper(IBSCBS.gCredPresOper)) else Result.AppendChild(Gerar_IBSCBS_gCredPresIBSZFM(IBSCBS.gCredPresIBSZFM)); esta gerando sempre a tag Gerar_IBSCBS_gCredPresIBSZFM deveria checar se foi preenchido mudei para: if (IBSCBS.gCredPresOper.cCredPres <> cpNenhum) then Result.AppendChild(Gerar_IBSCBS_gCredPresOper(IBSCBS.gCredPresOper)); if (IBSCBS.gCredPresIBSZFM.tpCredPresIBSZFM <> tcpNenhum) then Result.AppendChild(Gerar_IBSCBS_gCredPresIBSZFM(IBSCBS.gCredPresIBSZFM)); ACBrNFe.XmlWriter.pas

Olá comunidade ! Nos últimos dias temos recebidos alguns relatos de membros da comunidade com problemas para comunicar com o Padrão Nacional utilizando as soluções ACBr. Após investigação dos relatos, foi constatado que a API do Padrão Nacional passou por melhorias, dividindo end-points que até então eram genéricos em novos end-points mais específicos, causando assim essa divergência. Foi criado a tarefa ACBR-8132 para centralizar a análise dessas alterações e as modificações que possam vir a ser necessárias na solução ACBr para adequação. Qualquer novidade relacionada será divulgada neste tópico.

Esses benefícios (excluindo Herança múltipla) parecem estar presentes em uma estrutura de classes padrão de O.O... ou seja, não parecem ser tão exclusivos da técnica de uso de Interfaces...

Subi pro SVN os schemas atualizados já compatível com a versão 1.30 da NT 2025/002. Já deve validar, mas o grupo do crédito presumido parece que precisa de ajustes pra não gerar se não informado.

Deu certo aqui colocando o comando de envio desta forma. Obrigado pela atenção.

Esse erro é de validação local, então veja a pasta de schemas se está atualizada. As rejeições do validador da SEFAZ-RS são normais já que você está validando um XML de UF não atendida lá.

por essas e outras, que não vejo muita vantagens em usar Interfaces... Na minha opinião, as Interfaces são úteis apenas quando: - o Método precisa retornar um Objeto - deseja-se utilizar o estilo de codificação "Fluent Interface"

sim tem que ser feito isso. mas se tu vai usar só pra tratar uma classe que irá usar de model por exemplo não vejo o motivo de programar os fields dai no caso tu poderia só ter para os objetivos comuns e usar a tipagem para interface type IFace = interface function xpto:boolean; end; Tface = class(Tinterfacedobject, IFace) private fnome :string; function xpto:boolean; public property nome :string read fnome write fnome; end; ..... var LFace : IFace; begin LFace := Tface.Create; Tface(LFace).nome := 'xxx'; e mesmo assim ainda se for só mesmo para isso não usaria dai interface

se olhar o ACBrNFSeX o mesmo faz uso, bem como os novos que foram criados de DFe. eles fazem uso.

Acho que é uma questão de preferência... Eu particularmente, prefiro ter rotinas que criam e destroem seus objetos... E para evitar Memoryleaks, não uso métodos que retornam Objetos criados internamente, mas espera recebe-los como parâmetros, para deixar claro que a responsabilidade de quem deve criar/destruir o objeto, é da rotina chamadora do método Mas há alguns componentes que usam Interfaces, observe a implementação do novo componente, SmartTEF... E nesse caso, podemos ter métodos que retorno Objetos, e deixar que o contador de referência, elimine-os automaticamente

Olá, comunidade ! Foi adicionado a partir de 08/10/2025 no sistema do e-Social uma nova validação relacionada aos descontos de empréstimo consignado. Ao enviar os eventos S-1200, S-2299 e S-2399, será validado se existe um contrato de empréstimo consignado ativo com parcela prevista para a competência da remuneração enviada e se a instituição financeira e o número do contrato enviados estão corretos. Possíveis mensagens de retorno em caso de divergência serão: 1988 - O trabalhador <<cpfTrab>>, matrícula <<matricula>> possui parcela(s) de empréstimo consignado do Programa Crédito do Trabalhador prevista para desconto na competência de apuração <<MM/AAAA>>. No entanto, o empregador informou os dados incorretos ou não informou rubrica de desconto do empréstimo neste evento. Verifique a informação correta no arquivo disponibilizado no Portal Emprega Brasil e retifique este evento. Foram localizados os seguintes contratos de empréstimo consignado com previsão de pagamento de parcela nesta competência: Instituição Financeira: <<instFinanc>>, Contrato <<nrDoc>> | Instituição Financeira: <<instFinanc>>, Contrato <<nrDoc>> 1989 - O usuário informou rubrica de desconto do empréstimo consignado neste evento para o trabalhador <<cpfTrab>>, matrícula <<matricula>> que não possui parcela(s) do Programa Crédito do Trabalhador prevista para desconto na competência de apuração <<MM/AAAA>>. Verifique a informação correta no arquivo disponibilizado no Portal Emprega Brasil e retifique este evento. 1990 - O usuário informou rubrica de desconto do empréstimo consignado neste evento, mas a validação não pode ser realizada na base do Programa Crédito do Trabalhador. Certifique-se que os valores estão corretos no arquivo disponibilizado no Portal Emprega Brasil. Leia a notícia original completo AQUI. Lembrando que o ACBreSocial, o ACBrMonitorPLUS e a ACBrLib são compatíveis com o eConsignado.

Olá, comunidade ! Foi publicado no Diário Oficial da União o DESPACHO Nº 33, DE 8 DE OUTUBRO DE 2025, efetivamente permitindo que as UFs posterguem a data de obrigatoriedade da NFCom considerando critérios específicos. Fazem parte deste Despacho, dentre outros, os Ajustes Sinief relacionados abaixo. O Ajuste SINIEF Nº 25, de 3 de Outubro de 2025 altera o Ajuste SINIEF nº 7, de 7 de abril de 2022 que institui NFCom acrescendo o § 5º a cláusula primeira: Vale ressaltar, no entanto, que apesar desta publicação, ainda não foi publicado nada específico pelos estados, fazendo uso dessa nova cláusula e postergando a data de obrigatoriedade, portanto, até o momento, mantem-se a data de 01/11/2025

Se for para algo especifico do seu projeto, talvez valha a pena você desenvolver a sua própria solução. Não demorará muito o desenvolvimento já que o ACBr tem o componente pronto com exemplos de código e a comunidade para tirar suas dúvidas. Pense a respeito.

NO svn At revision: 42137 só para deixar declarado o motivo

No meu caso entrei em contato com o pessoal do sefaz mg "[email protected]", e logo em seguida não ocoreu mais o erro. mas ocorreu esta msg "Emissor não habilitado para emissão da NFCom" feito a solicitação de uso, tudo ok emitindio em homologação esperando para entrar em produção.

https://loja.regys.com.br/loja/fontes-delphi/fontes-aplicativo-distribuicao-nf/ @Régys Silveira

Agora funcionou perfeito, testei com nubank, caixa, bradesco, itau, mercado pago, sicoob e c6 bank, todos leram perfeitamente o qrcode impresso no NFCom.

Adiado para janeiro de 2026 (veja informações completas no tópico abaixo):

Olá comunidade ! No dia 06/10/2025, por volta das 08H19, começamos a receber relatos em nossa comunidade do Discord de membros recebendo rejeição ao tentar autorizar NFCe em alguns estados para o ambiente de homologação. Os relatos tem em comum a mesma rejeição: UFs cujo problema foi relatado até o momento: SP, MG, GO e PR. Esta rejeição está relacionada a Reforma Tributária sobre o Consumo, foi adicionada a partir da Nota Técnica 2025/002 e na versão 1.30, que é sua publicação mais recente, sua implementação foi postergada sem data definida no ambiente de homologação. Portanto, tudo indica que algumas Sefaz autorizadoras adiantaram a implementação da regra ou implementaram considerando cronograma de versão anterior da nota técnica. Os relatos confirmam ainda que os CRTs 1, 2 e 4 estão sendo tratados como CRT 3 exigindo as informações e também que até o momento desta publicação, apenas o modelo 65 está devolvendo a rejeição, com a NFe modelo 55 aceitando sem os campos. Caso esteja enfrentando problemas, como o relato foi no ambiente de homologação a sugestão é que abra um Fale Conosco junto a Sefaz relatando a questão. Também é importante lembrar que a rejeição pode ser sanada, caso os campos da reforma tributária sejam informados no arquivo XML.

ignora, deleta o topico, agora que vi, o numero mudou mesmo. aff: 37 https://delphidabbler.com/notes/version-numbers#:~:text=List of Delphi Pascal Compiler,VER170

Olá pessoal! O comportamento da quebra de linha nos impressos do ACBr será alterado! Como é hoje? Atualmente os impressos do ACBr fazem uso do caractere de ponto e vírgula para quebra de linha. Isso quer dizer que se o seu XML tiver um conteúdo como este: <infCpl>Teste Linha 1; Teste Linha 2 ;; Teste Linha 3 </infCpl> No momento em que for impresso, o conteúdo fica desta forma: Teste Linha1 Teste Linha2 Teste Linha3 No entanto, entendemos que ao manter fixo o ponto e vírgula, limitamos as possibilidades no momento de criar a informação. Se o cliente solicitasse que aparecesse o ponto e vírgula no impresso, não importa quantas vezes fosse adicionado o mesmo, só iria quebrar a linha. Por isso, este comportamento foi alterado. Como ficou? Os componentes de documentos fiscais possuem uma configuração chamada QuebraDeLinha em sua classe de web service. Esta configuração será utilizada ao invés do ponto e vírgula, fornecendo uma maior variedade de customização. Com isso, será possível definir o caractere que deseja para usar como quebra de linha. Em um exemplo, vamos considerar que desejo que o caractere de quebra seja \r\n. Para isso, vou definir a configuração desta forma: ACBrDFe.Configuracoes.WebServices.QuebraDeLinha := '\r\n'; Definindo a configuração desta forma, o conteúdo: <infCpl>Teste Linha 1; Teste Linha 2 ;; Teste Linha 3 </infCpl> Vai ser exibido no impresso: Teste Linha 1; Teste Linha 2 ;; Teste Linha 3 E caso eu queira que seja feita a quebra de linha vou precisar alterar o conteúdo para: <infCpl>Teste Linha 1\r\n Teste Linha 2 \r\n\r\n Teste Linha 3 </infCpl> Para que seja exibido: Teste Linha1 Teste Linha2 Teste Linha3 E se eu uso o ACBrMonitor ou a Lib, onde vou definir a configuração? Caso utilize a Lib, basta alterar a configuração QuebradeLinha no arquivo de configurações ACBrLib.ini. No exemplo da NFe que foi mencionado seria: [NFe] QuebradeLinha= Caso utilize o ACBrMonitorPLUS, foi adicionada uma config na aba DFe > WebServices > Configurações. Quais componentes se espera que sejam afetados por esta mudança? Os seguintes componentes serão modificados: ACBrBPe. ACBrCTe. ACBrMDFe. ACBrNF3e. ACBrNFe. Quais componentes já está em vigor a alteração? Até o presente momento foram alterados os impressos dos componentes: ACBrNFe. ACBrCTe. ACBrMDFe. ACBrBPe. ACBrNF3e Este tópico será atualizado a medida que os demais componentes forem atualizados. Porque isso é importante para mim? Neste processo de padronização, foi definido que será utilizado esta propriedade de quebra de linha e também foi decidido que o valor default para quebra será o pipe(este carinha aqui: | ). Isso acarreta uma mudança de comportamento. O ponto e vírgula, não vai mais quebrar linha a menos que seja definido ele na propriedade.

Olá... Totalize arquivo com essas tags abaixo: Inclua... [IBSCBSTot] vBCIBSCBS= (Soma de todas as vCBS=) Funcionou normal aqui conosco. Abs

Olá comunidade ! Foi publicado no dia 03/10/2025 a versão 1.30 desta nota técnica trazendo novos campos, novas regras de validação, alteração no cronograma e ajustes diversos. Alterações Novos campos e novos valores Adiciona no leiaute da NFe\NFCe os campos: dPrevEntrega, tpCredPresIBSZFM e indDoacao. Adiciona novos valores válidos para os campos tpNFDebito e tpNFCredito. Novos grupos Remove os grupos de gIBSCredPres, gCBSCredPres e gCredPresIBSZFM de dentro dos respectivos impostos e os adiciona em um novo grupo específico chamado gCredPresOper. Adiciona os novos grupos gAjusteCompet e gEstornoCred. Regras de validação Adiciona novas regras de validação para tratar os novos campos e grupos que foram incluídos. Altera a observação de algumas regras para considerar os novos valores possíveis para os campos já existentes. Substitui algumas regras de validação. Datas¹ O cronograma foi alterado postergando a entrada dos campos. Entrada dos schemas, das regras de validação (com exceção de algumas regras em específicas) e dos eventos: Implantação Homologação: Até 29/10/2025 Implantação Produção: 10/11/2025 Entrada das regras de validação (B10a-10, B10a-20, B10a-30, B10a-40, B10a-50, B25-110, B25-120, I05k-10, I05k-20, UB112-10, UB112-20, UB112-30, UB116-10, UB116-20, UB116-30, UB120-10, UB120-20, UB122-10, UB123-10, UB123-20, UB125-10, UB126-10, UB127-10, UB127-20, UB129-10, UB130-10, UB131-10, UB131-20, UB131-30, UB131-40, UB131-50, UB132-10, UB133-10, W59f-10, W59g-10): Implantação Homologação: Até 24/11/2025 Implantação Produção: 02/02/2026 Inicio da obrigatoriedade dos novos tributos: Implantação Homologação: Implementação futura Implantação Produção: 05/01/2025 Detalhamento Outubro/2025: Homologação: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Produção: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas. Sem valor jurídico para os novos tributos. Janeiro/2026: Homologação: Preenchimento dos campos IBS/CBS é facultativo. Se preenchidos, as RV serão aplicadas Produção: Preenchimento dos campos IBS/CBS passa a ser obrigatório conforme legislação. Para as NF-e e NFCe com IBS/CBS as RV serão aplicadas. Com valor jurídico para os novos tributos a partir de 01/01/2026. ¹ As datas foram reproduzidas no tópico conforme constam na Nota Técnica, no entanto, membros de nossa comunidade já relataram divergências nas datas estabelecidas na NT. Aguardemos novas informações. E como fica o ACBr? Esta versão traz modificações no leiaute e portanto modificações nas soluções do ACBr serão necessárias. Foi criada a tarefa ACBR-8146 para centralizar e registrar essas mudanças. Qualquer novidade será divulgada neste tópico ou em nossa área de notícias. Um agradecimento a todos os membros de nossa comunidade que compartilharam a informação da divulgação desta nova versão em nosso servidor do Discord. Leia a versão 1.30 dessa nota técnica completa AQUI.

IMPORTANTE: Alterações nas datas de implantação. Homologação: v1.10 deverá ser atualizada com schemas e RV´s até 20/10 (conforme capacidade de cada autorizador em efetuar as alterações) Produção: Os SCHEMAS da RTC serão disponibilizados em PRODUÇÃO no dia: 20/10/2025 Não ocorrerá troca de schemas no dia 06/10. Regra de validação que exige preenchimento do grupo IBS e CBS passa para implementação Futura (sem data definida) nos dois AMBIENTES. Caso o grupo IBS/CBS seja informado em qualquer um dos ambientes, TODAS AS REGRAS DE VALIDAÇÂO da NT 2025.001 serão aplicadas. *Em produção terá efeito a partir de 20/10 com a liberação do schema Fonte: https://dfe-portal.svrs.rs.gov.br/Cff/Avisos

Olá Pessoal, Os componentes ACBrCTe, ACBrNFe e ACBrMDFe possuem o método DistribuicaoDFePorNSU, DistribuicaoDFePorUltNSU e DistribuicaoDFePorChaveNFe (somente o ACBrNFe) deixam de usar as units: pcnDistDFeInt (responsável por montar o XML da consulta) e pcnRetDistDFeInt (responsável por ler o retorno) e passam a utilizar as novas units: ACBrDFeComum.DistDFeInt e ACBrDFeComum.RetDistDFeInt com a mesma finalidade das antigas, como uma diferença a nova unit responsável pela leitura do retorno se utiliza as rotinas do ACBrXmlDocument que já foi comprovado a sua velocidade em relação as rotinas do pcnLeitor. A priori vocês não vão precisar mudar nada nas suas aplicações, apenas atualizar todos os fontes de todas as pastas, reinstalar o ACBr com a opção de usar o ACBrXmlDocument marcada e por fim compilar a aplicação com a opção Build. Se por acaso na aplicação tiver uma linha semelhante a abaixo vai ter que fazer uma pequena alteração. Como esta hoje: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.Leitor.CarregarArquivo(OpenDialog1.FileName); Como deve ficar a partir da atualização dos fontes: ACBrNFe1.WebServices.DistribuicaoDFe.retDistDFeInt.CarregarArquivo(OpenDialog1.FileName); Como vocês podem ver basta remover o "Leitor." para que ocorra a compilação da aplicação.

Olá pessoal! Foi publicado no dia 22/09/2025 o Ajuste SINIEF Nº 22/2025, efetivamente postergando a obrigatoriedade do uso da Declaração de Conteúdo Eletrônica (DC-e, modelo 99) para o dia 06/04/2026. Vale ressaltar, que para o estado de SP, por exemplo, existe a portaria SRE28/2025 que define data diferente, portanto, apesar da publicação do ajuste, é importante que confirme a data junto a Sefaz de sua jurisdição Links úteis DC-e: Mais um documento para as transportadoras Portal do DC-e - Declaração de Conteúdo Eletrônica Programas exemplo do componente ACBrDCe nativos para Delphi/Lazarus DFe - Mudanças que estão em andamento para o ramo de transportes

deve ser o mesmo de cima, mas vocês estão a setar todas as propriedades e veja na sua imagem mesmo só informem os campos SSLLib como libWinCrypt e o SSLType em Webservices como TLS 1.2 os demais não mexe, não informa, remove as linhas

Uma outra solução seria você utilizar o Consulta Cadastro do componente ACBrNFe. Segue Exemplo de código abaixo: NFe.WebServices.ConsultaCadastro.UF := FUF; if Length(FCPF_CNPJ) > 11 then NFe.WebServices.ConsultaCadastro.CNPJ := FCPF_CNPJ else NFe.WebServices.ConsultaCadastro.CPF := FCPF_CNPJ; NFe.WebServices.ConsultaCadastro.Executar; Config := TIniFile.Create(ExtractFileDir(Application.ExeName) + '\Config.ini'); try Config.EraseSection('CONSULTA_CADASTRO_SEFAZ'); Config.WriteBool('CONSULTA_CADASTRO_SEFAZ', 'Usado', True); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'cStat', NFe.WebServices.ConsultaCadastro.cStat); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xMotivo', NFe.WebServices.ConsultaCadastro.xMotivo); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'UF', NFe.WebServices.ConsultaCadastro.UF); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'cUF', NFe.WebServices.ConsultaCadastro.cUF); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'CNPJ', NFe.WebServices.ConsultaCadastro.CNPJ); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'CPF', NFe.WebServices.ConsultaCadastro.CPF); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'IE', IfThen(NFe.WebServices.ConsultaCadastro.IE.Trim = '', NFe.WebServices.ConsultaCadastro.RetConsCad.IE, NFe.WebServices.ConsultaCadastro.IE)); Config.WriteDateTime('CONSULTA_CADASTRO_SEFAZ', 'dhCons', NFe.WebServices.ConsultaCadastro.dhCons); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'QuantCadEst', NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad.Count); for I := 0 to NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad.Count - 1 do begin Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'IE_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].IE); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'CNPJ_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].CNPJ); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'CPF_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].CPF); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'UF_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].UF); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'cSit_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].cSit); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'indCredNFe_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].indCredNFe); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'indCredCTe_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].indCredCTe); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xNome_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xNome); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xFant_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xFant); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xRegApur_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xRegApur); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'CNAE_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].CNAE); Config.WriteDate('CONSULTA_CADASTRO_SEFAZ', 'dIniAtiv_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].dIniAtiv); Config.WriteDate('CONSULTA_CADASTRO_SEFAZ', 'dUltSit_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].dUltSit); Config.WriteDate('CONSULTA_CADASTRO_SEFAZ', 'dBaixa_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].dBaixa); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'IEUnica_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].IEUnica); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'IEAtual_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].IEAtual); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xLgr_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xLgr); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'nro_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].nro); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xCpl_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xCpl); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xBairro_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xBairro); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'cMun_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].cMun); Config.WriteString('CONSULTA_CADASTRO_SEFAZ', 'xMun_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].xMun); Config.WriteInteger('CONSULTA_CADASTRO_SEFAZ', 'CEP_' + (I + 1).ToString, NFe.WebServices.ConsultaCadastro.RetConsCad.InfCad[I].CEP); end; finally Config.Free; end;