EMBarbosa

Para remover código repetitivo, melhorar a orientação a objetos, tornar o código mais claro, facilitar a manutenção, corrigir limitações, etc... permitindo a correção de erros dos que estão atualmente usando o trunk sem que isso quebrasse a compatibilidade.

Até onde eu sei, a UF é do emitente... Mas é bom você conferir isso...

Acho que essa parte do código não foi muito bem testada. Seria melhor você testar...

Você não pode consultar e inserir no cadastro do seu cliente? Daí não precisaria ficar consultando a cada venda...

Olá, Estranho que não há nada no site do SPED sobre esse problema. Aguardei esses dias para ver se saía alguma coisa... mas pelo visto vai continuar assim e vamos ter que implementar de acordo com o PVA, mesmo sem ter uma confirmação por escrito.

O IDE Colorizer só funciona do XE2 pra frente se não me engano. O Theme Editor funciona pelo menos do Delphi 7 pra frente, além de Lazarus.

Creio que sim. Mas é necessário mais detalhes. Faça Instale usando o ACBrInstall. Reporte os erros encontrados.

6.3 - Mostre respeito pelo modo de escrever. Escreva de modo claro, gramaticalmente e semanticamente correto. Não escreva TUDO EM MAIÚSCULAS. Isso é lido como se estivesse gritando e é considerado rude.

Não existe o dpk "bdertl" pois no Delphi XE8 não existe mais o BDE. Arquivos dcp não são dlls que você copia de um computador para o outro e por isso você não deveria tentar copiar ele de outra versão do Delphi.

Um monte de gente... De modo geral, nós preferimos aqui no fórum manter uma abertura maior às empresas. Assim, cada um tem uma preferência pessoal e evitamos elevar uma empresa acima de outra. Claro que, se você procurar no fórum, vai ver quais empresas estão sendo de ajuda, quais estão dando mais problemas, etc...

O problema está na PadR. Ele está truncando o parâmetro passado saltando o primeiro caracter. Estou alterando para PadL para corrigir. Os testes unitários passaram sem nenhum problema. Vou tentar compatibilizar os testes unitários tanto do trunk como o trunk2 só para facilitar o acompanhamento.

Google? Achei um post no ForumWeb em que eu mesmo respondi essa pergunta: http://www.forumweb.com.br/foruns/topic/83578-resolvido-bad-file-format/

Que pasta X?

Verifique se há espaço suficiente no HD utilizado. Verifique se há espaço nas pastas temporárias. Verifique se existem muitos arquivos nas pastas temporárias. Verifique permissões das pastas utilizadas pelo programa.

Você rodou o ApagarACBr.bat em todos os drives de seu computador? Tente rodar como administrador...

Eu posso estar enganado, pois preciso reler o código, mas acredito que esse evento ocorra como último passo antes de enviar a requisição. Assim, nenhuma alteração será feita após isso... Mas isso é o que eu lembro do código, como tem um bom tempo que estou sem mexer no TEF, o melhor é você testar mesmo...

Cleber, o que é enviado nestas tags adicionais só é enviado se você preencher manualmente conforme o Daniel falou. Faz o teste, leia o fonte... não é tão complicado quanto parece...

Testei no Trunk2, mas o problema só se encontra realmente no trunk.

Troque pela classe Exception correta...

Eu entendi, por isso que coloquei o último link e também escrevi:

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?