Sales management

• Inconsistency
• Worflows
• Workflow for approval of sales documents not working
• Functions
• Product proposal
• Output
• Free goods in SD document
• Material substitution
• 2942254 - Base unit of measure in document chains for material substitution
• Account determination
• Incoterms determination 
• Quantity rounding in sales order
• FI data determination
• Foreign currency
• Determine exchange rate type (VBAK-KURST) in sales order
• Date determination
• Other
789539 - International address version in the order
1047256 - FAQ: requirements, reference documents and overconfirmations
2890608 - Item Usage (VWPOS) additional documentation
2753397 - SD Sales: Maintain internal Document Number Ranges per Sales Organization, etc.


• Additional information
• 1176009 - FAQ: Questions and answers about value contracts

Additional information

Value contracts

1. Question: Which order types are supported in the value contract process?

Answer: In a value contract process, only the following order-type document categories are supported: "Order" (C), "Debit memo request" (L), "Credit memo request" (K), "Returns" (H) and "Order w/o charge" (I).

Note the following: In this case, you can create an order (C) only with a reference to the value contract. You can create credit memo requests and debit memo requests, for example, also with a reference to a billing document.

The values in brackets () are the document categories according to Customizing.

2. Question: Why does the released value in the value contract not change?

Answer: Check whether the value contract items have the completion rule "E" (Customizing item category or table VBAP-ERLRE).

3. Question: Why is the value contract not completed?

Answer: Contract values have the following feature: You require a reason for rejection to set a value contract to the status "completed". The reference status of an item in a value contract remains always open because the completion rule "E" does not affect this status.

4. Question: Why is the released value incorrect after an invoice with a reference to a credit memo request or debit memo request is created?

Answer: In the case of a credit memo request, the billing document must be a credit memo (VBTYP = "O"); in the case of a debit memo request, it must be a debit memo (VBTYP = "P"). A different combination cannot be used.

5. Question: Does the value contract scenario support documents that were created using resource-related billing (for example, DP90, DP91, DP..)?

Answer: No, this function is not supported in the standard system and results in update terminations in the statistic.

6. Question: Does the value contract scenario support documents with third-party order processing?

Answer: Yes, this function is supported in the standard SAP system.

However, note that the released value cannot be higher that the maximum value from the release document; for example, higher incoming invoice entry (overdelivery).

7. Question: Does the value contract scenario support documents with batch management?

Answer: The use of batch subitems that are not relevant for billing in the delivery that originate from a value contract delivery schedule as a subsequent document is not supported. This is the case if the main item in the delivery is relevant for billing but does not have a delivery quantity. In contrast, the batch subitems in the delivery are not relevant for billing but have the delivery quantities. In the billing document, the main item is billed.

8. Question: Apart from in dialog mode, is the value contract scenario also supported using BAPIs or function modules?

Answer: Yes, the value contract scenario is supported when you create items (for CREATE and CHANGE BAPI). For the assignment to a value contract item, the number of the value contract and the item number (BAPISDITM: VAL_CONTR and VAL_CON_I) must be specified.

9. Question: How does the system write the document flow when items are assigned to the value contract at a later stage?

Answer: When you assign items at a later stage via the menu: "Edit -> Assign contract -> Item", the system writes a document flow record for each item, regardless of whether the selected item is a main item or subitem.

The decisive factor in this case is the entry in the copying control with the target order type and source order type and the source item category.

10. Question: Does the value contract scenario support the down payment process?

Answer: No, this function is not supported in the standard system. As a result, the released value is incorrect in the value contract or the system cannot determine it correctly (release value Wert = 0).

Workflows

Workflow for approval of sales documents not working

https://help.sap.com/viewer/7b24a64d9d0941bda1afa753263d9e39/1909.002/en-US/5a5f3f686c06490893a588c99b36adca.html

Check whether event linkage has been activated for workflows:

To do this, go to customizing for SAP NetWeaver under 'Application Server -> Business Management -> SAP Business Workflow -> Perform Task-Specific Customizing' and then proceed as follows:

Expand the displayed component hierarchy and click 'Activate Event Linkage' for SD-SLS.

Check whether event linkage is active for WS 02000006 (workflow for sales orders), WS 02000029 (workflow for credit memo requests), and WS 02000447 (workflow for sales quotations).

If event linkage is not activated, activate it.

Note the following: All necessary steps for customizing of the flexible workflow are described here, for example. If you still do not receive any work items in the 'My Inbox' app after activating the event linkage or if the problems described above occur in the app for managing workflows for sales documents, check whether all of these steps have been performed in your system and perform them now if not. (The linked documentation describes the procedure for centrally managed purchase orders, but is also applicable for sales documents accordingly. You merely need to carry out the activities for the scenarios for sales documents, that is, the scenario IDs of sales documents must be used at the corresponding points in SD components in the component hierarchy, and so on.)

Finally, note the information in KBA 2424054 regarding the setup of the My Inbox app. In particular, ensure that the task filters are set up correctly in your system.

Inconsistency

521416 - Correctn report:Incorr order quantities in SD document flow

A purchase order exists for a sales order (for example, for a third-party or individual purchase order). You delete a purchase order item, however, the system does not reset the reference quantity in the document flow record to 0.

You can use attached correction report ZZVBFA03 to correct the reference quantity.
For security reasons, this report can only be applied to one sales order respectively.

2727077 - Sales orders "In Process" although delivered and invoiced

You have sales orders with "In Process" overall status even though the documents are fully delivered and invoiced.
You have maintained the completion rule in the item category of a sales order item. This is incorrect.

Remove the completion rule from the item categories of sales order documents. The completion rule is relevant only for sales documents that have a sales document as a follow-on document, that is, a quotation or contract with a sales order as a follow-on document.

When you create an item, the completion rule is copied from the item category (TVAP) to the item data (VBAP). A customizing change therefore does not affect existing documents.

The report ZZ_ERLRE_CORRECT is attached to this SAP Note. Use this report as an example for your own correction report to adjust the completion rule in the existing item data to the changed customizing. After a correction, execute the report SDVBUK00 for the affected documents to also correct dependent data, such as item statuses and document statuses. These actions change the sales document and then save, which can result in further document changes, such as a new credit check and availability check.

Functions

Product proposal

870085 - FAQ: Product proposal

Question 1: What is the difference between a product proposal and the cross-selling function?

The product proposal depends on the customer and the defined sales area. The proposed materials are proposed directly in the sales and distribution document without quantity specification and POSNR. This proposal can be determined as fully flexible and individual. To do this, you create a condition record with transaction VA51. Checks at item level and thus an assignment of the POSNR occur only after entry of a quantity from the product proposal.

The product proposal generally occurs when creating a document with transaction VA01. Redetermination of the product proposal takes place only when changing the type of the sales and distribution document and/or the sold-to party (see also SAP Note 553417).

In change mode in VA02, you can call the product proposal only via the menu or the 'Propose Items' button.

Cross-selling depends on the material. After entering the material in the document, a dialog box appears with a list of materials for selection. The materials presented for selection here are those that are sold together most frequently.

Question 2: What restrictions are there when creating a product proposal?

Automatic product proposal is not possible in connection with the following functions or activities:

Batch input

Inbound IDocs

BAPIs

Change sales and distribution document (only manually - button/menu)

Display sales and distribution document

Create sales and distribution document with reference

 

Question 3: From what sources can a dynamic product proposal be created?

The dynamic product proposa; can be determined from different sources in a combination of these.

The indicator for the origin (V_TPVH-PVHKN) is displayed in the sales and distribution document. If the same material in the product proposal is determined from several sources, the sales and distribution document always specifies the data source that was first accessed.

