arquivo mf e mfd apos primeira reducao

[gss200610]

2. O PAF-ECF deve, quando da emissão da primeira Redução Z de cada mês, comandar automaticamente a gravação de arquivo eletrônico no formato binário com dados extraídos do dispositivo de Memória Fiscal do ECF, relativo ao mês imediatamente anterior. 
3. O PAF-ECF deve, quando da emissão da primeira Redução Z de cada mês, comandar automaticamente a gravação de arquivo eletrônico no formato binário com dados extraídos do dispositivo de Memória de Fita Detalhe do ECF, relativo ao mês imediatamente anterior. 
4. Os arquivos eletrônicos a que se refere os itens 2 e 3 devem ser gravados no mesmo subdiretório onde está instalado o PAF-ECF com nome “xxxxxx_aaaammdd_hhmmss.MMM”, onde “xxxxxx” representa o número de fabricação do ECF, “aaaammdd” representa a data de geração do arquivo, “hhmmss” representa o horário de geração do arquivo e MMM, representa o tipo de arquivo, devendo o PAF-ECF assiná-los digitalmente criando um arquivo TXT com mesmo nome contendo uma linha com o registro tipo EAD especificado no requisito XXXI. 
 

resumindo: o arquivo gerado exemplo, hoje: 18/10/2016 , gero do mes 01/09 a 31/09/2016 é isso, nao como o do menu fiscal que gera o ARQ MFD GERAL DA ECF?

esse "MMM" , significa: MF, MFD, ficando o arquivo com extensao do tipo ai, exemplo:

xxxxxx_20161018_121700.MF

xxxxxx_20161018_121700.MFD ,me corrija se estiver errado

 

hoje uso as funcoes abaixo;

PafMF_ArqMF(sNomeArquivo +'.bin')

PafMF_ArqMFD(sNomeArquivo+'.bin');

ambas geram o arquivo de toda movimentacao do ecf. se estas nao foram as funcoes pra esse requisito e puderem postar uma dica aqui, agradeço

 

Editado 18 Outubro, 2016 por gss200610
FALTARAM DADOS

[Anderson Eccker]

Lembrando que esse requisito é obrigatorio apenas para o perfil "T",

Sim, deve ser gerado apenas do mês anterior ao da primeira redução Z do mês, se você esta fazendo a redução Z do dia 01/10/2016 deve gerar os binarios do mês 9. Isso eles testam certinho na homologação.

Quanto aos nomes dos arquivos é isso mesmo, e não esqueça de gerar o arquivo TXT, com a assinatura EAD.

 

[gss200610]

e quanto aos metodos para geracao no acbr por data, pode dar algum exemplo aqui?

[gss200610]

?

[Juliomar Marchetti]

Boa tarde!

confira no ato cotepe que ao final saiu correção de erratas. Será que isso não está lá

[gss200610]

olhando no demo do acbrecf seria esses

ACBrECF1.PafMF_MFD_Cotepe1704(edtDtInicial.Date, edtDtFinal.Date, PathArquivo) -> MFD

ACBrECF1.PafMF_ArqMF -> COMO GERAR POR DATA ESSE AQUI?

[Juliomar Marchetti]

Boa tarde

é necessário implementar!

[Pedro E. Braga]

Boa Tarde,

Realizei a implementação dos métodos de Download dos Binários da MFD por períodos nos modelos que contemplam a extração irei realizar os testes em alguns modelos que tenho na bancada, assim que tiver resultados posto caso seja necessário alterações.

ACBrSerial.7z

[Juliomar Marchetti]

No caso vi rapidamente mas tu tem outras implementações no meio que não informou aqui !

 

[Daniel Simoes]

Em 04/11/2016 at 17:52, Pedro E. Braga disse:

Boa Tarde,

Realizei a implementação dos métodos de Download dos Binários da MFD por períodos nos modelos que contemplam a extração irei realizar os testes em alguns modelos que tenho na bancada, assim que tiver resultados posto caso seja necessário alterações.

ACBrSerial.7z

Qual a natureza e a necessidade da modificação ?

[Pedro E. Braga]

Juliomar Marchetti,

Desconsidere as demais alterações diferentes dos métodos abaixo pois são alterações especificas que usamos para nossos projetos aki na empresa.

Considere apenas as implementações relacionadas aos métodos.

Procedure ArquivoMFD_DLL(NomeArquivo : AnsiString;  DataInicial, DataFinal : TDateTime); overload ;
Procedure ArquivoMFD_DLL(NomeArquivo : AnsiString;  COOInicial, COOFinal : Integer); overload ;

Daniel Simoes

