SO Number as a field in Pricing Access Sequence

[Former Member]

Requirement : To have an access sequence as " Sales Org \ Sales Order Number \ Material "

Issue: In the field catalogue, a field "Sales Document Number" is there, but it is not solving the requirement as for each document i.e. SO / Deliv and Invoice, the Sales Document number will take the different number, so the access created using above sequence will not be valid for deliv and invocie hence pricing will be incorrect.

Constraint : Have to keep pricing update in copy control as " Copy Manual and Redetermine Others" due to dependency over several Sales Orgs using same Pricing procedure.

Help required: I have gone through  numerous threads, many talking about Field catalogue, adding a Z-Field to field catalogue, creation of condition table But I am not able to find a proper solution to my requirement of keeping " SALES ORDER NUMBER".

Why this problem is unique to any other thread related to the access sequence / condition tables as the field " Sales Document Number " in the catalogue is already refereing to VBELN of KOMK, so I dont think that I can add a new field in catalogue specifically refering to Sales ORDER NUMBER only. So how do I get the desired requirement fulfilled keeping the constraint in cosideration.

Please help as to how can I address this issue even the ABAP solutions are welcome.

[Jelena]

Just like everyone pointed out, the sales document driven pricing should not be redetermined.

If pursuing access sequence with document number and price redetermination, then obviously a user exit will have to be implemented in every "touchpoint" to ensure that the right sales order number is used (I would suggest to leave the field names and other technical details to the developer). SD user exits are very well documented on SCN.

Certainly we can create the custom pricing conditions types and a suggestion by Yathish to have one that is both condition driven and manual might (or might not) work. It would just have to be prototyped. We had a pricing condition like that, but ended up scratching it because it was a hot mess and did more harm than good.

I'm not an SD expert, but overall this whole idea just doesn't feel right. Having pricing conditions based on just one document # kind of defeats the purpose of using condition records in the first place. And what about returns and credits? Maybe a better/simpler solution would be to go with the manual pricing altogether.

[Former Member]

@ Jelena,

I also have the same view that Manual pricing would have been the easiest solution but you may understand...clients have their unique issues.

in this case, the guy making the SO cannot be given the authorizations to enter manual pricing conditions and still needs va02 to make changes as required. so the problem is unique, might sound over the board but still I need to find solution for it.

[Jelena]

Sachin, it's possible to apply authorization check at the pricing condition type level. It's a customization, but there is an OSS note that describes the implementation - look it up. This still would be better than other options mentioned here, I believe.

[Former Member]

Hi Jelena,

I had already searched for SAP Note (sapnote_0000105621), this solution involves much more development and also the impact analysis for our case will be much difficult.

So I am looking for a simpler solution.

[Jelena]

Sachin, there is not more development in the note than if you stick with the intended solution of using access sequence. Also with the note the development will be limited to the sales documents, but with the other option you'd have to "touch" the whole document chain. Not sure how impact analysis could be any simpler in such case... Have you talked to an ABAPer about this?

It's pretty clear from all the previous posts thata there is no "easy" button in this case. So either way some custom development will be needed. From what I see, with the authorization check (per SAP note) the users won't have to do an extra step and enter the condition records and also you will have a better authorization management options.

You don't have to follow the exact implementation example given in the note, you could create any custom authorization check using that technique (e.g. just by condition type and activity).

[Former Member]

Hi,

Can We use below field combinations

VBAP - AUBEL  = Refrence Sales document Number(all the sales order reference number will come in this field and if you are creating billing document against more than one sales order also this will help full)

VBAP - POSNR = Item Number. (Item number of the billing document number)  

or VBAP-MATNR = Material code. 

VBRK - VKORG = Sales organisation. ( Sales organisation from the billing document header)

if we create condition record for above fields. i think it will solve the issue.

Regards

Gajanan

[Former Member]

vbap-aubel contains the SO NUMBER but how can I incorporate the same in an access sequence is the trouble.

[Former Member]

Constraint : Have to keep pricing update in copy control as " Copy Manual and Redetermine Others" due to dependency over several Sales Orgs using same Pricing procedure.

In case the issue can be resolved if the above constraint is addressed, you could try having a copy of standard copy control routine.  Execute  rule  " Copy Manual and Redetermine Others" for other sales org and use an option to not to re-determine price for the sales org where it should not be re-determined. That way you build in the flexibility to handle the price determination differently for different sales org while retaining the same pricing procedure.

[former_member182378]

Yathish,

Creative idea!

Thank you!

One quick question -

Can we create our own pricing type (z*)?

I check my organization's sandbox system, there are not new customized pricing types created.

If yes, then where can we do this?

, could you please comment on - can we create a customized pricing type? If yes, where?

[jpfriends079]

TW

I like to draw your attention towards 2 things here:

1. Nice to see that you put effort in exploring your IDES/your organization's sandbox system. But, in same time you would appreciate the fact that one should effort in search also before raising that same as discussion. "Reserve pricing type" is well discussed topic on SCN. And further clarity you can refer SAP Note 24832 - Pricing rules / TVCPF for your requirement.

2. Still, OP didn't seek info on reserve pricing type. Please don't get in habit of hijacking others discussion for asking your question or seek information. So, if you like to learn or seek information. As I did indicated this in past, there is no harm in starting your own discussion.

It is nice to have you & your contribution on SCN.

In anticipation of understanding.

Thanks & Best Regards, JP

[former_member182378]

JP,

Thank you for your post!

We should search the internet before we put a question in the forum(s). Importantly, searching the forum gives a learning that is (arguably) unmatch (by any other method)!

I shall adhere to your advise.

