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.

Sales Order Delivery Block due to Material Costing Update

Sometimes we create sales order with Material MRP schedule line (CP).  As per schedule line sales order refers the product to production department for Production Process. Then production team produce the finish goods against the Sales Order. But Sales Order line item showing “Delivery Block Status: Blocked”.

During create of sales order if material costing not update then below status shown in sales order line item.


So sales order not possible to process for delivery. During creation of Delivery for the reference sales order system give some error. Like

“Create Delivery” not allowed (Sys. Status cost, object VB ……………………………)

material error.PNG


How can we solve the error?

That’s mean delivery is not allow for this sales order due to material costing update. This sales order material has a BOM and BOM item component. This material and component item also needs to update material price costing. For this material we need to maintain Activity Type / Price Planning by Cost Center and Activity Type wise.

We can use this transaction by T-Code: KP26

Like :      Cost Center        :               Production

                Activity Type      :               LABOUR, MACHIN, POWER


After maintain Activity Type / Price Planning we can active the material costing price update by T-Code: CK11N



now open the sales order and save the sales order then material costing already updated and sales order material block status changed in " Not Blocked" Status.



now this sales should be allow for delivery process.

T-code: VL01N





this way we can remove sales order update material costing and allow for delivery process.


best regards,


Md. Enayet Hossain

Many times being at Functional side having some technical knowledge is a great way to make a big skills move in SAP. When you've a real passion for some particular area then I believe it’s equally important to start focusing on development efforts against your particular module along with functional role so sharing this document which I’m sure will be helpful for many of us.


Question arises that why there’s a need to modify F1 documentation for any Data Element/Keyword and the answer is sometimes you need to display a Custom message for that particular field, sometimes you want to display the F1 help in Multi-languages and sometimes it’s just that more Documentation is required according to the user level.


SAP provides its own documentation for each of the data elements which we can view as an F1 help for screen fields based on the particular Data Element. This documentation can be enhanced via T-code CMOD.




First we need to get the data element of the corresponding field for which we want to change F1 Help and the 1st step is knowing the data element. Suppose in Customer Master, I want to change the F1 help for ‘Data Line’ Text box and in order to get the Data Element the same press F1 and then click on Technical Information Icon.



Execute T-code CMOD


Now click on Goto --> Text Enhancements --> Data Elements --> New DE cust. docu.



You’ll get the below mentioned screen, copy the data element that you've got after clicking Customer Master ‘Data Line’ field.


Click on the Mark icon or press enter, following screen will appear.


Give unique name in Modification Name Text box while creating the same. It depends upon you as if what starting point you want will it be the Original Text or as a Template. This will be copied into the modification screen which can further be changed accordingly.


In below mentioned screen I've defined customized usage of this field as I don’t want other fields to be displayed so deleted them. Moreover, you can use other features like formatting, paragraph style etc. Don’t forget to activate this Modification after saving.


After activating it, click on F1 help of ‘Data Line’ field in Customer Master and you can see the changes in below mentioned screen.


Now this ‘Data Line’ field name might be confusion for many of the End users who are responsible for maintaining Customer Master Record hence we can also change the keyword as per our requirement using CMOD once again.


Click on Goto --> Text Enhancements --> Keywords --> Change; mention the Data Element once again as shown in below screenshot.


This is the default description that you will be going to see after clicking on the Mark icon.


You can make the changes in above mentioned text fields as per your requirement.


Go to XD02/XD03 and you will see the changes that you've made are reflecting against that particular field.


We can cross verify the done changes in SE11 by entering the structure name as ADDR1_DATA, press F7 for the view and you can clearly see the changed short description like in below mentioned screen shot.



This enhancement technique mentioned above can be used to fulfill business requirements however before applying such changes we need to be careful as changes made through CMOD are directly linked to the dictionary object and the same will be reflected at all those places wherever that particular field is available.


I hope it will be helpful for those who always are ready to meet client's requirement at any cost or where there's a Top Management demand to fulfill wishes like that for their reporting purpose. Fruitful comments of all valuable members are most welcome. Thanks.


Read about intended audience / purpose / approach towards these posts => Additional info

This my recent initiative. Give me feedback how I could improve it further, any topic you would like me to discuss in particular, change my writing approach / style etc.




In this post I touch various controls, objects that are in action during item pricing and interplay between them(form order document down all the way to to billing / invoicing). It is assumed you are already aware of concepts like - pricing condition technique, condition type, copy controls. item category etc.




