Painel de líderes

Olá Pessoal, Boas novas, foi implementado o provedor NFEletronica que no momento atende a cidade de Santana de Parnaíba/SP. Quem souber de outras cidades atendia pelo mesmo provedor, por favor crie um tópico no fórum para que possamos vincular o provedor a cidade. O provedor NFEletronica se utiliza da versão 1 layout da ABRASF, mas alguns serviços como por exemplo os de consulta foram alterados. A principio só foi implementado o envio do RPS. Precisamos da colaboração de vocês no que se refere aos testes para que possamos fazer as devidas correções e a implementação dos demais serviços. Desde já muito obrigado por tudo.

Na fiscalização que ocorreu, qual a legislação e artigo mencionados?

Bom dia @Sistemas Drogal Observe que no primeiro item aparece no CFexxxxxxxxxxxxxxxxxxxxxxxx (lembrando q este é um XML SAT a o prefixo correto é AD e não CFe) Já no item 2 que não aparece: ICMS 40 – Isenta, CST 60 Cobrando Anteriormente... e Pis/Cofins=4 ( Operação Tributável Monofásica – Revenda a Alíquota Zero ) Entao se a aliquota 0 nao existe valor de PIS e COFINS. Dependendo do código utilizado não será exibido estas informações no retorno da sefaz.

Olá pessoal! Ao acessar o portal SPED MG consta um aviso com a seguinte informação: A mesma deixa claro que no ambiente de homologação, será devolvido a mensagem de consumo indevido caso uma mesma rejeição de Duplicidade de NF-e com diferença na Chave de Acesso seja devolvida mais de 200 vezes em um período de uma hora. Por isso, é importante que verifiquem se sua aplicação possui um processo em loop que possa causar uma situação como esta. Por que isso é tão importante? Porque conforme observações nas regras de consumo indevido presentes na NT2018/002, a rejeição de consumo indevido faz com que seja necessário aguardar o período de uma hora para poder voltar a consumir o web service, no entanto, a critério da UF, após 50 bloqueios o contribuinte pode receber a rejeição 656 permanentemente até entrar em contato com a UF autorizadora para regularização.

Boa tarde! Atualizei a classe do ACBrPIX para Gerencianet, agora com os endereços apontados para Efí, e propriedade PartnerToken para quem tem parceria com a Efí. ACBrPIXPSPGerenciaNet.pas ACBrPIXPSPGerenciaNet.dcu

Está entrando em uma questão que não diz respeito a emissão do documento fiscal em si, você está com dúvidas no preenchimento do arquivo SPED e não na emissão do documento fiscal. Você começou o tópico com o assunto de SAT depois migrou para NFCe, agora está migrando e entrando na esfera de SPED Contribuições. nesse caso você precisa verificar com o departamento fiscal da empresa ou consultoria tributária para não gerar os blocos com informação errônea, leia novamente o Guia Prático acredito que tem algumas coisas que você está comentando ai que são para ocorrências de até o ano 2018. lembrando que o Guia do Sped é um material de apoio, podendo haver legislações especificas no RICMS de cada UF que precisa ser tratadas pela aplicação.

Como não respondeu que a versão oficial estava liberada fiquei na dúvida, pois sempre coloca quando gera uma versão. Vou atualizar então. Obrigado

Foi criada uma #TK-6045, vamos analisar o caso e daremos um retorno, combinado ?

@André Melim, A unit que eu mencionei não deve ser alterada, é para você a abrir e estudar ela. Os dados devem ser informados nos campos (vide o programa exemplo do componente) Ele tem 3 procedure que exemplifica a alimentação dos campos, uma é para os provedores que se utilizam do layout da ABRASF, outra para os provedores que tem o seu próprio layout (que é o caso do provedor ISSDSF) e a terceira e ultima para o Padrão Nacional.

Ya resolví el problema. El problema es la línea de código: sConcepto0 := dmAG.qFacTiqARTICULO.AsString; El campo ARTICULO estaba vacio y daba el error. Gracias por todo.

Boa tarde Italo, ok, obrigada pela orientação.

