Introduction/Business reason
Very often there is a question or requirement from Retail business to see real available stock of store in the system. For manufacturing or logistics industries (excluding decentralized operations or systems) this is rather easy task with usage of the Available to Promise (ATP) functionality as its wide configuration range should be a sufficient source of store’s real available stock including current stock and planned future operations. On the other hand, we can use the inventory view transactions like MMBE or MD04. For Retail industry, transactions mentioned above might be a bit misleading for store’s real available stock visibility where typically aggregated sales flow is applied. Why ?
Aggregated POS sales flow
Common sales flow in Retail industry with SAP is started at POS by sales of goods and then transfer the transaction to SAP CAR. Interval of time when POS transactions are transferred from POS to CAR is set individually per company but usually it’s either immediately or between 5 -30 minutes (mainly this interval depends on POS system capacities and volume of data to be transferred). Sales POS transaction received in SAP CAR can be processed in different ways based on business requirements set by specific CAR configuration like transaction types and group of tasks assigned to them. In principal, we need to split processing options into either individual where each sales POS transaction is reported separately into S/4 (or ECC) or aggregated where at CAR, POS transactions are cumulated into packages and sent periodically to S/4 system. In both cases moment of time when individual or aggregated POS transactions is triggered to S/4 depends on SAP CAR configuration but for aggregates it’s mostly once per day.
Processing of sales POS transactions in aggregated way is almost mandatory as without it SAP S/4 would end up with receiving data of a single sales transaction to be posted separately, means lot of articles documents (goods issue) and SD billing objects created. Unfortunately, aggregation of sales data in CAR besides its performance advantage has disadvantage for stock visibility due to package with aggregated data is mostly distributed once per day from CAR to S/4, means goods issue of sold articles (or goods receipt for returned) is posted at the same time and leads to stock quantities discrepancies in short period of time between aggregate postings and real sales of goods.
SAP CAR real available stock calculation
In case of SAP CAR real available stock is calculated based on values of S/4 stock figures that are transferred to CAR via SLT in nearly real time. Then with usage of not yet distributed to S/4 POS sales transactions stored in aggregates (more preciously in table /POSDW/TLOGUS) system is able to calculate current store stock level. In case of OAA functionality system is calculating stock based on the CDS views and Hana DB procedures.
SAP S/4 real available stock calculation
In S/4 real available stock can be used in multiple of places starting from ATP check in sales orders where delivering plant is our store or with native Fiori application used on handhelds in the store or ending with fully custom-built applications.
With Fiori application you can use it with:
SAP S/4 to calculate real available stock follows the same approach as SAP CAR with the single difference that current stock is available at S/4 and only not yet processed POS transactions need to be fetched from CAR and taken into consideration for calculation of real available stock.
Configuration at CAR
To activate mentioned calculation of the real available stock at CAR we need to perform configuration in number of areas including setting up the worklists and changing a bit tasks to activate index functionality on them.
Worklist is nothing else then a list of POS transactions on which some work still might be done. Entry on worklist is usually created when POS transaction is recorded in CAR but it can be as well some other event that triggers the creation of entry like execution of aggregation task on transaction. Similar some other activity is removing the entry from worklist (in our case it’s a confirmation of processing aggregate in S/4).
Each store prolife must have associated one worklist where Master Data checkbox is selected to include material enrichment (field MaterialNumer is populated based on ItemId field) when POS transaction is saved. Otherwise Material determination is done when task is executed, or POS transaction is loaded into POS Workbench.
To execute the lookups for stored in CAR but not yet processed transactions in S/4 we need to have at least two worklist entries that are calling BADI filter 0003 and 0004
Standard 0003 Worklist will add POS transaction to /POSDW/TLOGUS table and removal of records from processed aggregated package is done when the confirmation is sent from S/4.
Standard 0004 Worklist is needed as well to remove from /POSDW/TLOGUS table transactions that are reversed by post-void transactions. The process is triggered by Aggregation task processing and calls same BADI as previous worklist processing.
In documentation from SAP there is an information that for compatibility reason with ECC we would need to have as well worklist 0001 that is called by function module /POSDW/SALES_QUERY_RFC. In S/4 environment fetch of unprocessed transactions is done via RFC call of function module /POSDW/UNPROC_SALES_QUERY_RFC.
The next step as part of CAR configuration is to setup the index for aggregating task. By standard, system will not store any information about individual transactions stored in package. When this indicator is activated, table /POSDW/AGGRTI is populated by system with POS transaction indices while building the aggregate and allow system to know which POS transactions to delete from /POSDW/TLOGUS when package confirmation is received.
Last part of CAR configuration is to set in outbound task that processes the aggregates to expect the confirmation of processing from S/4 system. If the indicator is set then status of package will be changed only when confirmation is received.
Configuration at S/4
When we would like to fetch data from SAP CAR in S/4 the first configuration that is naturally required is to setup RFC connection in S/4 to CAR. It’s a regular RFC connection of type 3 – Abap Connection.
The next step is to setup the confirmation of Idoc processing with aggregated data in S/4. CAR system does aggregation and then package is sent to S/4 via Idoc. At that moment despite the Idoc has been triggered still package status in CAR isn’t “Completed”. Status of package will change when Idoc processing is finished in S/4. To let know to the S/4 system that confirmation is required we need to set it up at the level of POS Inbound profile (Aggregated sales control). When confirmation is received in CAR as set in worklist configuration entries from table /POSDW/TLOGUS are removed for respective package.
Here is worth to mention that system is designed in the way that only one confirmation is triggered. That unfortunately means that if there is any error with Idoc processing even for single article (and the remaining were posted) still no confirmation is sent to CAR and no entries removed from table /POSDW/TLOGUS and S/4 Fiori apps are displaying inaccurate information (GR/GI has been posted but Fiori still takes information from CAR of unprocessed sales).
When sending confirmation has been requested S/4 system needs to know where to send it. RFC connection to can has been already created (in previous step) not assignment between POS Inbound profile with RFC Connection is done.
The last step of the configuration at ECC side is to activate real stock calculation for Fiori applications. Please be aware that cycle count configuration requires further steps then only the ones mentioned here.
As you can see beside activation of integration with CAR as well RFC Destination to CAR is required where function module /POSDW/UNPROC_SALES_QUERY_RFC will be called. Additionally, there is option to enter number of minutes to fetch unprocessed sales as a scheduled job for Move Product application (more about it later on). In you use version of S/4 lower then 1909 you activation screen will look different (only RFC Destination) and activation is done via BADI BADI_RTST_CAR.
Example of processing:
Current stock is 3 PC and there is no pending aggregated sales for this article in CAR.
Registering one sales transaction in CAR with this article for quantity of 1 PC. New record in table /POSDW/TLOGUS is created
And Look UP Retail Product shows as expected only 2 PC
As already mentioned before worth to pay attention is the way the processing of aggregated sales works in S/4 and when the package confirmation is sent back to CAR. Usually in WPUUMS (aggregated sales) Idoc you have more then one article and some of them can end up in S/4 with error due to number of reasons, example of insufficient stock (and negative stock is not active). In this case S/4 system will post PGI and create SD billing document for articles that don’t have error, Idoc is in status not processed (status 51) and package confirmation is not sent back to CAR.
This cause in my opinion some inconsistency between S/4 and CAR stock figures as package is not confirmed, for some items from Idoc, PGI has been posted but still if you check in application that display real stock it takes S/4 current stock (already deducted) and as well entries form /POSDW/TLOGUS table in CAR that were not cleared because of lack of package confirmation.
Solution could be to change in CAR in worklist processing, deletion action to outbound processing of aggregation follow up task or pay particular attention to processing results of aggregation Idoc in S/4.
Hints
Very often there is a question or requirement from Retail business to see real available stock of store in the system. For manufacturing or logistics industries (excluding decentralized operations or systems) this is rather easy task with usage of the Available to Promise (ATP) functionality as its wide configuration range should be a sufficient source of store’s real available stock including current stock and planned future operations. On the other hand, we can use the inventory view transactions like MMBE or MD04. For Retail industry, transactions mentioned above might be a bit misleading for store’s real available stock visibility where typically aggregated sales flow is applied. Why ?
Aggregated POS sales flow
Common sales flow in Retail industry with SAP is started at POS by sales of goods and then transfer the transaction to SAP CAR. Interval of time when POS transactions are transferred from POS to CAR is set individually per company but usually it’s either immediately or between 5 -30 minutes (mainly this interval depends on POS system capacities and volume of data to be transferred). Sales POS transaction received in SAP CAR can be processed in different ways based on business requirements set by specific CAR configuration like transaction types and group of tasks assigned to them. In principal, we need to split processing options into either individual where each sales POS transaction is reported separately into S/4 (or ECC) or aggregated where at CAR, POS transactions are cumulated into packages and sent periodically to S/4 system. In both cases moment of time when individual or aggregated POS transactions is triggered to S/4 depends on SAP CAR configuration but for aggregates it’s mostly once per day.
Processing of sales POS transactions in aggregated way is almost mandatory as without it SAP S/4 would end up with receiving data of a single sales transaction to be posted separately, means lot of articles documents (goods issue) and SD billing objects created. Unfortunately, aggregation of sales data in CAR besides its performance advantage has disadvantage for stock visibility due to package with aggregated data is mostly distributed once per day from CAR to S/4, means goods issue of sold articles (or goods receipt for returned) is posted at the same time and leads to stock quantities discrepancies in short period of time between aggregate postings and real sales of goods.
SAP CAR real available stock calculation
In case of SAP CAR real available stock is calculated based on values of S/4 stock figures that are transferred to CAR via SLT in nearly real time. Then with usage of not yet distributed to S/4 POS sales transactions stored in aggregates (more preciously in table /POSDW/TLOGUS) system is able to calculate current store stock level. In case of OAA functionality system is calculating stock based on the CDS views and Hana DB procedures.
SAP S/4 real available stock calculation
In S/4 real available stock can be used in multiple of places starting from ATP check in sales orders where delivering plant is our store or with native Fiori application used on handhelds in the store or ending with fully custom-built applications.
With Fiori application you can use it with:
- Cycle count during opening hours
- Look Up Retail Products
- Move Products - Worklist Fiori application (F4231) available since S/4 1909.
- Custom application with Fiori or SAP GUI programs etc.
SAP S/4 to calculate real available stock follows the same approach as SAP CAR with the single difference that current stock is available at S/4 and only not yet processed POS transactions need to be fetched from CAR and taken into consideration for calculation of real available stock.
Configuration at CAR
To activate mentioned calculation of the real available stock at CAR we need to perform configuration in number of areas including setting up the worklists and changing a bit tasks to activate index functionality on them.
Worklist is nothing else then a list of POS transactions on which some work still might be done. Entry on worklist is usually created when POS transaction is recorded in CAR but it can be as well some other event that triggers the creation of entry like execution of aggregation task on transaction. Similar some other activity is removing the entry from worklist (in our case it’s a confirmation of processing aggregate in S/4).
Each store prolife must have associated one worklist where Master Data checkbox is selected to include material enrichment (field MaterialNumer is populated based on ItemId field) when POS transaction is saved. Otherwise Material determination is done when task is executed, or POS transaction is loaded into POS Workbench.
To execute the lookups for stored in CAR but not yet processed transactions in S/4 we need to have at least two worklist entries that are calling BADI filter 0003 and 0004
Standard 0003 Worklist will add POS transaction to /POSDW/TLOGUS table and removal of records from processed aggregated package is done when the confirmation is sent from S/4.
Standard 0004 Worklist is needed as well to remove from /POSDW/TLOGUS table transactions that are reversed by post-void transactions. The process is triggered by Aggregation task processing and calls same BADI as previous worklist processing.
In documentation from SAP there is an information that for compatibility reason with ECC we would need to have as well worklist 0001 that is called by function module /POSDW/SALES_QUERY_RFC. In S/4 environment fetch of unprocessed transactions is done via RFC call of function module /POSDW/UNPROC_SALES_QUERY_RFC.
The next step as part of CAR configuration is to setup the index for aggregating task. By standard, system will not store any information about individual transactions stored in package. When this indicator is activated, table /POSDW/AGGRTI is populated by system with POS transaction indices while building the aggregate and allow system to know which POS transactions to delete from /POSDW/TLOGUS when package confirmation is received.
Last part of CAR configuration is to set in outbound task that processes the aggregates to expect the confirmation of processing from S/4 system. If the indicator is set then status of package will be changed only when confirmation is received.
Configuration at S/4
When we would like to fetch data from SAP CAR in S/4 the first configuration that is naturally required is to setup RFC connection in S/4 to CAR. It’s a regular RFC connection of type 3 – Abap Connection.
The next step is to setup the confirmation of Idoc processing with aggregated data in S/4. CAR system does aggregation and then package is sent to S/4 via Idoc. At that moment despite the Idoc has been triggered still package status in CAR isn’t “Completed”. Status of package will change when Idoc processing is finished in S/4. To let know to the S/4 system that confirmation is required we need to set it up at the level of POS Inbound profile (Aggregated sales control). When confirmation is received in CAR as set in worklist configuration entries from table /POSDW/TLOGUS are removed for respective package.
Here is worth to mention that system is designed in the way that only one confirmation is triggered. That unfortunately means that if there is any error with Idoc processing even for single article (and the remaining were posted) still no confirmation is sent to CAR and no entries removed from table /POSDW/TLOGUS and S/4 Fiori apps are displaying inaccurate information (GR/GI has been posted but Fiori still takes information from CAR of unprocessed sales).
When sending confirmation has been requested S/4 system needs to know where to send it. RFC connection to can has been already created (in previous step) not assignment between POS Inbound profile with RFC Connection is done.
The last step of the configuration at ECC side is to activate real stock calculation for Fiori applications. Please be aware that cycle count configuration requires further steps then only the ones mentioned here.
As you can see beside activation of integration with CAR as well RFC Destination to CAR is required where function module /POSDW/UNPROC_SALES_QUERY_RFC will be called. Additionally, there is option to enter number of minutes to fetch unprocessed sales as a scheduled job for Move Product application (more about it later on). In you use version of S/4 lower then 1909 you activation screen will look different (only RFC Destination) and activation is done via BADI BADI_RTST_CAR.
Example of processing:
Current stock is 3 PC and there is no pending aggregated sales for this article in CAR.
Registering one sales transaction in CAR with this article for quantity of 1 PC. New record in table /POSDW/TLOGUS is created
And Look UP Retail Product shows as expected only 2 PC
As already mentioned before worth to pay attention is the way the processing of aggregated sales works in S/4 and when the package confirmation is sent back to CAR. Usually in WPUUMS (aggregated sales) Idoc you have more then one article and some of them can end up in S/4 with error due to number of reasons, example of insufficient stock (and negative stock is not active). In this case S/4 system will post PGI and create SD billing document for articles that don’t have error, Idoc is in status not processed (status 51) and package confirmation is not sent back to CAR.
This cause in my opinion some inconsistency between S/4 and CAR stock figures as package is not confirmed, for some items from Idoc, PGI has been posted but still if you check in application that display real stock it takes S/4 current stock (already deducted) and as well entries form /POSDW/TLOGUS table in CAR that were not cleared because of lack of package confirmation.
Solution could be to change in CAR in worklist processing, deletion action to outbound processing of aggregation follow up task or pay particular attention to processing results of aggregation Idoc in S/4.
Hints
- Sometimes entries are not deleted in CAR from table /POSDW/TLOGUS, then use report /POSDW/DELETE_TLOGUS
- In CAR there is a service to retrieve current stock in similar way how it is calculated in S/4. More details in this articles.
- Class CL_WPOSP_PROC_RESPONSE with single method send is used to distribute package confirmation.
- SAP Managed Tags:
