Painel de líderes

Gentileza passou longe... até onde me consta não sou seu funcionário...

Boa tarde.. Fiz um Video Explicando como Instalar Acbr http://windevdesenvolvimento.blogspot.com.br/2018/03/dicas-acbr-instalar-baixar-e-instalar_19.html

O evento foi fantástico! Tudo perfeito! Parabéns Daniel pelo sucesso que o ACBr têm alcançado e por ele ter se tornado simplesmente essencial no nosso trabalho. O reconhecimento de uma gigante como a Elgin é só o começo pelo que está por vir. Conte sempre conosco!

Foi gratificante participar da Palestra Elgin e ACBr. Muitas dicas sobre equipamentos, SAT, MFe, NFC-e e ACBr. Excelente a explicação do Daniel Simoes sobre o ACBr. Espero que esses eventos se repitam com maior frequência.

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/

Bom dia, durante os testes de cancelamento de transações, me deparei com a seguinte situação: No passo 43 pede para cancelar uma transação onde o NSU original é "123456789A123456789B123456789C123456789D". Porém ao realizar o CNC, o mesmo informa no arquivo somente os numeros, ou seja, "123456789123456789123456789123456789". Para conseguir atender o requisito, tive que fazer uma alteração no ACBrTEFDClass.pas, linha 1201. segue: procedure TACBrTEFDReq.SetNSU(const AValue : String); begin fNSU := AValue; //fNSU := OnlyNumber(AValue); fConteudo.GravaInformacao(12,0,fNSU); end; Bastou apenas remover o OnlyNumber. Pelo que li nos manuais da NTK, algumas redes podem retornar um NSU maior e podem conter numero e letras. Não subi o arquivo alterado aqui pois se trata de uma modificação muito simples. Creio que seja mais facil e seguro algum administrador ou moderador alterar e disponibilizar. Para quem for fazer esse teste, um alerta importante. No Passo 41 onde é feita a venda original para depois ser feito o cancelamento no passo 43, há um erro. O NSU retornado no CRT foi apenas "9C123456789D" e não da forma completa como deve ser para atender o passo 43. Vou até reportar isso ao suporte da NTK. Para atender o passo 43, eu tive que alterar o NSU no meu banco, colocando o completo impresso no comprovante. Espero ter ajudado.

Só um detalhe para quem for enviar notas: Os 3 campos as vezes são necessários: <ItemListaServico>09.01</ItemListaServico> <CodigoCnae>5510801</CodigoCnae> <CodigoTributacaoMunicipio>901</CodigoTributacaoMunicipio> Embora seja parecido o CodigoTributacaoMunicipio não tem ponto, mas o ItemListaServico tem.

Faça um teste com o demo , que se encontrar na pasta ..Acbr\Exemplos\ACBrDFe\ACBrNFe\Delphi DANFe FR. Utilizando o arquivo DanfeRetratonovo.fr3.. Ps : Sempre tenha os arquivos do ACbr Atualizados.

Segue o manual disponível no Site, no processo de homologação, eles disponibilizam uma Macro que valida também a linha digitável e também o código de barras, em meu processo de validação foi recusado tanto a linha digitável quanto o código de barras, por isto fiz a alteração, agora estando correto. Segue junto a Macro Usada para o processo de validação disponibilizada pelo próprio banco. Eu entendo a preocupação, não é a primeira vez que envio alterações do componente, portanto entendo que existem terceiros envolvidos, por isso procurei evitar ao máximo mexer em alguns detalhes como mencionei lá no começo do tópico(Referente ao nosso número e sua nova regra em compatibilidade com a antiga), mas obrigado pela atenção. cnab400.pdf 001.zip

Obrigado Daniel, Faltava informar o Vbc para PIS e COFINS e retirei o vPIS e vCOFINS do INI. Ai deu certo

Boa tarde Luiz, Muito obrigado pela colaboração, já esta no repositório.

Juliomar deu certo, obrigado pela atenção. ja pode ENCERRAR.

Peço desculpas. Eu sempre pesquiso antes. Neste caso, só encontrei depois que postei.

Obrigado Italo, agora consegui comunicação com o provedor. Aparentemente somente problema de cadastro na prefeitura: Método........ : Enviar Lote Numero do Lote : 5646 Recebimento... : 20/03/2018 11:39:12 Protocolo..... : 000000000413 Provedor...... : ELv2 Método..... : Enviar Lote Código Erro : EL17 Mensagem... : CNPJ nao encontrado na base de dados - Confira o numero do CNPJ informado. Caso esteja correto o prestador nao esta inscrito no municipio. Correção... : Provedor... : ELv2 Muito agradecido!

A única coisa que posso dizer é que é a opção 1, o resto é maluquice de contador ou sei lá o quê. Digo isso por seguir a mesma regra que era aplicada para medicamentos, onde os lotes ficavam na tag med e agora foram para o rastro, e todos os grandes distribuidores faziam na tag med exatamente como a opção 1 que agora será a tag rastro. Que com certeza é a mais lógica. A estrutura foi criada justamente para aceitar mais de 1 lote por produto.

Isso mesmo. Pesquisei aqui e encontrei o leiaute. http://portal.esocial.gov.br/manuais/leiaute_cqc_em_lote.pdf É um arquivo TXT. Não é obrigatório mas acho que enriqueceria o componente se estivesse disponível. Obrigado por responder.

Qualificação cadastral é um arquivo que segue um layout apenas para consulta da situação do funcionário. não necessita assinatura. Acho que não faz parte do componente eSocial. posso estar enganado!

parece que o Servidor voltou a funcionar... (e ficou bem mais rápido)