No caso ai vale uma validação do contador dele junto ele nos cadastros. ele poderia estar usando um generico qualquer e ao passar ao seu sistema como não passava o outro e mudou ele rejeito. é algo que o contador deve se preocupar em revisar os cadastros e tributações meio que periodico com o cliente

Perfeito pessoal Resolvido! Obrigado !

Boa tarde! Apenas complementando a resposta do meu amigo @Italo Giurizzato Junior, também partilho da opinião dele de que não vai ocorrer consumo indevido. Desde que você gerencie o processo de consulta de forma a não consultar a mesma nota. Sendo mais específico a NT2018/002 é a nota técnica que trata sobre consumo indevido nos web services da Sefaz. Nela temos: Veja que a regra de validação e a mensagem deixam explícito que se você consultar em looping uma mesma NF-e mais de 10 vezes no período de uma hora, vai ser bloqueado. Então faça a consulta de forma que ele não fique travado na consulta de uma mesma nota.

Italo, boa tarde... Só corrigindo um erro na digitação: a alteração da IPM para a prefeitura já aconteceu foi no dia 30/09/2024, última segunda-feira. Perdão pela gafe.

boa tarde, não procede esse caso. como é o caso da CST 04. você está argumentado que é Alíquota 0, mas está informando CST 04, cujo não possui tal informação de base de calculo. se "fiscal" questionou você sobre isso, sugiro reportar a legislação em que isso está embasada para um melhor entendimento. se tu for olhar os próprios schemas, não consta isso que foi solicitado ou desejado por ti no caso das CST 04,06,07,08,09 NFE / NFCE SAT

@Center Informática, Entendi a sua situação. Você vai usar o componente ACBrNFe para consultar pela chave (método Consultar) cada uma das notas. O componente ACBrNFe deverá ser configurado com o certificado digital da transportadora que vai emitir o CT-e. Eu acredito que não vai ocorrer consumo indevido.

Por favor verifique se as DLLs do OpenSSL estão na mesma pasta do seu .EXE http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/OpenSSL/1.1.1.10/X86/

Boa tarde @Adrian Kempinski, Caso esteja com todos os fontes de todas as pastas atualizados, note que a nova versão do ACBrInstall temos a seguinte opção: Marque a opção para usar o ACBrXmlDocument. Essa alteração vai afetar todos os componentes DF-e (ACBrNFe, ACBrCTe, ACBrMDFe, etc). Eu acredito que a nova unit responsável pela leitura do XML escrita para o CT-e vai conseguir ler corretamente o XML, além dela ser muito mais rápida.

Boa tarde @Eduardo Resende Lara, Por favor não cole o conteúdo do XML com parte do texto da postagem, procure sempre anexar o arquivo. Abra o arquivo ACBrNFSeXServicos.ini e faça a seguinte alteração: [3118601] Nome=Contagem UF=MG Provedor=Ginfes Params=NaoFormatarItemServico: ProLinkURL=http://contagem.ginfes.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null HomLinkURL=http://contagem.ginfesh.com.br/report/consultarNota?__report=nfs_ver4&cdVerificacao=%CodVerif%&numNota=%NumeroNFSe%&cnpjPrestador=null Depois siga os passos indicados no inicio do mesmo arquivo.

Boa tarde @Center Informática, Temos o método Consultar onde você informa a chave da NF-e, mas apesar dessa consulta não ser assinada digitalmente para consumir o respectivo serviço no webservice da SEFAZ se faz necessário o certificado digital do emitente da nota ou de quem esta realizando a consulta.

Boa tarde Italo! Muito bom! Ótimo! Claro, vamos fazer os testes. Muito obrigada!

