Daniel Simoes

Haa... falha minha... agora sim compreendi... SIM, é interessante... vamos inserir no RoadMap

Não temos a intenção de criar comandos para a Geração do XML... Assim como no caso do SPED, não faz muito sentido, criar uma sintaxe de comandos TXT, para gerar outro TXT...

Por favor forneça mais detalhes... Como podemos reproduzir o problema ? Que comandos você está enviando para o ACBrMonitorPLUS ?

Se você usar EscPos as próprias impressoras podem gerar o QRCode... (mas isso é complexo e o comando varia por impresssora)... No ACBr temos o ACBrPosPrinter para essa finalidade... Para usar um gerador de relatórios, ele deve ter a capacidade de imprimir QrCode ou Imagens... você pode gerar o QRCode em outro componente/classe e imprimi-la como imagem no seu relatório...

No google encontrei: http://stackoverflow.com/questions/5729806/encode-string-to-utf-8

Notei que você não é membro do SAC... tudo bem, isso não é obrigatório... Mas nesse caso, esperamos a sua colaboração, para analisar os fontes e nos ajudar a corrigir o problema...

Talvez o mais simples, seja o ACBrMonitorPLUS estar instalado no Cliente, e você usar a comunicação Socket para falar com ele... Não foi previsto o use de um ACBrMonitorPLUS para vários clientes diferentes (dados de configuração diferente)...

O Instalador irá "coletar" todos os Change-Logs.txt de todos os componentes utilizados, e eles estarão disponíveis na pasta "C:\ACBrMonitorPLUS\ChangeLog"

Acho que poderíamos modificar os fontes do ACBr para suportar esse recurso, usando alguns parâmetros com valores "default", para não impactar em aplicações já existentes... (Assim como já existe em TDFeSSLClass.SignatureElement o parâmetro "AddX509Data: Boolean") A remoção de espaços indevidos, é realmente uma deficiência "TDFeSSLClass.AjustarXMLAssinado" e pode ser corrigida. Não ficou claro para mim, se a OpenSSL/CAPICOM estão preenchendo o TimeStamp, ou se você mesmo está fazendo isso...

Somente ligando na Sw.Express para confirmar... mas crio que o 133 seja algo de controle interno deles... para cancelar a operação na Operadora, seria necessário o NSU do Host

Isso pode ser respondido em: procedure TACBrTEFDRespCliSiTef.ConteudoToProperty; 133 : fpCodigoAutorizacaoTransacao := Linha.Informacao.AsInteger; 134 : fpNSU := LinStr; E segundo o manual do SiTef, página 27 133 Contém o NSU do SiTef (6 posições) 134 Contém o NSU do Host autorizador (15 posições no máximo)

Estamos com planos de gerar uma versão do ACBrMonitorPLUS, "assinada"... acredito que isso tb possa ajudar em alguns casos...

Sim, pois não como assinar o XML todo, sendo que a propria assinatura faz parte do XML.. apenas o conteúdo do nó referenciado pela URI é assinado Acredito que você deva solicitar mais informações ao Provedor que consome esse WebService, a respeito do formato de assinatura dele...

Não consegui compreender o problema... Tudo que o ACBrTEFD faz, é capturar as informações do Log de retorno do Gerenciador da Transação TEF e interpretá-lo... Ative o Log detalhado em ACBrTEFD "LogDebug := True"...Verifique no Log gerado, como é o retorno do gerenciador TEF ao ACBrTEFD

Meu ambiente de desenvolvimento é Win10 64 bits (talvez não tenha compreendido bem a pergunta)... Mas atualmente uso o Lazarus 1.6, FPC3, 32 bits Fiz alguns testes de compilação em FPC3 64 bits, mas não uso em produção... Em relação a XMLSec, notei que é o ACBr é compatível com a versão 64bits. Existem relatos de usuários aqui do fórum que já estão usando Delphi 64bits com XMLSec em 64bits

Acredito que "ACBrMail1.Body.Text" somente é usado para e-mails em HTML (ACBrMail1.IsHTML := True)

Não tenho planos no momento... Fiz um trabalho recente para que os fontes do ACBr fossem compatíveis com a compilação 64bits no FPC... mas não tive tempo para ir mais longe... (tive outras prioridades)

Tente como: ACBrMail1.AltBody.Text := CorpoEmail.Text;

Nâo existe...

Repetindo... se você configurar de forma correta o ACBrSAT, isso não deve ser necessário... Veja o exemplo em SATTeste

Por favor informe um passo a passo de como reproduzir o problema no Demo do ACBr (SATTeste)

No seu caso, nem o instalador foi executado.. ele é gerado por outro programa: http://www.installjammer.com/ Uma opção seria tentar compilar o ACBrMonitorPLUS nessa máquina... ou tentar copiar manualmente o binário do MonitorPLUS... No geral eu sempre evito Ubuntu e todos derivados do Debian ... prefiro distribuições baseadas no RedHat como a CentOS

Marcos, Notei que as Tags que você deseja inserir, não fazem parte dos elementos previstos na especificação de: XMLSign: https://www.w3.org/TR/xmldsig-core/ Ou seja, provavelmente a XMLSec e CAPICOM nunca processem essas Tags. Entretanto o conteúdo assinado de um XML é o elemento que consta em <Reference URI="">.. Ou seja, não é todo o XML que é assinado, apenas o Elemento referenciado pela URI... Considere o XML em anexo. Eu modifiquei ele com o NotePad++ e adicionei manualmente as tags que você deseja (copiei e colei)... O ACBr continua validando o XML com sucesso, pois o conteúdo de "infNFe" não foi alterado... Agora, se você modifica qualquer coisa, dentro de "infNFe", verá que a assinatura fica inválida. Se você validar o XML no portal do SEFAZ, verá que está valido... mesmo no portal ele critica os elementos novos, que não constam no XSD da NFe https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx Minha sugestão é você anexar manualmente as tags, com o TimeStamp da máquina, antes de chamar a assinatura... 35160605481336000137550010000003411000003418-nfe.xml

Não é o Delphi... vc precisa descobrir qual a página de código usada pelo SAT Delphi 2009 usa Unicode (UTF-16)

Basta você configurar corretamente a página de código no ACBrSAT... que ele irá converter para a String nativa da sua IDE