300分讨论(稍后加够)：关于进销存系统中如何处理采购退货，也就是商品退回供应商？

Question

我是第一次做进销存，都是自己摸索，感觉采购退货非常不好处理，和客户商讨了很久，制定了如下流程：
1，生成退货单：选择供应商，要退的商品，数量，退货价格等。
2，输入退货结果：这个一个单独的模块，就是针对每条退货商品记录，选择几种退货结果：换货，冲抵货款，或者报废。
   这三种情况在退货的时候都可能发生，甚至有可能一种商品就会有几种情况，例如：10个商品，供应商只承认8个，而只有存活5个，那么退货的结果就是：换货5个，冲抵货款3个，报废2个。而上述的状况在客户的业务中是必须考虑的。
3，根据退货结果生成退货结果单，提交后，经财务审核，完成此次退货。当然财务审核后，系统会自动生成相应的财务记录，如应收账款等。这样做了下来，我还是觉得过于繁琐，但和客户讨论了很多次，总觉得每一步都无法省略，所以想请教大家，这里应该如何实现？

Answer 1

說個思路：數據 + 動作 + 操縱者。把商品庫存視為數據， 將企業本身，客戶，供應商視作操縱數據的操縱者，每一個動作都將產生不同的數據結果，就構成了進銷存。將動作分類索引統計，移交財務，這樣就能將  庫存數據  與  財務數據  切分成兩個系統。將企業所有的庫存動作都歸納出來，放入一個"動作關系表"。每個動作對應的單據及產生的庫存結果及財務結果在動作表上做出標識。（這樣進出庫動作可以自定義，可以滿足不同企業有不同的動作。）當庫存系統與財務系統隔離的時候。庫存只管庫存是不管金錢的。財務系統可以通過“動作”找到原始單據，查詢出單價然後依據財務規則來計算單價及其他財務金額。這樣寫庫存系統的人可以不管財務規則。模塊間就能良好隔離。你的問題在於：  退貨這個動作，與什麼對象相關，會產生怎樣的結果。 
財務需要什麼樣的結果，庫存又需要什麼樣的結果。總結一下這些數據，明確數據的流向，對於編寫程序有益。
編程就是：  數據  ＋  算法  ＋  用戶操作界面(後台程序的用戶界面是為前台提供接口)。數據庫程序更是如此。
           前台界面友好則最終用戶喜歡，後台程序接口良好，則程序員喜歡。
常見進銷存的數據流向: 
原始單據  －－＞算法A－－＞庫存數據－－＞算法C－－＞統計庫存...
          －－＞算法B－－＞財務數據－－＞算法D－－＞計算成本
將系統中的各個對象（商品，庫存，供應商，客戶，金錢...）通過動作的聯系起來，理直這些關系，這樣就有底氣了。就慢慢明白面向對象編程方法  其實就在我們日常生活中......
方法論中難題的解決過程： 分析現象->提出猜想->實踐驗證->總結經驗(我不懂業務規則的，具體規則別問我。)

Answer 2

说个思路： 数据 + 动作 + 操纵者。 把商品库存视为数据， 将企业本身，客户，供货商视作操纵数据的操纵者，每一个动作都将产生不同的数据结果，就构成了进销存。将动作分类索引统计，移交财务，这样就能将  库存数据  与  财务数据  切分成两个系统。 将企业所有的库存动作都归纳出来，放入一个"动作关系表"。每个动作对应的单据及产生的库存结果及财务结果在动作表上做出标识。（这样进出库动作可以自定义，可以满足不同企业有不同的动作。） 当库存系统与财务系统隔离的时候。库存只管库存是不管金钱的。财务系统可以通过“动作”找到原始单据，查询出单价然后依据财务规则来计算单价及其它财务金额。这样写库存系统的人可以不管财务规则。模块间就能良好隔离。 你的问题在于：  退货这个动作，与什么对象相关，会产生怎样的结果。 
财务需要什么样的结果，库存又需要什么样的结果。总结一下这些数据，明确数据的流向，对于编写程序有益。 
编程就是：  数据  ＋  算法  ＋  用户操作界面(后台程序的用户界面是为前台提供接口)。数据库程序更是如此。 
          前台界面友好则最终用户喜欢，后台程序接口良好，则程序员喜欢。 
常见进销存的数据流向: 
原始单据  －－＞算法A－－＞库存数据－－＞算法C－－＞统计库存... 
          －－＞算法B－－＞财务数据－－＞算法D－－＞计算成本 
将系统中的各个对象（商品，库存，供货商，客户，金钱...）通过动作的联系起来，理直这些关系，这样就有底气了。就慢慢明白面向对象编程方法  其实就在我们日常生活中...... 
方法论中难题的解决过程： 分析现象->提出猜想->实践验证->总结经验 (我不懂业务规则的，具体规则别问我。)----------------------------------领教了！