Creating tax groups can be very useful to handle the tax calculation in Brazil for different taxes (on Sales Orders, PO's and etc) , such as ICMS, IPI, PIS, COFINS, ISS, Tax Substitution, Withholding taxes and etc.
As taxes rates, bases and other taxes matters are very dynamic in Brazil, you will for sure need to have tax groups maintained in your SAP.

First you have to create the tax groups, then go to transaction J1BTAX (or you can go to SPRO - Financial Accounting (New) - Financial Accounting Global Settings (New) - Tax on Sales/Purchases - Calculation - Settings for Tax Calculation in Brazil - Tax Rates -Define Tax Groups for Dynamic Exceptions)


Then, select the Country BR

Country BR

At J1BTAX, go to Menu: Tax Calculation - Maintain Tax Group

Maintain Tax Groups

Before you select “New entries” let me explain what those fields on J_1BTXGRUOP means:

Tax Groups

In the Red Box – TAX GROUP – You can define groups in the range from 10 to 89. The numbers between 0 and 9 as well as between 90 and 99 are reserved for SAP. These groups should not be deleted. SAP delivers the groups 1, 5 and 97 to 99.
When looking for a tax dynamic exception, SAP will start from the smallest Tax Group to the Higher and stop searching then the 1st combination is found. Take this in consideration, building your groups from the most complex (smallest groups) to the less complex (higher groups)

The table below explains the usage of the tax groups delivered by SAP:

Tax Group Usage
1 MM: ICMS base reduction carrier
SD: ICMS base reduction customer
ISS rates (material-dependent)

5 ICMS, IPI, S.T. material-dependent exceptions
MM: ISS exceptions (dependent on ship-from, ship-to, material)

97 SD: IPI tax laws (based on NCM code)

98 IPI standard taxes (based on NCM code)
SD: IPI tax laws (based on country)
ICMS standard tax rates (based on ship-from and ship-to)
S.T. standard tax rates (based on ship-from, ship-to, S.T. group)

99 Default taxes (based on country)
SD: IPI tax laws (based on tax code)

In the Orange Box – TAX GROUP FIELDS 1, 2 and 3 – You can use between none and 3 possible keys combination to build the tax exception. The fields that are available are:

ASNUM- Service Number
MATNR- Material
MATKL- Material Class, Material Group
MWSKZ- Tax Code
LIFNR- Vendor
KUNNR- Customer
BRSCH- Industry Sector
CITYC- City Code
OIHMTXGP- Tax Group (Oil)
OIHVGROUP- Customer Tax Group (Oil)
OIHCGROUP- Vendor Tax Group (Oil)
USAGE- Tax Calculation: Material Usage
LOC_PR- Location of Service Provider
LOC_SE- Location of Service Provision
LOC_SR- Location of Service Customer
BUKRS- Company Code
WERKS- Plant
MTUSE_MARC- Material Usage (Material Master Record)
MTORG- Origin of Goods
CRTN- CRT Number
INDTYP- Industry Main Type
TDT- Tax Declaration Type
COMSIZE- Company Size
DECREGPC- Declaration Regimen for PIS/COFINS
LEGALNAT- Legal Nature
EXTWG- External Material Group
PRDHA- Product Hierarchy
GPART_KK- Business Partner Number

In the Green Box – CALLING APPLICATION – The ones that are valid for using are:
SD Sales and Distribution - it means that the exception will be valid only for the SD applications, like Sales Orders or Billing Documents for Example.
MM Material Management - it means that the exception will be valid only to the MM applications, like Purchase Orders or Invoice verification.
General - it means that, no matter if it is MM or SD, the exception for this group will be applied.

In the Blue Box – TAXES CHECKBOX - Here you select what are the taxes that the tax group can be used for a tax exception.

The screen above is just one example. You have to figure out with your tax department what would be the best combination to the key fields.

To create a new group, hit “new entries”:
New Entries Tax Groups

Map tax Rate tables to Cond. Tables
Once you have created the tax groups you have to assign tax groups to the condition tables. Go back to the J1BTAX main screen and then to the menu Condition Setup - Condition Mapping - Map tax Rate tables to Cond. Tables:
Map tax Rates to Condition tables

When you maintain Brazilian tax tables, the system generates or changes condition records automatically. In this activity, you specify which condition tables are to be used for a specific tax table. In the case of dynamic exceptions, you additionally specify the condition table per tax group. The system then knows for which condition table (which must be contained in the access sequence) condition records are to be generated.

The assignment of tax tables to condition tables is done with reference to a tax group for: dynamic exceptions for IPI, ICMS and Sub.Trib.; always for ISS, PIS, COFINS and withholding taxes.
Tax rate tables Tax Condition tables

* SAP does not deliver standard Customizing of dynamic tax exceptions. If you create new tax groups, you must specify a new entry for each group you use. In SAP’s standard concept, the condition table is the same for all tax groups. However, in case you need to follow a different concept of Customizing access sequences you can specify different condition tables per tax group. We recommend staying with the standard concept of one tax group per table.

** You can find these entries in the overview page of the Tax Manager’s Workplace (transaction J1BTAX). There you define tax rates for several kinds of taxes.

Let’s take a practical example on how to fill the J_1BVIEWMAP table:
I created the tax groups and I did select 9 of these groups to be relevant for COFINS Values Dynamic Exceptions:
Tax Groups CheckBox

Then, I created 9 entries to map the Tax Rate tables to the Condition tables, each one representing one tax group. You will notice that, the tables that has no tax group assigned, they will have one entry each table and they never change.

Every time when a new tax group is created and if the COFINS checkbox is selected, a new entry has to be created as below:

This idea is valid for all the following tables:

That means, if you have the check box activated to the taxes above, you will have to create one entry to each tax group in this table assigning the table name to the tax group and the correct condition table (349, 346, 382 and so on).

Migrate Tax Groups in Access Sequences
Now it is time to Migrate the Tax groups that you created into the access sequences.
Using the method of Tax Calculating via condition based (CBT), every time a new tax group is created, it must be added in a certain access sequence, automatically by the system through the transaction J1BTAX. The same should occur whenever changes are performed in the tax groups, or even it is deleted.

Go back to J1BTAX main screen and reach the menu: Condition Setup - Migration - Tax Groups in Access Sequences

On the program selection screen, you enter the tax group that you want to include in the update. You can simulate the results of the program by setting the Simulate Only indicator. This is extremely important, since the program makes cross-client changes to your data.

Additionally, you need to specify what type of conversion is to take place:
a. Update access sequences - if you want to update existing steps in the access sequences
b. Insert into the access sequences - if you want to include new steps in the access sequences after creating a new tax group
c. Delete from access sequences - if you want to delete existing steps from the access sequences

If you are creating all groups at once, it is easier select the range from 10 to 89 and you may want simulate first, just to make sure that there are no errors.
Tax Group Into Access Sequence

If it is all green, that means can run without the “simulate” check box active and the tax groups will be added to the access sequences:

You can use the report J_1B_EXT_ACC_SEQ to automatically update access sequences after you have created or changed tax groups for dynamic exceptions. You need to be authorized for cross-client Customizing if you want to modify the access sequences. It is important that you ensure that tax groups are not customized differently in different clients because with each conversion to access sequences, the previous Customizing settings will be overwritten.

The should looks something like this:
Migration Access Sequence results

The result of the run above, is that all access sequences will be updated automatically, check for example below where the different tax groups were added to one specific access sequence:
Acess Sequence MM

Migrate Tax Tables to Conditions
Now you have to migrate the tax tables to conditions to create the condition records. Go back to J1BTAX main screen and reach the menu Condition Setup - Migration - Tax Tables to Conditions. This is the execution of the program J_1B_MIGRATE_TAX_RATES.
Migrate Tax Tables to Conditions

First you have to select the application:
- TX (Material Management)
- V (Sales and Distribution)

Then you will have to select the the Conversion Options:
- Overwrite existing condition records
- Ask in case of existing condition records
- Never overwrite existing condition records

And then finally select the tables, one by one to run the migration.
Note that, the tax groups that you selected as MM will be the only ones that you will be able to run to the application TX and the tax groups that you selected as SD, you will have to run to the application V. the ones that are general, or the tables that has no Tax Group, you will run for both (some exceptions apply).
Table Migration Select Table

The result will be something closer to the screenshot below:
Result of Taxes Migration

Leandro da Pia Nascimento

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.




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


Schedule line assignment = ‘CP’.


Item category for the implied empty:


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:


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:


(ZARN is used for BOM-relevant products with % discount based on manual setting of KVGR1 to a specific value).



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:


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.


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:


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.


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.


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


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.



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:


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:


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:


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.


BOM for exploding the returned empty code:


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


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


Delivery creation result:


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





Reporting for returnable containers:

Balances for the deposit account (FS10N):


Empties evaluation report (/BEV1/EMS):



Details per account holder/material:


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.


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:



3. Set up item category determination:


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


  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.

When you create a sales document item for a certain quantity and a certain date, you expect that the system should confirm the item on the requested delivery date, but instead a new schedule line gets generated with a proposed delivery date.


Delivery date postponement (a.k.a the generation of a 2nd schedule line) can be the result of:

  •   delivery scheduling (in case the system performs forwards scheduling)
  •   transportation scheduling (in case the system performs forwards scheduling)
  •   availability check.


In order to disable the determination of a new delivery date, delivery scheduling, transportation scheduling AND the availability check needs to be deactivated.


Scenario 1 - Delivery scheduling turned OFF | Transportation scheduling turned ON | ATP check turned ON:


If delivery scheduling is switched OFF, but transportation scheduling remains active, AND the system switches to forwards scheduling, the material availability date/time (MBDAT/MBUHR), the transportation planning date/time (TDDAT/TDUHR), the loading date/time (LDDAT/LDUHR), and the goods issue date/time (WADAT/WAUHR) will be the same, but a new delivery date/time (LFDAT/LFUHR) will be determined based on the route relevant settings. If ATP check is also active then the system will check whether the requested quantity is available on the material availability date (MBDAT) calculated by transportation scheduling. If the material is available on the calculated material availability date then no further calculation will be performed. If the material is not available on the calculated material availability date then the system will check what is the closest availability date of the material. If the material can be available on a later date than this date will be found and be taken over as the new MBDAT by function module SD_SCHEDULING_ATP_CALC where the system will perform forwards scheduling.


Scenario 2 - Delivery scheduling turned ON | Transportation scheduling turned OFF | ATP check turned ON:


If transportation scheduling is switched OFF, but delivery scheduling remains active, AND the system switches to forwards scheduling, the material availability date/time (MBDAT/MBUHR), the transportation planning date/time (TDDAT/TDUHR), the loading date/time (LDDAT/LDUHR), and the goods issue date/time (WADAT/WAUHR) will be calculated based on the shipping point and/or route relevant settings. Also, a new delivery date/time (LFDAT/LFUHR) will be determined that is going to be the same as the goods issue date/time (WADAT/WAUHR). If ATP check is also active then the system will check whether the requested quantity is available on the material availability date (MBDAT) calculated by delivery scheduling. If the material is available on the calculated material availability date then no further calculation will be performed. If the material is not available on the calculated material availability date then the system will check what is the closest availability date of the material. If the material can be available on a later date than this date will be found and be taken over as the new MBDAT by function module SD_SCHEDULING_ATP_CALC where the system will perform forwards scheduling.


Scenario 3 - Delivery scheduling turned OFF | Transportation scheduling turned OFF | ATP check turned ON:


If delivery and transportation scheduling are both switched OFF, but availability check remains active, the system will not carry out scheduling at all, but will check whether the requested material is available on the requested delivery date. In this case, the requested delivery date (LFDAT) will be the material availability date (MBDAT). Please note that ERP/ATP is only accurate to the day, so only the date is considered, the time is not.


In order to prevent the calculation of a proposed delivery date, you need to disable the ATP check (transaction VOV6, field ATPPR; OR transaction OVZG, field ATPPR; OR transaction OVZ2, field VERPN) AND you need to:


  • disable delivery scheduling (transaction OVLY, field VSTRM) AND forwards scheduling (transaction OVLY, field TENUR)


  • disable transportation scheduling (transaction OVLY, field TRTRM) AND forwards scheduling (transaction OVLY, field TENUR)


  • disable delivery scheduling (transaction OVLY, field VSTRM) AND transportation scheduling (transaction OVLY, field TRTRM)


  • disable forwards scheduling (transaction OVLY, field TENUR).

The replenishment lead time represents the total period of time which is required to procure or manufacture an item. The replenishment lead time is mainly used by the availability check to calculate the material availability date. In order to enable the calculation of the replenishment lead time for availability check, the field 'Check without RLT' (V_441V-OWBZP) in the scope of check (transaction OVZ9) must be empty.



RLT calculation is performed in form END_OF_RLT_CALCULATE which is called from function module AVAILABILITY_CHECK / form AVAILABILITY_CHECK_R3.




Key variables:


S_MTWZT = In-house production time

S_WEBAZ = GR processing time

P_ATPMATX-PLIFZ = Planned delivery time

P_ATPMATX-WZEIT = Total replenishment lead time

P_ATPPLANTX-BZTEK = Purchasing processing time

S_FKDAY = Factory calendar day

S_GKDAY = Gregorian calendar day


1 - Calculation of the Replenishment Lead Time in case of externally procured materials ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = F:


For externally procured materials, the replenishment lead time gets calculated based on:

  •   the purchasing processing time (transaction OPPQ, Material Planning Run section, External Procurement button, field BZTEK)
  •   the planned delivery time (transaction MM02, MRP 2 view, field PLIFZ OR transaction ME12, 1 view, field APLFZ)
  •   the GR processing time (transaction MM02, MRP 2 view, field WEBAZ).

In case of the purchasing processing time, the system considers factory calendar days, a.k.a working days of the plant.

In case of the planned delivery time, the system considers standard calendar days.

In case of the GR processing time, again the system considers factory calendar days (working days of the plant).

The sequence of RLT calculation is:

  •   1st = purchasing processing time
  •   2nd = planned delivery time
  •   3rd = GR processing time.


Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

Purchasing processing time = 2 days

Planned delivery time =  5 days

GR processing time = 3 days


Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:


09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - Purchasing processing time | DAY 1

11.03.2015 (Wednesday) - Purchasing processing time | DAY 2

12.03.2015 (Thursday) - Planned delivery time | DAY 1

13.03.2015 (Friday) - Planned delivery time | DAY 2

14.03.2015 (Saturday) - Planned delivery time | DAY 3

15.03.2015 (Sunday) - Planned delivery time | DAY 4

16.03.2015 (Monday) - Planned delivery time | DAY 5

17.03.2015 (Tuesday) - GR processing time | DAY 1

18.03.2015 (Wednesday) - GR processing time | DAY 2

19.03.2015 (Thursday) - GR processing time | DAY 3


Based on the above described calculation the end of replenishment lead time will be 19.03.2015.



Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

Purchasing processing time = 2 days

Planned delivery time =  3 days

GR processing time = 3 days


Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:


09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - Purchasing processing time | DAY 1

11.03.2015 (Wednesday) - Purchasing processing time | DAY 2

12.03.2015 (Thursday) - Planned delivery time | DAY 1

13.03.2015 (Friday) - Planned delivery time | DAY 2

14.03.2015 (Saturday) - Planned delivery time | DAY 3 -----> The system performs an extra check to see whether the end date of the planned delivery time is a working day at the plant. If it is not, the end date of the planned delivery time will be moved to the next possible working day.

16.03.2015 (Monday) - Planned delivery time | DAY 3

17.03.2015 (Tuesday) - GR processing time | DAY 1

18.03.2015 (Wednesday) - GR processing time | DAY 2

19.03.2015 (Thursday) - GR processing time | DAY 3


Based on the above described calculation the end of replenishment lead time will be 19.03.2015.


2 - Calculation of the Replenishment Lead Time in case of internally produced materials ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = E:

For internally produced materials, the replenishment lead time gets calculated based on:

  •   the in-house production time (transaction MM02, MRP 2 view, field DZEIT)
  •   the GR processing time (transaction MM02, MRP 2 view, field WEBAZ)
  •   OR the total replenishment lead time (transaction MM02, MRP 2 view, field WZEIT).

In case of all the above mentioned figures, the system considers factory calendar days, a.k.a working days of the plant. If the total replenishment lead time (field WZEIT) is maintained, and the in-house production time (field DZEIT) or the GR processing time (field WEBAZ) are also maintained, the system will only take the total replenishment lead time into consideration.

The sequence of RLT calculation (if the total replenishment lead time is not maintained) is:

  •   1st = in-house production time
  •   2nd = GR processing time.


Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

In-house production time = 3 days

GR processing time = 2 days

Total replenishment lead time = 0 days


Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:


09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - In-house production time | DAY 1

11.03.2015 (Wednesday) - In-house production time | DAY 2

12.03.2015 (Thursday) - In-house production time | DAY 3

13.03.2015 (Friday) - GR processing time | DAY 1

16.03.2015 (Monday) - GR processing time | DAY 2


Based on the above described calculation the end of replenishment lead time will be 16.03.2015.



Actual date = 09.03.2015 (Monday)

Requested delivery date = 09.03.2015 (Monday)

Available quantity = 0 PCs

Requested quantity = 10 PCs

In-house production time = 3 days

GR processing time = 2 days

Total replenishment lead time = 8 days


Since the requested quantity is not available for the required delivery date, the system calculates the RLT as follows:


09.03.2015 (Monday) - Requested delivery date

10.03.2015 (Tuesday) - Total replenishment lead time | DAY 1

11.03.2015 (Wednesday) - Total replenishment lead time | DAY 2

12.03.2015 (Thursday) - Total replenishment lead time | DAY 3

13.03.2015 (Friday) - Total replenishment lead time | DAY 4

16.03.2015 (Monday) - Total replenishment lead time | DAY 5

17.03.2015 (Tuesday) - Total replenishment lead time | DAY 6

18.03.2015 (Wednesday) - Total replenishment lead time | DAY 7

19.03.2015 (Thursday) - Total replenishment lead time | DAY 8

Since the total replenishment lead time field is maintained, the system will not take the in-house production time and the GR processing time into consideration, so the end of the replenishment lead time will be 19.03.2015.


3 - Calculation of the Replenishment Lead Time in case of materials maintained for both procurement types ==> Material Master, MRP 2 view, Procurement type (field BESKZ) = X:

If a material is maintained for both procurement types, during RLT calculation the system will consider it as a material, which is internally procured. This means that the purchasing processing time and the planned delivery time will not be taken into consideration, not even if these are the only RLT relevant fields maintained.

Working on ERP/ATP related issues made one thing quite clear: many of the end users still use the wrong transaction(s) when they try to check the availability of certain materials. End users often refer to transactions like MD04 or MMBE, but in fact, these transactions are not suitable for checking ATP quantities.


In order to check the availability situation of materials, transaction CO09 must be used. This is the only transaction which takes into consideration not just the

different stock levels, but inward and outward stock movements as well. Other transactions (like MD04 and MMBE) does not have this functionality, these transactions were designed for completely different purposes.


Here is a simple example which shows the difference between how these transactions handle quantities.


In this situation we have:

  •   a material (AC_1)
  •   a plant (AC1)
  •   three storage locations (AC1, AC2, AC3)
  •   a planned order created for 23.09.2015 about 100 PCs (storage location determined in the planned order is AC1).


Transaction CO09:



In transaction CO09 the system shows the most important data which are considered by the ATP check, including:

  •   the material availability date
  •   the MRP element related data
  •   the required / requested quantity
  •   the confirmed quantity
  •   the cumulated ATP quantity (quantity still available after the confirmation is made).

Also, the created sales and delivery requirements, as well as the production and purchasing documents are shown on all the concerned storage levels, meaning that:

  •   if only the plant is given in the document, the MRP element will be shown only under the plant section
  •   if both the plant and the storage location are given, then the  MRP element will be shown under the plant stock and the storage location section as well.

In CO09 it can be seen that after 23.09.2015 we have 100 PCs available. These 100 PCs can be confirmed in sales or delivery requirements.

Now, what can we see in transaction MMBE?



In short: nothing. From an availability perspective this transaction is not useful at all. MMBE does not consider inward / outward stock movements. If someone checks MMBE to find out how many pieces are available of material AC_1, he/she will think that this material is currently not available (which is true) and will not be available in the future (which is wrong).


Let's take a look on transaction MD04 next.



In the current situation, MD04 shows the same available quantity that CO09 does, but there is a catch here. Transaction MD04 calculates with requested quantities, not with confirmed quantities.


To see what this means in terms of availability, let's create a sales requirement (a sales order) in which the requested quantity is 50 PCs. The system could confirm these 50 PCs for 23.09.2015, but let's change the confirmed quantity to 20 PCs manually (which can be done on the availability control screen) before saving the sales order.


In this case, CO09 will look like this.


Again, as I have already mentioned, the sales requirement will be displayed under all the relevant storage levels (in our case, under the plant section and the storage location section as well). Since the requested quantity was 50 PCs, but we confirmed only 20 PCs, the cumulated ATP quantity (the quantity which remains available after the confirmation is done) will be 80 PCs at 23.09.2015.


Now, what does MD04 tell us?


As it can be seen above, MD04 uses the requested quantity for the calculation, not the confirmed quantity, that is why column 'Available Qty' shows that 50 PCs are still available (which is not true).


In summary, as it has been represented, material availability related questions cannot be answered by using transaction MD04 or MMBE, the transaction that has to be used is CO09.

This is a continuation of Mass update of route determination with LSMW. See Mass update of route determination with LSMW


Due to restriction of amount of images loaded in previous post, this part continues with the LSMW upload for the TROLZ upload.


TROLZ upload


Now the TROIZ entries have been loaded, we can load the entries for shipping conditions and loading group.


Create a new object in transaction LSMW with different name.


Goto Maintain Object Attributes and create a new recording as described in the TROIZ load. Also use transaction 0VRF. In the first transaction we now press the button "Position" first. A popup appears and enter the Country of departure, Zone, Destination Country and Destination zone.


Then select the line and press the button "route determination w/o weight group".


In the next screen press button "New Entries"


Then SAVE the entries and the popup of the transport request appears again.


Confirm and return to the batch input overview using the BACK button.

Then change the values here as shown in the screenshot - like the TROIZ steps.


Enter the name of the recording in the attributes.


Then maintain source structure as described in the TROIZ upload.


Then goto Maintain Source Fields and enter the following fields.


Then maintain structure relation as described in the TROIZ upload.

Then goto Maintain Field Mapping and Conversion Rules

Same steps as in the TROIZ upload. Map the source fields to the structure.


Then goto Specify Files.

Source file should look like in Excel.


Save the file as a .CSV. Make sure the leading zero's don't get lost.

Then enter the file details like the TROIZ upload.


Then execute the same steps as the TROIZ load (see Mass update of route determination with LSMW).

- Assign Files

- Read Data

- Convert Data

- Create Batch Input Session

- Run Batch Input Session

After running the batch input session in background the entries in 0VRF are now completed.


Note that the generic entry is also created. In this example it would be sufficient to load only the generic entry. Then you only need to load the 'exceptions'. This saves some maintenance and amount of entries in the customizing table.

This completes the steps for loading route determination via LSMW.

This blog is to explain the steps for uploading route determination without weight group via LSMW.


During several rollouts or redefinition of routes we need to upload new route determination in the system. If the amount of records are not that many, best approach is to do it manual. However with a lot of records, we can use the LSMW tool for this activity.



  • Routes must be available.
  • Shipping conditions must be available.
  • Transportation groups must be available.
  • A basic knowledge of using LSMW tool.


Generic route determination:


In this post, I also load entries with a generic route determination. Refer to notes 386105, 414250, 656444 for this functionality. For the route determination maintenance in the Customizing, it is possible to generate entries for which shipping condition, transportation group, weight group are initial (generic). When entering a generic key, it will take the generic route entered in that key. So you only need to maintain the exceptions with an actual key. This can save a huge amount of records to be loaded.


2 step approach:


The route determination is contained in 2 tables:

  • TROIZ (keys for country from/to and departure zone from/to)
  • TROLZ (keys for shipping condition, transportation group, weight group (not used in this blog) and actual route)


To make it easy for the LSMW we load the records for each table so we need to have 2 LSMW's.


Note: Before starting, go to transaction 0VRF and change/update one entry in the route determination table so a transport request is created. This transport request is used in the LSMW's.


TROIZ upload


Goto transaction LSMW.


Create new project/subproject/object


Here we create a new load for the route determination load of the TROIZ table.


Maintain Object Attributes


This is the most important step of the LSMW, we create a recording for the TROIZ table. Using a batch input recording.


Next popup needs a transaction code. Enter transaction 0VRF


Next screen appears and press button "New Entries".


Enter one key that does not exist in the route determination table. Else you get error message and have to start over.


Press the SAVE button. The transport request we created before starting comes up.


Confirm and go back with green arrow a couple of times so that the recording screen is shown.


Now double click on the fields ALAND, AZONE, LLAND, LZONE and TRKORR one by one and give the following names. I normally delete the default value and only keep the field name + description. The transport request number do not change.


SAVE the recording and enter the recording name in the previous screen (object attributes).


Then go to menu option source structure. Enter something similar below.


Then enter Maintain Source Fields.


Then enter Maintain Structure Relations.


Then enter Maintain Field Mapping and Conversion Rules.


Note: In the menu --> Extra's --> Auto-fieldmapping will do the mapping more quickly. Else select the fields one by one and pressing button source field to assign the source fields manually.


Then goto Specify Files

You need to create your input file first. In Excel the source looks like this:


I normally save the Excel as a .CSV file (comma separated) for usage in the LSMW.


Note: always check if the keys are the same as in the Excel file. Sometimes the leading zero's get lost in the conversion.


Then goto Specify Files select Legacy Data and double click on that node.



    • File name on your computer
    • Description (any)
    • Delimiter as Comma (we use .CSV)
    • Field names at start of file checked.
    • Field order matches source structure definition checked.


          SAVE the entries.


Then goto Assign Files:


Then goto Read Data


Execute this transaction (F8) and you get overview of loaded entries. When it shows read = written it's ok. When not written there is something wrong. You should check your file or mapping when this is the case.


Then goto Convert Data


Press Execute (F8). The transactions read - written should be the same.


Then goto Create Batch Input Session


Screen should show the following, I always select 'keep batch input'.


Execute this transaction (F8)


Then goto Run Batch Input Session


Select the line and press button "Process". Select Background and press button "Process".


This will result that the from/to route determination is loaded in your system. In transaction 0VRF all records are now loaded.


This is the end of the first LSMW load.


TROLZ upload


Please refer to next link for the upload of the TROLZ entries.

Mass update of route determination with LSMW part 2

Some customers tried to re-update their pricing in intercompany billing but failed.


From price analysis, the following message is listed:


Access Message Description

05     108      Condition record exists, but has not been set

10     230      Access has not been executed due to previous access


Then we checked further and found the condition category KNTYP for the affected condition type is blank in V/06.

This is actually the standard behavior that condition type with KNTYP blank is not redetermined in intercompany billing, neither with pricing type B.


It is also specified in SAP Note 33487.


In the case of invoice type IV...

    • repricing SHOULD NOT occur for condition types with the condition category = ' ' (blank) or the condition category = 'G' (Cost).



Here in the blog I will introduce the responsible coding during the pricing update:


*   Verrechnungspreise und TP nicht neu ermitteln
    IF tkomp-kaend_typ = space.
      IF tkomk-vbtyp NA vbtyp_fkiv.         << not intercompany
        tkomp-kaend_typ = 'Gbh..'.
      ELSE.                                              << intercompany
        tkomp-kaend_typ = 'Gbh .'.
* jetzt käme der PRICING_DIALOG
* Kopfpreisfindung


Remark to the coding above:
tkomp-kaend_typ contains the condition categories that will not be redetermined regardless of the pricing type.


Hope it will do you some help.

Dear All,


Blog is just to explain how we have  implemented Discount and Free goods on Customer Group  with Pricing Condition

Business Scenario


This was one of our client requirements who are into FMCG business and company wanted to give Discount and Free Goods on following Levels


    A.Group 1 ASM Area Sales Manager one who handling entire State-State Level -Customer Group 1

    B.Group 2 TSM Territory Sales Manager one who Handling 2 or 3 district- Multiple Districts/zone Level-Customer Group 2

    C.Group 3 TSE Territory Sales Executive one who handles single District-District/City Level-Customer Group 3

    D.Group 4 Modern Trades like Reliance fresh, Lulu, More, Big Bazaar, Spencer’s etc. - Customer Group 4



We are maintaining 3 Distribution Channels

10 Direct Channels

20 Distribution Channel

30 Modern Trade (Reliance Fresh, More,Lulu, Big Bazar etc….

Now into Requirements Let’s says


1.The company wants to give a discount to Chennai alone.

2.The company wants to give discounts in 3 Districts alone.

3.The company wants to run a sales promotion campaign for particular TSM or TSE Alone to boost his business.

4.The company wants to give Free goods on Particular TSM or TSE Alone

5.The company wants to give a discount on particular material group in ASM, TSM and TSE level.


                                                                                        Configuration Settings


1.Customer Group


SPRO-Sales and Distribution-Master Data-Business Partner –Customers-Maintain Reserve Fields In Customer Master


customer GRP.png

Customer Group 1 at State Level

customer GRP.png

Customer Group 2 at District(Multiple Districts/zone)  Level

  customer GRP.png

Customer Group  3 at  District/city  Level

customer GRP.png


Plz note  that  since Chennai is big  territory so I am dividing Chennai into two i.e. Chennai 1 and Chennai 2.


                                                                                                    Customer Group 4 Modern Trade

customer GRP.png


2.Customer Master Data


Got to customer master data  under Sales area  tab above menu Bar Extras click on  additional Data


Fill all relevant data according to your requirements. Plz note that  Customer Group is 4 not applicable, since this customer is belongs to Direct Channel in  my case it is applicable only for Distribution channel  3 i.e. Modern Trade.

customer GRP.png

3. Pricing Configuration Part


Got to Pricing, pricing control Field catalog


Customer Groups fields are not added in the Field Catalog so add  the field catalog


customer GRP.png

Before you create a new condition table, you should check whether the fields listed in the field catalog meet your requirements. If you require a field in pricing which is not intended for this usage in the standard system, you must enter it in the field catalog. You can only enter fields from tables KOMG, KOMK or KOMP.

If you want to use a new field in the field catalog, you must add the field to KOMP or KOMK in the following INCLUDES:

                                                              Header data in INCLUDE KOMKAZ in KOMK

                                                              Item data in INCLUDE KOMPAZ in KOMP


The routines for assigning values to the new fields in order processing are found in member MV45AFZZ and new fields in billing are found in member RV60AFZZ. Use the following user exits:

                                                        USEREXIT_PRICING_PREPARE_TKOMK (header fields)

                                                        USEREXIT_PRICING_PREPARE_TKOMP (item fields)

                                                User Exit For Discount and Free Goods



Condition Tables


customer GRP.png



customer GRP.png



                                                                                                        Access sequence

Copied Standard Access Sequence and created new Access sequence call IFPR

customer GRP.png


Condition Types


Copied Standard Condition type and created new Condition Type call IFPR

customer GRP.png


Pricing Procedure

customer GRP.png


Creating a Discount for TSM Level in VK 11


We have different Material Group, for Example PK-Lime Pickle, SP-Chilli Powder, and WS-Kashmiri chilli so we can give discount on Particular group alone for ASM, TSM and TSE level

customer GRP.png


Plz Map your customer according to your ASM, TSM and TSE located in different State, Zone and District. customer GRP.png

customer GRP.png



customer GRP.png

4. Free Goods  Configuration

Business Scenario


  1. The company wants to give Free goods on Particular ASM, TSM, TSE Zone and District level Alone


        Condition Table Group 1


customer GRP.png

customer GRP.png


Access Sequence


customer GRP.png

Condition Table

customer GRP.png

            Creating Free Goods records in VBN1

customer GRP.png


customer GRP.png

I am Nothing in this SAP Ocean  just learning day  by day , so please share your ideas and suggestions with me.Thanks in Advance.



The chess grand masters analyze hundreds and hundreds of chess games!

Constant studying of threads will give SD consultants the much needed "richness and density"...making them better consultants!

Below is a list of threads related to Returns. Study these regularly, make notes, practice in IDES and with time, you will become a MASTER!




1. important:

  • Implementing RE process gives the most learning and experience! a new order type or a new item category. When you get an opportunity to create a new RE order type or item category grab it with both hands!
  • Understand the processes before and after returns. After return order creation, there could be re delivery, re credit memo or SDF. For what business scenario should we design SDF?
  • Flow of goods can be forward and backward (i.e. sale and return), document category is one of the important settings which determines how a process will behave, how data will be stored, how SAP will keep track of data. OTC and RE cannot be in the same sales order!
  • For promotional sale, customer can not return the goods, below link - Design of promotional sale process. If copy control does not exist between sale and re process, then RE order cannot be created with reference. Understand copy control - at header and item levels.
  • "Mixing and matching" document types of different processes. Example below ZCR (credit memo request) > ZRE (return billing type). This is not the way it should be configured


OTC and RE cannot be in the same sales order!

Functionality - Document category
Two delivery types in one sales order


Post go live, a temporary issue

Functionality - Reference mandatory

Understanding the issue - is it related to transaction data OR related to configuration?

SALES RETURN for the material sold before SAP implementation


Promotional sale, customer can not return the goods

Block sales order items for return orders


Business process related ticket

How to handle "after" goods are returned to the company? Give credit to customer, supply the goods free of charge

Functionality - SDF, key configurations in SDF - no billing, delivery block, any pricing? , copy control related to creation of SDF order

Sale return of Component of Fin Prod


ZCR > ZRE , not recommended

For credit memo process there is a dedicated billing type G2

Output to trigger header ship in return order


2. important:

  • Understand for what business requirements you need a new/different RE order type and for what requirements you need a different item category.


change the item category in RE order, instead of the default item category - If re order is created with reference, then the particular re item category can populate automatically with copy control (item level). If re order created without reference, then manually the "correct" item category needs to be input (in place of default, coming from item category determination table T184)


Functionality - Billing relevance

Return Sales order - update of Item category change

Complaint Processing -


3. Business does not want any major changes

Functionality - copy control

Userexit, enhancement

Propose order quantity in return sales order


4. View selected Order reasons in VA01/2

Functionality - make order reason a "mandatory" field in RE process, useful for reporting

Userexit, concept of Ztable (important and used frequently)

Order reason codes - specific to sales order type


User Exits In Sales Document Processing - System Modifications - SAP Library

Side comment: For a SD consultant to understand, identify the appropriate user exits that can be used for a requirement is very helpful.


5. important:

  • Visualize the flow of goods. Most of the times, business wants to have clear distinction between sales goods flow and re goods flows.

Functionality - Shipping condition for returns process

different shipping point for returns delivery

Discussed in point 3, below, configuration


6. Should returned goods be part of Salable stock or not?

Functionality - Movement type 651, 653

sales returns

Movement type for Sale return

Return Delivery from Customer with Movement type 653 - Toolbox for IT Groups


Important - DN is the schedule line category provided for return process, in standard. VOV6


7. Business process and enterprise setup

Functionality - Enterprise structure > assignment > Sales org, distribution channel to delivering plant. An important step in SD

Intercompany Return Process Error


8. Pricing - what components to refund to customer? should tax component be refunded? should freight be refunded?

Functionality - Pricing

Return process

Side comment: In every aspect of SD design/tickets, mentally check - is there any impact on pricing?


9. Flow of goods in return direction, to which plant should goods be returned?

Functionality - Delivering plant (receiving)

Return order

Good example of a business requirement

10. Quantity in return order, compared to quantity in sales cycle

return order

Return order with reference to the Billing Document


11. (09Aug15 updated) 11 merged with 1


12. Functionality - Billing block

Generally in returns, credit, billing block is setup. Billing block can be setup at different levels (header, item) in RE order

Below thread touches on authorization also.

Unable to remove biling block return sales order

Billing block

Important is to read the error message carefully, it gives clues, for solution


13. Functionality - REN, item category

Item category in a return order


(added on 08DEC2014) 14. Functionality - Billing (return credit note) created with reference to return delivery

(In standard, RE bill is created with ref. to RE order)


asked to include this. In few of my projects, companies have RE credit note created with ref. to RE delivery (and not order). There could be few business reasons to this process:

- The business would like to inspect the goods in their warehouse and then give refund, if applicable

- Quantity in delivery could be different from that in the RE order, so refund is given on the actual quantity that the business receives.

From configuration point,

14.1. copy control VTFL: RE delivery to RE bill is same as LF to F2,

and at item category level, copy control of REN is same as and item category TAN

14.2. item category REN, billing relevance should be A (delivery related billing)

Delivery Related Billing rather than Order Related Billing in Return Sales


Returns in standard SAP:

1. Return order created with reference to billing document

RE order can be created without reference or can be created with reference to sales order. But best practice is to create with reference to invoice

At item level of copy control configuration, pricing type is an important functionality - should prices be copied unchanged or any other way. The business requirement dictates pricing type. VTAF


2. Return document type

In several projects, I have noticed that field Reference mandatory has played an important role. Take note: when creating any custom reports, the SD document category is H, at transaction level, in order VBAK-VBTYP; at configuration level, in order type TVAK-VBTYP.

Different number ranges are given to RE orders, for easy recognition and reporting purposes. VOV8

2.doctype, reference mandatory.jpg

3. Continuing with order type, shipping condition can play an important role. Also billing block given here, then in sales order, at header level billing block will be set automatically. Business has to remove the billing block from the sales order in order to create a RE credit memo. If business does not want to give RE credit note, then a reason for rejection can be put

3.doctype, shipping condition, billing block.jpg

4. Item category

In addition to field billing relevance, also note field Returns has to be activated for all return processes including credit memo, check G2N. VOV7


5. Schedule line category

Movement type is an important field. 653, 655, 657 Availability check and Transfer of Requirement has been deactivated, as these functionalities are not required for goods coming into the plant. VOV6


6. Delivery item category

The item category name REN remains the same in sales order, delivery and billing

Relevant for Picking in deactivated as goods are coming into the plant. Document category is T, sometimes needed for analysis in VTFA. 0VLP (zeroVLP)


7. Billing type

The RE credit can be cancelled, for that SAP standard cancellation billing type is S2. Additional requirements can be setup, conditions where cancellation is permitted in copying requirements. Does a company want the option to cancel the RE credit memo is a business decision. VOFA


All the screenshots are from SAP, copyright by SAP AG.



Career Center

My company need to enhance the atp and production allocation, so I list all user-exits about atp and production allocation.

  • The user-exit column is user-exit name.
  • The caller column list the user-exit's call stack.
  • The refer column displays the user-exit sequence.





The pricing condition PR00 is marked as mandatory condition (T683S-KOBLI) in the pricing procedure (transaction V/08).
The same pricing procedure contains subsequent price conditions (conditions having Condition Class = B in V/06).



Due to the last price logic (see SAP note 836243) the PR00 price condition gets deactivated by one of the subsequent price conditions during SD document processing.

It means, KONV-KINAK / XKOMV-KINAK (condition inactive) is filled for PR00.



If you create a downpayment invoice, only the last active price condition is copied into the downpayment item and the deactivated PR00 condition is ignored. Since PR00 is a mandatory condition, the error message V1801 "Pricing error: Mandatory condition PR00 is missing" is displayed which hampers further activities.






It is the standard design of SAP system that inactive (KONV-KINAK) or statistical (KONV-KSTAT) conditions are not taken over into invoices having downpayment items.
For example billing type FAZ  has downpayment items.



The following source code is responsible for this behaviour:





* By default, statistic and inactive conditions are not copied
* in downpayment positions. By setting U15_SUBRC to '1' the
* copying is suppressed.
       if konv-kstat ne ' ' or konv-kinak ne ' '.
          u15_subrc = 1.






By using FORM USEREXIT_PRICING_COPY (RV61AFZA) you can easily change this behaviour and fulfill your requirement. Changing the field U15_SUBRC in the user exit achieves that statistical or inactive conditions are copied into downpayment items.



An example for the source code development:






if ( konv-kstat ne ' ' or konv-kinak ne ' ' ) and amount_rule ca '45'.

  u15_subrc = 0.









In some cases it is necessary to modify the customer master data (name, address ...) of a business partner within a productive SAP system.

As a result of that modification you face the problem that already existing SD documents are updated according to the new master data.
Thus old SD documents already sent to customers contain now new partner data (for example different address).




You might think this is a system error, in case you need to issue an output for an old SD document, since it displays now different data than the one it used to have in the past before master data change.

This phenomenon is not a program error but the standard design of the system.





SAP can not store all the master data inside the SD document tables.

An address change in the customer master record is always transferred to all existing documents (unless the document has a manual address).

The system does not save the master data in the document, but in the master record. The document shows only a reference to the master record.



Following SAP note provides an explanation:


380456 - Customer master data: Address change in documents







  • One option could be to create a manual address in the documents. See note 550073 (Point 5) and 97832. In this case the address is only stored in the document and a change in the customer master does not have an influence on the address in the existing documents.




  • However, in order to avoid such a problem, as a solution I would suggest you to use the optical archiving via ArchiveLink.
    This functionality makes it possible to store the outputs of SD documents so that you can print out them in the future at any time in their original form. In the output type customizing you have the possibility to set the storage mode 'Archive only' or 'Print and archive'




You can find the documentation in R/3 Library under the following path:


- Basis Components
- Basis Services / Communication Interfaces (BC-SRV)
  - SAP ArchiveLink (BC-SRV-ARL)
   - SAP ArchiveLink - Scenarios in Applications (BC-SRV-ARL)

    - SAP ArchiveLink - Archiving Scenarios (SD)


ArchiveLink - SAP Library




Use transaction OAAD (Administration of Stored Documents) to display documents from the optical archive






Stored documents are classified according to document types. The system uses the following document types in case of SD documents:



SDOORDEROrder confirmation
SDODELNOTEDelivery note
SDODELPLANScheduling Agreement
SDOINVOICEBilling documents
SDOINVLISTInvoice list
SDOBONUSRebate credit memo




You can make use of the activation of ArchiveLink functionality even after real document archiving. Sometimes people need the output of an already archived document. But it can not be opened from the archive and the reload of archived documents into the system is not supported by SAP.

In that case you can easily have an access to the output of documents stored by ArchiveLink in the Attachment list.




The following image shows how you can access the stored PDF output of an already archived billing document in VF07 transaction.
The output is also available from SARI transaction.






For more information have a look at the following notes:


1822569 - Not possible to display/print the output of archived billing document in VF07

  440033 - Information on billing document display from archive (VF07)




When you reversal billing  document by VF11, the error message appeared as below:

error message.png

Due to this billing which create without refer to actually sales document or delivery document, the may be created by  POS or IDoc with Billing category as "W" (filed: TVFK-FKTYP and VBRK-FKTYP); In this case, we can't revesal billing use VF11 by normal program. We should assign copying requirment route 410 to filed TVFK-GRBED within Billing document. Then we can reversal billing by VF11.


PS: for more detial information, pls refer to sap note 489678, this note just for you reference to resolve issue quickly.

If you look at the 'Scope of Check' that was setup for your Sales Order Availability Check, you'll see a choice that says: 'Check without RLT?'



Besides the question being a bit confusing (when I check it on, is it with or without RLT??), the decision has many, some hidden, implications. First off: when the choice is checked, your availability check performs its routine without the Total Replenishment Lead Time.


So what is the difference between the two? Let's look at an example:


Assuming you have nothing in inventory today and a customer orders 100 pieces with a desired shipment sometime in the near future. There are 50 pieces coming from the production line BEFORE the customer wants to pick up 100, and 50 coming in AFTER the customer wishes to pick up 100 - the last 50 are coming after the end of the Replenishment Lead Time.


If our sales availability check performs with Total replenishment Lead Time (the option in the 'Scope of Check' is unchecked), the following happens:



The system checks ONLY within the Replenishment Lead Time and ignores all receipts outside of it. It also assumes unlimited availability at the end of the TRLT. Therefore 50 pieces can be confirmed to the customer's requested delivery date and 50 are confirmed just after the end of TRLT.


This has the following implications: First, the sales order will confirm ANY quantity, no matter how crazy the request is, right after the TRLT, and second, it confirms quantities that are not on the schedule or even on the plan at that moment. Only after MRP is run, there will be a planned order to meet the new demand. This is a very unreliable and noisy way to do business and, in my personal opinion, only makes sense if you run MRP every day, or in a Make To Order situation, where there is no stock, nor any receipts.


On the other hand, when you check without Total replenishment Lead Time, the system checks the entire planning horizon for receipts, but doesn't let you confirm, if there aren't any.

Doing this right is imperative to business success, leveling demand, reducing noise in the production program and increasing visibility on what's demanded for the production scheduler and what's available for the customer sales representative.


Filter Blog

By author:
By date:
By tag: