Bloco VII - dúvidas

[wrmedeiros]

Pessoal,

O homologador me explicou rapidamente esse Bloco 7 do roteiro do PAF-ECF, mas confesso que não estou entendendo.

Qualquer alteração NO BANCO deverá gerar um caracter "?" ????

Alguém tem mais detalhes?

Estou lendo o roteiro, mas não dar pra entender muita coisa (página 90 do roteiro v1.5).

[Juliomar Marchetti]

Boa noite

isso mesmo meu amigo se o registro for modificado com um gerenciador de banco,

quando gerar o movimento por ecf deve-se gerar alguns registros com o caracter ??

mas no componente ACBrPAF já tem nos seus registros uma propriedade RegistroValido.

para tratar os dados a maioria tem utilizado um campo MD-5 com os campos a serem verificados

espero ter lhe ajudado com essa explicação

[wrmedeiros]

Oi Juliomar!

Obrigado pela resposta meu amigo!

Uso o ACBrPAF, mas não conhecia essa propriedade.

Fiz algumas buscas no Google, e encontrei bastante coisa no forumweb... amanhã vou dar uma lida:

http://www.google.com.br/search?q=paf-ecf+bloco+vii

Mais uma vez, obrigado pela dica. Vou fazer um UPDATE aqui no meu repositório do ACBr e fazer testes.

(o banco do PDV é Firebird, e o pessoal falou que é bem fácil fazer essa verificação de mudança nos registros via trigger).

[EMBarbosa]

Realmente com as variáveis de contexto, dá pra fazer essa verificação de forma simples no Firebird. Tem um tópico lá no FórumWeb explicando tudo.

[Daniel Simoes]

Pode ser que ajude...

O método abaixo calcula um Hash baseado em todos os campos de um DataSet, menos os campos informados na lista de Campos a ignorar

Uses ACBrUtil ;

...


function CalcHashDataSet(const ADataSet : TDataSet ; Chave : AnsiString = '';

   IgnoreFields : TSetOfByte = [] ) : Word ;

var

   NFields, I : Integer;

   Buffer : AnsiString ;

begin

  Buffer  := '';

  Result  := 0;

  NFields := ADataSet.FieldCount - 1 ;


  For I := 0 to NFields do

  begin

    if (not (I in IgnoreFields)) and

       (LowerCase( ADataSet.Fields[I].FieldName )  'hash') then

       Buffer := Buffer + ADataSet.Fields[I].AsString;

  end ;


  if Chave  '' then

     Buffer := StrCrypt( Buffer, Chave );


  Result := StringCrc16( Buffer ) ;

end;

[/code]


Exemplo: 

   sqlDocumento.FieldByName('HASH').AsInteger := CalcHashDataSet(DataSet, 'SuaChave' );

[wrmedeiros]

Obrigado pela sugestão Daniel.

Estou lendo e comentando o PDF do roteiro antes de começar a desenvolver... quando concluir eu informo como fiz.

[Fabrício G. Araújo]

Amigos,

Venho informar a todos para uma atenção especial ao BLOCO VII.

Ontem (08/06/2011) não fui aprovado nos testes do Bloco VII, os homologadores (UFG) fazem o teste da seguinte forma:

• 
  1 - Primeiro registram as operações normalmente, por exemplo 10 DAV,
  2 - Geram o arquivo para saber se está tudo ok,
  3 - Depois entram no banco e alteram os registros conforme o roteiro,
  4 - Geram o arquivo e verificam se os ??? apareceram somente nos registros alterados. Até aí tudo bem, só que para minha surpresa veio o passo seguinte:
  5 - Entram novamente no banco de dados e nos registros que foram alterados, altera os campos alterados para os valores originais,
  6 - Geram o arquivo e verificam se ainda possui os ???. Se não houver os ??? você é reprovado, pois uma vez modificado o registro, mesmo voltando aos valores originais é obrigatório manter os ???... então dancei nessa.
  

Utilizei Hash gerado pelo meu sistema, pois meus clientes ainda possuem Firebird 1.5, então ao voltar os campos aos valores originais o Hash confere normalmente e então os ??? não são atribuídos ao gerar o arquivo, por isso dancei.

Fica aí o alerta para a galera.

Espero ter contribuído.

Fabrício Gomes Araújo

[wrmedeiros]

Complicado em Fabrício!

Eu estava somando o conteúdo dos campos que são avaliados, criptografando, e aplicando CRC (conforme dica do Daniel, a diferença é que não faço do Dataset inteiro, faço somente dos campos em questão).

Se o usuário alterar algum valor pelo banco, o CRC não vai bater.. até aí tudo bem... mas se depois o cara alterar o banco e deixar EXATAMENTE o valor que estava antes não vai ocorrer crítica alguma no CRC... que bronca =)

Não estava nos meus planos fazer nada pelo banco (contexto do Firebird, triggers, etc)... até porque um usuário mais experiente pode desativar as trigger's e quebrar a proteção...

Engraçado que isso não está no roteiro! Essa avaliação está igual a de TEF... você faz tudo que está no check-list, e na hora da homologação aparece 1001 novidades. :/

