IRT310 SAP Retail Master Data (Part II)

[ SAP-Industry ] 27 三月, 2009 06:31::viwed(265)

http://www.box.net/shared/1pqp9sop4r
IRT310 SAP Retail Master Data (Part II)

l Single Article

Ø Basic Concept

Retail的article有single article, generic article, structured article之分，其中structured article包括display, sales set, prepack

display中是一些single article或者generic article的variant，作为一个整体采购，因此有采购价格，vendor和制造商预先制造准备好。比如情人节巧克力礼盒。

Sales Set是一些single article或者generic article的variant，作为一个整体销售，因此有销售价格，比如日本过年的福袋。

Prepack与display类似，不同的是article要来自同一个MC

Article主数据与material主数据一样，也有很多视图，只不过有了些变化basic data/list/purchasing/sales/logistics:DC/logistics:store/POS

因为article的数据量很大，所以SAP为零售准备了模板技术-reference article

我们可以为MC创建ref. article则所有这个MC下的article的数据都参考这个ref. article 在article创建屏幕可以指定ref. article，可以覆盖MC的ref. article。创建的article不会受ref. article数据的更改而有任何影响。

Article type与material type一样，可以控制valuation, Qty/value update, screen control, number range等

因为article可以以不同的单位出售，可以为每个UoM创建一个EAN，可以为一个UoM分配多个EAN，但是需要指定一个主要EAN

对于article可以通过Logistics->Central Functions->Mass Maintenance或者TCODE MM46进行大批量维护。

另外，我们还可以通过菜单Logistics – General-> Material Master-> Retail-Specific Settings-> Settings for Screen Data Display来设定为article上传图片 目前SAP预置的MODE article类型被分配了显示图片的子屏幕

Discontinue:如果一个商品不能继续供货或者不再销售，则需要做商品中止。Retailing-> Master Data-> Article Data-> Article-> Discontinue 之后我们可以通过discontinue monitor来查看商品中止结果，如果成功，可以将此worklist删除。被终止的产品如果想更改或者查看，系统会产生warning的消息。

Ø Fast Entry

SAP Retail中有一个article core master data的概念，是一种被其他模块功能生成的article.比如在采购时发现某些article没有创建，则不必退出PO功能，可以直接在PO中创建这个article,当然创建的article只具有当前业务功能的数据，如果想在其他所有业务模块使用，需要做完全的数据维护。

在MARA中需要指定一个field来存储article的status是否是core master以便稍后利用TCODE WRFMATMON - Article Monitor进一步的完善数据。

Logistics – General-> Material Master-> Retail-Specific Settings-> Settings for Core Master Data中可以做具体的设置

Maintenance group在创建article core master时是需要指定的。MG包含了一系列可维护的字段，在后台配置中，这些字段用field group组织在一起，在MG中需要指定field group

Logistics – General->Logistics – General->Retail-Specific Settings->Settings for Field Groups

Logistics->Retailing->Article Data->Article->WRFMGROUP - Manage Maintenance Groups

我们之前提到的要为article core master data设置值就是在这里的attribute维护的。

通过点击Show/Hide按钮，可以打开下半部的窗口，为自己创建新的template，这个template会在批量维护时使用

我们也可以通过WRFMATCOPY – Copy来参考一个article快速创建一个新的article，并指定copy的内容

SAP还可以对article进行follow-up和replacement操作。Follow-up会永久的替代原来的article，而replacement只会替代一个固定的时间段。

Logistics->Retailing->Article Data->Article-> Follow-Up/Replacement Articles

对于这种article的替代，可以在不同的层次上进行，比如一个site(local assortment)或者很多site(general assortment)

Logistics – General-> Material Master-> Retail-Specific Settings-> Settings for Follow-Up/Replacement Material下可以设置是否进行check 是否有validity等，但是一般我们不会更改

Ø PRICAT

如果想要vendor维护article大部分的数据，然后把敏感数据发给你，然后我们从data pool或者vendor那里得到最新的article数据，可以用到PRICAT功能。一个catalog item对应于一个SAP article

Ø Article List

