Régys Silveira

Os dados para a recomposição do GT estão na ER e são testados pelo homologador geralmente, existe inclusive um teste específico para a recomposição do GT. Qual é a sua dúvida, não consegui entender o ponto onde quer chegar.

Já estamos verificando esse problema.

Estarei verificando com o Isaque o andamento da sua pendência.

A autenticação existia somente nas impressoras matriciais, nas impressoras MFD não existe mais. Quanto ao comprovante não fiscal o exemplo está no DemoECF dentro da pasta exemplos\ACBrECF.

Você foi contato por e-mail?

Depende do estado, aqui em MG por exemplo é obrigatória a redução Z automática. O caso ai do mikromundo era que ele não teve movimento no dia anterior, portanto, a ECF vai estar livre no outro dia, já que não houve movimento para que ela ficasse pendente de Z.

Retorno em branco geralmente são problemas de conexão, existem tópicos no fórum tratando desse assunto.

ACBr está atualizado? Pergunto porque já tem um tempo que ele trata a mensagem pegando diretamente da dll nestes caso. Veja também se o arquivo bematech.ini está dentro do windows ou dentro do system32. Verifique se todas as dlls que a dll da bematech precisa estão junto da bemafi dll.

Como disse anteriormente, quem controla como vai ser impresso o identificação que é passada ao método identificaPafECF e a impressora, o que você pode fazer e não usar ele e passar a usar o MD-5 das informações de rodapé, veja no DemoECF como fazer isso.

Isso depende de cada modelo de impressora, porque é o ECF que controla como vai ser impresso as informações do IdentificaPAfECF.

o PathDLL é somente para dizer onde está a dll do fabricante, o projeto ACBr utiliza elas para a geração de arquivos MFD da impressora fiscal e somente para isso, o restante e tudo feito via comunicação direta com o ECF. Não existe alteração nenhuma no código.

Veja o DemoECF aba menu fiscal e o Demo ACBrPAF , ambos estão dentro da pasta ACBr\Exemplos.

Já existem tópicos discutindo esse mesmo assunto. Você deve ter adiciona um path da NFe antiga no library path.

Vá em "options" do pacote, escolha "description" e em "build control" marque "rebuild as need" e faça o teste.

Esse método utiliza a dll da bematech para gerar o arquivo, verifique se suas dlls estão atualizadas e para a mp4000 tem algumas dlls específicas.

Testei todos os EANs postados utilizando o método: "ACBrValidadorValidarGTIN" da unit "ACBrValidador" e todos passaram como válidos. Tem certeza que o seu ACBr está atualizado? se sim faça o seguinte apague o arquivo ACBrValidador e faça novamente a atualização, o SVN vai baixar novamente o arquivo, dai faça novamente o teste.

Basta alterar os 14 por 11 no pacote.

Foi feita uma atualização no cálculo do GTIN e testado com uma massa de códigos de barra bem grande. Teu ACBr está atualizado?

poste aqui os arquivos alterados que faremos a conciliação.

Já existem tópicos discutindo este assunto, faça uma busca no fórum.

Fiz o acerto e já enviei para o repositório, obrigado pela ajuda.

Estive olhando os fontes, está retornando essa data porque ainda não foram implementados todos os dados para este método, precisa da documentação da impressora para terminar de implementar.

Tente utilizar o modelo "ecfFiscNET" ao invés do modelo "ecfEpson" e faça o teste.

verifique se os componentes não estão na lista de exceções, isso tem que ver pelo registro do windows nas chaves do delphi procure por "Disabled Packages".

Estranho porque testes de desligamento do computador não imprimem, somente mostram a mensagem, seria bom verificar isso com o pessoal da SevenPDV a menos que isso tenha sido mudado.