In Customizing, you must always specify the name of the function module that evaluates a data source -> under "Define Product Proposal Procedure and Determine Access Sequences".

SD_DPP_CROSS_SELLING

SD_DPP_CUSTOMER_MATERIAL_INFO

SD_DPP_EXCLUSION

SD_DPP_HISTORY

SD_DPP_LISTING

SD_DPP_PRODUCT_PROPOSAL

The function modue SD_DPP_READ is used only to read the product proposal from the database. If the background determination is combined with an online determination, SD_DPP_READ must always be listed as the first function module in online mode.

4. Question: When are the quantitites copied from a product proposal to a sales and distribution document?

In the SAP standard system, the target quantities (VBAP-ZMENG) are not automatically copied from a dynamic product proposal (SD_DPP_PRODUCT_PROPOSAL).

You can only copy the target quantity to the document via the menu path "Edit -> Propose items" or via the button "Propose items".

Question 5: Is the dynamic product proposal function possible for types of sales and distribution documents that use the target quantity on the screen in their screen sequence group?

The dynamic product proposal can only be used for sales and distribution document types with an order quantity.

6. Question: Why does the dump CALL_FUNCTION_PARM_MISSING occur in order entry when using standard function modules (SD_DPP_*) with the action D for merging the result externally?

The action D for merging the result externally is only intended for customer-specific function modules. For the action D, the previous results are passed to the function module so that it can modify the results list. For this reason, the function modules with action D are called with a different interface from that of the standard function modules (SD_DPP_*).

Use the action D for merging the result externally only for your customer-specific function modules with the relevant interface (see the different ways to call function mdoules in SD_INT_DPP_GENERATE).

Question 7: Can the product proposal be determined in accordance with the ship-to party, so via a customer-defined function module that uses the ship-to party as the basis, for example?

No.The dynamic product proposal is designed only for use in accordance with the sold-to party.

If the ship-to party is used as the basis, problems can occur during the further processing of the sales and distribution documents. For example, if the ship-to party is changed, the redetermination of the product proposal is not triggered.

8. Question: Can the product proposal be combined with listing and exclusion?

Yes, listing and exclusion also work for the proposed products.

Note the following:  The listing and exclusion are checked for products that will potentially be proposed. If a product is excluded, for example, it is removed from the product proposal. Therefore, the listing and exclusion no longer run when entering the quantity adds the item to the order.

If you use your own fields for the condition accesses that you supply with data in the form routine USEREXIT_MOVE_FIELD_TO_KOMKG (include program MV45AFZA), you have to make sure that your fields are already filled with the required values at this early juncture.

Output

960611 - FAQ: Output control in SD

Question: Why does the system not print the sales text defined in Customizing when the terms of payment are printed out?
Answer: This field is not printed in the standard system. For more information about this, see SAP Note 532654.

Question: Is there a transaction for the collective printing of outputs from orders (such as VF31 for "Output from Billing" or VL71 for "Output from Deliveries")?
Answer: As of Release SAP ERP Enhancement Package 5, transaction VA71 is available. Also see SAP Note 2784287.
In the older releases, there is the following alternative:
The relevant transactions for outputs from sales process documents are always based on an SD70A* report: VL71 -> SD70AV2A, VF31 -> SD70AV3A, and so on.
Such a report also exists for outputs from orders: SD70AV1A. You can either directly execute this report or assign it to a customer-specific transaction.

Question: Why does the system not issue outputs in the expected sequence when sales documents are collectively printed?
Answer: This is the standard system behavior.
- The sequence of the outputs in the output determination procedure does not have any influence on the sequence of the outputs during printing.
- The system ignores the sequence in which the outputs were inserted into a document.
- The system does not automatically sort according to customers when it issues outputs.
In Sales and Distribution, the outputs in a document are repeatedly sorted in internal tables during output determination and output processing.
Please use the sort criteria of the relevant transaction (for example, VF31) or the sort criteria of the relevant report (for example, RSNAST00) for issuing outputs.

Question: Can you use further sort criteria in addition to those proposed in the "Sort order" field for printouts from sales and distribution documents (for example, transaction VF31 or VL71)?
Answer: Yes, the following options are available for this:

• a) In customizing for the output type, you can specify up to three additional sort fields from the relevant print structure (print structure KOMKBV1 for application V1, KOMKBV2 for application V2 and so on). You can then use these fields as "Sort fields 1-3" using sort criterion 04 and 05.
• b) If this is not sufficient, you can use the user exit RSNASTZZ for the customer-specific sorting of the outputs during processing with the report RSNAST00.

Free goods SD-BF-FG (Free Goods)

The transactions for the free goods condition maintenance (VBN1, VBN2 and VBN2) are used both for the inclusive bonus quantity and also for the exclusive bonus quantity. After the transaction has been called you reach a screen where it is only possible to maintain the inclusive bonus quantity. Above this screen there is a pushbutton with the description "Exclusive", which allows the simple change to the entry screen for the exclusive bonus quantity. You can also use the menu "Goto Exclusive".

*& Object REPS FV45PF0N_NATRAB_SELECTION
*& Object Header PROG FV45PF0N_NATRAB_SELECTION

FM NATRAB_SELECTION

Pricing in free goods

The pricing procedure for the free goods should contain the condition type R100 which is the free goods condition type. This condition type in the pricing procedure has requirements as 55 and base type 28.

55 means only if the item is Free Goods then the only value of R100 to be used in Calculation. Value = Controlled by ALT Condition Base Value 28 which states that discount should be 100%.

Path for pricing: Img -> Sales And Distribution -> Basic Function -> Free Goods -> Condition Technique For Free Goods -> Maintain Pricing Procedure.

 Restriction

You cannot use the free goods functions under the following conditions:

• The document type is not type C (sales order)
• A subitem is involved (bill of material (BOM) item, for example)
• You have activated the configuration and/or the bill of material explosion
• The item is configurable
• You have activated product selection
• A scheduling agreement or a delivery order is involved
• An item with active ingredient management (proportion unit or product unit) is involved
• The items do not have any schedule lines (in the case of contract or credit memo request items, for example)

549963 - FAQ: Free goods in SD document

In what conditions is the determination of the free goods triggered?

Each time an order item is created, a free goods determination is carried out. In the case of existing items, you can trigger the determination of free goods by changing the order quantity or the price date. When you do so, the manually changed data in the free goods subitem is lost.

Can multiple free goods subitems be generated for an item, so one for the inclusive bonus quantity and one for the exclusive bonus quantity?

 No. This function is not included in the standard R/3 system. During the free goods determination, just one record is taken into account if there are several valid condition records. This is the record with the greatest minimum quantity. For this record, the system generates just one free goods subitem.

Can the delivery of the free goods subitem take place before the delivery of the main item?

Yes, if you have maintained the "Delivery Control" field accordingly in the master record for the free goods (free goods condition).

Can you change the quantity in the free goods subitem?

Yes. The new determination of the free goods can result in the calculation of a different free goods quantity if the conditions have changed. You can also change the free goods quantity manually.

Exceptions: The quantity can no longer be changed if: 

• A follow-up document exists for the free goods subitem
• The free goods subitem is referenced by another object such as a WBS element 

These restrictions apply because when a change is made, the free goods subitem is always deleted and then redetermined. However, if this has a link with another object such as a follow-on document or if it has an external reference, it cannot be deleted. As a result, you cannot change the quantity in this case.

Can the order material and the free-of-charge goods come from different places?

