<我的项目之旅---北京之行20091117>Triangular Purchasing简述

flex_erp.jerry

在实际业务环境中我们会碰到这样一种情况，即本公司需要通过一些贸易公司采购一批进口物料，采购来的物料在报关结束后由贸易公司安排运输公司将物料送至本公司。在这个过程中我们会碰到的问题是，采购订单如何从本公司下达到供应商，货物如何在交达港口后被顺利提货至本公司，本公司如何付款给供应商等等。
    这种业务环境相信很多无法独立做进口采购的公司都遇到过，对于实际业务流程，基本上难不倒各公司的关务人员及采购人员，但在系统环境下如何实现上述操作，并简化流程且满足政策法规要求则不是一件容易的事情。那么就让我们来看一下Baan V环境下我们是如何实现上述业务环境的。
    在这里我们有两种方案提供给Baan V的使用者，一种是通过Buy-Sell的形式来实现上述采购模式，一种则是通过Triangular Purchasing的方式将物料采购回来。
    这两种方案各有利弊，为了让大家能够有比较性的了解这两种方案，我会在下面的讲述中一一提到这两中方案的处理方式。
    首先是Buy-Sell。Buy-Sell是一种常见的业务处理模式，即甲向乙方下采购订单，然后甲再将自己从乙方购得的物品转卖给丙方。在这个模式里，甲从乙方购得的物料价格通常是自己销售出去的价格的某个百分比，我们通常称为转移价格(Transfer Price)，当然，转移价格的定义是站在内部公司的角度上来看的，如果甲和乙方两个公司是各自不相关的两家公司，那么这个买卖的过程其实就是一般的买卖过程，其中采购方的采购单价也是根据一般协议定义的采购价格，而非转移价格。但是为了更具典型性地探讨这种模式，我更倾向于将甲乙双方看成是内部公司之间的业务往来，映射到一开始提到那个业务环境，甲就是所谓的“本公司”，而乙则是那家贸易公司。在Baan里面，对于这样的内部往来业务模型，通常是定义在有Logistic Company和Finance Company的不同之上的。甲公司具有独立的Logistic Company和Finance Company，但乙方公司往往只具有Finance Company的属性，也即仅作为贸易公司存在，实质上只是一个“本公司”与国外业务伙伴交流的窗口。
    在之前提到的整个业务环境中，实际的需求方是本公司，也即甲，但由于自身贸易条件的限制，他无法直接向国外供应商即丙方进口原材料，只能通过贸易公司及乙方来代理采购事宜，那么简单点讲，这个过程便是甲下采购订单给乙方，乙方根据甲的需求像丙方下达采购订单，在乙方受到丙方提供的物料后再以销售订单的方式将该批物料销售给甲。在这个过程当中我们必须看到：
1.甲在下达给乙方的采购订单上所使用的价格应当为转移价格，或者以标准成本作为价格基数。
2.乙方在下达给丙方的采购订单上所使用的价格应当为采购价格，这一价格的定义应当是乙方代表甲和丙方所达成的采购价格。
3.当丙方将物料运至乙方指定的港口处时，乙方有责任递交并跟踪报关事宜。
4.乙方向甲所下达的销售订单价格也以转移价格为基准，或者直接以标准成本作为价格基数。
5.甲在提货时必须提供相关单据如采购订单，发票等作为提取该货位的清关依据。
    那么在系统中上述要点又是如何体现的呢？
    由于需求来源于甲，所以整个业务的触发点是甲下达采购订单给乙方并托乙方向供应商下达采购订单。
   
    在上面的图解中我需要指出的是，供应商虽然最终目的是将物料送至甲，但经过乙方还有一个报关清关的过程，因此，实物实际上是先经乙方再去到甲的。
    如果将上述过程反映到系统中去其实是很简单的，无非是采购订单和销售订单的创建问
题，只是需要注意的是在乙方公司如果将甲设置成内部业务伙伴那么必须为它另外创建一个新的客户代码，这是因为Baan V环境不允许销售订单下给内部业务伙伴导致。
    对于Buy-Sell，需要说明的是这种模式操作起来比较简单，所以用户在理解上大概不会有太大的问题，但是值得一提的是，采取Buy-Sell的方式却会在无形中将甲公司的工作转移到乙方公司上去，第一，由于甲是需求来源方，尽管物料的采购最终是为甲进行的，但由于系统库存是经过乙方转卖给甲的，这里面无形中导致了乙方在库存管理上的投入，当然还有报关工作的参与及订单的跟踪，毕竟对于整个采购过程来讲，乙公司的采购订单才是关键订单。
    而另一种处理模式---Triangular Purchasing，实际上是对Buy-Sell模式的一种合并和简化，当然这里的简化从一定意义上来讲是系统控制上的简化，将整个过程的主体全部转移到甲公司上，而不需要作为贸易公司的乙公司参与采购订单的运行，当然付款则是需要乙公司参与进来的。
那么接下来就让我们来看看该种模式在系统中是如何运作的。
首先，我们先来看一下下面这个图示。
   
    上面的图示简单地描绘了物料在两公司之间的流转，很明显，这种模式下采购订单是直接由甲公司发往供应商的，但需要注意的是在该订单中的采购部分Financial Company归属必须是乙公司，这是进行Triangular Purchasing的第一个条件。另外，当供应商将物料送至乙公司的仓库等待报关时，报关资料的提交方通常为甲公司而不是乙公司自己，如果甲公司不是位于特殊港口如深圳，珠海等地那么他必须在每提一次货的时候便进行一次报关，而不能每月结关一次，而这也给操作上带来一定的障碍，采购提前期无形中增加了。说回物料交至乙公司仓库时（通常这个仓库是以托管的方式在处理的）甲公司必须在系统中对该PO进行收料操作，其接收仓库即该仓库在甲公司系统中的对应仓位，而该仓位的归属性同上述采购部门一样，它的EU是分开的。这是进行Triangular Purchasing的第二个条件。那么当甲公司需要将存放在乙公司的物料拖往内地时，甲公司必须在系统里通过一张移库单来完成系统上的交接，在这个过程中系统会有个Invoicing的过程，当然前提是你在Entity-Entity Relationship中定义了这两个仓位之间的贸易关系。
    当物料转移结束后也即物料成功地从乙方送至了甲方。但是，在整个过程中我们又不得不提出这样几个问题：
1.甲公司在提货的过程中以什么文件进行报关？采购订单？发票？
2.物料从乙公司转至甲公司，尽管系统上可以通过移库来完成，但如何保证物料从出到收刚好就是符合系统操作的？我们如何控制在途物料丢失的风险，又如何能够在移库的过程中反映这一层可能性？
    当然，并不是所有的公司都会遇到上述两个问题，但对于业务环境类似于文中所描述
的那样的公司就必须要先给出一个合理的答案方能将该模式顺利地进行下去。
    在这里我暂时不谈我的想法，希望有兴趣的朋友可以和我一起探讨这个业务模式以及解决方案，同一个方法见仁见智，相信在不断的交流过程中我们还能继续完善这个模型。
    虽然对于一开始谈到的业务环境我给出了上面两种解决方案，但实际上没有哪一种能说的上是最好的。对于不同的应用环境，基于不同的用户群及要求我们必须因地制宜，要知道业务解决方案永远没有最好的，只有最合适的。

abc006

嗯,寫得很不錯,學習了!