Without any surprise, new issues come with new company codes. The user reported that all Revenue Recognition documents are missing the sales order number for the new specific company code. The only clue is it referenced old company codes that are working fine without issue.

I use this article to track my checking steps to speed up my analysis if similar issues happen. Please be aware that there’re could be hundreds of reasons to lead to this issue, my case is just for your reference.

1. Check FI substitution (GGB1)

The FI document processing has been set up for years and has dozens of user-exit/enhancements at different places for various purposes. FI colleague suspects substitution could be the reason active for the old company code but missing the same implementation for the new. Sounds like the root, so check and start with FI substitution GGB1.

Have a check of the existing Substitution at the line item of Financial accounting. Double-click this Z908 exit will bring you to the editor with the code.

Set break-point here, call VF44, and perform collective processing of selected sales documents will have an overview of the major function modules being involved.

It’s already empty there for COBL-KDAUF. So this value must be clear ahead of this routine SUBSTITUTION being performed at include LFACIF20.

Traceback those big function modules like: ‘FI_DOCUMENT_CHECK’, ‘AC_DOCUMENT_CREATE’, and ‘SD_REV_REC_COLLECTIVE_RUN_NEW’, then will find out the source of sales order (KDAUF) comes from below FM:

In the end, it turns out to be one physical table VBREVE (Revenue Recognition: Revenue Recognition Lines)!!! It has been fetched at include LVFRR022:

All the above checks are in vain cause it’s not related to Revenue Recognition generation processing at all! Honestly, I’m not familiar with this VBREVE table. The lesson learned here is that:

• Start with a general understanding of the overall flow and check the contents of the major table first!
• Do not rush to debug the standard program!

2. The Famous RV60AFZZ

As the sales order number is already empty before Revenue Recognition processing. Now the focus is on why VBREVE-VBELV is empty during VF01?

RV60AFZZ is an important user exit for invoice generation processing. No idea whether it’s related to this issue or not, but it’ll be a good starting point for me to check whether VBRP-VBELV is empty or not at the point of RV60AFZZ.

Just realized that VBRP-VBELV has already been cleared, then have to check Events ahead of RV60AFZZ. By monitoring the changes of field: VBRP-VBELV, finally the root was revealed at LV60AA93.

3. The Cause of empty VBRP–VBELV

There’s one SAP standard logic that will reset the sales order number during the standard Billing generation process when

• Valuation area against company code Not Equal to Billing document’s company code

For my case, the valuation area against company code is fetched from the T001K table according to the plant of sales order.

The billing document’s company code is fetched from the order’s company code to be billed(VBAK-BUKRS_VF).

So T001K-BUKRS(PL10) is not equal to VBRK-BUKRS(PL20), then the sales order number has been reset during the standard Billing generation process which leads to a blank value at VBRP-VBELV. Finally, it leads to empty sales order numbers at the accounting document(BSEG-VBEL2) or Revenue Recognition document level(VBREVE-VBELV).

Although no user exit/enhancement is involved in my case, be cautioned that any custom enhancement could impact this value during Billing/Accounting document processing.