[SD] Item Categories Assignment

項目類型的指派

This assignment is influenced by:

• Item categories are assigned to sales document types .
  Configure the system to propose an item category when you create an order.
• The item category group from the material master record.
  The item category group allows you to group together different materials that behave in a similar way during sales and distribution processes, for example. You can also define new item category groups if needed.
• The usage for the item , which in some cases is set internally in the program.
  The system uses TEXT if the user enters an item in the inquiry or quotation by entering data in the "Description" field without specifying a material number. FREE is used for controlling free goods items.

  
  

  Trace list:

  
  Function Module RV_VBAP_PSTYV_DETERMINE
  Include FV45CF0C_CVBAP_FUSSZEILE_PRUEF
  Subroutine CVBAP_FUSSZEILE_PRUEFEN
    Include FV45PF0V_VBAP-PSTYV_PRUEFEN
  
    Subroutine VBAP-PSTYV_PRUEFEN
  Include FV45PFAP_VBAP_FUELLEN
    Subroutine VBAP_FUELLEN
  Include FV45PFAP_VBAP_FUELLEN_AUART_CH
    Subroutine VBAP_FUELLEN_AUART_CHANGE
  
  
  Function Module WTAD_ADDIS_IN_SO_IDOC_SLS_DET
  

  
  
• The item category of a higher-level item (in the case of a sub-item)

Parallel currencies in asset accounting

Turn on Secondary Currency in FI and further actions

---

1. OB22 (Additional Local Currencies For Company Code)

- create company code record
- setting 2nd local currency
  - Crcy type 30 (Group curreency)
  - set ExRate type
  - set Srce curr.
  - set TrsDte typ

[Code] YourIMG

Download Your IMG to Excel

---

IMG 的設定主要是存放在 Table, Maintenance View, Cluster View 裡，YourIMG 只針對主要的這三種格式下載。在 4.7 版中還有部份的 IMG 是使用獨立撰寫的程式去作設定的，這一類的資料就無法一併下載了。

IMG related tables & functions

與 IMG 相關的表格及功能模組

---

表格

SCUS_HIER                           Replacements table for hierarchies

TNODEIMG                            Node table for the new IMG
TNODEIMGR                           References for the new IMG

CUS_ACTOBJ                          Customizing Activity - Object List
CUS_IMGACH                          IMG Activities

功能模組

S_CUS_IMG_GET_REFERENCE_IMG_ID
S_CUS_IMG_SELECT_NODES

STREE_BROWSER_DYNP_HC
STREE_HIERARCHY_READ

STREE_STRUCTURE_READ_N_TOP_LEV
STREE_STRUCTURE_READ_TOP_NODE
STREE_STRUCTURE_READ_N_LEVEL

[SD] Sales Deal

A sales deal defines a marketing deal for a certain product. Depending on the setting, it can be allocated to a higher-level promotion.

Special condition records can be allocated to a sales deal. If relevant, the records also contain the number of the promotion allocated to the sales deal.

The control of sales deals includes the following options in Customizing:

• Define agreement types for sales deals
  The agreement type indicates the type of the sales deal, for example, whether it refers to a product or product line. The standard system contains sales deal type 0020.
• Define and allocate condition type groups
  A condition type group defines a group of condition types and condition tables which can be used together in the sales deal. Using the condition type group, it is possible to deal with individual products differently in a sales deal and, for example, to grant discounts specific to a customer or material.

Actions

Proceed as follows to define your own sales deals:

1. Create an agreement type by specifying a numeric key with a maximum of four digits and a description for the agreement type.
2. Specify the different control data on the detail screen of the agreement type (for example, validity period as default value, overview screen). In the agreement hierarchy, specify whether an allocation to a promotion may, can or must be made.
3. (Empty?)
4. Note
5. Further down in the Pricing chapter in Overviews you can also select a certain overview for sales deals as the default screen for maintenance of master data. For example, you can define an overview that should only be displayed for maintaining payment conditions for certain condition records.

[SD] Promotion

A promotion is a marketing plan for a certain product line (for example, during the market launch).

A promotion can be made up of several sales deals.

