|
|
 |
 |
 |
 |
Enterprise Resource Planning systems
|
 |
 |
 |
 |
|
|
|
|
New ck-mrp modules
Hi, folks, I have completed a preliminary version of a new ck-mrp module and
uploaded it to, http://ck-erp.net/xoops/html/index.php
New features include,
Bill of Materials
Material Requisition
I have also added a new header menu item of [Open New Window]. This
allows a user (if desired) to open up a new window to review or update
some related master record before reverting back to the original window,
the main benefit being the user does not need to log into a separate
session. If feedback is positive, I'll add this feature back to all
previous modules.
Please note that the module is totally experimental at the moment and I
am sure substantial changes will be made before it is incorporated into
the next formal release. At the same time, because data structural
changes are planned for the coming release, I hope to iron out all major
issues before formal release, to allow (data) structural stability at
least for the coming year.
Your comments, feedbacks, ..... etc, etc, etc,................ are most
welcome.
Cheers,
CK
The whirl wind of CK continues... :=) My only concern after a quick look at ck-mrp and a review of ck-inv, is
that you're basing new development on the ck-inv module which has a
weak concept of quantity. The crux of the problem is that UOM must be
presented EVERYWHERE quantity is presented and UOM must be convertible
from one UOM to another.
Every new Inventory manager thinks he's going to simplify inventory and
just deal with UOM of EACH. The problem is, in his mind's eye, he's
bought each from his supplier and he's sold each to his consumer. In
real life, He's received a BOX of 24 from his supplier and he's sold 1
out of the box. He probably won't realize his mistake until the
physical count at which point he'll blame the computer for the wrong
count.
My point is that the above scenario is the general case, and that the
case where every quantity is essentially EACH (however you name UOM in
ck-inv) is really the special case.
Not to complain one little bit. But I think you might be digging a
hole.
-----------------------------------------------Reply-----------------------------------------------
Hi, Jerre, Thank you for the valuable feedback.
Your observation is certainly a valid one. Indeed, the current
structural setup of ck-inv requires a lot of improvement. Translation
of (purchases) unit-of-material to (sales) unit-of-material or any other
intermediary unit-of-material will be put on the enhancement agenda for
the next release.
Cheers,
CK
jerre.h @gmail.com wrote: > The whirl wind of CK continues... :=) > My only concern after a quick look at ck-mrp and a review of ck-inv, is
> that you're basing new development on the ck-inv module which has a
> weak concept of quantity. The crux of the problem is that UOM must be
> presented EVERYWHERE quantity is presented and UOM must be convertible
> from one UOM to another.
> Every new Inventory manager thinks he's going to simplify inventory and
> just deal with UOM of EACH. The problem is, in his mind's eye, he's
> bought each from his supplier and he's sold each to his consumer. In
> real life, He's received a BOX of 24 from his supplier and he's sold 1
> out of the box. He probably won't realize his mistake until the
> physical count at which point he'll blame the computer for the wrong
> count.
> My point is that the above scenario is the general case, and that the
> case where every quantity is essentially EACH (however you name UOM in
> ck-inv) is really the special case.
> Not to complain one little bit. But I think you might be digging a
> hole.
Hi, Jerre, After a bit of deliberation and searching on how other ERP system works,
I think the general way to handle unit-of-measure (UOM) translation is
to allow the definition of standard UOMs with multipliers and let users
pick the appropriate UOM at ordering, invoicing, stock issue time, etc.
For example,
UOM multiplier
box (24 bottles) [base UOM] 1
bottle 0.04
(round to two decimal places) = 1 / 24
However, this could easily create stock discrepancy based on decimal
stock. For example,
Stock
Level (base UOM = box)
Purchase (1 box) 1 box
Sales (1 bottle) x 24 times 0.96 = (1
bottle x 0.04) x 24
Residual 0.04
box (= 1 bottle) [stock level should have been zero]
Admittedly, this is caused by the multiplier rounding to only two
decimal places. A more precise multiplier (more decimal places) would
ease the problem. However, it is difficult to determine how precise a
multiplier should be, especially when some items could be purchased in
tons and be sold in pounds. Some users could in fact enter a multiplier
of 0.041700000, thinking that it is stupid to enter any number with
(say) nine decimal places. One way of getting round this problem is to
set the base UOM to bottle, ie requiring multiplier >= 1.
UOM multiplier
bottle [base UOM] 1
box 24
However, with this, there is the further problem of non-definite base
UOM. For example, for cables, they could be purchased in reels of 100
meters, but be sold in meters or feet. Cumulative sales of x meters and
y feet would again create decimal stock.
Are there ways to get round these or perhaps better design to handle the
varying UOM problem ?
Cheers,
CK
C K Wu wrote: > Hi, Jerre, > Thank you for the valuable feedback.
> Your observation is certainly a valid one. Indeed, the current
> structural setup of ck-inv requires a lot of improvement. Translation
> of (purchases) unit-of-material to (sales) unit-of-material or any
> other intermediary unit-of-material will be put on the enhancement
> agenda for the next release.
> Cheers,
> CK
> jerre.h@gmail.com wrote:
>> The whirl wind of CK continues... :=)
>> My only concern after a quick look at ck-mrp and a review of ck-inv, is
>> that you're basing new development on the ck-inv module which has a
>> weak concept of quantity. The crux of the problem is that UOM must be
>> presented EVERYWHERE quantity is presented and UOM must be convertible
>> from one UOM to another.
>> Every new Inventory manager thinks he's going to simplify inventory and
>> just deal with UOM of EACH. The problem is, in his mind's eye, he's
>> bought each from his supplier and he's sold each to his consumer. In
>> real life, He's received a BOX of 24 from his supplier and he's sold 1
>> out of the box. He probably won't realize his mistake until the
>> physical count at which point he'll blame the computer for the wrong
>> count.
>> My point is that the above scenario is the general case, and that the
>> case where every quantity is essentially EACH (however you name UOM in
>> ck-inv) is really the special case.
>> Not to complain one little bit. But I think you might be digging a
>> hole.
The table of UOM's is what I've seen work along with a table to show the ratio of one UOM to another. The table may deal with multiple UOM relationships: Gallons to quarts to pints to ounces. Not all UOM's have a relationship. I didn't mention this earlier so I wouldn't flavor your thinking with what I'd seen commercially. The commercial system I use with some variety of items ( rolls of wire,
bags of wire nuts, pounds of refrigerent ( in various sized drums)),
has 4 decimal place quantities which seem to take care of most of the
slack. Ultimately, physical count procedures are used to deal with
rounding issues. For this reason, it is good to use a physical count
unit of measure that is likely to be integer.
Mechanisms and somewhatOriginal thoughts :
For the drums, I have to document for Environmental reasons where
exactly all the refrigerant has gone, so I have some turn-in mechanisms
that flush the drum to zero. I've written a P.O. system that works as
P.O., Inventory Transfer, Inventory Receive & in the case for
refrigerent drums (turn-in). I force each drum to zero because it is,
although its quantity on hand may be more or less than zero, depending
on whether the drum was oversold or undersold. It's the manager's job
to watch for abuse. The difference should even out to close to zero.
This is actually a special-case of a physical count because I happen
to know what the quantity should be at a given point.
There are other items that just run wild until the physical count, such
as consignment and what I call consumables ( items that you can't bill
for really, but you still need to know how much you used ).
Hope this helps. I think you're on the right track. I think the
hardest part about inventory is procedure. Human procedure error is
going to cause far more error than decimal rounding.
-----------------------------------------------Reply-----------------------------------------------
I think I can make the decimal/procedure question clearer: 1) You receive 2 boxes of 24 jars (CASE)
2) You sell 3 JARS
You don't sell 3/24 CASES, you sell 3 JARS.
The question is then, how do you count? Are you going to count jars or
boxes in your store. I would tend to count jars to avoid rounding.
That way, your quantity on hand increases by 24 (integer) at a time and
sales don't cause a fraction.
Also, you're not hindered from selling by the case, since that won't
cause a fraction either.
--
What about wire nuts?
They come in bags of 100. No, I'm not going to count the stinkin wire
nuts, they don't cost enough, so I will sell 3 nuts and effectively
diminish stock by 3 / 100. At the end of the day, I'll count bags.
Even mostly full bags.
Cheers...
-----------------------------------------------Reply-----------------------------------------------
Hi, Jerre, Thank you for the valuable information and discussion over the UOM
question. I think I have a much clearer picture of what the final
design will look like. Hopefully, with ck-mrp, ck-production and a
re-structured ck-inv, CK-ERP will be a more competitive OSS offering.
Cheers,
CK
jerre.h @gmail.com wrote: > I think I can make the decimal/procedure question clearer: > 1) You receive 2 boxes of 24 jars (CASE)
> 2) You sell 3 JARS
> You don't sell 3/24 CASES, you sell 3 JARS.
> The question is then, how do you count? Are you going to count jars or
> boxes in your store. I would tend to count jars to avoid rounding.
> That way, your quantity on hand increases by 24 (integer) at a time and
> sales don't cause a fraction.
> Also, you're not hindered from selling by the case, since that won't
> cause a fraction either.
> --
> What about wire nuts?
> They come in bags of 100. No, I'm not going to count the stinkin wire
> nuts, they don't cost enough, so I will sell 3 nuts and effectively
> diminish stock by 3 / 100. At the end of the day, I'll count bags.
> Even mostly full bags.
> Cheers...
|
|
|
|
|
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc