De onde “cargas d’água” vem o COD_SIT na Nota fiscal no S/4HANA?
Uma pergunta que vejo pipocando em alguns grupos de discussões fiscais vem devido ao layout 17 da EFD-ICMS está relacionada com o COD_SIT.
A origem desse questionamento está de acordo com o manual novo da EFD:
Observação: A partir de janeiro de 2023, os códigos de situação de documento 04 (NF-e ou CT-e denegado) e 05 (NF-e ou CTe Numeração inutilizada) da tabela 4.1.2 – Tabela Situação do Documento serão descontinuados
Manual da EFD Layout 17
OK. E de onde “cargas d’água” vem isso?
O preenchimento no SAP – Função J_1BNF_FILL_COD_SIT no ECC ou S/4HANA
Esse código vem de um módulo de função chamado na criação do documento fiscal.
Essa FM é chamada nas transações de criação de NF (VF01, MIRO, MIGO, J1B1N ou BAPI) e baseado em alguns parâmetros do documento o sistema decide qual COD_SIT deve ser determinado.
Os principais parâmetros que influenciam essa definição são:
- – Direção do documento fiscal
- – Dsaient – Data Saída/Entrada do Documento fiscal
- – Data de lançamento
- – Nota emissão própria ou de fornecedor
- – Doctyp – Tipo de Documento Fiscal
- – NF-e avulsa ou não
OK. Então tem essa determinação padrão da SAP, mas o que faço eu da vida se não concordo com o COD_SIT determinado ou se tenho requisitos que não são atendidos por essa determinação padrão?
A resposta é BADI.
A SAP tem duas BAdI’s para alterar esse comportamento, 1 para o S/4HANA nuvem pública e outra para o S/4HANA Private/AnyPremise.
O código está aqui abaixo para o S/4HANA Public Cloud:
IF lo_cloud_badi_situation_code IS BOUND.
TRY.
CALL BADI lo_cloud_badi_situation_code->determine
EXPORTING
nfeheader = is_nfdoc
CHANGING
nfesituationcode = ev_cod_sit.
CATCH cx_ble_runtime_error.
CLEAR ev_cod_sit.
ENDTRY.
ENDIF.
O código abaixo vem da BAdI j_1bnf_add_data no método FILL_COD_SIT e é o que está disponível no On-Premise (e Private Cloud):
* BAdI object is created as local hence the method
* fill_cod_sit should be called regardless the BAdI implemented
TRY. "2187144
GET BADI lo_nf_add_data. "2187144
CATCH cx_badi_not_implemented. "2187144
CLEANUP. "2187144
CLEAR lo_nf_add_data. "2187144
ENDTRY. "2187144
IF lo_nf_add_data IS BOUND. "2187144
CALL BADI lo_nf_add_data->fill_cod_sit "2187144
EXPORTING is_header = is_nfdoc "2187144
CHANGING ev_cod_sit = ev_cod_sit. "2187144
ENDIF. "2187144
ENDIF.
Nessas BAdI’s uma pessoa desenvolvedora e consultora das boas pode modificar o conteúdo do COD_SIT a seu desejo e comemorar o gol!
Após essa FM (e as BAdI’s) o sistema faz a persistência das informações no banco de dados do SAP. O campo COD_SIT fica gravado no cabeçalho da NF:
Mas e no SPED em 2023, como que fica?
OK. De onde vem a informação, mas e o que eu faço com o SPED agora no Layout 17, continuo determinando 04 e 05 no ERP?
Sim, a SAP já lançou uma solução para atender essa alteração e continua determinando esses códigos.
A solução é um pouco diferente se você usa o SPED no ECC (J1BEFD) ou no TDF/DRC, mas basicamente a idéia é filtrar documentos com o COD_SIT = ’04’ e ’05’ para que eles não sejam reportados.
Eu juro que li o manual e fiquei em dúvida qual seria o comportamento certo, mas pelo que entendi esse é o modelo que está sendo adotada pela solução da SAP para as entregas do EFD em 2023.
Valeu Gurizada!
Renan Correa
Mais infos sobre o TDF direto da sap no HELP do TDF.
Outros posts sobre TDF você pode conferir filtrando pela categoria TDF/ACR.
Quer ficar ligado nas novidades de localização? Entra no grupo da S4CN no Telegram e segue a gente no canal do Youtube
Renan muito obrigado por compartilhar esse excelente conteúdo porque estou passando exatamente por esse problema!
Sensacional!
Sensacional Renan, obrigada por compartilhar!
Renan obrigado por compartilhar estou sentindo a mesma dor. Excelente material e em tempo oportuno.
Olá Renan!
Excelente dica, obrigado por compartilhar!
Essa também sempre foi uma dúvida minha.
Carlos Prais