[Fabrício G. Araújo]

Pois é welkson, é exatamente isso.

As vezes penso que se ao invés do Hash, se apenas tivesse colocado um campo Booleano indicando a alteração S / N eu teria passado na homologação, pois eles não querem saber como você fez, se é a prova de falhas ou não, apenas querem que os ??? apareçam.

Fazer o quê né... agora é correr atrás.

Abraços,

Fabrício Gomes Araújo

[EMBarbosa]

Fabrício, Welkson,

Nesse caso, é melhor verificar com o homologador antes. Pois a lei não parece ser específica.

Acho que quando fui homologar (no ano passado) quem implementou dessa maneira, não teve problema algum. Mas como não foi o meu caso, não me lembro ao certo...

[Fabrício G. Araújo]

O pessoal que esté me homologando (UFG - Universidade Federal de Goiás), falou que teve uma reunião recentemente e passaram essa orientação para eles (deve ser o GT-46), que antes realmente não faziam o teste dessa forma.

Abraços,

Fabrício Gomes Araújo

[Daniel Simoes]

fabricio,

Qual o foi o argumento legal do homologador para isso ? (Que trecho da lei do PAF-ECF ele usou ?)

[jaime]

analisando de outro ponto de vista deles, é que mexeu no banco de dados e depois voltou original, já está concretizada a violação, sem prejuízo alguma mas houve modificação.

Eles gostam de inventar moda mesmo , quando tava homologando em Goiás só que na UCG também fizeram a modificação do GT no meio da venda, ou seja queria que a cada item checar o GT mas no ATOCOTEPE é bem claro "ao enviar ao ECF comando para abertura de documento fiscal" não durante a venda ai deixaram passar.

[Daniel Simoes]

É importante ler o Roteiro... mas é muito mais importante conhecer a Lei do PAF-ECF a fundo...

Os homologadores não são os donos da verdade, eles precisam argumentar o "porque não" usando a Lei... se não está na lei, ou estiver diferente, eles não podem exigir...

Aqui em SP, na Polimig, isso não seria problema... O homologador até prefere quando a registro é "refeito", pois é mais fácil ele continuar os testes e alterar os outros campos...

Minha aplicação usa uma Trigger, after Insert ou Update no banco, o que invalida o Hash... mas nem todo banco aceita triggers...

Uma saída seria vc invalidar o Hash no Banco, quando você mesmo fizesse uma verificação na hora de gerar os arquivos... com isso ele ficaria inválido, e voltar o valor do campo não iria restaura-lo...

[EMBarbosa]

Jaime,

analisando de outro ponto de vista deles, é que mexeu no banco de dados e depois voltou original, já está concretizada a violação, sem prejuízo alguma mas houve modificação.

Até entendo o que você diz. Mas o objetivo não é impedir as alterações para que os valores gerados nos arquivos sejam exatamente iguais aos recolhidos? Trabalhando com Hash, cumpre exatamente esse objetivo.

Além do mais não me lembro de nenhum "lacre eletrônico de dados" seguro da maneira que eles pedem, (se alguém conhecer, avise aí!).

[Fabrício G. Araújo]

Ops... estou de volta. Estava justamente homologando o nosso sistema.

Felizmente fomos homologados e agora só no ano que vem.

Sobre a questão levantada pelo Daniel:

fabricio,

Qual o foi o argumento legal do homologador para isso ? (Que trecho da lei do PAF-ECF ele usou ?)

É aquilo que tinha falado mesmo, de tempos em tempos os homologadores fazem reunião com a Sefaz ou GT-46 (não sei ao certo) e então são passadas as orientações de como devem proceder nos testes, não existe nada na lei que fale isso.

O próprio roteiro de teste possui falhas de impressão e então eles seguem as orientações recebidas, ou infelizmente ficamos por conta da interpretação deles.

Abraços,

Fabrício Gomes Araújo

[Fabrício G. Araújo]

Jaime,

Como você citou o seguinte, me gerou uma dúvida...

...

Eles gostam de inventar moda mesmo , quando tava homologando em Goiás só que na UCG também fizeram a modificação do GT no meio da venda, ou seja queria que a cada item checar o GT mas no ATOCOTEPE é bem claro "ao enviar ao ECF comando para abertura de documento fiscal" não durante a venda ai deixaram passar.

...no ano passado fiz a homologação pela UCG e este ano fiz pela UFG. No ano passado passei no teste que você citou (comigo não testaram o item, só abertura de cupom fiscal mesmo) e este ano quase me ferrei na UFG pois eles além de testar o cupom fiscal também tentam emitir os comprovantes não fiscais, como Sangria, Suprimento e Pagamento ou Recebimento diversos (comprovante não fiscal não vinculado).

No seu PAF você tratou isso? Pois tive que efetuar as alterações senão dançava. Inclusive tentaram questionar que nada que utilizasse o ECF do MENU FISCAL ficasse disponível, como a Leitura X ou Leitura da Memória Fiscal, mas nesse ponto bati o pé e aceitaram, pois não estou registrando nenhuma operação no ECF só consultando dados dela... seria até uma forma do Fiscal identificar um ECF inválido ao imprimir estas informações do ECF.

