Painel de líderes

Nessa tag você deve informar o CNPJ do autor do evento, que no caso do evento de prestação em desacordo é o próprio tomador do serviço.

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

Para ficar registrado, conforme explicado pela @Gr@c@, uma forma do campo obscont tanto da Nfe como do CTe ser utilizado hoje é para as informações de averbação. Pode ser que um fiscal multe caso essa informação não seja impressa. Mas caso contrário, vale o que está no MOC. Por isso... Alphajoy. Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17957. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Ah, entendi! É por que os ajustes que eu realizei foram apenas para o CNAB 240.

@joaolenosi boa tarde! Já tinha visto os ajustes ora mencionados e antes de iniciar meu processo de homologação com o Banco Safra tive o cuidado de atualizar meus fontes do ACBr(em 14/10/2019), já com seus ajustes, porém como mencionei logo mais acima o Banco Safra rejeito nosso arquivo de remessa CNAB 400, alegando estar diferente a informação do campo nosso número no arquivo de remessa em comparação com o mesmo dado no boleto, na composição da linha digitável e código de barras. Reforço novamente que fiz um pequeno ajuste na geração do arquivo de remessa CNAB 400 apenas removendo o cálculo do dígito verificador do campo nosso número no arquivo, e após isso tivemos a validação homologada pelo banco. Sendo assim fico no aguardo de uma posição dos commiters, para possível aplicação do commit desse ajuste ao SVN. @Juliana Tamizou , poderia por gentileza dar acompanhamento nesta situação.

Está no Build de Debug... mude para Release

Bom dia, quando um lote havia mais de um rps, ao assinar o segundo rps a assinatura do primeiro ficava inválida, mas atualizando os fontes está tudo certo. Obrigada pela atenção e ajuda.

Olá pessoal, Queremos informar que na revisão 17943 foi enviada ao SVN as alterações previstas a algumas semanas para padronizar as unidades de medidas e comportamento das margens nas impressões. Caso queira mais informações, veja o tópico de anúncio:

Olá Como sabemos o Projeto ACBr foi implementado mantendo a compatibilidade com o Delphi e Lazarus, porém, os arquivos de Formulário no Delphi (.dfm) não é o mesmo utilizado pelo Lazarus, que possui a extensão (.lfm) e utiliza o formato UTF-8. Por esse motivo, quando realizarmos alterações em Formulários do ACBr utilizando o Delphi(.dfm), devemos compatibiliza-lo também no Formulário do Lazarus(.lfm). A forma mais fácil de realizar esta tarefa é Converter o Arquivo alterado, assim não precisamos realizar as mesmas alterações nos dois arquivos. Segue abaixo o procedimento para Conversão. 1- Exclua o arquivo com a extensão .lfm, que já existe no Projeto. ex: ACBrNFeDANFeRLRetrato.lfm 2- Realize uma Cópia do Arquivo .dfm que foi alterado. ex: ACBrNFeDANFeRLRetrato - Copia.dfm 3- Renomeie o Arquivo copiado com o mesmo nome do original, mas altere a extensão para .lfm ex: ACBrNFeDANFeRLRetrato.lfm 4- Abra o arquivo .lfm utilizando o NotePad++ e selecione a opção Converter para UTF-8 (caso ainda não esteja em UTF-8). Salve as alterações... ex: 5- Abra o Formulário Alterado no Lazarus, mova o posição do formulário apenas para poder Salvar as alterações e Compile o Projeto.. Note que ao salvar o formulário utilizando o Lazarus os caracteres acentuados que estavam codificados agora estarão corretos... Basta então testar a Aplicação... Antes: Depois:

Moderador pode fechar o tópico. O problema era causado pelo hardware.

