Professional Documents
Culture Documents
of standard condition technique. this can be used to calculate complex tax structures.
N. ALTERNATE CONDITION BASE VALUE.
The alternative condition base value is a formula assigned to a condition type in order to promote an
alternative base value for the calculation of a value.
O. ACCOUNTS KEY
The account keys form part of account determination. These keys are used here to define the posting of
the revenue generated to respective account heads& to subsequent assignment to GL accounts.
PR00- ERL
K007/KA00- ERS.
KF00- ERF.& so On.
P. ACCRUAL KEY.
The accrual keys form part of account determination. These keys are used here to define the posting of
the revenue generated to respective account heads& to subsequent assignment to GL accounts and
payment to respective parties.
How To Add New Fields To Field Catalog
For adding field into Field catalog:
I shall give an example. But you should first identify the field for Profit Center (Design ID) and then do as
follows:
For example if you want to use field PSTYV (Sales document item category) that is included in structure
KOMP (Pricing Communication Item) as a key for a condition table.
When you create a condition table (Transaction V/03), however, the system does not propose the field in
the field catalog.
Prerequisites:
For technical reasons, field PSTYV was included in structure KOMP, however, not in structure KOMG
(Allowed Fields for Condition Structures).
To solve the problem, proceed as follows:
1. Call up the ABAP Dictionary (Transaction SE11) and create data type ZZPSTYV. Choose PSTYV as a
domain.As a short text, you can use, for example, ZZ sales document item category and as a field
label, you can use the field labels of PSTYV.Save, check and activate your entries.
2. Call up structure KOMPAZ in the ABAP Dictionary (Transaction SE11) in the change mode and make
the following entry:
Component Component type
ZZPSTYV ZZPSTYV
Save, check and activate the change you made.
3. Note:Because of the change in structure KOMPAZ, field ZZPSTYV is now known in structures KOMG
and KOMP because structure KOMPAZ is included in both structures.
4. Call up Transaction SPRO. Navigate to Sales and Distribution -> Basic Functions -> Pricing -> Pricing
Control and execute Define Condition Tables. Choose Conditions: Allowed fields and include
ZZPSTYV as a new entry.
5. Note:Now you can use field ZZPSTYV as a key field when you create a condition table Axxx.
6. Supply the new field you defined by including the following source code line in
USEREXIT_PRICING_PREPARE_TKOMP:
MOVE xxxx-PSTYV TO TKOMP-ZZPSTYV.
In order processing you find the user exit in Include MV45AFZZ, and in billing document processing you
find it in Include RV60AFZZ.
Consider that you can also use this note as a help if you want to use other customer-specific fields as key
fields in a condition table.For header fields, use structure
KOMKAZ instead of structure KOMPAZ and USEREXIT_PRICING_PREPARE_TKOMK instead of
USEREXIT_PRICING_PREPARE_TKOMP.
For more information, see Transaction SPRO via the path Sales and Distribution -> System Modifications
-> Create New Fields (Using Condition
Technique) -> New Fields for Pricing and Note 21040.
For creating a condition Table:
1) There are almost all the regularly used Conditon Table predefined in the system from 001 to 500.
See what best you can use the Standard Tables to avoid further errors.
will have certain number of batches . These batches will have the number series generated wither by
internal or external generation depending upon the client requirement
2. So till all the batches are produced as per that particular Batch Master will have the same price. Like
that there will n number of batches will different different prices
3. So when you are preapring Sales Order you be only putting the tenative price for the goods that are
sold
4. Then at the time of delivery we will be picking up the goods from different batches basing on the
required delivery quantity and finally we do the PGI.
5. This is called Delivery Based Pricing becuase your price for the goods will be determined at the time of
the delivery as the goods picked up from the different batches which have different prices. ( Mind it there
will very less difference in the prices).
6. So at the time of Billing the Pricing Procedure behaves differently depending upon the differnent
batches that are picked basing on the batch determination.
7. So the prices which are detemined from different batches will be the actual prices at which the goods
are billed to the customer along with other condition that are applied as required.
Reasons For Making Any Pricing Procedure in SAP
1. Why we are maintaining separate pricing procedure for inter company sales and business
processs.
2. What is the different between standard and inter company pricing procedure and what type
condition type we are using in this intercompany.
There are two simple reasons for making any Pricing Procedure in SAP SD Modules.
1) Business Reason. What are the pricing aspects or strategies you want to apply for the client
requirement in order to sell their
goods or render services, is all about the reason for various pricing procedures.
Eg: Domestic sales pricing procedure,
- Export Pricing Procedure,
- A rebate pricing procedure or
billing and rebate credit memos. For reasons of future compatability, you will still be able to use the old
program specifications. For this reason, you must set this indicator if you want to create a special pricing
procedure. This is to prevent the program settings being used.
This indicator is also used as of Release 4.0A to redetermine the condition class and the statistical
condition indicator when copying from a reference document.
Example:
You copy prices from a shipment document to the billing document. The prices should lead to a surcharge
in the billing document. This is guaranteed by the redetermination of the condition class in the pricing
procedure.
Same case with Standard Pricing procedure or Inter Company Pricing Procedure.
This configuration is done when user request for new pricing condition type other than the standard ones
provided by the system.
Screen to tcode VA01 Create New Sales Order for customers
- Double Click the Item
- Then Click the Conditions Tabstrips
Define Condition types
V/05 - Condition Table for V/07
e.g. a business may no longer wants to have a sales discount based on the sales organization, customer
group, and material, but decided that the discount should be based on the sales organization, customer
group and material group.
V/06 Create new condition types by copying a similar conditions type and changing it according to your
needs.
Click on the Pricing Procedures e.g. PR0000 Condition Supplements for PR00
Click Control e.g. Tick Mdt if you want the condition type to be mandatory
o
OVKK Determine which Pricing Procedures to use for which Condition Type.
Price with additional decimals
You can add additional decimals for a currency through a work around method.
Set up a currency lets say instead of USD call it US$ ( OY03 ) and define the number of decimal places (
OY04 ) to be 3 or more depending on your requirement.
Maintain the exchange rate for between US$ and USD to be 1 to 1 ( OBBS and OB08 ).
Create pricing condition records for those customers requiring 3 decimal places using Current US$
instead of USD.
That will give you 3 decimal places for your prices. However, one thing you will have to watch out for is
rounding.
You can try transaction OB90, define rounding rule for currency. Here you define the rounding rule for
your customers currency.
Control Pricing Conditions based on Order Type
4.6x
e.g. You create an order type ZP00 for QT Quotation and does not wish it to be used in OR Standard
Order.
Follows this steps :IMG Sales and Distribution -> Basic Functions -> Pricing Control -> Define and Assign Pricing
Procedures
First test run by ticking both option. If you confirm that there are no errors, then run by unticking both
options.
Be careful while executing the conversion program as it can erase all your existing pricing condition data.
Once the conversion is completed, you can activate the Customer/Material with release status :IMG -> Sales and Distribution -> Basic Functions -> Pricing -> Pricing Control -> Define Access
Sequences -> Maintain Access Sequences
In VK12, you will be able to choose the new Customer/Material with the release status column per
material.
Delivery Pricing Conditions
4.6x
Configure the pricing procedure at delivery with the required condition type to determine freight. Also have
the copying control from delivery to billing at item level with Price source as D for Delivery. While you
execute billing you would get the prices from the sales order as well as from deliveries.
If you were to look at the pricing procedure RVAA01 you will see there was a section dedicated to the
various freight charges. Normally, I would use one of the available condition types and create a condition
master based on the Incoterms.
Configuration path :IMG -> Logistics Execution -> Shipping -> Basic Shipping Functions -> Pricing
Hiding condition type VPRS OSS note 105621
It tells you to modify userexits: USEREXIT_FIELD_MODIFICATION,
USEREXIT_FIELD_MODIFIC_LEER,
USEREXIT_FIELD_MODIFIC_KZWI, USEREXIT_FIELD_MODIFIC_KOPF and
USEREXIT_PRICING_CHECK.
It also tells you to create two new includes: ZZAUTH01 and ZZAUTH02, but it doesnt tell you what
changes to actually make in any of these. I am assuming that the authority checks have to be
added somewhere, but what goes where?
The coding for includes ZZAUTH* are (create them in SE38 like INCLUDE, and althought note say that
dev.class must be VF, I have them with own dev.class ie: Z**, and it works)
include ZZAUTH01
*&*
*&*
*& Object REPS ZZAUTH01
*& Object header PROG ZZAUTH01
*&*
*& This object has been generated from an advance correction *
*& attached to a R/3 note. *
*&*
*&*
*& Title: Authority check for displaying fields *
*&*
***INCLUDE ZZAUTH01.
* Beim ersten Aufruf ist KOMV initial; OLD_KOMK lschen,
* damit auf jeden Fall Berechtigungsprfung durchgefhrt wird.
* Sicherheitshalber zunchst Berechtigung verweigern.
* if komv is initial.
IF SCREEN-NAME = FCODE.
CLEAR OLD_KOMK.
AUTH_SUBRC = 4.
ENDIF.
* Berechtigungsprfung auf Kalkulationsschema und Stufen-Nr.
* Beim Wechsel der KOMV-Zeile einmalig eine Berechtigungsprfung
* durchfhren
IF KOMK-KALSM NE OLD_KOMK-KALSM OR KOMV-STUNR NE OLD_KOMV-STUNR.
AUTHORITY-CHECK OBJECT Z_KONH_KLS
ID ZKALSM FIELD KOMK-KALSM
ID ZSTUNR FIELD KOMV-STUNR
ID ACTVT DUMMY.
AUTH_SUBRC = SY-SUBRC.
OLD_KOMK = KOMK.
OLD_KOMV = KOMV.
ENDIF.
*&*
In my system (46B) I remember that the subroutines USEREXIT is not changed for this purpose. With
SU21 (z_konh_kls I think that you dont have problems), like with SU02.
In su02, remember that in XU180-PROFILE of first dynpro, you must populate with value ZCOND_STD
and click on create work area for profiles. Double click on zcond_std. In object populate with
Z_KONH_KLS, double click and you see the parameters like in tcode PFCG (profiles and auth.)
For action you can populate *
For procedure you can populate with the procedure (see tcode V/08 ) that you use in your SD documents,
or the procedure/s in where you want that the restriction will work, if you have many procedures.
For level, you must write the ranges of levels in this procedures (into V/08 ) that you want that the user
can see (remember that alpha routine conversion dont works, ie: for level 1 [in dynpro] you must write
001, if not, you will have problems). The levels out of this ranges, the user with this profile when go to
conditions in SD document will not see the value of these items.
Finally, in SU01, add this profile to profiles created with PFCG in profiles.
After check if it works.
Pricing Procedure in Product Hierarchy
Pricing structure for line item is KOMP. A quick look thru KOMP structure (tx SE11) shows that you have
only PRODH field for all 18 digits of product hierarchy, whereas you need only the first three. So you do
the following:
1. Create the new data element ZZPRODH1. Also create a domain with the length 3 and the data type
CHAR for the new data element. Remember that new data fields must start with the letters ZZ or YY,
since SAP reserved these letters to protect them from being overwritten during a release upgrade.
2. Check whether the product hierarchy (PRODH) is found at header or at item level. In table VBAP,
document field PRODH is defined as an item field.
3. Integrate the field name ZZPRODH in the communication structure KOMP using the INCLUDE
KOMPAZ and allocate the data element PRODH to it.
4. Activate the structure.
3. Create a class called Zbike with the above 2 characteristics and save the class.
4. Create a configuration profile Zbikeprof using Cu41 and assign the Kmat material to Class Zbike,
5. Then create the order and Enter the Kmat material you want in the Order.
Q In variant configuration I have configured my material properly during sales order creation it is
selecting proper characterstics but my question is pricing should calculate at characterstics level not at
header level.
A Pricing in variant Configuration is done at the Header level only. The logic is that you create pricing
variant keys for each characteristic Value. This will be done at the Header level using cond type
VA00.based on the characteristic chosen the appropriate price according to the pricing variant key will be
picked up.
Q Here my question is with out creating the materials is it possible to get price based on the
characterstics.
I am working on variant configuration here my product is 9-100. i have created characterstics for
describing colours. this characterstics assigned to class, this class is assigned to 9-100(KMAT type). here
i have not created amterial to describe each colour.
Now how I need to setup my system to calculate the price based on colour.
A A cool Question. It will really get us into the thick of things in Variant Configuration.
Here are the steps.
1. Create a Characteristic called ZColour(Standard SAP has a characteristic called colour.I did not use it.)
Give your values.
Say, Red & Blue
2. Now create another characteristic called ZCol_surcharge
Give the description and go directly to Addnl Data Tab.Here in the table name Enter SDCOM and in the
Field Name Enter VKOND.The system will pick up the format from the Dictionary.
when am creating the sales order price is coming only for RED colour not other colours. even price is
maintained for all the colours.
A Seems like there is a mistake in the line $self.ZPRICE = RED (You have said you have given this for
all the values- If I have not mistaken). This refers only to red colour.
In front of 000010 Enter $self.ZCol_surcharge=RED.
Similarly Select Blue in the Values Tab and enter $self.ZCol_surcharge=BLUE
All this is Case Sensitive. So please be careful.
1.
Hi,
I also have a complicated requirements for shipment costs. I need to cumulate all items quantities in
order to determine each item condition value. In a shipment cost document there is no total quantity
field and the only field that gives me a quantity at item level is KOMP-MLGME or KOMP-MGAME.
I thought of addressing this requirement by calling other tables such as VFKP or VFSI or VTFA but Im
not sure if this is possible. What I would like to do is as follows:
VFSI (VBELN to determine the delivery number);
VTFA (VFSI-VBELN = VTFA-VBELV to determine the shipment number TKNUM);
VTFA-TKNUM: each item (POSNR) cumulate all referenced quantities (RFMNG) = Total Shipment
Quantity
KOMV-KWERT = (each item quantity / total shipment quantity) x KOMV-KBETR