Answer: Yes. In this situation, you must manually enter the plant and storage location into the free goods subitem in the sales order. This is because the system automatically copies the data from the main item when the subitem is generated. The manual entry of the plant and storage location can cause problems such as a delivery refusal in certain circumstances. See SAP Note 460079 for more information.

Can I generate manual schedule lines for items with free goods?

Answer: Yes, but only for the exclusive bonus quantity.  

Material substitution

2942254 - Base unit of measure in document chains for material substitution

SAP ERP and SAP S/4HANA, different base units of measure for the materials (original material to alternative material) are not supported during material substitution of an item within a document chain.

The use of different base units of measure during the material substitution of an item within a document chain leads to an undefined system response. This means that some functions may work randomly in the document or business process, while others do not.
For example, the system does not determine statuses as expected, there is incorrect data in credit management and in the statistics update, and so on.

The reason for this is that the system first calculates back to the base unit of measure for various calculations and then uses this for further calculations.

Example: During a quantity cumulation for document 1000 with material A with the sales unit = box, the system calculates back to the base unit of measure = bottle (piece). The alternative material B in follow-on document 2000, which replaces material A, has the sales unit = bottle (piece), but the base unit of measure liter. It is impossible to cumulate the values with base unit of measure = bottle and liter.

Use only materials with the same base unit of measure when you substitute a material within a document chain.

FI data determination 

2093295 - Incorrect VAT number determined from ship-to party

The system is customized that VAT number is determined from ship-to party. After the sales order is created the address of the ship-to party is modified manually with an address belonging to a different country than the original one. During invoice creation it is expected that the system determines the VAT number based on the new country of the ship-to party. However the system determines the VAT number based on the original address.

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

1. Either in sales order on header level on tab billing document Tax dest. country with the new country should be added.
2. Or the new address with new country has to be set as an independent ship-to party.

2831531 - Feild VBKD-FBUDA when creating Sales Document via EDI

• The field 'Services rendered date' (VBKD-FBUDA) is not transferred by IDOC when creating Sales Order
• The field 'Services rendered date' (VBKD-FBUDA) is only transferred by IDOC when you create a Credit Memo Request.

In any other cases, you could use the following userexits to fill the
field in the order:
> EXIT_SAPLVEDA_001 to the reading of the IDoc´s
> EXIT_SAPLVEDA_002 to the populating of the screen

2513971 - Determine exchange rate type (VBAK-KURST) in sales order

In standard system, the value of field "exchange rate type" (VBAK-KURST) is copied from customer master data of sold-to party. Namely, if "exchange rate type" is specified in customer master data of sold-to party like following, the value will be copied to VBAK-KURST.

2928817 - Billing date( VBKD-FKDAT ) determination when creating sales order (Non third-party scenario) in VA01

Billing date is determined with following two factors:

Request delivery date ( vbak-vdatu )

Factory calendar in field 'Invoicing dates' ( VBKD-PERFK )

Logic is:

Firstly take a date from Request delivery date (if request delivery date is initial, it takes current date sy-datlo)

Then calculate billing date

If Invoicing dates ( VBKD-PERFK ) is space, billing date will be the date determined in above step 1

If Invoicing dates ( VBKD-PERFK ) is not space, system will retrieve the working date from this factory calendar next to the date determined in above step 1

(via FM DATE_CONVERT_TO_FACTORYDATE )

36070 - Fixing foreign currency rate for accounting document

In the standard system, you cannot set the system so that the accounting rate is transferred by the billing document from the order to Accounting.You can only enter this rate manually into the business data of the order header
- Details "Billing", field "Accounting rate"

Only then is the foreign currency rate not recalculated in the billing document.

The following approach is a possible solution from a technical point of view:
See the attached solution proposal in the include MV45AFZZ in the subroutine USEREXIT_MOVE_FIELD_TO_VBKD.
As a result, for the order type XXXX, the exchange rate for accounting (field KURRF) is set or specified - and therefore is not redetermined in the billing document.

Other 

1478022 - How to analyze sales document status issue

Case 1

Report SDVBUK00 shows the incorrect status

You are in old release 

The issue coud be reproduced by creating new sales document

Case 2

Report SDVBUK00 shows the incorrect status.

The issue could not be reproduced by creating new sales document.

Case 3

Report SDVBUK00 shows that the status for this sales document is correct

Sales document Order Combination flag source change

If the 'Order combination' field flag is set, then as explained above, the data is filled from the Sold-To Party master data record (KNVV-KZAZU). There is no customization in place where you can define a different source, for example Ship-To Party.

If you want to define a different source, this would require a modification to the standard system which is not the responsiblity of SAP to maintain - refer to Note 170183. For example: 

The Order Combination flag (VBKD-KZAZU) is filled here:

Include program FV45KFKD_VBKD_FUELLEN_KUAGV

  MOVE-CORRESPONDING KUAGV TO VBKD.

->> structure KUAGV contains data from sold-to master record, also KZAZU

Other fields from Ship-To Party are filled here:

Include program FV45KFKD_VBKD_FUELLEN_KUWEV

  MOVE-CORRESPONDING KUWEV TO VBKD.

->> structue KUWEV does NOT have field KZAZU

Possible Solution:

Append field KZAZU to structure KUWEV

Use userexit FORM USEREXIT_MOVE_FIELD_TO_VBKD (include program MV45AFZZ)

The userexit is designed to fill custom fields (VBKD-ZZxxxx), but it might be helpful to modify a standard field

---------------------------------

The 'Order combination' field in sales documents (VBKD-KZAZU) is always filled from Sold-To Party master data record (KNVV-KZAZU).

This field indicates if you are allowed to combine orders during delivery processing. The system proposes the indicator from the customer master record. You can change the value manually in the sales document at both header and item level.

729381 - When should a profitability segment be determined?

Go through the following questions step by step. They will tell you the reason why a profitability segment has to be determined or why determination is unnecessary.

1. Is it a text item?

No profitability segment should be determined.

2. Is it an item that was transferred to the R/3 System from CRM?

The decision as to whether or not a profitability segment should be determined is made in the CRM system.

3. Was a plant determined for the item?

No - No profitability segment should be determined.

Yes - Continue with question 4

4. Does the controlling area used exist and is it assigned to the company code used (-> customizing transactions OX18 and OX19)?

No - No profitability segment should be determined.

Yes - Continue with question 5

5. Is profitability analysis active (-> customizing transaction KEKE)?

No - No profitability segment should be determined.

Yes - Continue with question 6

6. Does an account assignment to a WBS element exist (VBAP-KZVBR = P or VBAP-PS_PSP_PNR is filled)?

Yes - No profitability segment should be determined.

No - Continue with question 7

7. Are incoming orders active (-> customizing transaction KEKF)?

No - Continue with question 8

Yes - Continue with question 12

8. Is there an account assignment to a non-statistical internal order or service order (VBAP-AUFNR) (-> transaction KO03 / tab CONTROL / flag STATISTICAL)?

Yes - No profitability segment should be determined.

No - Continue with question 9

9. Single-object controlling - but the original document (cost and revenue object) is a different document (0 < VBAP-VBELV <> VBAP-VBELN)?

Yes - No profitability segment should be determined.

No - Continue with question 10

10. Single-object controlling - but the original item is a different item (0 < VBAP-POSNV <> VBAP-POSNR)?

Yes - No profitability segment should be determined.

No - Continue with question 11

11. No single-object controlling, but consignment fill-up?

Yes - No profitability segment should be determined.

No - Continue with question 13

12. Is the item relevant for billing (this does not include relevance for pro forma invoice)?

Yes - Continue with question 8

No - Continue with question 13

