Daily Archives: October 23, 2007

Pricing in SD (in detail)

Definitions of Fields in Pricing Procedure

This indicates the number of step-in the procedure.
This is used to show a second ministep
This is the most important component in the pricing procedure. The rates are picked up from this element, on the basis of the properties described.
This forms the description of the condition type.
This is used to define the progression of the calculation and range of subtotals
This is used to define the progression of the calculation and range of subtotals
This function enables to allow the condition type to be entered manually also apart from automatic pickup.
This function identifies the conditions that are mandatory in the pricing procedure. The sales price is a mandatory condition type.
This can be used to represent the cost price of the material sold, generally used for study statistical impacts of price
The activation of this function will enable the printing of the values and conditions to the document.
A key is assigned from the drop down menu; this can be used by the system in other area like Sis for reporting purpose also
This function is used to assign a requirement to the condition type. This requirement can be used to exclude the system from accessing the condition type and trying to determine the value. This can be used to specify that the condition type should only be accessed if the customer has a low risk credit.
This function allows you use a formula as an alternative in finding the value of the condition type, instead of standard condition technique. this can be used to calculate complex tax structures.
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.
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.
K007/KA00- ERS.
KF00- ERF………….& so On.
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.


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

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:


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

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.

2) In case you should define the new condtion Table,

a) Goto TCode: V/03

b) Give a Table any number from 501-999

Press execute and reach to next screen.

c) Check up whether the field you are looking is already added in Field catalogue.

d) Double click on the fields you want to make a Table..one by one. Note that the sequence here is important in higher hierarchical to lower..

Eample : Sales Org, DC, Division, Customer and then Material etc..,

e) After selecting, click on the Techincal View buttin (redone) and reach to next screen.

7) Check which key should be in header and which key should be footer. Use check and uncheck functionalities there..

8) Once you are through with all the above steps ..click on generate button.

Check the Table is generated or not.

You can check it at V/04 or V/05 or in SE11.

Can Sales Order and Billing Have Different Pricing

Yes, can have 2 different pricing procedures

1. One for Sales Order
2. Another at the Billing

Let us take an example:

Generally in the Pharma industry this procedure is adopted becuase all the goods are batch price based.

1. In the Pharma Industry whenever the goods are manufactured it will done in a batch to keep track and price is fixed, I mean there will be a Batch Master which has a certain price fixed for it. This Batch Master 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
– A High Discount oriented pricing Procedures.
– A repair pricing procedures.

You have your own conditions intended to few transactions only. Put all this conditions as a set defining your own Procedures. It may even include special requirements and formulas applied for such Pricing Procedures.

2) A special pricing procedures, in order to facilitate added functionalities of SAP pricing architecture, we must define new
pricing procedure. SAP Standard programmes checks these special Indicators in-order to do some required functions.

As a example 1, you need to have a Pricing procedure for condition supplement inorder to use the condition supplements. The condition supplement pricing procedure must be given in the condition type definitions (v/06) of the Pricing Condition where you need to supplement, without which SAP SD Condtion Supplements functionality doesnt work.

As a example 2, you need to have a Pricing procedure for Inter Company Billing Conditions(IV01 & IV02) inorder to be active for Inter Company Billing specific transactions. Thus make sure that, the procedure wouldnot apply for non-Inter company transactions.

Eg: KA0000 for Condition Supplement for KA00
– PR0000 for Condition Supplement for PR00
– ICAA01 for Inter-Company Billing

Here I would like to remind about a important field in pricing.

In V/08 of defining a new Pricing Procedure, in main screen, you have a field called TSPP (Transaction Specific Pricing Procedure). This has to be ticked on for Intercompany Billings.

The SAP help reads for this field as Under:

Transaction-specific pricing procedure

Pricing procedure transaction-specific indicator

Before Release 4.0A, no special pricing procedures were used for intercompany billing and rebate credit memos, programs were just set accordingly to deal with these situations. As of Release 4.0A you are offered greater flexibility in the form of the option to define special pricing procedures for intercompany 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.

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.

  • Double click on the condition type to change the control options

V/07 – Access Sequences for condition type

V/08 – Pricing Procedures for condition types.
The pricing procedure is also used in the account determination. This determines the general ledger accounts to which prices, discounts and taxes must be posted.

  • 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
    • OV34 – Define account key
    • OV35 – Assign account key
      • Actky – Revenue account
      • Accrls – Accruals account

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 let’s 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 customer’s currency.

