Last three weeks (at the same time my SPS-22 Upgrade is in motion), I have been assigned to check out an error that keeps telling user to "Enter G/L Account" when they tried to run a program to automatically create invoice based on a file.
1. I thought the file pass by another 3rd party system provided some wrong data in it. So I had the parameters checked against old files and previous technical specification. I found no discrepancies.
2. So it had to be some changes in the BAPI "BAPI_INCOMINGINVOICE_CREATE1", and I thought some user exits OR enhancement points done by some programmers had some effect to it. Or there were some change in the business process as a result of those exits/enhancement. None I found and even if the business process had change, the affect shouldn't be so adverse until existing customized business program's logic ran away. Even if it does, the previous programmers or functionals should've given thought of other customized programs will be affected by their changes.
3. Irregardless, I gave trace (ST05) on the customized program. So I found the following trace analysis :
- SAPLMRM_BAPI - DIM_GENERAL_SAPLMRM_BAPI==== - BAPI_INCOMINGINVOICE_REATEMRM_
- SAPLMRM_BAPI - LMRM_BAPIF0C - MRM_INVOICE_CREATE_CALL
- SAPLMRM_BAPI - LMRM_BAPIF0C - MRM_INVOICE_CREATE_CAL_N - MRM_INVOICE_CREATE (Line 39)
- SAPLMRMH - LMRMHU09 - MRM_INVOICE_CHECK - MRM_DRSEG_FILL
- SAPLMRMH - LMRMHF0A - MRM_DRSEG_FILL - ME_READ_ITEM_INVOICE
- SAPLEINR - LEINRF2M - XEK08R_AUFBAUEN
- SAPLEINR - LEINRF5I - XEK08R_AUFBAUEN_BLANKO
- SAPLMRMH - LMRMHF07 - DRSEG_ITEM_CHECK - MRM_DRSEG_CHECK
- SAPLMRMH - LMRMHF07 - DRSEG_ITEM_CHECK - MEX_LESEN_SACHKONTO
When we trace the standard routines as called from the standard includes above, the error message ME - 083 ('Enter G/L Account') came to be validated in routine MEX_LESEN_SACHKONTO.
MEX_LESEN_SACHKONTO is only validated by a call from BAPI's BAPI_INCOMINGINVOICE_CREATE1. Manual creation from ME21N, ME22N or MIR* tcode does not go through MEX_LESEN_SACHKONTO. Validation of G/L Account from MEX_LESEN_SACHKONTO is only done from a BAPI call.
Findings :
1. If you trace until SALEINR - LEINF5I - XEK08R_AUFBAUEN_BLANKO, and at the same time, you are creating an invoice for a blanket PO, you might bound to see BETS table containing type 99. This is normal as per invoice creation because the invoice creation is also based on all the best possible type to create it's line item.
2. If you find your manual creation in MIRO works just well, then it is absolutely not related to any change of code in either user exits, enhancement implementation or both.
3. MEX_LESEN_SACHKONTO is only validated from BAPI calling "BAPI_INCOMINGINVOICE_CREATE1".
As a result, if you find yourself doing the same thing like I'm doing, you are checking at the wrong places but no harm done because you have, at least, find out where the error ME - 083 is coming from. The error message is definitely BAPI related but not due to standard coding. It is due to the table ACCOUNTINGDATA neither filled up or filled properly.
So, the solution:
Check your BAPI's BAPI_INCOMINGINVOICE_CREATE1 table parameter's ACCOUNTINGDATA. Is it being filled or filled properly? This was my issue, the ACCOUNTINGDATA table parameter was not filled at all. As a result, the error message ME - 083 pops and halts the creation process.
williamwilstroth... BAPI_INCOMINGINVOICE_CREATE1, ME083
