Painel de líderes

A imagem mostra que tem algo errado com os teus fontes. Esse pacote "ACBr - DANFe em FortesReport" - ACBr_NFeDANFeRL.bpl - não devia estar sendo instalado já que ele é apenas de runtime. O pacote com os componentes é o "ACBr -- (Design Time) DANFe em Fortes Report" - DCLACBr_NFeDANFeRL.bpl. Veja novamente se está com todos os fontes atualizados, se há alteração local no fontes (faça o revert se necessário), se não há binários do ACBr em outros locais, etc.

Boa tarde. Verifiquei também, realmente está faltando uma opção no enumerado TCodVer. Deveria haver um "Versao013" para tratar a nova versão do layout na função CodVerToStr. Até percebi que na versão 1.2 do layout eles mantiveram o código como 0011 e não 0012... Mas enfim, é isso mesmo, caso queira eu posso modificar e anexar a unit "LCDPRBlocos.pas" alterada, ou você já fez alguma correção?

Oi Daniel faz uso sim! A lib OpenSSL1.1 tem essa dependencia. Apague as libs do OpenSSL1.1 que resolve. Ou faça atualização do seu Windows. Se for Windows 7 precisa ter SP1 no minimo..

Mas note que já está sendo impresso nas informações adicionais, conforme imagem... Não podemos adicionar em qualquer outro campo específico da DANFe, se isso não está previsto pela SEFAZ, pode causar até autuações...

Bom dia Thiago, Muito obrigado pela colaboração, vou analisar e caso esteja tudo OK, vou enviar para o repositório. Já esta no repositório.

boa noite.. nao sei se é o seu caso, mas vou colocar abaixo como esta configurado no meu sistema

Prezados, Gostaria de confirmar com mais alguém a respeito da versão do layout para o campo COD_VER do bloco0000. Observado a função de conversão em LCDPRBlocos.pas (function CodVerToStr(CodVer : TCodVer) : String;) hoje o ACBr trata apenas as versões 0001 e 0011. Mas não estaríamos na versão 0013?

Teve algumas modificações no site da receita que seria bom ser atualizado nos fontes, que ira alterar o "CURL_REFER" e alguns parâmetros do "PostStr" que não são mais necessários. Segue em anexo a alteração. ACBrConsultaCNPJ.pas

Blz então Farei um controle a parte disso

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Boa tarde amigo... a primeira coisa a verificar seria o código dos campos extras "c39_camposExtras"... pois na versão de produção, não existe o campo 91 e 73 na tabela... Se vc pegou estes campos na homologação, infelizmente o governo não manteve os mesmos códigos na produção... Também passei por esta dificuldade... Verifique esta configuração, e reporte se deu certo... Obrigado!! Att.: Gustavo Déo

Certo, tudo bem... Segue em anexo a unit "LCDPRBlocos.pas" com a alteração na função CodVerToStr para gerar o campo "3 - Código da versão do leiaute " do bloco 0000 com o valor 0013. Peço aos administradores quando possível validarem e adicionar ao svn. Obrigado. LCDPRBlocos.pas

Obrigado pela atenção. RESOLVIDO. O SSLType estava com LT_ALL e tive que mudar para LT_TLSV1_2. Mas como funcionou até outro dia, você fica procurando em todo lugar, mas não pensa que pode ser código. Depois de muito quebrar a cabeça, e perguntar aos amigos, enfim a solução. Mas o computador do cliente também tem que atualizar o Windows. Muito obrigado aos amigos que perderam tempo me ajudando. Um abraço

Boa Tarde @Italo Jurisato Junior, @Juliana Tamizou... O Distrito Federal ainda se encontra na Versão 1.00, não está disponível a versão 2.00 Realizei uma nova transmissão, e agora foi realizado com sucesso... Pode ter sido uma instabilidade da receita... De momento o tópico está resolvido.. Obrigado!!!

Com relação ao CNPJ, o problema era que estava informando da empresa 06.773.063/0001-08 do PI e o do certificado esta 06.773.063/0002-48 do DF. Pensava que era comparado somente a parte principal 06.773.063. Só fiquei na dúvida se o problema era porque são de estados diferentes ou se realmente precisa ser completo 06.773.063/0001-08, ou seja, se uma filial dentro do mesmo estado com final do CNPJ diferente pode ou não usar um único Certificado. Como não tenho este caso no momento não consegui testar. Ref. a I.E ficou OK, estava pegando UF de variavel errada. Grato pela atenção.

Cara seguinte eu tentei de varias maneira reproduzir seu erro aqui e não consegui. Então peço se possível crie uma vm no virtual box onde ocorra o erro e me envie para que eu possa tentar corrigir este erro.

Muito obrigado era isso mesmo, após atualizar a DLL funcionou corretamente, vlw.

Boa tarde Walison, Assim que possível vou analisar, pode ser que esteja faltando algumas coisas em relação a versão 2.00

Existe o DANFE simplificado, implantado pela NT 2012.001. https://svn.code.sf.net/p/acbr/code/tools/DFe/NFe/NT/2012/NFe_NT2012_001 DANFE Simplificado.pdf Esse modelo de DANFE é permitido apenas em vendas fora do estabelecimento da empresa. Para operações normais, o tamanho mínimo do DANFE NFe é o A4:

Não... O ACBr não faz uso dessa DLL

Obrigado pelo pronto atendimento.

Bom dia Cleonir, Já enviei para o repositório, fiz algumas alterações visando ele utilizar o Token quando o componente não esta configurado com o certificado digital e o serviço Login foi executado. Por favor atualize os fontes e faça novos testes.

obrigado

Bom dia, inclui no componente a propriedade Complemento de instrução, a principio criei para todos os bancos dentro da classe boleto, caso não fique de acordo podemos fazer somente para o sicredi, testado e aprovado pelo banco Em anexo as units alteradas ACBrBancoSicredi.pas ACBrBoleto.pas

Sobre esse assunto veja o tópico abaixo, ou abra um novo relatando o problema.

Para o caso do ESC/POS, é preciso carregar no componente o arquivo de evento também. Veja esse outro tópico:

Basta não mandar gerar o arquivo ao final depois de todos feitos, tu adiciona as informações de todos os boletos no componente e manda gerar o arquivo

Bom dia. Aparentemente ninguém tem oque você procura, talvez vc queria postar um anuncio na área de classificados. Att.

Já encontrei algumas units aqui. Vou estudá-las. Obrigado.

Bom dia Cleonir, No manual que tenho, consta que na versão 3.6 do mesmo publicado em 04/01/2016 diz: Melhorias nas explicações de parâmetros de quebra e diferença de frete. Método ObterOperacoesTransporteAgrupadasPdf foi descontinuado. Se o método que retorna o PDF foi descontinuado porque ele continua funcionando? Em vez de retornar o PDF deveria pelo menos retornar uma rejeição acusando que o método foi descontinuado. Fiz uma alteração no componente, mudei o tipo da propriedade PDF de String para AnsiString e na unit ACBrCIOTWebServices alterei o método responsável por salvar o PDF em disco, pois o que estava sendo utilizado pressupunha que o conteúdo do arquivo a ser salvo é um XML, que não é o caso. Favor atualizar os fontes e faça novos testes.

Bom dia Jeferson, Infelizmente a SEFAZ não possui uma opção de cadastro para desenvolvedores, quem sabe um dia. Sendo assim, quem vai emitir o BP-e é que tem que solicitar a liberação junto a SEFAZ, inicialmente para o ambiente de homologação e depois para o de produção. Supondo que a empresa XYZ que realiza transporte de passageiros (rodoviário por exemplo) lhe contratou para desenvolver o sistema de emissão de BP-e. Essa empresa ou o contador dela vai ter que solicitar a SEFAZ a liberação para emissão do BP-e. De posse do certificado digital da empresa XYZ você vai desenvolver e realizar os testes em ambiente de homologação da SEFAZ. Finalizado o desenvolvimento e com todos os testes realizados a empresa XYZ poderá iniciar a emissão do BP-e em ambiente de produção. Tem SEFAZ que ao realizar a liberação, libera os dois ambientes, outras não, sendo assim antes da empresa começar a emitir em ambiente de produção é preciso verificar se já esta liberado, caso não esteja solicitar a liberação. Espero ter ajudado.

