SD--定价过程的16个字段的作用说明 zz

http://blog.csdn.net/CompassButton/archive/2007/08/25/1759141.aspx

SD--定价过程的16个字段的作用说明收藏

Define Pricing Procedure

• Select the pricing procedure which is the standard and copy it and create our own pricing procedure.
• Highlight it and double click the Control icon in the LHS screen.
• We can see that there are 16 columns in the pricing procedure, these are going to be used by the system to control the condition types.
• The detail description of each column is given below.

Step:

• Number that determines the sequence of theconditionswithin a procedure.
• It indicates the position of the condition type in pricing procedure.
• Ex.: 10, 15 etc.

Counter:

• System uses the counter to count the steps and also it can be used to count mini steps of same condition types. So that number of steps can be reduced in the pricing procedure and hence enhancing the system performance.
• Access number of the conditionswithin a step in the pricing procedure.
• During automatic pricing, the system takes into account the sequence specified by the counter.

Condition Type:

• It represents pricing element in pricing procedure as a base price, discount, freight and tax.
• The condition type is used for different functions. In pricing, for example, the condition type lets you differentiate between different kinds of discount; in output determination, between different output types such as order confirmation or delivery note; in batch determination, between different strategy types.
• Ex.: PR00 - Price

K004 - Material Discount

K005 - Customer/Material Discount

K007 - Customer Discount.

Description:

• System copies description of condition type from its description (V/06).

From and To:

1. From:This can be used as a base to the condition type for calculating further value.

1. {+}From and To:+ The range between the steps from and to can be used to specify the range between same condition types. So that depending upon the condition type, the system deducts or adds the total value of those condition types from specific common source.

Manual:

• This indicator specifies whether the specific condition type can be determined manually during sales order processing.
• If we check the box then the entry is going to be manual, if we uncheck it, it is going to be automatic.
• For Base Price and Taxes, the entry should be automatic.
• For Discounts and Freights, The entry should be manual.
• If we check the box, in VA01 when we go to conditions at the header/item level, the condition type will not be listed. If we require we will have to manually enter it.
• If we uncheck the box, in VA01 when we go to conditions at the header/item level, the condition type will be listed.

Mandatory:

• This indicator specifies that particular condition type is mandatory in the pricing procedure.
• If we check the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will not allow us to do it and throws an error.
• If we uncheck the box, then in VA01 at the header/item level in the conditions tab, if we delete the value in the condition type and try to save the document then system will allow us to save it, without giving any error.
• Mandatory check box should be checked in condition types which are compulsorily required in pricing procedure. Ex.: PR00, MWST.
• If the condition type is checked with mandatory option, then value should be maintained for that condition type, otherwise the system will not allow the user to process the document.

Statistical:

• This indicator if it is activated will not allow the value of the condition type to be taken into net value calculation.
• It is used only for information purposes only.
• This indicator causes a surcharge or discount to be set in the document statistically (that is, without altering the value).
• This is commonly used for condition types
  • SKTO - Cash Discount
  • VPRS - Cost (Moving average price/Standard Price).

Print:

• The value of this field specifies whether line item can be printed or not in the sales document and at what level it is to be printed.

Subtotal:

• The value of this field determines where the values of subtotals to be captured i.e. in which table and which field.
• Controls whether and in which fields condition amounts or subtotals (for example, a customer discount or the cost of a material) are stored.
• If the same fields are used to store different condition amounts, the system totals the individual amounts.
• These condition amounts or subtotals are used as a starting point for further calculations. You may, for example, want a subtotal of all the discounts included in the pricing of a sales order.

Requirement:

• It is a routine that is written by an ABAP consultant according to the business requirement.
• By defining Requirement in condition technique we can restrict the access of condition type.
• To understand the concept, we will take the example of the Rebates. Rebates are to be included during the billing document processing and not in the sales document processing. As rebates are given on the delivered quantity and not on the ordered quantity (in case of cut-off period for rebates).
• For rebates we use the condition types BO01 to BO05, and in the Requirement column we give the value 24 which is "Only in Billing Document".
• This Requirement will ensure that these condition types will appear only during the billing document processing.
• If new Requirements are to be defined we follow the procedure given below.
  • Go to T.Code: VOFM. - Maintain Requirements & Formulas
  • Click on the "Requirements" in the top menu and then click on "pricing".
  • We have a list of requirements, we can ask ABAP consultant to create new requirement based on the client requests.
  • And we assign the application type like V - Sales/Distribution etc.