Olá pessoal! Recentemente temos recebido relatos de membros da comunidade com problemas para realizar o envio de e-mail quando o provedor é o da Microsoft(@hotmail, @outlook e afins). Um membro de nossa comunidade compartilhou a seguinte mensagem que recebeu da Microsoft: Esses "métodos modernos de autenticação" se referem ao Oauth 2.0 (Veja mais em Os Métodos de Autenticação Modernos agora necessários para continuar a sincronizar o E-mail do Outlook em aplicações de e-mail não Microsoft). O que é o Oauth 2.0? O Oauth 2.0 é um protocolo de autorização que funciona através de tokens de acesso e foi projetado primariamente com o objetivo de conceder acesso a determinados recursos de aplicações de usuários. Neste caso em questão, seria o acesso ao e-mail. Como fica o ACBrMail? Atualmente o ACBrMail não tem suporte a Oauth 2.0, foi criada em nosso backlog a tarefa #TK-6042 para análise e implementação da mesma. É o fim do ACBrMail então? O que eu faço agora? Não é o fim do ACBrMail. Conforme mencionado anteriormente, será analisada implementação do Oauth 2.0 no mesmo. Enquanto isso não ocorre, para provedores como o g-mail, por exemplo, ainda é possível fazer a comunicação com a Senha de App. Para a Microsoft, nos testes realizados pela equipe de consultores, Microsoft365 ainda demonstra estar funcionando, o HotMail e o Outlook que pararam de funcionar. Outra opção também seria o uso de um provedor de e-mail próprio.

Bom dia pessoal! Eu fiz um implementação do OAuth2 no ACBrMail a unit1 do anexo é alteração do exemplo do ACBr. Ainda falta o tratamento erros, mas já está funcional. Referencias: https://github.com/rvk01/google-oauth2/tree/master https://www.emailarchitect.net/easendmail/ex/d/23.aspx ACBrMail.pas unit1.pas unit1.dfm

Bom dia @Jhoni Conzatti A maioria dos fontes que vi, é criando um servidor http local para receber os tokens, por enquanto está funcionando... Só lembrando que os fontes que disponibilizei é baseado no https://github.com/geoffsmith82/GmailAuthSMTP @Juliomar Marchetti esse repositório https://github.com/rvk01/google-oauth2 é feito lazarus e synapse feito para o Gmail, mas acho que dá para fazer para Outlook...

Bom dia! Fiz o teste passando o a data sem hora e funcionou. Obrigado.

Depois de algum tempo conseguimos identificar o que ocorria. Em conversa com o pessoal do Sicredi, os mesmos nos informaram que os boletos híbridos utilizam uma chave aleatória, caso essa chave tenha sido excluída esse vinculo é desfeito causando o problema mencionado. Além disso, nos repassaram que. caso isso aconteça, deve ser entrado em contado com o gerente da conta do cooperado e solicitar que a opção de boleto híbrido seja desabilitada, salve e reabilite para que o vínculo seja refeito.

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

https://github.com/geoffsmith82/GmailAuthSMTP/tree/master Dá uma olhada neste github. Creio que terá de desenvolver o envio com Oauth, esta não é a parte complicada, mas sim criar as chaves. É algo que o cliente final não conseguirá e precisará do suporte para fazer todo o processo.

Boa noite. Realmente estava faltando os dados do tomador, agora deu certo, muito obrigado Diego.

Olá Pessoal, Para ajudar na problemática do envio de e-mail via Outlook quero disponibilizar código-fonte para usar autenticação OAuth2 da Microsoft/Google. Será necessário entrar no site https://portal.azure.com/ , Microsoft Entra ID, registrar um novo aplicativo, adicionar a permissão "SMTP.Send", criar uma senha secreta.........só dar uma pesquisada no google que acha algum tutorial.... Para usar com o ACBrMail, vai precisar instanciar o objeto do oauth e gerar o token......com o token gerado é só passar na propriedade "Password" do TACBrMail junto com o "Username" que será o e-mail da conta. Uma rotina extra que vc terá que ter, é atualizar o "RefreshToken" do OAuth de tempo em tempo conforme a data de expiração que retorna do componente.. Espero ter ajudado.... OAuth2.Gmail.pas OAuth2.Outlook.pas OAuth2.pas

então já faça juz e passe a usar a lib senão programa em delphi ou o monitor se não deixa consumir e dai sim estará usando algo que não precisa ficar a cada momento correndo atrás

Daniel Obrigado e parabéns. Eu sabia que tinha ouvido falar disso em algum lugar, mas não sabia onde procurar. O contador estava certo só não citou a fonte...rsrsrs

Assinar o exetável com um certificado de assinatura de aplicações de sua empresa.

Bom dia! Em seu XML está faltando a "Identificação do tomador do serviço no CT-e", grupo obrigatório e que vem antes do grupo infCarga de acordo com o layout trazido na NT.

