Skip to Content

Oi Pessoal,


A SAP Note “2135414 – [3.10] NF-e: Issuing hour not available for modification” foi disponibilizada.

Após implementá-la é habilitado na BAdI CL_NFE_PRINT, método FILL_HEADER o campo HEMI. Este campo é a hora de emissão da nota fiscal.

O novo comportamento após a nota verifica se o campo hemi foi preenchido via BAdI CL_NFE_PRINT e neste caso usa o valor da BAdI no lugar do horário determinado pelo sistema (esse horário é posteriormente convertido para UTC no perform convert_timespan_to_utc ).

No include abaixo é possíver ver o novo código:

TIME.jpg

Agora é possível determinar o horário de emissão no campo HEMI de forma mais flexível e também utilizando regras adicionais como CNPJ/CUF, não dependendo exclusivamente da configuração de timezone da planta/usuário.


att,

Renan Correa

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Eduardo Chagas

    Oi Renan.

    Mas neste caso poderá ocorrer de haver a nota 100 emitida as 14:00 e a nota 101 emitida as 10:00 ?

    Esse recurso foi adicionado também na badi nova?

    Abraço

    Eduardo Chagas

    (0) 
    1. Renan Correa Post author

      Oie,

      1- Sim, pode haver esse caso. Na verdade isso já pode ocorrer antes de implementar a BAdI com o HEMI.

      A lógica standard do mapeamento altera o horário (apenas horário e não data) cada vez que a nota é reenviada. Aquele código ali em cima com o perform_UTC_to_time pega o horário atual e envia. Se um documento é rejeitado e reenviado horas depois, o horário de emissão é alterado nesse ponto.

      2- Não. O mapeamento do horário não depende dos dados persistidos nas tabelas J_1BNF* e o DHEMI também não é gravado nessas tabelas, então não teria como ou porquê persistir isso usando a BAdI nova.

      att,

      Renan

      (0) 
  2. DANIEL ALVES BORGES

    Olá Renan,

     

    Estamos enfrentando um problema de inconsistência na tag DHEMI. Verifiquei que a origem dessa inconsistência é standard e gerada exatamente nesse trecho do programa.

    No caso de reprocessamento, o sistema concatena a data em que o documento foi criado com o horário do re-processamento e isso gera informação incorreta.

    Imagine o seguinte (considerando uma filial com diferença de 3h para UTC):

    Gerei uma NF num sábado (30.09.2017) às 10:00:00 horário local, porém essa nota foi rejeitada por um motivo qualquer.

    Na segunda feira (02.10.2017), eu ajusto o motivo da rejeição e tento reenviá-la às 18:00:00 horário local. O ECC está enviando para o GRC DH_EMI = 20170930210000 (2017-09-30T18:00:00-03:00) como data de emissão.

    Nesse caso, a tag dhEmi está ficando errada.

    Deveria ser ou a data/hora de emissão inicial: 30.09.2017 10:00:00 ou a data/hora de reprocessamento 02.10.2017 18:00:00 e não a data de um lugar com a hora do outro.

    No exemplo acima, não houve expediente no sábado (30.09) depois das 12h, mas há um registro de documento gerado nessa data/horário (errado).

    Acha que isso cabe uma OSS?

     

    Grato,

    Daniel

    (0) 

Leave a Reply