Painel de líderes

Olá pessoal, Acabei de enviar para o SVN, modificações para que o ACBrDFe e ACBrDFeOpenSSL suportem comunicação segura usando TLS 1.2 O componente ACBrNFe, já irá tentar ajustar a comunicação para TLS 1.2, se detectar que a versão é superior a 3.1 Atualizando o OpenSSL Para usar TLS 1.2, é necessário ter a versão do OpenSSL superior a 1.0.1, normalmente a versão usada é a 0.9.8.14, e portanto ela precisa ser substituída. Se você tentar utilizar uma versão inferior, o ACBrDFeOpenSSL acusará o seguinte erro: Porém não basta apenas baixar e copiar uma nova versão das DLLs do OpenSSL (libeay32.dll e ssleay32.dll). O problema, é que a libxmlsec, que se encontra na pasta: "ACBr\DLLs\XMLSec", não é compatível com OpenSSL superior a 0.9.8... e se você simplesmente atualizar as Libs do OpenSSL no seu sistema, provavelmente o ACBrNFe, passará a acusar Exceptions no momento de assinar o XML A solução, é utilizar um novo conjunto de DLLs, da OpenSSL e libXmlSec, libXML, e demais... você pode achar essas DLLs em: ftp://ftp.zlatkovic.com/libxml/ Essas DLLs foram compiladas com "MinGW", e portanto elas precisarão das DLLs de RunTime, da MinGW. Para sua conveniência, copiamos todas as DLLs necessárias para a pasta: \ACBr\\DLLs\XMLSec\MinGW. Observe que temos a versão 32 e 64 bits dessas DLLs... quais eu devo usar ? Em resumo, use 32 se o seu Compilador é 32 bits, e 64 apenas se você estiver usando um Compilador que gere .EXE em 64 bits... Leia esse tópico, para compreender melhor: Copie TODAS as DLLs (e não somente algumas) da pasta "\ACBr\DLLs\XMLSec\MinGW\32" ou "\ACBr\trunk2\DLLs\XMLSec\MinGW\64" (conforme o seu compilador), para o seu diretório de DLLs... (se não tem certeza para onde você deve copiar as DLLS, leia com atenção o Post indicado anteriormente) Outro problema, é que a MinGW, gera as DLLs com uma nomenclatura ligeiramente diferente do VisualC, exemplo: libxmlsec1.dll com MinGW, e "libxmlsec.dll" com VisualC. Portanto, o ACBr teria dificuldades em encontrar essas DLLs e carrega-las de forma dinâmica. Precisamos portanto, informar ao ACBr, que usaremos o conjunto de DLLs no formato da MinGW... Isso é feito, editando o arquivo: ACBr.inc. Repare que lá no final do ACBr.inc, temos a seguinte linha: {.$DEFINE USE_MINGW} Apenas remova o ".", alterando para: {$DEFINE USE_MINGW} Pronto... com isso você estará pronto para usar o ACBr com OpenSSL e TLS 1.2, seja em 32 ou 64 bits... Obrigado... e considere nos ajudar, contratando o SAC ocasionalmente: http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/

Quero ver como o sefaz vai resolver esse problema. Pois mesmo o arquivo sendo zipado o tamanho vai ficar grande. Enviar isso pelo webservice vai dar timeout. Tente testar com a maior base de cliente seu para ter certeza que vai funcionar, valeu.

Olá, Correção disponível no SVN, Rev: 12944 (Obs: O SVN do S.F. voltou a funcionar normalmente)

SIm, é que importo no meu sistema de outros sistemas o TXT, não é gerado por mim.. mas vou tentar entrar em contato com o desenvolvedor do software que gera o arquivo para uma possível solução na hora de gerar o arquivo

