Hi Robert,
Answers below:
On 10-Feb-2012, at 1:24 PM, Robert Becht wrote:
Hi ,
Thanks for yr suggestions on stock updating earlier this morning.
Indeed the idea to start with a “dummy” on 1.1.12 is a good one.What about this to allow a certain degree of negative stock. Just yr opinion, for discussion.
I see yr point of garbage in garbage out, but I will also know the frustration of the end user who want to sell an item and first has to update quickly inventory levels in order to do so. This will also create garbage, because the sales person (me, my wife, our business friend) will not go to the paper invoice files, look for the the last suppliers invoice, enter the data, while the client is waiting. What will happen in practice is that a) the item is not entered at check out (most likely) or b) quickly the item will be “created” by a stock reconsilliation with most likely a random number to the discretion of the user. Please consider that a client is waiting, and is not interested in the fact that ERPNEXT is not allowing negative stocks. So thew quick fixes are also introducing garbage, where with negative stock you can properly do the correct accounting later on.
I have seen a few implementations and what I have realized is good inventory control is also about good practices. In the ideal case, the system inventory should closely reflect the real inventory only then will you learn to rely on the system and hence benefit from it.
Once you are confident that the system has accurate stock, then it will make life much easier later on. Like you can just check the system if you have a particular item in stock or no instead of hunting around. I would recommend that you make a system entry as soon as you receive material and keep the stock as accurate as possible.
It is also about fixing responsibility and accountability - I know that can be tricky with your wife
What I could consider as an alternative is that I enter say 10 units as default on opening. (or at an other moment). So I artificial raise every item count by 10.
In all further processing, I should considwer this (with definitely some disadvantage, eg that the stock value is not represented correctly.Not sure whether, with a file upload I can “reconcile” the opposite way at a certain moment, namely to subtract 10 UoM of all items in the inventory.
Stock can be reconciled both ways (If I am correct, even if you make entries before that date, entries after the reconciled date will not be changed)
Please share yr view.
Nice that u wrote on codification.
I fully agree on the need of codification but there are some other considerations as well.What you subscribe is an internal consistent way of coding, where the code itself contains info on the item.
What I have done so far (the last 2 yrs running Dogs Love IT) is to observe the “supplier code” (if available) and for repacked item use a post-fix.
Using supplier code has the advantage that there is absolute no confusion about the article, especially useful if you sell the(almost) the same article from different suppliers.
Example. We sell dried fish prepacked and bulk and than repacked.
AAA dried fish 100g
BBB dried fish 100g
CCC dried fish 5 kg
CCC_250g dried fish 250gSo I maintain the suppliers code (AAA,BBB and CCC) so that I know which dried fish I 'm talking about, and secondly if I repack I derive the code from the suppliers code, by adding the weight info at the end, so also for repacked stuff I know the origin/supplier.
This is a good idea, my suggestion for your example would be,
DF-250-AAA
DF-250-BBB
DF-5000-CCC
DF-250-CCC
(this way when you type DF- you will know what options you already have)
We can argue about the pros/and cons of different systems, but I feel that the search should be as fast and generic as possible.
I don’t know whether it would be very difficult to implement a Property Setting of the select box where the end use can define the search properties/preferences.
If that were possible my search setting would be to search default in name/or decription , now it is ID. Secondly I would alternate the % and “no prefix”, meaning that by default I would search “string inside a string” (that is now indicated by %) and use say the % if I would constrain it to “match the beginning of two strings”, now the default setting.
I could do that, but just worried about the extra search effort the system might have to make and its effect on speed… Let me give this a thought, this may be possible.
An additional advantage of maintain suppliers code is when entering the purchase invoice, one just have to type in the item codes on the paper supplier invoice and add quantity. No search necessary. If the item does not “pop up” when entering the code it means that I have never bought before, and I can than “create” that item from the invoice.
Well, during this discussions “my system” is emerging; I think I will set up a coding system along your guidelines in item_ID, maintain the supplier code in Name, and have the description in description. That seems to be the best of both worlds
May be we should copy this discussions to the forum to have interaction with other users of erpnext
Sure I will copy it to the forum!
Rgds robert
-----Original Message-----
From: Rushabh Mehta [mailto:rm...@gmail.com]
Sent: Friday, February 10, 2012 7:20 AM
To: Robert Becht
Subject: item codificationwrote an article on it:
ERPNext - World’s most affordable ERP.
W: https://erpnext.com
T: @rushabh_mehtaFaculty of Geo-Information Science and Earth Observation (ITC)
University of Twente
Chamber of Commerce: 501305360000E-mail disclaimer
The information in this e-mail, including any attachments, is intended for the addressee only. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or action in relation to the content of this information is strictly prohibited. If you have received this e-mail by mistake, please delete the message and any attachment and inform the sender by return e-mail. ITC accepts no liability for any error or omission in the message content or for damage of any kind that may arise as a result of e-mail transmission.