Daniel Simoes

Por favor gere 2 XMLs idênticos, e assinados com ambos os programas, para compararmos... anexe no post

Que post grosseiro... Ninguém aqui é seu empregado... Faça você mesmo o seu...

o Objeto GAV é diferente... (e está obsoleto hoje em dia) Minha sugestão é que você passe a imprimir seus relatórios de bobina, todos baseados no ESCPOS.. e com isso ganhar suporte a Gaveta, Cod.Barras, QRCode, Guilhotina, etc Exemplo: ESCPOS.imprimir("</zera></linha_dupla>FONTE NORMAL: 48 Colunas</lf>....+....1....+....2....+....3.... +....4....+...</lf><e>EXPANDIDO: 24 Colunas</lf>....+....1....+....2....</lf></e><c>CONDENSADO: 64 Colunas</lf>....+....1....+....2....+....3....+....4....+....5....+....6....</lf></pular_linhas></corte_total></abre_gaveta>")

Afim de deduzirmos se o problema é no ACBrNFe ou no SEFAZ... Algum outro aplicativo (que não use o ACBrNFe) consegue enviar com os acentos ?

Não acho que a implementação seja correta, a rotina espera que o valor de "ItemCupom.DescAcres" contenha sinal (loops com a soma pode dar errado) Não consegui reproduzir o problema que você alega... usando o FPCUnitTeste da ACBrComum, adicionei os testes abaixo: procedure RoundABNTTest.ValoresNegativos; var AVal: Double; begin AVal := -2; CheckEquals( AVal, RoundABNT(AVal, 0) ); CheckEquals( AVal, RoundABNT(AVal, -1) ); CheckEquals( AVal, RoundABNT(AVal, -2) ); end; ... e tudo funcionou a contento...

O ACBr é OpenSource... estude a Unit pcnAuxiliar.pas function GetUTC(UF: string; const dataHora: TDateTime): string;

Prometo que dou uma olhada... mas estou com vários outros assuntos para avaliar no momento...

Baixe o Demo do PosPrinter.exe primeiro faça testes com ele... confira o botão "Ajuda - tags válidas" Veja a tag "</abre_gaveta>" Consulte no manual do ACBrMonitorPLUS, os comandos disponíveis no Objeto "ESCPOS", para compreender como enviar os comandos e as Tags

A mensagem de erro vem da DLL... Entre em contato com a Bematech

Use o modelo StdCall

Você consegue abrir a URL do Webservice, pelo Internet Explorer ?

Você precisa criar um mini exemplo que demonstre o problema...

Extraia o Log do SAT... A falha ficará descrita nele... Geralmente é falta da configuração da interface de rede

Humm... Sempre imaginei que já estávamos falando do MonitorPLUS, afinal conforme já anunciamos, o MonitorNFe é atualmente obsoleto... Não faz mas sentido investigar e corrigir problemas no MonitorNFe...

Parece ser um memory leak.. Geralmente essa demora ocorre quando o HeapTrace está sendo gravado... Veja o conteúdo do Log do HeapTrace

Por favor verifiquem esse post:

Apliquei as seguintes modificações no SVN -- pcnAuxiliar -- (por: DSA) [+] Adicionado novo Tipo: TTimeZoneModoDeteccao = (tzSistema, tzPCN, tzManual); [+] Adicionada novca classe: "TTimeZoneConf" com as propriedades published: ModoDeteccao: TTimeZoneModoDeteccao TimeZoneStr: String [*] Removida a sobrecarga do método: "GetUTC" [+] Adicionado o método: "GetUTCSistema", que utiliza a rotina de synautil para detectar o TimeZone do Sistema Operacional [+] Adicionada uma variável global "TimeZoneConf: TTimeZoneConf", para permitir configurar a maneira que o método "GetUTC", irá se comportar de acordo com as propriedades de TTimeZoneConf -- ACBrDFeConfiguracoes -- [+] Adicionado a propriedade: TimeZoneConf: TTimeZoneConf em TWebServicesConf, para permitit configurar como o métoto pcnAuxiliar.GetUTC se comportará, na detecção do TimeZone (leia mais em: PCNComum-change-log.txt) -- pcnCCeNFe, pcnEnvEventoNFe, pcnNFeW, pcnProcNFe -- [*] Ajuste para usar nova versão de pcnAuxiliar.GetUTC (por: DSA) -- ACBrNFE, ACBrNFeNotasFiscais -- [*] Ajuste para propagar valores de ACBrNFE.Configuracoes.WebServices.TimeZoneConf para pcnAuxiliar.TimeZoneConf (por: DSA)

Notei que a impressora definida, não era informada para a rotina que gerava o PDF.. Fiz alguns ajustes, numa tentativa de corrigir o problema Realmente o problema parece ser o caso do Windows usar a impressora como Default Por favor faça um teste, com o executável em anexo... ACBrMonitor.zip

A impressora definida como padrão, "Ricoh Aficio MP 171 PCL6", existe no sistema ? A impressão de NFe (55), ocorre com sucesso ?

modificações aplicadas: [*] Ajuste em "SAT.EnviarCFe", para permitir o envio do XML que esteja na memória carregado com "SAT.CarregarDadosVenda" (por: DSA) [-] Ajustes na leitura dos campos Emit.cRegTrib, Emit.cRegTribISSQN e Emit.indRatISSQN (por: Anfm)

Modifiquei a rotina "DescontoAcrescimoAnterior" para considerar os acréscimos em: Det.Prod.vOutro - "Valor de acréscimos sobre valor do item"

Amarildo, Finalmente achei um tempo para analisar... Não compreendi a necessidade de comentar a linha abaixo: procedure TACBrECFVirtualBufferClass.DescontoAcrescimoItemAnteriorVirtual( ItemCupom: TACBrECFVirtualClassItemCupom; PorcDesc: Double); ..... .... // ImprimeBuffer ; -- Amarildo Lacerda - so imprimir no final Acredito que o problema ocorria porque você está chamando "inherited" em "TACBrECFVirtualSATClass.DescontoAcrescimoItemAnteriorVirtual" ( e isso não é necessário ) Notei que você introduziu o método: "GetNumCFCEmAberto", para recuperar o valor: "fpCuponsCanceladosEmAberto"... mas isso não é necessário, pois já existe o método: "GetTotalCancelamentosEmAberto", chamado pela propriedade: "TotalCancelamentosEmAberto" notei ainda que em: "TACBrECFVirtualSATClass.VendeItemVirtual", estava adicionando o Desconto/Acrescimo e isso estava ocorrendo 2x, pois no final de "TACBrECFVirtualClass.VendeItem", há uma chamada ao método: "DescontoAcrescimoItemAnterior" Modificações já estão no SVN...

Vou providenciar a modificação que citei acima... (acho que um parâmetro para esse comportamento seria difícil de compreender)

Você deve postar um passo a passo de como reproduzir o problema, usando o Demo do ACBrNFe

Veja... o Bug pode até ser no Fortes... mas você precisará sinalizar isso de forma muito clara para eles... - Onde o bug está, e como ele ocorre. Não dá pra analisar nada no Fortes, com as informações que você passou até o momento...