Bom dia Minha opinião é que NFCe melhorou em muito em relação a ECF. Tenho vários clientes, com as mais diversas estruturas e todas funcionam perfeitamente. A contingênica OFF LINE contorna qualquer problema de conexão ou erro de cadastro. Quanto a impressora, uso de diversas marcas. Na minha opinião, a que melhor funciona é justamente a EPSON. Expecificamente no caso da EPSON, tem um detalhe que pode fazer toda a diferença. Existe uma parâmetro para configurar o SB da Impressora (Modo Pinter ou modo Vendor) De fábrica a impressora vem como modo Printer. No meu caso, não uso o Driver Spooler para impressão, uso a DLL do fabricante para imprimir. Sendo assim, tenho que configurar a impressora para modo Vendor e instalar o Driver USB da Impressora, sem o driver Spooler. Dessa forma funciona que é uma beleza. Não lembro de ter suporte sobre problemas de conexão com a EPSON utilizando dessa forma.

@Ricardo Miquinioty e @Juliomar Marchetti Ricardo o edit do MS-Dos deve considerar esse caracter uma quebra de linha, abri o arquivo no Notepad++ apaguei a linha extra que ele mostrava lá, e o arquivo importou normalmente. O Ideal agora seria eu conseguir verificar no delphi antes mesmo de importar se existe essa linha em branco para remove-la antes da importação, mas muito obrigado pela ajuda, Problema resolvido! Segue a imagem no Notepad++

Eu simulei aqui as duas situações... veja se ajuda: 1a. <prod> <cProd>1</cProd> <cEAN/> <xProd>CAFE PCT (UNIDADE)</xProd> <NCM>21011110</NCM> <CFOP>5102</CFOP> <uCom>UN</uCom> <qCom>10.0000</qCom> <vUnCom>3.5000000000</vUnCom> <vProd>35.00</vProd> <cEANTrib/> <uTrib>UN</uTrib> <qTrib>10.0000</qTrib> <vUnTrib>3.5000000000</vUnTrib> <vDesc>5.00</vDesc> <indTot>1</indTot> <nItemPed>1</nItemPed> </prod> 2a. <prod> <cProd>1</cProd> <cEAN/> <xProd>CAFE CX 10 UN</xProd> <NCM>21011110</NCM> <CFOP>5102</CFOP> <uCom>UN</uCom> <qCom>1.0000</qCom> <vUnCom>35.0000000000</vUnCom> <vProd>35.00</vProd> <cEANTrib/> <uTrib>UN</uTrib> <qTrib>1.0000</qTrib> <vUnTrib>35.0000000000</vUnTrib> <vDesc>5.00</vDesc> <indTot>1</indTot> <nItemPed>1</nItemPed> </prod> *Desconsidere a minha explicação anterior: Se qCom = 10 (e vProd = 3,50) o vDesc deve ser 0,50 Se qCom = 1 (e vProd = 35,00) o vDesc deve ser 5,00

Da uma olhada nos exemplos de cálculos que tem no site da FlexDocs. http://www.flexdocs.com.br/guianfe/gerarNFe.detalhe.imp.ICMS.html Da pra ter uma base legal

ACBrValidador.pas acbrvalidadortest.pas

Eu acho que que se as empresas forem filiais, não teria necessidade de ter um certificado para cada estabelecimento. O Bloco X o Sefaz ainda esta ajustando, esse deve ser um bug na validação deles. Tem que esperar para ver. Tenta enviar um e-mail pro Sefaz perguntando a respeito.

Boa tarde amigo, na verdade esse problema ocorre até mesmo com 1 lote, vai bastante da "sorte" na hora de emitir, infelizmente o servidor Betha(ao menos é o único que ocorre esses problemas pros meus clientes) é bem instável, há momentos que chega demorar mais de 45 minutos para processar um RPS, dessa forma, quando o sistema tenta consultar a situação do lote após a emissão e não retorna nada pelo fato de não ter sido processado ainda, ele retorna essa rejeição sem valor. No meu sistema fiz uma opção pro contribuinte selecionar se deseja que o lote seja consultado após emissão, especificamente pra esses provedores que tem alto tempo de resposta, então fica a responsabilidade do usuário verificar na prefeitura quando a nota foi processada, para então consultar no sistema o lote e retornar as informações corretas, é uma verdadeira gambiarra que esses provedores nos obrigam a fazer...

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.