Olá Pessoal, Já encontra-se disponível no repositório Trunk2 o mais novo componente ACBr - ACBrONE - Operador Nacional dos Estados. "O Operador Nacional dos Estados: ONE é o sistema responsável por integrar os documentos fiscais eletrônicos das Administrações Tributárias com as diversas tecnologias de identificação de veículos nas rodovias brasileiras. O sistema objetiva a geração dos eventos Registro de Passagem nos documentos fiscais transportados por intermédio da informação da placa do veículo e sua respectiva geolocalização, detectada por algum dispositivo ou tecnologia de monitoramento, o que auxilia nas ações de fiscalização de trânsito e de combate à sonegação." O texto acima foi retirado do Portal do Operador Nacional dos Estados - SVRS. Para mais informações visite o Portal. O manual do ONE já baixamos e se encontra em nossa biblioteca. Nas pastas: ...\Exemplos\ACBrDFe\ACBrONE\Delphi ===> temos o programa exemplo do componente. ...\Exemplos\ACBrDFe\Schemas\ONE ===> temos os schemas ...\Fontes\ACBrDFe\ACBrONE ===> temos os fontes ...\Pacotes\Delphi\ACBrDFe\ACBrONE ===> temos o pacote de instalação. Por enquanto o ACBrInstall_Trunk2 não esta preparado para instalar esse componente, logo será necessário a instalação manual através do Pacote. Observação1: apesar dos XMLs a serem enviados não precisam ser assinados digitalmente é preciso de um certificado digital para consumir os Webservices. Observação2: Não é qualquer empresa que pode usar o ONE é preciso que ela esteja cadastrada como uma Operadora.

Olá pessoal! Temos o prazer de informar que mais um novo componente foi adicionado ao projeto: ACBrLCDPR. O ACBrLCDPR foi criado para facilitar a geração do LCDPR - Livro Caixa Digital do Produtor Rural. Esse componente segue a mesma ideia de outros componentes para geração de arquivos como ACBrSPEDFiscal, ACBrSPEDPISCOFINS, ACBrSEF2, etc... Com ele você pode gerar o arquivo sem se preocupar com o layout do arquivo. A sua preocupação será apenas com as informações que precisa aprensentar. Como é um componente novo, temos consciência de que alguns ajustes talvez sejam necessários. Todos podem ficar à vontade reportar problemas. Podem fazer isso por criar um novo tópico com ajustes e anexar nele. Crie o tópico no subfórum ACBrTXT -> Outros (ACBrLFD, ACBrSEF2, etc). Mas queremos agradecer ao @Willian Hübner que pôs a mão na massa e fez a doação do componente que serviu como base dessa versão. Queremos também aproveitar a oportunidade para agradecer aos nossos usuários SAC. Seu apoio nos ajuda a continuar avançando.

Boa tarde! Realizei um ajuste na geração da remessa do Banco do Brasil para enviar no campo "Identificação da Distribuição" (Posição 62 do Segmento P) a opção "3 - Banco envia e-mail" quando a propriedade ACBrTitulo.CarteiraEnvio for tceBancoEmail. No leiaute do próprio BB esse campo possui a observação "Campo não tratado pelo Banco do Brasil.", porém uma homologação de remessa foi rejeitada por não enviar essa opção quando no campo "08.3S - Identificação da Impressão" (Posição 18 do Segmento S) informei "8 - Bloqueto por email". Em anexo envio a unit alterada para análise e o manual do BB utilizado para homologação. Caso estejam de acordo peço que subam para o SVN. Grato. Cnab240PARTICULARIDADES.pdf ACBrBancoBrasil.pas

No ArqINI: Antigo: [3118601] Nome=Contagem UF=MG Provedor=Pronim; Novo: [3118601] Nome=Contagem UF=MG Provedor=Ginfes;

Boa tarde. Obrigada pela contribuição, a mesma foi adicionada para validação. Att.

Boa tarde Gean, Realmente no fórum as coisas ficam dispersas. Mas voltando ao assunto do evento de prestação de serviço em desacordo, chegou a ler o artigo: Evento de Prestação de Serviço em Desacordo ? Curiosidade, o que vem a ser: "anulacao pelo desacordo...ou o desaacordo no mdfe e a anulacao no cte" ?

Acho que devia aceitar. Faça teste usando outra configuração SSLXmlSignLib.

Exato, estamos usando libWinCrypt

Você pode usar certificado próprio e usar o ambiente de homologação do Amazonas: http://portalnfce.sefaz.am.gov.br/desenvolvedor/ambiente-de-homologacao-para-desenvolvedores/ Apenas note que algumas regras são opcionais por UF então nos testes estará sujeito apenas àquelas ativadas pelo AM.

Qual exatamente o problema que teve com relação as fontes? Não consegui simular. De qualquer forma fiz ajustes nos nomes das fontes do .fr3, por favor faça teste com o arquivo anexo e veja se terá o mesmo problema. DACTE2Vias.fr3

Bom dia, eu já corrigi essa Unit faz algum tempo, inclusive eles já disponibilizaram a correção no SVN. Conforme pode ser visto aqui:

Italo, agradeço pela ajuda, consegui fazer funcionar o problema estava no arquivo SimpllSS.ini no [GrupoMsgRet], só atualizei o arquivo e funcionou como esperado.

