Skip to Content

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).

/wp-content/uploads/2015/09/image001_797740.jpg

Schedule line assignment = ‘CP’.

Item category for the implied empty:

/wp-content/uploads/2015/09/image002_797762.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:

/wp-content/uploads/2015/09/image003_797763.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:

/wp-content/uploads/2015/09/image004_797764.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)./wp-content/uploads/2015/09/image005_797765.jpg

Credit management settings:

/wp-content/uploads/2015/09/image006_797766.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:


  1. 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).
  2. Billing types without empties update – maintain all proforma types and intercompany billing types to avoid incorrect empties movement registration.
  3. 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.

/wp-content/uploads/2015/09/image007_797767.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:

/wp-content/uploads/2015/09/image008_797768.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.

/wp-content/uploads/2015/09/image009_797769.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.

/wp-content/uploads/2015/09/image010_797770.jpg

6 Assign item categories for empties – settings for the exchange process:

/wp-content/uploads/2015/09/image011_797771.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.

  1. 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.
  2. 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.
  3. 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.

/wp-content/uploads/2015/09/image012_797772.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:

  /wp-content/uploads/2015/09/image013_797773.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:

  /wp-content/uploads/2015/09/image014_797777.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:

  /wp-content/uploads/2015/09/image015_797778.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.

/wp-content/uploads/2015/09/image016_797779.jpg

BOM for exploding the returned empty code:

  /wp-content/uploads/2015/09/image017_797780.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

/wp-content/uploads/2015/09/image018_797781.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).

/wp-content/uploads/2015/09/image020_797782.jpg

Delivery creation result:

  /wp-content/uploads/2015/09/image021_797784.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):

  1. 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.
  2. New deliveries for correction postings are created.
  3. Goods movement is posted for all selected deliveries (original and new).
  4. Billing is executed.
  5. 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:

/wp-content/uploads/2015/09/image022_797786.jpg

  /wp-content/uploads/2015/09/image023_797785.jpg

Reporting for returnable containers:


Balances for the deposit account (FS10N):

/wp-content/uploads/2015/09/image024_797787.jpg

Empties evaluation report (/BEV1/EMS):

/wp-content/uploads/2015/09/image025_797788.jpg 

Details per account holder/material:

  /wp-content/uploads/2015/09/image026_797792.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.

  /wp-content/uploads/2015/09/image027_797793.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.

  1. Create a new item usage – ZNEX – No empties exchange.
  2. Create a new item category for the FG as a copy of ZAR and change only the structure scope:

/wp-content/uploads/2015/09/image028_797794.jpg

3. Set up item category determination:

/wp-content/uploads/2015/09/image029_797795.jpg

4. Create customer-material info record and set only the new item usage:

/wp-content/uploads/2015/09/image030_797796.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.

To report this post you need to login first.

6 Comments

