RicardoVoigt

bom dia, por acaso vc não está emitindo/autorizando em outra sefaz (de outra UF) diferente de MG? Att Ricardo

Bom dia, a recomendação geral é usar uma série pra cada caixa. Procure no fórum que tem vários tópicos sobre isso... Att Ricardo

Interessante... Em função do horário de verão (ou alguma atualização na sefaz), o sistema validador da NF-e passou a olhar a hora, pra saber a "real" data de emissão? Ao informar "2016-11-01T00:00..." na emissão, o sistema validador entendeu que era "antes da meia noite" do dia anterior? No caso, "2016-10-31", assim não bateu o AAMM informado na chave... Alguma coisa assim? Att Ricardo

Bom dia, consultando na sefaz (pelo cnpj ou ie), não aparece o regime no campo "Enquadramento Empresa" junto aos dados de cadastro? Att Ricardo

No arquivo q manda para impressora... Envia no final uma linha contendo os caracteres do comando q aciona a guilhotina.... Att Ricardo

Boa tarde Tente isso Att Ricardo

Bom dia, Eu abri seu pdf e não enxerguei onde está o problema... incompleto como? faltam itens? Att Ricardo

Bom dia, O NCM ele é obrigadtório ou não na NFCe? em alguns lugares dizem para colocar 99 e outros dizem que tem informar. - a princípio é sim... se não me engano podia usar o 99 para serviços, mas não sei mais sobre isso. O cNF e o nNF podem ser um número de controle gerado pelo meu sistema, ele tem que ser único? ele tem um sequencial lá no sefaz? - o nNF eh um sequencial (dentro da série), eu preenchia no início o cNF com o nNF, mas é meio perigoso pois permite que terceiros possam descobrir a chave de acesso das outras notas. O componente ACBRNFe vai gerar um código aleatório, caso vc não preencha o cNF. Eu preencho com o código (chave primária do banco de dados) da minha tabela de notas, que é diferente do número da nota. O NroLote ele tem que ser único? Respeitar uma sequencia? Pode ser o mesmo cNF? - Atualmente, meu sistema não tem controle de lote, então envio tudo com numero 1. Se o cliente não quer indetificação na NFCe como informo os dados do Dest.* (Dest.CNPJCPF, Dest.xnome...)? - Neste caso, vc tem estas 3 opções: (1) identificar o cliente com todos os dados, (2) identificar o cliente informando apenas o CPF ou CNPJ, ou (3) NÃO identificar o cliente, assim não será gerada a tag Dest. A sua bíblia agora eh o Manual de Orientação... boa sorte... Att Ricardo

Bom dia, não era no Windows 10, mas tive um caso em que tive que copiar as dlls do capicom manualmente pro system, e depois rodar como Administrador o .bat que registra elas... Lembrei, no meu caso o erro era "Classe não registrada" Att Ricardo

Bom dia, sobre NFC-e, outro dia achei esse site bem interessante http://nfce.encat.org/ sobre a sua dúvida: http://nfce.encat.org/institucional/nfc-e-nas-ufs/ Att Ricardo

Eu passei por isso na sexta tambem...

Boa tarde, utilizo o componente ACBrNFe no meu aplicativo, e gostaria de registrar uma situação que me pareceu estranha hoje em função do horário de verão. Meu cliente tinha desmarcado no windows a atualização automatica para o HV, e na segunda feira, ao emitir uma NF-e, ele berrou com De cara eu defini a propriedade ModoDeteccao para tzManual e TimeZoneStr para "-02:00", e resolveu. Hoje, ao CANCELAR uma NF-e deu novamente a mesma rejeição 703. Resolvi marcar a opção do windows para atualização automática do horário de verão, e redefini ModoDeteccao de volta para tzSistema, e funcionou tanto a emissão como o cancelamento de NF-e. Achei melhor registrar aqui pra ver se alguém consegue simular, ou me dar alguma dica de como descobrir se é mesmo um problema no componente ou em meu ambiente... Att Ricardo

Boa tarde, em que pasta o SEU programa está gravando o "primeiro" XML? EnvRec ou Arqs ? Att Ricardo

Bom dia, não sei se vai resolver seu problema, eu tinha um cliente que usava uma laser pra imprimir NFC-e em folhas A4 cortadas ao meio (105 mm de largura e 297 mm de altura), e acabei fazendo uns ajustes na classe ACBRNFeDANFCeFortes pra acertar a impressão... Att Ricardo

