Ir para conteúdo
  • Cadastre-se

Victor H. Gonzales - Panda

Consultores
  • Total de ítens

    3.698
  • Registro em

  • Última visita

  • Days Won

    92

Tudo que Victor H. Gonzales - Panda postou

  1. a partir do momento da primeira transmissão, assine o documento, e todas as informações do XML não altere mais.
  2. vamos subir um ajuste removendo o LOperacao. obrigado
  3. Bom dia, A variavel LOperacao não seria nem necessária, visto que o IF só entraria em caso de tpInclui.
  4. Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo
  5. envie o arquivo de retorno, se tiver dados sensíveis envie para consultores@projetoacbr.com.br e vincule esse topico ao email
  6. Boa tarde, Por padrão a impressão do cupom NFCe possui a configuração de 80mm, caso necessário ajustar essa largura precisamos informar o novo valor na propriedade LarguraBobina: <ACBrNFCeDANFeFPDF>.LarguraBobina := 65; //equivale a 65mm <ACBrNFCeDANFeFPDF>.LarguraBobina := 80; ou 302; //equivale a 80mm <ACBrNFCeDANFeFPDF>.LarguraBobina := 90; //equivale a 90mm Obs: LarguraBobina = 302 equivale a mesma coisa que a configuração de 80mm, somente para compatibilidade do create da classe que o valor padrão é 302 dos componentes.
  7. Boa tarde Comunidade, As alterações do Informe Técnico já foram aplicadas ao componente, Monitor e ACBrLib. A previsão da SEFAZ para vigência Homologação / Produção é 01/07/2024, nesse momento você pode testar os novos meios de pagamento na geração do XML e deixar uma flag no seu sistema para quando chegar a hora de utilizar a nova tabela o seu sistema já está pronto. As classes do ACBr já fazem a escrita do XML, Leitura e impressão. Exemplo : Caso receber a rejeição 436 : Código do meio de pagamento inexistente, é porque ainda não está liberado a nova tabela para o uso. Uma observação ao Meio de Pagamento 05 fpCreditoLoja, que teve sua descrição alterada de Credito Loja para Private Label, isso devido ao fato de agora temos o enumerador 21 fpCreditoEmLojaPorDevolucao Crédito em Loja, que tem a finalidade "Crédito em loja decorrente de valor pago anteriormente, de devolução de mercadoria etc.". Eles possuem nomenclaturas parecidas, mas possuem finalidades diferentes, o que foi alterado foi a descrição e não código ou enumerador dos mesmos. De forma mais explicativa, o enumerador CreditoEmLojaPorDevolucao associa de forma mais clara as ocorrências relacionadas a esta forma de pagamento, tais como quando o cliente teve um crédito gerado por uma devolução de uma compra feita anteriormente, já o já existente CreditoLoja visa ser utilizado nas situações onde de fato é utilizado crediário ou cartão próprio da loja, ou seja, o chamado private label.
  8. Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo
  9. não é o caso de usar o LayoutVersaoArquivo = 002 ?
  10. Então emita nfe e não nfce pois os modelos de impressão são diferentes. A emissão pelo tipo de documento está errada
  11. Fiz um teste de impressão utilizando o FastReport, não foi detectado nenhuma marca dagua, ou mensagem estranha na impressão que não fosse o padrão. porem fiz um ajuste que estava faltando um literal (Quadrado Vermelho).
  12. tem alguma coisa errada nesse boleto: 1: não existe mais Sacador / Avalista a alguns anos, esse é o Beneficiário Final 2: o intermediário, quando se faz uma transação geralmente boleto vinculado por exemplo, o Banco é o Beneficiário, o emitente é o Beneficiário Final. o que induz que esse intermediário do seu boleto é o beneficiário do mesmo. mas essa ficha sua está fora do padrão da febraban
  13. https://cmsarquivos.febraban.org.br/Arquivos/documentos/PDF/Convenção da Cobrança - 05_02_2021_f.pdf página 27
  14. o envio está sendo feito Sincrono? caso não, a chave consulta é idêntica a enviada originalmente?
  15. 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.
      • 7
      • Curtir
  16. exato... quase todos os relatórios exigem o FastScript de alguma forma, pode não subir algum raise, mas ele não é executado com todos os recursos que ele é programado, podendo não ter o resultado como o esperado. os Exportadores só estão disponíveis na versão comercial do Fast, estamos pensando talvez em mudar isso, porem como o @EMBarbosa falou, o relatório pode não funcionar com a versão do Getit (versão basic) por falta de carregar todos os scritps, então pode ocorrer erros silenciosos. Dificil o FR3 hoje ou componente que não está com FastScript ativo.
  17. o CaracTitulo você vai usar para informar se é carteira Vinculada ou Carteira Normal.
  18. Servidores do RS devem voltar a normalidade todos os serviços nos proximos dias.
  19. Carteira geralmente é 17 variação é 35 (modalidade) segue o mesmo padrão do CNAB
  20. pelo o que andei olhando o Tomate ele pega vários equipamentos e só coloca o nome deles, não é bem um fabricante. então deve ser um protocolo genérico ESCPos possivelmente ESC/Epson.
  21. Por favor atualize seus fontes, pelo SVN do ACBr... Já subimos para o nosso repositório de fontes, modificações que podem corrigir algum dos itens referentes a esse tópico... Por favor atualize seus fontes, faça testes, e se possível comente em uma nova resposta, se o problema foi resolvido... Dúvidas, sobre o uso do SVN ? Clique aqui e veja um vídeo
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.