进销存中的移库问题，你们解决了吗？(300分)

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

程云

Unregistered / Unconfirmed
GUEST, unregistred user!
在一个进销存系统中，如果有多个库房，它们之间一定不可必免有移库问题，
1、当然在如能从逻辑上把他们当成一个库房哪自然好了，
可人家有库房责任的问题，不能合为一个处理。
2、要记录移库过程，这好说记下就是。
3、一物品从A库房移到B库房，如B库房认为这个物品要退回厂家，不是他们进的货，
自然要退给A库房去退货了。然后又从B库房移到A库房，但这时A库房又怎能知道
这个物品是从哪进的呢？又怎作这退货的工作呢？
4、在一个系统中的若干子公司间的调货（习惯称为系内调拨），也同样存在这样的问题。
大伙儿，多帮忙想想，这是必须要解决的问题。
我也为他想了一年了，都没有找到一个比较好地解快这个问题的方法。
到时多分分。
 
要解决什么问题?
 
进销存系统中必须记录商品的许多附加信息，比一般的信息管理系统要严格，因为涉及商业
成本核算。
换言之，商品的每一业务流，都必须打上该商品的业务 ID ，而不只是商品本身的 ID 比如
商品编码。比如卖出一件商品，必须记录下，该商品是哪一批次、哪一厂商、当时采购成本等
许多信息，当然这些附加信息可以用一个专门的表来组织，用一个业务 ID 来表示。
调拨是同样的道理，执行一次调拨单，如果打上商品的业务 ID ，那么不论如何变动，总可
以根据这个业务 ID 来找到它的原始发生情况。
如果你了解商业成本核算的“先进先出”、“后进先出”、“全月平均”、“加权平均”、
“个别计价”等核算流程的话，这样的解决方案应该是很自然的。
 
to BaKuBaKu:
你说的这些我们也有，
我们的业务明细表(t_salelist)中记录这些业务单据。
单据编号，单据序号，库房编号，操作方式，商品编码，商品名称，……，供应商编号，供应商名称，源单据编号，源单据序号
R00001, 0001, 0001, 购入， 100001, 六味地黄丸, G0001 第一制药厂,
(从0001库房移到0002库房，的记录过程)
YC0001, 0001, 0001, 移出, 100001, 六味地黄丸, 0001 第一库房, R00001, 0001
YR0001, 0001, 0002, 移入, 100001, 六味地黄丸, 0001 第一库房, YC0001, 0001
(再从0002库房移回0001库房，的记录过程)
YC0002, 0001, 0002, 移出, 100001, 六味地黄丸, 0002 第二库房, YR0001, 0001
YR0002, 0001, 0003, 移入, 100001, 六味地黄丸, 0002 第二库房, YC0002, 0001
这样，这最后一条就成了0001库房的入库，要对它退货，我要如何去退呢？
本来退货是在供应商中记录进货的供应商，要退出它的，可这会，哪里记录的是第二库房，
但如果不这样记录，哪就不知这个是从哪移过来的了。
不知大伙能明白这个问题出在哪儿吗？
 
：BaKuBaKu 说得对
增加批次号，这样无论怎么搬到、移库都可以了
批次号；约定了一批货物的唯一的标示~


 
批次号，不行的，
因为它作不了唯一的，
有的多次进的，可能是同一批次的，
或多不同的供应商进的为同一批次，这我们也见过。
还有，就是有的物品没有批次的，哪要如何去作呢?
现在我们的软件是在管理这个批次，每一次进货，第一笔单据都有批次，
可这不能这样用的。
还得再想办法。
 
批次号就是唯一表示货物属性的，多次进的就应该是多个批次
对于没有批次号的，也是允许的
主要在于是否进行批次跟踪，如果需要则批次号必须存在；否则没有必要
 
to 轩辕散光:
不知我们说的批次同你说的批次是不是一会事儿？
我们用的批次是物品出厂时自带的，是指某一批的产品，只会有一个，
这样很可能到了商家手里，就是重复的，这怎能用作唯一码呢？
在我们的客户中，还没发现哪个有批次绝不出现重复的客户呢。
而且如没有批号，哪又如何唯一的确定哪次进货呢？
还个方法根本行不通。
 
哦看法不同
我的批次是指入库时的唯一标示，这样如何？？
 
