进销存设计思路

from:http://search.csdn.net/Expert/topic/560/560566.xml?temp=.1193354
我陆陆续续地做了一段时间进销存相关的东东，看到大家的讨论，真有一种相见恨晚的感觉，许许多多熟悉的问题在大家的讨论下变得如此有趣，现在我想聊聊我自己关于进销存软件大概流程的看法，请各位不吝斧正：
   订单是进销存业务的基本操作手段，用订单可以直观全面地记录每一笔业务过程。进销存业务中最重要的就是理清商品以及款项的流动，所以订单中的关键动作就是对商品数量和款项变化的控制和记录。由于订单是对单笔业务的记录，所以必须用其它方法记录某一时间段内每种商品在所有业务中涉及的数量及金额的累计数，这就是总帐。基于订单的进销存描述可以简单地概括为：
  在期初建帐时就记录好已经有了多少商品，价值几何，以此作为基础并记录到总帐；然后进行采购，买进某种商品，这时候总帐中该商品的累计数（包括数量和金额累计）增加了，同时也产生了对供应商的应付款记录；再进行销售，卖出某种商品，这时候总帐中该商品的累计数（包括数量和金额累计）减少了，同时也产生了对客户的应收款记录；经过一段时间的买卖，当然要清楚地知道自己到底还有多少商品，很自然地我们也是到总帐中去查，此时当然没有必要了解每项业务的累计数，只要知道那个时间段最后还剩多少商品就可以了，也就是商品的期末数量，由于商品破损等其它原因，计算机系统上总帐的期末数量和公司实际库存可能不符，这时候必须以实际库存为准进行以后的业务，这就是盘点的原因；对于公司而言，商品的变化不仅仅是买进卖出，可以有其它的方式如：厂家赠送、商品借出、库房间调拨等，这些方式在是否产生利润的角度上与采购、销售不同，所以也必须用独立的单据来记录。
  以上就是进销存业务的简单描述，在这些业务订单收集的数据基础上，就可以进行统计和分析，得出采购、销售等分析报表。

  呵呵，希望我的一些粗浅观点没有误导各位，我提到的订单就是对销售单据，采购单据的抽象而已，以下是我的一些设计思想：
在表设计中，我尝试过两种方法：
把销售单、采购单等等单据用同一个实体表示，然后通过单据类型的字段来标识，因为单据设计到商品的出入，所以单据类型必须有出入状态标志。这样做的理由是：
1、符合OO的设计思想，把订单做为一个类
2、代码重用性好，效率高
3、有利于业务扩展，通过对订单类继承，增加接口方法就可以增加新的业务
在实现过程中，特别是数据库设计中，这种思想产生了一些很小的表，个人感觉是否应该把这些表硬编码，但这样就失去了扩展性

当然也可以分单，即把每个单看成单独的实体，这样实现有这几个好处：
1、对于业务量大的企业，分单有利于减轻数据查询的复杂度；
2、程序员实现时，编码的复杂度降低，代码可读性也好；
3、帐套业务数据备份时更灵活，可以对不同的业务单独备份；
但是这样的设计抽象级别低，代码重用的效率不高

另外toideage(莲花宝典)：我个人觉得财务与业务软件不一定要连在一起，我们公司与国内一家财务软件大牛公司关系很密切，我们的二次开发中心更多时候是给我们的客户作该财务软件与其它业务软件（如进销存）的接口。当然财务业务一体化是很理想的，也是客户的梦想，但正如楼上高手说的，财务已经有了固定的流程，而业务确千差万别（虽然在基本模型上有共同之处），不管财务软件公司多牛，他也不可能提供通用的业务软件，这可不是大话，UF/KD等大牛门有好用的业务软件吗，到现他们都不说自己是财务软件公司了，说什么企业管理total sulotion，呵呵，SAP不是一天就成功的，也正因为如此，大伙儿才有机会做多如牛毛的中小进销存系统，不过这样的日子也不会很久了，国家经济环境规范化，行业规范化，这将会导致企业业务的逐渐规范化，同时软件技术特别是系统设计分析方法的成熟，也将提出合理的业务模型，在这些模型上对业务流的构造甚至可以下放到用户，不可能吗？就算业务模型以框架构件的方式发布，开发的门槛就很低了，大伙考虑过没有，那时，谁动了我们的奶酪？噢，扯远了，sorry