13. Single-object controlling - the order item is the original item (VBAP-VBELV = VBAP-VBELN and VBAP-POSNV = VBAP-POSNR)

Yes - A profitability segment is required and should be determined.

No - Continue with question 14

14. Are incoming orders active (-> customizing transaction KEKF) and does billing relevance apply?

Yes - A profitability segment is required and should be determined.

No - Continue with question 15

15. Is account-based profitability analysis active (-> customizing transaction KEKE)?

Yes - A profitability segment is required and should be determined.

No - Continue with question 16

16. Does revenue recognition or revenue account assignment apply?

Yes - A profitability segment is required and should be determined.

No - No profitability segment should be determined.

2786988 - Manual Scheduling after enabling Delivery Group

You use a delivery group to determine a common delivery date for all the tems that it contains. If you double the quantity ordered for the main item, then the order quantity for the sub-item will also be doubled.

• Indicator X means that a delivery date is created for the delivery group. The system uses the last date (chronologically) of an item in this group to create the schedule line date.
• Indicator A means that the system generates correlated schedule lines.
• If no complete delivery is required, as soon as all the items in a bill
• of material are available, the system creates a correlated schedule
• line. On the first date, when all items in a bill of material are
• available, a confirmed quantity is issued.

2492002 - Why System Status NoMP is set in sales order

System status NoMP will be set if there is no individual customer requirement, that means if consumption indicator (KZVBR) <> E. This is assigned in customizing of the requirement class (transaction OVZG, consumption -> field KZVBR).
Requirement class is assigned to a requirement type, (transaction OVZH).
VBAP-OBJNR is determined in FV45PF0S_STATUS_OBJEKT_ANLEGEN.
If an object number is determined (e.g. due to a status profile) but no account assignment to sales order is carried out, the system status NoMP is set by the system.

An object number will be determined either in case of make-to-order production or this object number is required due to status profile.

2611643 - Customer Connection Improvement Request D201523: Determination of Shipping Conditions During Sales Document Processing

This SAP Note introduces the new 'Ship.Con.Ship-to-p.' field (VBVWE) in the Customizing of the sales order types (transaction VOV8).
The new functionality enables you to automatically determine the value of the shipping conditions during sales document processing based on the shipping conditions maintained in the ship-to-party and sold-to-party master records.
Depending on the settings made in Customizing, the shipping conditions from either the ship-to-party or the sold-to-party master record can be automatically applied when creating or changing sales orders (transactions VA01/VA02) and sales quotations (transactions VA21/VA22).
If the shipping conditions are not maintained in the master records, you can decide which value to use directly during sales document processing.

2752744 - Business Suite: SD Information Retrieval

According to present legislation, such as GDPR, data subjects have the right to get information regarding their personal data undergoing processing.

The Information Retrieval Framework (IRF) allows you to search for and retrieve personal data of a specified data subject. The search results are displayed in a comprehensive and structured way. To use the IRF, customers must set up a data model.

Business Function CA_DTINF_FW must be activated in your system.

2805057 - FAQ: System Time Zone and User Time Zone in SD Sales

For sales order the user date is recorded in VBAK-AUDAT. The user date is based on the user timezone as configured in the user master data (i.e., from sy-datlo).

Determines a local date and a local time from a time stamp.

GET TIME STAMP FIELD DATA(ts). 

CONVERT TIME STAMP ts TIME ZONE sy-zonlo 

        INTO DATE DATA(date) TIME DATA(time).

2753397 - SD Sales: Maintain internal Document Number Ranges per Sales Organization, etc.

It should be possible to assign different number ranges for Sales Documents per criteria like Sales Organization.

User exit 'USEREXIT_NUMBER_RANGE' is called when a sales document is being saved (FORM routine BELEG_SICHERN).
You can use this user exit to define the number ranges for internal document number assignment depending on the required logic, for example if you want to define the number range depending on the sales organization (VBAK-VKORG) or on the selling company (VBAK-VKBUR).
Please note that the number range object is always 'RV_BELEG'. You can define the number ranges in transaction SNUM.

2890608 - Item Usage (VWPOS) additional documentation

In the case of BOM sub-items, the Item Usage can be specified in the following IMG path (transaction OVT6):

SPRO > Production > Basic Data > Bill of Material > Item Data > Item Data from Related Application Areas > Define Relevance to Sales

Also custom item usages may be added in transaction 0VVW and then configured in Customer Material Info (KNMT-VWPOS) to overwrite item category determination for the particular material.

Item category determination for Sales Document is defined in transaction VOV4 with data stored in T184 table. The determination results in one default item category and up to 11 alternative item categories. Item categories are determined based on the following key combination:

Sales Document Type (AUART) + Item Category Group (MTPOS) + Item Usage (VWPOS) + Item Category of High Level Item (UEPST)

The item usage (VWPOS) can be used to control what item categories are to be found in a certain environment (text items and product selection, for example). The system then uses the item category (PSTYV) to determine how to process a particular item. With understanding of the context of the item usage, item categories can be customized accordingly.

2804135 - The sales order item has incorrect status however it has been rejected

In spite of the fact that a reason for rejection is set for a sales order item, the overall status of the item is still being processed.

A billing relevant item is rejected. Until the billing document has not been created for the billing relevant item, the billing relevant status remains 'A' in the table VBUP thus the overall status of the item is being processed.

Since the item should be rejected, it is no longer relevant to billing. To set the billing status to ' '( not relevant for billing) the field 'Not relevant for billing' has to be set for the rejection reasons. The rejection reasons can be customized in transaction OVAG.

1047256 - FAQ: requirements, reference documents and overconfirmations

1. When setting the reason for rejection for a sales order referencing a preceding document such as a quotation, the requirement for the preceding document is not increased by the rejected quantity (this is not true for MAIS scheduling agreements, the requirements of the scheduling agreement is increased after the reason for rejection is set in a referring sales order)
2. in transaction co09, one can see an over confirmation after removing a reason for rejection, unsetting the partial delivery indicator or decreasing the value in the underdelivery tolerance

Solution

1)This is an intended behaviour: rejection is not regarded as cancellation (For sales orders, this can only be achieved by item deletion or quantity reduction). You may use the reason for rejection also as final delivery flag, ie if you want to give the overall delivery status (field VBUP-LFGSA) to "Completely delivered" to a sales order which is only partially delivered. For that reason too, it would not be relevant to increase the preceding document requirements.

2)This is because when you remove these indicators, an ATP check takes place and passes the preceding document quantity as a correction record. This is a current limitation of the system.
In order to remove the over confirmation, you either have to add new receipts or if you can't, trigger an ATP check on the other documents (for instance the preceding document or one of the other standalone documents) and save the document. This ATP check will unconfirm the document which will in turn fix the cover confirmation situation.
In the case of the reason for rejection for a sales order referencing a quotation, please consider if you cannot use a delivery block instead of the reason for rejection. By using a delivery block which is customized (table TVLS) not to block confirmations, you can keep the requirement active and thus avoid over confirmations.

789539 - International address version in the order

he address versions are activated in the Customizing, however, the address on the overview screen in an order always uses the international address version. The rule based on "Sending country" and "Recipient country" is not taken into account.

Quantity rounding in sales order

80183 - Rounding

1. According to the properties of absolute amounts (KRECH = "B"), the net price is always an amount derived from the net value. On account of the construction, it is also always quantity-dependent. The net price therefore cannot be determined independently of the net value; there is no parallel calculation at the amount and value level, and no rounding differences can be displayed for this reason.