Control Pricing Conditions based on Order Type


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

Define document pricing procedure
e.g. Q – Quotation

Assign document pricing procedures to order types
e.g. Assign Q to Order Type QT – Quotation

Maintain pricing procedures
e.g. Copy Standard Pricing Procedure to e.g. ZQT (all the pricing conditions list will only be allowed in order type QT – Quotation

Define Pricing Procedure Determination
e.g. Copy and assign Document Pricing Q and Pricing Procedure ZQT accordingly

Users will receive Message no. V1 206Condition ZP00 is missing in pricing procedure A V ZQT“.

Create a New Pricing Conditions Key Combination


In VK12, click the Key Combination button. You can see a list of available key combination for your price master.

Now, let create a new key combination e.g. Customer + Sales Document + Material

IMG – Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition Tables -> Create condition tables

e.g. 900
Selected fields
Sales organization
Distribution channel
Sales document
Click Generate to activate it

IMG – Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition Tables -> Defince Access Sequences -> Maintain Access Sequences

Select PR00 – Price
Click Accesses
Click New entries

AcNo Tab Exclusive
50 90 X – Tick

Save your entries

IMG – Sales and Distribution -> Basic Functions -> Pricing Control -> Define Condition Tables -> Defince Access Sequences -> Optimize accesses

Copy an existing PR00 and substitute the AcNo with 50

Finally, goto VK12 and key in the new price master for PR00.

Next, goto VA02 and test out the material. If it didn’t work check the pricing date in the header details. Is the pricing date within the validity period?

Pricing Release Procedures


Define Processing Status – SM30 -> V_T686E

You are free to design your own processing status flow.
e.g. from 01 -> 02 or
from 01 -> 02 -> 03

To convert the old Pricing Condition with the release status use program SD_MOVE_A004_TO_A304.
For the standard tables, the following pairs of condition tables are intended to be used:
‘old’ <–> ‘new’ VAKEY fields
A004 <–> A304 VKORG + VTWEG + MATNR
A007 <–> A307 VKORG + VTWEG + (SPART) + KUNNR

For example, if you are using A005 –> A305, you have to copy the program to ZSD_MOVE_A005_TO_A305 and amend the program Source and Target table.

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


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 also tells you to create two new includes: ZZAUTH01 and ZZAUTH02, but it doesn’t 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 *
* Beim ersten Aufruf ist KOMV initial; OLD_KOMK löschen,
* damit auf jeden Fall Berechtigungsprüfung durchgeführt wird.
* Sicherheitshalber zunächst Berechtigung verweigern.
* if komv is initial.

* Berechtigungsprüfung auf Kalkulationsschema und Stufen-Nr.
* Beim Wechsel der KOMV-Zeile einmalig eine Berechtigungsprüfung
* durchführen

* Ende Berechtigungsprüfung

for include ZZAUTH02

*& Object REPS ZZAUTH02
*& Object header PROG ZZAUTH02
*& This object has been generated from an advance correction *
*& attached to a R/3 note. *
*& Title: Authority check for creating new conditions *
* Ende Berechtigungsprüfung


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 don’t 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.

5. Check in which table the field PRODH exists.
The field is in table VBAP (sales document: item data).

6. Assign a value to the new field in the FORM routines for sales order processing and billing using the appropriate user exits: In sales order processing the user exit is found in member MV45AFZZ. The complete statement is:
The routines for assigning a value to the new fields in billing are found in member RV60AFZZ. The statement is as follows:

7. Allocate the specifications A, V and 001 to the field ZZPRODH in table T681F. Use “E” has been added for fields in rebate processing.

This is a standard example from SAP Library. In this case you must tell the ABAP three things:
– that your source field is VBAP-PRODH,
– that you need to get the first three digits from that field into your pricing structure KOMP
– and that you need to specify the transfer by user exit thru MV45AFZZ

Please note that this is a very simple example. Quite often you have to dig a lot deeper.

Modifications of Copy Control routines, making output forms (thru SapScript) and such requires you to know all the necessary tables, structures and fileds.

The only advice I can give you is to use tx SE11, which will show you the organisation of a table/structure, and can also help you check the contents of a specific table in a specific sales doc.

Steps for Variant Configuration and Pricing

1. Create a Material of your Motor Cycle using Material type KMAT(MM01).

2.Then create a characteristic called ZColour(SAP has a standard Characteristic for this but it has multiple values-i.e you can select more than one colour for your Bike.If you do not want that create your own)with character format and assign single value radio button on the initial screen. Go to values Tab and give the colors you need.save the characteristic. Similarly repeat for CC (I figure this CC as 100cc & 200cc kind of thing. If you want these as materials then it is a different story-I am taking this as feature as well)

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.

3. Now go to CT04 and change the Characteristic Zcolour.
Go to values tab and select RED.Goto Extras-> Object Dependencies->Editor and then select Procedure.

In front of 000010 Enter $self.ZCol_surcharge=’RED’.
Similarly Select Blue and enter $self.ZCol_surcharge=’BLUE’

3. Link both these characteristics to the Class(The class which you have attached the KMAT Material).

4. Go to VK11 and the Enter VA00.Then give the values RED and BLUE and enter the values.

5. Go to your order and Enter your material.

Q – Here are some clarifications required from you.

what is the significance of item category group 0002 and 0004. Apart from these are they any other item category groups are available for configurable materials ?
In BOM header material having components. is it possible to make the component as configurable material.

A – The difference b/w 0002 and 0004 is basically that of LUMF & ERLA.
In 0002 the pricing happens at the Header Item Level.
In 0004 the pricing happens at the Sub Item Level.
Check out the Item category Assignments and things will be Clear.

I think these two are the only ones used for Configuration.

Please let me know in which Scenario you would like to have the configurable material Inside a BOM(as it would help me in visualising thh Item Category Assignment).

Q – As you said I setup my system to calculate price based on colour.
ZCOLOUR contains all colours in values tab page.
ZPRICE contains table name and filed name in additional data tab page.

I went to ZCOLOUR characterstics I maintained (extras-object dependicies-editor-action) there I have given $self.ZPRICE = ‘RED’ for all the values.

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.


Credit Management

All business have their own credit management needs, SAP allows you to specify your own automatic credit checks based on a variety of criteria. You can also specify at which critical points in the sales and distribution cycle the system carries out these checks.

  • SM30 – Table/View
  • V_TVTW – Define Distribution Channel
  • V_TVTA_KKB – Assign sales area to credit control area
  • V_T014 – FI – Define Credit Control Area
  • T001CM – FI – Assign Permitted Credit Control Area to company code

OVXG – Set up Sales Areas
e.g. Sales Organization
Distribution Channel
Distribution Channel

FD32 – Customer Credit Management

OVAK – Define credit limit check by sales document type

  • Check Credit
    • A – Credit limit check and warning message
    • B – Credit limit check and error message (no sales order can be created)
    • C – Credit limit check and delivery block (block delivery if hit credit limit)
      • Options B and C -> used for checking open order values (when you create/change the sales order)
    • D – Automatic credit control with open order values
      • More control in transaction OVA8 – Automatic credit control
      • You check for open orders and deliveries, or just open deliveries.
      • or open order values with other options
  • Credit group
    • Allows you to combine different sales document types for the credit limit check

VKM1 – Blocked SD Documents – Finance have to released the delivery block

OVAD – Define credit limit check by delivery order

  • whether the automatic credit check occurs at the time of delivery creation and/or goods issue

OVA7 – Define credit limit check by item category

  • Set whether to include/exclude item category for credit limit check

OVA6 – Define credit group. You can groups together different business transactions which should be dealt with in the same manner with regard to the credit check.
You enter the credit groups when you configure the sales document types for credit management and define the (D – automatic credit check).

  • SAP default credit groups
    • 01 – credit group for sales order
    • 02 – credit group for delivery
    • 03 – credit group for goods issue

OVA8 – Automatic credit control – Double click on the line itemsYou can have the followings credit limit check :-

  • Static

Depends on the customer total value of open orders, deliveries, billing documents and open items.

  • Open items

No of days open
Overdue open items checks is based on the ratio of open items that are overdue by a certain number of days.Max open items %
The customer balance must not exceed a certain percentage.

  • Oldest open items

If you don’t want to deliver to the customer at all when even only 1 invoice is overdue.
Tick the Check for Oldest Open Item and Set the field Days oldest item = 1.Days oldest item
No of days allowed for overdue or payment terms.

Use of the credit check Oldest Open Item. If a user attempts to alter the order quantity of a released sales document
that was previously blocked, it would be reblocked again by the system. The system only reblocks the sales document if the new order quantity is above a certain % amount.

  • Released documents are still unchecked

The preset % is whatever you want to set it as when configuring your automatic credit processing. You enter a deviation % and number of days,eg, you can set it so that an order can be changed by up to 10% within 30 days of original order entry date without it going back on credit block.

  • Next Review Date

If a customer has a credit limit of 1000 USD, and you would like to restrict this credit limit only to be available in current month (say March). If the document day is in April then the credit limit is zero.You can use the “NextReview date” and “Number of days” fields and combined it with the “Last int.review” field in customer credit master “Status” view (FD32).

VOKR – Display of work list for credit management (configure the display variant)

Releasing the Credit Block

These are the three transaction code you can used for releasing the SAP credit management block.

VKM3 – Sales Order

VKM5 – Delivery Order

VKM4 – Both Sales Order and Delivery Order

Useful SAP Credit Management program

RVKRED06 – Background jobs for checking blocked credit management.
If an order is no longer outside the horizon as defined in the dynamic credit check, (i.e. it is INSIDE the horizon) it can cause existing “good” orders to block. If you run this job every night, if you have your horizon set for 1 month it can cause a lot of blocks at beginning of month. Try to use ‘W’ for weekly horizon status.

RFDKLI10 – Customers With Missing Credit Data

RFDKLI20 – Reset Credit Limit for Customers

RVKRED77 – Reorganize SD credit data
When updating errors occur, it enables you to reorganize the open credit, delivery and billing document values.

RVKRED08 – Checking sales documents which reach the credit horizon
You should runs this report periodically, usually at the start of a period. The report checks all the sales documents, which reach the dynamic credit check horizon. The period for the ‘date of the next credit check’ is proposed from the current date, with the help of the period split for open sales order values.

Static and Dynamic Credit Check

Tell me the difference between Static and Dynamic Credit Checks.
What is the difference between the Open Order Value used in Static check and the one used in Dynamic Check?

*Simple Credit Check :*

Tr.Code – FD32

It Considers the Doc.Value + Open Items.

Doc.Value : Sales Order Has been saved but not delivered

Open Item : Sales Order has been saved , Delivered, Billed & Transfered to FI, but not received the payment from the customer.

*Static Credit Check*

it checks all these doc value & check with the credit limit

1) Open Doc.Value / Sales Order Value : Which is save but not delievered

