Can someone help me with an example of Pricing in Product Hierarchy.

If you are an SD consultant (you are one, yes?), you should know your tables and fields. Because you can't do a lot of customizing without that.

But if you want an example here goes. Say, you want to base your pricing procedure on first three digits of product hierarchy, defined in the material master, via condition technique.

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:
FORM USEREXIT_PRICING_PREPARE_TKOMP.
MOVE VBAP-PRODH(3) TO TKOMP-ZZPRODH. ENDFORM.
The routines for assigning a value to the new fields in billing are found in member RV60AFZZ. The statement is as follows:
FORM USEREXIT_PRICING_PREPARE_TKOMK MOVE
XVBRP-PRODH(3) TO TKOMP-ZZPRODH. ENDFORM.

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.

I want to configer motercycle having differnt types of colour, each colour have varity of standered feature as wall as differnt CC. while want to create slaes order I want motercyle with speciefic colour, Cc feature. which is not possible while creating BOM it will only be configer by materiel Varient Configration.

-------------------------------------
Here are the Steps for Variant Configuration

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 colours 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.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.

John Devraj.

-------------------------------------
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.

Ugamesh.

-------------------------------------
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.

John Devraj.

-------------------------------------
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.

Ugamesh.

-------------------------------------
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.

John Devraj.

-------------------------------------
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.

Ugamesh.

-------------------------------------
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).

John Devraj.

-------------------------------------
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.

Ugamesh.

-------------------------------------
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.

John Devraj.

-------------------------------------
Now its coming any way thank you very much.

Ugamesh.

-------------------------------------
I have been reading your's and ugamesh's mails regarding the same but no where the sales doucments have been discussed as well as material master record and configuration in SPRO.

If you can kindly explain me the same as I was trying to do the same.

Reena

-------------------------------------
There is no need SPRO involvement in Variant Configuration.Everything happens in Easy Access.
As far as Material Master record is concerned you only need to use a KMAT Material type.

There is no need to assign any sales document to this material.

Follow the steps and you will get the result.

John Devraj.

-------------------------------------
I have gone thru the steps and created a sales order, but the pricing procedure is not coming proper. Also do we have to maintain the values for the ZCol_surcharge.
As I have already maintain the rates of the color in VK11 - VA00.

Reena

-------------------------------------
Have you maintained the Object Dependencies for the values in the characteristics class.

John Devraj.

-------------------------------------
Yes !

What I have done is created a customer with KMAT ( Car), without characteristics tab pg. After this I created 3 charateristics viz., zcolor, zengine & zcol_surcharge and assigned them to Class 300 ( Variant).
But I have maintained the dependencies only for Zcol_surcharge : $self.Zcol.surcharge='RED'
Then I assigned all these to a config profile and aslo added the condition VA00 in the pricing procedure, then maintained the same in VK11.
Now my problem is it is not coming in the SO

Reena

-------------------------------------
I think the problem is with the characteristics.
For the characteristics Zcolor and Zengine you must maintain some values in the Values Tab.
Ex:
Zcolor- Red
Blue
Zengine- V6(Right now you can use only one Characteristic for learning)
V8

The characteristic Zcol_surcharge(By name this suggests that it is applicable only to colour-Whereas you can use it for other characteristics as well) does not have any values.

For the values maintained in the Characteristics Zcolor and Zengine you have to go to each value(Go to values tab and select Red) and maintain the object dependency "Action" $self.Zcol_surcharge='RED'. Similarly maintain for Blue,V6,V8 for Example.

Then maintain the condition records for Va00(without any Case mismatch).

Use standard pricing procedure RVAA01.(or a copy- as it has provision for VA00).

This should solve your problem.

John Devraj.

What is the meaning of this column in the pricing procedure ,i.e

1. STEP
2 CTRSTEP
3. CTYP
4. DISCRIPTION
5. FROM
6. TO
7. MAN
8. Mand
9. STAT
10. PRINT
11. REQUIREMENT
12. ALCTYP
13. ALBCTYP
14. ACKEYS
15. ACCRUALS

A. STEP
This indicates the number of step-in the procedure.
B. COUNTER
This is used to show a second ministep
C. CONDITION TYPE
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.
D. DESCRIPTION
This forms the description of the condition type.
E. FROM
This is used to define the progression of the calculation and range of subtotals
F. TO
This is used to define the progression of the calculation and range of subtotals
G. MANUAL
This function enables to allow the condition type to be entered manually also apart from automatic pickup.
H. MANDATORY
This function identifies the conditions that are mandatory in the pricing procedure. The sales price is a mandatory condition type.
I. STATISTICS
This can be used to represent the cost price of the material sold, generally used for study statistical impacts of price
J. PRINT
The activation of this function will enable the printing of the values and conditions to the document.
K. SUBTOTAL
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
L. REQUIRMENT KEY
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.
M. ALTERNATE CALCULATION TYPE
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.
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.

Amol Wani

I have to add new field "Profit Center(Design ID)" to the field catalog first and then create new condition table for pricing using this field.

1. How to add new field to field catalog?
2. How to create condition table using that new field?

For adding field into Field catalogue:

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.

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.

Tips by : Ajay Kumar Veeranki

During the interview, the interviewer raised one question, whether the SALES ORDER & BILLING can have different pricing Procedure?

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.

Tips by : Kittu

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.

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.

Tips by : Kumar

How to configure pricing procedure to choose only one among the different condition type?

ECC 6 - Exclusion group Customizing is in the following IMG path (transaction SPRO):

Sales and Distribution > Basic Functions > Pricing > Condition Exclusion > Condition Exclusion for Groups of Conditions Carry out the following steps:

a) Define condition exclusion groups:
First create one or more exclusion groups, for example:

• G001 Discount group 1
• G002 Discount group 2

This data is stored in the T684 database table.

b) Assign condition types to the exclusion groups:

Then the required condition types are assigned to the exclusion groups, for example:

• G001 Discount Group 1 ZD01 Discount 1
• G001 Discount Group 1 ZD02 Discount 2
• G002 Discount Group 2 ZD03 Discount 3
• G002 Discount Group 2 ZD04 Discount 4

This data is stored in the T684G database table.

c) Maintain condition exclusion for pricing procedures:

Finally, define the required exclusion rules for each pricing procedure. In this case, you can create exclusions in accordance with the following predefined rules (KAUVF field):

- 'A' - Selection of the most favorable condition type within a condition exclusion group
- 'B' - Selection of the most favorable condition record of a condition type if several condition records exist (for example, selection under various condition records of the condition type PR00)
- 'C' - Selection of the most favorable of the two condition exclusion groups (in this case, all of the condition types of the two groups are cumulated and the totals are compared with each other).
- 'D' - "Exclusive" procedure: If any of the condition types of the first group exists on the item, all of the condition types of the second exclusion group are excluded.
- 'E' - Similar to 'B', but with the most unfavorable condition record.
- 'F' - Similar to 'C', but with the more unfavorable condition exclusion group.

The actual exclusion rules for a pricing procedure are maintained with a sequence number and completed by specifying the exclusion rule and the affected exclusion group(s):

- 10 D Exclusive G002 Discount Group 2 G001 Discount Group 1
- 20 A More favorable ... G002 Discount Group 2

This data is stored in the T684S database table.

All exclusion rules except for rule 'D' are based on the knowledge of the condition values of the condition types involved. In accordance with exclusion group Customizing, the condition exclusion is therefore also created in pricing in the FORM XKOMV_AUSSCHLUSS (include LV61AA56)

- after an 'initial' (preliminary) valuation (FORM XKOMV_BEWERTEN, Include LV61AA55) of the pricing result
- and after the condition exclusion based on the KMANU field

(FORM XKOMV_AUSSCHLUSS, Include LV61AA56)

The exclusion is created with inactivity indicator 'A'.

The information in section 3 also applies here: If conditions were excluded from FORM XKOMV_AUSSCHLUSS, a 'second' (final) valuation of the pricing result takes place once again (FORM XKOMV_BEWERTEN), in order to update the pricing result based on the exclusions made. In this case, conditions with inactivity indicator 'A' are no longer valuated.

Note:

a) Since the exclusion of a condition may influence the condition basis and therefore also the condition value of follow-up conditions, a condition or exclusion group that was more favorable (more unfavorable) than another condition or exclusion group after the preliminary valuation may have been more unfavorable (more favorable) after the final valuation. See also the following example.

In such a case, another exclusion or valuation based on the last valuation is NOT triggered. This procedure could result in a continuous loop (the "flip flop effect"). For more information, see Note 217009.

b) In the R/3 standard system, conditions with a zero condition value do not participate in exclusions according to exclusion groups. However, you can change the system response in such a way that conditions with a zero condition value also participate in exclusions.

To do this, add the value formula 038 (Include FV64A038), or a corresponding user-defined value formula that contains the source code from value formula 038, to the pricing procedure used for a condition that will definitely be part of the pricing result.

c) Conditions that the condition exclusion indicator (see section 2) already fully excluded from the pricing result of an item no longer participate in exclusions according to exclusion groups. As a result, you can no longer use rule 'D' to exclude the conditions of another group.

d) Exclusion group Customizing should not be maintained randomly, but rather with care. If exclusion group Customizing is so extensive that you can no longer comprehend the formation of the 'final result', it is time to reconsider the relevant business process.

Example:

The aforementioned exclusion group Customizing is valid. Before an exclusion is created, a document item contains the following preliminary pricing result, which of course is not displayed in this form. In this case, the percentage discount ZD02 refers to the price ZPR0 and the percentage discount ZD04 refers to subtotal 1.

Condtns Amt Condtns Val Inactive

• ZPR0 Price EUR 100.00 1 PC EUR 100.00
• ZD01 Discount 1 EUR 4.00 1 PC EUR - 4.00
• ZD02 Discount 2 5.000% EUR - 5.00

Subtotal 1 EUR 91.00

• ZD03 Discount 3 EUR 9.50 1 PC EUR - 9.50
• ZD04 Discount 4 10.000% EUR - 9.10

Subtotal 2 EUR 72.40

In accordance with exclusion rule 10, the discounts ZD01 and ZD02 are excluded from the G001 exclusion group since conditions were determined from the G002 exclusion group with the discounts ZD03 and ZD04.

In accordance with exclusion rule 20, discount ZD03 (condition value EUR -9.50) excludes discount ZD04 (condition value EUR -9.10) since ZD03 is the more favorable discount in the G002 exclusion group.

After you create the exclusion and the conditions have been valuated again, you finally receive the following final pricing result:

Condtns Amt Condtns Val Inactive

• ZPR0 Price EUR 100.00 1 PC EUR 100.00
• ZD01 Discount 1 EUR 4.00 1 PC EUR - 4.00 A
• ZD02 Discount 2 5.000% EUR - 5.00 A

Subtotal 1 EUR 100.00

• ZD03 Discount 3 EUR 9.50 1 PC EUR - 9.50
• ZD04 Discount 4 10.000% EUR - 9.10 A

Subtotal 2 EUR 90.50

Note that, if subsequently considered, discount 4 would now be more favorable than discount 3, since the exclusion of discounts 1 and 2 influenced the condition basis of the percentage discount 4, but it did not influence the absolute discount 3.

For the pricing to be automatically determines in the sales document, we have to make all the following customizing settings.

The pricing is based on “condition technique”. Condition technique comprises of

1. Condition Tables
2. Access Sequence
3. Condition Type
4. Pricing Procedure.

Condition Tables

Condition table contains the key fields for maintaining the condition records i.e. condition records of a condition type will be stored in condition tables. Depending on the sales requirement of the client we can have any field as a key field in the condition table.

One condition type can have multiple condition tables and if required one condition table can be used for multiple condition types.

Defining condition tables

Tcode: SPRO
- Sales and distribution
- Basic functions
- Pricing
- Pricing control
- Define condition tables
- Create condition tables

Specify a condition table number which must be between 501 and 999

From the field catalogue which contains all the available fields select the required key fields.

While maintaining condition records in order to set the validity period we have to get the fields “valid on” and “valid to”. For this here we need to check the field “with validity period”

Select the button “Technical view”. Here fields which are marked as key appears at key level and the fields marked as footer field appears at footer level while maintaining the condition record.

Select the icon “Generate”.

Select the button “Local object” for saving the Table.

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

The condition records has a higher priority than the Customer Master.

4.6x

• Transaction VK32
• Search for the All fields List Box and Choose Terms of payment
• The PayT field columns will appear next to the Material

3.0x

• Transaction V-51
• Positon your cursor on the Material and click Additi.SD data
• Search for the field Payment terms

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

Sales Tax Determination

OBQ1 - Maintain/Create Condition Type

• Double click on the Condition Type for more control

OBQ3 - Tax Pricing Procedures

OBQ2 - Tax Access Sequences

OBBG - Assign Tax Country to calculation procedure

OVK3 - Define the Customer Tax category

OVK4 - Define the Material Tax category

OVK1 - Define Tax determaintion rules

• Define the links between the Tax Country and Tax conditions type

OVK6 - Assign delivery plants for Tax determination (locally which Tax country category to use)

VK13 - Maintain Tax Condition Rate (e.g. 1%, 2% etc...) by Tax Country

SM31 - Table View V_T001 - Maintain default country, currency for Company Code.

Material and Customer Tax Master Maintenance must be equal
e.g. 0 = tax 1 = no tax both Material and Customer master must be 1 and 1

Search for the Tax Classification field
MM02 - Sales Organization data
XD02 - Tick Billing

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

Collective Billing

Configuration steps:-

• transaction VD02 - Change Customers - tick Billing and filled in the Customer Code, Sales org., Distr.channel and Division then hit enter.
• Look for field name Inv.list sched. - you must filled in the Factory Calendar that you are currently using.
• You can simulate the collective billing in transaction VF04 - Process Billing Due List.

During simulation, if the billings cannot be combine, the system will give you this message,

Different header fields $000000001 $000000002
Combination criteria in the billing xxxxxxxxxxxx123 xxxxxxxxxxxx125

Criteria to satisfy for collective billings:-

• Billing document type is the same.
• Reference document type is the same.
• Item category in the reference document is the same.

The system combines into one billing document all transactions for the same customer and same billing data. If the header data and the header partners for the specified deliveries or sales orders are identical and if the requirements for splitting do not apply, one billing document is created for all the deliveries or sales orders.

The following illustrates an example. The system determines that deliveries 1 and 2 had the same bill-to party, and therefore combines the deliveries in one billing document.

Delivery Order 1 - |
-----------> Invoice
Delivery Order 2 - |

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

4.6x

VTFL - Check copy control rules
Target Source
e.g. Select F2 - Invoice LF Delivery
Click Item
e.g. Double click on Tan - Standard Item
Check Data VBRK/VBRP - Copy rule number in use e.g. 900

VOFM - Creating a splitting rule
Click Data Transafer -> Billing documents

Copy the standard 1 - Inv.split (sample) to a e.g. 900 series number range

A new splitting rule 900 will be created, follows by a program FV60C900.

In program FV60C900, SAP has a standard internal table called ZUK where you can define fields that must be compared and be equal before a billing may be combined. However, total characters allowed is 40 will be store on the billing header table VBRK.

e.g. Program FV60C900
DATA: BEGIN OF ZUK,
MODUL(3) VALUE '900',
BUPLA LIKE VBRK-BUPLA, "Business place
LIFNR LIKE LFA1-LIFNR, "Consignor (Vendor Consignment)
MWSKZ LIKE VBRP-MWSKZ, "Tax code
END OF ZUK.

ZUK-BUPLA = VBRK-BUPLA.
ZUK-LIFNR = LFA1-LIFNR.
ZUK-MWSKZ = VBRP-MWSKZ.

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

Tested in 4.6x

This will not have any affect on the sold-to-party price.

If you want a payer based discount on invoice list only. This is what you will need to do:

1. Check out the pricing procedure RVAA01 and condition type RL00. This pricing procedure is for Germany and the
discount is factoring discount. But it is payer based discount.

IMG - Sales and Distribution -> Billing -> Billing documents -> Maintain conditions for invoice lists ->
Maintan pricing procedures

2. RL00 uses access sequence RL00 and condition table 7 which is sales organization/distribution channel/divison/customer
(payer). If that fits your needs, use it. Otherwise, do the usual create condition table, access sequence and condition type
configuration.

3. In the appropriate place in your pricing procedure, add in condition type RL00(or one you created). Be careful to copy the
requirement routine and condition base value assignments from pricing procedure RVAA01.

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

Subsequent Debits/Credits are used in cases where the quantity is in the original invoice is to remain the same. For eg.

PO 10 - $10
Gr 10 - $10
LIV 10 - $11 (Logistics Invoice Verification)

The vendor invoice is more than that in the Purchase Order. In order to correct, the Vendor may send in another invoice for
the Increased amount or a credit memo for the increased amount.

If you approve of the price increase, post the subsequent invoice received as a Subsequent Debit/Credit Invoice.

If it is a credit memo that has been received, then post the credit memo as Subsequent Debit/Credit.

This would retain the quantity but reduce the amount.

Subsequent Debit/Credit is for the case when the credit is not for the full amount eg. if the Vendor decided to credit
only the $1 overcharged.

Credit memo is for the credit of the full amount and value.

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

1. What's the difference between document type and billing document type?

2. What's the use of the field 'document type' during definiation of billing type? What's the effect if leave it blank / assign it with a document type?

3. Where can I define how the system number the billing documents, in both case using internal and external number range intervals?

1. In SAP all sales transactions are representred by documents. Document type is a generic term applicable to delivery / sales / inquiry / billing etc. e.g. if someone says "check in shipping / delivery if document type is correct or not" it means you need to check the document types relevent for shipping/delivery processing. Document type controls and links the process flow. In billing process the documents used have distinct document types .

2. The billing document type defines how the document would behave in the process chain. If you try saving the document you will come to know why it is necessary. You cannot create a document type without giving it a name. If you give it a name then you can use it afterwards.

3. In the billing document type definition (VOFA) itself you assign the number ranges to be used for the document type. Whereas it is defined through VN01. In internal numbers system maintains the counter and generates document number internally when document is save. Current counter you can see in VN01 itself. Whereas in external number ranges you can give the document number at the time of creation itself provided it falls in the assigned number range and is not yet used.

San

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

How to configure Inter Company Billing

by: Mamta Singh

INTERCOMPANY BILLING

Business case: - Customer orders goods to company code/Sales organization A (Eg.4211/4211). Sales org 4211 will accept and punch the order in the system with sold to party as end customer code in the system. Company code/sales org B (Eg.4436) will deliver the goods to end customer and raise an inter-company billing on 4211 with reference to delivery. This can happen only after 4211 raises invoice to his end customer to whom the material has been delivered by 4436.

SPRO Customization required:-
1. Assign plant of delivering company code (Eg.SI81) to sales org/distribution channel combination of ordering company code (Eg.4211/RT)
2. Maintain intercom any billing type as IV for sales document type OR
3. Assign Organizational Units By Plant (Eg.SI81/4211/RT/11)
4.Define Internal Customer Number By Sales Organization (Eg.4436 will create customer master for 4211 company code and that number will be maintained in this relationship:-4211/231)
5. Automatic posting to vendor account (Optional)
6. Maintain pricing procedure determination for 4211/RT/A/1/RVAA01-For customer sales and billing
Maintain pricing procedure determination for 4436/RT/A/1/ICAA01-For inter-company billing

Master data to be maintained:-

1. Create end customer master in company code/sales org 4211/RT/11
2. Create customer master for 4211 company code/sales org in 4436/RT/11
3. Maintain PR00 as price for end customer-Active in RVAA01
4. Maintain PI01 as price which has to be paid to 4436-Statistical in RVAA01
5. Maintain IV01 as inter-company Price-Active in ICAA01

Process:-
1. Create OR with sold to party as end customer.
2. Plant to be selected is delivering plant belonging to different company code. With this selection system will treat this order as inter-company sales.
3. Pricing procedure is RVAA01
4. With reference to this order delivery will be created from the delivering plant and post the goods issue for this delivery.
5. Ordering sales org will create billing document F2 with reference to delivery for end customer.
6. Delivering sales org will create inter-company billing IV with reference to delivery document.

A company arranges direct delivery of the goods to the customer from the stocks of another company belonging to the same corporate group. To put in simple terms, Company code A orders goods through its sales organization A from Plant B belonging to Company code B. It is imperative that both Plants A & B should have the material. In other words, the material is created for both the Plants A & B + their respective storage locations.

Sales Organizations and Plants are uniquely assigned to Company codes. It is not possible to assign either a plant or a sales organization to more than one company code.

Sales organizations and plants assigned to each other need not belong to the same company code.

In other terms, a plant belonging to Company code A & assigned to Sales Organization A can also be assigned to Sales Organization B of Company Code B. This enables cross company sales.

PARTIES INVOLVED
1) End Customer 2) Ordering Company code 3) Supplying Company Code.

End customer:
Customer who orders goods from the ordering company code.

Ordering Company Code:
Which orders goods from Plant belonging to Supplying Company code through its sales organization and bills the end customer.

Supplying Company Code: Supplies goods from its plant to the end customer specified by the ordering company code and bill the ordering company code.

CONFIGURATION SETTINGS
Assign Delivery Plant of the supplying company code to Sales Org + Distribution channel of the Ordering company code in the Enterprise Structure.

DEFINE ORDER TYPES FOR INTERCOMPNY BILLING:
Menu path: IMG/ SD/Billing/Intercompany Billing/Define Order Types for Intercompany billing

Assign Organizational units by Plant:
Menu Path: IMG/ SD/Billing/Intercompany Billing/Assign Organizational units by Plant.

Define Internal Customer Number By Sales Organization:
Menu Path: IMG/ SD / Billing/ Intercompany Billing/ Define Internal Customer Number By Sales Organization:

Creating / Showing Ordering Sales Organization as Internal Customer for Supplying Company code:

Transaction Code: XD01

The ordering sales organization is represented as Internal customer of Supplying company code.

We need to create customer master in Account Group – Sold to Party and maintain minimum required financial & Sales Area data.

This internal customer number has to be assigned to the ordering sales organization. Hence, the system automatically picks up this Internal customer number whenever there is Intercompany billing.

PRICING:

We need to maintain two pricing procedures RVAA01 & ICAA01. Pricing procedure RVAA01 represents condition type PR00 & any other discounts or surcharges that are meant for end customer.
We assign Pricing procedure RVAA01 to combination of Sales area (Of Ordering company code) + Customer Pricing Procedure + Document Pricing Procedure of Sales document type.

This pricing Procedure (RVAA01) is determined both at Sales Order level & Billing processing for the end customer.

We maintain PR00 condition type to represent the ordering company code’s price to the end customer.
Condition records for PR00 are maintained using organizational elements of Ordering company code, end customer & the Material.
Eg: Sales Org. of Ordering company code + End customer + Material.
We also need to maintain PI01 condition type to represent costs to Ordering company code (in other words revenue to supplying company code). It is statistical condition type & meant for information purpose only.

Condition records for PI01 are created with the following key combination:
Ordering sales Org + Supplying Plant + Material

Pricing Procedure ICAA01is determined at Intercompany billing processing level.
Pricing Procedure ICAA01 – Pricing Procedure for Inter company billing is assigned to the combination of:
1) Sales Area (of supplying company code) + Document pricing Procedure of Billing document type IV + Customer Pricing Procedure of the Internal customer.
Pricing Procedure ICAA01 has condition type IV01 that represents revenues for Supplying company code in the intercompany billing.
PR00 condition type also appears in Intercompany billing document. It is for information purposes only and does not have bearing on the value of the document.
PI01 represented under pricing procedure RVAA01 is reference condition type for IV01 and the same is defined in the condition type IV01. Due to this these two condition types represent same value.
The condition type IV01 in intercompany billing document represents revenue to the Supplying Company. But its corresponding condition type PI01 in the billing document to the end customer is shown as a statistical item meant for information purposes.
Condition Type VPRS in the intercompany-billing document indicates cost to the supplying company code.
The use of two different condition types in Intercompany billing is necessary to ensure that data is transmitted correctly to the financial statement (Component CO-PA).

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

By: Mike

Is there a way to run VFK3 in background? When I execute the transaction the "execute in background" option is greyed-out.

If you would like to run it in background,you have to use the program RVFAKSPE instead of SDBLBDDL.

There had been a change of the program used in transaction VFX3 for release 4.5B and afterwards. You can see this in the System -> Status screen. The program used in releases up to 4.5B is RVFAKSPE, in releases after 4.6A it is SDBLBDDL. Report SDBLBDDL can't be used for processing in the background, it is not designed to run as a batch job.

You can still process the release to accounting in background processing by creating background jobs for program RVFAKSPE, which is still available.

Is there any T.code for finding the billing document was not released to accounting?

Please use Tcode VFX3

You can find the same against the following:

Sales organization*
Mandatory
Created by
Created on
SD document
Billing type
Billing category

While entering the billing document in vf01, you got the following information, how to make it?
The accounting document has not yet been created
Message no. VF062

Go to release for accounting. However if it does not create automatically there will be a problem posting to Finance.

I would then suggest that you use t code VFX3 to release the billing document to Finance. There is a log in both VF02 and VFX3 that will show what the error is.

First thing to do is re-checking the config for revenue account determination.

This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc). This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.

The integration is controlled both in SD and in FI.

In SD there is a awesome area of configuration called the pricing procedures. The pricing procedure determines the final price quoted to the customer for a particular product. This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. This condition technique is used in a number of areas of SAP.

For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys). You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:

- ERF freight revenues
- ERL revenues
- ERS sales deductions
- EVV cash settlement
- MWS sales tax

Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!

So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )

We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".

The chart of accounts part is standard in all account determinations, so let us look at the rest. This access sequence allows us to specify different GL accounts for different Sales Organisations.

Also check the customer master record for account assignment group.

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

What is the difference between credit memo request and credit note and can we see the credit note in the system?

Credit memo request will be created when you have to pay to the customer. (excess bill or damages or change in the price).

Credit memo request is a Sales document type (VA01), based on this you will create credit memo (VF01).

While creating the credit memo you will get a block which will be removed by an authorised person set.

The credit memo can be seen with transaction VF03 and credit memo request with VA03.

Credit memo request is a sales document used in complaints processing to request a credit memo for a customer. If the price calculated for the customer is too high, for example, because the wrong scale prices were used or a discount was forgotten, you can create a credit memo request. The credit memo request is blocked for further processing so that it can be checked. If the request is approved, you can remove the block. The system uses the credit memo request to create a credit memo.

You can use credit memos in Sales and Distribution (SD) for assigning credit memo requests to the open invoices and in Financial Accounting (FI) for assigning credit memos and payments to the open invoices and carry out clearing with them. If you use both Financial Accounting (FI) and Sales and Distribution (SD), there is a 1:1 relationship between the credit memo request and the credit memo item posted in Financial Accounting (FI). As soon as you bill the credit memo request together with other sales orders, or distribute the items of one credit memo request to several billing documents, the assignment is no longer valid and the system will not process it.

For credit memos, credit memo requests, and payments, you have the following assignment options:

• Assignment to a single invoice
• Assignment of a partial amount to an invoice
• Assignment to several invoices

When you post credit memos, the payment programmed processes them automatically. If the credit memo is specifically related to a particular open invoice item, the payment program automatically attempts to offset the credit memo against the open item. If it is not possible to completely offset the credit memo against an invoice, you can post a debit memo to the vendor, who is to reimburse the amount. Then you can apply a multilevel dunning program.

Credit Memo Based On Return Delivery

I have sales return scenario where I want to make credit memo based on return delivery.
What are the steps and settings for copy control for creating credit memo in VF01 with return delivery Vl01n

Credit memo in Return always refers to the Return order NOT to the Return delivery.

So create the Credit memo with reference to the Return order, there will be no error, but before that ensure that you have released the block from the Return order.

First copy billing type from G2 (T-code VOFA) and that copied billing

Type maintain in sales document type (T-code VOV8) in for delivery related billing.

Billing
SAP Billing represents the final processing stage for a business transaction in Sales and Distribution. Information on billing is available at every stage of order processing and delivery processing.

Debit Memo Request:-

Step 1: Sales Document Type

IMG > Sales and Distribution > Sales > Sales Documents >

Sales Document Header:

1. Sales Document Type:DR is the sales document type for Debit Memo Request. To create new sales order type, always copy as with reference to similar sales order. If possible use standard sales order.

2. Define Number Ranges For Sales Documents: Maintain number range with discussion with core team.

3. Assign Sales Area To Sales Document Types:
A. Combine sales organizations / Combine distribution channels / Combine divisions: Ensure to maintain these, else Sales Order creation will give error.
B. Assign sales order types permitted for sales areas: Assign only required Sales Order Types to required Sales Area. This will minimize selection of Sales Order Type as per sales area.

Sales Document Item:

1. Define Item Categories: If possible use Standard Item Category. Incase if required to create new, copy as from standard & maintain New.

2. Assign Item Categories: If possible, use standard. Formula for deriving item category: Sales Document Type + Item Category Group + Usage + Higher Level Item Category = Item Category

Step 2:

IMG > Sales and Distribution > Billing >

1. Define Billing Types: L2 is standard Billing Type for Debit Memo. If possible use Standard Billing Type. In case if required to create new, copy as from standard & maintain New.

2. Define Number Range For Billing Documents: Ensure to maintain number range.

3. Maintain Copying Control For Billing Documents: Maintain relevant copy controls such as Sales Order to Billing.

Note: Ensure that Copy Control settings are done

Sales Order to Billing (OR --> F1): VTFA

In what situation do we use a debit memo request and a debit memo?

Debit memo is used in below scenarios:

1) When you have charged the customer less then actual due to reason like selection of wrong scales or you have not checked the actual Market price.

2) When there is an over delivery and customer agrees to pay for it.

Debit memo request is an order type which is referred to create a debit memo there can be release procedure in-between depending on the business process.