AltCty - Condition formula for alternative calculation type:

• It is again a Routine that is written by ABAP Consultant.
• It is an alternative formula for the condition type that can be used instead of standard formulas.
• For example, let us take the Profit Margin which can be both + / - , so here this routine will help us in generating the value which can be either + or -. Profit margin is not a condition type so it cannot be classified as +ve or -ve in the V/06.
• Ex.: 950 0 Profit Margin 11.
• So we assign 11 - Profit Margin.
• If new routines are to be defined we follow the procedure given below.
  • Go to T.Code: VOFM. - Maintain Requirements & Formulas

• • Click on the "Formulas" and then on the "Condition Values".
  • We have a list of routines, we can ask ABAP consultant to create new routines based on the client requests.
  • And we assign the application type.

AltCBV - Alternative formula for condition base value:

• Formula for determining the condition basis as an alternative to the standard.
• It is again a Routine that is written by ABAP Consultant.
• It is used as a basis to calculate value of the condition type instead of using it from the "FROM" column.
• Ex.: Freight - KF00.
• Freight is calculated based on weight, volume etc. and not on the base price. In pricing there is no entry of weight from which the value can be referred like we do for discounts using base price. We have to get the value from the Material master.
• In this column we can mention the value as 12 - Gross Weight or 13 - Net Weight.
• During pricing, the system will consider the value that is mentioned in this column and determine the freight based on this value.
• Suppose we have Net weight: 100 kgs and Gross Weight: 150 kgs. And if we mention 13 in this column then the Freight condition KF00 will be calculated using the weight as 100 kgs.

AcyKy - Account Key/ Accrls - Accruals:

• The values of the Sales Revenues, Sales Deductions, Freight Revenues, Tax Revenues, and Rebate Accruals etc. are going to be posted in the respective G/L accounts in Fi Module.
• In order to do this we assign account keys/ accruals to the different condition types based on their classification. The classification shown below.
  • ERB Rebate sales deduct.
  • ERF Freight revenue
  • ERL Revenue
  • ERS Sales deductions
  • ERU Rebate accruals
• For Ex.,
  • For all Price condition types like PR00 etc. we assign ERL - Revenue.
  • For all Discount condition types like K004, K005 etc. we assign ERS - Sales Deductions.
  • For all Freight condition types KF00 etc. we assign ERF - Freight Revenues.
  • For all Rebates condition types BO01 to BO05 we assign in Account key ERB - Rebates Sales deductions and for Accruals ERU - Rebate Accruals.
• This account keys and accruals are in turn assigned to respective G/L accounts. So the system posts respective values in respective G/L accounts in Fi-Co Module.
• This also one of the areas of SD - Fi Integration. SD consultants assign the account keys and Fi Consultants assign the respective G/L accounts in T.Code:VKOA.

How to create and process Rebate agreement?zz

http://www.saptechies.com/how-to-create-and-process-rebate-agreement/

Following explains how to crete a rebate agreement, test it using a sales order and billing it. Then settling it partially or fully using a rebate credit memo. Please use the basic procedure and tweak your IMG settings according to your unique requirements.

Rebate processing:
1. First requirement is that the rebate processing must be active for
a. the customer ( check in customer master) ,
b. for the billing type ( check in IMG > Billing > rebate processing > active rebate processing > select billing documents for rebate processing. )
c. For the sales organizatin:
( check in IMG > Billing> rebate processing > active rebate processing > Active rebate processing for sales org. )

2. Next create a rebate agreement For this ust T-code VB01. For the rebate agreement type you can choose either 0001
( group rebate ) or 0002 material rebate or 0003 ( customer rebate ) etc
b. Enter your rebate conditions. Dont forget to enter the accrual rate here.

3. Now test your rebate functionality : create a sales order for the particular customer, sales org ( ensure that the billing type used in your sales order is relevant for rebate) . Create outbound delivery, transfer order to do picking and post goods issue.

