Register Login

SD Header Conditions/ Header Condition Screen Interview Q&A

Updated May 18, 2018

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 access). In R/3 standard pricing, the automatic condition access occurs only at item level of the document. (See also section 2.d).

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 'Change Options' section:

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 KAEND_WRT).
c) For 'Manual entries' (field KMANU), do not select the setting 'B' (Automatic entry has priority) or 'D' (Not possible to process manually).
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) and on whether the group condition (field KGRPE) is set or not.

Example:

For a header condition with calculation type 'Fixed Amount', the amount entered on the header condition screen is duplicated in each item if the condition is not set as a group condition.

However, if the condition is set as a group condition, the amount entered on the header is distributed proportionally (that is, in the relationship of the relevant condition bases at item level) and a rounding difference adjustment may be carried out (compare section 7).

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 tables XKOMV and TKOMV) with item number '000000' (field KPOSN) with the following specification:

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 '000000') onto which it was distributed or duplicated:

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 row from the source document with item number (field KPOSN) '000000' no longer exists in the target document. Only the 'item portions' of the header condition are copied with the following specifications to the target document during the copy procedure:

  • 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 a single row, for example:

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 two rows: One row for the already billed items and one row for the outstanding items.

The following section explains this system response using the example of an 'actual' header condition with the calculation type 'Fixed amount' (for example, the condition type HB00 in the R/3 standard system).

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 proportionally to the open items, for example, as follows:

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 40 (the item with the largest condition basis) receives the resulting rounding difference of EUR 0.01-.

There is a milestone billing for this order and the items 10, 20 and 30 are billed. The order 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, change of the sales quantity) or the order itself (for example, creation of further items) remain open for changes.

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 with condition control 'E' (Condition value and basis fixed) and condition origin '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.57 - 4.42 - 2.92 = EUR 7.09) and displayed in one row with the specification 'C' (Changed manually) for the condition control and 'C' (Manually entered) for the condition origin.

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 outstanding items (in the example, items 40 and 50).

Example: The order quantity of item 50 (or the PR00 price) is tripled, which also triples the condition basis for HB00 to EUR 8.49. 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 / 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 HB00.

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 amounts EUR 17.21, EUR 8.49 and EUR 13.97.

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 overall condition value for HB00 - seen for all document items - no longer corresponds to the relationship of the condition bases. In fact, the relationship in general is only correct within a group of items that were fixed together (10 -30) or that are all outstanding (40, 50 [and 60]).

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

  • There is no significance. In the KONV database table, only the condition rate (field KBETR) is relevant for an 'actual' header condition.
  • The condition basis (field KAWRT) and the condition value (field KWERT) of an 'actual' header condition are (re)calculated during R/3 pricing, if they are required (for example, when displaying the header pricing screen).
  • 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 condition. Standard R/3 pricing does not access these values.
  • 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 KWERT, but in the same way as R/3 standard pricing, the system should determine these values dynamically at runtime.
  • The values saved in the database table (generally) correspond to the values that were determined the last time the header condition screen was displayed (FORM XKOMV_AUFBAUEN_KOPFSUMMEN in the PRICING_SUBSCREEN_PBO function module).
  • If you now enter an 'actual' header condition and, for example, save the document immediately afterwards (that is, without activating the header condition), the system no longer displays the header condition screen. In this case, the PRICING_SUBSCREEN_PBO function module no longer runs and the KAWRT and KWERT fields of the 'actual' header condition are still filled with the initial value 0.00.

9. What is meant by 'item totals'?

'Item totals' are condition rows on the header condition screen that represent a summation of item conditions. These item conditions are conditions that (unlike 'actual' header conditions) have their origin on the items of this document, for example:

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 for question 6):

  • 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 condition control has the specification of the first item condition that was incorporated in this 'items total' ('First item condition' according to the sorting described in section 10).

10. How are 'item totals' displayed?

The summation of the item conditions for the display on the header condition screen occurs in the XKOMV_AUFBAUEN_KOPFSUMMEN FORM (include LV61AA60). In this case, item conditions are summarized as much as possible. In other words: If certain criteria are not fulfilled, there is a split into two or more rows.

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 total'), provided that none of the following split criteria is fulfilled.

However, if at least one of the split criteria is fulfilled, the system starts with the structure of a further row for the header condition screen (= a further 'Items total').

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 (field KRECH) or processing in different groups (field IX_GKOMV) in both rows.

Also the following:

a) Item conditions excluded with an inactivity indicator (field KINAK) not equal to 'Y' or 'A' (see 836243) are not included at all in the header condition screen. In other words: Only active conditions or inactive conditions with 'Y' or 'A' are included in the header condition screen.
b) Statistical conditions (for example, the condition type VPRS) appear on the header condition screen, provided that they are not inactive as described in a).
c) The 'item totals' are only 'virtual' condition rows. They are only created (dynamically) at runtime during the display of the header condition screen and not saved in the KONV database table.
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.

Read here for more SD (Sales and Distribution) Interview question and answer.


×