有关开发我的进销存应用的一系列问题？可能需要较长时间！但分数可观！(200分)

我准备开发一个进销存应用，但由于第一次开发这样的应用，很多财务上和技术上的问题
不懂，我准备每遇到一个自己确实不能解决的问题就在这里提出来，不是一次性提出，而是
每遇到一次就提出，因为时间紧，不可能一次性提出等大家回答，因为提出问题通常都要
一定时间回答，我可以在这段时间暂时先搞定其他内容！

如果不够分大家可以提出来！我有1500多分，可以拿出来！

问吧，我这个月开发了四个了，实在累。业务规则一个比一个复杂，郁闷。

我也开发了一个，不过在安全性上经验不够，想和大家探讨一下

关注

listen[]

这方面我是新手，希望各位大侠帮助！我想那位一个月开发四个的先生应该是很专业吧？
郁闷是不是没有新意的意思？

呵呵，真得很没真意，真正要有新意是深入的理解与分析管理中的枝节，做出更能提升
企业管理水平的软件结构才是有意思。为此我把一家公司的业务规程全改了。不过，不好
意思，我是商务管理与计算机双专业的。单独做其中一行都没意思，呵呵[]

关注。

这么厉害，你是双专业还是双学位？

首先希望大家能够仔细看看，因为很多，我怕写得不详细大家误会我的意思，麻烦了，请原谅！
因为是进销存，所以涉及到很多单据（都是主从结构），如销售单：
我是这么做的：单据号，日期，经手人，总金额，备注（还有其他）等做一个主表；
商品号，商品名称，商品单价，数量，商品总价等做从表；
其他相关的：仓库、交易单位等信息有其他表暂不讨论。
这样做好不好？
上面是销售单的，下面是进货单：
因为进货单和销售单的结构（都是两个主从表，而且字段基本一样）一样，那么
是否可以将销售单的两个表用于进货单，只不过增加一个字段说明是销售单或进货单，
并且在金额字段用正或负数来表示，这样计算起来可能比较方便（同表计算应该方便？）
而且也不用再增加两个表来单独用于进货单。不过其他帐单，我还是准备用单独表来做？
不知好不好？
还有一个问题：
先说明一下：
我的每张单据都要使用2个Table或2Query（在设计时就存在，
不是程序运行时才动态建立，因为动态建立的化会增加很多代码，因为每张
单即是每个Table的Post前、后事件，插入前、后事件等事件的代码都不同，
而且事件也很多，如果动态建立，岂不是要浪费很多无谓代码去连接事件和
方法（即将事件和方法关联），此外也要很多代码设计Table的不同属性，
这样做我觉得不好，不是各位觉得怎样？也可能我的理解不对，请大家给出
意见，做好是以前做过此类的！
言归正传：
上面举的销售单的两个主从表，其他单据共享这两个表的机会不多，也即是
说其他窗体共享（每个窗体代表一张单据）这2个DataSet（应该是4个）的
机会不多，我是指其他窗体（即其他帐单）！所以我不准备将这此类DataSet
（每张帐单都有4个，至少十几张帐单，共几十个Table或Query和DataSource）
放在DataModule里，因为又没有其他窗体共享这两个表，其他帐单应该没有太
大机会使用到这两个主从表，因为帐单之间好像相对独立（这里面不包括什么
仓库，交易单位信息，人员表等表，这些是相关的，我准备放在DataModule里）？
概括起来就是不共享的表所使用的DataSet要不要放在DataModule里？
因为DataModule在程序运行就建立，而且一建立也就建立了上面放的所有DataSet。
由于在同一时刻我可能只会打开一张帐单，如果我将所有几十个DataSet都放在
DataModule里，岂不是在同一时刻建立了几十个无谓的而且是互不相关DataSet？

我觉得你应该理解一下企业的内部管理机制及财务的相关知识。以我的经验，在企业的资源
流转过程中，可以分为“物资流”和“现金流”两个部分，物资流就是日常所说的库存管理
，对于仓库来说，他们并不在意物资价值的多少，而是物资的数量。而对采购、财务和销售
来讲他们更多的关心“现金”的流动，不很确切的说是“来往账”。
我的系统就按照上面这个规则区别仓库和采购、业务的操作。
对管理系统，无非是从单据或基本信息而来的数据源，以查询或报表为主的数据目标。
因此，对仓库来说，它数据源就分为进、出来个部分的单据。但在现实中因为部分差别及
财务规程，所以细分为进、出仓、调拨（有时还有退货单，为什么呢？这是针对退货比较
频繁，而且对退货也有相关统计的设计，而退货也有进仓退货，也有出仓退货，具体的应用
根据实际的需要。而很多时，以对进出仓开负数单（也叫红单）来处理这些退货，其实调拨
也可以如此分单处理）单。
对采购部门来说，主要是采购单，和采购结款单
对业务部门来说，主要是销售单，和销售回款单
所以，各个单据应该各自建表，尽管不要重复使用，不然单表的数据量会很大，而且做查询
的时候也不容易明晰思路。
至于用TABLE还是QUERY，那要看你比较习惯用哪个，我是用TABLE的。应该是要把这些TABLE
放在DATAMODULE中，但不是一开始就把所有的TABLE的ACTIVE设为TRUE，而是在使用这些表
的窗体或报表打开的时候再打开，这样程序启动的速度会快得N多。
如果你是BDE，那么我建议你好好看看DELPHI自带的例程MASTAPP，主明细表的处理方式，它
做得很不错。
打得好累了，回头再继续[]

