Campo HEMI habilitado na BAdI CL_NFE_PRINT
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:
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
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
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
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