2) Open Delivery Doc.Value : Which is delivered but not billed

3) Open Billing Doc.Value : Which is billed but not posted to FI

4) Open Item : Which is transfered to FI but not received from the customer.

*Dynamic Credit Check*

1) Open Doc
2) Open Delivery
3) Open Billing
4) Open Items
5) Horizon Period = Eg.3Months

Here the System will not consider the above 1, 2, 3 & 4 values for the lost 3 months.

Settings for SAP FI Credit Management

The Credit Control Area is an organizational unit that represents an area responsible for granting and monitoring credit. Credit information can be made available per customer within a credit control area. One will use one credit control area that is four characters “JHEN”. All of the available functionality for credit management will not be used since a service has already been provided.

Stopping the billing process is not an option Organizational unit in an organization that specifies and checks credit limits for customers. A credit control area can include one or more company codes. It is not possible to assign a company code to more than one credit control areas. Credit and risk management takes place in the credit control area.


OB45 – Maintain Credit Control Area
A company code can be assigned to one credit control area. However, a credit control area can be assigned to more than one company code.

OB38 – Assign Company Code to Credit Control Area.
If your company have different business area, you can assign each with a Credit Control Area. e.g. 0001 for BA-A, 0002 for BA-B, 0003 for BA-C etc. In this case, the same customer master code can have different credit limits for the different Business Area.

