daniel.simoes

você não ajustou a biblioteca de Criptografia, para WinCrypt

Puxa.. quase... Sim, o QRCode é obrigatório... Talvez com alguma atualização de Firmware da impressora, ela consiga ficar compatível com Epson EscPos, ou funcionar o QRcode no modo EscDiebold

Aparentemente, ela não é compatível, com Epson EscPos Você poderia - Testar outros modelos de protocolos do ACBrPosPrinter (Ex: GPrinter) - Usar a impressão por Fortes Report (usando o Spool do Windows) Não deixa a escolha de compra da impressora, livre ao cliente... Deixe claro, que o cliente precisa comprar uma Impressora previamente homologada pelo seu sistema...

Sim.. e o Fabricante provavelmente tem algum Utilitário que voce pode reprogramar, todo o Teclado, com o layout de teclas que deseja

Se não me engano, ele se comportará como um HID normal.. (como um Teclado qualquer)

Esse ajuste foi desfeito... pois causou efeito colateral e erro ao transmitir os Documentos em algumas IDEs

AnsiSrting é um String Binário... Nossa preocupação em editar uma Unit "core" do ACBr, é que pode interferir em outros DFes que estão funcionais @Juliana Tamizou, precisamos de credenciais para testar em uma das cidades que apresenta o problema, para nosso próprio time reproduzir

Olha só que bacana, quando você configura a CliSiTef.ini, com DataEmAmbienteDeDesenvolvimento=AAAAMMDD Observe que além de gerar o arquivo CliSiTef.20260213.dmp, a biblioteca CliSiTef32I.dll, também gerou o arquivo CliSiTef.20260213.txt (aberto, o que permite observar a comunicação da aplicação com DLL) No Teste acima, a minha CliSiTef.ini, está configurada da seguinte forma: [Geral] TransacoesAdicionaisHabilitadas=7;8;58;3299;4439 DataEmAmbienteDeDesenvolvimento=20260213 EmAmbienteDeHomologacao=1 [PinPadCompartilhado] Porta=COM3 [CliSiTef] HabilitaTrace=1 DiretorioTrace=C:\CliSiTef [CliSiTefI] HabilitaTrace=1

não precisa desmarcar... Mas se instalou com essa opção desmarcada... então o Delphi conhece os "Paths" de todos os fontes do ACBr, e consegue recompila-los, sob demanda

sim... Mas se ele instalou o ACBr, com a opção "Deixar somente a LibXX..." então ele precisará rodar novamente o instalador...

Os fontes anexados acima, ainda não estão no SVN

Havia um erro na Unit PadraoNacional.Provider.pas... (falta de sincronismo) eu editei o tópico e subi uma nova versão

Estamos testando uma possível, solução... Caso queiram testar.. seguem as Units modificadas... ACBrXmlDocument.pas PadraoNacional.Provider.pas

Obrigado @LeoDoreto @EliasCesar, pode por favor inserir na sua Fila de tarefas ?

Essa operação, só possível de ser feita, com o certificado Digital da Empresa e a Senha do mesmo - Quem são as pessoas, que tem acesso ao Certificado Digital e Senha da Empresa ? - Se realmente tiverem certeza que a operação não foi efetuada, pelo contador, ou alguém da Empresa.. sugiro revogar o Certificado Digital vigente... Isso irá invalidar o Certificado, mas impedirá acesso da pessoa que está de posse dele, e vocês desconhecem...

Você pode testar a Lib e o Monitor, nas versões Demo https://www.projetoacbr.com.br/forum/files/category/21-acbrmonitorplus-demo/ https://www.projetoacbr.com.br/forum/files/category/63-acbrlib-demo/

@Italo Giurizzato Junior e @Diego Foliene, Preciso de instruções, de como podemos reproduzir esse problema, nos Demos do ACBr... essa modificação, pode quebrar o suporte a FPC e Delphi POSIX, que usam UTF8 de forma nativa... O problema parece estar nas classes de NFSe, pois os documentos de NFe, NFCe, usam esses mesmos fontes, sem problemas com acentos em UTF8

AnsiString, é um "String Binário".. ele aceita caracteres de Controle como #0, #13, #10, etc o WideString, é um UTF16, cada caracter, irá sempre ocupar 2 bytes https://www.freepascal.org/daily/doc/prog/progsu162.html O problema, pode ocorrer, quando você converte AnsiString para String... Exemplo, se ler um Stream do BD, e jogar ele em uma String do Delphi... pode realmente dar problemas... mas funcionaria, ler de um Stream, e jogar para um AnsiString

Obrigado pelos testes @Marcos Pereda, Vamos manter o tópico aberto... o problema de termos APIs diferentes, na mesma cidade, para Regimes tributários diferentes, parece ocorrer também em outras cidades... Logo voltamos aqui, com um Workaround para esse problema, e como podemos replicar o Workaround na ACBrLib...

A proposta parece alterar Units demais do ACBr... O ACBr já lida corretamente, com acentuação em UTF8, nos Documentos NFe/NFCe.. então creio que o problema esteja isolado nas Units do ACBrNFSeX @Diego Foliene, como podemos, de forma simples, reproduzir o problema, usando o Demo do ACBr ?

O PNG gerado dessa conversão... - Se você abrir ele na sua máquina, fica legível ? - Qual é o tamanho da imagem gerada ? Poderia anexar um PNG gerado dessa conversão ? Verifique por favor.. se o SmartTEF, não aceita o envio de PDFs (para ele mesmo converter para Imagem)

@Italo Giurizzato Junior e @Diego Foliene, nos ajudam com essa questão ? Podemos ter uma mesma Cidade (São Paulo), usando duas APIs diferentes, de acordo com o regime de empresa ?

Não seria uma boa opção, usar o INI em Memória ?

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.