obrigado bigwings uma informação que talvez seja util, é que nota fiscal estamos conseguindo fazer normalmente, por isso que escrevi que sao nos eventos o erro. windows 10 pro build 1903

muito obrigada, no início da semana os arquivos retornaram com esse erro, mas hoje cedo foram transmitidos com sucesso.

obrigado, e desculpe a demora em responder estive fora, mas essa configuração funcionou perfeitamente.

Não encontrei nenhuma informação na área de perguntas respondidas: http://caf.sef.sc.gov.br/Views/Publico/BaseConhecimento/BuscarBaseConhecimento.aspx?assunto=9 Então a primeira verificação é se os schemas estão corretos e são de homologação. Você também pode tentar enviar um arquivo com a data do ano que vem e verificar se vai passar. Caso contrário, sugiro entrar em contato com a Sefaz e perguntar como proceder.

Eu uso o layout Default layout mesmo sem ter um monitor 4K. A única coisa que eu faço é colocar o Project Manager e o Tool Palette para auto-ocultar.

Contagem- MG no ArqINI: Antigo: [3118601] Nome=Contagem UF=MG Provedor=Pronim; Novo: [3118601] Nome=Contagem UF=MG Provedor=Ginfes;

Cara, se você tiver Lazarus ou Delphi aí é só olhar os fontes que faz a criptografia/descriptografia com o ACBr, aí vc pode replicar ela para o conjunto de dados que vc tem. Aqui no fórum mesmo vc vai encontrar post sobre isso. Fora isso, quando se compra o Certificado tem a senha (PIN) e também tem a senha PUK que é justamente para quando esquecer a senha PIN, verifica com a empresa se ela não guardou os dados do certificado na época.

bom dia ======================= PROCEDURE ACBR_NFE_CARREGARXML(sRecebe_arquivo_ou_xml) // NFE_ CarregarXML( eArquivoOuXML ); gnretorno_acbr=API("ACBrNFe32.DLL","NFE_CarregarXML",StringToUTF8(sRecebe_arquivo_ou_xml)) IF gnretorno_acbr=0 THEN RESULT "Carregou Xml com Sucesso" ELSE RESULT "Erro Retorno :"+gnretorno_acbr END ==================== // btn NFE carregar xml bRETORNO is boolean=ACBR_INICIALIZAR() IF bRETORNO=True THEN EDT_RESPOSTA=ACBR_NFE_CARREGARXML(EDT_XML) END ACBR_FINALIZAR() ================================= https://windevdesenvolvimento.blogspot.com/2019/10/dicas-2385-windev-webdev-mobile-acbr.html bom dia https://acbr.sourceforge.io/ACBrLib/NFE_ImprimirPDF.html ======================= PROCEDURE ACBR_NFE_ImprimirPDF() // https://acbr.sourceforge.io/ACBrLib/NFE_ImprimirPDF.html // NFE_ ImprimirPDF gnretorno_acbr=API("ACBrNFe32.DLL","NFE_ImprimirPDF") IF gnretorno_acbr=0 THEN RESULT("Imprimiu com Sucesso") ELSE texto is string="Erro Retorno - "+gnretorno_acbr+" = " IF gnretorno_acbr=-1 THEN texto+=" Indica que a biblioteca não foi inicializada" IF gnretorno_acbr=-10 THEN texto+=" Indica que houve erro ao gerar o PDF do DANFe." RESULT texto END ================================= // btn NFE imprimir pdf bRetorno is boolean=ACBR_INICIALIZAR() IF bRetorno=True THEN EDT_RESPOSTA=ACBR_NFE_CARREGARXML(EDT_XML) EDT_RESPOSTA+=CR+ACBR_NFE_ImprimirPDF() ShellExecute("C:\ERPMATOS\xml_acbr\PDF\"+EDT_CHAVE_NFE+"-NFE.PDF") END ACBR_FINALIZAR() ================================= https://windevdesenvolvimento.blogspot.com/2019/10/dicas-2390-windev-webdev-mobile-acbr_17.html

Bom dia! Pessoal, realmente o ajuste conforme mencionei acima foi aprovado pelo Banco Safra, sendo assim gostaria de solicitar gentilmente aos Admin se é possível aplicarmos o ajuste no SVN. Grato.

Bom dia. Obrigada por informar. Para novas mudanças, note que temos um tópico exclusivo para estas situações. Att.

