300分讨论(稍后加够)：关于进销存系统中如何避免采购退货，也就是商品退回供应商
300分讨论(稍后加够)：关于进销存系统中如何处理采购退货，也就是商品退回供应商？
我是第一次做进销存，都是自己摸索，感觉采购退货非常不好处理，和客户商讨了很久，制定了如下流程：
1，生成退货单：选择供应商，要退的商品，数量，退货价格等。
2，输入退货结果：这个一个单独的模块，就是针对每条退货商品记录，选择几种退货结果：换货，冲抵货款，或者报废。
这三种情况在退货的时候都可能发生，甚至有可能一种商品就会有几种情况，例如：10个商品，供应商只承认8个，而只有存活5个，那么退货的结果就是：换货5个，冲抵货款3个，报废2个。而上述的状况在客户的业务中是必须考虑的。
3，根据退货结果生成退货结果单，提交后，经财务审核，完成此次退货。当然财务审核后，系统会自动生成相应的财务记录，如应收账款等。
这样做了下来，我还是觉得过于繁琐，但和客户讨论了很多次，总觉得每一步都无法省略，所以想请教大家，这里应该如何实现？
------解决思路----------------------
僵哥讲的不错，其实楼主你还是去了解一下具体的 行业需求吧，这个东西和需求紧密相连，不能以我们自己的想法去做行业软件，进销存看似简单的系统，其实里面牵扯的环节很多，如果你不深入了解一下业务流程，很难做的
------解决思路----------------------
做采购退货单，也没什么繁琐的，退货给你厂家，是有几个退货条件的，比如换货(由于从厂家进错了)、报废(由于从客户那里退货回来，再退回给厂家，这个可能比较少见的)、冲抵货款(只不过退款而已)。
你也不需要是去理会“退货的结果就是：换货5个，冲抵货款3个，报废2个。而上述的状况在客户的业务中是必须考虑的。”这些原因的，按单录入退货单就可以了。
然后就是在付款时，做退货款就可以了，这样才使得应付与已付平衡了。
------解决思路----------------------
所以没有必要去理会客户的各种原因
------解决思路----------------------
從樓主目前這種情況來看一般只是换货的應該開退貨單，而且要求退貨單上指定采購單；
這樣可以用退出的采購單收每二次的數量(换货)。如果是內部使用產生报废，當然要開报废單，這個
和廠商沒有關係，但是如果是廠商的物料有問題要报废，那樣也是用退貨退給廠商，廠商要怎樣
處理是他的事了。反正他不補貨，就扣錢。至於冲抵货款一般是用憑證(傳票)來做，因為加權單價
一般是采購單價來算的(進，退貨都要有采購單價)。這樣你的加權單價就會好做些。
------解决思路----------------------
"楼主的这个问题,跟先进先出还是后进先出没有关系,那是成本核算的问题."
个人觉得,在做这个退货流程时,如果了解到财务成本核算规则等,可能会更好的做出符合实际的操作流程,这样为后期的财务上的处理可能会更好一些.
------解决思路----------------------
說個思路：
數據 + 動作 + 操縱者。
把商品庫存視為數據， 將企業本身，客戶，供應商視作操縱數據的操縱者，每一個動作都將產生不同的數據結果，就構成了進銷存。將動作分類索引統計，移交財務，這樣就能將 庫存數據 與 財務數據 切分成兩個系統。
將企業所有的庫存動作都歸納出來，放入一個"動作關系表"。每個動作對應的單據及產生的庫存結果及財務結果在動作表上做出標識。（這樣進出庫動作可以自定義，可以滿足不同企業有不同的動作。）
當庫存系統與財務系統隔離的時候。庫存只管庫存是不管金錢的。財務系統可以通過“動作”找到原始單據，查詢出單價然後依據財務規則來計算單價及其他財務金額。這樣寫庫存系統的人可以不管財務規則。模塊間就能良好隔離。
你的問題在於： 退貨這個動作，與什麼對象相關，會產生怎樣的結果。
財務需要什麼樣的結果，庫存又需要什麼樣的結果。總結一下這些數據，明確數據的流向，對於編寫程序有益。
編程就是： 數據 ＋ 算法 ＋ 用戶操作界面(後台程序的用戶界面是為前台提供接口)。數據庫程序更是如此。
前台界面友好則最終用戶喜歡，後台程序接口良好，則程序員喜歡。
常見進銷存的數據流向:
原始單據 －－＞算法A－－＞庫存數據－－＞算法C－－＞統計庫存...
－－＞算法B－－＞財務數據－－＞算法D－－＞計算成本
將系統中的各個對象（商品，庫存，供應商，客戶，金錢...）通過動作的聯系起來，理直這些關系，這樣就有底氣了。就慢慢明白面向對象編程方法 其實就在我們日常生活中......
方法論中難題的解決過程： 分析現象->提出猜想->實踐驗證->總結經驗
(我不懂業務規則的，具體規則別問我。)
------解决思路----------------------
僵哥跑了~...
------解决思路----------------------
另外用批次管理的话，就会大大增加用户管理难度的(也就是说用户的管理上了很高的一个层次)，用户的仓库与开单要非常紧密的结合，否则批号很容易乱的。
我是第一次做进销存，都是自己摸索，感觉采购退货非常不好处理，和客户商讨了很久，制定了如下流程：
1，生成退货单：选择供应商，要退的商品，数量，退货价格等。
2，输入退货结果：这个一个单独的模块，就是针对每条退货商品记录，选择几种退货结果：换货，冲抵货款，或者报废。
这三种情况在退货的时候都可能发生，甚至有可能一种商品就会有几种情况，例如：10个商品，供应商只承认8个，而只有存活5个，那么退货的结果就是：换货5个，冲抵货款3个，报废2个。而上述的状况在客户的业务中是必须考虑的。
3，根据退货结果生成退货结果单，提交后，经财务审核，完成此次退货。当然财务审核后，系统会自动生成相应的财务记录，如应收账款等。
这样做了下来，我还是觉得过于繁琐，但和客户讨论了很多次，总觉得每一步都无法省略，所以想请教大家，这里应该如何实现？
------解决思路----------------------
僵哥讲的不错，其实楼主你还是去了解一下具体的 行业需求吧，这个东西和需求紧密相连，不能以我们自己的想法去做行业软件，进销存看似简单的系统，其实里面牵扯的环节很多，如果你不深入了解一下业务流程，很难做的
------解决思路----------------------
做采购退货单，也没什么繁琐的，退货给你厂家，是有几个退货条件的，比如换货(由于从厂家进错了)、报废(由于从客户那里退货回来，再退回给厂家，这个可能比较少见的)、冲抵货款(只不过退款而已)。
你也不需要是去理会“退货的结果就是：换货5个，冲抵货款3个，报废2个。而上述的状况在客户的业务中是必须考虑的。”这些原因的，按单录入退货单就可以了。
然后就是在付款时，做退货款就可以了，这样才使得应付与已付平衡了。
------解决思路----------------------
所以没有必要去理会客户的各种原因
------解决思路----------------------
從樓主目前這種情況來看一般只是换货的應該開退貨單，而且要求退貨單上指定采購單；
這樣可以用退出的采購單收每二次的數量(换货)。如果是內部使用產生报废，當然要開报废單，這個
和廠商沒有關係，但是如果是廠商的物料有問題要报废，那樣也是用退貨退給廠商，廠商要怎樣
處理是他的事了。反正他不補貨，就扣錢。至於冲抵货款一般是用憑證(傳票)來做，因為加權單價
一般是采購單價來算的(進，退貨都要有采購單價)。這樣你的加權單價就會好做些。
------解决思路----------------------
"楼主的这个问题,跟先进先出还是后进先出没有关系,那是成本核算的问题."
个人觉得,在做这个退货流程时,如果了解到财务成本核算规则等,可能会更好的做出符合实际的操作流程,这样为后期的财务上的处理可能会更好一些.
------解决思路----------------------
說個思路：
數據 + 動作 + 操縱者。
把商品庫存視為數據， 將企業本身，客戶，供應商視作操縱數據的操縱者，每一個動作都將產生不同的數據結果，就構成了進銷存。將動作分類索引統計，移交財務，這樣就能將 庫存數據 與 財務數據 切分成兩個系統。
將企業所有的庫存動作都歸納出來，放入一個"動作關系表"。每個動作對應的單據及產生的庫存結果及財務結果在動作表上做出標識。（這樣進出庫動作可以自定義，可以滿足不同企業有不同的動作。）
當庫存系統與財務系統隔離的時候。庫存只管庫存是不管金錢的。財務系統可以通過“動作”找到原始單據，查詢出單價然後依據財務規則來計算單價及其他財務金額。這樣寫庫存系統的人可以不管財務規則。模塊間就能良好隔離。
你的問題在於： 退貨這個動作，與什麼對象相關，會產生怎樣的結果。
財務需要什麼樣的結果，庫存又需要什麼樣的結果。總結一下這些數據，明確數據的流向，對於編寫程序有益。
編程就是： 數據 ＋ 算法 ＋ 用戶操作界面(後台程序的用戶界面是為前台提供接口)。數據庫程序更是如此。
前台界面友好則最終用戶喜歡，後台程序接口良好，則程序員喜歡。
常見進銷存的數據流向:
原始單據 －－＞算法A－－＞庫存數據－－＞算法C－－＞統計庫存...
－－＞算法B－－＞財務數據－－＞算法D－－＞計算成本
將系統中的各個對象（商品，庫存，供應商，客戶，金錢...）通過動作的聯系起來，理直這些關系，這樣就有底氣了。就慢慢明白面向對象編程方法 其實就在我們日常生活中......
方法論中難題的解決過程： 分析現象->提出猜想->實踐驗證->總結經驗
(我不懂業務規則的，具體規則別問我。)
------解决思路----------------------
僵哥跑了~...
------解决思路----------------------
另外用批次管理的话，就会大大增加用户管理难度的(也就是说用户的管理上了很高的一个层次)，用户的仓库与开单要非常紧密的结合，否则批号很容易乱的。