计划行类别.
计划行类别的例子Schedule Line categories
系统交付了不同schedule line categories来为Item在销售流程中提供不同的控制选项;
schedule line categories 定义为2位的key,标准系统已经包含了经常用来指示Item category用途的key:
第一位指示schedule line categories用在哪些销售流程中:
A = Inquiry
B = Quotation
C = Order
D = Returns
第二位指示schedule line categories在物流模块中发生什么:
T = No inventory management
X = No inventory management with goods issue
N = No materials planning
P = Material requirements planning
V = Consumption-based planning
Eg. :
Pre-sale
AT=Inquiry schedule line;
BN=Schedule line in Quotation without MRP;
Outline Agreement
CV=Scheduling Agreement with deterministic MRP;
Sale phase
CP=Order schedule line with MRP;
CO=Consignment issue without availability check;
Complaint
DN=Schedule line in returns without MRP;
DO=consignment returns;
计划行类别Schedule Line categories
计划行包含交货日期/数量以及需求传递和库存管理的信息,这些是交付的先决条件
在item category的配置中,定义了是否允许item有计划行;你可以为每个item category 分配Schedule Line categories;
通过定义Schedule Line category,判定哪些计划行实际与交货有关;如果要实际交货,需要激活relevant to delivery indicator;
在计划行类别中,通过设置移动类型movement type来控制哪些数据和价值的改变会Post到库存科目;库存管理负责维护移动类型;
标准系统中的所有process都定义了移动类型;与SD相关的大部分移动类型在601与699之间;
可以在计划行层关闭需求传递和可用性检查;
采购订单的先决条件是PR,PR可以自动从销售凭证产生;要做到这一点,需要需要配置采购订单的类型,以及item和account assignment category;
如果你为Schedule Line category激活了delivery block,则block会自动地设置在销售凭证的schedule line层;
计划行类别的重要参数:
Goods movements;
Delivery relevance;
Purchasing;
Availability Check;
Requirements Transfer;
Assigning basic functions;
控制销售凭证中的计划行Controlling Schedule lines in Sales Documents
BN: Quotation中的Schedule line与delivery无关,需求传递未激活,不需要移动类型;
CP: 在销售凭证中产生Delivery项目,因此‘relevant to delivery indicator’是激活的;
需求传递是激活的,完整地定义需求传递需要先定义和分配需求类requirements class;
货物移动类型是601,对于这个移动类型,当Delivery做了Post goods issue后,Ship的数量从非限制性库存中减掉;
DN: 如果需要一个returns delivery来跟踪一个return order,就需要一个与delivery相关的Schedule line category;
在这个case中,需求传递是不需要的;移动类型651保证返回的货物Goods receipt 移动到Block的返回品仓库blocked stock returns;
分配计划行类别到行项目类别Assigning Schedule line categories to item categories:
分配的目的:
配置系统以在生成订单的时候自动带出计划行类别;
设定用户可以选择来替代系统自动带出的计划行类别的范围;
分配受物料主记录中的MRP Type影响;
系统执行2步来决定自动决定Schedule line categories:
首先尝试使用Item category和MRP Type的组合来决定;
如果没找到,则使用Item category和no MRP Type来搜索;
数据流(Data Flow)
根据参考创建Create with reference
可以参考之前的凭证来创建销售凭证,可以在初始画面,也可以在凭证处理过程中,通过uniform. dialog box来控制,该对话框有6个标签页:
Inquiry‚ Quotation, Order, Contract, Scheduling agreement, Billing document;
在对话框中输入凭证号之后,可以选择COPY,将完全复制参考凭证;也可以选择Item Selection来COPY一部分项目以及修改数量;
在处理中,可以为新的凭证定义一个新的delivery date,此日期设置在头部,对凭证中的所有行项目有效;
要用参考创建,首先需要配置相应的Copy Control,必须要是符合逻辑的业务处理流程;
凭证流Document Flow
销售流程由一系列有顺序的记录为凭证的process steps组成,该流程链存储在凭证流中;
凭证流为所有的凭证和个别项目更新;
可以通过一个列表来查看凭证流中的所有凭证;
在状态浏览图中,可以快速的查找到有关销售流程的目前状态的详细信息;
Eg. : Document flow of quotation
Quotation
.Order
..Delivery
…Invoice
..Returns
…Returns delivery
….Returns credit memo
SD中的复制控制Copying Control in SD
在Copying control中,可以决定哪些凭证类型可以Copy到其他的凭证类型,并定义详细的Copying方法;
Eg. :
Sales document type from a sales doc. Type:Standard order(OR)
Sales document type from a billing doc.type:Credit memo request(G2)
Delivery type from a sales document type:Delivery (DL)
Billing doc. type from a sales doc.Type:Credit memo(G2)
Billing document type from a delivery type e.g. Invoice (F1)
Billing doc. type from a billing doc.type e.g. Invoice cancellation(S1)
销售凭证的Copying Control
可以为Header,Item,Schedule line层设置Copying Control(要符合销售凭证的结构),每层你需要创建:
Data transfer routines:控制Fields如何Copy;
Copying requirements:需要满足的条件Check;
Switches:可为每个事务设置特殊控制,例如可激活或关闭item numbers的transfer
如果你在Item和Schedule line层输入了无效值或不输入target value,系统根据Item和Schedule line Category assignment来判定target;
Copying条件Copying requirements
Copying requirements包含为每个业务处理定义的特殊条件,并且可以存储在所有层次;当所有条件都满足时,参考凭证才会被创建;
Eg. :
Header level:001—Check sounce和target的Sold-to party和Sales area是否相同;
Item level:301—Check 将要用来Copy的Item是否有reject的原因或者完成状态;
Schedule line level:501—保证只有open Quantity大于0的部分会Copy;
MARK:Routines和Requirements是用ABAP/4代码写的,且能够通过修改系统的方式在SD配置中进行处理,
你首先应该检查系统中现有的对象是否有合适的,通常可以通过Copy标准系统的对象,
然后删除或者增加代码行到对象来快速的调整系统;
Completion Rule and reference status
当使用‘Create With Reference’时,通常需要更新reference的数量或值,所以需要在Copying Control中Check Item层的‘Document flow update’Field;
在item category中设置适当的Completion rule,根据Item Category中的Completion rule,之前凭证的Item的状态会独立地更新;
合同contracts中的Items没有Completion Rule;
如果你输入了Rejection的原因,Item会变成‘Compelte’;
定价基础(Pricing Fundamentals)
条件组Groups of Conditions
定价Pricing;
折扣/附加费Discounts/surcharges;
运费Freight;
税Taxes;
有关条件的数据存储在条件记录中;
你可以根据需要在任何层次决定条件;
定价最通常执行的层次已经在标准系统中预定义了;
你能够非常容易地添加额外的层次;
系统提供了一个包含定价常用Fields的standard field catalog,然而你可以设置条件依赖于凭证中的任意Field,
但是你需要将这些Fields添加到field catalog中;
条件记录Condition Records
可以为定价协议定义一个有效期;
条件记录中的值(price、surcharge、discount)可以维护为一个刻度,刻度的层次数量不限;
可以为条件记录设置上限和下限,手动修改系统确定的价格要素只能在这个限制内;
条件类型Condition Type
条件类型确定Condition的类别和如何使用;
可为每个条件类型设置calculation type和scale base type;
EG..:scale base type:Percentage
calculation type:Value scale
100¥ 1-%
1000¥ 2-%
10000¥ 3-%
scale base type:Weight scale
calculation type:Amount/weight
100kg $1- per 1 kg
1000kg $3-
10000kg $5-
条件维护Condition maintenance
4.6A版本之后提供了新的维护接口,新接口允许批量维护(based on characteristics);
condition records can now be maintained across all condition types and condition tables;
例如可以一步显示和维护客户的Material Prices以及Discounts,surcharges等;
也可以选择Select using condition type来调用老的条件维护事务代码;
定价中的条件技术(Condition Technique in Pricing)
定价程序Pricing Procedure
所有定价中允许的条件类型都包含在定价程序中;
通过为每个条件定义requirements来决定系统将如何使用条件;
业务凭证中系统访问条件的次序也在这里确定;
参考层次Reference level提供一方法来为条件类型计算定义不同的basis以及将条件分组求和;
定价程序能够包含介于Gross和Net price之间任意数量的分组求和;
可以在定价程序中将一个条件类型定义为:
强制条件mandatory condition;
手动输入条件manually entered condition;
仅作统计用;
访问次序Access Sequence
在定价程序中,除了header and manual only condition types外,
每个condition type都定义了一个访问次序(搜索策略);
搜索策略定义了系统为condition type读取condition record的顺序;
访问顺序中每个访问通过使用condition table来执行;
条件表condition table是条件记录的key fields的集合;
可以执行一个依赖于某些先决条件访问;
定价预览Pricing Overview
Eg. 订单创建—120PCs of a material,系统需自动决定price;
首先,相关的定价程序确定(基于销售区域,客户和销售凭证类型);
然后,系统读取第一步中的条件类型,判定该条件类型指定的access sequence;
其次,系统读取access sequence,条件表的次序显示了寻找相关condition record的搜索策略;
每个条件表描述一组可作为key生成条件记录的一次访问;
再次,系统使用条件表中定义的key搜索有效的条件记录,如果第一次访问没有找到有效的条件记录,
则系统使用下一个条件表搜索下一个access;
最后,当系统为某次访问找到有效的条件记录,则读取条件记录并Copy符合刻度的值到销售凭证中;
整个流程需要为每个condition type执行一遍直到系统完成整个定价程序;
排斥条件Excluding conditions
在定价程序中,条件condition能够链接到requirements;
Requirements能够检查condition exclusion indicator,如果设置,则忽略该condition;
Condition exclusion indicator可以设置在condition type或者condition record;
凭证中手动修改价格Changing Price Manually in Documents
在条件记录中,你可以定义手动修改的限制范围;
除了自动确定,在销售凭证中也可手动输入condition,它们会标记为已经手动输入;
也可以通过配置,禁止手动修改某个condition type;
凭证头部的条件Conditions in the Document Header
也可以在凭证头部输入conditions,叫做header conditions,对所有的Items有效;
这些header conditions自动地基于net value分布到Items;
分布header condition的基础可在定价程序中通过在ALTCBV field中选择适当的routine来修改;
新定价和定价类型New Pricing and Pricing Types
你可以在Pricing type中配置pricing的行为;
从4.5版本以后,会有2种选项来控制销售凭证中的新定价功能;
Update prices 在condition screen,对header和item层都可用;
New pricing document 将定价类型分配到定价程序,默认为B(执行新定价);
这些功能支持销售凭证和billing凭证;
定价类型Pricing type:
A copy pricing elements and update scales
B carry out new pricing
C copy manual pricing elements
G redetermine taxes
H redeterming freight conditions
X、Y reserved for customer
1-9 reserved for customer
Bill Document中的定价Pricing in the billing Document
在Outbound delivery 到Billing document的每个item的coping control中判定pricing type;
定价配置(Pricing Configuration)
定价配置预览1 Overview:pricing configuration1
条件表condition table 包含可用来创建相应条件记录的keys
Eg1.:condition table :Material; customer/material;
可以添加自定义的条件表,号码范围501---999;
条件表Condition Tables
条件记录通常用特定的key创建,用table来帮组定义condition record keys;
用在header和Item层定价的最重要的fields在标准系统里已经可用;
从4.5版本开始,也可以添加non-key fields到条件表,例如condition table144(用于价格目录,condition type PBUD);
条件表的key fields必须位于table的开头;
定价配置预览2 Overview:pricing configuration2
Access sequence 由一个或多个条件表组成;
创建访问次序Creating an Access Sequence
你可以在不同的层次定义价格,折扣和额外费用,每个层次可由条件表中的fields组合或一个field定义;使用access sequence,能够定义不同层次的次序;系统尝试按定义的sequence来确定condition records;
为访问次序确定源字段Determining Source Fields for Access Sequences
对于access sequence中的每个access,你可以定义access执行所需的特定的凭证字段(source fields);
例如:
Material or pricing material;
Document currency or Local currency;
Sold-to party or Ship-to party;
访问先决条件Access Requirements
设置access依赖于requirements可避免不必要的access,这样减轻系统负荷;
定价配置预览3 Overview:pricing configuration3
创建access sequence之后,被分配给condition type;
可创建自定义的condition types,为每个condition type确定特征,例如,是用于surcharges还是discounts以及是应该依赖于values还是quantities;
定价配置预览4 Overview:pricing configuration4
Condition types 按照需要的顺序组合到pricing procedure中;
定价配置预览5 Overview:pricing configuration5
最后,你需要为定价程序维护procedure determination table;pricing procedure 根据一下内容确定:
销售区域Sales area
客户主记录中‘Customer pricing procedure’field
销售凭证类型的‘Document pricing procedure’field
为定价添加新的字段Adding New Fields for Pricing
所有用来创建条件表的字段都必须包含在各自的字段目录中;可以向字段目录中添加新的字段;
实施定价策略1Implementing Your Own Pricing Strategies1
满足特定的定价需求可能需要1个或多个新定价组件,理解每个组件的目的和能力,以及定价组件之间的关系是关键的;
解决特定的问题需要创造性地构建和结合所有的定价组件:
条件表condition table:定义条件记录的关键字;
访问次序Access sequence:包含访问条件记录的层次;
条件类型Condition type:描绘定价条件的属性;
定价程序Pricing procedure:定义条件类型是怎样联系在一起的;
程序确定Procedure determination:选择正确的定价程序;
实施定价策略2 Implementing Your Own Pricing Strategies2
下面的元素对于实施复杂的情景可能是必要的:
为定价添加新的字段 adding new fields for pricing –为了符合所有客户的需要;
必要条件Requirements—定义依赖条件和改善性能;
公式Formulas—扩展标准配置的限制;
Requirement routines and formulas 提供了修改标准定价逻辑的方法来满足独特的用户需求;
使用条件记录(Working with Condition Records)
定价报表—客户特定价格Pricing Reports-customer-specific prices
为了浏览存在的条件记录,可以生成一张条件分析列表,你可能会问这些问题:
在某一时期内,制定了什么样的客户特定价格协议?
系统中存贮了什么样的Incoterm condition?
等级价格创建了什么样的price list?
List的格式布局和在报表上显示哪些条件记录在配置中设置;
定价报表—表Pricing Reports-Tables
在为定价报表创建新的程序时,你首先要决定要在哪些View中分析条件记录,可通过从存在的条件表中选择特定的fields来实现;
依赖于选中的Fields,系统会生成tables列表,每个表至少包含一个选中的field,从这个tables列表选择哪些特定的tables出现在报表上;
列表的布局通过放置和排序出现在3个report sections的某一个中的选中的table中的fields来定义:
Page header--a page break occurs when a value changes;
Group header - a new line heading is generated for each table analyzed
Items-detailed record information
用定价报表维护条件1 Maintaining Conditions Using Pricing Reports1
条件维护已经提供了一个新的维护接口;允许批量维护;
用定价报表维护条件2 Maintaining Conditions Using Pricing Reports2
新条件维护function能够用area menus来配置;标准的condition maintenance area menu 是COND_AV;
自定义的area menu可通过选择菜单项Environmentàassignment area menu来指派;
自定义area menu可使用SE43来创建,例如Copy COND_AV,然后调整以满足特定需求;
用参考创建条件记录Creating Condition Records with Reference
新的条件记录可参考已有的条件记录创建,在处理过程中,可以修改新建记录的rate、validity period,以及additional sales data;
这个function提供了一个有效的方法来同步更新条件记录;
修改条件记录Change Condition Records
个别的条件记录能够手动地维护;价格修改功能(price change function)允许你同时维护多条条件记录;
用change documents来回顾和监控对condition records的修改;
复制条件记录Copying Condition Records
可通过Copy已存在的条件记录来创建多个条件记录,在Copying时,可以选择copying rule,copying rule在配置中维护,也可以自己创建;
净价列表Net Price List
净价列表提供了为客户创建基于选定数量物料的价格信息;净价通过模拟billing document来确定;ABAP list viewwe是创建用户定义display variants的简单方式,VBRP table中的所有字段都可用于此目的;
Sales area + Customer + Material + Plant + Pricing date/Order type 来模拟;
条件索引Condition Index
可以创建和使用条件索引来搜索为多个条件类型和条件表创建的条件记录;例如,需要查看应用于某一客户或产品的所有条件记录;
激活功能(activation function)显示了所有可用的条件索引的列表并标示哪些是激活的,系统只能使用已激活的条件索引;
在使用标准系统交付的index之前,你首先需要在配置中激活;
然而,如果你创建了自己的indexs,在generate的时候,系统会自动激活每个新的index,另外,你必须为每个条件索引指定update requirement;
你可以为每个condition type指定当你Post condition records for the corresponding condition type时系统是否更新条件index;
为条件发布程序Release Procedure for Conditions
当一个条件表被创建,你能够允许a release procedure to be used,通过选中‘With release status’复选框;这样会自动添加以下2个fields到条件表中:
KFRST release status作为最后一个key field;
KBSTAT Processing status作为一个可变数据部分的一个field,不是key;
Release status是预定义的,目前下列statuses已经定义:
Released
Blocked
released for price simulation (net price list)
released for planning and price simulation (planning in CO-PA)
release status通过在定价配置中定义processing status并分配一个release status给他来间接地设置;
Business Transaction Event 00503303 Maintain Conditions: Transfers 可用来为processing status定义个别的processing logic;
你也可以将老的没有release indicators的条件记录转换为新的有release indicators的条件记录,系统提供了一个model来完成此目的;
可变计算类型Changeable Calculation Types
Condition type的calculation type在配置中定义,calculation type确定condition的价格或者折扣以及额外费用如何计算;
在4.6版本以前,该标记(Condition type)直接copy到条件记录中,现在的版本创建新的条件记录时,可以选择不同于配置中设置的calculation type;
条件记录中的长文本Long Texts in Condition Types
可以在pricing和agreement的条件记录中维护长文本(rebates,sales deals,and promotions),这些文本提供以下信息:
Create condition records创建条件记录;
Approvals 审批;
Invalidity 无效;
如果需要,rebate agreement长文本能够copy到凭证中,例如,到credit memo request for rebate payments and from there to rebate credit memo);
计划行类别的例子Schedule Line categories
系统交付了不同schedule line categories来为Item在销售流程中提供不同的控制选项;
schedule line categories 定义为2位的key,标准系统已经包含了经常用来指示Item category用途的key:
第一位指示schedule line categories用在哪些销售流程中:
A = Inquiry
B = Quotation
C = Order
D = Returns
第二位指示schedule line categories在物流模块中发生什么:
T = No inventory management
X = No inventory management with goods issue
N = No materials planning
P = Material requirements planning
V = Consumption-based planning
Eg. :
Pre-sale
AT=Inquiry schedule line;
BN=Schedule line in Quotation without MRP;
Outline Agreement
CV=Scheduling Agreement with deterministic MRP;
Sale phase
CP=Order schedule line with MRP;
CO=Consignment issue without availability check;
Complaint
DN=Schedule line in returns without MRP;
DO=consignment returns;
计划行类别Schedule Line categories
计划行包含交货日期/数量以及需求传递和库存管理的信息,这些是交付的先决条件
在item category的配置中,定义了是否允许item有计划行;你可以为每个item category 分配Schedule Line categories;
通过定义Schedule Line category,判定哪些计划行实际与交货有关;如果要实际交货,需要激活relevant to delivery indicator;
在计划行类别中,通过设置移动类型movement type来控制哪些数据和价值的改变会Post到库存科目;库存管理负责维护移动类型;
标准系统中的所有process都定义了移动类型;与SD相关的大部分移动类型在601与699之间;
可以在计划行层关闭需求传递和可用性检查;
采购订单的先决条件是PR,PR可以自动从销售凭证产生;要做到这一点,需要需要配置采购订单的类型,以及item和account assignment category;
如果你为Schedule Line category激活了delivery block,则block会自动地设置在销售凭证的schedule line层;
计划行类别的重要参数:
Goods movements;
Delivery relevance;
Purchasing;
Availability Check;
Requirements Transfer;
Assigning basic functions;
控制销售凭证中的计划行Controlling Schedule lines in Sales Documents
BN: Quotation中的Schedule line与delivery无关,需求传递未激活,不需要移动类型;
CP: 在销售凭证中产生Delivery项目,因此‘relevant to delivery indicator’是激活的;
需求传递是激活的,完整地定义需求传递需要先定义和分配需求类requirements class;
货物移动类型是601,对于这个移动类型,当Delivery做了Post goods issue后,Ship的数量从非限制性库存中减掉;
DN: 如果需要一个returns delivery来跟踪一个return order,就需要一个与delivery相关的Schedule line category;
在这个case中,需求传递是不需要的;移动类型651保证返回的货物Goods receipt 移动到Block的返回品仓库blocked stock returns;
分配计划行类别到行项目类别Assigning Schedule line categories to item categories:
分配的目的:
配置系统以在生成订单的时候自动带出计划行类别;
设定用户可以选择来替代系统自动带出的计划行类别的范围;
分配受物料主记录中的MRP Type影响;
系统执行2步来决定自动决定Schedule line categories:
首先尝试使用Item category和MRP Type的组合来决定;
如果没找到,则使用Item category和no MRP Type来搜索;
数据流(Data Flow)
根据参考创建Create with reference
可以参考之前的凭证来创建销售凭证,可以在初始画面,也可以在凭证处理过程中,通过uniform. dialog box来控制,该对话框有6个标签页:
Inquiry‚ Quotation, Order, Contract, Scheduling agreement, Billing document;
在对话框中输入凭证号之后,可以选择COPY,将完全复制参考凭证;也可以选择Item Selection来COPY一部分项目以及修改数量;
在处理中,可以为新的凭证定义一个新的delivery date,此日期设置在头部,对凭证中的所有行项目有效;
要用参考创建,首先需要配置相应的Copy Control,必须要是符合逻辑的业务处理流程;
凭证流Document Flow
销售流程由一系列有顺序的记录为凭证的process steps组成,该流程链存储在凭证流中;
凭证流为所有的凭证和个别项目更新;
可以通过一个列表来查看凭证流中的所有凭证;
在状态浏览图中,可以快速的查找到有关销售流程的目前状态的详细信息;
Eg. : Document flow of quotation
Quotation
.Order
..Delivery
…Invoice
..Returns
…Returns delivery
….Returns credit memo
SD中的复制控制Copying Control in SD
在Copying control中,可以决定哪些凭证类型可以Copy到其他的凭证类型,并定义详细的Copying方法;
Eg. :
Sales document type from a sales doc. Type:Standard order(OR)
Sales document type from a billing doc.type:Credit memo request(G2)
Delivery type from a sales document type:Delivery (DL)
Billing doc. type from a sales doc.Type:Credit memo(G2)
Billing document type from a delivery type e.g. Invoice (F1)
Billing doc. type from a billing doc.type e.g. Invoice cancellation(S1)
销售凭证的Copying Control
可以为Header,Item,Schedule line层设置Copying Control(要符合销售凭证的结构),每层你需要创建:
Data transfer routines:控制Fields如何Copy;
Copying requirements:需要满足的条件Check;
Switches:可为每个事务设置特殊控制,例如可激活或关闭item numbers的transfer
如果你在Item和Schedule line层输入了无效值或不输入target value,系统根据Item和Schedule line Category assignment来判定target;
Copying条件Copying requirements
Copying requirements包含为每个业务处理定义的特殊条件,并且可以存储在所有层次;当所有条件都满足时,参考凭证才会被创建;
Eg. :
Header level:001—Check sounce和target的Sold-to party和Sales area是否相同;
Item level:301—Check 将要用来Copy的Item是否有reject的原因或者完成状态;
Schedule line level:501—保证只有open Quantity大于0的部分会Copy;
MARK:Routines和Requirements是用ABAP/4代码写的,且能够通过修改系统的方式在SD配置中进行处理,
你首先应该检查系统中现有的对象是否有合适的,通常可以通过Copy标准系统的对象,
然后删除或者增加代码行到对象来快速的调整系统;
Completion Rule and reference status
当使用‘Create With Reference’时,通常需要更新reference的数量或值,所以需要在Copying Control中Check Item层的‘Document flow update’Field;
在item category中设置适当的Completion rule,根据Item Category中的Completion rule,之前凭证的Item的状态会独立地更新;
合同contracts中的Items没有Completion Rule;
如果你输入了Rejection的原因,Item会变成‘Compelte’;
定价基础(Pricing Fundamentals)
条件组Groups of Conditions
定价Pricing;
折扣/附加费Discounts/surcharges;
运费Freight;
税Taxes;
有关条件的数据存储在条件记录中;
你可以根据需要在任何层次决定条件;
定价最通常执行的层次已经在标准系统中预定义了;
你能够非常容易地添加额外的层次;
系统提供了一个包含定价常用Fields的standard field catalog,然而你可以设置条件依赖于凭证中的任意Field,
但是你需要将这些Fields添加到field catalog中;
条件记录Condition Records
可以为定价协议定义一个有效期;
条件记录中的值(price、surcharge、discount)可以维护为一个刻度,刻度的层次数量不限;
可以为条件记录设置上限和下限,手动修改系统确定的价格要素只能在这个限制内;
条件类型Condition Type
条件类型确定Condition的类别和如何使用;
可为每个条件类型设置calculation type和scale base type;
EG..:scale base type:Percentage
calculation type:Value scale
100¥ 1-%
1000¥ 2-%
10000¥ 3-%
scale base type:Weight scale
calculation type:Amount/weight
100kg $1- per 1 kg
1000kg $3-
10000kg $5-
条件维护Condition maintenance
4.6A版本之后提供了新的维护接口,新接口允许批量维护(based on characteristics);
condition records can now be maintained across all condition types and condition tables;
例如可以一步显示和维护客户的Material Prices以及Discounts,surcharges等;
也可以选择Select using condition type来调用老的条件维护事务代码;
定价中的条件技术(Condition Technique in Pricing)
定价程序Pricing Procedure
所有定价中允许的条件类型都包含在定价程序中;
通过为每个条件定义requirements来决定系统将如何使用条件;
业务凭证中系统访问条件的次序也在这里确定;
参考层次Reference level提供一方法来为条件类型计算定义不同的basis以及将条件分组求和;
定价程序能够包含介于Gross和Net price之间任意数量的分组求和;
可以在定价程序中将一个条件类型定义为:
强制条件mandatory condition;
手动输入条件manually entered condition;
仅作统计用;
访问次序Access Sequence
在定价程序中,除了header and manual only condition types外,
每个condition type都定义了一个访问次序(搜索策略);
搜索策略定义了系统为condition type读取condition record的顺序;
访问顺序中每个访问通过使用condition table来执行;
条件表condition table是条件记录的key fields的集合;
可以执行一个依赖于某些先决条件访问;
定价预览Pricing Overview
Eg. 订单创建—120PCs of a material,系统需自动决定price;
首先,相关的定价程序确定(基于销售区域,客户和销售凭证类型);
然后,系统读取第一步中的条件类型,判定该条件类型指定的access sequence;
其次,系统读取access sequence,条件表的次序显示了寻找相关condition record的搜索策略;
每个条件表描述一组可作为key生成条件记录的一次访问;
再次,系统使用条件表中定义的key搜索有效的条件记录,如果第一次访问没有找到有效的条件记录,
则系统使用下一个条件表搜索下一个access;
最后,当系统为某次访问找到有效的条件记录,则读取条件记录并Copy符合刻度的值到销售凭证中;
整个流程需要为每个condition type执行一遍直到系统完成整个定价程序;
排斥条件Excluding conditions
在定价程序中,条件condition能够链接到requirements;
Requirements能够检查condition exclusion indicator,如果设置,则忽略该condition;
Condition exclusion indicator可以设置在condition type或者condition record;
凭证中手动修改价格Changing Price Manually in Documents
在条件记录中,你可以定义手动修改的限制范围;
除了自动确定,在销售凭证中也可手动输入condition,它们会标记为已经手动输入;
也可以通过配置,禁止手动修改某个condition type;
凭证头部的条件Conditions in the Document Header
也可以在凭证头部输入conditions,叫做header conditions,对所有的Items有效;
这些header conditions自动地基于net value分布到Items;
分布header condition的基础可在定价程序中通过在ALTCBV field中选择适当的routine来修改;
新定价和定价类型New Pricing and Pricing Types
你可以在Pricing type中配置pricing的行为;
从4.5版本以后,会有2种选项来控制销售凭证中的新定价功能;
Update prices 在condition screen,对header和item层都可用;
New pricing document 将定价类型分配到定价程序,默认为B(执行新定价);
这些功能支持销售凭证和billing凭证;
定价类型Pricing type:
A copy pricing elements and update scales
B carry out new pricing
C copy manual pricing elements
G redetermine taxes
H redeterming freight conditions
X、Y reserved for customer
1-9 reserved for customer
Bill Document中的定价Pricing in the billing Document
在Outbound delivery 到Billing document的每个item的coping control中判定pricing type;
定价配置(Pricing Configuration)
定价配置预览1 Overview:pricing configuration1
条件表condition table 包含可用来创建相应条件记录的keys
Eg1.:condition table :Material; customer/material;
可以添加自定义的条件表,号码范围501---999;
条件表Condition Tables
条件记录通常用特定的key创建,用table来帮组定义condition record keys;
用在header和Item层定价的最重要的fields在标准系统里已经可用;
从4.5版本开始,也可以添加non-key fields到条件表,例如condition table144(用于价格目录,condition type PBUD);
条件表的key fields必须位于table的开头;
定价配置预览2 Overview:pricing configuration2
Access sequence 由一个或多个条件表组成;
创建访问次序Creating an Access Sequence
你可以在不同的层次定义价格,折扣和额外费用,每个层次可由条件表中的fields组合或一个field定义;使用access sequence,能够定义不同层次的次序;系统尝试按定义的sequence来确定condition records;
为访问次序确定源字段Determining Source Fields for Access Sequences
对于access sequence中的每个access,你可以定义access执行所需的特定的凭证字段(source fields);
例如:
Material or pricing material;
Document currency or Local currency;
Sold-to party or Ship-to party;
访问先决条件Access Requirements
设置access依赖于requirements可避免不必要的access,这样减轻系统负荷;
定价配置预览3 Overview:pricing configuration3
创建access sequence之后,被分配给condition type;
可创建自定义的condition types,为每个condition type确定特征,例如,是用于surcharges还是discounts以及是应该依赖于values还是quantities;
定价配置预览4 Overview:pricing configuration4
Condition types 按照需要的顺序组合到pricing procedure中;
定价配置预览5 Overview:pricing configuration5
最后,你需要为定价程序维护procedure determination table;pricing procedure 根据一下内容确定:
销售区域Sales area
客户主记录中‘Customer pricing procedure’field
销售凭证类型的‘Document pricing procedure’field
为定价添加新的字段Adding New Fields for Pricing
所有用来创建条件表的字段都必须包含在各自的字段目录中;可以向字段目录中添加新的字段;
实施定价策略1Implementing Your Own Pricing Strategies1
满足特定的定价需求可能需要1个或多个新定价组件,理解每个组件的目的和能力,以及定价组件之间的关系是关键的;
解决特定的问题需要创造性地构建和结合所有的定价组件:
条件表condition table:定义条件记录的关键字;
访问次序Access sequence:包含访问条件记录的层次;
条件类型Condition type:描绘定价条件的属性;
定价程序Pricing procedure:定义条件类型是怎样联系在一起的;
程序确定Procedure determination:选择正确的定价程序;
实施定价策略2 Implementing Your Own Pricing Strategies2
下面的元素对于实施复杂的情景可能是必要的:
为定价添加新的字段 adding new fields for pricing –为了符合所有客户的需要;
必要条件Requirements—定义依赖条件和改善性能;
公式Formulas—扩展标准配置的限制;
Requirement routines and formulas 提供了修改标准定价逻辑的方法来满足独特的用户需求;
使用条件记录(Working with Condition Records)
定价报表—客户特定价格Pricing Reports-customer-specific prices
为了浏览存在的条件记录,可以生成一张条件分析列表,你可能会问这些问题:
在某一时期内,制定了什么样的客户特定价格协议?
系统中存贮了什么样的Incoterm condition?
等级价格创建了什么样的price list?
List的格式布局和在报表上显示哪些条件记录在配置中设置;
定价报表—表Pricing Reports-Tables
在为定价报表创建新的程序时,你首先要决定要在哪些View中分析条件记录,可通过从存在的条件表中选择特定的fields来实现;
依赖于选中的Fields,系统会生成tables列表,每个表至少包含一个选中的field,从这个tables列表选择哪些特定的tables出现在报表上;
列表的布局通过放置和排序出现在3个report sections的某一个中的选中的table中的fields来定义:
Page header--a page break occurs when a value changes;
Group header - a new line heading is generated for each table analyzed
Items-detailed record information
用定价报表维护条件1 Maintaining Conditions Using Pricing Reports1
条件维护已经提供了一个新的维护接口;允许批量维护;
用定价报表维护条件2 Maintaining Conditions Using Pricing Reports2
新条件维护function能够用area menus来配置;标准的condition maintenance area menu 是COND_AV;
自定义的area menu可通过选择菜单项Environmentàassignment area menu来指派;
自定义area menu可使用SE43来创建,例如Copy COND_AV,然后调整以满足特定需求;
用参考创建条件记录Creating Condition Records with Reference
新的条件记录可参考已有的条件记录创建,在处理过程中,可以修改新建记录的rate、validity period,以及additional sales data;
这个function提供了一个有效的方法来同步更新条件记录;
修改条件记录Change Condition Records
个别的条件记录能够手动地维护;价格修改功能(price change function)允许你同时维护多条条件记录;
用change documents来回顾和监控对condition records的修改;
复制条件记录Copying Condition Records
可通过Copy已存在的条件记录来创建多个条件记录,在Copying时,可以选择copying rule,copying rule在配置中维护,也可以自己创建;
净价列表Net Price List
净价列表提供了为客户创建基于选定数量物料的价格信息;净价通过模拟billing document来确定;ABAP list viewwe是创建用户定义display variants的简单方式,VBRP table中的所有字段都可用于此目的;
Sales area + Customer + Material + Plant + Pricing date/Order type 来模拟;
条件索引Condition Index
可以创建和使用条件索引来搜索为多个条件类型和条件表创建的条件记录;例如,需要查看应用于某一客户或产品的所有条件记录;
激活功能(activation function)显示了所有可用的条件索引的列表并标示哪些是激活的,系统只能使用已激活的条件索引;
在使用标准系统交付的index之前,你首先需要在配置中激活;
然而,如果你创建了自己的indexs,在generate的时候,系统会自动激活每个新的index,另外,你必须为每个条件索引指定update requirement;
你可以为每个condition type指定当你Post condition records for the corresponding condition type时系统是否更新条件index;
为条件发布程序Release Procedure for Conditions
当一个条件表被创建,你能够允许a release procedure to be used,通过选中‘With release status’复选框;这样会自动添加以下2个fields到条件表中:
KFRST release status作为最后一个key field;
KBSTAT Processing status作为一个可变数据部分的一个field,不是key;
Release status是预定义的,目前下列statuses已经定义:
Released
Blocked
released for price simulation (net price list)
released for planning and price simulation (planning in CO-PA)
release status通过在定价配置中定义processing status并分配一个release status给他来间接地设置;
Business Transaction Event 00503303 Maintain Conditions: Transfers 可用来为processing status定义个别的processing logic;
你也可以将老的没有release indicators的条件记录转换为新的有release indicators的条件记录,系统提供了一个model来完成此目的;
可变计算类型Changeable Calculation Types
Condition type的calculation type在配置中定义,calculation type确定condition的价格或者折扣以及额外费用如何计算;
在4.6版本以前,该标记(Condition type)直接copy到条件记录中,现在的版本创建新的条件记录时,可以选择不同于配置中设置的calculation type;
条件记录中的长文本Long Texts in Condition Types
可以在pricing和agreement的条件记录中维护长文本(rebates,sales deals,and promotions),这些文本提供以下信息:
Create condition records创建条件记录;
Approvals 审批;
Invalidity 无效;
如果需要,rebate agreement长文本能够copy到凭证中,例如,到credit memo request for rebate payments and from there to rebate credit memo);
然而,你不能copy pricing texts 到凭证中,用参考创建条件记录时,Texts不会Copy;
------------------
http://blog.sina.com.cn/s/blog_5fa4766c0100e5uo.html
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/96380/viewspace-677156/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/96380/viewspace-677156/