Article list是一组预定义的article.比如你想要隶属不同MC的article被一起分发给store，则可以定义一个article list.比如你想创建一个article list，其中包含所有将来不再想继续销售的article或者定义出同一个代理商的所有article，在将来对article做选择操作时作为一个选择条件

SAP中有两种AL：

Dynamic AL: 在系统中保存一个选择的标准，然后动态的选出符合的article

Static AL: 在系统中包含选择标准和release时选出的article

运行TCODE WRF_AL – Edit 画面如下

左侧是article list hierarchy，可以以商业或者应用为标准进行组织，article list会创建在最终节点上，右侧是相应的AL信息画面。

首先编辑AL的header信息，如图

在编辑完header信息后，点击edit selection定义article选择的标准。定义完之后点击results list来查看结果。如果是static list，可以手工添加和删除不在选择标准内的article

如果是static list，在编辑了新的选择标准以后一定要点击update result，新的结果才会更新，并且结果前面会标出来不同的图标，+表示新增加，=表示没变，-表示被删去。

在SAP中创建的static article list可以被BI用来reporting.

SAP BI中有business contents映射为article list, BI回传给SAP填充static article list

Ø Discontinuation

一个article将不再被使用的时候，我们可以做discontinuation废止。对于废止的方法，我们有以下几种：

Article discontinuation for vendor 特定的vendor将不能再提供article

Article discontinuation for assortment article将不能从特定的assortment(sites)采购和销售

Article discontinuation for distribution Chain article将不能在特定的distribution chain销售

Client-side article discontinuation article不能在任何业务操作中使用

在一个article不再使用之前，需要有一些check的步骤的

如果在库存，在PO等里面依然存在这个article，则discontinue不会成功，我们必须先解决这些问题。SAP预先定义了一些解决问题的后续步骤：

IMG->Logistics – General->Material Master->Retail-Specific Settings->Settings for Material Discontinuation->Define Follow-Up Actions

我们可以看到是一些系统内置的function module 如果我们要开发自己的后续action 就需要在这里配置

Assign Follow-Up Actions to Error Messages一步将每种error分配一个action

l Generic Article

Ø Characteristic

Generic article的关键是SAP的classification system。我们先用TCODE CT04创建一个characteristic.在创建了相关的characteristic 之后通过Logistics -> Retailing -> Master Data -> Article Data -> Environment -> Merchandise Categories -> Characteristics -> Characteristics ->TCODE WRFCHVALGRP - Group Characteristic Values我们可以将相关的value 组织起来。

左边区域显示了整个特征值的树状结构，特征值可以在每个节点层级上，在屏幕右下部分维护。每个节点的使用可以限制在固定的一些MC上，在右上部分维护。也就是说如果一个article不属于这个范围中的MC，那么article的维护画面不会出现维护search help

之后我们通过TCODE CLWE - Create创建一个characteristic profile，在char.维护处输入我们创建的characteristic并在relevant输入


(0) 评论    (0) 引用   

SAP cash discount 现金折扣

[ SAP-FI/CO ] 09 三月, 2009 21:43::viwed(375)

http://www.study-erp.com/Article/ShowArticle.asp?ArticleID=88
http://www.for-admin.cn/ERP/ShowArticle.asp?ArticleID=89

http://baike.baidu.com/view/514890.htm


SAP中相关折扣帐户的设置在
IMG->Financial Accounting (New)->Accounts Receivable and Accounts Payable->Business Transactions->Outgoing Payments->Outgoing Payments Global Settings

IMG->Financial Accounting (New)->Accounts Receivable and Accounts Payable->Business Transactions->Incoming Payments->Incoming Payments Global Settings


(1) 评论    (3) 引用   

SAP采购审批策略 purchase release strategy

[ SAP-MM ] 04 三月, 2009 18:39::viwed(485)

我这里简单的介绍了PO的审批流程，在附件中包含了图片，以及网络上的关于PR的审批详解，以及SAP Notes 207490对PO审批配置的介绍。Release Strategy.rar

Purchase Release Strategy