Rounding differences can occur in this case only if you force the relation "price * quantity = value" at the net value level. Only variant 1 is able to handle absolute amount conditions in this sense. Due to their approach to absolute amount conditions, variants 2 and 3 principally cannot offer a solution, and the corresponding rounding formulas therefore lead to a price determination error.

2. For the lines in the pricing procedure after the price condition and before the rounding condition, problems may occur if conditions exist that could receive a surcharge from the rounding differences clearing as part of the group condition processing. These scenarios are not tested and their ability to work in the context of this consulting note is therefore explicitly not guaranteed. Any modifications or enhancements that may be required in this context fall into the area of consulting. We therefore recommend that you suppress the rounding differences via a group key routine (see SAP Note 39034), if necessary.

General reason: The rounding difference clearing is carried out with the pricing type "F". If a condition in this pricing mode is then updated, the corresponding base and value formulas are no longer executed in change mode; that is, all changes in the work area XKOMV or the variables XKWERT are rejected. In this case, the variables XKOMV-KKURS, XKOMV-KINAK, and XKWERT in the condition value formulas 19, 20, 919, and 920 are affected by this.

However, the following statements can be made for the individual variants:

a) Variant 1 is not critical with regard to rounding difference clearing for the discount conditions because the discount conditions do not contain any formulas. However, the discount amount in the item containing the rounding difference clearing is, of course, no longer correct.

b) Variant 2 can probably be run despite formulas if a rounding difference clearing is carried out for the discount conditions. XKOMV-KKURS and XKOMV-KINAK should already be set correctly in the item pricing so that a new setting within the group condition processing should no longer be required. A surcharge for the discount condition based on rounding difference clearing should be caught again by the rounding condition NETP and should therefore not lead to a destruction of the relation "amount * quantity = value".

c) Particularly for variant 3, in the case of a surcharge for the discount condition based on rounding difference clearing, the relation "amount * quantity = value" would definitely be destroyed. The surcharge immediately affects the condition value of the net price condition PNTP.

3. In all the above solutions, the rebate amount is always rounded commercially and not the net price resulting from the calculation. Take the calculations specified under variant 3 as an example.

Procedure described in detail

1. Set up the condition type NETP (rounding difference, not for variant 3, transaction V/06):

Condition class "A" Surcharges and discounts

Calculation type "C" Is quantity-dependent

Condition category "L" Always determine again

Manual entry "D" No manual entry

Item condition "X"

No access sequence is defined.

2. Set up the condition type PNTP (net price, transaction V/06):

Condition class "B" Prices

Calculation type "C" Is quantity-dependent

Condition category "L" Always determine again

Manual entry "D" No manual entry

Item condition "X"

No access sequence is defined.

3. Create the formulas in the customer name range as described below (called condition base formula 917 and condition value formulas 906, 919, and 920 in the attachment; transaction VOFM). You only need base formula 917 and condition value formula 919 or 920 for variant 3. If you want to use only condition value formula 920 but not 919, you should still create formula 919 completely because it contains a data definition for formula 920.

4. Change your pricing procedure according to one of the following three variants:

Pricing procedure variant 1:

CTyp Description Reqt AltCTy AltCBV Stat Print

PR00 Price 2

RA00 Discount 2

NETP Round. diff 2 6 3

PNTP Net price 2 906 3 X X

          Net value 2

          ...

Attributes:

Net value = net price * quantity

Net price does not remain the same

Discount calculated correctly

This variant ensures that the relation "net price * quantity = net value" is always fulfilled. However, the net price can still be different due to rounding.

Any number of discount conditions of the same kind can be before the NETP condition.

Mode of operation of variant 1:

a) For 3 pieces:

   PR00 Price $135.50 per piece $406.50

   RA00 Discount 9.00% $36.59

   NETP Round. diff $123.30 per piece $0.01

   PNTP Net price $123.30 per piece $369.90

           Net value $123.30 per piece $369.90

For the condition value of $406.50, a 9% discount is granted, and that corresponds to $36.59 (rounded off). The result is a current net value of komp-netwr = $369.91. For the condition type NETP, base formula 3 uses the resulting current net price of komp-netpr = $123.30. Thus, for this condition type, the condition value is xkomv-kwert = $369.90. Condition value formula 6 now calculates a rounding difference of $0.01, which again is subtracted from the current net value. The rounding difference works like a normal surcharge or discount. The resulting net value is thus corrected so that the relation "net price * quantity = net value" is fulfilled.

If you now add a subtotal line item to display the net value to the condition type NETP, the net price could be different for the following reason (again due to rounding): The net price has 2 decimal places, and the quantity has 3 decimal places; the net value, therefore, theoretically has six decimal places. Because the net value uses only two decimal places, however, it has to be rounded. In contrast to normal condition type lines, subtotal lines calculate the net price backwards from the net value. With a hypothetical billing quantity of 1,234 pieces in the above example, you would receive the following:

        $1221.60 / 1,234 pcs = $989.95(1377...),

whereas if you want to print a net price line/net value line, you get:

        $989.95 * 1,234 pcs = $1221.60 (exact value: $1221.5983).

To rule out possible deviation here, the dummy condition type PNTP is also introduced. It bypasses the calculation logic of the subtotal line item. It is mainly used to print a consistent net price line/net value line. With condition basis formula 3, a condition amount is calculated from condition value here, and it results in the net value when multiplied with the quantity due to the standard pricing logic. Condition value formula 906 finally determines the net price and the net value resulting from it as price information.

In the last subtotal line item "net value", a deviating net price may theoretically result as described, but it is of no importance.

b) For 10 pieces:

   PR00 Price $135.50 per piece $1355.00

   RA00 Discount 9.00% $121.95

   NETP Round. diff $123.31 per piece $0.05

   PNTP Net price $123.31 per piece $1233.10

           Net value $123.31 per piece $1233.10

You can recognize that the net prices deviate by $0.01 in both of these cases.

Pricing procedure variant 2:

CTyp Description Reqt AltCTy AltCBV Stat Print

PR00 Gross price 2

RA00 Discount 2 19

NETP Round. diff 2 6 17

PNTP Net price 2 906 17 X X

         Net value 2

         ...

Attributes:

Net value = net price * quantity

Net price remains the same

Discount calculated correctly

Furthermore, this variant ensures that the net price is always the same.

Instead of condition type RA00, the following condition types can also be used with the following formulas:

Description Calc. formula Calc. type

RA00 Percent of gross amount 19 A

RA01 Percent of reduced amount 20 A

         Value

RC00 Quantity discount 19 C

RD00 Weight discount gross amount 19 D

RE00 Weight discount net amount 19 E

RF00 Volume-based discount 19 F

Any number of discount conditions, each with the corresponding value formula, can exist before the NETP condition.

Mode of operation of variant 2:

a) For 3 pieces:

   PR00 Price $135.50 per piece $406.50

   RA00 Discount 9.00% $36.59

   NETP Round. diff $123.31 per piece $0.02

   PNTP Net price $123.31 per piece $369.93

           Net value $123.31 per piece $369.93

In contrast to variant 1, here the discount is calculated by condition value formula 19 directly from the net price, thus, the net price no longer results from the net value being divided by the quantity. As a result, the net price is always the same due to the construction. This net price calculated in this way is then set as a condition rate in condition base formula 17. However, the standard procedure in which the discount is calculated from the net value runs parallel. In condition value formula 6, now the difference between the product "net price * quantity" and the net value calculated independently from it is determined again. The net value is then corrected by this amount. Using condition value formula 906, the condition type PNTP resets the net price and net value determined in this way.

b) For 10 pieces:

   PR00 Price $135.50 per piece $1355.00

   RA00 Discount 9.00% $121.95

   NETP Round. diff $123.31 per piece $0.05

   PNTP Net price $123.31 per piece $1233.10

           Net price $123.31 per piece $1233.10

