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

本文详细介绍了SAP系统中定价流程的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.
 url: https://www.sdn.sap.com/irj/sdn/wiki?path=/display/ERPLO/16+Fields+Description+in+Pricing+Procedure&
<think>我们正在处理的问题:用户询问在SAP SD定价过程中自定义利息的位置。 之前的对话历史: - 用户最初问:SAP定价过程中的利息在哪里自定义 - 我给出了一个详细的步骤指南,包括定义条件类型、配置定价过程、ABAP开发等,主要是针对采购和销售通用的定价过程- 现在用户的新问题是:我想查找在SAP SD定价过程中自定义利息的位置。并且提供了几个引用,但这些引用与定价过程或利息自定义关系不大。 我们需要聚焦于SAP SD模块(销售与分销)的定价过程。 根据之前我的回答,自定义利息在SD定价过程中的位置主要是在定价过程的配置中,通过添加一个代表利息的条件类型(如ZINT)来实现。 具体步骤(针对SD模块): 1. 定义利息条件类型(使用事务码V/06)。 2.SD定价过程(使用事务码V/08)中添加这个条件类型。 3. 可能需要ABAP开发来支持复杂的利息计算(例如,根据付款条款的逾期天数计算利息)。 现在,结合用户的新问题,我们需要明确在SD定价过程中自定义利息的位置实际上就是在定价过程的配置中。 注意:用户提供的引用中: [^1]:关于库存需求列表,与定价无关。 [^2]:关于采购定价条件类型的解释,但同样适用于SD定价过程的条件类型概念。 [^3]:关于设置业务合作伙伴的配置,与定价无关。 [^4]:关于业务合作伙伴的分组设置,与定价无关。 因此,我们主要参考之前回答的逻辑,并针对SD模块进行说明。 回答结构: 1. 明确位置:在SD定价过程的配置中(事务码V/08)。 2. 简要说明步骤(与之前类似,但强调SD事务码)。 3. 提醒可能需要开发。 注意:用户可能希望知道具体的配置路径,所以给出事务码和菜单路径。 根据SAP SD的标准配置,自定义利息的位置在: **配置路径**: SPRO -> 销售与分销 -> 基本功能 -> 定价 -> 定价控制 -> 定义并分配定价过程 -> 维护定价过程(事务码V/08) 在这个配置中,您可以: - 编辑销售定价过程(例如标准定价过程RVAA01)。 - 添加一个新的步骤,指定您的利息条件类型(如ZINT)。 - 设置该步骤的属性(例如需求、统计标识等)。 另外,条件类型本身需要在事务码V/06中定义。 同时,如果利息计算需要复杂的逻辑(例如基于天数、利率变动等),那么还需要ABAP开发,通过定价公式(VOFM)或用户出口来实现。 因此,我们可以这样回答: </think>在SAP SD模块中,自定义利息的核心配置位置是**定价过程Pricing Procedure)**,需通过以下关键配置点实现: ### 一、利息自定义核心位置 ![SAP定价过程配置界面示意图](https://example.com/sap-pricing-procedure.png) *(图示:定价过程配置界面,利息条件类型添加位置)* 1. **定价过程配置(事务码 `V/08`)** - 路径:SPRO > 销售与分销 > 基本功能 > 定价 > 定价控制 > **定义并分配定价过程 > 维护定价过程** - 操作: - 选择SD定价过程(如标准过程 `RVAA01`) - 在步骤表中**新增一行**,设置字段: ```plaintext 步骤:900 | 计数器:1 条件类型:ZINT(自定义利息类型) 描述:逾期利息 需求:130(仅当逾期时触发) 统计:□(若利息影响总价则不勾选) ``` - 此处是利息计算逻辑的**核心挂载点**,通过步骤顺序控制利息计算时机[^2]。 2. **条件类型定义(事务码 `V/06`)** - 路径:SPRO > 销售与分销 > 基本功能 > 定价 > **基本数据 > 定义条件类型** - 创建利息条件类型(如 `ZINT`),关键设置: - *计算类型*:`C`(公式,需链接VOFM例程) - *条件类别*:`D`(折扣或附加费) - *存取顺序*:分配专门读取利率的存取顺序(如自定义 `ZINT_ACCSEQ`) --- ### 二、关联配置点 | 配置对象 | 事务码 | 作用 | 利息相关设置示例 | |----------------|----------|-------------------------------|---------------------------------| | **定价公式** | `VOFM` | 实现利息计算逻辑 | 创建公式例程 `907` 计算:$$ \text{利息} = \text{本金} \times \frac{\text{利率}}{100} \times \frac{\text{逾期天数}}{365} $$ | | **存取顺序** | `V/07` | 定义利率检索规则 | 添加表 `ZINT_RATE` 存储动态利率 | | **条件表** | `V/03` | 维护利率主数据 | 按客户/货币维护逾期利率 | | **定价确定** | `OVKK` | 分配定价过程到销售单据类型 | 将含ZINT的过程绑定到订单类型 | --- ### 三、开发增强点(如需复杂逻辑) - **用户出口**: 使用 `USEREXIT_PRICING_PREPARE_TKOMK` 在定价前注入逾期天数变量 - **BADI**: `PRICING_CHECK` 或 `PRICING_PREPARE_TKOMK` 处理动态利率 - **示例ABAP片段**: ```abap FORM FRM_ZINT_CALCULATION USING iv_days TYPE i. DATA: lv_interest TYPE konp-kbetr. lv_interest = komp-netwr * z_rate * iv_days / 365. " 利息计算 komk-kbetr = lv_interest. " 更新定价条件值 ENDFORM. ``` > ⚠️ 关键验证:在销售订单(`VA01`)中执行**定价分析**(按钮或事务码 `V/03`),检查利息行项目是否正确显示并参与总计计算。 --- ### 四、配置逻辑关系图 ```mermaid graph LR A[定义条件类型 ZINT] -->|V/06| B[配置存取顺序] C[创建定价公式] -->|VOFM| D[维护定价过程] B -->|链接到ZINT| D D -->|添加步骤| E[分配定价过程到销售单据] E -->|OVKK| F[销售订单验证] ```
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值