Pesquisar na Comunidade

Boa tarde. Estou tentando conciliar um CT-e emitido via EPEC, no ambiente de Homologação da Sefaz MT, só que sempre está retornando a rejeição a seguir: “402 - Rejeicao : XML da area de dados com codificacao diferente de UTF-8.” Já verifiquei o XML, inclusive no Validador de Mensagens do Projeto CT-e, e não acusa erro. - Ao tentar emitir um documento com os mesmos dados, mas forma de emissão 1 – Normal, é autorizado normalmente. - Ao tentar emitir um evento EPEC, o mesmo é criado normalmente. - Ao tentar conciliar o CT-e (com tpEmiss = 4) referente a EPEC anterior, sempre é retornada a rejeição 402. Entrei em contato com o atendimento da Sefaz MT, mas não responderam mais. Expliquei a situação, pedindo para verificarem também se poderia ser algo relacionado ao ambiente, conforme e-mail abaixo: Analisei até o código-fonte (\Fontes\ACBrDFe\ACBrCTe\ACBrCTe.pas linha 338 em diante) e não percebi nada diferente: // Passo 2 calcular o SHA-1 da string idCTe se o Tipo de Emissão for EPEC ou FSDA if TipoEmissao in [teDPEC, teFSDA] then begin // Tipo de Emissão em Contingência SSL.CarregarCertificadoSeNecessario; sign := SSL.CalcHash(idCTe, dgstSHA1, outBase64, True); Passo2 := '&sign=' + sign; sEntrada := sEntrada + Passo2; end; Result := urlUF + sEntrada; Em anexo XMLs: CT-e com emissão Normal: 51240706137422000190570010000000311680036048-cte-normal.xml Evento EPEC: 11011351240706137422000190570010000000254289813233001-procEventoCTe.xml CT-e com tipo de emissão EPEC: 51240706137422000190570010000000254289813233-cte-epec.xml Envio do lote: 25-env-lot.xml e 25-env-lot-decodado.xml Rejeição retornada: 25-pro-lot.xml Caso alguém tenha passado por essa situação e possa contribuir com algo, fico grato, mas acredito não ter algo a ver com o ACBr, já que utilizamos a emissão e conciliação de EPEC normalmente em ambiente de Produção, pelo menos até o momento.

Boa tarde. Realizando testes com a geração do arquivo do Livro Caixa do Produtor Rural (LCDPR), verifiquei que o componente não está gerando o arquivo com codificação UTF-8 conforme consta no manual do LCDPR no "Capítulo 2 – Dados Técnicos para Geração do Arquivo do LCDPR" página 4. Como no momento o componente não está utilizando a classe "TACBrTXTClass" pra geração da estrutura, eu fiz uma pequena e rápida alteração na unit "\Fontes\ACBrTXT\ACBrLCDPR\UACBrLCDPR.pas" para que o arquivo sempre seja gerado com codificação UTF-8. Obs.: Eu não vi a respeito, até porque o manual não fala nada sobre, mas caso seja necessário manter o BOM (Byte Order Marker) podem remover a linha adicionada no Create ou então passar o valor da propriedade WriteBOM para True. // Alteração no Create constructor TACBrLCDPR.Create(AOwner: TComponent); begin inherited; FBloco0000 := TRegistro0000.Create; FBloco0010 := TRegistro0010.Create; FBloco0030 := TRegistro0030.Create; FBloco0040 := TBlocos0040.Create; FBloco0050 := TBloco0050.Create; FBlocoQ := TBlocoQ.Create; FBloco9999 := TRegistro9999.Create; FDadosContador := TContador.Create; FConteudo := TStringList.Create; FConteudo.WriteBOM := False; // Salvar sem BOM FDelimitador := '|'; FArquivo := 'LCDPR'; end; //... // Alteração em SalvarBlocos procedure TACBrLCDPR.SalvarBlocos; begin FConteudo.SaveToFile(Path + Arquivo, TEncoding.UTF8); // Salvar com condificação UTF-8 end; Segue em anexo a unit "UACBrLCDPR.pas" com as alterações. Se puderem verificar para ser adicionado no svn, ok? Obrigado! UACBrLCDPR.pas