A Inclusão dos Métodos visa atender ao requisito REQUISITO XII que pede a geração do arquivo binário referente ao mês anterior, em conversa com a UNIFIL, o binário deve contem apenas dados do mês a que se refere a Leitura da Memória Fiscal emitida quando o ECF disponibilizar a geração de forma Parcial.

Sendo assim foi implementado os métodos nas impressoras que possibilitam a geração de forma parcial assim possibilitando que os itens que falam da geração do arquivo binário seja atendidos.

Editado 7 Novembro, 2016 por Pedro E. Braga
Ajustes

[Daniel Simoes]

ok, obrigado pelas explicações.... em analise...

[gss200610]

esse metodo gera tanto o MF quanto MFD, pq vi ai que é pra MFD, e la no requisto sao dois arquivos MF E MFD.

tentei gerar o mfd aqui e deu erro xGerarRelatorioDaruma, uso DARUMA

[Pedro E. Braga]

Os métodos que passei geram apenas os arquivos MFD.

Os arquivos MF binários apenas a Epson tem um método para geração por período, assim não fiz a implementação visto que se a ECF não dispor se método para geração parcial pode ser gerado o arquivo completo segundo o orgão homologador.

Quanto a Daruma aqui testei em uma FS600 e hora gera hora da erro de comunicação ou outros erros como período maior que a ultima redução Z mesmo que o período seja de meses atrás, assim acredito que seja erro ou na MFD da minha ECF ou na DLL, passei pra Daruma o problemas mas ainda não obtive retorno da mesma.

Editado 8 Novembro, 2016 por Pedro E. Braga
Inclusão da resposta sobre geração da Daruma.

[gss200610]

estou tentando gerar , pois o metodo tem um parametro onde vc pasa a fnalidade do arquivo, e na daruma é MF. sempre codigo erro: 0

nao conseguir gerar de forma alguma mesmo se colocar mfd

 

ACBrECF1.ArquivoMFD_DLL(DateTimePicker1.Date, DateTimePicker2.Date, Edit1.Text,
    [docTodos], finMF);

[Pedro E. Braga]

A Assinatura dos métodos são onde passa o nome do arquivo binário a ser gerado e depois o período não é necessário passar finalidade, acho que os métodos estão bem confuso, acho que valeria um refactor para o nome dos métodos que geram o arquivos binários, mas ai fica a cargo do Daniel.

Procedure ArquivoMFD_DLL(NomeArquivo : AnsiString;  DataInicial, DataFinal : TDateTime); overload ;
Procedure ArquivoMFD_DLL(NomeArquivo : AnsiString;  COOInicial, COOFinal : Integer); overload ;

[gss200610]

observei os fontes: acbrecfdaruma

 

    Ativo     := False;
    Tipo      := 'DATAM';
    DtInicial := FormatDateTime('ddmmyyyy', DataInicial);
    DtFinal   := FormatDateTime('ddmmyyyy', DataFinal);
    OnLine    := (OldAtivo) or ((TACBrECF(fpOwner).Modelo = ecfEscECF) and (TACBrECF(fpOwner).Ativo));

    // utilizar o modo on-line quando a impressora estiver ativa e o off-line quando não estiver
    if OnLine then
    begin
      Resp := xrGerarRelatorio_ECF_Daruma(Relatorio, Tipo, DtInicial, DtFinal);

 

debuguei os parametros estao chegando ao metodo, mais o rGerarRelatorio_ECF_Daruma era pra funcionar. pois tenho um projeto aqui que 

fiz pra testar via loadLibrary pra gerar CAT-52 e funciona muito bem, nao entendir o pq sempre codigo erro igual a zero com acbr.

 

[Pedro E. Braga]

Os métodos implementados utilizam as chamadas para "rEfetuarDownloadMFD_ECF_Daruma" da DLL, acredito que esteja utilizando os métodos incorretos, não sei que já foram incorporados aos fontes principais do projeto.

[gss200610]

bom nao sei se vem ao caso, mais se fosse possivel queria implementar os metodos de tratamentos de retornos pra daruma. assim

o metodo de erro:  eInterpretarRetorno_ECF_Daruma  retornaria a msg conforme daruma mesmo.

seria ate mesmo uma forma de contribuir. 

Editado 8 Novembro, 2016 por gss200610

[gss200610]

em anexo arquivos com modificacoes para ARQUIVO MF com geracao do txt assinado com ead.

fiz algumas melhorias na unit ACBRECFDARUMA.PAS ( tratamento dos erros extendidos );

adicionei o overload na unit acbrecf para gerar o MF:

 

    procedure PafMF_ArqMF(const NomeArquivo: String;
                          DataInicial, DataFinal : TDateTime;
                          Assinar: Boolean = True );overload;

 

 usa o metodo:  

   ArquivoMFD_DLL(DataInicial, DataFinal, NomeArquivo,
                      [ docTodos], finMF);
 

 