(Remember "item category" == "document type" + "item cat. grp." + "high lvl. item cat." + "usage")


As soon as you enter the material in sales order, SAP runs through item category determination rules. Identifying appropriate item category for an item with-in the context of this transaction. Item category has 2 configuration settings that are highly relevant in pricing context:


  • Pricing :: Whether the item is to be priced at-all or not (with-in the context of this transactions). An item may be relevant for pricing in one transaction and may not be relevant for pricing in other transaction. This is controlled though th is setting of the item category identified for an item in the transaction. Because the other transaction (free-of-charge subsequent delivery, FD for example) may result in different item category (KLN) not relevant for pricing, and so the item is never priced in that transaction

As you can see standard item category (TAN) is relevant for standard pricing (‘X’). and so normal pricing is carried out when TAN is identified as material’s item category in standard order (OR)

whereas, free-of-charge material category (KLN) is not relevant for pricing (BLANK). and so no pricing is carried out for the material in free-of-charge subsequent order type (FD)




  • Billing Relevance :: The billing / invoice document is to be based on sales order or based on delivery documents or based on pre-defined billing plans? Most literature do not elaborate much upon that but in practical terms it means what types of copy control settings to use when data flows into billing document.


    • For order related billing, data flow is based on order => billing copy controls (VTFA)
    • For delivery related billing, or, data flow is based on delivery => billing copy controls (VTFA).




More detailed discussions on copy controls in later posts, but basically with-in pricing context the copy control settings (at item-level) control

(condition value are copied from source to target document at item-level only. Never at header level. and so for time being I only discuss item-level copy controls in pricing context)


  • Billing quantity :: what quantity to be copied to billing / invoice documents - should it be (ordered qty.) or (delivered qty.) or (ordered - invoiced qty.) etc. If you set it C (order quantity), SAP will always bill total ordered quantity (irrespective how many quantities were actually delivered)



  • Price source :: Which source document the billing / invoice fetches condition values from - should it be order or delivery or both?

NOTE-1 :: Pricing source set to ‘E’ (delivery / order) for standard item category (TAN) in source document. This means for every condition type included in billing document’s pricing procedure, SAP tries to copy value from delivery document. Only, if billing document does not find condition value in delivery document will it try to access condition value from sales order. This is particularly useful when freight conditions are entered in delivery document and other conditions are n sales order. Make sure the condition type being copied is also included in order / delivery  pricing procedure. (remember order / delivery / billing - each have their own pricing procedures, more on that towards the end of this post)

NOTE-2 :: If an item category is order related (Billing relevance = order related) the system gives error if you choose Price Source as delivery (B / D / E / F. why?



  • Pricing type :: While copying  condition values from source to target document, should condition values, scales etc. be re-determined or should they be copied as-is. For example billing document may be created months after order was created or delivery was made and meanwhile item prices / discounts etc. might have changed. or, the scales for Freight charges may have changed as per weight of the actual delivery (vs planned delivery in sales order). Being highly configurable system SAP allows the flexibility to selectively choose what set of condition types to be re-determined (for ex. taxes, freight etc condition categories) and which ones to be copied as-is (for example manually entered values).

NOTE :: remember "Billing date" in billing document is always "actual GI date" from the delivery (Delivery document => Item overview screen). This can be different form planned GI date, which is copied form sales order)







Coming back to sales order, as soon as you enter the material in sales order and SAP finds the item to be price relevant, it runs trough pricing procedure determinations rules and determine the relevant pricing procedure.


This pricing procedure controls what all condition types constitute overall item pricing. Each condition type can be

  • Automatically determined :: if the condition type has an access sequence assigned to it and the valid condition records exists.
  • or, if no condition record is found, the condition type can still be added manually. In that case make sure you further set up the condition type to be manually editable (condition type settings, V/06 => “Changes which can be made” section). Set “Manual Entries” as either BLANK, A or C.

3-Manually editable.png


Depending upon business needs, it is also possible that a condition type be only added manually (not automatically!) to an item pricing. Despite relevant condition records existing. For example one-off special discount discussed case-by-case with customers. In order to achieve that, check the “Manual” check-box against the relevant condition type in the pricing procedure (V/08). In such situation, as-soon-as condition type is added manually, automatic  determination kicks-in whereby SAP automatically picks the relevant condition records if there is one that exists. Or you just have to enter “Condition Amount (rate)” or “Condition Value” manually. Again make sure condition type shoudl still be set to be manually editable as described above.