4. Now go to Tcode VB03 and check your rebate by choosing conditions , selecting the condition line and choosing payment data. You will see that the accruals and business volume are updated when accounting doc is created for billing.

5. Settling your rebates:
Once your rebates have been accrued you need to settle the rebate.
For this first release the rebate for settlement by using Tcode VB02. As a trial basis choose B ( you can choose other settings based on your requirement) and choose Create manual accrual. Now enter the amount to be paid and save the rebate agreement.

6. Next display your rebate agreement using Tcode VB03.
Enter your rebate agreement number . Next choose rebate payments > Rebate documents and select partial settlement. Click on the choose button to note down your credit request number.

7. Use Tcode VA02 and release the billing block for your credit request. ( use item overview tab)

8. Now use VF01 to create a rebate credit memo by entering the credit memo request number and save it

9. Now release the credit memo to accounting using vf02.

ATP zz

常说可用性检查或者ATP（Available-to-Promise），其实他们并不完全等同。可用性检查的方式有两种，

一是ATP Logic，

一是Against planned independent requirements。

前者会全盘考虑各种Issues和Receipts，如计划订单、生产订单、库存、销售订单等，可配置。后者只考虑计划独立需 求（PIR）与销售订单的供求关系，甚至不考虑库存。

ATP Quantity是Receipts减Issues的差值，该数量可供新的销售订单使用。

The quantity available to MRP for new sales orders.

The ATP (Available-to-promise) quantity is calculated according to the following formula: ATP quantity = warehouse stock + planned receipts - planned issues.

http://www.kanterwang.cn/post/47.html Kanter Wang

Availability Check，顾名思义，就是有效性检查，指的是要检查一下此物料是否能满足我的需求。

简单地举个例吧，你 接到一张销售订单（SALES ORDER），客户要求数量为100PC，并且客户要求的出货日期是2009-4-1，此时我们的销售人员肯定会想，在这个愚人节到底能否出货给客人呢？ 那怎么办呢？一个个电话去问生产计划人员，去问厂长，经理？废话，肯定不能这样，要不然花几百万，几千万上SAP做什么对吧，此时在系统中建立此单 时，SAP就会做一个所谓的检查，检查一下我们预先设定的考虑因素，能否满足客户的要求，什么时候可以满足，这就是有效性检查的功能。

但一般人看到此单词就会想到 ATP，实际上系统中并不只是包含这一层意思的，就听俺慢慢道来

有效性检查包含以下两个概念

1就是大名鼎鼎的ATP(全称：Available To Promise)

2.就是Check Against planned independent requirements (意指计划独立需求的相关检查)

ATP (Available To Promise)

有效性承诺，检查承诺物料的相关元素，看是否能满足需求，什么时候能满足。

先看标准解释图片

第一张图表示某物料在某个时间上有生产订单或计划订单，数量及时间如图

第二张图表示如果在某个时间上有销售订单

那我们的生产订单或计划订单能否满足客户的需求呢？就看图三了

当我们在建立S1此销售订单时，因为我们已经有了一张P2的生产订单，并且日期是小于S1的，因此S1是肯定可以满足的，并且是提供满足

S2同S1原理一样，完全就可以由P2去满足

S3可以被P3的一部分满足

S4可以被P3的剩余部分满足

S5被P4部分满足

而P4再剩下的部分数量，就是未来可提供的ATP QTY

当我们在使用ATP时，系统检查的LOGIC如下：

通过 checking group + checking rule 得到Scope of check

再在SCOPE OF CHECK中设定需要检查哪些元素，再把哪些元素加加减减得到剩余的ATP QTY，再用剩余的ATP QTY来与新的需求对比，从而决定是不是能满足到需求，看似简单，整起来还是有点事的，哈。有点说时迟，那时快的感觉。

Setting

Checking group 来自于物料主档，如下图

Checking Rule来自于应用程序，即不同的应用程序有不同的设定，如生产订单有生产订单的设定，销售订单有销售订单的设定等

SPRO->Production->Shop Floor Control->Operations->Availability Check->Define Checking Control

