EMBarbosa

Lendo o manual do equipamento e lendo os arquivos fontes do ACBrETQ para ver se as funções estão implementadas concordemente.

No trunk eu sei que está com problemas. Mas vou enviar os testes para o trunk2 também e verificar. Pois é... como eu disse antes, não consegui descobrir desde quando começou a acontecer esse problema. Só sei que está funcionando no ACBrValidador e não na ACBrUtil.EAN13Valido.

Você já configurou sua conta no gmail para poder ser enviado emails assim? Veja essa sugestão: Claro que o acima é sobre drupal e está especificamente falando sobre o envio pelo SMTP do gmail, mas pode ser alguma coisa nessas configurações... Outros pontos a serem analisados: - na ajuda do gmail aqui. - explicação da configuração SMTP do gmail - explicação do amazon SES para referência

Enquanto estava analisando um problema nos meus clientes, descobri que a validação EAN13 da unit ACBrUtil.pas (método EAN13Valido) não está correta. Ela é chamada pelo componente ACBrInStore. Não consegui descobrir desde quando isso vem ocorrendo, mas me parece que é recente. Códigos como 7896232517828, 7896645900026, 7897186015095 e 2000100002629, estão sendo acusados como inválidos. No entanto, eles são válidos conforme pode-se testar em http://www.gs1.org/check-digit-calculator. No entanto, o ACBrValidador está funcionando corretamente. Adicionei testes unitários para esse método exemplificar e facilitar a correção. Daí percebi que o que acontece é que ao passar para o método ACBrUtil.EAN13_DV um valor com 13 caracteres, ele trunca de forma incorreta e calcula o dígito validador errado. Mas se você passa 12 caracteres, ele vai fazer da forma certa. É como se o PadR estivesse trocado por um PadL... Temos algumas opções então para corrigir: 1) Trocar o código na função ACBrUtils.EAN13_DV utilizando um PadL: function EAN13_DV(CodEAN13: String): String; Var A,DV : Integer ; begin Result := '' ; CodEAN13 := String( PadL(AnsiString(Trim(String(CodEAN13))),12,'0') ) ; if not StrIsNumber( AnsiString( CodEAN13 ) ) then exit ; DV := 0; For A := 12 downto 1 do DV := DV + (StrToInt( CodEAN13[A] ) * IfThen(odd(A),1,3)); DV := (Ceil( DV / 10 ) * 10) - DV ; Result := IntToStr( DV ); end; 2) Trocar o método EAN13Valido pelo método na unit ACBrValidador (ACBrValidadorValidarGTIN) Como não sei onde esse método é utilizado, fiquei pensando, será que não seria uma boa ideia passar a utilizar os métodos do ACBrValidador aproveitando para reduzir a redundância de código?

Talvez seja necessário alguma configuração diferente de porta ou outra coisa, Além disso, se eu entendi bem, você está utilizando a Amazon para enviar e-mails pelo gmail. Isso significa que podem ser necessárias outras configurações no gmail para habilitar essa funcionalidade. Eu lembro de ter lido sobre isso, mas como não utilizei ainda, não guardei de cabeça. Eu começaria a pesquisar por aí...

Debug o programa de exemplo e verifique qual a linha exata do código do componente em que acontece o erro. Anexe aqui essa informação além dos logs, a mensagem completa do erro, e quaisquer outras informações que julgar necessárias.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]".

Você consegue reproduzir o problema com o exemplo.

Acrescentando: Para colorir o código do Delphi/Lazarus/AppMethod: https://github.com/RRUZ/delphi-ide-theme-editor/ Para colorir a IDE do Delphi: https://github.com/RRUZ/Delphi-IDE-Colorizer

Por favor, use apenas a área de Classificados para fazer oferta ou procura de serviços e produtos.

https://pt.wikipedia.org/wiki/Lista_de_c%C3%B3digos_de_status_HTTP#5xx_outros_erros

Olá doidopb, A primeira vista os seus cálculos estão corretos para o exemplo citado. Mas o que você procura é orientação fiscal e tributária. Neste caso, ninguém melhor que um contador de confiança para lhe orientar.

Olá Alessandro, Com respeito a validade da sua homologação anterior, se você entrar no programa, você verá o estado atual dela. Na verdade, é possível ver todas as versões do seu PAF-ECF cadastradas. Acredito que você já tenha lido os tópicos relacionados existentes no fórum e a Portaria SRE 132... Então, qual parte da legislação citada você está em dúvidas em entender?

Não adianta... na verdade vira e mexe o GBPSV.EXE vai considerar um executável como falso positivo e vai fechá-lo. As vezes basta você mover uma linha de lugar para outro e muda a situação. Pois a detecção é heurística.

Lendo os dois e comparando um com o outro.

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]".

Outro repetido?

O problema não é do ACBr. O problema é do GBPSV.EXE.

Post duplicado

2.2 - Permaneça no assunto - Quando tiver uma dúvida diferente do assunto no tópico, poste em novo tópico. Não use algo equivalente a "aproveitando o gancho... [dúvida não relacionada com o tópico aqui]".

Os testes de DAV e pré-venda são feitos se seu PDV implementar DAV e/ou pré-venda.

Não dá pra falar muito sem ver o arquivo completo ou o primeiro erro que aparece... Mas, você viu o erro que está acusando que o indicador de estorno está errado e o outro que a linha 42 deveria ter 112 caracteres mas só tem 109? Corrija esses erros primeiro.

Enviado na revisão 9245. Favor testar.

Não deu pra entender. COO não tem casas decimais. Mas seu arquivo está com problemas de estrutura. Veja que o validador está mostrando outros erros antes da linha que está marcada como atual. Eu sugiro que corrija os erros na ordem que ele relatar primeiro. Isso normalmente facilita.

Isso muito provavelmente é um bug conhecido do Delphi 2010. Foi reportado no QC 23580. Se for esse problema mesmo, a boa notícia é que instalando o Delphi IDE Fix Pack isso é corrigido.