Bom dia Luiz, O CNPJ do certificado digital tem que ser o mesmo informado no grupo <Emit>. A Insc. Estadual informada no grupo <Emit> tem que ser do Emitente e ser da UF informada no referido grupo. Portanto se no grupo <Emit> a UF é PI a Insc. Estadual do emitente tem que ser da mesma UF e o CNPJ informado tem que ser igual ao do certificado digital.

Para emissão de CFe utilizando o MFe não precisa do integrador... Com esse erro no Integrador realmente não vai conseguir transmitir utilizando o mesmo.

@marcio-carneiro Tu precisa alterar sim, de acordo como o @Amarildo de Matos postou acima. Os protocolos já foram desabilitados em 20/01, de lá para cá nada mais funciona com protocolos antigos, como o SSL, nem NFe, a não ser que SVRS ainda não tinham sido, mas no caso de problema com protocolo nem NFe vc consegue emitir. em todo caso da´uma olhada nesse post.

Muito obrigado pela analise e correção... no SVN... Commit [r19332]

Maybe you can find they here: https://sourceforge.net/p/zeoslib/code-0/HEAD/tree/trunk/lib/mysql/

provavelmente foi tratado em alguma rotina... Qual é a UF ? Podemos fazer um teste com o Demo do ACBrNFe por favor teste com o que anexei... Se você visualizar o XML no I.E. ele mostra uma Declaração genérica, que não está fisicamente no arquivo... na dúvida veja o XML pelo Notepad++

Bom veja tu fala de NFCe Android mas fala em Linux. no caso do Android ele já vem com as bibliotecas

Tchê, vários monitores no mesmo servidor ? Não me agrada muito esse cenário. Se fosse possível é claro, eu optaria por instalar um monitor em cada estação que necessita, gravando o que for preciso no servidor

Boa tarde. Ocorreu o mesmo problema comigo. Instalando manualmente o pacote DCLACBr_NFSeDanfseFR, verifiquei que a unica alteração nos fontes da unit pnfsConversao.pas, além dos comentários, foi a inclusão da uses ACBrBase. Então comentei essa uses no arquivo pnfsConversao.pas e compilou sem erros. Com isso consegui fazer a instalação manual desse pacote DCLACBr_NFSeDanfseFR.dpk Fiz os testes de impressão da Nota de Serviço e por enquanto está funcionando normalmente.

Já falei com o @José M. S. Junior, a respeito... vamos fazer uns testes e ver se seria possível...

Muito obrigado pela analise e correção... já está no SVN... Commit [r19329]

Boa tarde Michel, Muito obrigado pela colaboração, já vou enviar para o repositório.

@Daniel Simoes se der certo ficaria excelente. Sds.

Testei com o teu XML e não tive problemas na geração do arquivo, o componente gerou o nome conforme esperado. De qualquer forma, enviei ajuste para o repositório, rev. 19325, baseado na sua alteração: Favor atualizar os fontes e testar novamente.

Pelo erro no log esta dando timeout tente aumentar o tempo do timeout.

Obg Pelas informações, realmente não tem e já iniciei a implementação do mesmo sem uso de componente. Atendemos postos de combustíveis e lá é obrigatório.

