DB Design: 该从哪个table读取product cost

hornsay

最近在update 自己的程序，主要是加 inventory control 这部分。因为已经有Product table了，所以这次加了2个tables: PurchaseOrder and PurchaseDetail.

我想请教一下如何去读取product cost, 就是每次卖掉一个product, 系统应该自动去减掉一个quntity on hand, 同时要get product cost, 但是这product cost在不同的purchase 是不同的，所以这个cost应该读自PurchaseDetail还是应该读之product table?

azurej

那就要看你是用什么valuation method了
比如你是用real time APP的 那每次只要把当前系统里的cost减掉cost * 1
如果你是用FIFO的 那你就要找到相对应的PO 找出COST然后减掉
又或者你是用standard cost的 那只要把系统里master data的cost减掉cost * 1就好了

stevenbian

没看懂这和数据库设计有啥关系。
product表里应该存放指导价格，purchase detail里应该是实际价格。

hornsay

原帖由 azurej 于 2011-11-18 15:40 发表
那就要看你是用什么valuation method了
比如你是用real time APP的 那每次只要把当前系统里的cost减掉cost * 1
如果你是用FIFO的 那你就要找到相对应的PO 找出COST然后减掉
又或者你是用standard cost的 那只要把系统里master data的cost减掉cost * 1就好了

我是用real time 来计算。

刚才想了一下，FIFO可能在db integrity方面会有一些问题。感觉用average cost比较好，就是每次purchase order completed, 系统应该update product table的quantity on hand, 同时计算product table的average cost. 即 quantity on hand = quantity on hand ＋ｎｅｗ　ｏｒｄｅｒ　ｑｕａｎｔｉｔｙ，　ｃｏｓｔ　＝（ｏｌｄ　ｑｕａｎｔｉｔｙ　ｏｎ　ｈａｎｄ＊ｃｏｓｔ＋ｎｅｗ　ｏｒｄｅｒ　ｑｕａｎｔｉｔｙ＊ｎｅｗ　ｃｏｓｔ）／ｎｅｗ　ｑｕａｎｔｉｔｙ　ｏｎ　ｈａｎｄ．

这样基本上不会有ｉｎｔｅｇｒｅｔｙ　ｐｒｏｂｌｅｍ，　未来计算方面也比较方便一些。

hornsay

原帖由 stevenbian 于 2011-11-18 15:53 发表
没看懂这和数据库设计有啥关系。
product表里应该存放指导价格，purchase detail里应该是实际价格。

如果读ｐｕｒｃｈａｓｅ　ｄｅｔａｉｌ的实际价格，那ｐｕｒｃｈａｓｅ　ｄｅｔａｉｌ就必须加一个ｏｎ　ｈａｎｄ的ｃｏｌｕｍｎ，但这样会出现２个ｑｕａｎｔｉｔｙ　ｏｎ　ｈａｎｄ，　一个在ｐｒｏｄｕｃｔ　ｔａｂｌｅ，　一个在ｐｒｕｃｈａｓｅ　ｄｅｔａｉｌ，我想这样ｄｅｓｉｇｎ不是很好。

典

不懂你的Cost是什么概念，最好问会记，不同的cost本身有不同的算法，要看你的真实目的是什么，
先进先出？先进后出？

hornsay

原帖由 典 于 2011-11-18 16:11 发表
不懂你的Cost是什么概念，最好问会记，不同的cost本身有不同的算法，要看你的真实目的是什么，
先进先出？先进后出？

这个ｃｏｓｔ就是某一个ｐｒｏｄｕｃｔ进货的价格，想通过这个价格知道货卖掉后的ｍａｒｇｉｎ，　不是用在ａｃｃｏｕｎｔｉｎｇ上面的。只是让用户知道整个这段时间的ｍａｒｇｉｎ多少，能够了解整个销售的情况。

azurej

原帖由 hornsay 于 2011-11-18 16:02 发表


我是用real time 来计算。

刚才想了一下，FIFO可能在db integrity方面会有一些问题。感觉用average cost比较好，就是每次purchase order completed, 系统应该update product table的quantity on hand, 同时计算produc ...

理论上是这样 可是你有没有想过万一你PO goods 已经收到系统里面去了 但是Purchase Invoice还没有收到 当你过几天收到的时候发现价格和你的PO有出入而你已经卖掉一部分的货物了 这种情况你要怎么处理呢？
现实生活中我觉得PO COMPLETE不会那么理想
你算APP的时候也要考虑到怎么去adjust那些已经卖掉的货物with incorrect cost

hornsay

嗯，这个有道理。

但这样系统是不是会变得更复杂？我在ｐｕｃｈａｓｅ　ｏｒｄｅｒ里有个ｓｔａｔｕｓ，　只有在ｓｔａｔｕｓ是ｃｏｍｐｌｅｔｅｄ才会去ｕｐｄａｔｅ　ｐｒｏｄｕｃｔ　ｔａｂｌｅ．　所以基本上应该是拿到ｉｎｖｏｉｃｅ后才ｃｈａｎｇｅ　ｓｔａｔｕｓ．但事后因为某种原因追加ｉｎｖｏｉｃｅ，　我这样的ｄｅｓｉｇｎ确实无法ｈａｎｄｌｅ了。

如果有意外，那只能手动去修改ｐｒｏｄｕｃｔ　ｔａｂｌｅ的ａｖｅｒａｇｅ　ｃｏｓｔ了。　

但是ＦＩＦＯ也有麻烦，就是你的产品卖掉后又被客户退回来，那这个产品你不知道是从来源于哪个ｐｕｒｃｈａｓｅ．

glen

Moving avg cost seems good for this purpose

hornsay

谢谢。

一直被这个ｉｓｓｕｅ难倒，迟迟没有下手。昨天一边在做一边在想，是ａｚｕｒｅｊ的回复让我有了灵感。我觉得这是一个不错的ｓｏｌｕｔｉｏｎ，主要是计算更方便，ｉｎｔｅｇｒｉｔｙ也很好，而且也ｈｕｍａｎ　ｒｅａｄａｂｌｅ。