EMBarbosa

Tivemos um problema com a internet aqui na cidade... Só conseguiram resolver hoje. O problema da ordenação do registro 60M foi resolvido verificando, além da data, também o CRZ. Já para organizar os filhos de reduções no mesmo dia, foi necessário utilizar de forma manual as propriedades internas do Registro60M a saber Regs60A, Regs60D e Regs60I. Assim, ao invés de, por exemplo, criar um registro 60A e adicioná-lo no Registros60A do ACBrSintegra, a pessoa cria os registros para aquele 60M específico, e o adiciona no Registros60M.Regs60A. O mesmo vale para Registros60D e Registros60I.

Como assim?

Pessoal, Detectei um erro na geração do arquivo Sintegra pelo ACBrSintegra quando há mais de uma Redução Z no mesmo dia. O componente não consegue ordenar corretamente caso criemos os registros e deixemos que ele próprio relacione os registros 60A e 60M devidos. Assim é necessário fazer esse relacionamento manualmente. Mas caso usemos as propriedades existentes para isso, o componente não cria os registros 60A. O mesmo ocorre com os registros 60D, 60I e 60R. Fiz uma alteração no componente para corrigir esse erro, mas estou ainda testando para ter certeza que não vai alterar o comportamento para quem já faz uso do componente. Foi necessária alteração no modo de criação e destruição interna dos registros para que não houvesse leak de memória, mas isso não deve alterar em nada o código dos usuários atuais do ACBrSintegra. Apenas quem precisar atender o caso de mais de um registro 60M no mesmo dia é que deverá alterar o código. Achei por bem avisar a todos que, assim como eu, talvez não tenham percebido essa limitação no componente. Devo terminar os testes amanhã e fazer o commit.

Você configurou a versão do validador no componente? Qual está configurado?

Não sei agora, mas até a pouco tempo atrás, ainda era melhor homologar no XP por causa do TEF. Mas sobre o ECF, use o que o seu programa funciona e não dê problema com a comunicação com o ECF. Principalmente ao tentar gerar os arquivos do Menu Fiscal que vão fazer acesso à DLL do fabricante.

Não precisa abrir uma nova aplicação se usar a opção Menu -> Component > Import WSDL

Acabei de fazer um teste aqui com o Validador 2012 e deve ser assim:

Tem certeza que vem desabilitado? Numa máquina que temos aqui, pareceu normal. No Delphi XE tem até duas maneiras de entrar nele: Menu -> Component > Import WSDL ou Menu -> File > New > Other > Delphi Projects or C++Builder Projects > WebServices > WSDL Importer Sendo que a segunda opção exige que exista uma aplicação já criada antes que habilite o comando.

O maior problema não é ter um Windows 64 bits, mas compilar para 64 bits. Você ou qualquer outrapessoa que possua o Lazarus ou Delphi que permita compilar para 64 bits pode ajudar da seguinte maneira: 1) Compilar os programas de exemplo para 64 Bits. 1.1) Reportar quaisquer erros de compilação, se possível com sua correção. 2) Executar os programas de exemplo no Sistema operacional de 64 bits e verificar seu funcionamento se está de acordo com a versão 32 bits. 2.1) Reportar quaisquer erros ou divergências no funcionamento, levando em conta o funcionamento da versão de 32 bits. Assim, a pessoa pode testar todos os componentes ou projetos mesmo que não utilize o componente em questão.

Vou verificar e dou um retorno.

Daniel, obrigado pelo retorno. Mas não sei se entendi como o código poderia quebrar a compatibilidade com outros usuários. Também acho que essa parte da geração do Requisito X usando os componentes não está bem clara. Se puder me dar uma resposta um pouco mais elaborada. Se for o caso, eu mudo aqui a minha implementação para não ter que usar uma versão do ACBrPAF diferente da do projeto.

Anexe o log do ACBrECF.

Realmente. Por um momento achei que estava falando do SPED Fiscal. No EFD Contribuições (SPED Pis/COFINS), esse erro está relacionado às opções que você muda dos registros 0110 e seus anteriores. Por exemplo: Seu registro 0110 atual é o seguinte: Mude a linha para o seguinte e tente validar: A mensagem de erro é totalmente diferente.

Não tem uma regra no Discado dizendo que o cartão sempre deve ser a última forma de pagamento?

Ué, no "Perfil C" vários dos registros do bloco C não devem ser informados mesmo...

Então sugiro que envie um report para o pessoal da receita corrigir o erro. Veja o link Fale Conosco no site do SPED.

Parabéns. Bom trabalho.

Pois é, se houver retorno ou dúvidas a gente pode investigar. Mas não estou lembrado de nada no momento. Penso por alto, me vem duas coisas à mente que poderiam dar problemas: 1) A biblioteca Synapse, para acesso a porta paralela. Que não me lembro se estava bem testada para 64 bits. 2) Algum acesso/alocação/liberação à memória, arquivo ou algum protocolo que seja feito em bloco de bits. Mas como disse, o melhor seira talvez compilar e executar todos os DEMOS e verificar se o retorno de todos é igual ao deles compilados para 32 bits. É trabalhoso, mas não precisa de muito conhecimento técnico dos componentes.

Deixa ver se entendi. Quer dizer que o validador do Linux não conseguiu validar o arquivo mas o do Windows validou o arquivo corretamente?

No momento essa funcionalidade não existe.

Integração com xml não tem nada ainda... O ACBrSintegra apenas é um componente para ajudar a gerar o arquivo no layout correto.

A não ser que seja proposital, memory leaks não são normais.

Ei Gr@ç@, não tivemos nenhum retorno sobre isso ainda. Eu acredito que se houverem os problemas sejam muito poucos. A ideia seria alguém começar compilando os DEMOS e fazer testes neles. Não sei se alguém já fez isso.

Eu ia sugerir você verificar justamente se o arquivo não foi salvo com codificação UNICODE ao invés de ANSI. Isso costuma atrapalhar...

O link não está abrindo aqui.