关注

首先，谢谢你这么详细的回答，我仔细看了看，觉得很有得益，不过有些还要慢慢体会，
如果按你说的规则和我自己的想法结合，那这个程序可能要40-50个Table，
我想应该不会太多吧？（放心我肯定不会一次性打开这么多表）
另外：我想将每个Table在设计时就添加所有字段（即是在设计时用字段编辑器将
所有的字段添加进去并设置各字段属性，你懂我意思吗？），这样做是否不妥（
结合上面的一次性建立所有DataSet）？

我会好好看看DELPHI自带的例程MASTAPP的！

另，我希望你能有耐心看完我所有问题（包括未提问的），我对你的解答和意见建议
很重视，而且到时候所有问题加起来说不定成了一篇XXXXX，对于其他有兴趣学习
的人来说也有帮助！谢谢！

没问题！
我觉得做这种软件，你应该循序渐进，从自己能理解和能力所及的角度去写。不然，一开始
就很复杂，你会很难有进展的，这样你也会失去信心。所以，你可以先从每个TABLE在设计
时就添加所有字段开始做起，等有必要的时候再做动态添加字段。而且据我的经验，为做
动态添加字段的机会不是很多，只是在TDBGRID中动态显示字段机会多一点而已。
有一本书有讲述MASTAPP这个例子的，是《DELPHI5.0开发实例》，挺早的书了，不知道还
卖。
其实我也希望有人真得能写一个以本地数据库为主的（有主明细表结构）的完整程序实例
的书籍，最好是同时写上BDE和ADO两种不同处理方式的说明。这样对初学者都是很大的帮助
进销存软件的开发之前，建议你先多花点时间，画出业务流程图，画出它们之间的业务关系
图，单据关系图，及查询关系图。这样你的思路会清楚一点儿……[]

关注

listion

谢谢！
关于：
>建议你先多花点时间，画出业务流程图，画出它们之间的业务关系
>图，单据关系图，及查询关系图。这样你的思路会清楚一点儿……
这个有难度，我对这种关系很模糊，画不出来，而且也找不到书或有关资料，
那些会计的书也好像太专业，并不是专门给程序员看的，所以可能要边做边补，
做一步看一步啦！[]

小弟刚才看到一张类似的流程图，产生了一个问题，现将此图贴出。



问题如下：
比如在进货单中，货物进货自然要进仓库，而且进货单里已经包含商品数量，本来
以为进仓这部分肯定要自动生成，不用用户输入，也就是说进货单入帐时，程序会自动
在入货的仓库添加商品数量和相关信息，但看了这张图上面是有采购入库存单也有出入库
单，这好像不是自动生成，可能要人工输入？那么还要不要在填写进货单时自动在库存
表中加上进货商品数量呢？

to ：oceanwave
一个月作了四个进销存，真历害，我作了一个还用了三个月，多向你学习。。。。[]

一、我是不做库存表的，这容易出现错误，因为如果其中一个单据提交出问题，对库存表
的增减的问题，就会影响库存表的正确性，所以我的库存结果是用查询做出的来。还有进
出存的查询、回款的查询。因为我的看法是数据源，也就是单据，是以表的方式来做，但
查询结果应该用QUERY来构造，这样灵活性更大些，相当结果也比较正确。
二、采购入库存单与入库单分开，就象我前面说过的，就是“物资流”和“现金流”明确
分开，但这要向企业实际的需求，也就是越大的企业，职能分工越明确，这两“流”之间
的区分越明显。对于小企业，由于它们本身职能分工不是很明确，如果有些单据输入分得
太细，他们的具体操作人员的工作就会变复杂，不利于软件的易用性。
所以，从面上讲，单据的操作者只操作自己所涉及的职能范围内。从技术细节来讲，表的
建立应该符合关系型数据库的几个范式（有关的知识可以看看数据库或具体SQL SERVER方
面的书籍），尽量减少因为表设计而引起的数据亢余。
另外我把我以前做的流程图其中之一放到我的网站上去，你看看吧
http://www.5432i.com/manageflow.gif