In variant 2, the relationship "net price * quantity = net value" is always fulfilled, and the net price is always the same.

Pricing procedure variant 3 (P variant from R/2):

CTyp Description Reqt AltCTy AltCBV Stat Print

PR00 Price 2

RA00 Discount 2 919

PNTP Net price 2 906 917 X X

          Net value 2 X

          ...

Attributes:

Net value = net price * quantity

Net price remains the same

Discount not calculated correctly

This variant also ensures that the relationship "net price * quantity = net value" is always fulfilled and the net price is always the same. Rounding differences, however, are no longer displayed separately. Instead, they are contained in the discount.

Instead of condition type RA00, you can also use the following condition types with the following formulas:

Description Calc. formula Calc. type

RA00 Percent of gross amount 919 A

RA01 Percent of reduced amount 920 A

         Value

RC00 Quantity discount 919 C

RD00 Weight discount gross amount 919 D

RE00 Weight discount net amount 919 E

RF00 Volume-based discount 919 F

By using formula 920, you continuously grant the discounts for the accumulated new value/net price. For formula 919, every discount for the net value/net price is calculated before the first condition to which formula 919 or 920 was assigned.

Any number of discount conditions (each with the corresponding value formula) can exist before the PNTP condition.

Mode of operation of variant 3:

a) For 3 pieces:

   PR00 Price $135.50 per piece $406.50

   RA00 Discount 9.00% $36.60

   PNTP Net price $123.30 for each piece $369.90

           Net value $123.30 for each piece $369.90

Here, the net price is calculated directly first, and then the net value is calculated from it. You calculate the discount by determining the difference between the new net value and the initial amount. If the discount calculated in this way is then subtracted from the initial amount, you receive the first calculated net value again. This variant does not display any rounding differences since these differences are contained in the discount.

b) For 10 pieces:

   PR00 Price $135.50 per piece $1355.00

   RA00 Discount 9.00% $122.00

   PNTP Net price $123.30 per piece $1233.00

           Net value $123.30 per piece $1233.00

453347 - Sales unit and rounding profile

In the material master, you maintain a rounding profile or the delivery unit on the 'Sales: Sales org. 1' view. 

As a result, the base units of measure are rounded up or down to the alternative unit of measure according to the stored rule. For example, pieces are converted into cartons.

Then in the sales order, you enter the material with a requested delivery quantity in base unit of measure, for example 8 PCS. As a rounding rule, for example, it is stored that 10 PCS are one carton and that the system should always round up to whole cartons (alternative unit of measure). In this case, the system issues message V1720. In this example: "Item 000010 rounded to 1 KAR. Rounding reasons: 1,2 -> long text"

On the overview in the sales order, however, the system still issues the unit of measure pieces and not cartons, however, the old quantity (8 PCS) is replaced with the new quantity determined according to the rounding profile (10 PCS).

549413 Quantity rounding in sales order

1. Question: Why does rounding not take place to the alternative unit of measure even though there is a rounding profile for it?

Answer: In the sales order, the quantity entered in the item overview is always used, even if alternative units of measure exist. A conversion to a unit of measure does not take place. See SAP Note 453347.

2. Question: Why are V4 messages about rounding sometimes issued as information messages even though they are customized in a different way?

Answer: During a structure explosion, only information messages may be processed, since otherwise incorrect quantities will occur for the subitems during the quantity correlation.

3. Question: Why do rounding problems sometimes occur during the quantity correlation?

Answer: In the material master, a larger unit of measure was selected as the base unit of measure for the main item than for the alternative unit of measure or sales unit of measure. Always define the base unit of measure as the smallest unit.

For example, base unit of measure: Pc // sales unit of measure: L

Assignment: 1L = 100 pc (see also SAP Note 8818)

4. Question: Does rounding also take place during the creation of manual subitems?

Answer: Yes. If not, implement SAP Note 424772.

5. Question: Quantity optimizing does not take place in a sales order. Why not?

Answer: The corresponding rounding parameters must be maintained in the sales data under consideration. If only the additional quantity optimizing functions should be used without rounding with the help of rounding profiles or rounding values, a dynamic rounding profile with the rounding method ‘No Rounding’ (0) can be assigned in the master data. See SAP Note 434290.

6. Question: Why do rounding inconsistencies occur for BOM subitems if you work with three decimal places in the component quantity of the BOM?

Answer: Internally, the quantity in the sales order is calculated with three decimal places. If you enter a quantity with decimal places as the requested delivery quantity for the main item in the sales order, the product of the requested delivery quantity and the component quantity receives four decimal places. You can solve the problem by changing the component quantity or setting the quantity rounding of the unit of measure to four decimal places.

7. Question: Are the conversion factors from the item used for rounding?

Answer: No. Rounding always uses the conversion factors from the material master if rounding works with several different units of measure.

Example: You use the base unit of measure PC ("piece") and the sales unit PAK (“pack”) with the conversion factors in the material master: 1 PAK = 20 PC. Rounding should take place to the full PAL (“pallet”), and in the material master, it is defined that 1 PAL = 100 PC, which is equal to 5 PAK. You enter an order item with 4 PAK and change the conversion factors to 1 PAK = 25 PC there. Despite this, the system rounds to 5 PAK because the rounding works with the information from the material master and not with the conversion factors of the order item.

Do not use deviating conversion factors in the order item for complex rounding scenarios. In rounding scenarios, restrict yourself to a maximum of two units of measure. This gives you comprehensible rounding results. In the above example, use the sales unit of measure PAK for rounding and not the alternative unit of measure PAL.

Incoterms determination

The business logic for this system behavior is that incoterms are part of a sales agreement with the sold-to party as opposed to the ship-to party. The Incoterms are determined from the sold-to party, as they are purchasing the material, whereas the ship-to party is only a recipient of the goods. There is no option to determine Incoterms automatically from the ship-to party.

Account determination

1587812 - Account determination in sales order

In a sales order an account determination is only performed if it is absolutely necessary.

This is the case if Funds Management is active or the document is relevant for CO or for revenue accounting (vbkd-farr_reltype is not initial).

If the following fields are not filled then no account determination will be carried out in the sales order:

• VBAP-KZVBR, VBAP-PS_PSP_PNR, VBAP-AUFNR

The relevant code is in include FV45PF0K_KONTENFINDUNG.

If the above fields are filled and despite no account, determination happens, the following settings should be verified:

1. In transaction VOV8 the billing type of the used sales order type should be (TVAK-FKARA) checked.

2. In transaction VOFA the billing type defined for the sales order type is to be checked, the relevant field is here account determination procedure (TVFK-KALSMC).

3. It is a common problem that for the billing type defined for the used sales order type no account determination procedure is maintained.

4. If no procedure is maintained in TVFK-KALSMC then no account determination will be carried out no matter if fields VBAP-KZVBR, VBAP-PS_PSP_PNR or VBAP-AUFNR are filled or not.

Control elements 

Control determination 

Plant determination

With the access sequence: 

• Material: Sales: sales org 1->Delivering Plant
• Customer: customer master record of the ship-to party (XD*->Sales Area Data->Shipping->Delivering Plant)
• Customer-material info record(Note 626931 - FAQ: Customer-material info record->Transaction VD5*->Plant)

Shipping point determination

With the criteria:

• Loading Group: check the Loading Group from Material Master (MM0*->Sales: General/Plant->Loading Group)
• Plant (see 'Plant determination')
• Shipping Condition
• Sales Order Type in T-cd VOV8->Shipping Condition
• Customer Master in T-cd XD0*->Sales Area Data->Shipping->Shipping Condition
• Storage location ( optional )