Exemplo ACBrMonitorPlus Solicitar a movimentação da carteira de cobrança registrada para beneficiário informado; Alimentar um titulo para que o componente pegue alguns parâmetros como contrato, cedente (valor pode estar zerado) Na consulta, passar os parâmetros no arquivo INI: BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=1 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0") Atenção, o envio das consultas deve ser realizado pelo parâmetro: TpConsulta Boleto.Configuracoes.WebService.Operacao := tpConsulta; Esta consulta vai te retornar o código da solicitação na propriedade NossoNumeroCorrespondente: Msg_Retorno=Solicitação recebida com sucesso. Utilize o 'Código da Solicitação' para verificar se já foi processada. Ori_Retorno= HTTP_Result=200 ... NossoNumeroCorrespondente = 28505038 Consultar a situação da solicitação da movimentação Alimentar um titulo para que o componente pegue alguns parâmetros como contrato, cedente (valor pode estar zerado) Na consulta, passar os parâmetros: CodigoSolicitacaoConsultaMovimentacao (numero devolvido na consulta anterior na propriedade NossoNumeroCorrespondente) BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=1 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0 NumeroProtocolo=28505038") Esta consulta vai te retornar a lista Lista de arquivos de movimentação disponíveis para Download na propriedade: NossoNumeroCorrespondente No exemplo abaixo, observe que temos 2 ID de arquivos disponiveis dentro da lista de Boletos: [Boletos Index = 000] e [Boletos Index = 001] : Cod_Retorno= Msg_Retorno=-Quantidade de arquivos :2 Ori_Retorno= HTTP_Result=200 JSON= indicadorContinuidade=0 proximoIndice=0 [Boletos Index = 000] numeroBoleto = SeuNumero = dataRegistro = 30/12/1899 dataVencimento = 30/12/1899 NossoNumeroCorrespondente = 11694670 DataBaixa = 30/12/1899 [Boletos Index = 001] numeroBoleto = SeuNumero = dataRegistro = 30/12/1899 dataVencimento = 30/12/1899 NossoNumeroCorrespondente = 11694671 DataBaixa = 30/12/1899 Download e Leitura do(s) arquivo(s) de movimentação. Alimentar um titulo para que o componente pegue alguns parâmetros como contrato, cedente (valor pode estar zerado) Na consulta, passar os parâmetros: CodigoSolicitacaoConsultaMovimentacao (numero devolvido na primeira consulta na propriedade NossoNumeroCorrespondente) IDArquivoSolicitacaoConsultaMovimentacao (numero devolvido na consulta anterior devolvido na propriedade ListaArquivosConsultaMovimentacao *Lembrando que é necessário realizar uma consulta para cada IdArquivo da lista de consulta. BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=1 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0 NumeroProtocolo=28505038 Identificador=11694671") Esta consulta vai fazer o download do arquivo de movimentação com id (11589536) e tratar automaticamente este arquivo, devolvendo como uma resposta padrão das consultas API; Filtro de Consultas Disponíveis: O Sicoob disponibiliza algumas consultas por tipo de movimento: Entrada, Prorrogação, A Vencer, Vencido, Liquidação e Baixa Exemplo de filtros de movimento na consulta: Entrada: Observe que além do IndicadorSituacao 1 (Aberto) , passamos o filtro boletoVencido como 0 (Nenhum): BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=1 boletoVencido=0 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0") A Vencer: Observe que além do IndicadorSituacao 1 (Aberto) , passamos o filtro boletoVencido como 1 (Não): BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=1 boletoVencido=1 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0") Vencido Observe que além do IndicadorSituacao 1 (Aberto) , passamos o filtro boletoVencido como 2 (Sim): BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=1 boletoVencido=2 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0") Liquidados Observe o IndicadorSituacao 2 (Baixado): BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=2 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0") Baixados Observe o IndicadorSituacao 3 (Cancelado): BOLETO.ConsultarTitulosPorPeriodo("[ConsultaAPI] IndicadorSituacaoBoleto=3 DataInicioMovimento=07/09/2024 DataFinalMovimento=09/09/2024 indiceContinuidade=0")

