Igor Bastos

Isso resolveu o problema. Apesar de tudo aqui é 64 (win e projeto), tive que realmente jogar TDS DLLs 32

Sim. Segue anexo como estou deixando na hora da instalação. Primeiro sem o LibXX marcado e depois com o LibXX marcado. (ao copiar tds os Library Paths do Win32 para Win64 deu certo a compilação, mas ainda estou tendo os erros de "Can't load package")

Boa noite, fiz pesquisa no Fórum para procurar e não trouxe resultados, pesquisei no Google e o tópico existente sobre o assunto não ajudou. Estou tentando instalar o ACBr SVN versão 18095 no RadStudio Rio 10.3.2 CE, tentei com LibXX desmarcado primeiro e depois com LibXX marcado, ambos sem sucesso. Estou instalando todos os componentes menos os Report (Fast e Fortes, não serão necessários nesse momento). Além de não conseguir fazer funcionar em 64bits, sempre que inicia o Delphi ou um projeto fica falando que vários componentes não foram carregados (segue anexo apenas 1 exemplo, pois são vários e vários outros)

Refiz os testes e acho que deu certo: desmarcando o LibXX só tive que adicionar no Win64 TDs as PAS que foram para o Win32, daí rodou sem erro. Obrigado.

Infelizmente não deu certo. Desmarquei a LibXX, marquei para remover os arquivos já instalados, terminou de instalar sem erros. Roda de boa no Win32, mas no Win64 avisa que falta os PAS. Como eu disse, infelizmente não aparece a opção para escolher a plataforma (vide imagem do primeiro post)

Desculpe, mas eu não sei onde deixar selecionado Win32, visto que não tem nenhum lugar para selecionar a plataforma (32 ou 64), vide imagem que postei. Mas irei instalar com LibXX desmarcada e aviso.

Gostaria de saber como compilar o ACBr para compilar em 64 bits. Segue como aparece na minha instalação. Não sei onde estou errando, mas msm ao adicionar o path na Library para 64 bits ainda dá falha ao achar o PAS. Meu Library para 32 bits está praticamente igual, mas só dá erro no 64.

Segue impressão de Teste, é alguma configuração, talvez?!

Boa tarde, estou tentando imprimir em uma impressora não fiscal PertoPrint 4000 mas a impressão saí td desconfigurada. Para ser mais exato, ela saí como se fosse sequencial, sem formatação e sem o QRCode. Na Elgin i7 imprime normalmente.

Era o serviço 'Spooler de Impressão' mesmo. Obrigado a todos

Erro está aparecendo ao tentar imprimir NFC-e com o ACBrDanfeFortesFe, apenas na máquina de desenvolvimento. Aparentemente os clientes estão OK. Erro: System Erro. Code: 1722. O servidor RPC não está disponível Disparado em: ACBrDANFCeFortesFr.pas Linha 1327 frACBrNFeDANFCeFortesFr := TACBrNFeDANFCeFortesFr.Create(Self); Erro acontece especificamente em Vcl.Forms Linha 3642 if not InitInheritedComponent(Self, TForm) then Como solucionar? (precisamos realizar testes e não estamos conseguindo) Trunk atualizado hj 07/09/2018. (pensei que poderia ser falta de atualização, atualizamos e a falha continua)

Apesar de eu ter desistido de fazer a contingência funcionar (não era função prioritária), pelo que entendi na época que li era que ao enviar em Contingência e o SEFAZ estiver disponível, a NFe será transmitida normalmente. Alguém com mais experiência poderia confirmar ou negar isso, por favor?!

Minhão opinião de Solução Viável!

@simons na época trabalhei em cima desse XLS (que no meu ponto de vista não ajudou muito), demorei horas de análise do XLS e testes até chegar em uma solução viável. Apesar de eu achar que seria interessante ter essa função no fontes, entendo a dificuldade de implementá-la, visto que é uma tabela externa (pelo que entendi de utilização e atualização mundial) e pode ser atualizada constantemente. Imagina a dificuldade para os desenvolvedores manterem ela atualizada o tempo todo para suprir nossas necessidades?! O custo/benefício não vale a pena. @Riquena, se quiser eu posto minha solução, mas ficou bem simples mesmo.

Acabei de atualizar os arquivos aqui e o arquivo que veio ACBrCEP.pas está com a V2... Pode ser que alguém já tenha atualizado p V3 mas não disponibilizaram ainda.

Uhm... na realidade não notei isso não, qual parte do código é da api V2? Estou utlizando o URL da V3 (http://www.cepaberto.com/api/v3/), e fazendo a chamada de CEP para a V3 (cep?cep). OBS: eu não alterei a BuscarPorLogradouro.

Segue anexo arquivo corrigido. Por favor, analise e me dê o feedback. ACBrCEP.pas

Farei isso e posto aqui.

Qual a versão mínima de compatibilidade para ser incorporado? Eu posso fazer funções bem específicas para validar o retorno do GET? Por exemplo: o retorno do GET é uma String no formato JSON, eu poderia sair lendo a string e procurando os campos com Copy, Pos, LeftStr, etc... Posso implementar desse jeito? Aí ficaria compatível com qualquer versão.

Segue .pas com as alterações para Nova API do CEP Aberto. Fiz vários testes e ficou certo. Qualquer detalhe, me avisem que corrijo. ACBrCEP.pas

Olá, estou realizando atualizações no código do ACBrCEP (ainda estou testando, mas qnd terminar gostaria de enviar para ser analisado), mas meu problema agora é: como carregar as alterações sem precisar reinstalar o ACBr? Pois estou fazendo alterações no código e td vez para testar tenho que reinstalar td ACBr, tem alguma forma de recompilar só o ACBrCEP.pas? Desde já agradeço.

Estou atualizando o fontes do CEP Aberto, jaja encaminho para análise.

Solução que desenvolvi: Fiz uma função de validação do Prefixo GTIN (baseado na Tabela de Prefixos da GS1 e nesse link), coloquei o retorno como Aviso, ou seja, não impedirá de transmitir a NFe e permitirá que o usuário escolha entre não transmitir para corrigir ou transmitir com os Avisos. Nos casos em que realmente não são validados localmente (por exemplo se retornar erro no ACBr.ValidarGTIN), retorna erro real e impede de transmitir. Se o usuário decidir transmitir msm com os Avisos, pode ser que retorne os erros da SEFAZ, daí é com o usuário trabalhar nas alterações manuais dos EANs.

Fiz uma validação local baseada no arquivo disponibilizado pela GS1, mas existe uns Códigos que não foram validados, por exemplo: 382904918019. Mas na SEFAZ ele passa normalmente. Acontece que eu achei este link http://www.codigodebarras.net.br/varios/codigo_de_barras_ean13.htm com a informação de que o prefixo 382 está sendo implantado. Na minha opinião aconteceu assim: o GS1 está implantando os prefixos mas não atualizou o arquivo, mas a SEFAZ já atualizou a validação dos GTIN com os códigos a implantar. Isso é baseado na situação de que o prefixo é inválido baseado no arquivo mas a SEFAZ aceita ele normalmente. Como solucionar a situação? Já que, aparentemente, a SEFAZ vai sempre estar "atualizada" e a validação local não poderia impedir a transmissão, já que a SEFAZ aceita o GTIN

Em análise mais específica identifiquei que são estes EANs com falha: http://textuploader.com/dfue7 Aparentemente a verificação é a mais simples possível: se o DV estiver correto, verifica os três primeiros números com a tabela de prefixo GS1. Fiz testes deixando os inválidos como "SEM GTIN" e a NF passou normalmente. É possível adicionarem essa solução no ACBr ValidarGTIN?