In Customizing, you have the following options for controlling promotions:

• Define promotion type
• Set up number ranges for promotions, if necessary
  The same number range is used for promotions as in rebate processing. If you want to use separate number ranges, make the appropriate setting.
• Enter the overview screen displayed for the user to create master data

Note

The same authorization object is used for promotions as for rebate processing (V_KONA_VKO).

Actions

1. Enter a numeric key with a maximum of four digits and a description for the promotion type.
2. On the detail screen, specify control data, such as:
   • Agreement category "P" for promotion
   • Validity period proposed as a default value
   • Overview screen
3. If necessary, create new number ranges (internal or external).

Transport

You transport number range objects as follows:

Choose Interval -> Transport in the accounting document Number Range screen.

All intervals for the selected number range object are deleted in the target system first. After the import, only the intervals you export are present. The number statuses are imported with their values at the time of export.

Dependent tables are not transported or converted.

[SD] Material Determination, Listing/Exclusion

物料決定，允許/排除清單

Material Determination

• Condition technique
  The condition technique provides you with greater flexibility in material determination. When you process a document, the system automatically searches for valid master records that you created previously in material determination.
• Substitution reason
  That defines how the material should be determined.
• Master data
  When you process master records, you can:
  • Restrict the validity period of a record
  • Maintain separate entries for each key combination
  • Determine reasons for substitution
  • Save one or more substitutes per master record
• Selecting Products Manually
  In manual production selection, (reason for substitution 0005), the system does not automatically replace the product.
• Automatic Product Selection
  When you enter an order, the system tries to fill the quantity of the order with the first material in the material determination master record. If there is not enough of this material, it fills the remaining quantity with the next material.
  • Re-run
    You can choose whether or not you want to re-run material determination when the delivery is created. If material determination is re-run, the result of the substitution may change due to the new availability situation.
  • Partial confirmation of product selection
    The Partial confirmation of product selection allows you to deal with shortfall cases (in which only the available quantity is confirmed, and it is less than the order quantity) by passing the shortfall quantity on to materials planning. In this case, an additional sub-item is generated with a specifically defined material.
  • Master Data
    The sequence of the substitution materials in the master data influences the result of the automatic product selection in the order.
    If you want the material that is first entered in the order to be included in the substitution, then you must enter it in the substitutions list.

Material Listing

• Condition technique.
• You want to make sure that your customer receives only specific materials. You enter these materials as a material listing.

Material exclusion

• Condition technique.
• You want to ensure that the customer does not receive certain materials. You enter these materials as a material exclusion.

[SD] Outline agreements

概要協定

The two main outline agreements are scheduling agreements and contracts.

• The simplest and most common type of scheduling agreement is represented in the system by document type DS .
• There are two types of contracts - value and quantity .

Scheduling Agreements

A scheduling agreement is an outline agreement between you and a sold-to party that is valid for a certain period of time . The scheduling agreement contains fixed delivery dates and quantities .

• These dates are contained in the schedule lines for the scheduling agreements.

Quantity Contracts

• The contract does not contain any schedule lines, delivery quantities, or delivery dates.

Messages about Open Outline Agreements

• You can choose several options for the search and determine how the system should react if the search is successful:
  • Blank: No checks
  • A/B:Check at header / item level:
    The system compares the customer numbers and material numbers. If there are any open outline agreements, it displays a dialog box in which you can make a selection. You can then display the open agreements in the form of a list, or continue to process the sales order.
  • C/D: Check at header / item level and copy if unique:
    If the system finds exactly one open outline agreement, this document is created automatically. Instead of displaying a dialog box, the system issues an information message in the status bar for the release.
  • E/F:Check at header / item level and branch immediately to selection list:
    Instead of displaying a dialog box, the system immediately goes to the selection list. No dialog box is displayed. If there is only one open contract, the system reacts as in C/D.

Value Contracts

It specifies that your customer agrees to purchase a fixed dollar value (target amount) of goods and services during a defined period.

A value contract can contain other agreements between you and your customer that are checked in the release orders:

• Special price agreements
• Customer restrictions
• Material restrictions
  • Product hierarchy (can be searched for generically by entering the first few digits, such as 0000101)
  • List of valid materials (assortment module)
• You can create releases in any currency but the total value is updated in the currency of the contract.
• You can either bill the value contract directly or you can bill each release order
• Document type WK1 uses item category WKN. Document type WK2 uses item category WKC.
  According to what you enter in the item, the system determines the item category with the usage indicator VCTR or the item category group VCIT .
• In the standard system, value contracts (document determination procedure Y) use pricing procedure WK0001 with condition type WK00 for the agreed target value.

Partners Authorized to Release in Contract

To meet this requirement, maintain the Check partner authorization field in Customizing for the sales document type. The sales order can be set up as a customer list (rule A) or via the customer hierarchy (rule B).

• Rule A Check contract partners
  If there is a customer list, you can store the partners authorized to release directly in the partner screen for the contract document.
  • In the standard system, partner function AA has been defined for use as an optional partner function in the relevant partner determination procedure (KAB procedure in the standard system).
  • Alternative ship-to parties are represented by partner function AW .
  • If there are already several possible sold-to parties in the customer master record (partner functions SP and AA), the system displays a selection screen when you create the contract where you can select and copy several partners in one step.
  • Partners authorized to release are checked at header level only.

Contract Data in Sales Documents

In Customizing for sales document types, you can activate the contract data.

blank:	No contract data
X:	Contract data is permitted. Any changes to the contract header are not copied to the items.
Y:	Contract data is permitted. Changes to the contract header are automatically copied to the items if the header and item data were identical previously. Changes are saved in a log. The log also notes any possible problems and inconsistencies.

Contract Profile

If you assign a contract profile to the sales document type, the system automatically determines default values specific to the contract. These could be:

• Rules for determining start and end of the contract
• Duration category
• Subsequent activities
• Cancellation procedure

[SD] Automatically Determine the Schedule Line Category

排程明細的自動決定

SAP uses two steps to automatically determine the schedule line category:

• First, it tries to determine the schedule line category using the key combination of item category and MRP type .
• If no schedule line category is found, the system searches for the key combination of item category / no MRP type .

[SD] Pricing Formulas

條件基值代用公式

Formula for determining the condition basis as an alternative to the standard.

定價公式

formula	usage
22	whole units of measure only 完整的數量才計價
23	any fractional portion of the total quantity 整張訂單合計後，不完整的數量才計價
24	for an incomplete unit 不完整的數量才計價

[SD] How to direct GI & return for vendor consignment stock with delivery

如何使用 D/N 直接對廠商寄售庫存作發貨及退貨

Reference: https://forums.sdn.sap.com/thread.jspa?threadID=347983

---

通常，執行 vendor consignment stock(廠商寄售庫存) 出貨時，要先用 411 K 將 廠商寄售庫存 移到無限制庫存後，才能夠由無限制庫存去作出貨。客戶退貨後，也要再用 412 K 把退貨移回到 廠商寄售庫存 去，後續結算時才能夠產生應付帳款的減項。

廠商寄售庫存 是帶特殊庫存指示碼 K 的庫存，如果你直接在出貨的項目類型設定 601 帶 K 的話，在作發貨過帳時會出現錯誤訊息指出 vendor code(廠商編號) 沒有輸入， 而且 ，在訂單、出貨單上都沒有地方可以輸入這個廠商的編號喔。

所以，Note 607604 指出了可以使用 MM 模組 stock determination(存貨決定) 的功能來讓 K 類的庫存在出貨時可以自動決定庫存以及帶出 vendor code 來。因此只要照 Note 607604 的方式處理，出貨的流程已經可以作一個步驟的出貨沒有問題了。

但是退貨呢？

標準退貨的異動類型 655 是不能指定特殊指示碼 K 的，所以不能用 655 當作退貨的異動類型，因此我們考慮使用 602 。

不過 ，在 存貨決定 的 source code 裡直接跳過了與退貨相關的訂單類型、訂單項目類型，以及退貨交貨的類型。因此我們只能用偷吃步(tricky)的方式讓 SAP 在退貨時執行 存貨決定 ：那就是利用標準的出貨訂單流程來偽裝，以達到退貨直接入廠商寄售庫存的目的。