你的业务明细表是否还缺少一点东西呢？
每一笔商品采购入库，一定要为它指派一个“终身”ID ，就像人出生后给他一个身份证号码，
如果有这个标识，那么无论在那个环节发生诸如“退货”等的业务，都能够立即定位到该商品
的<font color = #ff0000></strong>原始</font></strong>信息！！
在你现有的数据结构中，即使仓库 2 不把商品调回仓库 1 ，仓库 2 也没办法退货的。
单据一定要保证它的原始性，一旦单据发生，就绝对不允许修改，否则电子数据的擦除是没有
任何痕迹的，我们做商务系统，就要在系统逻辑上防止这种行为。
一般的做法是，建立一个普通业务记录表，即把单据流中发生的所有行为的共性抽象出来，组
织到一起，当然其中就包括我所说的所谓“终身”ID。
这样做的好处在于：首先，不必把所有类型的单据放到一起，还要为兼容各种单据各自的特性
操心如何设计单据总表的数据结构；其次，单据一旦发生（审核），就不需要再对单据表进行操
作，此时的单据表就相当于一个备查的原始档案，符合实际的行为特点；方便各种查询统计，比
如成本核算的算法在这个数据结构下就显得非常简单，并且如果拥有“终身”ID，你原来的问题
都将不成其为问题了。
在业务发生的即刻并不需要马上更新这个“普通业务表”，因为涉及的操作比较复杂，如果应
用于大型超市、购物中心，由于并发度很高，这样的任务和网络流量也是系统所不能承受的，而
且容易出现并发控制问题。所以，在业务发生的即刻，我们只需要记录下业务本身的情况就可以
了，具体说，就只需要负责把录入的数据保存到你的原始单据表中，每一天的某个时候，或者每
个星期的某个时候（如果要求不高的话），执行一次结转操作，把所有的业务的共性提取到这个
“普通业务表”中来就可以了，实际上大部分商场、大型超市都是这样做的。诸如调价等操作也
都可以放在这一环节执行，因为绝大部分都是先一天调价，隔日生效。

一家之言，不知意下如何。
 
to BaKuBaKu:
你的"终身"ID的方法很好，这种没有唯一性，而设的唯一值的方法，
起马在理论上我看是可行的。但还要在实践中多试，说不定还有更难办的问题发生。
你之后提到的问题我们是在前台专有POS程序，它在工作时是与后台断开的，
只用来记录大量的零售数据，然后在不忙时，或他们认为合适的时候，如交结班时，
再传回后台，而后台是在这些零售的明细数据的基础上，汇总之后并按照
如"先进先出"的这种设定好的出库原则出库。
这种方法只用作在长期的大量数据的输入操作中。
这个问题就先到这儿，过两天我就接束它。
我还的哪个问题你也多多帮忙。
<a href="DispQ.asp?LID=420150">进销存的定义与进销存的核心问题。</a>
 
to 轩辕散光:
你给出的答案也是正确的，
你这位高手，可也不要忘了帮帮我的另一个问题。
 
这个问题是不是太大了一点，不过我现在所作的大概就是这个
从mrpII提升到erp，不过进销存依然是重点
实际上顺序应该为销-进-存-销
以订单为根本从而达到三流统一的境界，同时联系到财务的成本核算，库存则是重中之中
我们可以更加详细的讨论这个问题。。。
mymailwh@263.net
oicq :3877369
 
其实是一个意思。:-)
 
to 轩辕散光:
你所说的顺序"销-进-存-销"为何销在前面？
>>以订单为根本从而达到三流统一的境界
为何以订单为根本呢？
我们的客户中使用进货计划的没几家，
而用销售订单模块的一个也没有，
可见这部分在软件设计中可以考虑，
但实际用处显然不大。
这三流统一的境界还真难达到。
 
程云：我所说得以销售为龙头主要针对mrp类型，结合生产管理而言的，不知我说的是否明确？？
 
to 轩辕散光:
咱们私下聊，我先分分。

BaKuBaKu : 的答案正合题意， 150分
轩辕散光 : 的答案也同样正确， 140分
jqw : 这位连EMail回复的 10分
大侠灌水有分，
所以我以后的问题
可得多灌水了

没竟见吧！哪我分了。
 
多人接受答案了。
 
to jqw:
你也太不够意思了，
打个问号就再见不到人了。
 
您必须登录或注册才可回复。

Similar threads

S
[教程]Delphi 函数的内部函数在匿名回调函数中无法使用的一种解决办法
回复
0
查看
553
swish
S
S
[教程]使用 ZAsyncInvoker 进行异步编程教程之二：ZAsyncInvoker 解决了什么问题
回复
0
查看
698
swish
S
S
[教程]Lazarus 在 Linux 下中文输入法问题的临时解决办法
回复
0
查看
864
swish
S
不
Python从内存中使用编译后的模块 - 不得闲
回复
0
查看
721
不得闲
不
不
Delphi中设置条件断点 - 不得闲
回复
0
查看
815
不得闲
不
后退
顶部