在进销存不支持负库存影响大吗？
我在开发一个进销存系统，我不打算支持负库存，这样做会减低竞争力吗，系统支持负重要吗？
[最优解释]
负库存不影响什么．也基本没什么用．这是过去管理意识不强，流程不完善时，总用负库存．
实际使用负库存，如果用加权平均法的话，还会造成成本变化．得不偿失．
而先进先出等，根本不可能用负库存的．
[其他解释]
像这样说我的系统就不考虑支持负库存了，持负库存还要过多的考虑成本价，实现更复杂些！
[其他解释]
是啊，我个人这样认为。实际中负库存的情况让用户变通处理下更合适。否则引起的成本单价变高，你还得解释
[其他解释]
基于ｄｅｌｐｈｉ的快速“业务构件”开发平台（半开源）,
delhi生手可以快速进行实战开发，
为你节省开发成本，让你为客户定制开发事半功倍。
其功能及理念如下：
1。类似Eclipse微内核＋插件的体系结构，方便升级扩充
EIS支持Delphi脚本，扩展ＤＬＬ，独立可执行程序（*.exe）三种插件。代理商甚至是最终用户可以开发
插件任意裁减定制、改进扩展系统既有功能。
2．源代码级任意修改，即时生效，真正意义上的随需应变
EIS 内置了类似Delphi的IDE环境，熟悉Delphi的开发人员可以在客户端没有安装Delphi的情况下获得和
Delphi类似的开发能力(我们叫三次业务微调，二次开发是指插件开发)，从代码级实现真正意义上的随需
应变。由于利用了动态语言的优势，改动无须编译，保存后即时生效。（下一版本将支持.NET平台下的任
何语言，如C#,VB等等）
３．C/S的强大功能，B/S一样方便维护
几乎所有的功能模块都是以Delphi脚本形式存放在后台数据库中的，就像所有的网站元素（如*.ａｓ
ｐ、*.htm、图片等）存放在ｗｅｂ服务器上一样，客户端用相同的浏览器连接不同的网址便可得到完全
不同的Web内容。ＥＩＳ客户端就扮演的是Web浏览器的角色，但它打开的不是网页，而是存储在数据库中
的“业务构件”（以Form形式封装的业务模块：如销售订单、凭证录入等等），所以我们称之为“业务浏
览器”。像网页浏览器一样，“业务浏览器”连接不同的ＳＱＬ数据库将打开不同的业务应用，客户端只
是充当一个解释浏览外壳而已，升级更换数据库便几乎彻底改变业务应用。由此既可以获得类似Ｂ／Ｓ应
用的维护优势，又可以获得Ｃ／Ｓ应用的强大功能。
４．面向构件，基于构件，用构件来组装业务。
为了尽可能的降低模块之间的耦合度，模块开发人员可以各自独立开发业务模块，开发完成后再注入数据
库即可被平台自动整合。（自动共享数据库连接；权限控制可以进入控件事件级别；注入后修改控件Hint
内容提供动态帮助等）。例如：插件开发人员在单独开发构件模块时完全不用考虑权限控制等复杂的业务
逻辑问题，模块注入数据库后，用户使用前进入“代码控件级别”进行业务权限调整即可。如此，开发复
杂度被尽可能地控制在单个功能模块（构件）范围内，在“粗粒度”下基于构件开发大型系统就非常接近
积木游戏了。
５．适合敏捷过程，团队松散型协作开发。
由于利用EIS开发上层应用可以降低模块之间的耦合度，方便开发人员在源代码级进行多次迭代，同时，
EIS使利用既有构件作为模板重用更加方便。因此，EIS最适合敏捷过程，支持团队之间的松散型协作开发。
有意请联系:13551638864
qq: 561704155
[其他解释]
sign
