Link
统驭科目是用来将明细分类帐附加到总分类帐的一种总帐科目。统驭科目和明细分类帐在过帐业务时同步更新- 即行项目明细保持在明细份类帐中，汇总信息则保留在统权科目中，统驭科目是不能直接过帐的。
在系统中，我们一般把某个客户最经常发生的业务对应的总帐科目设为它的统驭科目。如非特别说明该客户的业务都会自动计入它的统权科目中去。而一个总帐科目一旦被设为统权科目，它就只能接收来自明细帐的数据进行汇总，它本身不能直接录入数据。应收应付和资产相关科目一般设置成统驭科目(有分类账的总帐科目) 。
在创建GL主数据的时候指定；当你在创建客户或供应商主数据的时候，都会提示输入特别总帐标准，就会用到统驭科目，与会计科目表中的应收、应付、预收、预付形成对应关系，起到连接总帐和分类帐之间的关系。
星期三, 四月 27, 2011
星期二, 四月 26, 2011
Chart of Acounts & G/L Accounts
Link
Chart of accounts (COA): 指包含所有总账科目定义并按顺序排列的清单，其中每一项都是一个总账科目，称为G/L Account。Chart of accounts在中文中一般译为科目表。
在SAP系统中，每一个总账科目(G/L Accoun)都有两个层次(level)，首先必须在Chart of accounts level维护相关信息，然后再在company code level维护附加的信息。Company code实际应用的科目表叫operating chart of accounts.
Chart of accounts (COA): 指包含所有总账科目定义并按顺序排列的清单，其中每一项都是一个总账科目，称为G/L Account。Chart of accounts在中文中一般译为科目表。
在SAP系统中，每一个总账科目(G/L Accoun)都有两个层次(level)，首先必须在Chart of accounts level维护相关信息，然后再在company code level维护附加的信息。Company code实际应用的科目表叫operating chart of accounts.
Posting Period
Link
Fiscal year (FY for short)
按我国会计制度，会计年度一定是按日历年度(calendar year)的1月1日到12月31日，但西方会计制度就没有这一限制，因此FY可能各不相同。英国和香港公司就很流行4月1日到3月31日为一个FY。如果FY和calendar year相同，配置较简单一些，如果与calendar year 不同，就有两种可能性。比如：
1) 2008年度 是从 2008.04 到 2009.03
2) 2008年度 是从2007.04到2008.03
2) 2008年度 是从2007.04到2008.03
这样在配置时有一个year shift的概念，本文一会儿说明。
Posting periods 和 special periods
SAP系统允许设置12个positng periods以及最多4个special periods。Posting period用来作日常过账之用，special periods用来作年结(year-end)调整之用。但要4个special period有什么用呢，主要是为了增加灵活性。比如将公司自已的调整记入13期间，将审计师的调整记入14期间，这样，财务报表可以有不同的版本。
Company Code
Compnay code是FI的最基本组织单位，资产负债表和损益表就是在company code层面上编制。所以，如果法律要求某个组织独立核算，则须设立单独的company code.
国内很多ERP软件，都有一个账套(ledger)的概念。SAP系统的company code与ledger并不相同，company code只是FI模块中的一个组织单位，其它模块有其它的组织单位。比如MM模块的组织单位是plant，CO模块的基本组织单位是controlling area。不同模块的组织单位通过相互指派的方法，表达集团公司的组织架构。比如：一个company code可以包含多个plant，一个controlling area可以包含多个company code。
星期一, 四月 25, 2011
星期五, 四月 22, 2011
Profit Center
Link
1.基本概念
利润中心是出于内部控制目标而设定的反映管理架构的会计组织单位。从管理会计的角度来说，一个利润中心，最终考核的是利润，那么该组织单元就会发生收入，也会发生成本和费用。
利润中心是出于内部控制目标而设定的反映管理架构的会计组织单位。从管理会计的角度来说，一个利润中心，最终考核的是利润，那么该组织单元就会发生收入，也会发生成本和费用。
SAP中，日常业务可能并不是直接基于利润中心发生并记录的，但是由于利润中心创建配置之后，会分配给各级产生业务的各种对象，如成本中心、物料等等。因此，这些对象产生收入、费用、成本等凭证的时候，如果必要，就会同步平行生成利润中心的会计凭证。这些凭证就是利润中心会计信息处理、分析和统计的基本或根本信息来源。正是由于这种同步信息的生成，使我们可以基于利润中心出具三大财务报表。
每个利润中心都有以下基本的属性：
【编码和名称】根据需要设定；编码肯定是不可重复，同一控制范围下。如果有多个利润中心，各利润中心的编码长度还是要一个规则为好。
【控制范围】每个利润中心都必须切仅属于一个控制范围，因此，创建利润中心之前，要确保控制范围已经创建并确定好了。
【标准层次】标准层次在后面具体提到。创建利润中心的时候，即可制定该利润中心所属的利润中心标准层次。
【有效期】同成本中心类似，利润中心也可制定其有效期。大多数情况下，创建了也就设为永远有效了，将失效日期设置得超级大。
【其他】每个利润中心严格来说还有责任人、责任部门等信息。
【状态】这个也是比较重要的。要是创建了没激活，也是用不了的。利润中心分为多个状态，如创建了未激活、激活、删除（冻结）。利润中心正式使用后只能冻结，并不能真正物理删除。当然，如果没有正式使用，无物理删除也是可以的，但是由于物理删除系统要校验很多信息，所以较长等待时间。
扩展应用上，SAP中的利润中心也可以用作管理会计上的投资中心。这种中心在权力责任划分上，显然比一般的利润中心更大，它要负责投资决策，以及有投资带来的利润回报。
2.利润中心组
与利润中心相关的一个组织概念就是标准层次结构（Standard Hierarchy）和利润中心组（Profit Center）
利润中心标准层次（Profit Center Standard Hierarchy）是一种特殊的利润中心组（Profit Center Group）,包含了所属控制范围下的所有利润中心，反映了利润中心会计的组织结构。例如，某集团分为白电、黑点、空调等几个集团，每个集团下多种产品，如白电下有冰箱、冷柜、洗碗机等，每个产品设置为一个利润中心。那么，其利润中心会计的组织架构就是Client—控制范围Control Area——集团Group——利润中心Profit Center。
鉴于此，我们可以把利润中心组分为标准利润中心组或非标准利润中心组。一个控制范围（Control Area）下的所有利润中心必须放到该控制范围的利润中心标准层次结构下去，而非标准利润中心组是出于日常操作、报表分析等方面的便利而进行的利润中心的自由组合。这样，一个控制范围下，一个利润中心只能属于一个标准上级利润中心组，而可以属于多个非标准利润中心组。
【编码和名称】根据需要设定；编码肯定是不可重复，同一控制范围下。如果有多个利润中心，各利润中心的编码长度还是要一个规则为好。
【控制范围】每个利润中心都必须切仅属于一个控制范围，因此，创建利润中心之前，要确保控制范围已经创建并确定好了。
【标准层次】标准层次在后面具体提到。创建利润中心的时候，即可制定该利润中心所属的利润中心标准层次。
【有效期】同成本中心类似，利润中心也可制定其有效期。大多数情况下，创建了也就设为永远有效了，将失效日期设置得超级大。
【其他】每个利润中心严格来说还有责任人、责任部门等信息。
【状态】这个也是比较重要的。要是创建了没激活，也是用不了的。利润中心分为多个状态，如创建了未激活、激活、删除（冻结）。利润中心正式使用后只能冻结，并不能真正物理删除。当然，如果没有正式使用，无物理删除也是可以的，但是由于物理删除系统要校验很多信息，所以较长等待时间。
扩展应用上，SAP中的利润中心也可以用作管理会计上的投资中心。这种中心在权力责任划分上，显然比一般的利润中心更大，它要负责投资决策，以及有投资带来的利润回报。
2.利润中心组
与利润中心相关的一个组织概念就是标准层次结构（Standard Hierarchy）和利润中心组（Profit Center）
利润中心标准层次（Profit Center Standard Hierarchy）是一种特殊的利润中心组（Profit Center Group）,包含了所属控制范围下的所有利润中心，反映了利润中心会计的组织结构。例如，某集团分为白电、黑点、空调等几个集团，每个集团下多种产品，如白电下有冰箱、冷柜、洗碗机等，每个产品设置为一个利润中心。那么，其利润中心会计的组织架构就是Client—控制范围Control Area——集团Group——利润中心Profit Center。
鉴于此，我们可以把利润中心组分为标准利润中心组或非标准利润中心组。一个控制范围（Control Area）下的所有利润中心必须放到该控制范围的利润中心标准层次结构下去，而非标准利润中心组是出于日常操作、报表分析等方面的便利而进行的利润中心的自由组合。这样，一个控制范围下，一个利润中心只能属于一个标准上级利润中心组，而可以属于多个非标准利润中心组。
3.虚拟利润中心dummy profit center
虚拟利润中心本身也是一个利润中心，但是不具任何业务或财务上的意义。同其他利润中心相比，他只是有个一个特殊的标识而已。
如果某个对象应该分配指定利润中心，而没有指定的时候，系统默认将虚拟利润中心分配给它。
最常见的就是，一般情况下的成本中心都必须指定具体的所属的利润中心，但是有些成本中心并不能唯一确定所属的利润中心，例如，某个成本中心是为多个而利润中心服务的时候，就只能先将虚拟利润中心分给这种成本中心。
系统支持而且一般情况下，必须将虚拟利润中心的数据分摊分配到具体的利润中心去。但是值得注意的是，标准方案并不建议，用户为了日后的分摊分配，而将相关数据专门过账到这个虚拟利润中心，而是要根据业务需求，专门创建一个要分摊的利润中心来实现这个目标。
虚拟利润中心本身也是一个利润中心，但是不具任何业务或财务上的意义。同其他利润中心相比，他只是有个一个特殊的标识而已。
如果某个对象应该分配指定利润中心，而没有指定的时候，系统默认将虚拟利润中心分配给它。
最常见的就是，一般情况下的成本中心都必须指定具体的所属的利润中心，但是有些成本中心并不能唯一确定所属的利润中心，例如，某个成本中心是为多个而利润中心服务的时候，就只能先将虚拟利润中心分给这种成本中心。
系统支持而且一般情况下，必须将虚拟利润中心的数据分摊分配到具体的利润中心去。但是值得注意的是，标准方案并不建议，用户为了日后的分摊分配，而将相关数据专门过账到这个虚拟利润中心，而是要根据业务需求，专门创建一个要分摊的利润中心来实现这个目标。
4.利润中心的维护
在创建功能范围组织数据的时候，就可以维护一个利润中心标准层次的基本组（或者叫利润中心标准结构的最上层组）；然后，通过前台或后台利润中心标准层次维护入口进去维护该控制范围下的具体的利润中心层次结构。标准层次前台路径：Profit Center Accounting——>MasterData——>Create/Change/Display Standard Hierarchy;后台路径：Profit Center Accounting——>MasterDATA——>Profit Center——>Maintain Standard Hierarchy。
而利润中心标准层次结构下的利润中心也可通过两种方法关联标准层次结构：（1）单独创建利润中心，并指派已经存在的标准利润中心层次结构给它；（2）在利润中心标准层次结构下直接创建利润中心。
同标准利润中心层次维护一样，前台后台都可以，并且利润中心的维护可以单个维护或批量维护。值得注意的是，虚拟利润中心只能在后台维护。
对于非标准利润组中心主而言，自然是在创建利润中心之后，才能根据需要自由组合创建。这种自由，体现在利润中心组层次结构的层次数量、下属包含的利润中心都是自由指定的，只要是在同一个控制范围内。非标准利润中心组可以再系统前台维护，也可以再后台维护.前台路径——Profit center accounting——>Master data——>Create/Change/Display Profit Center Group；后台路径：Profit Center Accounting——>MasterDATA——>Profit Center——>Maintain Profit Center Groups
在创建功能范围组织数据的时候，就可以维护一个利润中心标准层次的基本组（或者叫利润中心标准结构的最上层组）；然后，通过前台或后台利润中心标准层次维护入口进去维护该控制范围下的具体的利润中心层次结构。标准层次前台路径：Profit Center Accounting——>MasterData——>Create/Change/Display Standard Hierarchy;后台路径：Profit Center Accounting——>MasterDATA——>Profit Center——>Maintain Standard Hierarchy。
而利润中心标准层次结构下的利润中心也可通过两种方法关联标准层次结构：（1）单独创建利润中心，并指派已经存在的标准利润中心层次结构给它；（2）在利润中心标准层次结构下直接创建利润中心。
同标准利润中心层次维护一样，前台后台都可以，并且利润中心的维护可以单个维护或批量维护。值得注意的是，虚拟利润中心只能在后台维护。
对于非标准利润组中心主而言，自然是在创建利润中心之后，才能根据需要自由组合创建。这种自由，体现在利润中心组层次结构的层次数量、下属包含的利润中心都是自由指定的，只要是在同一个控制范围内。非标准利润中心组可以再系统前台维护，也可以再后台维护.前台路径——Profit center accounting——>Master data——>Create/Change/Display Profit Center Group；后台路径：Profit Center Accounting——>MasterDATA——>Profit Center——>Maintain Profit Center Groups
星期一, 四月 18, 2011
Credit Memo & Debit Memo
credit memo和debit memo是对企业向顾客已经交付的货物的价值进行调整的单据类
型。举个例，如果您已经就所交付的货物向买主开具了100元的发票，可是由于货物质量的瑕疵，
买主主张“货接受但必须削价10元”，如果您接受了这个主张，那您就得开具10元的credit memo
（即实际业务中的所谓“红字发票”）。总之，与原始invoice的价值相比，增价用debit memo，
降价用credit memo，两者都是billing document type。
credit memo request 和debit memo request都是sales document type，其原理与一般的销售订
单类型并无质的区别。只是，两个memo request的下游transaction都是直接参照订单创建
billing document，而不需要有delivery。
credit memo request --> credit memo, debit memo request --> debit memo，这就是它们的
流程。
Debit Memo（借项通知单） & Credit Memo（贷项通知单） 都是因为顾客对产品不满意所产生的请款的文件。Debit Memo增加应收账款（Account Receivables）的数值; 反之，贷项通知单则减少应收账款的数值。
借/贷项通知单建立 1 直接由顾客发票转置而成; 2 由借/贷通知单（Debit/Credit Memo Request）转置而成
星期五, 四月 15, 2011
Pilot Release
- Status set to Pilot Release
- Remember to set pilot customer for this release
- After that, reverse all code change made
