Painel de líderes

Por ser assinante ACBrPRO, veja este módulo do curso.. vai te ajudar sobre Distribuição DFe. https://acbr.nutror.com/curso/59fa9f9962ed0e88ca5d25ffe138c121dc5b88e7/aula/2881902 O curso foi feito com a linguagem java, mas você consegue aplicar a lógica em seu código..

Você está falando sobre as casas decimais na impressão? Se for isso está na aba "DFe" ->Impressão -> "NFe" das configurações do monitor.

Boa tarde @Italo Giurizzato Junior, Conforme reposta suporte da AT&M eles diferenciam pelo "Terminal" (propriedade CodATM do componente). Ou seja, eles disponibilizam códigos diferentes para homologação e produção. Cordialmente,

Como se trata de um componente da acbr, creio que haja alguma outra coisa para ser vista? Ou uma outra pessoa , para tentar ver se encontramos algo?

Veja no programa de exemplo como proceder: Delphi: ACBreSocial1.Configuracoes.WebServices.Ambiente := StrToTpAmb(Ok,IntToStr(rgTipoAmb.ItemIndex+1)); C#: ACBreSocial.Config.Ambiente = rdbHomologacao.Checked ? TipoAmbiente.taHomologacao : TipoAmbiente.taProducao; Documentação da Lib: https://acbr.sourceforge.io/ACBrLib/ConfiguracoesdaBiblioteca11.html Ambiente Define o ambiente que vai receber os eventos do e-Social: 0 = taProducao 1 = taProducaoRestrita Tópico movido para a área do SAC, para que o SLA de respostas seja considerado

Consegui resolver atualizando a biblioteca, obrigado pela ajuda.

Boa tarde @BSSOFT, Já esta no SVN.

@C4Dev, Já esta no SVN. Favor atualizar todos os fontes de todas as pastas, reinstale o ACBr e faça novos testes.

Olá Pessoal, As dicas abaixo são validas para todos os os modelos de DF-e (Documentos Fiscais Eletrônicos). 1. A chave de um DF-e é composta por diversas informações e todas elas estão presentes no XML. A chave é composta pelo Código da UF (2 dígitos), Ano (2 dígitos) e Mês (2 dígitos) de emissão, CNPJ do emitente (14 dígitos), modelo do DF-e (2 dígitos), série (3 dígitos) e numero do documento (9 dígitos), tipo de emissão (1 dígito), código aleatório do documento (8 dígitos) e digito verificador (1 dígito). Devemos guardar no banco de dados, juntamente com os demais dados do DF-e as seguintes informações: Data/Hora de emissão e Código aleatório que deve conter somente 8 dígitos. Jamais use como código aleatório o próprio numero do documento, pois isso você deixa a chave vulnerável. O código aleatório deve ser gerado pela sua aplicação e armazenado no banco de dados conforme orientado acima, jamais deixe o componente gerar o código para você, pois desta forma você perde o controle dessa informação. A Data/Hora deve ser definida e também armazenada no banco de dados, jamais devemos usar a função Now na rotina que alimenta o componente, pois isso faz com que você também perca o controle dessa informação. Ao alimentar o componente com os dados do DF-e todas as informações devem ser lidas do banco de dados, com exceção do Digito Verificado da chave que é o próprio componente que o calcula. 2. De preferencia de guardar o XML do DF-e no banco de dados em vez de salvar em disco, pois alguns usuários desavisados resolvem excluir arquivos do HD da maquina por achar que tem muito arquivo salvo. Se isso ocorrer, ou seja, o usuário acabar deletando o XML de um DF-e, tendo todos os dados salvos no banco de dados basta fazer o seguinte: Alimente o componente com os dados do documento que estão no banco de dados, execute os métodos Assinar, Validar e Consultar. Desta forma você vai ter o XML de volta, mas lembre-se que esse processo só pode ser executado caso o DF-e tenha sido emitido dentro do prazo de 180 dias, passou de prazo não tem como recuperar. 3. Se ocorrer erro de internet (timeout por exemplo) como devo proceder? A resposta é muito simples: Não devemos enviar o documento novamente, pois o documento pode ser rejeitado por duplicidade. Não devemos gerar, assinar, validar o XML novamente, pois essa atitude pode mudar o código aleatório do documento e a data/hora de emissão caso você não seguir as orientações da primeira dica. Com isso ao enviar novamente o documento pode ser rejeitado por duplicidade com diferença chave, situação mais grave. Devemos sim carregar o XML que foi enviado através do método LoadFromFile (se esta salvo em disco) ou LoadFromString (se esta salvo no banco de dados) e em seguida executar o método Consultar. Antes de enviar o DF-e para a SEFAZ atualize o banco de dados mudando o status do documento como "Enviado", depois devemos executar o método Enviar. Se ocorrer o erro de internet a aplicação não deve permitir que o usuário envie novamente o mesmo documento uma vez que ele esta marcado como Enviado, mas a aplicação libera o documento para que o mesmo seja carregado e consultado conforme dito acima. Caso o retorno for uma rejeição acusando que o documento não se encontra na base de dados da SEFAZ, a aplicação pode tomar uma atitude automática de enviar novamente o documento, visto que ele não se encontra na base de dados da SEFAZ. Por outro lado se retornar o protocolo de autorização, como o componente esta com o documento "carregado" o XML será automaticamente atualizado e salvo em disco ou disponibilizado para que o mesmo possa ser salvo no banco de dados. A aplicação em seguida pode imprimir o documento auxiliar do DF-e. Seguindo essas dicas, muitos problemas com a emissão de DF-e são sanadas.

