Skip to Content

New Fields in Pricing

Oct 23, 2017 at 02:00 PM


avatar image

Hello all

I would like to add the field LGORT to a new condition table, by M/03.

My aim is to have a condition table containing the fields: MATNR, LIFNR, LGORT. The table already contains the fields MATNR and LIFNR, but LGORT is missing. The filed LGORT is necessary for my process.

I follow the instruction at link :

1. I added the field to the structures : KOMK, KOMP KOMG.

The field was added to a structure I built, and the structure was included in the structures above. The field called ZLGORT that should present the value of LGORT in the table T001L.

2. I added the field in the user exists in MV45AFZZ (in the forms called - USEREXIT_PRICING_PREPARE_TKOMK / TKOMP). I added the field using - "TKOMK/TKOMP-ZLGORT = T001L-LGORT."

3. I tried adding the field to RV60AFZZ, in the same forms as in MV45AFZZ, but in this form the table T001L was unknown.

What should I do in order to add the field to RV60AFZZ? Or is there another way to add the field to the customization?

Thank in advance.

Best Regards


10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

1 Answer

Veselina Peykova
Oct 23, 2017 at 02:34 PM

M/03 is for Purchasing tables, not for SD.

What is your process exactly?

I do not understand the idea behind your code sample, sorry.

Normally you populate fields in pricing that depend on certain information in the document, but if this is all your code then I am not convinced that just selecting any value from T001L is a good approach.

Show 7 Share
10 |10000 characters needed characters left characters exceeded


My process is to build a price list ,for keeping prices of services such as delivery / storage/ transportation for different vendor / storage location, and use those price list at a development plan that will take into account the costs of storage, transport and transportation to the special storage location as a refrigerant for any material received . The plan would based on the price list, at list would create an invoice for those value of services.

Thank for advance.



Now you confuse me even more. Maybe if you use SAP terminology and explain the design that your solution architect or the functional consultant proposed it will be more clear.

The only context that I know for 'development plan' term is related to HR, which does not fit into your explanation, that looks logistics-related.

MV45AFZZ is for documents like inquiries (VA11), quotations (VA21), sales orders (VA01). These all have storage location field at item level in VBAP, billing documents also have storage location, just in a different table, which is why I am surprised that you need T001L selections. Well, LGORT in sales orders is not populated in standard as far as I know, but some companies do this anyway via exits. For delivery-related billing it is updated from the referenced delivery, but it is probably not relevant in your case.


sorry for confusing you.

AT first I ment for MM process.

I need to create a pricing list not depent on any process as sale order or purchase order, just Independent.

In addition I will open a Z program that will calculate the cost of the services related to the material entering the storage location, such as a transport / storage service in MIGO movement type 101


What you call pricing list is probably a custom pricing procedure and the master data for it - either SD or MM. Doing calculations via a pricing procedure makes the most sense, because it is easier to maintain and understand compared to some z-program that just a few selected individuals know about.

Pricing procedures are defined per application. Condition types are also defined per application.

If you have decided to use procurement pricing for whatever reason then the exits that you chose are not useful for you, because MV45AFZZ is not meant for procurement.

I strongly suggest that you speak with your solution architect (if you have one) or brainstorm the business case with a few colleagues from your company. From what you explained so far it looks as if you have not decided what you want to achieve and how in great technical detail and it is not a good approach to start with development and block two of the most widely used exits in SD while you are still in design phase.


Hello Veselina

I appreciate your help. and pls I need more details.

I am limited by the process, I can not use the pricing procedures are defined per application because the order is created in another organization, they wouldn't add the costs at their procedures, and we only perform the MIGO , that why I want to use SAP standard at the custom pricing procedure and master data for it only, and make the calculate in a Z program, If the LGORT field was define at first on the structures there wasn't any problem.

Can you pls tell me in which structures and user exit I would enter my field? or the way to solve my process.

Best Regards



What difference does it make if some order is created by a different organization and you are not allowed to update costs there for whatever reason?

From your explanation I was left with the impression that all you want is to have a feature for calculating costs for reporting purposes.

Nothing prevents you from having a separate document type, e.g. inquiry, which is not allowed for manual generation, build your own pricing procedure and then either generate documents or simulate them via a custom transaction. Adjusting pricing procedures is something that most SD consultants are familiar with and even not very experienced developers can create VOFM routines with some guidance.

Seriously, speak with your solution architect or with some of your colleagues. Replicating something as complex as SAP pricing in Z* developments without a really good justification is going to be terribly expensive, time-consuming, a nightmare to support and you will probably encounter more bugs than there are notes with SD-BF-PR.

Re: exits. If you do not initiate document creation/simulation at all there is no point in adding logic in exits to populate fields in pricing communication structures - be it for SD or MM processes, because these won't be triggered.


I intend to create a new condition type ZSRV, by MEK1 transaction to create a price list document
using combination ,vendor & material & storage location fields