进销存的核心问题之二。 (300分)

  • 主题发起人 主题发起人 程云
  • 开始时间 开始时间
程

程云

Unregistered / Unconfirmed
GUEST, unregistred user!
进销存可以分化为三个并行，但又不完全同步的层面。
这样就可在软件中同时建立三套帐。
虽然我们认定其中的业务层在整个进销存的流层中起到主干作用
(是我这样认为的，这还有等讨论)，
但依然没有抓住问题的中心。
我们如果能从进销存中找到他的核心问题，让它成为软件的内核，
一切工作都是围绕着这个内核来工作的，并且在任何进销存的情况下，
都是不可缺少的。不论进销存的经营模式有什么差异，而这个核心也不会有所改变。
即，就是找到进销存的最基本的东西，不变的哪个核心。当客户要求变动时，
我们的内核不变，只要扩充一些外围的模块就可。
这样不仅方便软件的开发和修改，也有利于软件的稳定性。
这就是我们这次讨论的重点，大伙儿多多帮忙。
 
怎么在非技术问题栏里。
 
怎么说呢，这么就我一直想这么搞过。。实际上也就是三层次体系的一种表现方式
但是结合到企业的具体实际情况而言，抽取共同之处的确是太难了把；现在我也只能
作到很简单的一步也就是抽取操作相似的（单表主从表）我很关心这个问题请大家继续
发表高见
 
这个问题还是先解决的好，不然作起进销存来还真是挺麻繁的。
如真能定出进销存的核心，给于它相应的公共接囗，以后类似的软件可重用它，
哪正是我们的目的。
还望众位多多帮助。
 
对于进销存的一些概念我们已进行了一些初步的讨论，
象进销存的三层面问题，就是在下面的连接中讨论的，
可先去看一下，如接上这个问题。
<a href="DispQ.asp?LID=420150">进销存的定义与进销存的核心问题。</a>
 
进销存从表面意义上讲的就是物流中的进货，销售，库存等物流过程。
但是实际业务中物流不能脱离开款流，票据流而独立存在。如果你仅把物流
看成进销存的，可能会在客户那碰到一鼻子灰的。
我想你可能是想尽快总结出进销存的核心模块，但实际上光有进货，销售，库存
的进销存是绝对没有市场的。在3年前，市场上都是通用进销存，但现在市场上
进销存都是分行业，分规模的，财务商务一体的，并且出现了更多ERP。这说明
中国的企业管理软件已经从简单的进货，销售，库存的记帐模式转化为物流，款流，
票据流的全方位管理上了。
一个好的企业管理软件的核心及其需求一定是经过很多的市场，客户的研究作出的，
只有作出的软件全面适合客户现在及将来的的需求，才是真正的好软件。
别人的单方面意见往往并不能代表真正的市场需求。
 
很难作到核心定义的方式来实现。可行的方式是采用多层结构，重新利用UML建模。
所有业务都对象化。实现数据层和表现层分离。但这种方式用delphi操作起来我还
没看出什么优势来。
有人采用的开关量的方式来达到快速客户定制的目的，但实际操作起来效果
好象也不怎么样。
我个人的看法是，尽可能让客户适应软件，据我的接触，现在大部分企业的管理确实
很有问题，如果照它们的意见设计软件，对企业的管理毫无助益。而一个管理软件开发
的版本到了3.0后，实际上也已经具备这个实力适应各种需要,也已经可以说服客户采用你的模式。
而确实有必要修改的话，我相信只要软件开发规范的话，那么实际上修改起来也是很快的。
现在中国软件开发的最大的问题是不规范。
 
即然它们都叫进销存，总有一个共性的问题，
这个共性就是我们要找的，并封装在一起，
让它得到重用。只要调整一下设置，
它就能处于不同的进销存工作模式中。
这一点要作到，不应太困难吧！
 
想法挺好，学学。
 
不懂，没作过
 
你可以看看这个网站，他们在开发一个通用的平台。
www.justep.com
 