Olá Pessoal, Muitos DF-e (Documentos Fiscais Eletrônicos) foram implementados para o seu envio ser em Lotes contendo de 1 até 50 documentos. Esse modo de envio em lote funciona no modo assíncrono. Outros DF-e já foram implementados com o modo de envio unitário, ou seja, só podemos enviar um documento por vez, consequentemente esse modo de envio funciona no modo síncrono. A primeira diferença que podemos notar é: No envio assíncrono podemos enviar um lote contendo de 1 até 50 documentos, já no envio síncrono podemos enviar somente um documento por vez. A segunda diferença diz respeito ao retorno: No envio assíncrono temos como retorno do webservice um numero chamado de Recibo que atesta que o webservice recebeu o lote enviado, por outro lado no envio síncrono não temos o numero do Recibo como retorno. A terceira diferença se refere ao resultado do processamento: No envio assíncrono devemos realizar uma consulta se utilizando do numero do Recibo. É o retorno dessa consulta que nos vai dizer se o(s) documento(s) enviado(s) para o webservice foi ou foram processado(s) com sucesso. Já no envio síncrono não temos no retorno o numero do Recibo, logo não temos como realizar a consulta pelo numero do Recibo, alias não se faz necessário uma vez que no retorno do envio síncrono o que temos de retorno já é o resultado do processamento, portanto já temos na resposta se o documento foi processado com sucesso ou não. DF-e que já nasceram com o modo de envio Síncrono: BP-e = Bilhete de Passagem Eletrônico BP-e TM = Bilhete de Passagem Eletrônico Transporte Metropolitano GTV-e = Guia de Transporte de Valores Eletrônico DC-e = Declaração de Conteúdo Eletrônica NFCom = Nota Fiscal de Comunicação Eletrônica DF-e que nasceram com o modo de envio Assíncrono e que mudaram ou vão mudar para Síncrono: CT-e = Conhecimento de Transporte Eletrônico (desde 06/2023 só funciona o modo Síncrono) CT-e OS = Conhecimento de Transporte Eletrônico Outros Serviços (desde 06/2023 só funciona o modo Síncrono) MDF-e = Manifesto de Documentos Fiscais Eletrônicos (Modo Assíncrono será desativado em 30/06/2024) NFC-e = Nota Fiscal ao Consumidor Eletrônica (desde 04/09/2023 só funciona o modo Síncrono) DF-e que possui os dois modos de envio Assíncrono e Síncrono: NF3-e = Nota Fiscal de Energia Elétrica Eletrônica Observação: Notem que nas listas acima não aparece a NF-e = Nota Fiscal Eletrônica, o motivo é que a NF-e nasceu somente com o modo Assíncrono de envio, depois passou a ter o modo de envio Síncrono, mas este modo não se encontra disponível na SEFAZ de São Paulo e Bahia. O Fisco já sinalizou que pretende acabar com o modo de envio Assíncrono da NF-e, deixando somente o modo Síncrono. A motivação para essa mudança é que por volta de 90% dos lotes recepcionados por todas as SEFAZ de todas as UF possuem somente um documento. Sendo assim não faz muito sentido consumir dois serviços (Recepção e Consulta) para apenas um documento, lembrando que no modo Assíncrono se faz necessário a Consulta pelo numero do Recibo para obter o resultado do processamento. Já que 90% dos contribuintes enviam as suas notas de forma unitária, ou seja, uma nota por vez, tanto a SEFAZ quanto o desenvolvedor do Software sairiam ganhando com essa mudança, pois a SEFAZ eliminaria o serviço de Consulta pelo numero do Recibo e o Software ficaria mais rápido pois não precisaria executar essa consulta. Quando vai ocorrer essa mudança não sei, o Fisco não disse quando, mas vai ocorrer. Codificação para quem utiliza os componentes: A titulo de exemplo será utilizado o componente ACBrMDFe, mas podemos replicar para os demais. O método Enviar possui 3 parâmetros: function Enviar(const ALote: String; Imprimir: Boolean = True; ASincrono: Boolean = False): Boolean; overload; ALote = Numero do Lote que contem os documentos a serem enviados para o webservice da SEFAZ. Imprimir = Se True (valor padrão) diz que o Documento Auxiliar vai ser impresso no final do processo, se False diz que não vai ser impresso. ASincrono = Se False (valor padrão) diz que o modo de envio é Assíncrono, se True diz que o modo de envio é Síncrono. Exemplo de Envio no modo Assíncrono (só deve ser utilizado pelos DF-e que ainda possuem esse modo de envio): ACBrMDFe1.Enviar(NumLote); ou ACBrMDFe1.Enviar(NumLote, False); Exemplo de leitura do retorno do envio no modo Assíncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Retorno.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Retorno.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Retorno.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Retorno.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Retorno.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Retorno.Recibo); Lines.Add('Protocolo: ' + ACBrMDFe1.WebServices.Retorno.Protocolo); end; Exemplo de Envio no modo Síncrono (utilizado pelos DF-e que só possuem ou também tem este modo de envio): ACBrMDFe1.Enviar(NumLote, True, True); ou ACBrMDFe1.Enviar(NumLote, False, True); Exemplo de leitura do retorno do envio no modo Síncrono: with MemoDados do begin Lines.Add(''); Lines.Add('Envio MDFe'); Lines.Add('Chave: ' + ACBrMDFe1.Manifestos[0].MDFe.procMDFe.chMDFe); Lines.Add(''); Lines.Add('tpAmb: ' + TpAmbToStr(ACBrMDFe1.WebServices.Enviar.tpAmb)); Lines.Add('verAplic: ' + ACBrMDFe1.WebServices.Enviar.verAplic); Lines.Add('cStat: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cStat)); Lines.Add('xMotivo: ' + ACBrMDFe1.WebServices.Enviar.xMotivo); Lines.Add('cUF: ' + IntToStr(ACBrMDFe1.WebServices.Enviar.cUF)); Lines.Add('xMsg: ' + ACBrMDFe1.WebServices.Enviar.Msg); Lines.Add('Recibo: ' + ACBrMDFe1.WebServices.Enviar.Recibo); end; E para quem usa ACBrLib ou ACBrMonitorPLUS? Os diferentes modos de envio também são considerados e estão disponíveis em ambas as soluções. No que diz respeito ao envio, os comandos também possuem um parâmetro que define se o envio será síncrono ou assíncrono. Vamos ver o exemplo do MDFe: Para a ACBrLib: MDFE_Enviar(ALote, AImprimir, ASincrono, sResposta, esTamanho); ALote: Número do Lote a ser enviado. AImprimir: Se True, imprime DAMFDe caso o MDFe seja autorizado. ASincrono: Se True envia o MDFe em modo sincrono. sResposta: Usado pelo retorno, contem as informações retornadas pela consulta. esTamanho: Usado pelo retorno, contem o tamanho da string (sResposta). Então o comando ficaria: MDFe_Enviar(ALote, AImprimir, False, sResposta, esTamanho) ou MDFe_Enviar(ALote, AImprimir, True, sResposta, esTamanho) Para o ACBrMonitorPLUS: MDFE.ENVIARMDFe(nXMLMDFe, [nLote], [nAssinar],[nImprimi],[nImpressora], [bAssincrono], [bEncerrado] ) nXMLMDFe: Caminho do XML do MDF-e nLote: Número do Lote (opcional) nAssinar: Assinar o XML (opcional - informe 0 para não assinar) nImprimi: Imprimir MDF-e (opcional - informe 1 para imprimir) nImpressora: Nome da Impressora (opcional) bAssincrono: Por padrão o envio é Assíncrono, informa "False" para envio Sincrono bEncerrado: Imprimir Mensagem de "MDFe Encerrado", (opcional - informe 1 para imprimir) Ficando: MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, True, bEncerrado) ou MDFe.EnviarMDFe(nXMLMDFe, nLote, nAssinar, nImprimi, nImpressora, False, bEncerrado) A hora de ler a resposta também muda um pouco. No envio assíncrono, temos uma seção [Envio], [Retorno] e [MDFe + Numero do Documento]. Já no envio síncrono, não existe mais a seção [Retorno] e a seção MDFe é concatenada com a chave de acesso. Resposta Assíncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [Retorno] CStat= CUF= ChaveDFe= DhRecbto= Msg= Protocolo= VerAplic= Versao= XMotivo= cMsg= nRec= tpAmb= xMsg= [MDFe1] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo= Resposta Síncrona: [Envio] CStat= CUF= DhRecbto= Msg= NProt= NRec= TMed= TpAmb= VerAplic= Versao= XMotivo= Xml= [MDFe12345678901234567890123456789012345678901234] Id= XML= cStat= chDFe= dhRecbto= digVal= nProt= tpAmb= verAplic= xMotivo=

Contextualizando. As configurações de SSLLib, CryptLib, HttpLib, XmlSignLib e SSLType são comuns a todos as soluções de Documentos Fiscais Eletrônicos do ACBr. Aqui vamos considerar os exemplos nativos, mas essas configurações também se aplicam ao ACBrMonitorPLUS e ACBrLib. As configurações SSLLib, CryptLib, HttpLib e XMLSignLib costumam ficar na aba Certificado dos programas exemplo e podem ser definidas via código da seguinte maneira: ComponenteDFe.Configuracoes.Geral.SSLLib := libOpenSSL ou libWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.CryptLib := cryOpenSSL ou cryWinCrypt;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLHttpLib := httpOpenSSL ou httpWinHttp;//Dependendo do tipo de certificado ser A1 ou A3. ComponenteDFe.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Se o certificado digital for A3 só vai ser possível usar as configurações do WinCrypt, por outro lado se for A1 poderá usar o WinCrypt ou OpenSSL. Recomendamos fortemente que o certificado seja A1. Desta forma podemos usar o OpenSSL e não precisamos nos preocupar com a versão Windows e suas atualizações. Além disso, o certificado não precisa ser instalado, pode ser lido de uma pasta onde esta salvo ou de um campo do banco de dados. Essas configurações influenciam comportamentos como protocolo de comunicação, assinatura, validação de schema, entre outros. Já a configuração SSLType costuma ficar na aba WebService dos programas exemplos e pode ser definida via fonte assim: ComponenteDFe.SSL.SSLType := LT_TLSv1_2; Como o nome sugere, essa configuração influencia se vai qual protocolo TLS ou SSL será usado na comunicação. Porque você está atrasado. Além de não suportar 64 bits, a Microsoft condenou a CAPICOM como obsoleta desde 2016. Então, se você ainda usa configuração de Capicom está usando algo defasado, aberto a erros e com brechas de segurança. A MsXML foi descontinuada pela Microsoft em 2014 e atualmente é considerada obsoleta. Usar essa configuração para assinatura ou validação significa usar algo ultrapassado, que não sofre manutenção e com maior propensão a erros. Se você vai usar certificado A3, não deve em hipótese alguma usar MsXML, sob risco de inutilizar a chave privada do certificado digital. Praticamente todos os DFes atuais estabeleceram que deve ser usado TLS1.2 na comunicação. Por isso, foi atualizado nos fontes para que os DFes usem como padrão TLS1.2 ao invés de LT_all. Se você mesmo assim ainda usa essa configuração, o componente vai usar o primeiro protocolo disponível e não o mais indicado. O que eu uso então? As configurações recomendadas por tipo de certificado podem ser encontradas neste tópico: Caso prefira, também pode acompanhar este vídeo com orientações e demonstração prática: Mais informações. Veja mais detalhes sobre como o ACBr deu Bye Bye para a Capicom neste tópico: No tópico abaixo foi relatado o problema com MsXML e perda da chave privada de certificados A3:

Boa tarde pessoal, Temos recebido informações de nossa comunidade de que infelizmente a SEFAZ-SP continua enfrentando problemas quanto a NFCe, conforme o relato do nosso colega @wandarlei, em seu contato recente com a SEFAZ, os mesmos relataram que parte dos contribuintes continuam tendo problemas e estão atuando para sanar o mais breve possível.

Depois de 3 dias tentando fazer funcionar.. enfim funcionou! Problema: Cliente havia trocado sua internet. (só me falou depois) Ligou para seu provedor e disse que não estava conseguindo emitir notas pra sefaz... fizeram alguma configuração lá e voltou a funcionar Obrigado a todos... Mais uma pra lista de coisas incríveis de clientes.