Abraços,

Fabrício Gomes Araújo

[jaime]

Fabricio, também homologuei ano passado e só consistiram também só na abertura do cupom. Mas analisando melhor o que diz o atocotepe:

no requisito XXII item 5

"ao ser inicializado, ao viabilizar o acesso à tela de registro de venda e ao enviar ao ECF comando para abertura de documento fiscal, comparar o valor acumulado no Totalizador Geral (GT) do ECF"

Neste caso eles generalizaram, não especificaram em quais abertura de documentos fiscais. Uma sangria, suprimento, relatório gerencial pode ser considerado documento fiscal ? Se sim ai tem que verificar.

requisito XVII item 1

"O PAF-ECF deve impedir o seu próprio uso sempre que o ECF estiver sem condições de emitir documento fiscal, devendo, neste caso, disponibilizar exclusiva e obrigatoriamente as seguintes funções:

e) para geração dos arquivos previstos no requisito VII que não dependam do funcionamento do ECF interligado fisicamente ao computador onde esteja instalado o PAF-ECF."

Pelo visto tem que desabilitar tudo mesmo.

Grato

Jaime

[guilhermebraga]

Pessoal,

Já homologuei 2 vezes o PAF-ECF. Para quem tem dúvida, postei no meu blog como fiz esse bloco VII.

http://guilhermebragaf1.blogspot.com/20 ... f-ecf.html

Espero que ajude.

Boa Sorte !!

Guilherme Braga

[brunoso]

Primeramente disculparme por mi portuguese.

Estou intentando homologar o PAF 1.6. He utilizado triggers. El homologador di que non podo utilizar triggers por que no cumple o teste 116 do Bloco VII:

TESTE 116: Inspeção de menus ou rotinas automáticas que eliminem as evidências apontadas pelos alíneas e c) presentes no bloco VII;

PASSO1: Busque no sistema por menus ou rotinas automáticas que façam com que registros evidenciados sejam limpos;

Condição para requisito atendido: Inexistência de menus ou rotinas automáticas que eliminem uma evidência de alteração nos registros ou de manipulação nas tabelas do PAF-ECF;

Condição para requisito não atendido: Existência menus ou rotinas automáticas que eliminem uma evidência dos registros e tabelas manipuladas.

¿e esto certo?

[cnbatalha]

Primeramente disculparme por mi portuguese.

Estou intentando homologar o PAF 1.6. He utilizado triggers. El homologador di que non podo utilizar triggers por que no cumple o teste 116 do Bloco VII:

TESTE 116: Inspeção de menus ou rotinas automáticas que eliminem as evidências apontadas pelos alíneas e c) presentes no bloco VII;

PASSO1: Busque no sistema por menus ou rotinas automáticas que façam com que registros evidenciados sejam limpos;

Condição para requisito atendido: Inexistência de menus ou rotinas automáticas que eliminem uma evidência de alteração nos registros ou de manipulação nas tabelas do PAF-ECF;

Condição para requisito não atendido: Existência menus ou rotinas automáticas que eliminem uma evidência dos registros e tabelas manipuladas.

¿e esto certo?

Quando homologuei recentemente o homologador disse a mesma coisa, que não era permitido usar trigger.

[guilhermejvmbraga]

Pessoal,

No meu blog postei uma dica para implementar esse bloco VII.

http://guilhermebragaf1.blogspot.com/

At.

Guilherme

[jose111]

Então alguém desenvolveu uma solução para o teste 115 sem ser esta de salvar o número de registros das tabelas?

A cada ano o Paf Ecf esta conseguindo se superar com testes cada vez mais sem pé nem cabeça... esse controle de inclusão/exclusão deles é totalmente falho... parece que fazem somente para dificultar...

[Hw2]

Boa tarde a todos, e se a solução para esse requisito, for criar uma permissão no Banco de Dados, criando um usuário/senha para a aplicação e/ou verificar qual aplicação esta efetuando a manipulação, e o restante dos usuários não teria permissão para update,insert,delete, como os homologadores tratariam essa situação?

Já que no momento da homologação, o homologador irá pedir para efetuar a manipulação, e o BD não permitira, já que não seria a aplicação efetuando o comando....

Att,

[Juliomar Marchetti]

Bom eles vão querer acessar o banco de qualquer forma para alterar os dados

via gerenciador de tarefas

Solução meu amigo, acho que deve até estar em algum outro tópico

cria uma tabela para guardar o nome da tabela e a quantidade registros

claro guarde os dados criptografados com uma chave sua

quando inserir um registro verifique antes se corresponde

caso sim insira o registro e atualize as informações nessa tabela

caso contrario ele ficará inválido

da mesma forma para excluir um registro faço o mesmo

há mas dai vem a pergunta mas se eu excluir e inserir um registro

vai bater os dados e ficará correto, bom mas dai o cara vai ter que ser fera para burlar a outra parte

que valida o registro em si, onde se você não bater os dados a linha do registro estará errado

então escapa de um lugar e cai em outro e vice versa

beleza.. espero que tenham entendido a solução