FM: VERSANDSTELLE_ERMITTELN.

1. Check the determination method (TVLK-SPOFI Rules for Shipping Point Determination ): Plant-Specific Shipping Point Determination, Storage-Location-Specific Shipping Point Determination
2. Check the table tvstz_storloc by Storage, ship. cond., loading group, plant.
3. Check the entries for alternative shipping points from 1 to 12.

Route determination 

We can predefine different standard routes in the system. These are dependent on:

• Where the delivery comes from
• Where the delivery is going to
• Under what conditions the delivery is to take place

Criteria:

• Departure Country(CDep) and Departure Zone(DepZ) ->Shipping Point OVXD
• Destination Country(DstC) and Transportation Zone(RecZ) 
• Shipping Condition
• Transportation Group, Material Master
• Weight Group(GRULG) is determined in FM RV_WEIGHT_GROUP_DETERMINE
• Gross Weigh of Item(BRGEW) = Requested Quantity of Item * Gross Weigh of Material from Material Master(MM03).

Route Schedule

• Working times must be maintained at the following customizing: SPRO - Logistics Execution - Shipping - Basic Shipping Functions - Scheduling - Delivery Scheduling and Transportation Scheduling - Maintain Working Hours
• The working times must be assigned to the shipping point (so the system executes precise scheduling). In this example, working times 'ZNCTEST' which was maintained in the above customizing is assigned to the shipping point. This can be done in transaction OVLZ.
• Route Scheduling must be activated in customizing table TVST for the relevant shipping point
• Transportation Scheduling must be activated for the sales document type.
• Ensure the transportation group in the Sales: General/Plant data tab of the material master (transaction MM02) is the same as the transportation group maintained in the route schedule (transaction VL52).
• Ensure the shipping conditions in the customer master correspond to those in the relevant route schedule.
• If an unloading point is maintained for the customer in VD02, ensure the route schedule (transaction VL52) contains the same unloading point for the ship to party.
• Check the GI day & time maintained for the route schedule in transaction VL53.
• Obtain the working times assigned to the shipping point in transaction OVLZ
• Using the working times that are assigned in OVLZ, check the specific working hours maintained for them
• Ensure that the specific transit times maintained in the itinerary of the route schedule result in an arrival time that is within the goods receiving hours of the ship to party.

SD_ROUTE_SCHEDULE_DETERMINE, SD_ROUTE_SCHEDULE_READ_DB, SD_ROUTE_SCHEDULE_PREPARE.

Functions 

Material determination

Material determination enables the automatic substitution of materials in sales documents during sales order processing.

Use material determination if you want the system to automatically substitute, for example:

• customer-specific product numbers with your own material numbers
• International Article Numbers (EANs) with your own material numbers
• Substituting discontinued materials with newer materials

Partner Functions in Material Listing

• If the sold-to party has a material listing, the system only checks this listing (no other check takes place).
• If there is no listing for the sold-to party, but a listing has been created for the payer, the system automatically checks the payer’s listing.
• no material listing data exists for either the sold-to party or payer, then the customer may order any material.

Material Listing and Exclusion

Material listing and exclusion let you control which materials specific customers may or may not buy. For example, if you create a material listing for a specific customer, the customer can only order products from that list.

SD -> Basic Functions -> Listing and Exclusion

863767 - FAQ: Listing/exclusion

1. Question: When does a check on listing/exclusion occur?

A condition record for listing/exclusion is a customer-material relationship in the SAP standard system.Therefore, the check on listing/exclusion occurs by default during document creation and is dependent on the following header data:

a) Sales document type

b) Sold-to party/Payer

c) Requested delivery date

If the material is entered in the document, the check is run for this material.

a) The sales document type must be assigned to the listing or the exclusion or both in customizing. (transaction OV04)

b) If the sold-to party and the payer are different, the check occurs as follows:

• Listing for sold-to party = YES -> Check for this listing, no further check
• Listing for sold-to party = NO -> and payer = YES, a check on this listing occurs
• Listing for sold-to party and payer = NO -> the customer can order any material

c) The requested delivery date of the header is important for the check date for listing/exclusion. If there is no requested delivery date, the order creation date is used.

If this field is not filled either, the current date is used.

A new check on listing/exclusion occurs only if there is a change in one of the four header data listed above or in the material number.

2. Question: Is a check on listing/exclusion carried out in the sales order when there is a delivery date fast change?

Yes. If an exception for the listing/excusion is determined during the fast change with the new delivery date, the changed requested delivery date is not copied as default value to the order header.

The system then issues error message V2 145 "Date cannot be copied to header due to listing / exclusion", which is correct.

3. Question: Is a check on listing/exclusion carried out again if the delivery date has changed at item level?

No.

4. Question: What does the system do if several access sequences (key combinations) exist for the same key fields in the accesses for a condition type in listing/exclusion?

Consider, for example, the following accesses:

• Customer/material
• Customer/division
• Customer/hierarchy

General standard behavior is as follows:

• If no condition record is found for the first access, all further accesses are not executed.
• For Releases < 4.5B, this is the standard behavior; for more information, see consulting note 47851.

This procedure defines how the system reacts when several accesses occur. Maintain these settings in Customizing transaction OV04.

The field TVAK-VERLI has the following characteristics:

• - The first listing of the access sequence is critical
• A - The last listing of the access sequence is critical
• B - At least one listing must apply
• C - All listings must apply

5. Question: What does the system do if a material is listed for a customer and there is also a condition record for the exclusion of this material?

Apart from the fact that the maintenance of such condition records is contradictory, the system generally reacts as follows:

First, there is always a check for exclusion: If a condition record exists, the system issues error message V1 117 ("Material has been excluded"), which is correct.

6. Question: Can the table contents from the material listing/material exclusion be distributed to other systems using IDocs?

No. In the SAP standard system, there is no IDoc distribution of conditions for the usage 'G' (listing/exclusion).

7. Question: How can the following process be displayed? A material may be bought only by a certain number of customers.

Through material listing and material exclusion, you can control which materials a customer may purchase.

With material listing, a certain customer can purchase only the materials contained on the list.

With material exclusion, a customer may not purchase the materials listed.

However, you want to create your own requirement, which differs from this SAP standard function and in which a material may be bought only by certain customers.

Consulting note 865302 provides you with a workaround.

8. Question: What should I take into account when using my own conditions, and how does the prestep logic work?

A condition is defined. When checking conditions in the SD_COND_DETERMINATION function module, the condition prestep in the include KOBEV_xxx (checking header fields) is run first. If this prestep condition is not met (sy-subrc = 4), the system does not run the rountine KOBED_xxx. The performance is therefore improved, sinde the system no longer checks for listing/exclusion of the individual items.

When you create your own routines, note the following:

- At the time of the prestep in KOBEV_xxx, only fields from the structure KOMK (header fields) are available. Queries in KOBEV_xxx that access fields from KOMP (items) are not used.

- In the KOBED_xxx routine, you can then select the item fields from the KOMP structure for queries.

If you want the system to run queries from KOBED_xxx, the condition in KOBEV_xx must be met (sy-subr = 0).

Restriction:

An active listing cannot be completely deactivated at access level by using a separate condition at item level (KOBED_xxx). If access via requirement is deactivated, the system does not search for a condition record for this access and therefore may not find any condition record at all. The behavior is the same as if there were no condition record for the active listing. As a result, the system issues error message V1 118 ("Material & is not listed and therefore not allowed"). Solution: Include the item information to be checked as a field in your own condition table (see question 9) and maintain a condition record for it.

