转：SAP 零售业POS心得分享
分类： SAP-retail 2010-03-09 09:36 751人阅读 评论(0) 收藏 举报
最近看了一些SAP进行中的零售业项目，觉得有些心得，希望透过本篇文章让大家多了解SAP跟零售业POS连接的做法，能够更顺利地完成项目的导入。
一般在讨论POS跟SAP的应用时，多半都是属于零售业的专案。这几年SAP导入的客户中不乏零售业的翘楚，举凡松青超市、星裕国际、新光三越、统一星巴克、太平洋崇光百货等等都是各零售业中的代表。进行中的陆续也还有饭店跟餐厅的案子，但基于NDA，我就不多说了。
不过SAP在零售业的导入项目中，有一个关键，也是目前我观察业界中很多有趣的现象，闲来无事，所以就决定提一提。这个关键就是将外部POS系统的每日营运数据转入SAP中，或是将SAP中的物料编码或定价策略等转出到POS中的方法。简称POS Inbound/Outbound。由于两者并提范围太大的关系，所以就简单谈谈POS Inbound的作法，这就很有趣了。
POS Inbound往往因为不同的顾问公司所以手法不太相同。有些公司使用的是正宗的SAP POS Inbound作法，利用IDOC将数据由外部POS系统透过Flat File转入至SAP系统中，但有些公司会先说SAP没有标准的零售业解决方案，所以他们使用的就是用外挂程序的方式，一样透过Flat File将数据转入SAP系统中。至于会采用哪一种方式，看客户跟顾问的沟通而定。不过，全球一堆百货公司在使用的SAP解决方案，每次Gartner Magic Quadrant都挂SAP在零售业解决方案中的前几名，这样会没有标准的POS Inbound功能呀。哇塞，原来全世界大家都用外挂的方式在处理，不觉得这是件很神奇的事吗？
其实SAP原本就已经发展了一整套成熟的POS Inbound机制，包括转入数据比对、数据历史纪录、数据错误追踪跟转入SAP Billing的作法。基本上，无论是在错误的比对，或是与SAP标准如COPA、SIS的配合上，都是最完整的作法。不过问题就是进入门坎较高，因为顾问除了必须了解FI跟SD的内容之外，还需要了解IDOC的处理机制跟POS Inbound的运作流程。因此需要多方的通力合作才能够完成，所以，不是每一个顾问公司都做得来的。
也因此，有些顾问公司在遇到同样需要运作POS系统的客户时，就思考利用其它的方法来处理，也就是外挂。这一点也不是不好，但就是让人觉得很神奇的，明明人家已经处理好的Solution，为何还要绕一大圈路？而且做出来的程序还要一堆Debug跟测试，说不定成果还没有原来的好。
这样的解决方法的成因主要有几个，第一个是客户不懂，以为SAP对POS这一块没辄。第二个是因为顾问搞不懂，反正做不出来就外挂。第三个就是顾问公司的PM或高层太厉害，一直去说服跟沟通，摸一摸头就让客户买单了。之所以会使用这样的作法我猜其实有部分也是因为可以推到SAP软件方的错，也就是”反正最后都是SAP烂，没有标准的作法，所以我们做的也不怎样，一切都是SAP的错”，这一类的说辞。会不会这样子我不清楚，但我相信一定有案子是这样的解决方法。所以，如何挑选一个合适的顾问公司就至关重要。至于如何挑选一个合适的顾问公司，请详前文。
不过，缺乏详细的比较基础，前文的三言两语，对于实事求是的我们，实在很难说服外挂一定比标准的Solution差或好。所以，还是针对几个差异来说明一番，免得各位会觉得我在胡吹。
第一个是转入/转出的方式，SAP跟POS或其它接口沟通的模式不外乎就是汇出/汇入跟前后时间的数据差异。在汇入方面，SAP转入POS资料主要会是在SD端的Billing。也就是把某时期由POS系统收集的发票信息转入到SAP系统中立即立会计帐跟产生后续分析的数据基础。由于是Billing的关系，所以可以马上使用的就是FI的报表、SIS跟COPA几种工具。SAP不但可以直接将转成IDOC格式的POS数据逐笔转入至Billing跟立会计帐，也同步更新如SIS跟COPA的数据，如果User在主文件数据区分得很细致的话，可以实时获得如毛利分析表、销售统计等分析报表的同步更新。
至于外挂的话，就看要做到怎样的程度了。要建到Billing吗？那还要有料号跟价格策略，太麻烦了。简单一点，那就直接切传票好了，然后把要分析的数据一样切COPA文件即可。这样看起来好像简单多了，撇开多花的开发时间跟成本，这样的策略舍去了”产品”这个重要的因素，从此POS传回SAP的销售数据，产品只能放在传票中的备注栏跟COPA文件中。一些如产品阶层与客户阶层、客户进销退与产品的交互分析等传统SIS可以使用的分析工具就全部失效了。
另外一个差异是付款方式跟交易型态。一般的零售业，除了商品定价有千变万化的组合之外，其中一个复杂的就是付款方式了。举凡现金、商品礼券、现金礼券、信用卡(Master/Visa/AMX/Dinner)、提货单、支票、公司卡、代用券等都可以是支付方式之一。应该说除了以物易物不被接受之外，其它应都可被接受。至于支付的行为也是千变万化，有预售、预售结帐、事后登录、订金、订金结帐有尾款、订金结帐无尾款、尾款缴款、订金退回、订金结帐退回、订金解约、预售解约等。付款方式跟支付行为两者是一个矩阵关系，都有可能会发生这样的可能性。因此，理论上上述的情境有88种组合。我个人是真不知道搞这么复杂是要做啥？因此，做了零售业的项目之后，我放弃了这辈子开咖啡店、卖面或民宿之类的主意。
所以，这么多的付款方式跟支付行为，基本上外挂也是很难写。更何况是每个组合都要来来回回测试。我想应该是会搞得人仰马翻才是。不过，标准的SAP POS Inbound就可以透过设定做出这些变化。更胜者，有些客户会有现金礼券做预售但是退货时不能做现金的科目回转，也就是只能退提货券。这一点虽然公平交易委员会好像有说明是违法行为。但是客户要求，我们还是要在系统上实现。 还有一个差异是库存的进耗存。透过POS Inbound的功能，我们可以在系统中进行Movement type 251, 252的交易。也就是将库存从各商店中透过销售或退货的方式做销货发货跟退货并产生销货成本的异动。此外，除了销售的功能之外，采购端的进出货，也可以透过POS Inbound的方式自动建立PO及GR。这一点不知道写外挂的顾问公司有考虑到吗？我想没有零售业不想管理商店里的库存并实时获得最新的统计信息吧。
最后一个差异，也是一般转档进SAP最讨厌的事情，就是数据Delta跟错误处理。在Delta处理方面，SAP POS Outbound会控制系统内客户、物料及价格等前次转出跟此次转出间的差异。不过这并不在本文的范围内，至于在Inbound的部分，通常转入的都是当天结帐后的POS数据，所以多半不会有数据Delta的部分。但是在错误处理方面，POS Inbound就发挥其能耐了。一般POS转入的数据一次多不会少于万笔的数据，如果少于万笔的话，那我不建议导入SAP，因为您的商店消费者人数还不够支撑导入的费用。在这破万笔的数据中，难免会有一些数据异常的错误，包括格式错误跟数据错误，如付款方式跟金额错误。POS Inbound在格式错误方面，会将该笔错误数据拦截，但后续正确数据仍允许转入系统中，管理者只需要在每次转入后列出少数错误格式的数据，人工修正后就可再将其转入。如果是数据错误的话，同样可以用人工处理的方式模仿POS Inbound的作业将修正后的差异转入到系统中。
如果是外挂的话，恭喜您中宾果。
经过这些分析，各位，您应当了解不同的导入方式会有截然不同的成果，套句张老师的话，好的方式让各位上天堂，坏的方法让各位住套房了。不过，我还是建议，如果您的顾问没有使用SAP标准与POS连接的部分，还请再询问一次。虽然说不是花了钱就是老大，但我认为要求使用SAP标准的作法，是在合理的范围内。还希望这次的文章能对各位在解决方案的选择上有些帮助。