You must be Logged on to comment or reply to a post.

  1. Shiva Ram

    I never worked on this area. But I could feel your effort providing as much as information, with detailed explanation. This document is not only going to help the folks who is currently working in this area but the ones, who will work on this.

    Thanks for sharing your knowledge. Keep the good work!!!

    Kind regards,

    (0) 
  2. Typewriter TW

    Veselina,

    very good effort! thanks!

    ZAR – BOM

    ZAI – implicit empties

    ZRU – return empties

    1. weight, Empties returns: why is weight not relevant for ZRU?

    The same empties material which is sent to customer, is also returned, this material master contains the weight information, so why is it not taken into consideration in the returns empties process?

    2. order entry, no empties returs: As I understand, the setup in T184 makes the BOM (ZAR) and explodes both ZAI and ZRU in the order. If returns empties is not required, then user needs to manually delete this line item from the order.

    How is the commnication setup (maybe out of SAP) that for a particular order, empties will not be returned (this is before delivery creation and warehousing activities)?

    3. stock maintenance for implicit and return empties:

    In section Document processing, delivery creation, the implicit empties (ZAI) does not show movt type (because ZX does not have movt type). Does this mean, stock is maintained for return empties and not for implicit empties?

    4. “since the warehouse personnel could update directly the actually returned containers as a manual item in the outbound delivery upon customer arrival,”:

    At what time frame do the warehousing staff update /change the quantity of return empties (after few days of dispatch of truck to customer)? If there is some quantity in order and that quantity is changed in delivery, will there be a mis-match?

    5. different process:

    Suppose company wants to create a separate line item for return empties in the order, this is not possible because of current T184 setup. If we do set it up with ZRU, will there be any impact on the report you have described?

    thanks again!

    TW

    (0) 
    1. Veselina Peykova Post author

      1. ZRU is set as not relevant for weight check, because if you set it to weight relevant, the total weight and volume in the outbound delivery (which is used for capacity calculation) will be incorrect – e.g. if the liquid weight = A and container weight = B, the outbound weight should be A+B, but in this case you will get A+B+B, which might be a problem if the transportation planning algorithm considers the total delivery weight/volume in a planning prestep.

      2. When the customer orders products, the clerk always asks the question about empties – this was actually an already established procedure in the company so we did not need to perform change management.

      3. Only the untied empties can be seen as stock in the warehouse in inventory management. When we produce the finished product, we consume the empties as a part of the production BOM. So if you would like to know how many empties you have in the plant, you need to get the sum of all untied empties and the implied empties for the products that use the specific empty code and are part of the plant stock.

      4. Pickup process means that the customer comes to the plant with his own truck to buy products. When he arrives at the plant, the truck is checked at the gate and whatever is on the truck is recorded on papers (I believe this is the standard procedure everywhere – no matter if you use SAP or not). When the customer arrives at the warehouse, he unloads the empties and the warehouse checks them for breakages etc. Then the clerk updates the outbound delivery for FG with the actual quantity of returned empties by adding a manual return item with the respective empties code. The FG are in the meantime prepared for loading. The delivery is also updated with the quantity of picked FG. The warehouse post goods movement and print documents for the customer (the process may or may not include payment at a cash desk – depending on the payment term used).

      In plant sales we have only a single transfer of responsiblity for empties/FG – between the customer and the warehouse employee, which can be registered at the time when we execute the sale. In the DSD process the specific is that we have several transfers of responsibility for FG products/containers and the proformas are printed at the time the truck leaves the plant premises (we do not have the empties yet on our truck, we expect to receive them during the visit at the customer).The actual quantities of FG/empties are registered after the truck comes back, check-in is performed and route settlement is executed. With plant sales we skip most of these steps and register the quantities delivered/received directly.

      It is technically possible to use empties exchange for plant sales, but it is not really that useful.

      In case of DSD changes to delivery execution – such as less FG accepted/different quantity of empties received, the driver records the changes on the proforma and both he and the customer sign the document, which serves also as a protocol for receiving products. The date of check-in (truck comes back to the warehouse) depends on the route duration – can be the same day, in extreme cases can take a week. Route settlement (the step where the actual quantities per customer delivery are recorded in the system and goods movement is posted happens usually on the same day or the day after the truck check-in).

      5. The empties report is based on item category settings, so it will work withoot problems.

      Unfortunately there are several problems with additional manual ZRU item – if it is not part of a BOM and we have stock-out of FG for check B, we will execue a visit to receive the additional empties without delivering any FG and because this is not part of 1:1 exchange we do not have any reserved space on the truck for them. It is possible as a workaround to use a second item in the empties BOM as an entry aid without quantity correlation (quantity = 1), but it will be quite inconvenient and annoying to delete the item when it is not needed. So in case of manual ZRU items usage somebody should check LF deliveries that have only ZRU items (which can be tedious in case of large number of documents per day, but still can be done).

      The second potential problem with using ZRU as an additional item in a standard order is that you can achieve negative credit exposure by abusing the fact that ZRU is relevant for credit update. Also you have to ensure that you have sifficient space on the truck for the additional empties by comparing ZAI/ZRU quantity for all delvery items in the shipment per empties type.

      From my perspective it would be better to use a separate return order and delivery for the additional empties, not update the credit exposure, reserve space on a truck (even if we risk that it can be a different vehicle) compared to problems wih audit and possible delays in transportation planning.

      Another possible scenario is not to plan the excess of returned empties at all and handle them as an unplanned empties return during customer visit in case the driver has sufficient space on the truck. The driver will add the additional return empties in the proforma as a separate item to serve as a proof of receipt and the final invoice/invoices can be sent upon request after route settlement and billing is executed.

      (0) 
  3. Luís Lemos

    Hi Veselina,

    I would like to thank you for all this information.

    I would like to ask you some doubts I have:

    1 – Why don’t you have a movement type associated with 122 for sale?


    2 – How do you manage, on the financial level, the empties:

    a) How do you create the bank deposit movement? we had thought on the process (D – bank; C – Special client account)

    b) When the empties are transferred to the cliente, how do you register that in the reconciliation account? We had thought in the process (D – special costumer account; C – Transitory account)


    Thanks again.

    LL

    (0) 
    1. Veselina Peykova Post author

      Hello Luis,

      1 – I have mentioned the reason in the blog – you have reduced the quantity of material 122 in Inventory management, when you produce the finished product. After that, the implied (tied) empty 122 is part of material 8042, there is no need to perform an additional movement in IM.

      2 – Probably there is some misunderstanding what empties deposit means in Beverages industry. The client receives returnable containers when he buys the finished product. There is no transfer of ownership of the crates/bottles at that time (companies state that on the customer invoice). You collect a deposit (a fraction of the price for returnables) to ensure that you will get them back. When the customer returns empty crates/bottles, you will give the money back (30.00 in my case). The client pays the initial deposit, when he sends money for purchasing the finished product (the liquid), there is no separate transaction for sending a deposit for empties.

      I do not understand what you meant by Special client account, there is just one customer account, when you pay for products by bank transfer. If you meant the account holder for empties, you don’t actually need to use that for financial postings, it can be even a hierarchy node grouping several payers. It is mainly used for reporting purposes. If you need to sell empties to the customer, this is a separate process for sales of fixed asset.

      (0) 

Leave a Reply