EMBarbosa

Adicionei na minha lista de afazeres.

Não existe esse campo no componente. Mas não seria muito difícil adicionar. Acredito que deveria ser adicionado na classe TACBrCargaBalNutricional para que possa ser tratado no método TACBrCargaBal.PreencherToledo.

Veja esse post: Em especial a parte que diz:

Eu entendi o que você quis dizer... O problema é que o SPED ECD não parece ter um campo definindo o "layout". Daí se formos alterar o componente para isso temos um impasse. O componente deve gerar o arquivo de acordo com o leiaute da época ou de acordo com o leiaute atual? Se for de acordo com o leiaute atual, isso geraria dificuldades quando surgir um novo leiaute, pois ao implementá-lo, deixaríamos de suportar o leiaute anterior no mesmo instante. Isso me parece criar mais problemas do que ajudar. Estou enviando ao SVN uma alteração que valida se está gerando um arquivo de substituição, conforme o item "1.12. Substituição do Livro Digital Transmitido" do Manual. Isso quer dizer, que ele vai validar se existe algum registro J801 ou se no registro 0000 o campo (IND_FIN_ESC = '1 - Substituta'). Nesse caso ele gera usando a versão mais atual do leiaute. Veja se isso resolve o seu problema. Está no SVN na revisão 17671.

Eu também fiquei com dúvida nessa parte. Sugiro que você faça um passo a passo descrevendo o problema pra que possamos entender.

Outra sugestão é verificar se nos logs de comunicação estão sendo enviados os dados corretos para a impressora.

Olá Lucas. A própria descrição da resposta está admitindo que pode ser uma falha temporária dos servidores. Chegou a verificar?

Bom dia. Por favor, seja um pouco mais específico. De qual registro estamos falando? Qual é o erro apresentado?

Creio que houve algum equívoco. O leiaute do registro J930 com 12 campos é o leiaute 5 e posteriores, que abrange o período do ano calendar de 2016. Você pode conferir fazendo donwload dos manuais na página do SPED: http://sped.rfb.gov.br/pasta/show/1569 O Manual de Orientação da ECD, na versão Anexo ao ADE Cofis nº 34/2016 é o que contém as versões 1 a 4. Abaixo estou anexando com os devidos destaques de página, versão e número de campos.

Se a dll for CliSiTef32I.dll, então me parece que sim...

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 17657. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Tentou o contato com a Software Express/SkyTef/Certificadora? Eles geralmente respondem rápido esse tipo de questão.

Me parece que está relacionado a esse tópico abaixo. Você chegou a ver?

É o mesmo exemplo do NF-e. ACBr\Exemplos\ACBrDFe\ACBrNFe\

Hmm... Acho que estamos com ideias diferentes. Eu não vejo o Application.onException com o objetivo de tratar erros num form específico. Eu o vejo como um modo pra tratar exceptions que fugiram todos os tratamentos nos forms. Nesses casos, o ideal é você registrar o CallStack da exception, de modo que você vai saber exatamente não só onde aconteceu, mas também o percurso que o código fez pra gerar o erro. Fica mais estável porque você estava sobrescrevendo o Application.onException. Você pode remover o código que faz isso e daí usar um TApplicationEvents para cada form como queria. O detalhe é que nesse caso, todos os forms abertos vão receber o evento. Daí você deve usar o método CancelDispatch para impedir a propagação pros próximos forms. Queria acrescentar que esse modelo eu nunca trabalhei... mas não me parece vantajoso.

Veja a parte do código que carrega a dll como eu mencionei antes "LoadDLLFunctions". Você vai ver que ele menciona o caminho da DLL: // Concatena o caminho se exitir mais o nome da DLL. sLibName := sLibName + CACBrTEFD_CliSiTef_Lib; Essa constante "CACBrTEFD_CliSiTef_Lib" usada no nome da DLL é definida por volta da linha 90 no arquivo que você anexou: ... {$IFDEF LINUX} CACBrTEFD_CliSiTef_Lib = 'libclisitef.so' ; {$ELSE} CACBrTEFD_CliSiTef_Lib = 'CliSiTef32I.dll' ; {$ENDIF} ...

Então parece que está faltando executar o código da procedure "LoadDLLFunctions". Veja também o método TACBrTEFDCliSiTef.Inicializar;

Não quis dizer que o "form padrão" fosse criado, mas sim os forms que herdam dele que possuem o mesmo evento onCreate que você descreveu acima. Dito isso: Creio que não, porque esses outros eventos são de cada form. Mas o evento Application.OnException é da aplicação (Application). Application é na verdade uma variável global da aplicação. Por isso, toda vez que você faz: Você está na verdade sobrescrevendo o mesmo evento com uma procedure do form que foi criado agora.

Que bom que no seu caso não precisou reinstalar. O motivo de não estar mais marcada a opção não é a atualização do ACBr. Na verdade, geralmente é o apresentado no tópico que eu mencionei acima.

Olá. Eu particularmente gosto de analisar sugestões criativas como a sua. Acho que nos acrescenta muito. Dito isso, tenho os seguintes comentários: hmm... talvez o seu problema esteja em colocar o TApplicationproperties no seu FormPadrao. Você deve ter apenas uma instância do TApplicationProperties na sua aplicação. Geralmente coloca-se num DataModule que não vai ser criado e destruído mais de uma vez. O problema ao fazer isso é que cada form criado sobrepõe o Application.OnException do Form anterior. Isso pode levar a uma inconsistência. Acredito que se você criar um dois forms em sequência, o segundo for destruído e então o primeiro gerar uma exception você terá um AccessViolation.

Verifique exatamente onde a exception é levantada. A partir daí, veja qual o caminho que o código está seguindo pra levantar a exception.

Verifique as propriedades Style, AutoComplete e ReadOnly. Me lembro que em conjunto essas propriedades podem ter esse comportamento que você quer.

Sim. Essa escala afeta a contagem do DPI para a aplicação rodando.

Se essa primeira tela é uma tela do método ADM então ele foi inicializado mesmo. Nesse caso, restam duas possibilidade. A implementação está com problemas O seu SiTEF não está preparado para isso. A possibilidade 1 pode ocorrer porque já está desatualizada, continha erros ou o merge feito em sua máquina não está correto. Você pode tentar fazer um debug e verificar exatamente onde a exception está sendo levantada. A possibilidade 2 pode indicar que você não entrou em contato com a Software Express (ou outra credenciadora) para habilitar o seu SiTef para esse tipo de operação. Veja nas mensagens anteriores dos outros usuários que alguns passos são necessários.