我正在做一个电脑销售公司的进销存软件，用的SQL Server7.0
我的感觉是，用户的需求是千变万化的，与其在考虑使用一个固定不变的内核，
还不如考虑在程序开发时，多考虑各种变化，增加库结构和程序模块的灵活性
和适应性。
我的建议是：
1）尽可能多用基础编码库，将用户想要表达的信息尽可能想到，并考虑到
用户需要可能的变化；
2）将查询和生成报表模块做成通用的，以便于修改和维护；
3）多使用Object Pascal的面向对象功能，同类窗体尽量用继承。
另外，按你的意思，我想你可以考虑用动态生成的库结构的方法来实现，
以前，我做过一个类似人口普查的通用扫描仪识别程序，就是根据库结构定义表
来动态定义库结构。

我的话完了，哈哈！
 
htw看来也是苦命人.
 
我对这个的问题也有了一点愚见，
希望大家能多多指点一下。
******************************************************************************
进销存可以分化为三个并行，但又不完全同步的层面。这样就可在软件中同时建立三套帐。
虽然我们认定其中的业务层在整个进销存的流层中起到主干作用，
但依然没有抓住问题的中心。
我们如果能从进销存中找到他的核心问题，让它成为软件的内核，
一切工作都是围绕着这个内核来工作的，并且在任何进销存的情况下，
都是不可缺少的。不论进销存的经营模式有什么差异，而这个核心也不会有所改变。
即，就是找到进销存的最基本的东西，不变的哪个核心。当客户要求变动时，
我们的内核不变，只要扩充一些外围的模块就可。这样不仅方便软件的开发和修改，
也有利于软件的稳定性。
其中进销存中进货、销售和库存是它的三大基本要素，
它的核心自然也就是这三者的其中之一。
其中进货，可以分为多种，如正常的进货，
客户退回也是一种进货，调入、借入、盘盈这些也算是一种进货，
而且也有不存在进货的情况。进货的不确定因素太多了，不具备核心的必要条件。
再就是销售的问题了。销售起马也可分为批发和零售两种，如象进货一样分，
哪进货退货和调出、借出、盘亏也都可算销售的一种形式，
这样销售的表现形式比进货还要多，自也不能作为进销存的内核。
这样就只剩下存的问题了。其实对于存来说，就是出入库的问题，
没有其它更多的东西。对于三个层面来说，每个层面都有自己的存，
象业务中的票据流的流入流出，库房层的物品流的流入流出，
面财务的就是金额流的流入流出。如个层面都会涉及到自己的进销存，
去维护这个自己的“库存”。
从这可以看出每个层面对自己的 “库存”的维护就是进销存的核心。
而软件的核心部分就是库房维护系统，即出入库的管理。在这部分如果作好了，
在任何一个进销存中都可以很好的发挥作用，而后期的工作，
就是根据客户的需要定制外围的模块。如设置不同的进货和销售模块，
或是各种报表查询。
******************************************************************************
 
to htw:
你能不能详细点说一下"动态生成的库结构的方法"？
这样又是如何去管理这些动态库结构的呢？
 
我不懂數據庫,但我認為你們應該抓住下列一點:
進銷存,顧名思義,購進-庫存-銷售 三環節
這三環節不變的是流程,
變化的只是購進的東西不同,數量不同,價格不同,供應商不同,時間不同
庫存也只是倉庫多少,規格不同,庫存物品隨購進與銷售影響,計價方法不同
銷售的東西永遠是庫存中的東西,價格有利潤率左右
 
后排听课
 
轩辕散光、wangjerry、liqunxin、htw、vinca378五人，每人40分，
还有100分，我就随意分了呀！
老朋友就少分他点。
 
多人接受答案了。
 
您必须登录或注册才可回复。

Similar threads

S
[教程] ZValueWatch 教程之二：在线程中处理图片
回复
0
查看
429
swish
S
S
[教程]使用 ZValueWatch 在主线程中监测值变化
回复
0
查看
488
swish
S
S
[教程]使用 ZAsyncInvoker 进行异步编程教程之二：ZAsyncInvoker 解决了什么问题
回复
0
查看
698
swish
S
S
[教程]ZAsync 异步编程之四：请记住匿名函数是一个接口
回复
0
查看
709
swish
S
S
[教程]ZAsync 异步编程教程之七：在后台线程中 async/await
回复
0
查看
747
swish
S
后退
顶部