Receive Products is a SAP IS-R Retail standard application to post goods receipt. In my opinion it’s a great app that might seem profane at a first glance, but really shines after a deep dive
😊
Since I couldn’t find much information online when I was looking into the app for our GR process, I thought it a bit underappreciated. Therefor I decided to point out the coolest features.
I won’t go into details with the basic functionality like the multiple entry points (bar code scan, document or material number entry), GR posting and reversal, filters etc., since this is pretty obvious in the app itself, the information in the
Fiori Library is solid and there are videos on youtube that cover this.
In this blog post I like to describe the (not that obvious) features I had to find out about myself (or at least find out by myself how the shortly mentioned feature in
SAP Help actually works).
Ok, the start might be a bit basic, but if you are new to Fiori it might be helpful nonetheless and it caused a bit confusion in our project at first whether or not the app actually supports scanning.
1. (Really) Switch from desktop mode (in browser) to mobile mode and back
Hit F12 to enter development tools and switch mode:
Right after clicking the visible window is switched and you can select the size of your actual device or create a custom one, but you are not yet in mobile mode! You need to reload (F5) first:
Now (when the scan symbol appears), you really are in mobile mode
😊
2. Differences between “Receive Products” and “Receive Products trusted”
The first and pretty obvious functionality of the “trusted” version of this app is the additional option (the button in the upper right area) to select the complete document and post the GR either exactly like ordered (in case of reference to purchase order) or exactly like advised (in case of reference to inbound delivery document):
The normal (not trusted) “Receive Products” mode just doesn’t offer this menu button in the upper right area:
Not that obvious is the second option to post a trusted GR.
2.1 Handling Units / SSCC18
If you received an inbound delivery with handling units and the handling units are identifiable by a scannable barcode (e.g. SSCC18) the scan of this number leads to
direct posting in the background through “Receive Products trusted” while a scan in normal mode just opens the scanned document.
(sorry about the german screenshot, but it's just handling unit details from inbound delivery VL33n to show the connection)
Receive Products -> Scan opens document:
Receive Products trusted -> Scan directly posts the GR in the background:
Btw. the HU description “pallets” on the screenshot stems from the description of the packaging material from customizing.
2.2 Other scannable identification (e.g. tracking number)
This works as well with other scannable data like e.g. a standard tracking number that logistic providers attach to deliveries.
If you can’t or do not want to use handling units the corresponding tracking number needs to be in LIKP-BOLNR:
Frachtbr. = BOLNR
3. BOL Number replaces internal delivery number
As you probably already could deduct from the screenshots above whatever is entered in LIKP-BOLNR will replace the SAP internal inbound delivery number on the "Receive Products" screens. So if you do not want to use it for the tracking number, you could/should store the suppliers delivery number in this field and directly see this number, which makes it much easier to verify that you are working on the right document. (I mention this, because from my experience the suppliers delivery number will be mapped to E1EDL20-LIFEX which won’t populate the BOLNR (but LIKP-LIFEX) and therefor this feature is easy to miss
😉)
As you also can see on the screenshot, if BOLNR is not populated the internal SAP delivery number (1800…. In standard number range) is shown in the app, but in general no user will be able to do anything with it, since it shouldn't be on any papers in an inbound scenario.
4. Post single GR in item detail screen
In a manual goods receipt posting process it is possible to pull a single goods receipt forward. To do this you need to click on an item in the document to enter the item details. There you not only see (and can add further) additional data but you can also post a single GR for this item without affecting the other items in this document. This could possibly be helpful if you need a specific article for a waiting customer.
Additionally (resp. as kind of inspiration
😉), this detailed screen could be the entry point for further (enhanced) processing. E.g. if you directly want to trigger a change of stocks and/or trigger a direct supplier returns after GR posting for defective delivered items, this could be a suitable place to implement the enhancement.
5. Great Error handling
Mentally coming from GR through MIGO or IDoc I really like the apps error handling. At least in manual posting mode posting errors on single items do not hinder the posting of the other items. All items will be posted, only the erroneous items remain and the respective errors can be easily displayed:
Since in general
all entries (not just errors) are immediately saved in staging tables even without “posting”, errors can be processed later.
6. Scanning of an article that’s part of another document leads to a direct switch to this document
If you are working on a GR of a specific document and scan an article that’s not ordered / advised in this document but in another that fits the filter criteria (!) you’ll automatically switch documents without ending/posting the current document or even a warning message. This can be very cool on the one hand, because it does not interrupt the work routine, everything can be recorded with minimal technical interference and as mentioned above your entries in the prior document are saved in staging tables. On the other hand you could leave a document without posting it without even noticing.
So you should be aware of this, since in standard procedure you need to reenter the document to hit the “post” button.
Therefore (at least) make sure to establish a checking routine for started, but not finally posted GR processes
😊 To be fair, the filters for processing status make this very easy to achieve!
7. Confirmation control key determines whether purchase orders are shown or not
The confirmation control key determines not only whether a GR can be posted with respect to PO or to inbound delivery, but also if the PO item is visible at all in receive products app. This doesn’t sound revolutionary and is in a way absolutely consistent with SAP GUI / MIGO, but it’s worth to keep in mind, since you need to do
something if an (expected) inbound delivery document is missing. Also, you may be able to use this feature for workarounds e.g. if you want to add additional items during GR that have not been ordered but delivered nonetheless
😉
The first item of the PO has no inbound delivery confirmation control key
In addition to the above mentioned features the app provides a bunch of entry points for enhancements on all frontend levels (see
Fiori Library) as well as a lot of BADIs for backend enhancement (listed in customizing).
To wrap it up: In my opinion this apps grants
out of the box a lot of features that come very handy in retail goods receipt process as well as great customizability. All in all it's a really great app!
Nonetheless I'd like to mention some (in my opinion) outstanding issues:
Apart from a lot of small things we need/want to enhance to adjust to our specific process I have two general issues:
- In standard there is no way to control the use of “trusted Mode” (is it allowed for a specific vendor or not?) in the Business Partner / Supplier Master Data. Who wants to leave this decision to the user!?
- A report for retrying of the GRs with status “Error” in the background (like BD87 for Idocs) just to eliminate “Material 123 is locked by User XY” and other circumstantial errors without burdening a user would be very helpful in general.
If you have some input regarding these issues (maybe I missed something) or if you want to add anything, please comment below
😊
I hope this post shed a bit light on some "hidden" features and helps a great application to get the recognition it absolutely deserves!
Best regards
Boris Plum