如上图，则是在PP模块中针对不同的PLANT + order type来定义不同的RULE，后面的BUSINESS 1 OR 2表示CREATE OR RELEASE.

看到吧，在这里就可以看到CHECKING RULE是多少

并且component check type是决定用ATP CHECK 还是用 AGAINST CHECK PLANNING INDEPENDENT REQUIREMENT

根据上两副图我们就会得到组合 Checking group + checking rule = 02 + PP

而02+PP又是控制什么呢，来看下面的路径

SPRO->Production->Shop Floor Control->Operations->Availability Check->Define Scope of Check

1 – 13 我想很明白可以看出来，是什么东西，这里我就不详细解释

14： 表示相关预留的选项，与10的区别在于，10是一般是表示我们用MB21建立的，而14是表示由于相关预留，即此预留是来自于其他物料，如生产订单所产生的预留

15：指STOCK TRANSFER ORDER

16：指计划订单

17：指生产订单

18要单独再演示

19 表示是否在库存地点的角度上去分析，如你在仓位：0001的需求是100PC,但是库存如下：0001仓 = 80PC ,0002仓=60PC，那对此物料去做ATP的时候，到底是应该显示缺料20（100-80）还是不缺料呢（80+60-100 > 0）？就是此栏位决定的

20：主要用于WORKFLOW，即在这个区间中，如果存在收货了，则会发邮件到MISSING CONTROLLER

21：用于控制确认的日期能否在过去或未来

演示

来个简单的演示吧。

今天心情不太好，没有用我的KT物料，因此用了标准的100-110此物料

此物料有库存72PC,0001仓22PC，0002仓50PC

但是在2008-12-30有一需求（OrdRes）即相关预留11PC，因此72PC中还有61PC可用，对吧。

如果此时建立一张新的PRODUCTION ORDER，如下图

可以看出第一次确认是为61PC，第二次为50PC（从中就可以看出是把2009-3-20的PchOrd给包含进去了）

在这里可能会有几个疑问：

1是61PC包含0001仓与0002仓

2是为什么61PC是2009-3-11

3是为什么PchOrd也参加了计算

先看看后台设定画面

看我上图中的红色标记可以1与3就可以解答了。

而2的答案是要看此物料的需求日期

如果你把No storage location inspection不选中的话，则ATP结果会如下：

2009-3-11变成了11PC，因为我们的0001仓只有22PC，但已经被第一张用了11PC，因此还剩下了11PC给新的生产订单使用。

如果不包含PURCHASE ORDER（不选中有数字标明图中的第7个及13）,则表现如下

只有11PC了，因为没有考虑PURCHASE ORDER。

好，现在来看看18的功能，之前的测试18项都是选中的

假设即不选中7 AND 13，也不选中18，如下图

注意，变了，大大的变了，多了一个2009-3-23 ，数量为剩余的109 = 120 -11 意思是为从现在去买的话，2009-3-23就会回来的，呵呵。

这个2009-3-23如何来的？就是靠18项控制的，18项的意思是说要不要考虑“补充交货周期”，那这个又是从哪来的呢？

看看这个

如果你是用SALES ORDER来演示的话，就要看看下面

OK? No Problem?

Check Against planned independent requirements

此方法即只是检查相关物料（或相关物料的计划物料）的计划独立需求能否满足需求，如果可以的话，就可以CONFIRM，如果不可以就不行，而不会去看相关物料的库存有没有，生产订单有没有。

在之前一画面我们曾经看过在生产订单中如何设定采用哪种方式，而是销售订单中，即是通过这个LOGIC来的。

1. 物料的STRATEGY GROUP

如果上图都不知道是那个画面的话，我想可能要麻烦你先学学以前的基础学科

2. 此STRATEGY 所对应的Requirement type of customer requirement

SPRO->Production->Production Planning->Demand Management->Planned Independent Requirements->Planning Strategy->Define Strategy Group

默认用第一个，但也可以选择其他几个策略的，这里可以参加PRODUCTION PLANNING COURSE

SPRO->Production->Production Planning->Demand Management->Planned Independent Requirements->Planning Strategy-> Define Strategy

就是上图中红色标记的 Availability check来决定的，如果选中，则在Sales order中是用ATP ，如果不选中，就是用 CHECK AGAINST PIR .

