POS inbound IDocs
POS Inbound IDocs in Retail have two main types, which types are fundamentally behaving different regarding the error handling
- Splittable IDocs: e.g. WPUUMS
- Non-splittable IDocs: e.g. WPUBON
The base rule is, that an IDoc of Non-splittable type will always fail to be processed (getting status 51) if any error is occurring during the processing.
Partial processing of an IDoc is possible however for IDocs of Splittable types. Partial processing means - depending on the IDoc type and customizing settings - article document (and it's follow-on documents on FI and CO side) or billing document (and it's follow-on documents on FI and CO side) may get posted containing only the error-free items. Later, when the situation preventing the processing of specific items gets resolved, the not-yet-posted items can be re-processed and in separate article document, billing document, etc. they will appear. Merging or appending to existing follow-on documents is not possible.
There can be few type of errors again, which may make difference when coming to error handling by POS inbound process:
- Header level error: this is probably self-explanatory; no partial posting is possible, despite of IDoc type
- Item level errors:
- If the error is originating from a so called first level Follow-on document (e.g. Billing document, or Article document in context of WPUUMS), the error can be handled on item level, thus the erroneous items are excluded from follow-on document posting, all the rest is included in the necessary documents.
- If the error is originating however from a deeper* level follow-on document, the process may unable to identify which exact item is impacted (or the application logic cannot return the information on the required level), also cannot simply roll back the parent document and post it again excluding the erroneous items. Therefore, even an item level error may cause to fail the whole IDoc processing as result.
*Deeper level follow-on documents:
Under normal circumstances, the WPUUMS IDoc will trigger the creation of below follow-on documents:
Article document
Billing document
It is easy to remark, that two first level documents are in scope with WPUUMS, the Article document (Inventory Management for goods movement postings) and the Billing document (SD invoice).
Both of them can have follow-on documents, which may again trigger the creation of further follow-on documents, etc. These are not directly triggered and supplied by POS inbound process therefore.
The LUW concept in POS Inbound
The concept of LUWs (Logical Unit of Work) used in POS inbound needs an overall understanding, as it is loosely related to the topic of error handling.
In nutshell, a LUW has the purpose to ensure data consistency in the system. Let's review the concept via processing of a POS inbound IDoc:
As already detailed above, many level (and type) of follow-on documents may be necessary to be created based on the IDoc data. However, specific errors may not be known yet at the time of creating the higher level documents, on the other hand the deeper level follow-on documents can be created only referencing (and based) on those higher level documents. So, how to ensure the data consistency then - to avoid having posted e.g. Billing document without corresponding accounting document? This is where the LUW plays a crucial role. All the documents created during the inbound processing will be "just" prepared, but not saved on Database immediately, in fact. All documents will be saved (update tasks started) at the very end at once, when POS inbound gives a green light (this is what we call from technical side COMMIT WORK). If at any step of preparation of follow-on documents a critical issue is identified, the POS inbound is capable to interrupt and reset the situation to the consistent state as was before the IDoc posting (this is what being called ROLLBACK WORK in ABAP). So, with the help of LUWs and basically these two keywords, it can be easily controlled when and whether any follow-on documents can be created and saved on Database.
IMPORTANT to bear in mind: a COMMIT WORK (or ROLLBACK WORK) made unintentionally (so not by standard POS inbound logic) can ruin the whole process and result in inconsistencies (just some examples: partially or duplicated posted items; wrong IDoc status, etc. the variety is marvelous). The end user may identify these kind of issues either in WPER transaction, or from functional consequences, at the end it may cause huge efforts to be corrected and sometimes also even to be reproduced for analyzing purposes!
Certainly no one implements COMMIT WORKs in custom coding in order to cause inconsistency; still, it is not that hard to occur. Namely, just having a look at the tree of various follow-on documents shown above, clearly many custom BAdIs, user exits can be touched until finishing the IDoc processing (SD, MM, FI, CO… so many functional areas impacted). So, again: any COMMIT WORK (or ROLLBACK WORK) implemented in those user exits, BAdIs - or trickly just calling some standard SAP delivered subroutines, function modules containing COMMIT WORK - will sooner or later lead to inconsistencies. This is an ancient rule, also documented already in note 944204.
