Daniel Simoes

Os campos parecem ser autoexplicativo... Se você tiver acesso ao SAC... esse vídeo dá o passo a passo de forma mastigada https://www.projetoacbr.com.br/forum/video/view/10-comunicação-entre-acbr-e-sat/

Teste com o Demo SATTeste... Use o modelo do ACBr stdcall

Por favor poste (anexe) a sua configuração (ACBrMonitor.ini) e o Log do MonitorPLUS, nele estará presente a mensagem de erro

Com a ajuda do @BigWings, hoje cedo enviamos algumas modificações para o SVN, que devem resolver o problema...

Respondi por M.P., com o código que obtive sucesso, com os dados de sua conta...

Realmente no ECF não dá para cortar o Papel por "Tag"... isso ocorre porque o Corte de Papel em ECF é efetuado por um comando do Sw,Básico do mesmo... e não por um caractere de controle...

Enviei uma possível correção para o SVN...

https://servicos.serpro.gov.br/api-serpro/ Antes de se animar... veja os preços em: https://minhaconta.serpro.gov.br/pfa/#/venda-api?produto=apicnpj

Qual é exatamente a mensagem de Erro ? Qual é a a marca e modelo do ECF ? Qual é o passo a passo para reproduzir o problema, no ECFTeste ? Repare que o método TruncFix está coberta por nossas UnitTestes.... já rodou elas ? procedure TruncFixTest.AsExpression; begin CheckEquals( 156, TruncFix( 1.602 * 0.98 * 100) ); CheckEquals( 64, TruncFix( 5 * 12.991) ); CheckEquals( 49, TruncFix( 2.09 * 23.5) ); end; procedure TruncFixTest.AsDouble; var ADouble: Double; begin ADouble := 1.602 * 0.98 * 100; CheckEquals( 156, TruncFix( ADouble ) ); ADouble := 5 * 12.991; CheckEquals( 64, TruncFix( ADouble ) ); ADouble := 2.09 * 23.5; CheckEquals( 49, TruncFix( ADouble ) ); end; procedure TruncFixTest.AsExtended; var AExtended: Extended; begin AExtended := 1.602 * 0.98 * 100; CheckEquals( 156, TruncFix( AExtended ) ); AExtended := 5 * 12.991; CheckEquals( 64, TruncFix( AExtended ) ); AExtended := 2.09 * 23.5; CheckEquals( 49, TruncFix( AExtended ) ); end; procedure TruncFixTest.AsCurrency; var ACurr: Currency; begin ACurr := 1.602 * 0.98 * 100; CheckEquals( 156, TruncFix( ACurr ) ); ACurr := 5 * 12.991; CheckEquals( 64, TruncFix( ACurr ) ); ACurr := 2.09 * 23.5; CheckEquals( 49, TruncFix( ACurr ) ); end; procedure TruncFixTest.AsLargeExtended; var AExtended: Extended; begin AExtended := 116529560.3123 * 100; CheckEquals( 11652956031, TruncFix( AExtended ) ); end;

Não notei nada de errado... recebi o e-mail normalmente.. acredito que você tenha recebido uma cópia... Notei que você usa Hotmail.. eu odeio o Hotmail.. ele é o campeão de "Bounce"

Por favor forneça um passo a passo completo, de como reproduzir o problema no Demo do ACBr

comente essas linhas... essas propriedades não existem mais...

se você puder me passar as informações de Login, no Privado, posso tentar fazer alguns testes...

Não há erros.. tudo indica que o email, foi enviado... Verifique se o Destinatário não está filtrando o mesmo...

Por favor testem substituindo a Unit em anexo... ACBrNFeWebServices.pas

Eu realmente não tenho como testar de forma avançada, pois não tenho esse equipamento... Por favor, fique a vontade para sugerir modificações nos fontes... (basta anexá-los)

Não consegui reproduzir o problema, no Delphi XE Tokio.. Vejas os XMLs gerados, estão corretamente acentuados e em UTF8... Por favor teste com o Demo do ACBr, e informe um passo a passo de como reproduzir o problema... 20180116002756-ped-cons-soap.xml 20180116002756-ped-cons.xml Verifique se você está usando os Schemas corretos...

Obrigado pelo Log, apliquei uma possível correção no SVN

Teste com o Projeto Demo do ACBr

Não se assemelha com as suportadas pelo ACBrETQ... PPLA, PPLB, ZPLII

Verifique no manual qual protocolo ela suporta...

Obrigado... já está no SVN...

Bingo... era isso mesmo... Quando usando a comunicação pela DLL, ela na verdade não retorna o TBR.. e a classe do ACBr, não completava a resposta com essa informação... Enviei uma possível correção ao SVN Obrigado pela analise e pelo Bug Report

Não é uma falha, mas uma característica do Fortes... Ele usa as métricas do Papel definido na Impressora, para compor o relatório...

Humm.. isso pode ser verdade... essa informação realmente não era verificada antes... Mas em todo caso, seria um erro da DLL, compor a resposta dessa maneira... pois TBR é o "Tamanho do Bloco de Resposta", ou seja, seria quantos bytes haverá no Retorno... Reanalisando o log, com essa possibilidade...