Skip to Content
0

Retrieving Pricing schema - ABAP FM?

Oct 23, 2017 at 07:19 AM

83

avatar image

Hello all,

i'm developing a tool to help people into managing pricelists for sales (basically VK11-VK12).
There are many functions to update conditions and i'm using them with a good success.
But now i want to take a step further and i want to help my users proposing only the right conditions for the according schema of pricing.


What i found out

The list of available conditions for a given schema is stored in table T683S and the available schemas for Sales Organization and Documents are stored in table T683V.
But i'm a step before this, because when a pricelist is filled for a material (VK11-VK12) i do not have the informations about which document will be used (needed to read correctly table T683V), so for a sales organization i can have a lot of different schemas and i cannot link the correct one to the corresponding A... tables (i.e. A908), the one with the keys of the pricing (basically the popup you see in VK1x transactions).

The search i did

Like the candid soul i am, i hope SAP would provide any FM (even not released) to get schemas and i tried the following ones

  • PRICING WB2_GET_PRICING_SCHEMA
  • WLF_GET_PRICING_SCHEME
  • SPR_PRICING_SCHEME_GET
  • PRICING_SCHEME
  • CONDITION_TABLE_ARRAY_READ

And many others (most where blind shot) i tried to debug a bit the VK13 and the FM RV_CONDITION_COPY but i ended nowhere.

The need

So, reached this point, i'm start to wonder if what i got in mind it's even possible or if my users will have no other guidance into creating their pricelist.
i know i can use a workaround like a set or some entries in TVARVC table to propose these conditions (we got a somehow rigid schema of condition: i'm going to replace an old program with fixed columns), but i found it somehow limiting because if the usual schema will be changed, i'll have to maintain the array of conditions.
And i hate that, because i'm sure that tomorrow i'll win lottery and my documentation about the procedure will be forgot the exact moment i deliver it.


Any idea or suggestion about the topic will be greatly appreciated.

Technical note

i'm on SAP NW 731 :)

Thanks all!

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

1 Answer

Best Answer
Veselina Peykova
Oct 23, 2017 at 09:32 AM
1

Hello Simone,

it is great that you are thinking of ways to make the life of business users easier, but I am afraid that what you ask is not really feasible, because you will end up in a lot of complexity.

Even if we assume that we can obtain the sales org./distr.channel/division for which the user is responsible to maintain conditions by certain assignment, then we have the problem with different document pricing procedures (which you already noted) and in certain scenarios, for the same criteria - different procedures depending on the customer. Probably not all companies use this, there is a chance that yours does not have customer-based procedures, but there is always this 'yet'.

Let us assume for now that you start maintaining somewhere assignments on job positions and that the master data team and the business will be able to maintain these correctly and on time and you can successfully determine what condition types a user may need in his job. At this point at best you will have a list of condition types, not the level where a condition needs to be maintained. And you actually need to know the right levels applicable for a specific scenario.

Yes, you could get a list of the possible levels from the access sequence, but what if the condition table uses a property or a partner function that is not applied always in some documents? Or what if there is a requirement in the access sequence that checks specific properties before the condition record is evaluated?

I do not wish to be too negative but apart from business users learning how and where certain conditions on specific levels are used and being informed in a timely manner about changes I do not see other way to ease the situation. Of course, if you introduce new products often, people know that they will need at least some base price conditions, but for discounts/surcharges you usually maintain these when you are informed that sales made an arrangement with a certain group of customers that product group A will be with X% or some flat value discount when they purchase quantity B, but when they get quantity C it has to be Y% or a different flat discount. Or Logistics and Sales gather on a meeting and decide that for rush orders if you buy in custom packages they need to introduce surcharge for some groups of customers starting from next month. I do not think that it is typical for a user to sit and maintain everything possible for a group of products - it is often done on demand and based on information that is not available in the system.

For some really simple cases you might be able to guide people to select the right condition and level by asking questions and limiting the selection, but usually users responsible for pricing condition maintenance are well trained and can figure out these situations on their own by making a test case in the training or QA system. In some organizations at least some pricing conditions are maintained centrally by CMDT with templates that the key user fills after discussing the best approach with the SD consultant (especially for uncommon or new processes for the subsidiary) in which case this will be probably done via LSMW...

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

Hi Veselina!

thanks for your reply: i was silently hoping in an answer by you!
i agree with you on all the line about the complications which could araise into simplify too much the pricing update.

The users already have a template in XLS which they feed to the system via custom report, report calling a BDC to VK11.
Right now, we are moving things to UI5/Angular Application in order to replace the template, to give a bit more flexibility and to make their work less XLS dependant yet fast enough.


In this scenario i was looking a way to pre-filter the different conditions.
We have often a change in pricelists (about once per quarter) according to some market parameters and we have around 10 new products per year as well as opening 2 new plants per year.
As you can see, the pricelist changes are quite often this way, even if the structure is pretty static.


i think i'll replicate somehow the actual template, avoiding the hardcoded values and doing my best to keep things simple.
Again, thanks for voicing and reflecting my doubts as well as giving me some clubs i could use against the management for when they'll ask why i'll put some kind of limitation or "not too much" help!

0

I do not know if this could look well in a UI5 app (I suspect - not), but you could probably think of making it like guided choices for the most typical tasks:

Do you wish to maintain base price for new products? (To be honest for this case I would prefer some workflow based on material view created and certain status set instead of waiting for someone to tell me that I should proceed with condition maintenance).

Do you wish to extend price list validity?

Do you wish to increase/decrease prices for a price list?

(These two can be combined in a single activity, but for some users it can be confusing).

Do you wish to maintain discounts/surcharges? and so on...

Usually there are just a few mandatory conditions in a pricing procedure that users need to maintain for new material codes and for the first option you can present just these. The users know at which level they maintain base price in most typical cases (or you could check in the system and let the business confirm if you understood correctly) and you can set it as default, then give them a choice to switch to a different level.

Unless you have plant-specific prices, opening new plants (if you do not introduce new products and if these plants are for existing sales organizations) will not have much impact on condition record maintenance except for conditions based on regions. In this case they will probably refer to existing combinations and adjust values in a second step.

0

Sadly, plant specific prices here!

But thanks a lot for all the input!

0