Alberto Scolnik

Tentei pesquisar sem sucesso. Em algum comentário que não consegui reencontrar parece precisa gravar algum número. Pelo log parece a comunicação está funcionando. Parece o problema está na consulta somente mas não consegui entender se consigo ver se houve o registro no Banco Inter. A documentação deles achei bastante fraca e por telefone não dão nenhum suporte. Já estou tentando entender há mais de 2 semanas e por isso pedi ajuda.

Estamos testando o ACBRboleta para o Banco Inter no ambiente SandBox. Após clicar em "inclui Boleto" , "Gera Remessa" e "Consulta" não retorna nenhum valor e aparece o erro 500. Anexo o log gerado pelo programa após clicar nestes 3 botões acima. Alguma dica? log

Consegui resolver limpando e reinstalando os componentes ACBR.

Apesar da unit pcesConversaoeSocial estar com a nova versão incluída conforme linha abaixo do TVersaoeSocial o programa que seta a configuração não enxerga esta 7 opção para ser setada que é a veS01_03_00 para ser usada à partir de 01/01/2025. (TVersaoeSocial = (ve02_04_01, ve02_04_02, ve02_05_00, veS01_00_00, veS01_01_00, veS01_02_00, veS01_03_00);) -Abaixo também o código do programa de configuração onde ele preenche as opções e versão disponíveis cbVersaoDF.Items.Clear; for K := Low(TVersaoeSocial) to High(TVersaoeSocial) do cbVersaoDF.Items.Add( GetEnumName(TypeInfo(TVersaoeSocial), integer(K) ) ); cbVersaoDF.ItemIndex := 0; Ao compilar o programa exemplo do Acbresocial ela dá um erro não reconhecendo a variável veS01_03_00 na linha abaixo if (VersaoDFx > veS01_00_00) and (VersaoDFx < veS01_03_00) then Alguém está com o mesmo problema Alberto Scolnik

Poderia explicar como fazer isto no Componente? Na definição do campo A170 Aliquota Pis e Aliquota Cofins na unit ACBrEPCBloco_A_Class está com formatação para 4 decimais apesar de na observação do campo o formato ser N 2 conforme definido no manual. Alterei a formatação de 4 para 2 mas ao rodar o programa ficou com as 4 decimais. Poderia orientar à respeito. Alberto Scolnik

Caros, Atualizei a versão documento fiscal para veS01_02_00 e coloquei no componente a TAG identarXML para false e "FUNCIONOU". Algumas observações: -Colocando a versão S_01_01_00 e TAG identarXML false ao enviar o evento volta o erro 403 (layout do evento inválido) -Colocando a versão S_01_01_00 ou S_01_02_00 e TAG identarXML true ao enviar volta o erro 142 (assinatura inválida) -Acredito na atualização do componente para versão S_01_02_00 o código tenha gerado esta inconsistência. O programa parou de funcionar por volta de 15/12/2023 quando talvez tenhamos atualizado o componente. Acho vocês deveriam verificar esta inconsistência pois acredito outros usuários devem estar com problemas. Só não entendo como ninguém mais está reportando o erro.

O e-social ainda não respondeu minha solicitação. Buscando uma solução para o problema dentro do Forum ACBR encontrei em 09/02/2023 onde o usuário ismaelspaniol reportou o erro 142 (assinatura inválida) e ele colocou a Tag identarXML como false e funcionou. Fiz este teste e recebo o erro 403 (layout inválido) usando a Tag identarXML como False. A TAG identarXML deve ficar como true ou False?

Enviei nova mensagem para o e-social em 31/01/2024. Ainda não me responderam.

Obrigado Renato pela informação mas não funcionou, As configurações estavam exatamente como as indicações no post acima. Apenas o timeout estava com 5000. Aumentei para 20000 depois 30000... "continua o mesmo erro". Note que o componente do Acbr ao assinar já faz a verificação da assinatura. Não faz nenhum sentido para mim o erro que está dando de assinatura inválida. Procurando na internet li que a base de dados do e-social pode dar problema e necessita algum ajuste por parte deles. Como em Dez/2023 tive um evento que ficou incompleto e o serviço estava muito lento acredito possa ter alguma ligação. Você consegue avaliar a tag de assinatura do arquivo que anexei e confirmar que está correta? Já passou por este problema por erro dos servidores do e-social?

Obrigado Renato,

Enviei estas informações para o suporte do e-social e informaram que a assinatura está inválida. Alguém poderia esclarecer se o XML mostra algum erro na tag assinatura? Analisei a TAG utilizando o notepad++ para verificar algum caracter indevido não encontrando qualquer erro.