**********************VERY IMPORTANT*******************************


Condition Amount (rate) and Condition Value are two different things

and,  Condition value == Condition amount (rate) * Condition base


  • Condition base :: is determined by condition type settings => “Calculation type” (Fixed amount or item’s quantity / volume / weight or it could be % based
  • Condition amount :: is simply the condition’s rate card and originating from condition records

(This is very important concept esp. when it comes to distributing header level "group condition" to various items or condition types that are % based. I have met even semi-experienced consultants alien to this concept!








Now that we are on sales order stage, all condition types that comprise item price have been determined (or added manually). Next step is to make a delivery document, followed by billing / invoice document. How the prices / condition values flow from document-to-document?


It is a common myth that conditions types and respective amount (rate) and values are copied from sales document => delivery document and from there on => billing document. That’s not what happens exactly. In-fact if you look sales => delivery copy control, VTLA, there exist no controls for copying pricing data




Sales, delivery and billing document each has its own pricing procedure assigned to it

  • Sales and billing pricing procedure is determined as per determination rules = (Sales org.) + (dist. ch.) + (div.) + (cust. pricing proc.) + (document pric. proc.)
  • For delivery, the pricing procedure is directly assigned to delivery document type. Normally delivery pricing procedure only contains delivery related condition types (for example freight charges).




During billing / invoicing phase, SAP copies condition values from order document or from delivery document or both. Based on “price source” setting in delivery => billing copy controls, VTFL (Or, for order related billing relevance, order => billing copy controls, VTFA). Make sure all the condition types you want to include in billing / invoice exist in both

  • the target document's pricing procedure (billing pricing procedure)
  • as-well-as in source document you are copying from (order or delivery or both)

Because condition values are copied only if the condition type exists on both source and target document. In order to test that, try to leave out PR00 pricing condition type from billing pricing procedure. Then try to bill the delivery. In the billing document you wont notice PR00 condition anymore.


In practice though we can

  1. Create one pricing procedure
  2. Assign this pricing procedure to all three documents (sales / delivery / billing)
  3. Selectively hide any condition type from irrelevant document. For example freight conditions only relevant in delivery and not in sales order. This is achieved through “requirement” routine assigned to relevant fr eight condition(s) in pricing procedure where-in requirement routine hides the condition in sales order and displays it in delivery document.

To fulfill special requirements in text processing, it is possible to create customer own specific data transfer routines in transaction VOFM. The customer specific name space in this case is from 50 until 99.


An example for a created routine would be number 91, which then has as technical include name RV45TE91:




All created routines are inserted into the Include RV45TENN, which functions as the object holder of all:




Now of course after the creation of such an own text data transfer routine, it should be transported to the productive system. At this step you will face the problem that the include RV45TENN can not be transported.


This is due to its development class, the include belongs to package $TMP, which is for temporary objects:


As temporary objects can never be transported, the transport of RV45TENN will fail with an error message.


To be able to solve the problem, the procedure described in Knowledge Base Article 1922260 should be followed. In the transport organizer tool (transaction SE03) the attributed package will have to be changed from $TMP to VMOD:



With VMOD the transport will become possible.


Further information:


  • Knowledge Base Article:


        1922260 - Include RV45TENN can not be transported


  • CSS SAP Notes:


327220 VOFM function and its objects

Include RV45TENN has incorrect development class

32394 Change object development class allocation



As we know, we have 5 parameter help us to determine batch determination procedure for SD module within SAP system. (for instance : Sales organizaiton/ Distribution channel/ Division/ Sales order document  --  Batch Search procedure)


when we create a STO delivey document, we are referecen puchase order instead of sale order; According the batch search procedure rule, we cannot to use the purchase order document type replace sale order document type as the parameter to determine batch search procedure.




In this circumstance, we have a concept of default sale document type to solve this situation.

1. we will assign a default sale document type to STO delivery document type, eg. NLCC or NCR (as figure 1 & 2)

2. and then use the default salt document type as we peremater to determine Batch Search procedure (as figure 3)

3. at the end we activate automatic Batch determination in SD for item category NLC and NCRN


when we finished all activity that mentiond as above, then the system will automatic determine batch within STO business scenario.


Filter Blog

By author:
By date:
By tag: