Difference between Actual header conditions and Item totals

1. What is meant by 'actual' header conditions?

'Actual' header conditions are conditions that are are manually entered on the header condition screen.

It is never possible to determine 'actual' header conditions using automatic condition determination (condition acce

2. Which Customizing settings are required to enter an 'actual' header condition?

In Customizing of the condition type (for example, transactions V/06, M/06) make the following settings in the 'Cha

a) Select the header condition checkbox (field KKOPF).

b) In addition, select at least one of the two checkboxes 'Amount/Percent' (field KAEND_BTR) or 'Value' (field KAEN

c) For 'Manual entries' (field KMANU), do not select the setting 'B' (Automatic entry has priority) or 'D' (Not possible

d) 'Actual' header conditions are not allowed to have access sequences (field KOZGF).

3. How is an 'actual' header condition distributed to the pricing result of the individual document items?

This depends on further Customizing settings of the condition type, in particular on the calculation type (field KRECH

Example:

For a header condition with calculation type 'Fixed Amount', the amount entered on the header condition screen is

However, if the condition is set as a group condition, the amount entered on the header is distributed proportional

4. Which specification has the condition origin and the condition control for 'actual' header conditions?
a) For an 'actual' header condition, you create a row in the table of conditions (database table KONV or internal tab

Condition origin (field KHERK) 'C' (Manually entered)

The condition control (field KSTEU) has the specification

'C' (Changed manually), if only a condition rate (not equal to zero) is entered,

'E' (Condition value and basis fixed), if a condition value is entered,

'A' (Adjust for quantity variance), if neither condition rate nor condition value are entered.

b) The 'actual' header condition has the following specification on the items (KONV rows KPOSN not equal to '00000

Condition control (field KSTEU) 'C' (Changed manually)

Condition origin (field KHERK) 'D' (Header condition)

5. How do 'actual' header conditions behave in copy procedures?

In R/3 standard pricing, conditions are copied only at item level. No 'actual' header conditions are copied. The KONV

Condition control 'E' (Condition value and basis fixed)

Condition origin 'G' (Original header condition)

These conditions then become item conditions in the target document.

6. How do 'actual' header conditions behave in (milestone) billed documents?

If you display the (milestone) billed document in display mode, the system displays the 'actual' header condition in
CnTy Name: HB00 Absolute disc.

Amount Curr per UoM: 20.00 EUR

Condition val currency: 20.00 EUR

However, if you call the (milestone) billed document in change mode, the system must split the header condition in

The following section explains this system response using the example of an 'actual' header condition with the calcu

7. Examples for question 6

An order has 5 items. On the header, the HB00 discount is entered with an amount of EUR 20.00- and is distributed

Item Cond.basisFor HB00 Cond.val for HB00

10 15,76 15,76 / 56,57 * 20,00 = 5,5718... ==> 5,57-

20 12,51 12,51 / 56,57 * 20,00 = 4,4228... ==> 4,42-

30 8,26 8,26 / 56,57 * 20,00 = 2,9202... ==> 2,92-

40 17,21 17,21 / 56,57 * 20,00 = 6,0844... ==> 6,09-

50 2,83 2,83 / 56,57 * 20,00 = 1,0005... ==> 1,00-

Total 56.57 (EUR) (EUR) 20.00

The condition bases in the left column result in the condition values displayed in the right column. In this case, item

There is a milestone billing for this order and the items 10, 20 and 30 are billed. The order is now called in change m
To display the condition on the header condition screen, the system proceeds as follows:

The fixed item portions of the billed items are added (5.57- + 4.42- + 2.92- = EUR 12.91-) and displayed in one row w

CnTy Name Amount Curr per UoM Condition val currency

HB00 Absolute discount 12.91- EUR

HB00 Absolute disc. 7,09 EUR 7,09 EUR

a) What happens if the condition basis for HB00 changes on one of the open items?

In this case, the outstanding condition rate of EUR 7.09- is distributed in relation to the (new) condition bases of the

Example: The order quantity of item 50 (or the PR00 price) is tripled, which also triples the condition basis for HB00

Item Cond.basis Cond.val