procedure TACBrECF.PafMF_ArqMF(const NomeArquivo: String;
DataInicial, DataFinal: TDateTime;Assinar: Boolean  );
var
  EADStr: String;
begin
  if (not fsAtivo) then
     raise EACBrECFNaoInicializado.create( ACBrStr(cACBrECFNaoInicializadoException) );

  Self.ArquivoMFD_DLL(DataInicial, DataFinal, NomeArquivo,
                      [ docTodos], finMF);

  if not FileExists(NomeArquivo) then
    raise EACBrEADException.CreateFmt('Arquivo MF: "%s" não foi gerado', [NomeArquivo]);

  if Assinar then
  begin
    // assinar o arquivo baixado da impressora
    EADStr := 'EAD' + GetACBrEAD.CalcularEADArquivo(NomeArquivo);

    // gravar o arquivo texto com a assinatura EAD
    WriteToTXT(ChangeFileExt(NomeArquivo, '.TXT'), EADStr, False, True);
  end

end;

ACBrECF.pas

ACBrECFDaruma.pas

[Daniel Simoes]

Olá pessoal,

Desculpem-me pela demora na resposta... Ainda estou analisando as modificações referente a geração da MFD Binária, por periodo...

Até onde li da lei atual do PAF-ECF, apenas o arquivo Binário passou por modificação, mas vou debater isso com minha equipe...

No momento, apliquei as seguintes modificações:

Data 13/11/2016
-- ACBrECF, ACBrECFClass --
[*] Método "CancelaDescontoAcrescimoItem", modificado inserindo novo parâmetro:
    "TipoAcrescimoDesconto: String = 'D'"
[*] Método "GetRodapePaf" modificado para atender ao requisito XXXVI do PAF-ECF
[*] TACBrECFRodape modificado inserindo as propriedades "Placa" e "QtdeKM"

-- ACBrECFBematech, ACBrECFEpson, ACBrECFFiscNET, ACBrECFSwedaSTX --
[+] Adicionado suporte ao método: "CancelaDescontoAcrescimoItem"

-- ACBrECFEscECF --
[*] Método "CancelaDescontoAcrescimoItem" modificado para suportar o parâmetro
    "TipoAcrescimoDesconto"

-- ACBrECFFiscNET --
[*] Método "TraduzirTag", modificado para suportar modelo "URANO/1FIT LOGGER"

(por: Pedro E. Braga) - http://www.projetoacbr.com.br/forum/index.php?showtopic=32980 

[Daniel Simoes]

Prezados... notei uma imensa confusão nos seguintes métodos:

procedure PafMF_Binario(const PathArquivo: String);
Procedure ArquivoMF_DLL(NomeArquivo: AnsiString);
Procedure ArquivoMFD_DLL(NomeArquivo: AnsiString); overload;  

Procedure ArquivoMFD_DLL( DataInicial, DataFinal : TDateTime;
   NomeArquivo : AnsiString; Documentos : TACBrECFTipoDocumentoSet = [docTodos];
   Finalidade: TACBrECFFinalizaArqMFD = finMFD ) ; overload ;
Procedure ArquivoMFD_DLL( ContInicial, ContFinal : Integer;
   NomeArquivo : AnsiString; Documentos : TACBrECFTipoDocumentoSet = [docTodos];
   Finalidade: TACBrECFFinalizaArqMFD = finMFD; TipoContador: TACBrECFTipoContador = tpcCOO) ; overload ;

Vou aplicar as seguintes modificações, que irão quebrar a compatibilidade... mas que acho necessário, para ficar bem claro a finalidade de cada procedure

TACBrECF.PafMF_Binario -> Será removido... pois hoje ele cria um arquivo binário e assina o próprio (o que é errado)

ArquivoMF_DLL(NomeArquivo: AnsiString); -> Será renomeado para: ArquivoMF_Binario_DLL(NomeArquivo: AnsiString; DataInicial, DataFinal: TDateTime);
ArquivoMFD_DLL(NomeArquivo: AnsiString); -> Será renomeado para: ArquivoMFD_Binario_DLL(NomeArquivo: AnsiString; DataInicial, DataFinal: TDateTime);

 

ArquivoMFD_DLL e ArquivoMF_DLL, continuam como estão... eles não geram arquivo binário... mas sim um TXT....

 

[Pedro E. Braga]

Daniel concordo plenamente com essa alteração, pois geram bastante confusão mesmo os métodos, apoio as alterações descritas.

[gss200610]

se nao for incomodo, tem previsao de quando sera disponibilizado no svn, pois irei homologar em dezembro. e ja estou testando meu paf todo

[Daniel Simoes]

Estou trabalhando nisso, nesse momento...