我們要完成底下的這幾件事情：

1. 將標準的訂單 OR, 項目 TAN, 排程明細 DN 複製成新的類型，如 ZREA(SO) / ZTRA(Item) / DA(SLCa).
2. 設定訂單類型 ZREA 的訂單相關的請款類型為 "RE".
3. 設定排程明細 DA 的異動類型為 "602" ( 或是複製 602 成為其他的類型如 902 )。
4. 設定所有新增類型的指派以及複製控制。
5. 開放讓異動類型 602 可以使用 T-Code: VL01N, VL02N, VL09.

然後你就可以使用新的退貨訂單流程直接將退貨退入 廠商寄售庫存 了。

[SD] Set Up for Credit Card Payment Processing

以信用卡付款的設定

Source: http://www.sap-img.com/sap-sd/set-up-for-credit-card-payment-processing.htm

---

Given below is the set up for credit card payment processing:

Set Up Credit Control Areas:

Define Credit Control Area

Transaction:	OB45
Tables:	T014
Action:	Define a credit control area and its associated currency. The Update Group should be ‘00012’. This entry is required so the sales order will calculate the value to authorize ※ 00012 是指定銷售值的累計包括：未結訂單、未結交貨、未結請款 ※ 00015 是指定銷售值的累計只含：未結交貨、未結請款 (不計未結訂單值，如果碰到非出貨類的訂單，會自動使用 00018 ) ※ 00018 是指定銷售值的累計只含：未結訂單、未結請款

Assign Company Code to Credit Control Area

Transaction:	OB38
Tables:	T001
Action:	Assign a default credit control area for each company code ※ 也可以使用其他的信控範圍的指派啦

Define Permitted Credit Control Area for a Company Code

Transaction:
Tables:	T001CM
Action:	For each company code enter every credit control area that can be used

Identify Credit Price

Transaction:	V/08
Tables:	T683S
Action:	Towards the end of the pricing procedure, after all pricing and tax determination, create a subtotal line to store the value of the price plus any sales tax. Make the following entries: Sub to: “A” ( A 是信用值 ) Reqt: “2” AltCTy: “4”

Automatic Credit Checking

Transaction:	OVA8
Tables:	T691F
Action:	Select each combination of credit control areas, risk categories and document types for which credit checking should be bypassed. You need to mark the field “no Credit Check” with the valid number for sales documents. ※ 可以用「無信用檢查」的 Routine 來避開使用信用卡訂單的信用核查

Set Up Payment Guarantees

Define Forms of Payment Guarantee

Transaction:	OVFD
Tables:	T691K
Action:	R/3 is delivered with form “02” defined for payment cards. Other than the descriptor, the only other entry should be “3” in the column labeled “PymtGuaCat”

Define Payment Guarantee Procedure

Transaction:
Tables:	T691M/T691O
Action:	Define a procedure and a description. Forms of Payment Guarantee and make the following entries Sequential Number “1” Payment Guarantee Form “02” Routine Number “0” Routine Number can be used to validate payment card presence.

Define Customer Payment Guarantee Flag

Transaction:
Tables:	T691P
Action:	Define a flag to be stored in table. Create Customer Payment Guarantee = “Payment Card Payment Cards (All Customers can use Payment Cards)”.

Define Sales Document Payment Guarantee Flag

Transaction:
Tables:	T691R
Action:	Define the flag that will be associated with sales document types that are relevant for payment cards

Assign Sales Document Payment Guarantee Flag

Transaction:
Tables:	TVAK
Action:	Assign the document flag type the sales documents types that are relevant for payment cards.

Determine Payment Guarantee Procedure

Transaction:	OVFJ
Tables:	T691U
Action:	Combine the Customer flag and the sales document flag to derive the payment guarantee procedure

Payment Card Configuration

Define Card Types