演示

此物料有库存100PC

没有任何的PIR (计划独立需求)

在建立Sales order的时候，不能CONFIRM到任何的数量，就算有库存也不行，并且你会发现这种与正常的ATP有点不同，在上面的工具栏中，并不会有什么SCOPE OF CHECK之类的字眼，可以去留意一下。

再来，如果我建立一个PIR

再建立SALES ORDER , CHECK 如下

看到吗？日期与数量都等于我们的PIR的数量。

注：此种方法跟：SPRO->Production->Shop Floor Control->Operations->Availability Check->Define Scope of Check 没有一点关系。

这个很简单吧。

下班了，要去吃饭了，写了我一上午，真是辛苦啊。

Credit Control

1. check setup for credit control area: 4 levels
OB38 CCA-companycode
OVFL CCA-sales area
XD02 CCA-payer
SE37 user exit

2. sales doc. type--credit limit check OVAK/OVAP
OR-D(automatic credit limit check) 01 (sales credit group)
LF-02-01

3. Define risk cat. for each CCA, will assigned to FD32
001 low risk
002 high risk
100 new customer

4. define credit check for Key fields: OVA8 CCA/risk cat./credit grp
eg: 1000 001 01 -> detail
1) if choose "status/block", the follow-up actions (like confirmation, avalibility check... will stopped)
if not choose, maybe impact, means even exceed credit, still can do ATPcheck...
2)statistic
Dynamic-impact follow acti vity

5. setup master data (credit limit) for payer FD32

6. item cat. level: active credit VOV7

7. pricing: "A" subtotal entered V/08

8. credit update for CCA OB45
000012-update group

9.define detail update for update group S066 OM01

思路：
credit control area setup: 4 ways
define credit group: 01 sales/02 delivery/03 goods issue
assign credit grop to sales doc. or delivery types
define credit limit relavance per item cat.
define scope of credit check (auto): CCA/risk cat./credit group

when credit hold, system can trigger output TRML to relative people

Settlement Downpayment with Installment payment Term zz

http://www.sap-img.com/sd024.htm

Scenario :- Problem with Down payment settlement using installment payment term.

1. When we create Sales order, (sales item value = 100) use payment term :
0009 (Installment Payment term, 30%, 40%, 30%). In the Billing Plan, I specify 2 records, 1st record is
Downpayment request 30% of Order value, billing type is FAZ . the 2nd record is Final invoice 100%, billing
type is F2.

2. Create Billing type Down payment request , it will document as Noted item in the accounting document.

3. Receive Downpayment from customer via FI screen , at this stage the asccounting document is created as following
Dr. Cash/Bank 30
Cr. Advance from customer 30

4. When I create Billing document for the sales item, the down payment value will be proposed for settlement at Billing
Creation, I then accept the default value of down payment clearing. The accounting document is as below
Dr. AR 30 (*split AR by installment payment term)
AR 40
AR 30
Cr. Sales 100
Dr. Advance from customer 30
Cr. AR 9 (DP. 30% * 30)
Cr AR 12 (DP. 30% * 40)
Cr AR 9 (DP. 30% * 30)

It seems SAP settlement Down payment by Installment Payment term. I was wondering that is there are alternative or an option to setup the Down payment settlement independent of Installment term. I meant, I don't want to have the last 3 Credit item as above, I want only 1 line item of credit, the accounting should be
Dr. AR 30 (*split AR by installment payment term)
AR 40
AR 30
Cr. Sales 100
Dr. Advance from customer 30
Cr. AR 30 (Not separate by Installment payment term)

Solutions : Suggesstions on how I could proceed?

Your problem with Down payment settlement is common. Many users object to the down payment or security lodgement mechanism. In our case we often park and apply the advance manually to final invoice.

However, following the above case we sometimes use this with our PS orders:

1. Create Sales order, (sales item value = 100) with billing plan with three steps 30% down payment,30% std billiing on
order completion and 70% on delivery. A little different to your original Billing Plan, but 1st record is Downpayment
request 30% of Order value, billing type is FAZ . the 2nd & 3rd records are std F2 invoices 30% ,70%.

