Daniel Simoes

Vamos por partes... imaginei que você estivesse falando do XML de retorno, mas aparentemente é o XML de envio.... Qual é o passo a passo para gerar o mesmo no SATTeste.exe ? Como ele deve estar configurado ? O que exatamente é o problema ? Como está e como deveria estar ? Já tentou editar o XML e envia-lo para o SAT ? o que ocorre ? {$IFDEFs} são resolvidos apenas em tempo de compilação... Acho que compreendi o que você diz... o método TCFeW.GerarXml, apenas irá adicionar a Tag com o tipo UTF8, se a IDE suportar UTF8 de forma nativa... isso indica que o XML não precisará ser convertido antes do envio (pois já está em UTF8) Porém observe em: TACBrSAT.EnviarDadosVenda, que o XML é convertido para UTF8 (se necessário)... Ou seja, o componente mantém o XML na codificação nativa da IDE... isso permite que você possa manipulá-lo e lê-lo de forma tranquila (pois usa o mesmo encoding de sua IDE) Porém, antes do envio, ele converte o mesmo para UTF8, que é o que determina a Especificação técnica do SAT

Estranho... é como se o Compilador estivesse avaliando ambas as expressões, sem se preocupar com o Booleano... Enfim... a correção é justa, e não causará efeito colateral... Enviado para o SVN... obrigado

Tópico fechado por desacordo comercial

Como eu já disse no tópico anterior.... a correção já está no SVN...

O ACBr somente usa a porta Serial... Comunicação USB é muito específica de cada dispositivo... Ou seja... não há planos do ACBr suportar a USB dos dispositivos de forma nativa... A grande maioria dos Fabricantes disponibilizam drivers que fazem a USB criar uma COM virtual no S.O.

O XML retornado é exatamente como o SAT devolve ele... para inserir essa Tag estaríamos alterando o mesmo... Não sei se isso é uma coisa boa... essa propriedade só tem sentido se o SAT usar UTF8... E tem mais efeito na exibição de mensagens e erros... Nem todos modelos suportam UTF8

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

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...