Olá pessoal, Sei que todos estão muito atarefados com seus programas por aí... Maaaasssss.... Precisamos de sua atenção para uma alteração nos componentes!!! Atualmente temos uma falta de padronização nas unidades de medidas das margens das impressões dos documentos fiscais. Cada impressão Report tem margens medidas com um formato. Isso não está bom. Note a tabela a seguir com as unidades de medidas das margens atual: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) cm cm nd X NFC-e mm mm X X NFC-e (A4) cm mm X X SAT mm X X X CT-e (Evento) cm nd X X CT-e (A5, Retrato) nd nd X X CT-e (Inut, Inut Retrato) nd nd X X GNR-e nd nd nd X MDF-e (Retrato, Evento) cm nd X X NFS-e cm nd X X BP-e X X X X Legenda: mm – milímetros cm – centímetros nd – O componente poderia, mas não está atualizando as margens do report X – Não possui impressão nesse formato ou não interage com as margens. Nota: Os modelos em ESCPOS que existem não consideram as propriedades de margem. Afinal, não faz muito sentido mesmo. Como podem ver na tabela acima, muitos componentes não estão atualizando as margens. Isso significa que mesmo que configure uma margem, ela será simplesmente ignorada. Então a ideia é fazer com que esses componentes imprimam de acordo com a configuração. Além disso, queremos evitar qualquer possível confusão e por isso vamos padronizar as unidades de medidas. A unidade de medida escolhida foi milímetros (mm). Alguns dos motivos foram: A unidade de medida mm funciona bem tanto para impressões grandes (por exemplo A4) como para bobinas (80 mm); As pessoas estão acostumadas com mm porque é a unidade padrão de todos os geradores de relatório usados atualmente (Fast Report, Fortes Report, LazReport ...); Devido ao ponto anterior, usar mm vai nos poupar código de conversão de unidades; Mesmo que tivéssemos escolhido centímetros (cm), haveria quebra de compatibilidade por causa do SAT e NFC-e; Quando as alterações vão entrar em vigor? A previsão é que dia 14 de outubro, as alterações sejam enviadas ao SVN. Acreditamos que isso dá tempo suficiente, para conseguirmos avisar a todos e para que todos possam se preparar. As alterações já foram enviadas ao SVN. Veja nota no fim desse post. O que eu preciso verificar no meu aplicativo? A primeira coisa é verificar se você tem configuração de margem (seria bom que tivesse). Em caso afirmativo, como você está armazenando? Em que unidade está armazenando? cm ou mm? Vai ser necessário fazer alguma conversão? Verifique como você deseja manter a configuração? De posse das informações acima, faça um teste imprimindo todos os documentos que você usa. Isso vai ajudar você a prevenir qualquer problema antes de enviar o executável para o cliente. Sugerimos você a imprimir tanto antes como depois das alterações no componente. Assim você vai ter algo para comparar as impressões e ajustar as margens caso necessário. O que eu preciso fazer caso use o ACBrMonitor Plus? A nossa ideia é minimizar o impacto para quem usa o ACBrMonitor. Vamos colocar as informações o próximo post logo abaixo. Se ficarmos atentos a essas alterações, as impressões vão seguir o mesmo padrão e ninguém mais vai precisar se confundir. Atualização- 17/10/2019 As alterações já foram enviadas ao SVN. Agora todos os reports seguem o mesmo padrão: DF-e Fortes Fast LazReport ESCPOS NF-e (Paisagem, Retrato, Inut, Evento, Simplificado) mm mm mm X NFC-e mm mm X X NFC-e (A4) mm mm X X SAT mm X X X CT-e (Evento) mm mm X X CT-e (A5, Retrato) mm mm X X CT-e (Inut, Inut Retrato) mm mm X X GNR-e mm mm mm X MDF-e (Retrato, Evento) mm mm X X NFS-e mm mm X X BP-e X X X X Caso encontre algum problema, queira por favor criar um novo tópico.

Olá No Danfe em Rave CB é um pouco diferente. Optamos por incluir uma propriedade nele Chamada: ExpandirDadosAdicionaisAuto Quando TRUE e os dados adicionais "estourar" para a próxima página, o Danfe automaticamente irá Redimensionar o quadro Dados Adicionais. Dessa forma ele não divide o quadro como no Fortes, só expande. Veja bem, as duas maneiras estão corretas (Fortes e RaveCB), escolha a que melhor lhe atende. []´s