如果想需要PR或者其他采购文档(PO, contract, scheduling agreement, request for quotation (RFQ)等)在一定条件下被审批，就需要用到SAP的审批策略。

对于PR的审批可以在item级别也可以再total级别，并且有带classification和不带classification两种，不过不带classification的只能在total级别审批。我们接下来都以PO为例讲解。

l Release Condition(Characteristics class)

一个PO必须满足审批条件，才会进入审批流程，比如采购总价值超过1万元，或者采购组001采购的物料等。SAP采用classification系统进行审批条件的配置。

首先通过CT04定义审批条件的要素，比如采购组或者总价值，我们可以在表CEKKO中找到所有可以被利用的字段，如果不能满足需求，就需要enhancement M06E0004

之后CL02定义class，也就是将各个审批要素组合在一起，组成一个完整的审批条件。比如采购组001采购金额大于5K 采购组002采购金额大于10K

l Release Strategy overview

审批策略是一个总的审批流程，可以在一个审批策略下定义release code，我们最多可以定义8个release code。定义审批策略包括定义定义release group, release code, release indicator等步骤

l Release Group

同一个release group具有相同的审批level，比如我提到的001采购组大于5K的金额需要审批，而002采购组大于10K的金额需要审批，这就需要连个不同的审批组，而如果有一个第三个部门，但是依然用采购组001和大于5K的policy，那么它可以与第一组共享审批组。

我们为审批组分配Class

l Release Code

Release Code我们可以理解为现实中与整个审批流程相关的人，每个审批者都会审批相应的release code。如果配置了workflow，可以将他们与workflow结合起来用，审批自动到达他们的task中。

l Release Indicator

这一步骤实际是定义审批中的各种状态和在此状态时系统的反应。

比如我们这里有2个状态，在审批流程中都会是状态1，也就是没有release，可以更改PO并且不会触发新的审批流程，或者是在触发新的审批流程的值状态时进行新的审批等。后面的%value change字段限制了字段更改的最大范围，超过了一定百分比系统会产生错误信息。

l Release Strategy

最后一步定义审批流程。Release codes我们看到最多输入8个，我们按照审批顺序输入。

Release prerequisites定义的是每个审批流程需要的前提，很简单，一般的审批都是一步一步进行的。都会勾成下面的样子，也就是02需要01最为条件。

Release status定义每一步被审批后，PO的状态，我们定义只有01 02都被通过了，才会进入最终的2状态

Classification相当于定义这个审批策略被触发的条件。

l Authorization

整个审批的授权可以通过分配authorization object M_EINK_FRG给相应用户进行限制

l Test

我们为采购组001创建一个总价80块的订单，没有触发审批流程。

当我们改为总价8000块时，就产生了审批流程

我们通过TCODE ME28进行审批，如果直接审批02 code会发现系统提示没有合适的PO，审批后PO的状态改变

审批02 CODE以后，PO状态改变

如果尝试更改PO会得到以下错误消息

Purchasing document has release indicator 2 (changes not possible)


(0) 评论    (42) 引用   

Tolerance Limits for Price Variance

[ SAP-MM ] 03 三月, 2009 22:45::viwed(345)

在我们创建PO的时候，可以检查当前PO中物料输入的价格以及产生的现金折扣，如果与我们期望的相差过多，可以产生warning或者error的消息。
这个功能是通过Set Tolerance Limits for Price Variance来实现的 IMG->Materials Management->Purchasing->Purchase Order->Set Tolerance Limits for Price Variance
SAP预置了两个容差KEY PE和SE PE是用来检查物料的价格与物料主数据价格的差异 SE是用来价差现金折扣 为每个company code通过设置上下限最终达到在创建PO时进行条件检查的目的。

 查看全文

(0) 评论    (11) 引用   

主数据之account assignment group

[ SAP-SD ] 02 三月, 2009 23:37::viwed(508)

在material和customer的sales相关view中，有一个字段，account assignment group，它可以决定最终billing doc到FI doc时，进入哪个revenue account

相关配置在 IMG->Sales and Distribution->Basic Functions->Account Assignment/Costing->Revenue Account Determination下

执行Check Master Data Relevant For Account Assignment就可以配置material和customer的account assignment grp

之后通过执行Define Dependencies Of Revenue Account Determination 来定义决定收益帐户的条件table

比入001 就由sales org./acct assgGr/accout key 组成

然后执行Define Access Sequences And Account Determination Types来定义帐户决定的一个过程的condition type，跟定价类似，通过不同顺序和condition table来定义搜索的过程

之后通过Define And Assign Account Determination Procedures将condition type分配给一个决定过程

Define And Assign Account Keys可以定义和分配account key给condition type 这样可以使得进入FI的不同帐户，比如SAP内置了

  • ERF freight revenues
  • ERL revenues
  • ERS sales deductions
  • EVV cash settlement
  • MWS sales tax

最后通过Assign G/L Accounts 分配帐户。
http://www.sapscene.com/sapscene/accassg.html

SD-FI Account Determination and Postings

This is known in the IMG as "revenue account determination", but it covers a lot more than that (discounts, taxes etc). This is what determines how the financial impact of your SD Billing document is posted into the FI General Ledger.

The integration is controlled both in SD and in FI.

In SD there is a awesome area of configuration called the pricing procedures. The pricing procedure determines the final price quoted to the customer for a particular product. This could be a complicated calculation taking into account the base price, any special prices or discounts that may apply to that scenario, taxes, freight charges etc. These prices or charges are called 'condition types'. This condition technique is used in a number of areas of SAP.

For now all we need to know is that each condition type is assigned to an account key (or in the case of rebates two account keys). You can assign multiple condition types to the same account key. There are a number of account keys that are pre-defined in the system. For example:

  • ERF freight revenues
  • ERL revenues
  • ERS sales deductions
  • EVV cash settlement
  • MWS sales tax

Now we start getting to the integration by mapping the account keys to GL accounts. But it is not as simple as that. It can be as flexible (ie: as complex) as you want. Start off with the most simple approach. Generally if one is using a good sales / revenue reporting tool (eg: CO-PA) then one does not need a lot of flexibility and variety in the GL accounts that are posted to. The level of detail that you need in GL should be determined by your financial statement reporting requirements - you may end up with only one Revenue account - it is a good bet!

So, taking the simple approach we would ignore most of the configuration possibilities : procedures, access sequences, condition tables etc (Yes it is that 'condition technique' kicking in again. Once you have worked through it once in one area and encounter it in another then hopefully you will be comfortable in knowing that most of the standard configuration can be left as is. )

We have to decide which access sequences we want to use (Five access sequences are defined in the standard SAP R/3 System). To keep it simple, let us assume we just use one - for example: the access sequence "chart of accounts/sales org./account keys".

The chart of accounts part is standard in all account determinations, so let us look at the rest. This access sequence allows us to specify different GL accounts for different Sales Organisations.

So if we had a billing document line item where the customer had some special deductions for one of the products he purchased, we could map accounts by Sales Organisation. To make it even simpler a document is within one Sales Organisation so we have an overall mapping as follows:

SD Line Item Condition typeSD AmountAccount KeySales OrganisationGL Account
1 Sales deduction for being such a nice guy$10ERS1000800010 - Sales deductions for 1000
Sales deduction for special promotion on particular product$15ERS
Base Revenue$200ERL800000 - Revenue for Sales Org 1000
Total for item 1$175
2Base Revenue$100ERL1000800000 - Revenue for Sales Org 1000
Total for item 2$ 100
Document Total$ 275

So the invoice that the customer gets (and that you can view in SD) will look something like:

Item (Note this is the SD Invoice line item)Amount
Item 1: $175
Item 2: $100
Total owing , 30 days terms etc: $275

The GL document posting that the system will make to FI will look something like this though:

FI Line Item Debit / Credit AccountAmount
1Debit (PK=01)Customer (AR Account)$ 275
2Credit (PK=50)Revenue (GL Account)-$ 300
3Debit (PK=40)Sales Deduction (GL Account)$25

Balancing to 0 as all GL documents must....

$0

Note : There is no direct relation between an SD Line item and an FI Line Item - they are different things.


(0) 评论    (0) 引用