Boa tarde Comunidade ACBr, no commit 33681 foi unificado o comportamento do componente ACBrNFe no que diz respeito a geração de PDFs. Desta forma para qualquer um dos geradores suportados, o comportamento de geração dos arquivos em PDF será respeitado igualmente, não havendo distinção de regras entre eles, o que causava problema ao se trocar de gerador e também dificultava o suporte. Esta mudança foi aplicada para preservar a compatibilidade entre os geradores, para que todos tenham a mesma regra de negócios aplicada, e também caso haja uma das configurações abaixo sejam aplicadas com sucesso a cada arquivo gerado de forma individualmente. Configurando : <ACBrNFe>.DANFE.UsaSeparadorPDF := True; <ACBrNFe>.Arquivos.SepararPorAno := True; <ACBrNFe>.Arquivos.SepararPorMes := True; <ACBrNFe>.Arquivos.SepararPorDia := True; <ACBrNFe>.Arquivos.SepararPorCNPJ := True; o sistema irá criar os arquivos com base nas informações do XML como exemplo : [CNPJ] [ANO] [MES] [DIA] C:\ACBr\pdf\9999999000191\2024\05\18\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\19\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf C:\ACBr\pdf\9999999000191\2024\05\20\XXXXXXXXXXXXXXXXXXXXXXXXX.pdf Como era Antes O PDF era gerado usando como base o primeiro arquivo carregado ou conforme o gerador selecionado, eram gerado todos os PDF dentro do mesmo arquivo. Como ficou Agora É gerado um arquivo único com seu respectivo documento na respectiva estrutura conforme a configuração do componente, não há a possibilidade de gerar um arquivo com vários PDF juntos, o sistema irá gerar vários PDF cada um com seu documento fiscal respectivo. Eventos Para a impressão correta dos eventos, é necessário que a nota fiscal esteja também carregada no componente, e não somente o evento, pois existem informações que são necessárias abstrair do XML do Documento Fiscal. O não carregamento da NFe que originou o evento, pode ocasionar erros no fluxo de impressão ou campos faltando o preenchimento.

Deixando a solução para quem precisar, como no Android 12 teve mudanças nas permissões, foi necessário marcar essas opções no projeto.

esse problema que ele esta enfrentando por acado acabei de descobrir oque é, tem que marcar a opcao formulario continuo para não ficar aquele espaço no final.

Bom dia @vinizioWOW, E como eles identificam que se trata de um teste e não uma averbação pra valer?