EBS集中采购简介Intercompany.doc

集中采购简介Intercompany 1文档作者：林业东创建日期：2009-6-10更新日期：2009-6-10文档编码：当前版本：1.0文档控制变更记录3日期作者版本变更参考20090610林业东1.0原始文档分发姓名职位分发拷贝编号姓名位置/岗位1234 目录文档控制ii前言4目的4方案设计原则4适用范围4集中采购详细解决方案5组织结构5业务模式5细节讨论8注意问题10设置和操作截图10已解决/未解决的问题17未解决的问题17已解决的问题17前言集中采购，公司间事务处理流之一。主要用于集团式采购业务中：各子公司向某一子公司（简称A）传达采购需求；A向供应商下达采购订单，供应商将货物直接送至需求分公司。然后，A与供应商结算，A与其他子公司用公司间应收应付结算。本文用HK和SZ作为两个子公司的简称，企图隐藏企业的真实信息，但百密一疏，上了截图后就起不到隐藏的目的了。目的本文档主要是与大伙探讨集中采购的方案与应用，抛砖引玉。方案设计原则适用范围集中采购详细解决方案组织结构组织结构某企业有一香港子公司（以下简称HK），一深圳子公司（以下简称SZ）。反映在系统内的组织架构如下：业务模式业务模式SZ子公司有采购、库存、生产、销售等业务；而其中的采购业务一分为二，部分是向海外供应商采购的。海外采购如果能集中报关，则能省时省力，提高效率。于是设立HK子公司，专门负责SZ子公司的海外采购。而事实上，HK子公司并无实际的仓库，实物是直接发到SZ，但帐上需要经过HK的库存。业务链：SZ子公司传达采购需求HK子公司接收需求，并向供应商下订单货到，HK暂收并报关SZ接收、检验、入库；财务上：公司间应收、应付，HK子公司对供应商的应付。（为简化讨论，这里仅以两个子公司为例。更多的子公司，也只是扩展一下以上业务链而已（例如在HK子公司和SZ子公司之间再增加广州子公司，上海子公司），对方案整体不会构成大的影响。）方案匹配如果让系统一步一步来实现业务，则有以下步骤（方案1）：1、 SZ向HK下PO；2、 HK接到SZ的PO，录入为SO；3、 HK根据SO及库存量，以决定需向供应商下的PO；4、 HK接收货物并入库；5、 HK应付；6、 HK销售出库；7、 SZ接收、检验、入库。8、 HK与SZ公司间应收应付。为简化讨论，可以先忽略财务上的步骤5、8。接下来，我们会觉得也许内部销售能派上用场（方案2）：1、 SZ下Internal PR2、 HK导入SZ的PR并创建Internal SO3、 HK创建PO4、 HK接收入库5、 HK销售发运6、 SZ接收检验入库这里，第6步是必需的，因为SZ检验这一步需要在系统内反映，所以无法将发运网络的转移类型设置为“直接”。比起方案1，简化了录入SO的操作。但是，如果业务量大，则各订单行和价格的反复录入、同一物料的入库和出库等操作难免出错，多次审批既耽误时间也影响心情。综上所述，操作繁杂；接下来的目标是把重复的操作简化掉。当我们重新审视这一业务现状，会发现其实集中采购刚好能满足需求（方案3）：1、 SZ创建PR2、 HK引用SZ的PR创建PO3、 SZ接收、检验、入库（系统同时自动生成HK的接收、入库和销售出库事务处理记录）通过对比，方案3挺好。当然，若干细节有待后面讨论。流程图采用R12的集中采购流程详解：1、 HK_OU内创建全局一揽子协议2、 SZ创建PR3、 SZ引用HK的BPA创建标准订单（全局一揽子协议只能被创建成标准订单；该订单是HK向供应商下的单。订单所在的OU=HK_OU，SHIP_TO_ORGANIZATION_CODE=SZ_INV）4、 HK根据该标准订单，对抵港的货物作接收5、 HK应付6、 HK将货物转移至SZ，SZ在系统内作转移操作7、 SZ录入检验结果8、 SZ入库9、 创建公司间应收发票、公司间应付发票细节讨论逆向物流集中采购操作起来挺简单，但是是否支持退货呢？以前曾看过某个同事的文章，说这种公司间事务在11I里不支持退货。经过测试，集中采购在R12里支持退货的，所有操作跟一般的采购退货无异；而且也会在HK内生成逆向的逻辑事务处理。价格控制价格问题比较敏感。HK以什么价格销售给SZ？业务上有两种选择：1、 HK以采购价格销售给SZ；2、 HK以不同于采购的价格销售给SZ。系统内，公司间事务处理流设置时可以选择以上任一种价格模式；而且可为资产物料和费用物料分别选择不同的模式。计划在SZ_INV运行的MRP，是否会把集中采购所创建的HK的标准订单考虑为供应呢？集中采购模式下，SZ只有一张普通的PR，并没有SZ直接下给HK的PO；而PR一旦经过自动创建，则成为了HK向供应商下达的标准订单。所以，我们很想知道，该标准订单对SZ的MRP会有怎样的影响。实际上，SZ跑的MRP会把该标准订单考虑为供应，而该订单的变更对计划的影响跟SZ本身的订单是无异的。（这一点是项目上的同事帮忙测的）事务处理及分录当从接收到检验、入库整个过程完成后，会生成以下事务处理及分录。这里，HK的逻辑销售并没有产生R12所特有的递延销货成本的分录，而是直接生成销货成本了。退货流程会沿着以上路径从下往上生成相反的分录。财务首先是HK对供应商的应付，这个跟一般的采购无异。然后是公司间的应收和应付发票，其产生有严格的先后顺序。1、 创建公司间应收发票2、 HK AR职责下“自动开票主程序”3、 创建公司间应付发票4、 SZ AP职责下“应付款管理系统开放接口导入”这些票据之间，有何联系？HK的AR发票，参考一栏里正是标准订单的编号；（假设发票编号为10000）SZ的AP发票编号，为 HK的AR发票编号+HK所在的OU id，例如“10000-82”注意问题注意问题1、 两个OU的本位币是否相同？一般来说，HK跟SZ两个子公司对应的币种应该是不同的，则做集中采购的时候，要注意币种间的折换率。2、分录是否完整产生？需要耐心的检查和测试了。3、生成的标准订单如何控制价格？该标准订单是引用一揽子协议生成的，如果协议上没允许修改价格，则标准订单像一揽子发放一样也是不能随意更改价格的。4、HK销售给SZ的价格如何控制？前面提到，有两种方式可以选择。如果设置销售价格赞同于PO，则一切不用费心。如果设置销售价格来自内部价目表，则需要在客户地点收货方处关联内部价目表。5、外部供应商是否需要在两个OU下都建立地点？其实不必，只需要在HK所在OU下建立地点即可。设置和操作截图设置截图1、 币种折换率2、 内部价目表（可选）3、 外部供应商，（内部）客户、（内部）供应商4、 公司间事务处理流4.1设置业务的起点和终点4.2 设置HK销售价格的来源4.2 设置公司间AR，AP发票信息操作截图1、 HK创建全局一揽子协议2、 SZ创建PR3、 PR引用全局一揽子协议创建成HK的标准PO4、 接收至入库5、 HK应付6、 公司间应收7、 公司间应付1.1 一揽子协议选择“全局”。必须在建立协议时就勾选，否则就改不了了。注意：该协议，是在HK的OU下建立的。1.2 工具启用组织里，加上红框所示的记录，表示从SZ请求，HK采购。3.1 创建标准订单对于集中采购，这里只能选标准PO；因为全局一揽子协议是无法创建为一揽子发放的。4.1 接收、检验和入库时，要选择SZ_INV，HK所在OU至于为什么要这样，我是给客户这样解释的：订单是HK子公司直接下给供应商，因而OU要选HK_OU；而货物最后是送到SZ来的，因而库存组织要选SZ_INV。接下来的HK应付和公司间的应收、应付，都是跑请求而已。上文已列出各请求的名称，不再附图，如有需要另传。再附PAC下的事务处理截图：HK： SZ：（此处没有做转移）（另外，“采购订单接收”是根据英文直译过来的，其实是采购入库。）大功告成。已解决/未解决的问题未解决的问题已解决的问题