OB01 – Define Credit Risk Categories.

OB02 – Define Account Clerk Groups

OB51 – Define Credit Representatives

OB39 – Define Intervals for Days in Arrears for Credit Management


What is Forward and Backward Scheduling?

What do you mean by forward scheduling and backward scheduling?Backward scheduling is the calculation of deadline dates: the arrival time at the customer site is calculated as the earliest possible goods receipt time at the customers unloading point on the requested delivery date. All four of the delivery and transportation scheduling lead times are subtracted from the customer’s requested delivery date to determine if this date can be met.

The transit time, loading time, and pick/pack time are subtracted from the customer’s requested delivery date to calculate the required material availability date.

The system calculates backward scheduling as follows:

Requested delivery date minus transit time  = Goods issue date
Goods issue date minus loading time = Loading date
Loading date minus transportation lead time = Transportation scheduling date
Loading date minus pick/pack time = Material availability date

By default, the system will calculate delivery dates the closest day, taking into consideration the working days of the shipping point and a rounding profile. In this case the system assumes a 24 hour work day and lead times can be entered in days up to 2 decimal points.  This is referred to as daily scheduling.

Precise scheduling calculated down to the day, hour and minute is supported.  This allows the scheduling of a delivery within a single day.  It is activated by maintaining the working hours for a particular shipping point.

