Régys Silveira

Serviços não são gerados, mas é bom sempre ver com o a unidade homologadora antes de implementar, cada homologador tem um ponto de vista em determinados assuntos.

Entendam que erros de rejeição não são causados pelo ACBr mas sim retornados pelo webservice.

O instalador não está atualizado, somente as pastas no ACBr.

Como o colega disse anteriormente o ean vazio voltou a funcionar, agora fica o ean válido que dá como inválido, esse eu testei aqui é ainda não funciona, não em ambiente de homologação de MG, mas no ambiente de produção nenhum cliente reclamou ainda.

Você troca o número de lote a cada envio? porque estou vendo que esse último está 219 como no primeiro.

Olha, eu fiz testes aqui de envio e está tudo funcionando corretamente, mas eu estou testando com MG que é meu estado, pode ser que algo esteja errado no webservice do RS, faça o seguinte, aqui em MG temos um serviço onde enviamos o XML e relatamos o erro para eles verificarem se procede ou não e reportarem o que deve ser feito ou arrumarem o webservice, ai no RS deve ter algo parecido. Você pode também digitar os dados desta nota no emissor gratuito, gerar e verificar se acontece o mesmo erro, se sim realmente é problema no webservice, se não verifique o que está diferente do teu XML.

Antes de postar por favor efetue uma busca no fórum viewtopic.php?f=20&t=3604

Olha, parece estar tudo correto no xml, tente atualizar o ACBr, recompilar tudo e atualizar os schemas, tente enviar e veja se continua ocorrendo.

Fiz a validação do EAN e ele realmente é válido, mas o envio da nota retorna o codigo de rejeição para o cEAN, parece que tem algo de errado no webservice da receita.

Você efetuou as atualizações de schema? Se não baixe os novos schemas no site da nota fiscal eletrônica: http://www.nfe.fazenda.gov.br/portal/li ... wLvLUSmU8=

Talvez os dcus compilados estavam desatualizados.

Minha rotina de emissão de redução Z. class procedure TfrmDiaFechamento.EmitirReducaoZ(const ADataHora: TDateTime); var TimeOutImpressora: Integer; begin // aumentar o timeout para evitar erros durante a impressão da redução Z // geralmente causados na impressão da fita de codigos 3D no final MensagemControl.ShowAguardar('Aguarde a impressão da redução Z...'); dtmPDV.TEF.BloquearMouseTeclado(True); TimeOutImpressora := dtmPDV.ECF.TimeOut; try dtmPDV.ECF.TimeOut := 600; // 10 minutos dtmPDV.ECF.ReducaoZ(NOW); MensagemControl.ShowAguardar('Lendo informações do fechamento do dia atual...'); GravarReducaoZUltima; finally dtmPDV.TEF.BloquearMouseTeclado(False); dtmPDV.ECF.TimeOut := TimeOutImpressora; end; end; [/code] Como está configurado meu ACBrECF: IntervaloAposcomando = 0; todas as outras propriedades o padrão do ACBrECF, exceto configurações de porta, modelo e velocidade que variam de impressora para impressora.

Problemas durante a impressão do código tem a ver com o tempo de timeout, basta aumentar ele. ACBrECF.TimeOut, aqui como eu já postei, eu coloco 600 que equivale a 10 minutos. Tenho clientes com fitas de código de mais de 1 metro e nunca ocorreu o estouro do tempo, mesmo na MP2100 que são mais lentas que a MP400.

As validações são feitas pelos schemas e os mesmos são disponibilizados pela receita federal, o ACBr somente valida os arquivos utilizando os schemas. Efetuei testes de envio de notas com e sem Ean utilizando os novos schemas, ACBr atualizado e Capicom nos ambientes de homologação e produção de MG, está tudo funcionando corretamente.

Em que momento especificamente, durante a impressão do relatório de redução Z ou durante a impressão da fita de código que é impressa após a redução Z?

Está classe se encontra em "ACBrEPCBloco_0.pas" que está no diretório "\Fontes\ACBrSPED\ACBrSPEDPisCofins". Aqui compila normal, alguma coisa deve estar errada ai com teus fontes, está classe pertence ao Sped Pis/Cofins e o arquivo que está chamando ela pela mensagem que você passou e do Sped Fiscal. [DCC Error] ACBrEFDBloco_0_Class.pas(76): E2003 Undeclared identifier: 'TRegistro0110' Inclusive nessa linha 76 que é apontado o erro não tem nada referente a está classe. Exclua o diretório "\Fontes\ACBrSPED\" e efetue a atualização, assim o tortoise vai baixar novamente todos os diretórios para todos os SPEDs.

Utilize o ACBrValidador para validar o EAN, veja o exemplo de como utilizá-lo em "\Exemplos\ACBrValidador".

Não há a necessidade dessa impressão, basta digitar e gravar no banco para gerar os arquivos sintegra e sped a não ser que você tenha algum controle qualquer, dai a impressão teria que ser feita por relatório gerencial e efetuados os controles conforme manda a ER.

Quando o erro acontece o ECF ainda está imprimindo alguma coisa?

O parâmetro e data/hora e serve para acertar a data/hora da impressora, lembrando que existem algumas restrições quanto a esse acerto. Aqui eu sempre utilizo a data e hora atuais do computador já que eu controlo a diferença de horários entre a impressora e o ECF, assim os dois sempre andam juntos e quando o computador altera a hora por algum motivo qualquer dando uma diferença muito grande eu sei que aconteceu e tomo as devidas providências.

Foram feitas as devidas correções e já disponibilizadas no repositório.

Seu ACBr está desatualizado, favor atualizá-lo. Caso continue acontecendo, apague o arquivo e efetue novamente a atualização, pois alguma coisa pode estar "travando" o arquivo para atualização. Estes métodos foram movidos para outra unit, porque são utilizados por outros componentes além da nota eletrônica, fizemos isso com o intuito de diminuir as dependências entre componentes quando necessário.

Veja que o instalador do monitor nem sempre anda junto dos fontes, então algumas implementações novas podem não ser refletidas no mesmo tempo que são implementadas no código, por isso te dei a idéia de compilar diretamente dos fontes.

Juliana, Atualize teu ACBr e recompile como o Italo disse, andamos fazendo algumas realocações no código para evitar a duplicação de código e estes dois métodos foram alterados de lugar, uma atualização e recompilação vão ajudar.

Quanto a instabilidade é estranho você estar passando por isso porque nunca foi reportado algo do tipo, salvo quando existem erros de configuração. Se você debugar realmente apareceram exceptions silenciosas que no processo normal não aparecem, uma boa saída e tentar utilizar o ECFTeste na pasta exemplos e verificar se ocorrem as mesmas instabilidades. Para o tratamento de retornos você pode utilizar os eventos que existem no componente e o restante quando ocorre erro é gerado uma exceção. Faça os testes gravando o log, assim se continuarem acontecendo erros, você pode postá-lo aqui e tentaremos te ajudar a resolver. Aqui na empresa utilizamos o ACBr já homologado para o paf-ecf e TEF e em produção a um bom tempo, com impressoras variadas (Bematech, Daruma, Epson, Sweda) e tudo funciona perfeitamente. Qualquer necessidade de ajuda recorra ao fórum, a "turma" está ai para ajudar.