Bom dia, vc quer dizer a chave de acesso do(s) documento(s) referenciado(s) ? (Quando informados...) Se for isso, os componentes de impressão de DANFE (Fast ou Fortes) têm uma propriedade chamada "ExibeDadosDocReferenciados"... Att Ricardo

se for retorno do itau, tem que mudar a posicao onde colocam o tipo de pessoa, pois o acbr interpreta como está la e tenta validar um cpf, sendo que é cnpj que espera pelo numero que o itau muda: o que eu faço aqui se é um retorno de pessoa fisica do itau: var ArquivoDeRetorno : TStream; LS : TStrings; ArquivoDeRetorno := TMemoryStream.Create; LS := TStringList.Create; // CONTEUDO DO ARQUIVO LS.Text := TBlobField(IBDSPai.FieldByName('ARQUIVO_RETORNO_BOR')).AsString; P := LS.Count - 1; if (IBDSPai.FieldByName('RETORNO_PESSOA_FISICA_BOR').AsString = 'S') then MudarRetornoPosicao2_FisicaJuridica(LS); LS.SaveToStream(ArquivoDeRetorno); procedure TFCadBorderoBancario.MudarRetornoPosicao2_FisicaJuridica(var ARetornoLido: TStrings); var Linha: string; I : Integer; begin for I := 0 to ARetornoLido.Count - 1 do begin Linha := ARetornoLido; // Mexer nas linhas que correspondem a titulos apenas - iniciados com 1 if (Copy(Linha, 1, 1) = '1') and (Copy(Linha, 2, 2) = '02') then begin Delete(Linha, 2, 2); Insert('01', Linha, 2); ARetornoLido := Linha; end; end; end; testa ai, pode ser o seu problema também...

Conseguir, resolver usei outro opção de envio.

Ok José. Não ocorre com frequência. Vou alterar a propriedade só para emitir a nota. Obrigado pelas dicas. Grato, Josadac

Chegamos a marca de 3 webservices distintos para Blumenau, agora SimplISS já pode pedir música no Fantástico. Eu já tenho empresas usando os outros dois webservices(wsblumenau e migracao) e agora vou ter no terceiro(wsblumenau1), porque ainda tenho problemas em 3 clientes referentes a assinatura. ou seja, pessoal se não der certo a emissão em um, bola pra frente e colocamos para enviar no próximo. Desde que não tenha o 4 webservice já estamos de bom tamanho;

Boa tarde Juliana. Obrigado pelo retorno. Eu consegui a parte do retorno de forma funcional aqui, falta a questão a remessa em "empréstimo". E a partir de hoje estou trabalhando em produção com o componente modificado. Com mais alguns dias de teste trarei aqui minhas implementações. Att, Wellington.

Opa... obrigado... A liberação é feita de.forma automática, pelo PagSeguro... assim que ele acusa o recebimento ... Boleto pode demorar um pouco mais... se tiver muita pressa, por favor envie o comprovante para nosso financeiro

Já assinei a mensal.

Entendi Italo, Então eu vou assinar pois preciso da ultima versão do ESOCIAL, que já esta em homologação e que entra em produção em 11/11. Obrigada Italo.

Entendi, e esses restante? pode deixar desta forma?

Não... veja o tópico anterior... Se você usar WinHTTP não precisará configurar nada no I.E.

ACBrNFe1.NotasFiscais[0].NFe.Ide.dEmi := IncMinute(sysUtils.now, -1); Coloque DateUtils no uses.

Bom dia Juliomar, Realmente era a versão, conexão com oracle somente versão Enterprise e/ou Architect.

Bom dia, não houve alterações recentes quanto a isso, a questão de usar apenas o método Assinar é que deve desmarcar a opção citada acima: "Salvar Apenas NFes processadas na pasta NFe", para que o XML assinado possa ser gravado na pasta.

Boa tarde Adilson, Se a sua aplicação foi compilada para 32 bits, basicamente você precisa das DLLs: ...\DLLs\LibXml2\x86 ...\DLLs\OpenSSL\1.0.2.19\x86 Procure sempre copiar essas DLLs para dentro da pasta que se encontra o seu EXE.

Tive o mesmo problema e resolvi atualizando as DLLs que são utilizadas para comunicação com a Nota Fiscal Eletrônica. Utilizei as DLLs que estão em ...\ACBr\DLLs\LibXml2\x86

