定价过程的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 the conditions with in 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 conditions with in 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:
From:This can be used as a base to the condition type for calculating further value.
{+}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.
posted @ 2011-06-27 16:22 elegant 阅读(333) 评论(0)
编辑ERP项目经验总结
该总结的目的：通过总结ERP项目的实施经验，提炼项目风险。包括在人员、组织架构、管理制度、程序文件等方面为其他项目提供参考，达到规避风险的目的。
1、项目最大的感触就是战略决定架构，项目实施部门的高层领导在项目上线后不要授权给其他人最好能够亲力亲为，必须执行到位，这样才能使项目更好的推进和实施。
2、在项目初期和蓝图阶段高层领导特别是一把手也应该参与到项目中，能在项目的各个阶段或者遇到需要领导拍板下定论的时候及时的将问题解决或者制定出相应的规章制度，否则会使问题积压，得不到根本的解决，进而影响到项目的进度和质量。
3、高层领导的意识很重要，只有领导能个从上而下的推进项目，则项目就能够得到很好的推进，所以项目的重点还是怎么提高领导意识，怎样能让领导真正推动项目。
4、如果是小项目，因为业务范围比较小，所以没必要设立太多的职能部门，使权力不是很分散，避免部门间互相咬合，互相推诿责任的问题，也能在项目中能更明确的确立相关的工作，遇到问题能更好、更快的解决。
5、每个项目最好尽可能的在蓝图阶段就将相应的管理制度制定出来，否则等项目上线后就会被搁置；项目的推进最好由专人或者专门的部门进行，这样会更有利于推广。
6、对于最终用户的培训最好能从蓝图阶段开始，这样有助于修改前期的各种习惯，从实施软件和项目的原理入手进行培训，进行流程的宣贯，就能使关键用户能从项目的角度去看待问题，从而能够更好的进行项目的实施，也能增加项目的成功率。
比如对于外检、采购等部门，如果不懂蓝图，仍然各自为政，还是按照各自原有的流程实施，就会使项目不顺畅，就会有争议。因为前期毕竟有其习惯的做法，而且都使用了很长时间，比较驾轻就熟了，如果不了解蓝图是不会真正的去改变习惯的。
7、项目阶段的例会制度，特别是初期，应指定责任人，而且责任人要是那种说话有力度的人，敦促责任人之间相互沟通，相互了解业务和实际的困难，可有利于项目推进，也可使项目得到更好的实施。
8、系统操作相对于制造部门会感觉比较累，要事先让其了解系统对整个公司的意义和益处，防止只从个人、片面的角度看问题，产生抱怨，使其知道会在比如成本和工序平衡方面会有很好的控制。
9、要经常跟高层领导汇报工作进度和工作中遇到的难点、困难等，使其从系统和项目的角度了解为何有些看似能解决的需求但在实际实施和运作的过程中是实现不了的。
10、主数据维护的准确性对后期的各项工作有至关重要的作用，不能只说差不多对了就可以了，对后期的成本和库存的精确度和准确度都起到主导作用。
11、关键用户和最终用户对业务和系统的了解程度是每个项目成功的关键，所以应加强对其的培训，只有业务部门愿意学、愿意接受才能够更好的解决问题，才能体现出项目的价值。
12、每个项目在上线之前最好能进行一次模拟试运行，一是看是否有BUG，二是看用户对系统的掌握情况，能更好的暴露问题，有利于增加项目的成功率。
13、外部实施公司的能力对项目来说是至关重要的，应该进行招标的方式，让所有投标公司来讲解方案，并让相关部门参与招标，中标公司的项目经理和顾问要进行面试，且要求顾问一定要到一线部门去沟通，了解业务，不能闭门造车，使开发方案一再变动。
14、对项目相关部门的参与人员的要求一定要是业务骨干且必须全职，要能够全程参与，所以建议项目的发起人最好能是项目的使用部门，这样能够使其责任感更强一些，在项目中工作能够更加主动一些。
15、不管做任何项目，项目的目标一定要明确，且项目目标一旦明确就不能随意的更改，如果有提出这方面需求的，必须从项目风险的角度去考虑是否能够更改。
16、项目的目标不能定的太高，要考虑基础，为了能使项目尽快的推进，最好能只是改变业务人员的习惯，而不要期待一个项目能够使整个公司发生翻天覆地的变化，使其能够焕然一新。譬如国外欧美地区之所以成功率很高，归根结底是因为他们的项目周期长，一点点的实施，慢慢的深入，使业务部门一点点的改变，这样就能很好的、扎实的实施。
17、要让关键用户真正掌握系统，让关键用户去培训最终用户，这样就能然关键用户能够独立的解决一些日常出线的问题，而不是一出现问题就找内部顾问。
18、在项目的蓝图阶段最好就能够确定下项目上线后的考核制度，如果初期不指定和实施等项目正式上线已经推进后再制定就容易实施不开。要让制定的细规则放入到各部门细节职责中。
19、怎样让项目最终用户能真正运用、了解系统，更好的操作系统，最好的方法就是让关键用户去培训最终用户，给别人培训也是最好的提升自己的水平的一种途径。
posted @ 2011-06-27 16:16 elegant 阅读(428) 评论(0)
编辑