Muito Obrigado @Gr@c@... Adorei conhecer MG, e ter contato com vários usuários do ACBr... Conforme prometido... subi o conteúdo das apresentações em PDF, para o fórum:

Contribuição no SVN - Revisão: 14876 Mais uma vez, obrigado.

tópico relacionado...

Realmente está instável... parou de funcionar.

Parece ser um problema no servidor do governo (problemas no Certificado deles)... experimente por exemplo, abrir a URL abaixo no navegador: https://www.receita.fazenda.gov.br/pessoajuridica/cnpj/cnpjreva/captcha/gerarCaptcha.asp

Bom dia a todos. Fiz alterações também na classe ACBrTEFDClass.pas para comportar os novos campos: CNPJ Credenciadora, Bandeira, Codigo da Credenciadora, Validade do Cartão, nome do dono do cartão, os ultimos quatro digitos do cartão, para o TEFDial. Que são solicitados pelo MFE do Ceará. Em anexo estou disponibilizando as mesma para, se assim os administradores entenderem ser viável, colocar as alterações no svn. ACBrTEFDClass.pas

Bom dia, CST= 60 (substituição tributária) não destaca valores de ICMS. Tente ser usado CST=00 (tributado). OBS: remova o espaço depois do "=". Att Ricardo

Bom dia, uma dica que eu demorei vários dias pra entender quanto ao eSocial, e que gostaria de compartilhar: não confunda número do PROTOCOLO DE ENVIO com número do RECIBO DE ENTREGA. Toda vez que vc conseguir enviar algum XML/lote (sem problema na estrutura) vc vai receber um PROTOCOLO DE ENVIO. Depois, de posso desse número de protocolo, vc precisa fazer a consulta desse protocolo pra obter o resultado do processamento desse envio. Dependendo, se o resultado foi "Sucesso", daí sim vc vai receber um número de RECIBO DE ENTREGA. Att Ricardo

Boa Noite sr.Ricardo... agradeço de coração pelo seu post...realmente preciso estudar muito ... sou programador delphi a 10 anos mais nunca fiz nada fiscal na minha vida..era programador de manutenção..por esse motivo nao tenho experiencia... mais sei que a comunidade Delphi sempre foi muito unida. sempre trocamos conhecimentos.. e sempre estamos dispostos a ajudar uma colega de trabalho..como o sr. fez, agradeço mesmo...muitíssimo obrigado . Deus te abençoe.. P.s Acredito que seja igual para nfce..Abraços a todos.. Se alguem souber onde encontrar um curso de como utilizar os componentes acbr por favor me avisem pois tenho que desenvolver sat e Nf-e tambem e sei que vou apanhar muito sem esse conhecimento...Abraços aos participantes do forum...

Após vasculhar o disco todo, descobri que havia uma outra biblioteca utilizando o Synapse E o path dela esta antes do Path do ACBr. Alterei a outra biblioteca e funcionou.

Ok, Obrigado

Boa tarde italo, Para não exibir nenhum CNPJ de meu cliente eu editei esses campos dos XML's

@Daniel Simoes Muito obrigado.

Senão me engano no sistema deve-se registrar o desconto ou acréscimo.

RESOLVIDO para quem tiver o mesmo problema, na hora de passar os campos do cliente (endereço de entrega, cpf/cnpj, etc), os campos obrigatórios devem ser preenchidos, no meu caso era o campo "Entrega.nro" que estava indo vazio. Preenchendo os campos obrigatórios vai funcionar o envio e a impressão!!

Altere: [NFRef001] Tipo=NFCe refNFe=43180303946536000192650020000016501209917270 Para: [NFRef001] Tipo=NFe refNFe=43180303946536000192650020000016501209917270

Também me deparei com esse problema e sua resposta foi simples e direta e útil!

Use a força... leia os fontes... ACBrNFe1.SSL.SSLXmlSignLib := xsLibXml2; Enviei para o SVN...

Bom dia Item 1 - O problema em questão Como já citado anteriormente as tags vBCSTDest e vICMSSTDest estão sendo geradas para NF-e 3.1 quando realizo o Load de um XML em que possui vBCSTRet ou vICMSSTRet maior que zero. Estas tags não devem ser geradas na 3.1 sendo que foram incluídas para o ICMSST (CST 60 com ST) apenas na 4.0. No fonte pncNFeW já temos uma condição onde aplica o cstRep60 apenas para versão maior ou igual a 4.0, mas no fonte pncNFeR essa condição não é aplicada. Em anexo segue fonte com alteração sugerida. Item 2 - Porque LoadFromString(XML, True)? Sempre usamos True porque recebemos XML de outros sistemas em que o XML não é gerado pelo componente ACBr podendo estar em uma outra estrutura (válida de acordo com a Sefaz) que não é lida corretamente pelo método ACBrNFe.NotasFiscais.Validar() quando passado como False no LoadFromString. Sigo a disposição caso necessário. Atenciosamente Giovane pcnNFeR.pas

Ainda tem o fato que cada Sw.House irá ganhar uma Impressora não fiscal I9 Nos vemos no evento...

Você precisa somar o valor do IPI devolução no valor da NF: <vProd>14250.00</vProd> <vIPIDevol>712.50</vIPIDevol> <vNF>14250.00</vNF> Nesse caso o vNF deveria ser 14962,50.

Essa alteração não subiu para o trunk. Apaguei tudo, mandei atualizar baixando os arquivos e continua dando o erro. Este tipo de alteração devia ser testada com mais cautela. Após baixar o arquivo FONTES.ZIP e atualizar, instalou sem erros e voltou a funcionar redondo. Obrigado e atualize o trunk por favor.

Bom dia acho que é melhor tu achar um fórum sobre C# acho que vai poder lhe ajudar mais fácil aqui os componentes são para delphi/lazarus