For HB00 for HB00

*10 15,76 15,76 / 56,57 * 20,00 = 5,5718... ==> 5,57-*

*20 12,51 12,51 / 56,57 * 20,00 = 4,4228... ==> 4,42-*

*30 8,26 8,26 / 56,57 * 20,00 = 2,9202... ==> 2,92-*

40 17,21 17,21 / 25,70 * 7,09 = 4,7478... ==> 4,75-

50 8,49 8,49 / 25,70 * 7,09 = 2,3421... ==> 2,34-

Total 25.70 (EUR) (EUR) 7.09

Overall total (EUR) 20.00-

b) What happens if a further item is created?

In this case, the newly created item is included in the distribution of the outstanding condition rate of EUR 7.09-.

Example: Item 60 is created with a condition rate of EUR 13.97 for HB00. This has the following result:

Item Cond.basis Cond.val

For HB00 for HB00

*10 15,76 15,76 / 56,57 * 20,00 = 5,5718... ==> 5,57-*

*20 12,51 12,51 / 56,57 * 20,00 = 4,4228... ==> 4,42-*

*30 8,26 8,26 / 56,57 * 20,00 = 2,9202... ==> 2,92-*

40 17,21 17,21 / 34,01 * 7,09 = 3,5877... ==> 3,59-

50 2,83 2,83 / 34,01 * 7,09 = 0,5899... ==> 0,59-

60 13,97 13,97 / 34,01 * 7,09 = 2,9122... ==> 2,91-

Total 34.01 (EUR) (EUR) 7.09

Overall total (EUR) 20.00-

c) What happens if the outstanding condition rate of EUR 7.09- is changed for HB00?

In this case, the changed condition rate is distributed to the outstanding items in relation to the condition bases of
Example: The condition rate for HB00 is reduced from EUR 7.09- to EUR 5.00-. This has the following result:

Item Cond.basis Cond.val

For HB00 for HB00

*10 15,76 15,76 / 56,57 * 20,00 = 5,5718... ==> 5,57-*

*20 12,51 12,51 / 56,57 * 20,00 = 4,4228... ==> 4,42-*

*30 8,26 8,26 / 56,57 * 20,00 = 2,9202... ==> 2,92-*

40 17,21 17,21 / 20,04 * 5,00 = 4,2939... ==> 4,29-

50 2,83 2,83 / 20,04 * 5,00 = 0,7060... ==> 0,71-

Total 20.04 (EUR) (EUR) 5.00

Overall total (EUR) 17.91-

d) What happens if the three examples a, b and c are combined?

In this case, EUR 5. 00- for HB00 is distributed to items 40, 50 and 60 in relation to their condition bases with the am

Item Cond.basis Cond.val

For HB00 for HB00

*10 15,76 15,76/56,57*20,00 = 5,5718... ==> 5,57-*

*20 12,51 12,51/56,57*20,00 = 4,4228... ==> 4,42-*

*30 8,26 8,26/56,57*20,00 = 2,9202... ==> 2,92-*

40 17,21 17,21/39,67* 5,00 = 2,1691... ==> 2,17-

50 8,49 8,49/39,67* 5,00 = 1,0700.. ==> 1,07-

60 13,97 13,97/39,67* 5,00 = 1,7607.. ==> 1,76-

Total 39.67 (EUR) (EUR) 5.00

Overall total (EUR) 17.91-

Keep in mind: Due to the 'subsequent' intervention in the already 'partly fixed' distribution, the distribution of the o

8. What is the significance of the KAWRT and KWERT fields in the KONV database table for an 'actual' header conditi

There is no significance. In the KONV database table, only the condition rate (field KBETR) is relevant for an 'actual'

The condition basis (field KAWRT) and the condition value (field KWERT) of an 'actual' header condition are (re)calc

The system calculates them by adding up the condition bases and condition values of the relevant items.

Therefore, the contents of the KAWRT and KWERT fields in the KONV table are not important for an 'actual' header

In standard R/3 pricing, these values are not the basis for any function.

Therefore, in user-defined programs (for example, in print), you must not access the contents of KAWRT and KWER