Boa tarde, pelo que entendi, o ACBrValidador (TipoDocto := docGTIN) valida o EAN-8 e não o UPC-E (exemplo da imagem) Aqui tem um site que calcula os diferentes DV https://www.upcdatabase.com/checkdigit.asp Se informar "000000785300" (simulando um EAN-13) ele calcula o DV = 5 (igual ao TACBrValidador) Se informar "0785300" ele calcula o DV = 1 (pelo que entendi, EAN não pode começar com zero, daí o site entende que é UPC-E) Att Ricardo

tente atualizar a pasta do FortesReport...

Bom dia, tenta aplicar a regra de arredondamento no total de cada item... Assim 0,69 + 8,84 + 5,54 = 15,07 Att Ricardo

Bom dia, eu não uso o MonitorPLUS via socket, e não sei se tem esse recurso usando socket, mas uma sugestão para resolver seu problema, será que não daria pra fazer "download" do PDF da danfe, do servidor pra estação? Att Ricardo

Boa tarde, botei a mão na massa aqui e implementei a propriedade "QuebraLinhaLetra" conforme descrevi acima... OBS 1: correção, serve também para o InfCpl (e não InfSupl) - Informações Complementares. OBS 2: não mexi no formato Paisagem. OBS 3: se aprovado, com essa propriedade, também poderá ser criado o respectivo parâmetro no ACBrMonitorPLUS. OBS 4: se não quiser fazer nenhuma quebra de linha, basta informar #0 na propriedade. Att Ricardo ACBrNFeDANFeRL.pas ACBrNFeDANFeRLClass.pas ACBrNFeDANFeRLRetrato.pas

Bom dia, não caberia uma propriedade no componente (ACBrNFeDANFeRL) para indicar o caractere que define quebras de linha? com valor padrão contendo o caractere ";" (ponto-e-virgula) Acho que a mesma propriedade poderia servir para os principais campos, como xProd, InfAdProd e InfSupl. Não estudei muito a fundo ainda essa parte, não tenho certeza como o componente se comunica com as outras classes do DANFe em Fortes, mas imagino que esta propriedade teria de ser verificada (estar visível) nestes métodos: TfrlDANFeRL.InsereLinhas e TfrlDANFeRLRetrato.Observacoes Att Ricardo

Olá, acho que a dica que vc precisa é usar esta propriedade ACBrNFeDANFeRL1.QuebraLinhaEmDetalhamentoEspecifico := True; define ela com TRUE que vai ser feita a quebra de linha entre o xProd e o InfAdProd. Att Ricardo

Bom dia, acho que precisa de um IF pra testar se (infAdProd <> ''), pois assim vc vai inserir quebra de linha em todos os itens, mesmo naqueles sem informações adicionais... (Imagino que essa quebra de linha #13+#10 pode gerar uma linha a mais em branco na impressão...) Att Ricardo

Boa tarde, caso alguém puder testar a emissão/geração do XML de uma NFC-e a partir de um arquivo INI no ACBrMonitorPLUS, segue em anexo os 2 arquivos (DoACBrNFeUnit.pas e ACBrMonitor1.pas) para análise da alteração que eu sugeri na resposta acima, tratando o troco na emissão da NFC-e. Enfim, é só uma sugestão "paliativa" enquanto não sai a tag do troco no XML, eu vi que tem outros usuários pedindo isso no fórum, espero que seja útil. Att Ricardo gambi-troco.zip

bom dia, enquanto o XML não tiver uma tag específica para o troco, ACHO que o ACBrMonitorPLUS não terá suporte ao valor do troco, nem passando como INI... Já os componentes de impressão da NFC-e já permitem vc informar um valor de troco na forma de uma propriedade, mas daí precisa do componente dentro da sua aplicação (se usar Delphi ou Lazarus). Impossível de fazer não é, mas seria meio que uma "gambiarra" pra fazer funcionar esse parâmetro ser recebido pelo INI e tratado pelo ACBrMonitorPLUS. Na tela em anexo aparece o trecho de código no ACBrMonitorPLUS onde ACHO que poderia ser feito esse ajuste. Seria necessário (não sei o impacto que daria) trocar a ordem da chamada das procedures ConfiguraDANFe e GerarIniNFe, para que o campo do troco fosse lido do INI (retornando com uma var) e passado como parâmetro para o ConfiguraDANFe, onde o valor do troco seria alimentado no DANFCeFortes ou no PostPrinter... Enfim, é só uma ideia, alguém teria de botar a mão e testar OBS: Eu não uso a emissão com arquivo INI. Att Ricardo

Bom dia, eu fiquei curioso com essa frase Dá algum erro específico na compilação? Att Ricardo