Aqui temos um verificador de updates rodando com o Windows em todas as máquinas e notificando caso encontre uma nova atualização. (não é necessário estar em todos os PC's. Mas como isso é instalado junto com o sistema e na prática não muda muita coisa. Deixamos assim) Quando o usuário clica para instalar a atualização em uma máquina qualquer, exibe uma janela com as melhorias, novidades, correções... Após o término do download do update, é gravado em um banco de dados especifico e temporário as informações do update, como: Nome, versão/build, data, novidades, MD5. Também gravamos o executável do InstallShield nesse banco (sim, gravamos um arquivo de mais de 700MB). Conforme print abaixo. Quando termina a instalação do update e o usuário inicia o sistema, os scripts necessários para o funcionamento da nova versão/build são rodados no SQL Server. (não precisa ser o servidor) Depois do banco de dados também estar atualizado, as demais máquinas "acusam" diferentes versões entre o executável e o banco de dados, possibilitando a atualização do sistema nesses outros computadores. Nesse momento ao invés de baixar o update novamente, acessamos o banco de dados temporário onde tem o arquivo já baixado e apenas instalamos. Quando o usuário abrir o sistema, os scripts não serão rodados pois já foram. Observação 01: Não importa se mais de um computador baixar a atualização ao mesmo tempo, antes de gravar o arquivo do InstallShield no banco, é verificado se ele já não existe. Observação 02: Os updates são controlados por CNPJ, UF... Já que as vezes é necessário uma correção imediata apenas no estado X. E ainda verificamos se o cliente está apto a receber o update já que o mesmo pode ter problemas financeiros, contrato de manutenção cancelado (não dando direitos a updates de versão, apenas build dentro da versão que o cliente adquiriu). Observação 03: Depois de todos os PC's atualizados, os dados da versão nova e o arquivo da versão são apagado desse banco de dados temporário. Observação 04: Existem atualizações criticas, nesse caso não fica a critério do usuário a instalação. O próprio atualizador, se encarrega de baixar e executar a instalação. Observação 05: Após o término da atualização no PC, solicitamos o registro da licença novamente para controlarmos qual é a versão que o cliente está utilizando. (de forma online e transparente já que as licenças são controladas por um HWID e não por um serial previamente cadastrado). Aqui controlamos por MD5. Ou seja, ao executar o sistema e algum arquivo (bpl, exe, dll..) não bater com o MD5 do executável. Não será possível executar o sistema.

Boa tarde Pessoal, Os documentos: CT-e - Conhecimento de Transporte Eletrônico e CT-e OS - Conhecimento de Transporte Eletrônico Outros Serviços, possuem um evento chamado: Prestação do Serviço em Desacordo. O autor desse evento, ou seja, que envia ele para a SEFAZ é o tomador do serviço. Esse evento, permite ao tomador informar ao Fisco que o CT-e/CT-e OS que o relaciona esta em desacordo com a prestação do serviço. O tomador tem um prazo máximo de 45 dias a contar da data de autorização do CT-e/CT-e OS para enviar o evento. Detalhe importante: O evento tem que ser enviado para a SEFAZ do emitente do CT-e, supondo que o emitente seja de São Paulo devemos: 1. Configurar o componente para a UF do Emitente (Configuracoes.webservices.UF := 'XX'; // onde XX é a UF do Emitente do CT-e) 2. Ao alimentar o componente informar em cOrgao a UF do Emitente do CT-e. Como montar a rotina para enviar o evento: ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.Add do begin infEvento.nSeqEvento := 1; // Para o Evento de Prestação do Serviço em Desacordo nSeqEvento sempre = 1 InfEvento.cOrgao := UFtoCUF(xUF); // Devemos informar a UF do Emitente do CT-e infEvento.chCTe := Copy(ACBrCTe1.Conhecimentos.Items[0].CTe.infCTe.Id, 4, 44); infEvento.CNPJ := xCNPJ; // CNPJ do Tomador infEvento.dhEvento := now; infEvento.tpEvento := tePrestDesacordo; infEvento.detEvento.xObs := trim(sOBS); // minimo 15, máximo 255 caracteres end; iLote := 1; // Numero do Lote do Evento ACBrCTe1.EnviarEvento(iLote); No exemplo acima o XML do CT-e/CT-e OS foi carregado, mas não se faz necessário, caso não deseja carregar o XML basta informar a chave (44 dígitos) ao campo chCTe. No campo xObs deve constar uma observação do tomador que justifique o desacordo do serviço prestado. Em caso de dúvidas, clique aqui para criar um novo tópico.