Transaction:
Tables:	TVCIN
Action:	Create the different card types plus the routine that validates the card for length and prefix (etc…) Visa , Mastercard, American Express, and Discover. Create the following entries for each payment card Card Description Routines Periodic AMEX American Express ZCCARD_CHECK_AMEX Month DC Discover Card ZCCARD_CHECK_DC Month MC Mastercard ZCCARD_CHECK_MC Month VISA Visa ZCCARD_CHECK_VISA Month The Routines can be created based on the original routines delivered by SAP. *****SAP does not deliver a card check for Discover Card. We created our own routine.

Define Card Categories

Transaction:
Tables:	TVCTY
Action:	Define the card category to determine if a payment card is a credit card or a procurement card. Create the following two entries Cat Description One Card Additional Data CC Credit Cards No-check No-check PC Procurement Cards No-check Check

Determine Card Categories

Transaction:
Tables:	TVCTD
Action:	For each card category map the account number range to a card category. Multiple ranges are possible for each card category or a masking technique can be used. Get the card number ranges from user community. Below is just a sample of what I am aware are the different types of cards. Visa Credit Expires in 7 days. 400000 405500 405505 405549 405555 415927 415929 424603 424606 427532 427534 428799 428900 471699 471700 499999 Visa Procurement Expires in 7 days. 405501 405504 405550 405554 415928 415928 424604 424605 427533 427533 428800 428899 Mastercard Credit Expires in 30 days 500000 540499 540600 554999 557000 599999 Mastercard Procurement Expires in 30 days 540500 540599 555000 556999 American Express Credit Expires in 30 days 340000 349999 370000 379999 Discover Card Credit Expires in 30 days 601100 601199

Set Sales Documents to accept Payment Card Information

Transaction:
Tables:	TVAK
Action:	Review the listing of Sales Document types and enter “03” in the column labeled “PT” for each type which can accept a payment card

Configuration for Authorization Request

Maintain Authorization Requirements

Transaction:	OV9A
Tables:	TFRM
Action:	Define and activate the abap requirement that determines when an authorization is sent. Note that the following tables are available to be used in the abap requirement (VBAK, VBAP, VBKD, VBUK, and VBUP).

Define Checking Group

Transaction:
Tables:	CCPGA
Action:	Define a checking group and enter the description. Then follow the below guidelines for the remaining fields to be filled. AuthReq Routine 901 is set here. PreAu If checked R/3 will request an authorization for a .01 and the authorization will be flagged as such. (Insight does not use pre-authorization check). A horizon This is the days in the future SAP will use to determine the value to authorize (Insight does not use auth horizon period). Valid You will get warning message if the payment card is expiring within 30 days of order entry date.

Assign Checking Group to Sales Document

Transaction:
Tables:	TVAK
Action:	Assign the checking group to the sales order types relevant for payment cards

Define Authorization Validity Periods

Transaction:
Tables:	TVCIN
Action:	For each card type enter the authorization validity period in days. Card Description Day AMEX American Express 30 DC Discover card 30 MC Master card 30 VISA Visa 7

Configuration for clearing houses

Create new General Ledger Accounts

Transaction:	FS01
Tables:
Action:	Two General Ledger accounts need to be created for each payment card type. One for A/R reconciliation purposes and one for credit card clearing.

Maintain Condition Types

Transaction:	OV85
Tables:	T685
Action:	Define a condition type for account determination and assign it to access sequence “A001”

Define account determination procedure

Transaction:	OV86
Tables:	T683 / T683S
Action:	Define procedure name and select the procedure for control. Enter the condition type defined in the previous step.

Assign account determination procedure

Transaction:
Tables:
Action:	Determine which billing type we are using for payment card process.

Authorization and Settlement Control

Transaction:
Tables:	TCCAA
Action:	Define the general ledger accounts for reconciliation and clearing and assign the function modules for authorization and settlement along with the proper RFC destinations for each.

Enter Merchant ID’s

Transaction:
Tables:	TCCM
Action:	Create the merchant id’s that the company uses to process payment cards

Assign merchant id’s

Transaction:
Tables:	TCCAA
Action:	Enter the merchant id’s with each clearinghouse account

SAP SD Tips by *: **Radhakrishna Srinivas *