Actually, I was searching the internet, for some answers, when I saw your post in my "Communication" button, here in SCN.

Coming to the "hijacking part", I do not agree with you.

One of the suggestions to the OP's issue is to have a customized Pricing type.

To know if indeed a customized pricing type can be created, with the necessary logic; I have asked this question to some "Techno-Functional" members.

Thus my query here is in line with "providing a solution to the OP's query". Thus I don't think it is hijacking.

Further, if posts are related (probably "around the OP's topic") I think moderators should allow it. As this is the place where we can discuss, throw in ideas, "do some co-relation across SD functionalities".

This is my view and my request. As ultimately this forum (or any other forums) is just a "tool" for us to learn and serve our clients better.

Thanks again for your post!

[former_member184065]

Dear,

Whatever you asked that was your doubt not OP guy Query .So ,obviously ,there is major chances to creation of New query by you and one thing is ,we can easily can get this type of queries in Google when this query will be separately answered .

Note : This is my Opinion .

Thanks,

Naren

[former_member182378]

Sachin,

I am not enthusiastic about the idea of creating condition records at a document number level!

What is the business reason to do so?

There are other options to fulfill this requirement, without condition records.

How is a sales document different from another, when ALL the master data remain the same?

[bsivasankarreddy_reddy]

hi

In the field catalogue, a field "Sales Document Number" is there, but it is not solving the requirement as for each document i.e. SO / Deliv and Invoice, the Sales Document number will take the different number, so the access created using above sequence will not be valid for deliv and invocie hence pricing will be incorrect.

billing level what type issue you facing , can explain  briefly ,  and also check the billing level condition records for this access sequence ( condition type) ,  here sale document number level which document its flowing,

@jyothi prakash : in billing document level  VGBEL =  delivery number not a sale order number,

vgpos=  delivery item number its feated for table level ,

AUBEL - sale order number ,  AUPOS - sale order item number   stored at VBRP table level ,

so you can add the field sales document number ( AUBEL) , check the v/03 level , you find the this field , replace this field for yours access sequence level , Then you test the process

[Former Member]

Hi Bojja,

See I made an access Seq : S_ORG / Sales Doc / Material. I created the condition entry and it worked correctly for the sales order. using this access, say the price of 10 USD was picked.

Now when I reached the Invoice, i wanted the pricing condition to remain at value 10 USD , but the above access is not valid while doing invoice because system wants the access now to contain Invoice as sales document number and Not the order number.

Please note that I know If I change the pricing update rule in copy control to "Copy all elements unchanged", then this issue will be solved ,but I have a constraint to keep the pricing update as " Copy manual and re-determine others".

Thats why I am looking at making Access as S_Org / SALES ORDER NUMBER/ Material. I need pointers to achieve this.

[former_member182378]

Sachin,

Create another condition type (ZMAN) add it to your pricing procedure. Set this condition type as manual and mandatory (in your pricing procedure).

The condition type that is "linked" with condition table S_Org / SALES ORDER NUMBER/ Material, make it statistical.

Because this condition type has a condition record, the value of this cond type shall populate in your pricing procedure automatically.

The user shall have to manually enter the value of ZMAN, which would be same as the above condition type (with cond table S_Org / SALES ORDER NUMBER/ Material).

As condition type (with table S_Org / SALES ORDER NUMBER/ Material) is statistical, it would not impact the net value.

And user would have to enter the value of ZMAN, without which the sales order can not be saved.

Note: If needed, your ABAPer could write a requirement routine and put it adjacent to ZMAN. This requirement shall be satisfied only if there is any value of the cond type (with cond table S_Org / SALES ORDER NUMBER/ Material)

So if the value of this condition type (with tableS_Org / SALES ORDER NUMBER/ Material) is not found, then ZMAN would not be mandatory!

[Former Member]

Dear Sachin,

System will take respective sales document number (i.e. order, delivery, billing etc) in access sequence if you have used field "sales document number" in your access sequence.

What I understood from your requirement is that you want to carry out pricing only based on sales order number. If I am correct than follow the below step to achieve the same.

1) Add new Z field in structure KOMPAZ let say ZZSALEDORDNO.

2) Now this field will be available in pricing catalog to be used to create condition table.

3) Create new condition table and access sequence.

4) Pass sales order number VBAK-VBELN in field TKOMK-ZZSALESORDNO through user exit MV45AFZZ and form routine USEREXIT_PRICING_PREPARE_TKOMK.

write a logic before passing the sales order number to check the document category being process.

If current document being process is sales order (i.e. document category is "C") than pass VBELN directly.

If current document being process is sales delivery (i.e. document category is "J") than pass LIPS-VGBEL.

If current document being process is sales invoice (i.e. document category is "M") than pass sales order number deriving from table VBFA.

By doing so system will pass sales order number every time in access sequence irrespective of transaction being process.

Hope this will help you.

Thanks,

Tarpan

[jpfriends079]

Try with Condition Table 372 : Sales org./Ref.doc./Ref.item

But, make sure that sales order/Item no stored as reference doc (VGBEL)/ Reference Item(VGPOS) in Billing Document: Item Data(VBRP).

So, to check whether your copying control header (VTFL or VTFA) for Reference number(B - Sales order number) setting, to make sure sales order data get populed as reference in billing.

Cheers, JP

[Former Member]

Hi Jyoti,

Thanks for response.

In VBRP, the field AUBEL is having the SO number and not the Ref Doc. So the standard condition table 372 is not working.

I already tried it.

[jpfriends079]

Thanks Sachin & Bojja for correcting me.

Sachin

Try with following combination, Sales Org / SD Doc. / Item / Material

Thanks, JP