9. Question: How can self-defined fields be used in the condition tables for listing/exclusion?

"Sales and Distribution -> System Modifications -> Create New Fields (Using Condition Technique) -> New Fields For Listing/Exclusion"

The following communication structures are relevant:

• KOMKG (header fields)
• KOMPG (Item fields)

Use the following user exits to supply these structures with the field values for the self-defined fields:

• USEREXIT_MOVE_FIELD_TO_KOMKG
• USEREXIT_MOVE_FIELD_TO_KOMPG

The exits are in the include MV45AFZA.

Ensure that the new fields are first included in the field catalog in customizing and that these can also be inserted in the user include structure (KOMKGZ/ KOMPGZ).

10. Question: How does the check on listing/exclusion occur for the subitems of a BOM?

If a material is created by means of a BOM, and BOM subitems are created, there is always a check on listing/exclusion for all items.

If there is a condition record for a determined subitem that then would not allow the material in question, the system behaves slightly differently than in the other processes that also check listing/exclusion.

At first, it issues only an information message, either V1 117 ("Material has been excluded") or V1 118 ("Material & is not listed and therefore not allowed").

The process of the BOM explosion is not interrupted, but the invalid material is not transferred to the BOM. You therefore correctly receive the information message V2 003 'Material & is not copied from the bill of material.'

Note that the check on listing/exclusion prevents the transfer of the item but does not change the characteristic valuation in the configuration.

11. Question: Is a check on listing/exclusion carried out for the subitems resulting from the rule-based ATP check?

No. This is not allowed for sourcing-subitems and results in errors.

12. Question: What does the system do if overlapping validity periods were created for the same key combination of a condition type?

Overlapping validity periods of condition records for the same key combination of a condition type are not supported for material listing and material exclusion (usage G) in the standard system.

This leads to inconsistencies in the respective condition tables (KOTGxxx). It may cause update termination SAPSQL_ARRAY_INSERT_DUPREC or you receive error message VK 067 Internal Error: T IVAKE F IVAKE_INSERT I MV130F0I.

For information on troubleshooting, see consulting note 901718.

13. Question: Can conditions with multiple-value attributes be used for listing/exclusion?

No. Conditions with multiple-value attributes are not supported for listing/exclusion.

865302 - Listing/Exclusion: Defining own requirement

Calls in the coding:

-> FV45PF0V_VBAP_MATNR_LIST_EXCL 

  1.  Material read in maapv_select 

  2.  Fill the structures in  komkg_kompg_fuellen 

  3. * material exclusion

        if tvak-kalau ne space.

         …

  4. * material listing

        if tvak-kalli ne space.

        …

      after that for every one FB  ‘PRODUCT_LIST_EXCLUSION‘

Partner Determination

Partner Determination for Customer Hierarchy Nodes

• To determine the hierarchy path and store it in the document
• To store hierarchy data per item (the pricing of individual items in the order may relate to different hierarchy nodes)
• To make it possible to display sales orders or invoices by node

The standard version of the SAP System includes four standard partner functions for this purpose: 1A - 1D. You can add as many additional partner functions as you require, up to a maximum of 26 levels.

Authorized Partners for Release Orders

When you create a release order for a contract, you enter the number of the contract and the name of the partner who is requesting the goods. The system then checks if the business partner is authorized to release against the contract.

Depending on the settings in Customizing (Sales doc.type), the system determines whether a partner is authorized to release against the contract by checking against one of the following:

• Partners in the contract ( Rule A )
• If the partner has the partner function AG (sold-to party) or AA (sold-to party for release order) in the contract, the system accepts the partner as the sold-to party for the release order.
• If the contract contains a WE (ship-to party) and several AWs (ship-to party for release order), the system lists the possible ship-to parties in a dialog box. You select the appropriate ship-to party for the release order.
• Partners in the hierarchy (Rule B )
• If the partner who wants to release against the contract is the sold-to party of the contract or at a lower level in customer hierarchy to the sold-to party in the contract, the system accepts the partner as the sold-to party for the release order.

Texts in Sales and Distribution

• You can copy from a reference SD document to another SD document – from an inquiry to a quotation, for example, or from an order to delivery.
• You can copy the texts on a language-specific basis.
• You can change copied texts.
• You can integrate standard texts into SD documents.

Free Goods

Free goods can be mapped in the sales order in sales from the warehouse. When creating a sales order, the free goods items are automatically created in accordance with the agreement. The free goods are displayed as a separate item. The free goods item is a subitem of the original item. The free goods items are delivery-relevant and are copied to the delivery. The free goods item can be copied to the billing document. This makes it possible to prove the free goods are items that are free of charge on the invoice.

The free goods item is determined automatically by the system, according to the data in the free goods record. In the standard system, item category TANN is set for free goods items.

Inclusive bonus quantity 

Two out of ten bottles of sparkling wine are free goods. Therefore, if you order 10 bottles, 10 will be delivered and you will not be charged for 2 of them. So in this case, you have ordered an inclusive bonus quantity.

Inclusive Free Goods without Item Generation

In the free goods master record in the Free goods category field, select free goods category 3 (inclusive free goods without item generation).

Condition type NRAB is set up as follows:

• It does not determine a discount from a condition record. It uses condition basis formula 029 in the pricing procedure to determine a discount from the free goods factor.
• The condition receives the new pricing requirement 059 in the pricing procedure. This requirement checks whether free goods have already been determined.
• The condition type receives condition category f. This condition category ensures that the condition is redetermined every time the quantity is changed, since this can also mean a change to the free goods quantity.

Exclusive bonus quantity

If the customer buys 4 coffee machines, the vendor provides a packet of coffee as free goods. So if you order 4 coffee machines, a packet of coffee is delivered too, but you are not charged for it.

For inclusive free goods, the main item is automatically reduced by the free goods quantity. For exclusive free goods, the quantity of the main item remains the same.

Constraints

• Free goods are not supported in combinations with material structures (for example, product selection, BOM, variants with BOM explosion).
• Free goods are only supported for sales orders with document category C (for example, not quotations).
• Free goods are not supported for deliveries without reference to a sales order.
• Free goods cannot be used in make-to-order production, third-party order processing, and scheduling agreements.

Transfering to CO-PA

• You activate pricing for the free goods item category (TANN) using the special setting ‘B’.
• You defined a new condition type, which you set in the corresponding pricing procedure as a 100% discount.
• You assign requirement 55 (free goods) to this condition type - which checks for indicator ‘B’ in pricing.

Additional information

163057 - Rush order: Log if no delivery generated

When you apply the modification described in this note, the system generates a log in case that delivery generation for the rush order fails and a corresponding error message is generated during delivery processing in the background. This log corresponds to the log for collective processing for delivery creation and can be displayed using the same tools (for example, Transaction V.20, report RVSAMPRO or SDSAMAN4).

2092584 - Customer hierarchy levels (e.g. HIEZU01) are not considered in product allocation

You can use the form USEREXIT_QUOTA_KEY_VALUE (program FV45VFZY) to fill in the values for customer hierarchy (HIEZU01 – HIEZU10).

2578457 - Net Price List: Pricing relevant indicators in the Customer Hierarchy are not used

You have set the customer hierarchy where the pricing-relevant indicators are set for higher hierarchy levels, while the base level is not marked as pricing-relevant.
When generating the Net Price List (transaction V_NLN), the customer hierarchy fields are not participating in the pricing conditions access, which affects the overall pricing results.
However, the customer hierarchy fields are participating in the pricing conditions access when the sales document is created for the same customer (VA01).