Backward scheduling is always carried out first.  If the material availability date or transportation scheduling date is calculated to be in the past, the system must then use forward scheduling.

Third Party Order Processing

Third party order processing is as follows:

Assume three companies X, Y and Z
X – The company,
y – The customer
Z – Vendor

When ever X gets a PO from Y to supply some goods, X has an option of either manufacturing those goods or procuring those goods.

If he is procuring the goods, there are two methods that are generally followed:

Method 1) After receiving the PO from Y, X creates a sales order against Y.
Now at the same time he also creates a PO to a vendor Z to produce the goods
Z produces the goods and supplies to X
X receives the goods from Z
Then X delivers the same goods to Y.
After that X invoices Y and Z invoices X.

Note : Here there is no direct/ Indirect relation between Z and Y.

This process is known as Trading Process. and the Material here is created  with Material type HAWA.

The other method is a Third party order processing method:

Here the glaring difference is that instead of Z supplying the material to X and X in turn supplying the same material to Y.

X authorizes Z to supply the material to Y on his behalf and notify him once the delivery is complete.

Now Z supplies the material to Y and acknowledges the same to X.

Z  will send a copy of delivery acknowledgement and invoice to X.

After receiving the delivery confirmation and invoice from Z, X has to verify the invoice and this process is known as invoice verification and is done in SAP through Tcode MIRO.

The next step for X  is to create an invoice and submit to Y

Only after the invoice verification document is posted  then only X can create an invoice for Y.

This is the business flow that is followed for third party order configuration.

There are few steps that have to be configured to enable the system to function as mentioned above.

If you are always followwing a third party process for a material then you have to create the material using item category group BANS.

The procument type should be marked as External procurement (F) in MRP 2 view of the material master record.

if you are not always allowing third party order processing then u can create a material master record with item category group as NORM and the procurement type should be marked as ( X) meaning both types of procurment ( in house manufacturing and external procurement).

step 2)
the item category in the order should be manually changed as TAS.
For that you need to confugure the item category determination

ord type + item cat grp + usge + Hiv level = Item cat + Manual item cat

OR + NORM +      +       = TAN . + TAS
OR + BANS +       +       = TAS

Step 3)
make sure that during the item category configuration for TAS  you need to mark relevnat for billing indicator as F

step 4)
The schedule line cateogry for this type should be CS.
make sure that you mark  subsequent type as NB – purchase requisition  in this schedule line category as this will trigger the purchase requision order immediately after the creation of the sales order and the PO to vendor is created against this purchase requiesion.

Backorder Processing

Backorder processing is a functionality in SAP where you can change the committments and over-ride the blockage of stocks
marked against sales documents/deliveries. For e.g. you receive an order from a very important customer for material “A” but
the entire quantity of A is committed to another customer “B” via earlier sales orders and this is where BACKORDER processing helps you to change the committment and shift stock due for B to A. This is the benefit of this funtionality.

OMIH – Checking rule for updating backorders
OPJL   – Define new checking rule
OPJJ   – Define scope of check

V_RA – Backorder Processing

Data selection:-
Sold-to-party             Customer code            Mandatory
Sales Organization                                         Mandatory
Distribution Channel                                       Mandatory
Division                                                         Mandatory

Changed confirmed quantity :-
Tick the material you want to changed and click the Backorder button
Confirmed quantity that still can be changed are highlighted.

V.15 – Backorder List
Sales Organization                                         Mandatory
Distribution Channel                                       Mandatory
Division                                                         Mandatory