Uso o componente do e-social Acbr para fazer todo o processo. Desde meados de dez/2023 todos eventos que envia recebo a msg de transmitido com sucesso mas nenhum processamento é feito no e-social. Consultei o protocolo de envio e recebi retorno de Erro 405 Ocorrencia 142 : "Assinatura do evento inválida. Verificar se houve alteração do evento após a assinatura. Verificar a validade da assinatura". Em anexo um exemplo do envio do evento S1200 e o retorno da consulta. 20240124104118-sit.xml 1547702190000002024012410410120953-S-1200-0.xml

No mês passado modificamos a estrutura dos campos do Infopgto para adapta-la a nova forma exigida pela versão S_01. Neste Mês o programa parece estar gerando o XML errado. Dá mensagem de ausência do Infopgto, dando erro de verificação com o Schema. Não grava o XML gerado em nenhum lugar para que pudesse entender como está sendo gerado.

Fiz a re-instalação há cerca 1 mês atrás limpando todo ACBr e rodando o ACBrInstall_Trunk2.exe. o instalador adicionou as seguintes Paths relacionadas ao GZ: C:\SistemaSectorD7\PGMLinuxIB\source_delphiXE\ACBR_Trunk2\Fontes\Terceiros\ZLibExGZ\zlib C:\SistemaSectorD7\PGMLinuxIB\source_delphiXE\ACBR_Trunk2\Fontes\Terceiros\ZLibExGZ\win64 C:\SistemaSectorD7\PGMLinuxIB\source_delphiXE\ACBR_Trunk2\Fontes\Terceiros\ZLibExGZ\win32 C:\SistemaSectorD7\PGMLinuxIB\source_delphiXE\ACBR_Trunk2\Fontes\Terceiros\ZLibExGZ Fiz o teste adicionando o GZIPUtils no path como vc sugeriu , baixei a versão original do ACBr.ini e compilou o programa sem erros Ficam as dúvidas:. 1) Se ao ter que limpar a instalação do ACBr e reinstala-la o ACBrInstall_Trunk2.exe criará este path do GZIPUtils automaticamente; Agradeço pela ajuda. Resolveu meu problema.

Estou na versão do DelphiXE5. Não entendo que ajuste foi feito no ACBR.inc pois sem tirar o "." da diretiva {.$DEFINE USE_ZLibExGZ} a compilação reclama da falta GZIPUtils. Também não consegui encontra a UnitTeste de ACBrComum. Poderia esclarecer se será necessário recompilar e/ou reinstalar para funcionar sem alteração no fonte?

Andre, Uma última questão: Após rodar o GeraNFe executa-se o Acbrnf1.enviar .. No comando enviar não é gerado o mesmo xml e de depois o .pdf? Neste caso o campo não estaria filtrado? Posso modificar meu programa e depois do GerarNFe executar o gravarxml, limpar o ACBRNF , fazer loadfromfile e depois executar o enviar?

Note que o xml está sendo gerado corretamente o que parece demonstrar que não existem caracteres indevidos na base de dados. Na base de dados não visualizei nenhum caracter especial para quebra de linha. Abaixo a informação colhida deste campo na base de dados através do IBExpert: LOCAL DE ENTREGA:RUA DOUTOR MAURO PAES DE ALMEIDA,601-SOCORRO,PROCURAR POR JHONATAN OU ESLEI Nosso Contrato Locação N.10809 /Anexo:1 /T.Entrega:32527 "Não incidência de ICMS cfe.art.7º, inciso IX - DL.45.490 DE 30/11/00." Continuo entendendo que o problema esta ligado a forma como a variavel InfCpl está sendo setada e o comportamento do Fortes Report que parece não estar respeitando o tamanho de cada linha. Gostaria de entender porque o Fortes Report não se perde quando o arquivo é carregado via loadfromfile?

O ACBR está atualizadíssimo. Acho que o problema possa estar relacionado a como o Fortes Report/ Componente ACBR recebe a informação deste campo. Preencho na rotina GerarNFe setando infCpl := campo Blob da base de dados em firebird. Este campo na base de dados é tip Blob size: 80 Type Text. O comando acbrnfe1.enviar faz o resto. Quando re-imprimo a DANFE o programa faz um loadfromfile do arquivo xml criado e a DANFE é impressa corretamente. Entendo que o campo InfCpl é preenchido diferente nos 2 casos e de alguma maneira o campo Blob faz o Fortes perder tabulação ( o Rave não fazia isto ) com quebra de linha em alguns espaços em branco. Tem algum sentido para você as diferenças acima?

Em anexo arquivo xml da DANFE conforme solicitado. 35160854770219000280550000000032541214023875-NFe.xml

