EMBarbosa

Olá Sérgio, Fique a vontade para compartilhar aqui mesmo o código. Depois de análise ele pode ser integrado ao projeto ACBr.

Se em algum lugar você usar o DecimalSeparator, então ele altera a formatação do sistema. Talvez por exemplo ao montar um Select em SQL.

Respondendo suas perguntas iniciais: 1) Tanto faz, desde que ela seja encontrada pelo seu executável. 2) Não. Mas você tem que garantir que seu executável encontre a versão correta e não uma versão diferente da que ele espera. 3) Não tem necessidade.

Talvez... Mas se for para habilitar o string em unicode quando estiver definido a diretiva UNICODE igual você fez no seu código, seria melhor declarar as variáveis como string logo de uma vez. Pois se não estiver definido o UNICODE, String já é igual a AnsiString e não há nenhuma necessidade de definir strRegistroI200 como AnsiString...

Ei Elton, se o P200 for realmente filho do P010 o Guia esta errado sim, pois o P010 ta como nível 2 e o P200 tb como nível 2, isso pela hierarquia os dois seriam filhos do P001 que é o nível 1. Para ele ser filho do P010, então no guia teria que estar P200 como nível 3, igual ao P100. Ah puxa, me confundi na hora de escrever. Era isso que eu queria dizer.

Lá vamos nós outra vez.... O C481 e o C485 DEVEM permitir o valor vazio. Favor fazer pesquisa no fórum. viewtopic.php?f=23&t=5624&p=29760&hilit=C481#p29704

Sobre que componente ou parte do projeto você está falando?

1a divergência no Guia Pratico diz que o P200 é nível 2, então ele deve ser filho do P010, como tava antes no SVN, será que no Guia ta errado? Preciso dessa confirmação. O guia não está errado não. Ele é mesmo filho do P010 que é o registro de estabelecimento.

Olá analista.edilson, Esse é só um dos problemas de postar a mesma coisa em vários lugares diferentes. Ainda estou esperando sua resposta nesse tópico que você mesmo criou:

Eu acho que seu problema seria mesmo nas chamadas do LFILL, RFILL e semelhantes. Elas estão retornando string, mas as variáveis internas dos componentes (strRegistroI200 por exemplo) estão definidas como AnsiString. Você poderia usar essa diretiva de compilação no arquivo ACBrTXTClass.pas e resolver seu problema para todos os componentes de uma vez só, mudando o retorno delas para AnsiString ao invés de apenas String. O que acha?

Por favor alcir Crie um tópico novo para uma dúvida nova. MODERAÇÃO: TÓPICO DIVIDIDO

Já vou dizendo que não tenho muita experiência com essa área de acesso SOAP e afins. Mas da ajuda que você mesmo passou o link, veja: Ou seja, parece que não vai conseguir em run time fazer isso. Não com essa propriedade.

Isso. Verifique se resolve. Se resolver a gente pode pensar em algo que não atrapalhe o desenvolvimento em outras versões.

Qual a versão do Delphi que está usando. Verificou se não é algum erro de Unicode? Se não for, me parece erro de memória. Você consegue reproduzir o acontecido em outras máquinas? Consegue reproduzir algo parecido com o DEMO?

Veja o demo na pasta exemplos.

Há uma boa possibilidade de você estar alterando os parâmetros do sistema para separador de decimal (DecimalSeparator) e formato de datas e isso estar influenciando na escrita do componente.

Criptografar os dados na tabela de log seria uma ajuda. Mas quanto a se daria certo, seria melhor verificar com os homologadores.

Isso.

O código aqui está incorreto. Não se deve usar o FormatCurr dentro do código do ACBrPAF_D_CLASS deste jeito. É exatamente para isso que serve o LFill. LFill( FormatCurr('###,##0.00', VLT_DAV), 8, '0') + //LFill(VLT_DAV, 8, 2) +

Seria melhor verificar a data especificada no Bloco 0 ao invés de usar a função Date().

Essa é uma maneira que eu não tinha considerado ainda. O problema é que se alguém apagar o registro na tabela de DAV e depois ir na tabela LOG_DADOS e apagar o registro correspondente, o programa não vai conseguir acusar nada.

No fórum também há as diferenças dos dois ATO COTEPEs http://www.djsystem.com.br/acbr/forum/viewtopic.php?p=32336#p32336. Mas não estão as diferenças dos testes.

Acho que esse post está no lugar errado. Não sei se os usuários do NFS-e viram esse post aqui.

Pois é, mas não teria nem sentido eles recusarem isso.

Corrigindo: a Bematech faz o suporte a USB através da DLL.