Daniel Simoes

Obrigado por colaborar.... Favor anexar (zip) os fontes, para análise...

Use o WinMerge e compare as Units do Trunk e Trunk2

Já temos uma correção para esse problema... Trabalhei na compatibilização do Fortes CE com o Lazarus... E acho que o resultado final ficou muito bom... em breve devo comitar modificações nos Pacotes e Projetos, removendo a dependência de Fortes4Lazarus e usando o novo Fortes CE...

Você diz o problema de acentuação no DANFCe ? (CONSUMIDOR N?O IDENTIFICADO) Realmente estava faltando um tratamento... pois essa String era atribuída em run-time... Correção já está no SVN

Como assim ?? Todo XML é um simples arquivo texto... qualquer editor de textos abre o mesmo... O problema talvez seja que o seu escritório está confundindo o XML CFe (do SAT) com o XML da NFe/NFCe... são documentos com estrutura diferente..

Esse problema é muito básico... se isso não estivesse funcionando, o fórum estaria inundado de pedidos de suporte... Aparentemente você não está carregando o CFe no ACBrSAT antes de tentar imprimir... Teste com Demo SATTeste.exe... estude os fontes dele...

(Acho que) lembro de ter corrigido um Bug no MonitorPLUS, que não considerava a parâmetrização do tipo de Empresa, na hora de gerar o XML...

Oi Cantu, Em nossa conversa por Skype, notamos que o Delphi XE (e todos Delphis com suporte a Unicode) não estavam gravando os XMLs corretamente com o encoding em UTF8... Por isso o problema ocorria... Apliquei modificações na ACBrUtil, baseado na sugestão que você me enviou.... para permitir que a conversão da String nativa do XE (Unicode) seja convertida para UTF8 antes da gravação do XML em disco... Testei no D7, XE7 e Lazarus... todos gravaram com sucesso os arquivos de Envio, Retorno e Envelopes, usando o encoding UTF8... e todos os arquivos foram abertos sem problemas no MS Edge

OK... Já está no SVN...

Italo... sobre esse problema dos XMLs salvos pelo ACBr, com acentuação, não serem abertos no navegador... eu e o Cantu já mapeamos o problema... Ele só ocorre no Delphi e nas IDEs com suporte a Unicode... aparentemente é um Bug do Delphi XE que não consegue converter uma String em Unicode para UTF8... como consequência, o arquivo é salvo como ANSI (por isso o erro) Com a ajuda do Cantu, acho que podemos aplicar um "workaround" para esse Bug do Delphi... vou testar hoje a noite..

Difícil saber o que exatamente está aumentando o Executável... Verifique aplicações mais simples, como os próprios Demo do ACBr... Não creio que isso seja uma premissa no Trunk2 (afinal, no Trunk2, milhares de linha código foram suprimidas, usando O.O).... talvez você tenha mudado algo a mais na sua aplicação.... como por exemplo a inclusão de um novo Engine de Relatórios

Tudo indica uma instabilidade temporária do Servidor...

O Emulador usa o modelo CDECL... se você usar o modelo errado... o componente irá carregar a DLL incorretamente, e fatalmente irá gerar um A.V.

Por favor forneça um passo a passo mais objetivo, de como configurar o Demo do ACBr e reproduzir o problema usando apenas o Demo do ACBr... Como eu devo configurá-lo ? Quais botões devo apertar... e em qual ordem ? Acabei de usar o Demo para gerar uma NFe e Enviar um Evento de Cancelamento... não consigo reproduzir o problema... Copie todos os Schemas, de todas as sub-pastas em: ACBr\trunk2\Exemplos\ACBrDFe\ACBrNFe\Schemas\, para uma única pasta... Use essa pasta com todos os Schemas, de todas as versões, como repositório dos Schemas

Não há...mas você pode editar o ACBrMonitor.ini de sua aplicação,e depois mandar ele recarregar os parâmetros.. Chamando ACBr.LerIni

Enviei para o SVN uma possível correção para o problema "Unable to Parse"

Observe que no PLUS há uma configuração com um CheckBox ANSI, no lado dos Edits dos arquivos de Entrada e Saída... Experimente marcá-los...

Se possível prefira o A1... com o OpenSSL, vc não precisa nem instalá-lo... Os certificados A3, evite os Tokens do tipo "PenDrive"... pois neles não há possibilidade de resgatar o PIN, usando o PUK... Ou seja, errar a senha 3x, inutiliza o certificado

O DANFE em Fortes está correto... Analisando o XML anexado e observei que você especificou "2-Outras" em indPag e por isso as Duplicatas não são impressas... Modificando no XML indPag para "1", a impressão das Faturas ocorre com sucesso... (veja o PDF em anexo) 43150900980023000100550010000507771000507770-nfe.pdf

Acho que agora matamos todos os problemas de acentuação... Essas Strings são atribuídas em Run-Time de acordo com o calculo da coluna dos Produtos, por isso foi difícil identificar o problema... Correção já no SVN...

O uso de TCP para comunicação com o Monitor, não nenhuma relação com o Tipo de Certificado... Veja com mais atenção as telas de configuração... Você pode salvar a senha...

Aqui no fórum, na área do ACBrSAT, vários usuários disponibilizaram programas já compilados, para essa finalidade

Lembre-se que o ACBr é OpenSource... então você mesmo pode ler os fontes e descobrir como funciona... Rode o SATTeste.exe estude os fontes deste projeto... Veja o Capitulo 6 da na Especificação Técnica do SAT

Aguardo o seu retorno, com o passo a passo de como reproduzir o problema usando o Demo do ACBrNFe

Corrigido, obrigado por reportar...