Attention

This text is not mine. It belongs to Renan Correa and it was posted at the SPED and NFe SCN Blog: https://scn.sap.com/community/portuguese/sped-and-nf-e

Unfortunately the SCN Blog above is in Portuguese and the text below is good enough to be missed. I am translating it to English.

All the credits to the text below go to Renan (https://scn.sap.com/people/renan.correa) and the SAP Localization team.I am only translating it to English and posting it in my blog.

Cancellation by Event not finished in ERP

How to do the analysis? Where to Start From?

I suggest always start from J1BNFE Nfe ERP Monitor

What to check?

I recommend start from the fields Required Process Step (ACTION_REQU), Document status (DOCSTA), System Communication Status (SCSSTA) and Messaging System Status (MSSTAT). Besides that, clicking on the events flag to check the event status.

The necessary status to each process step (Authorization, Cancellation and Skipping) can be seen in the ERP Help:

http://help.sap.com/erp2005_ehp_07/helpdata/en/e6/2d713a377e49d2a69a864c8a34c762/content.htm

To understand better more of the cancellation process, just follow the below information. An additional  recommendation is always look for SAP Notes using the object related to the process (Functions, tables, Structures) and/or using the SAP automated tools such as ANST (Automated Note Search Tool ).

1) NF-e with inconsistence between J_1BNFE_EVENT and J_1BNFE_ACTIVE:

In the situation below for example, there is an inconsistency in the document, since the event status is “authorized” and the NF-e status is “waiting Messaging System”.

The most common reason for this issue is that the OSS Note 2029305 is missing.

The manual solution to this problem would be execute the function J_1B_NFE_XML_IN simulating the authorization to the cancellation (DOCNUM, AUTHCODE = SEFAZ Protocol, AUTHDATE = SEFAZ Authorization Date, AUTHTIME = SEFAZ Authorization Time, CODE = 101 for cancellation and MSGTYP = 4 Cancellation Authorization)

NFe1

2) NF-e (without error / inconsistency) waiting GRC anwer to cancell

The procedure above fixes an issue when the ERP events table is not synchronized with the table J_1BNFE_ACTIVE.

However, there are other scenarios with error where the events table and the J_1BNFE_ACTIVE table  are synchronized (both waiting answer from SAP NFe / GRC)

NFE2

In this case, the recommendation is to check how the status of the documents are in the GRC. If the status of the cancellation is OK (01/Green) then it is needed to execute the functionality “repeat process step” as shown below:

NFE3

This Functionality is available from the SP20.

If the status to the “cancellation” was “135 – Authorized” and the step “Update to ERP” has error (02/Red) then it was required to execute the functionality “Continue Process”, like in the image below:

NFE4

If you are not running the SP20 and need to bring the results back to SAP, you can execute the program /XNFE/PROCSTEP_EV_ERPUPDAT on SAP NF-e to re-send the OK status back to the ERP.

However are situations where those new procedures to trigger the SAP NFe (GRC) update back to the ERP may not work for many reasons (SAP OSS Notes missing, Core functions changed, incorrect validation or commit work at the BAdI, RFC or connection issue and etc).

3) NF-e (without error/inconsistency) waiting GRC answer the cancellation but the GRC update didn’t work

If the procedures above didn’t work, then the last option to analyse/fix the issue would be execute the function J_1BNFE_EVENT_IN  in the ERP to simulate the process and debug the program to identify the reason why the update not be working.

NFE5

The parameters below are required to execute the function manually. A interesting hint if you don’t know how to fill them is to enter a breakpoint on SAP NFe (GRC) before the call to J_1BNFE_EVENT_IN  and execute the function /XNFE/PROCSTEP_EV_ERPUPDAT. By doing that, it will be possible see what are the parameters entered on ERP via SAP NFe (GRC).

NFE6

In the ERP side, the begin of the J_1BNFE_EVENT_IN processing has the FORM process_nfe_for_cancel_event that verify if the cancellation was authorized and if all information required were received from SAP NFe and after that the program will call the function J_1B_NFE_XML_IN

NFE7

In other hands, the function J_1B_NFE_XML_IN has some validations of the table “active” status and also the method check_subsequent_documents of BAdI CL_NFE_PRINT and the accounting period.

NFE8

In this point it is possible to add business rules to check / reverse other documents that normally are not part of the NF-e Flow.

NFE9

Besides that, it is important to remember that the program also perform the validation if the accounting period assigned to the Company Code is open. The logic to cancelling the NF on ERP do not allow the reversal if the accounting period is already closed. It is necessary, before perform the closing, do a detailed check on the status of all the NFs to identify documents that are in cancelling process, but were not reversed, to avoid fiscal and tax issues and penalties (NF cancelled at SEFAZ can’t be cancelled at the ERP anymore).

NFE10

NFE10.1

4) NF-e already cancelled at J_1BNFE_ACTIVE but stuck on step “2 – Cancell Source Document “

In many situations, the ERP will pass through the validations above, but it could happen that it doesn’t finish the cancellation with success and it stops in the status below:

NFE11

In this case, the cancellation process, updating the table J_1BNFE_ACTIVE was done with success, but the source document (billing document, material document, and etc) couldn’t be reversed for some reason.

To check the reason, you can click the J1BNFE log (red flag). If the error is not clear (for example “No Batch input data for screen XXXX XXXX ) it iss possible request the reversal of source document (as per screenshot below) and debug the cancellation process to see where it is failing.

NFE12

The code below shows part of the function  J_1B_NFE_CANCEL, that identifies what is the source document type and perform a call transaction to the respective reversal transaction as screenshots below:

NFE13

A hint to debug this process is change the variable lv_mode from P to A, in that way, the cancellation transaction will be executed in the screen and if an error exists, that will be shown in the screen as well.

NFE14

That’s the message for today… more to come… and thanks again to Renan Correa for such good content…

5356132783_a490d85fed-2-300x225

Copyright Notice: © Leandro da Pia Nascimento and SAPBR.COM (SAP BRAZIL) WordPress Blog. Unauthorized use and/or duplication of this material without express and written permission from this blog’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Leandro da Pia Nascimento and SAPBR.COM with appropriate and specific direction to the original content.

Advertisements