The values saved in the database table (generally) correspond to the values that were determined the last time the

If you now enter an 'actual' header condition and, for example, save the document immediately afterwards (that is
9. What is meant by 'item totals'?

'Item totals' are condition rows on the header condition screen that represent a summation of item conditions. The

Automatically determined conditions:

Condition control 'A' (Adjust for quantity variance)

Condition origin 'A' (Automatic pricing)

Automatically determined and manually changed conditions:

Condition control 'C' (Changed manually)

Condition origin 'A' (Automatic pricing)

Manually entered conditions:

Condition control 'C' (Changed manually)

Condition origin 'C' (Manually entered)

Original 'actual' header conditions on already (milestone) billed items (compare with items 10 - 30 in the example f

Condition control 'E' (Condition value and basis fixed)

Condition origin 'G' (Original header condition)

Original 'actual' header conditions copied from a source document using a copy procedure (compare with section 5

Condition control 'E' (Condition value and basis fixed)

Condition origin 'G' (Original header condition)

'Items totals' have the specification 'E' (Items total) for the condition origin on the header condition screen. The con

10. How are 'item totals' displayed?

The summation of the item conditions for the display on the header condition screen occurs in the XKOMV_AUFBA

In detail, the system proceeds as follows:

The internal table TKOMV, which contains all conditions of the document, is sorted according to the following key:

KNUMV STUNR ZAEKO KSCHL KSTAT KRUEK KHERK

KRECH KWAEH KGRPE IX_GKOMV KINAK KBETR KNUMH

After that, the table entries are run in the sequence that was just created.

The row that was just edited is added to the row currently in the structure for the header condition screen (= 'Items

However, if at least one of the split criteria is fulfilled, the system starts with the structure of a further row for the h

The following split criteria are taken into account by the system:

Different condition type in both rows (field KSCHL).

Different step number in both rows (field STUNR).

The condition of one row is statistical, the condition of the other row is not (field KSTAT).

The condition of one row is relevant for accrual, the condition of the other row is not (field KRUEK).
The condition rows do not originate from the same 'actual' header condition (field ZAEKO).

There is a different alternative currency in both rows (field KWAEH).

There is a different inactivity indicator in both rows (field KINAK).

For variant conditions: There is a different condition record number in both rows (field KNUMH).

For automatically determined group conditions: Different condition rate (field KBETR), different calculation type (fie

Also the following:

a) Item conditions excluded with an inactivity indicator (field KINAK) not equal to 'Y' or 'A' (see 836243) are not incl

b) Statistical conditions (for example, the condition type VPRS) appear on the header condition screen, provided th

c) The 'item totals' are only 'virtual' condition rows. They are only created (dynamically) at runtime during the displa

d) Cumulated conditions (field KDUPL = 'B') are not displayed on the header condition screen (see 844141).

11. How do 'actual' header conditions or 'item totals' behave during the deletion?

See 647240 answers this question.

r condition screen.

determination (condition access). In R/3 standard pricing, the automatic condition access occurs only at item level of the document. (See

e following settings in the 'Change Options' section:

ND_BTR) or 'Value' (field KAEND_WRT).

as priority) or 'D' (Not possible to process manually).

al document items?

he calculation type (field KRECH) and on whether the group condition (field KGRPE) is set or not.

the header condition screen is duplicated in each item if the condition is not set as a group condition.

der is distributed proportionally (that is, in the relationship of the relevant condition bases at item level) and a rounding difference adjustm

eader conditions?
ase table KONV or internal tables XKOMV and TKOMV) with item number '000000' (field KPOSN) with the following specification:

ows KPOSN not equal to '000000') onto which it was distributed or duplicated:

onditions are copied. The KONV row from the source document with item number (field KPOSN) '000000' no longer exists in the target doc

he 'actual' header condition in a single row, for example:

st split the header condition in two rows: One row for the already billed items and one row for the outstanding items.

header condition with the calculation type 'Fixed amount' (for example, the condition type HB00 in the R/3 standard system).

f EUR 20.00- and is distributed proportionally to the open items, for example, as follows:

ight column. In this case, item 40 (the item with the largest condition basis) receives the resulting rounding difference of EUR 0.01-.

rder is now called in change mode. Items 10, 20 and 30 and therefore their pricing result are fixed, whereas items 40 and 50 (for example
91-) and displayed in one row with condition control 'E' (Condition value and basis fixed) and condition origin 'E' (Items total). In addition, t

he (new) condition bases of the outstanding items (in the example, items 40 and 50).

s the condition basis for HB00 to EUR 8.49. This has the following result:
condition rate of EUR 7.09-.

following result:

tion to the condition bases of HB00.

as the following result:

eir condition bases with the amounts EUR 17.21, EUR 8.49 and EUR 13.97.
 ution, the distribution of the overall condition value for HB00 - seen for all document items - no longer corresponds to the relationship of

le for an 'actual' header condition?

ETR) is relevant for an 'actual' header condition.

header condition are (re)calculated during R/3 pricing, if they are required (for example, when displaying the header pricing screen).

the relevant items.

mportant for an 'actual' header condition. Standard R/3 pricing does not access these values.

contents of KAWRT and KWERT, but in the same way as R/3 standard pricing, the system should determine these values dynamically at run

e determined the last time the header condition screen was displayed (FORM XKOMV_AUFBAUEN_KOPFSUMMEN in the PRICING_SUBSCR

mmediately afterwards (that is, without activating the header condition), the system no longer displays the header condition screen. In this
mation of item conditions. These item conditions are conditions that (unlike 'actual' header conditions) have their origin on the items of th

items 10 - 30 in the example for question 6):

edure (compare with section 5):

ader condition screen. The condition control has the specification of the first item condition that was incorporated in this 'items total' ('Fir

occurs in the XKOMV_AUFBAUEN_KOPFSUMMEN FORM (include LV61AA60). In this case, item conditions are summarized as much as po

ccording to the following key:

ader condition screen (= 'Items total'), provided that none of the following split criteria is fulfilled.

cture of a further row for the header condition screen (= a further 'Items total').

(field KRUEK).
d KNUMH).

, different calculation type (field KRECH) or processing in different groups (field IX_GKOMV) in both rows.

or 'A' (see 836243) are not included at all in the header condition screen. In other words: Only active conditions or inactive conditions with

condition screen, provided that they are not inactive as described in a).

ly) at runtime during the display of the header condition screen and not saved in the KONV database table.

n screen (see 844141).

m level of the document. (See also section 2.d).

a rounding difference adjustment may be carried out (compare section 7).

lowing specification:

longer exists in the target document. Only the 'item portions' of the header condition are copied with the following specifications to the t
tandard system).

difference of EUR 0.01-.

items 40 and 50 (for example, change of the sales quantity) or the order itself (for example, creation of further items) remain open for ch
'E' (Items total). In addition, the amount of EUR 20.00- initially entered manually on the header is reduced by the fixed portions (20.00 - 5
esponds to the relationship of the condition bases. In fact, the relationship in general is only correct within a group of items that were fixed

he header pricing screen).

hese values dynamically at runtime.

MMEN in the PRICING_SUBSCREEN_PBO function module).

eader condition screen. In this case, the PRICING_SUBSCREEN_PBO function module no longer runs and the KAWRT and KWERT fields of t
their origin on the items of this document, for example:
orated in this 'items total' ('First item condition' according to the sorting described in section 10).

re summarized as much as possible. In other words: If certain criteria are not fulfilled, there is a split into two or more rows.
ons or inactive conditions with 'Y' or 'A' are included in the header condition screen.
ollowing specifications to the target document during the copy procedure:
her items) remain open for changes.
by the fixed portions (20.00 - 5.57 - 4.42 - 2.92 = EUR 7.09) and displayed in one row with the specification 'C' (Changed manually) for the
group of items that were fixed together (10 -30) or that are all outstanding (40, 50 [and 60]).

KAWRT and KWERT fields of the 'actual' header condition are still filled with the initial value 0.00.
o or more rows.
C' (Changed manually) for the condition control and 'C' (Manually entered) for the condition origin.