2. Create Billing type Down payment request , it will document as Noted item in the accounting document.

3. Receive Downpayment from customer via FI screen , at this stage the accounting document is created as following :-
Dr. Cash/Bank 30
Cr. Security deposit payment 30 ( In many countries this may be subject to TAX laws)

4. Create the First Billing documents , the down payment value will be proposed for settlement at Billing Creation, then
accept the default value of down payment clearing as these equal each other. The accounting document is as below
Dr. AR 30
Cr. Sales 30
Dr. Advance from customer 30
Cr. AR 30

5. Create the Second Billing document ( down payment value has expired and will not be proposed) The accounting
document is as below is then standard for the last installement.
Dr. AR 60
Cr. Sales 60

This alternative provides a cleaner option with the Downpayment.

Payment term - Installment Payment

1. OBB8：setup Payment Terms
2.OBB9：Setup Installment Payment in IMG

The system will create a single billing document with different due dates based upon how you defined the installments in OBB9.

For instance, you create the following

payment term z001 - net 30 days
payment term z002 - net 60 days
Installment payment term Z2 - Two equal installments.

In OBB9, you assign the following to Z2:

Installment % Payment Term
1 50 Z001
2 50 Z002

When you invoice, the system created a single billing document, but when it posts to accounting, it splits the document with 50% due in 30 days and 50% due in 60 days.

http://blog.csdn.net/mysingle/archive/2007/11/22/1898100.aspx

SAP Payment Terms 中文翻译为 收付款条件， 他的用途是应收和应付的财务凭证中帐期的管理，顾名思义即手动录入和自动生成的财务文档多少天内未冲销处理则为正常，否则为超期应收应付财务文档！他包含 的内容是：帐期计算基准日（开始计算过期日的日期），帐期到期日（未过期的最晚日期）或者到期周期天数（基准日+周期天数即为最晚未过期日），同时SAP 系统还引申扩充应用为分期付款阶段日期管理，提前付款付款折扣管理。

我们以SD中Billing结算系统即产生财务应收文档为例来说明

过期基准日Baseline Date的业务需求

1. 结算日即开始为过期计算日，向后90天内客户付款都为正常，超过则为超期

2. 不论我当月哪天结算，过期日都为本月的月末开始计算，90天内客户付款都为正常，超过则为超期

3. 当月我1号～20号结算，过期日为当月的月末，21号～月末结算则过期日为下个月的月末

过期天数Due Days的业务需求

1. 基准日选定后，向后90天内客户付款都为正常，超过则为超期

2. 基准日选定后，基准日后的下月10号前客户付款都为正常，超过则为超期

分期付款Installment 和提前日期付款折扣DIscount业务需求

1. 系统3次分期付款，3次的付款基准日和过期天数分别管理

2. 系统3次提前日期付款折扣率，各世界阶段设置折扣率

请大家开下面的演示 ,有不明白的地方给我留言吧！

SD订单退货流程

步骤如下：
1）VA01，创建退货单据，单据类型RE。由于 们的产品采用batch管理，所以 们的人为规定 是：所有退货单据必须“参照billing单据创建”；
2）VL01，创建退货交货单，之后以VL02过账收货；
3）退回的货物将回到MRP的库存需求表中（MD04），处于退货库存状态（用MMBE可以看到），检 验批次用QE51可以看到。当然，如果根本就没有实施QM的话，QE51可以省略，但货物仍然处于退 货库存状态；
4）开具贷记备忘凭证（VF01），QM检测的结果记录以QE01完成；
5）退回货物若不需要QM处理，直接移到相应的库存（453移到非限制、459移到冻结），事务代码 MB1B。在QM介入的情况下， 们得用QA11做使用决策，合格品453、不合格品459，代码MB1B。殊 途同归。
6）退回货物的后续处理只有两种情况：要么买主要求 们换货（replace），要么买主要求 们 退款（refund）。前一种情况下，参照return单据创建新的标准订单然后备货发运开票即可；至 于后一种情况，如果提前收了买主的钱则经FI模块退回，要是没有提前收款也必须冲销销售收入 （即所谓的“红字发票”），这样第4）步的贷记备忘凭证就有存在的理由了。