Bom dia, Estou usando o ACBrLCDPR fui validar o arquivo na Receita Federal para Transmissão e voltou com um erro: Pendencias_LCDPR_FULANO_01012019_31122019.txt-new.pdf

Pessoal, boa tarde. Acabei de baixar a última versão dos fontes do acbr do SVN. Depois de compilar tudo notei que alguns caracteres estavam vindo errados durante a comunicação do ACBrMonitorPlus, enviando o comando "teste" (que não existe) o retorno foi esse: teste ERRO: Comando inv�lido (teste) Note que o "á" está com um caracter errado. Foi quando resolvi pegar uma versão antiga dos fontes do ACBR que eu tinha em minha máquina e verifiquei que todos os arquivos em "Projetos\ACBrMonitorPLUS\Lazarus" estão em encoding UTF-8, já os demais fontes ainda continuam em ANSI, sendo que a versão antiga dos fontes que eu tinha guardada estavam todos em ANSI. O que mudou? Preciso configurar algo no lazarus para compilar corretamente?

Boa noite pessoal. Notei que o alguns acentos estão incorretos no ACBrMonitor, fiz a revisão num arquivo onde encontrei os erros e ajustei a acentuação que por algum motivo ficou desconfigurada devido alguma edição sem o formato UTF8. Tomei a liberdade de fazer alguns ajustes em outras palavras como por exemplo, número e último(a) que encontrei no fonte, anexo o arquivo que revisei a pouco. ACBrMonitor1.zip

Boa tarde. Estou tendo alguma dificuldade em relação a opção ANSI, não encontrei exatamente de qual versão, mas em algum momento não estava mais respondendo corretamente, utilizo a integração do Delphi com o AcbrMonitorPlus, e conforme orientações no fórum devo marcar a opção ANSI. Gerei o seguinte problema, criei uma pasta c:\sistemã e adicionei dentro desta pasta um xml, e solicitei a impressão do DANFE, o monitor retorna erro de arquivo não encontrado. Ex: "c:\Sistem�\...... não encontrado ". Somente apos alterar a função de "AnsiToUtf8" para "ACBrAnsiToUTF8" tive sucesso. Anexado o fonte com a alteração. ACBrMonitor1.pas

Boa tarde pessoal Hoje notei que o ACBrCEP, como o WebService ViaCEP não esta tratando a codificação UTF-8 e com isso retorna a string de bairro, cidade com caracteres ilegíveis. Como medida paliativa eu alterei a linha linha 1402 da unit ACBRCEP.pas de: Buffer := ParseText(fOwner.RespHTTP.Text); Dia 05/09/2016 14:47 - Weber de Paula para: Buffer := ParseText(fOwner.RespHTTP.Text, true, false); assim o tratamento ocorreu de forma correta. Se alguém tiver alguma outra sugestão eu agradeço. Obs.: Eu estava com o meu repositório SVN atualizado. Desde já obrigado.

Pessoal, boa tarde. Baixei e compilei todo o projeto do ACBr em Lazarus 1.6 Windows. Comecei a utilizar o modo de comunicação do ACBr Monitor Plus via TCP, para integrar minha aplicação feita em Java. Até o momento tudo corria bem, mas agora me deparei com um problema, que acredito ser gerado pelo Lazarus. Tenho uma impressora Bematech e uma Epson. Ambas tem formas de pagamento com acentuação já programas. Quando obtenho junto ao ACBrMontiorPlus as formas de pagamento (comando ECF.CarregaFormasPagamento) o contrato de retorno está sendo quebrado. Veja no seguinte exemplo de retorno: OK: 1 Dinheiro| 2V Cartão Formatando melhor o retorno para verificarmos a falta de caracteres: IIIITDDDDDDDDDDDDDDDDDDDDDDDDDDDDDD " 1 Dinheiro" " 2V Cartão" Note que na descrição cartão está faltando um caracter, são na verdade somente 29 posições (ao invés de 30) retornadas pelo ACBrMonitorPlus. Não estou conseguindo descobrir como resolver isso (até porque não tenho grandes conhecimentos em Lazarus), porém acredito que isso esteja ocorrendo pois a String é UTF-8, onde no caso a caracter ã é representado em 2 bytes em UTF-8, diferentemente que no ANSI aonde é 1 byte. Já tentei trocar aquele parâmetro no ACBrMonitor para usar comunicação ANSI mas o problema continua. Fiz a depuração do ACBrMonitorPlus, e o problema aparece no ACBrUtils.pas na função abaixo: function PadLeft(const AString : String; const nLen : Integer; const Caracter : Char) : String ; var Tam: Integer; begin Tam := Length(AString); <<< ESTE LENGTH('Cartão') retorna 7 ao invés de 6!!!! if Tam < nLen then Result := StringOfChar(Caracter, (nLen - Tam)) + AString else Result := LeftStr(AString, nLen) ; //RightStr(AString,nLen) ; end ; Alguém pode me ajudar a resolver isso? Obrigado!

Bom dia pessoal, Na empresa em que trabalho, não utilizamos delphi nem o lazarus em grandes projetos, utilizamos o delphi apenas para criar DLLs com algumas funcionalidades para integrar com os projetos que desenvolvemos em clarion. Pela questão da quantidade de licença do delphi que temos hoje na empresa resolvi migrar um dos nossos "projetinhos" do delphi XE4 para o Lazarus. O projeto em questão, se trata de uma dll que utilizo o componente AcbreSocial (que ainda está em desenvolvimento). Sempre que crio um função na DLL que será consumida por nossas aplicações desenvolvidas em clarion, e esta função irá receber um String por parâmetro, por questão de compatibilidade, sempre criei o tipo do parâmetro como "PAnsiChar", e posteriormente convertia para string, e sempre funcionou "bunitinho" no delphi. Porém ao migrar para o Lazarus, a principio, ocorreu tudo bem, o único problema é quando estou passado uma String(Clarion) que contém alguma acentuação, ao debugar a DLL, quando inspeciono o parâmetro, a letra acentuada está vindo como um ponto de interrogação "?", existe alguma configuração a se fazer no lazarus para que o tipo PAnsiChar se comporte da mesma forma que no Delphi XE4, ou se tenho que fazer alguma conversão diferente, pois hoje e unica conversão que faço é: var a: PAnsiChar; b: String; begin b := String(a); end; Obrigado.

Bom dia, Tenho uma aplicação em C# (WinForms com VS 2015 Community) e uso o Firebird 2.5.5 para armazenamento no banco. Para poder usar o ACBr, criei um módulo em Lazarus (versão 1.4.4) com o qual troco XMLs de requisição e respostas. O problema é que em campos varchar no meu banco de dados, no VS2015 (C#) está ok e no Lazarus não. Exemplo: JOÃO -> Visual Studio JO?O -> Lazarus Uso no lazarus o TIBConnection para conexão (aquele nativo que tem o iconezinho do firebird). Meu banco Firebird está com o Character Set definido como NONE. Devo fazer alguma alteração na base? É possível "corrigir" de forma simples no Lazarus (tenho preferência de mexer na base somente em ultimos casos). Obrigado, Marcos Gerene

Estou recebendo esse erro ao tentar validar uma NFCe para estado de são paulo Rejeicao: XML utiliza codificacao diferente de UTF-8 Segue anexo do arquivo xml que estou tentando transmitir NFe35150114396397000197650010000000011874781363.XML a nota passa pelo processo de validação, assinatura e recebe essa mensagem do webservice