Also note that our FI counter parts can create standalone DEBIT MEMOS.

There are a lot of scenarios we create debit memo request and debit memo against a customer. I am giving a couple of scenarios:

In repair processing the material has come back to our premises, we repaired the same and send it back to the customer. The charge for repair and the parts consumed has to be billed to the customer. We normally use resource related billing in such cases, through RRB we generate a debit memo request and followed by a debit memo.

We have sold one equipment (material) to a customer, it is having some issue, the customer wants an immediate replacement. We send the replacement immediately, expecting the customer to return back the faulty one. But the customer is not returning back the equipment. After many follow-up, we create a debit memo request and debit him with a debit memo.

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.

Procedures to switched off ATP at delivery

The simpliest way is to use tranaction OVZK and mark availability check off column for all the delivery item categories you are
using.

or

Another way is to use transaction OVZ9. For all the MRP checking group you are using, and checking rule B, de-select
in the Receipts/Issues section, sales, deliveries, and reservations.

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.

Post goods issue must be done on current period - VA02

• Go to VA02
• click Edit -> Actual GI date
• Change the date to current period. (Check transaction MMRV for the period)

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.

Additional fields in worklist for VL06O - List Outbound Delivery

4.6x

There are no more configuration to include a new field. Any additional field in table LIPOVZ will be reflected in the worklist.

To add a field in the worklist, you must insert the field in customer specific table :-

LIPOVZ - Customer modification division for Table LIPOV

SE12 - Database Table - LIPOVZ
Click Display -> Change

You can delete away the Component DUMMY.
e.g. to insert the Batch Number in the worklist
Component Component Type
CHARG CHARG_D

After this, you have to execute program BALVBUFDEL (note 122975) to reset the ALV buffer.

Table you can use for VL06O
LIKP - SD Document: Delivery Header Data
LIPS - SD document: Delivery: Item data
VBUP - Sales Document: Item Status

Once completed, you should be able to see the new fields in Settings -> Layout -> Change

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.


Question : Subject : Adding additional fields to Delivery Due List

I would like to add additional fields to the Delivery Due List - Transaction VL04. These fields do not exist in the list of additional fields in the IMG so I assume I will need to have a user exit written or something... Has anyone had any experience in adding fields to the delivery due list that do not exist in the IMG? Your help is greatly appreciated.

Answer : Subject : Adding additional fields to Delivery Due List

USE T-CODE VOL1.CREATE A DISPLAY VARIANT AND ADD FIELDS & SEQUENCE NUMBER.

Answer : Subject : Adding additional fields to Delivery Due List

Check OSS, at least note 198137.

Answer : Subject : Adding additional fields to Delivery Due List

Thank you... but as I stated in my question, The fields I need do not exist in the list of addtional fields in the IMG. I need to add fields from KNA1 and display them in the existing Delivery Due List.

Answer : Subject : Adding additional fields to Delivery Due List

additional fields need to be added to structure VBVFI. SAP provides an include in the structure to do so or you can create an append, depending on how your basis folks see life

Answer : Subject : Adding additional fields to Delivery Due List

Thank you. I forgot to mention, we are release 3.1I. Do you think this 4.X note would be applicable?

Kind Regards,

Answer : Subject : Adding additional fields to Delivery Due List

I found note 415716. Thank you for your help.

Kind Regards,

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.


SAP Spools Configuration for Sales/Distribution

SAP Printers outputs

• Create/Change the shipping loading point (VV22) and (OVX7)
• Create/Change the billing output (VV32)

Sales Document Output Control

• transaction /NVV12
• Input the Output type e.g. BA00 - Order Confirmation then hit enter
• Input the Sales document type e.g. OR - Standard Order and click Execute
• Under the Output Conditions Section, you must know which Sales grp. you used. Look at the Tim Column. Option 4 indicates an immediate printout once the user save its data.
• To check which SAP printer the sales document print to, tick the desired Sales grp. and click Communication button.

Shipping
SAP Shipping is an important part of the logistics chain in which guaranteed customer service and distribution planning support play major roles.


Delivery Output Type Default

You can specify a default printer for your delivery note. If you maintain the loading point for printers, it will overwrites the default output type when the user enter the loading point.

Maintain the output type by loading point

• VV21 / VV22 - Create or Change the output type by loading point

Maintian the output type default by shippint point
4.6x

• VP01SHP - Shipping -> Delivery Note

3.0x

VP01 - Shipping -> Delivery Note