After several years as a SAP consultant, sometimes I find myself guilty of trying to tackle a seemingly difficult problem by first going through SAP notes, then searching the online documentation and checking SMOD for a possible solution. Back in the days, when I did not have any previous project experience, armed only with the .CHM SAP help version, I might have handled the situation differently and surprisingly – better. It may seem illogical at first, but gaining more experience could act as a ‘blind spot’ and instead of going through SPRO and master data (as you probably did as a junior), you find yourself rushing to an ABAPer with a new development specification, which looks stunningly similar to the specifications you wrote during your previous 5 projects.
Returnable containers exchange, which I will use as an example, is a very common scenario in the beverage business. In some companies it is realized by complex developments, in others – it is left out as a purely manual process. There is a good reason behind each of the possible methods – external systems involved, agreed project scope and budget, availability of resources, project deadlines, the level of process standardization in the company, the possibility of change management and so on.
There is also this really simple and cheap alternative that a junior consultant could have come up with.
A junior consultant does not refer to the person’s position neither implies inferior skills – it describes a person who is relatively new to a certain area.
Business case:
The usage of refillable containers for produced products in beverages industry has not only environmental benefits, but also substantially reduces the costs-per-filling compared to one-way RGB bottles, one-way PET bottles, carton packaging. In case a product in returnable container is sold, the company charges a deposit to the customer, which is returned on receiving back the empty containers. A very common business practice is after the initial delivery to establish a process where the customer returns the same quantity and type of empty containers as the quantity of purchased products.
Benefits for the producing company in RC exchange scenario:
- Timely collection of containers which can be used for further refilling;
- Reduction of transportation costs (the empty crates when returning from customer visit occupy the same space as the delivered FG).
Benefits for the customer:
- After the initial delivery he is basically charged only for the ‘liquid’. Deposits from customer’s perspective are money that he cannot use for investing in his own enterprise.
Challenges:
If the company is not able to deliver the FG on time (insufficient stock or temporary credit issue) no separate visits for empties collection and for FG delivery should be scheduled – the current order should be fully rejected and a new order for empties return should be created and planned (as a part of the order cleaning procedure). The reason behind the decision for no separate visits is to have a better utilization of truck capacity and lower transportation costs.
The company needs to track the containers per type both by value and quantity for each domestic customer and to be able to perform reconciliation between the quantity and value of the containers and the balances on the deposit account/accounts.
This idea aims to minimize the effort in ERP during order entry and route settlement process and to cover most of the described company requirements without an additional development.
The purpose of showing some of the customizing settings is not to create a general ‘how to configure the process’ and there are no revolutionary discoveries presented (you would not expect too many revolutionary discoveries from a fresher, anyway). They simply illustrate what you can achieve by applying some basic SAP knowledge in a slightly different manner to address a customer requirement – something that a junior consultant could do.
Setup for standard sales order
Item categories:
Item category of the main item (FG)
Notable fields: the item is pricing and billing-relevant, schedule lines allowed = ‘X’, credit active = ‘X’, structure scope = ‘B’ and application = ‘SD01) (I will use multi-BOM explosion and sales BOM); create delivery group = ‘A’ (to ensure that both implied and returned empties are kept together).
![image001.jpg]()
Schedule line assignment = ‘CP’.
Item category for the implied empty:
![image002.jpg]()
Important fields: the item billing relevant, pricing for empties, credit exposure should be updated, schedule lines are allowed.
Assignment to schedule line = ‘ZX’ – no goods movement, no ATP, no requirements transfer, relevant for delivery. The item is used to collect the deposit and track empties at the customer’s premises. The goods issue for implied empties is performed during production order confirmation.
Item category for return empty:
![image003.jpg]()
Notable fields: pricing for empties, no weight/vol. relevance, billing-relevant, schedule lines allowed, returns = ‘X’, update credit exposure.
Incompletion procedure assignment: copy of 20 without weight checks.
Schedule line assigned = ‘DN’ (movement type 651, no ATP, no requirements transfer, relevant for delivery).
Item category assignment:
![image004.jpg]()
(ZARN is used for BOM-relevant products with % discount based on manual setting of KVGR1 to a specific value).
Pricing:
Main item – relevant for base price, discounts, VAT.
Implied empty – relevant only for deposit, value collected in CMPRE.
Return empty – also relevant for deposit, value collected in CMPRE.
Pricing requirement for deposit condition – checks for pricing relevance = ‘A’ (to be on the safe side).![image005.jpg]()
Credit management settings:
![image006.jpg]()
Delivery item categories specifics:
Main item: relevant for picking, determine storage location, storage location required, check quantity 0, check over delivery dismissed with error.
Implied empty – no storage location required, no picking relevance, check quantity 0 and check over delivery dismissed with error.
Return empty – determine storage location, storage location required, check quantity 0 and check over delivery dismissed with error, not relevant for picking.
Copy control VTLA, VTFL for all item categories.
The tracking of returnable containers is achieved by using empties update functionality in billing.
Prerequisite: you need to have EA-CP active in SFW5 to use empties update.
The settings relevant for the process are in SPRO->Sales and Distribution->Billing->Empties Update.
Empties management settings:
- Material types that determine empties – set the material type used for RC (in the standard system this is LEER, in my case this is a separate material type for non-valuated materials with quantity update for the valuation area).
- Billing types without empties update – maintain all proforma types and intercompany billing types to avoid incorrect empties movement registration.
- Maintain empties account holder – SAP suggests a choice for account holder between payer, sold-to, ship-to, bill-to party as account holder, but it is also possible to set a custom partner function and in this way to be able to group several customers for reporting purposes. I chose to use 3A – Customer chain, which I have set up as a level in the customer hierarchy. This partner function is transferred to the respective sales document types.
![image007.jpg]()
Log empties update – a useful feature to track each step of empties update in a greater detail during the test phase. It should be switched off for productive environment. The log is in table /BEV1/EMLGFS:
![image008.jpg]()
4. Manage empties fields – the defaults provided by SAP are sufficient for most companies, but in case you have a requirement for a more detailed reporting, you can use additional quantity and value fields.
![image009.jpg]()
5. Calculation matrix for empties – this is where the main logic for empties balance is defined. It is extremely important in case you define additional empties fields to update them correctly into the respective formula, otherwise it will be impossible to perform reconciliation between the empties register and the deposit account balance.
![image010.jpg]()
6 Assign item categories for empties – settings for the exchange process:
![image011.jpg]()
Here only the assignment for some of the item categories for the process is displayed– you also need to assign the item categories for debit/credit memos (only for value fields update), free deliveries and returns to get an accurate representation in the empties register.
7. You can maintain empties groups in case you wish to group several materials with the same deposit price for reporting and printing purposes.
How empties management works?
Empties update is performed at the time of billing document generation, when certain requirements are fulfilled.
- The billing type should be relevant for empties update. If it is not relevant for update, the billing document is stored in table /BEV1/EMLOGFS with LGOF = ‘F’ – suppression of update using billing type.
- The partner function for account holder should be present in the billing document. In case of missing partner function the document is recorded in table /BEV1/EMLOGFS with LGOF = ‘P’– suppression of update as partner not found.
- It is possible to restrict empties update for a specific customer by setting the indicator Empties Update from = ‘X’. Such billing documents are recorded in /BEV1/EMLOGFS with LGOF = ‘D’– suppression of update using indicator on customer.
![image012.jpg]()
4. The material type of the item should be specified as empties material.
5. The item category for empties should be assigned to the fields for quantity/value.
When all of the prerequisites are fulfilled, the billing document items containing empties are stored in /BEV1/EMLGBDP with the Q and V fields updated with the logic from the empties matrix and the pricing data of the document, reference documents for the billing, billing date etc.
In addition the data from V and Q fields is stored in aggregated form in /BEV1/EMLGBSD – per account holder, month and material number. It is used to prepare empties balance confirmations for the customer and for internal reporting purposes.
Calculation example:
![image013.jpg]()
ZAR is excluded from the calculation based on material type.
ZAI and ZRU are checked against the assignment to empties fields.
ZAI should update Q1 and V1.
ZRU should update Q2 and V2.
Q1, Q2, V1 and V2 are part of the formulas defined in /BEV1/EMMATRIX_V (calculation matrix for empties).
ZAI updates V13 – difference del./returned value
As V13 is part of the calculation of V14 – individual price /vs quantity, we are updating it as well, similar logic for V16 – total value for delivered empties in the new period.
ZAI also updates quantities – Q13 for calculating difference between returned and delivered,
Q16 total delivered quantity for the new period; it influences the result in V14 (also in the quantity part of the calculation).
Result in /BEV1/EMLGBWDP for RECHNR = billing document number:
![image014.jpg]()
In addition to the empties account holder number, the payer, ship-to and sold-to parties are also recorded in the table, which allows performing also detailed analysis for empties transfers.
Updates in /BEV1/EMLGBSD:
For each combination of empties partner, sold-to, ship-to, bill-to, payer and material number for a specific sales area a separate line is recorded per period (MMYYYY). There are separate V* and Q* fields for the balances of the old and new period. My customer is a new one, so I have zeroes for the old periods (non-zero values only in TO* (total) and BN* (new balance) fields:
![image015.jpg]()
Note: Empties tracking in general will not work very well with the standard approach for Advanced Returns Management, since it relies on billing documents for empties register updates. Still it is possible to record the returned containers by using a dedicated billing type without FI postings (with the assumption that ARM is used as originally intended – returning of products from the customer for the finished product (e.g. due to quality issues) and not for value adjustments of the returnable containers).
Empties management functionality observations
The good part:
It is extremely easy to set up empties management update in SD and fulfill the customer requirements – you need:
- to understand the different properties of item categories in the sales processes (basic SD knowledge);
- knowledge of basic arithmetic operations (skill obtained during 1st -2nd grade at school)
- only the standard authorizations granted to functional consultants.
A nice ALV report for empties balance (most users prefer this type of representation).
Balance confirmation printout - SAPScript is delivered by default, it is technically possible to use a smartform or a PDF form as well for empties balance confirmation (with an additional development).
Archiving functionality is provided.
It is easy to correct the empties balance in case the reason is a missing partner or incorrectly assigned/not assigned item category.
Despite what the name suggests, you can use this functionality to track not only returnable containers, but also all kinds of fixed assets at the customer’s premises without having equipment master data in the system.
The bad part:
The idea behind and the functionality for empties tracking is good, but does not have the look and the feel of a finished product. While most of the customers’ requirements could be covered by what is provided as standard, it would be good to have the option to switch on logging of empties update for a specific partner in the productive environment without flooding the database with thousands of records for all other partners (when you cannot reproduce some issue in the development client).
You cannot get empties update for NLCC originating documents per empties code without an additional development (because PO/STO BOM explosion is not provided in standard). It seems a strange design decision to deliver a sample BAPI for BOM explosion with hardcoded account assignments instead of providing some customizable logic that can be used out-of-the-box.
The really bad part:
In case you need to change empties calculation matrix after the initial implementation in the productive environment, the process is extremely difficult (when it is possible at all), not straightforward (you have to figure it out by yourself considering what you change, when-number of documents affected, archived data, usage of balance confirmations, what is the current and the future setup). Even SAP advises not to do that, because this will cause inconsistencies in the database.
In the unlikely (or not so unlikely, judging by the number of notes and available correction reports) event of corruption of the empties tables, the reconstruction process takes a lot of time, involves running several reports in a certain sequence with specific selections, you have to ensure that no empties updates occur in the meantime (this essentially means to stop all billing activities, which is considered as a serious business disruption).
605075 - Documentation for reconstruction Beverage empties tables
Q: Can we simply achieve this traceability with a list of all billing items with specific item categories in a SQ* query? You do not need a developer to do that.
A: Yes, but it will be slow, because the data is not aggregated. And you will not have balance confirmation printouts. It would be better to use BW for such kind of reporting instead of queries.
Q: Could this be achieved with LIS?
A: Yes. You will still need a developer to produce some professionally-looking balance confirmation forms, though. The forms are quite simple, so the effort estimation will not be really high.
Q: Could this be done with a custom development instead?
A: Yes, you can create your own logic to populate z-tables, create reports and print balance confirmations that use the data from these z-tables, set authorizations for the new transactions, create service reports for the support team to fix potential problems etc. You will need to consider the archiving aspect and as well. Depending on the skill of the developer and the quality of the solution proposal, the end product could be a really great and reliable functionality. It will also be a very expensive one, which requires a lot of effort in development and testing.
Master data specifics:
Customer master data:
‘Empties Update from’ should be ‘ ‘ – we do not need exceptions from empties update for any trade customers.
Credit master record exists with risk category maintained for the credit control area and document credit group with activated dynamic credit check.
Material master data:
FG – separate item category group for BOM-relevant materials in order to determine a different item category than TAN.
The implied empty uses LEER item category group.
The materials involved should be extended for the relevant plants and storage locations.
BOM setup:
There are 2 bills of material used for the process. Both are with usage 5 – Sales and Distribution.
FG BOM with implied empty code:
Material code – FG product, component – implied empty code for sorted bottles. For the implied empty we need to have quantity correlation.
![image016.jpg]()
BOM for exploding the returned empty code:
![image017.jpg]()
Material code – sorted implied empty.
Item 1: the same material code for sorted bottles (recursiveness allowed = ‘X’).
In case the customer returns unsorted empties of the same size and the same deposit price, you can use a separate material code for the second BOM - then recursiveness is not needed.
Document processing:
Order entry:
Upon entering the material code of the FG, the implied empty and return empty are exploded with quantity dependent of the FG quantity.
Default view – 1:1 exchange
![image018.jpg]()
Processing variant 1: first fill or no available empties for return – delete the ZRU item
Credit control:
In case of credit block the exposure is not updated at all.
In case of partial confirmation – the credit price for the FG is taken from the confirmed quantity, ZAI and ZRU with material 122 offset each other (so the fact that they are not relevant for ATP does not cause a problem for credit price).
![image020.jpg]()
Delivery creation result:
![image021.jpg]()
Due to the correlation the quantity of material 122 is adjusted to the FG quantity.
As all items are relevant for delivery, the value from S066 (open orders) is moved to S067-OLIKW (open delivery quantity).
Only the FG is relevant for picking.
No specifics for this process related to transportation planning.
The process is intended to be used mainly in the context of paper-based DSD pre-sales scenario.
When selling products directly from the plant there is not a very significant benefit of using such technique apart from the initial credit price calculation, since the warehouse personnel could update directly the actually returned containers as a manual item in the outbound delivery upon customer arrival, post goods movement and handle the final invoice.
Delivery execution:
In the DSD process at shipment completion no material documents are posted.
Shipment output DSDP is used to trigger the printouts of the outbound deliveries, which are assigned to proforma billing type (this is used to print valuated delivery notes, which in case of no changes to the delivery execution are the ‘official’ documents received by the customer.
The proforma billing types are excluded from updating the empties register.
Route settlement:
The settlement clerk receives copies of the valuated notes signed by the driver and the customer, which serve also as acceptance protocols. In case of changes to the delivery quantities indicated on the printed documents, the items are updated manually in the delivery execution tab.
During FSR (final settlement run):
- New orders are created or the original orders are updated (for example the billing block is reset, new items are added – depending on the settings of the determined customer sales transaction type). For my case the original orders are updated with correction items and the billing block is reset.
- New deliveries for correction postings are created.
- Goods movement is posted for all selected deliveries (original and new).
- Billing is executed.
- In case of cash collection clearing is also performed.
At point 4 the empties register is updated.
Important note on DSD CSTT determination – with sap note 1701162 - Incorrect processing of returns items SAP changed the logic for determination of whether a delivery item change should be treated as an increase or decrease and considers /DSD/HH_RADELIT-TA_CODE values (which affects the customizing related for RC exchange).
Related sap notes for DSD:
1819489 - Incorrect processing of new returns items
1823436 - No customer sales transaction type for new items
1971555 - DSD: Incorrect processing of new returns items
Billing:
![image022.jpg]()
![image023.jpg]()
Reporting for returnable containers:
Balances for the deposit account (FS10N):
![image024.jpg]()
Empties evaluation report (/BEV1/EMS):
![image025.jpg]()
Details per account holder/material:
![image026.jpg]()
Documents without empties update (table /BEV1/EMLOGFS)
The table can also be used as a basis for creating a query with an optional authorization check per sales area. It is used in case discrepancies are discovered between FS10N and /BEV1/EMS.
![image027.jpg]()
In the example all documents with billing type IV are excluded from empties update based on the customizing settings for empties update. Billing document 90038179 is not updated because of missing empties partner (the customer was not added yet to the customer hierarchy at the time of billing document creation).
Process variant 1: No agreement for empties exchange (yet) with some of the customers
As the company does not have a unified approach for a specific process, this will be at the cost of additional master data maintenance. It is possible to create a separate document type, but it will result in additional effort for setup (including the adjustment of authorization roles) and a higher learning curve for the employees. Even in the case of pure custom development to check for a specific customer property there should be some criteria in the master data or a z-table that somebody maintains and reviews.
- Create a new item usage – ZNEX – No empties exchange.
- Create a new item category for the FG as a copy of ZAR and change only the structure scope:
![image028.jpg]()
3. Set up item category determination:
![image029.jpg]()
4. Create customer-material info record and set only the new item usage:
![image030.jpg]()
As a result: during sales order creation the information is first read from the CMIR (setting in VOV8 Read infor record = 'X'). Usage ZNEX is determined and we get ZARX for the finished good and only ZAI for the implied empty.
Process variant 2: Empties exchange process is acceptable only in some of the locations
Some distribution centers do not have a dedicated warehouse to store empty crates. This means that the agreement for empties exchange can be valid only when the customer orders from a production location or a DC, which can store the returned empties.
When creating the BOMs for the plant, maintain only the first BOM (for the FG and implied empty).
Note: in case of CRM order creation, the approach cannot be used, because you can have only one BOM per product.
Always remember: if you find a KBA deserves some recognition, you can give it a star rating on the top right corner!!!