Estou utilizando a nova versao ACBR Trunk2 no ambiente DelphiXE5, Windows 7 64bits e Fortes Report. 1) Ao criar e enviar uma DANFE pelos comandos ACBrNFe1.NotasFiscais.GerarNFe; ACBrNFe1.Enviar(vNumLote,True); o arquivo DANFE em pdf aparece com campo Informações Adicionais quebrando linha em alguns espaços em branco ( além de quebrar corretamente onde tem o ponto e virgula) antes de completar o espaço de cada linha. Não encontrei no campo nenhum caracter que pudesse estar provocando a quebra. Abaixo como fica o campo Informações Adicionais quebrando erradamente em alguns espaços em branco ( linha 4 e linha 7 ): SOLICITADO E APROVADO POR ROMEO DURANTE ENTREGA:DIA26/08/2016 RETIRADA:DIA 02/09/2016 Nosso Contrato Locação N. 10808 / Anexo: 1 / T.Entrega: 32526 "Não incidência de ICMS cfe.art.7º, inciso IX - DL.45.490 DE 30/11/00." 2) Quando utilizo o xml gerado para enviar e-mailda DANFE pelos comandos ACBrNFe1.NotasFiscais.LoadFromFile(nomearquivo); ACBrNFe1.NotasFiscais.Items[0].EnviarEmail(... o campo informações adicionais quebra corretamente no limite do campo ou quando tem o ponto e vírgula. Abaixo o campo Informações Adicionais com as quebras corretas: Notem que a 3ª linha o espaço entre a palavra DIA e 02/09/2016 provocou quebra de linha no 1ª emissão, assim como, na linha 5, o espaço após a palavra Não também provocou quebra de linha na 1ª emissão. SOLICITADO E APROVADO POR ROMEO DURANTE ENTREGA:DIA26/08/2016 RETIRADA:DIA 02/09/2016 Nosso Contrato Locacao N. 10808 / Anexo: 1 / T.Entrega: 32526 "Nao incidencia de ICMS cfe.art.7 , inciso IX - DL.45.490 DE 30/11/00." Alguém pode me dar uma direção de como entender o que está acontecendo?

Fiz os testes no ambiente Windows 7 / Delphi XE5 - Tanto a versão do ACBRNFe.demo 2015 como a do trunk2 retornam o Status do Serviço de forma correta sem nenhum erro de compilação no código. No ambiente Windows XP / Delphi 7 o programa dá erro de compilação na função ReplaceStr no comando copy informado : 'Erro missing operator or semicolon' e 'Imcompatible types "string" and "inflate-code-mode". Comentando estas linhas ( retirando a função copy ) foi quando provoquei o erro do SOAP. Poderia me posicionar se realmente a versão atual do trunk2 não rodará no XP com Delphi7?

Vou testar com o Demo sem fazer nenhuma alteração no código. Acho pouco provável que seja erro no código pois as linhas no botão do Demo para fazer-se a consulta do Status são idênticas no meu programa e no Demo. Acredito que problema esteja no meu ambiente ( windows XP e Delphi 7 ) com a nova versão do ACBR. Vou testar também no ambiente W7 e Delohi XE5 ( ambiente que estou migrando ).

Feita a migração e correção dos códigos Delphi7 para nova versão do acbr baixada do trunc2. Compilação do programa sem eero. Ao executar o programa para verificar o Status do Serviço do Sefaz ocorre seguinte erro: Esoaphttpexception with message A area de dados transferida para chamada do sistema e muito pequena

Não estou conseguindo instalar os componentes ACBRNFeDanfeQRpkg, ACBRNFSeDanfeQRpkg e ACBR_Boleto_FC_Quick. Estou usando Windows 7 64bits, QuickReport 32 ou 64 versão 5.06 e Delphi XE5. Aparece erro na compilação informando a falta de QR5RunDXE5. Ocorre que na versão 5.06 o nome deste arquivo é QR506RunDXE5 (win32) e QR506RunDXE5W64 (win64). Tentei recompilar os pacotes ACBRNFeDanfeQRpkg, ACBRNFSeDanfeQRpkg e ACBR_Boleto_FC_Quick mas no DelphiXE5 abre informado erro nas clausulas Requires. Alguém já passou por este problema?

Adicione a unit QRPDFFilt a user do ACBRboletoFCQuickFr. Descomente tudo da procedure TACBrBoletoFCQuick mantendo apenas a exclusão da linha ref, HTMLfilter. Dê um nome com final .pdf ao seu arquivo na propriedade do componente ACBrBoletoFCQuick.NomeArquivo. Fiz estas alterações e funcionou corretamente com o boleto (arquivo pdf) atachado ao e-mail.