Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Adding some dates
06-10-2012, 01:23 PM (This post was last modified: 06-10-2012 01:24 PM by PakRicard.)
Post: #11
RE: Adding some dates
(06-10-2012 12:34 AM)tim_schofield Wrote:  Stock records don't get changed that often, so personally I would rather see us create a new record each time a change happens, and the old record be marked as closed. This way a history of the stockmaster table always exists.

Tim

That would be even better than my approach Smile We will have full audit functions and full data details.

Regards,
Pak Ricard
Find all posts by this user
Quote this message in a reply
06-10-2012, 01:31 PM
Post: #12
RE: Adding some dates
I am not sure that the stock category field is the right flag to use for the purpose you propose - the implications of changing the stock category are quite profound as all the GL posting changes.
Flagging items as good sellers A, B, C etc maybe done with category item properties - a user defined field. We would need new functionality as you describe but using a new field without so much other implications.

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
Quote this message in a reply
06-10-2012, 02:22 PM
Post: #13
RE: Adding some dates
(06-10-2012 01:31 PM)phil Wrote:  I am not sure that the stock category field is the right flag to use for the purpose you propose - the implications of changing the stock category are quite profound as all the GL posting changes.
Flagging items as good sellers A, B, C etc maybe done with category item properties - a user defined field. We would need new functionality as you describe but using a new field without so much other implications.

Hi Phil:

So your vote (if I understood correctly) is to use a new field (let's call it lifecycle) with some values (like test, active, etc). But the date of activation of the flag is a must.

Both should go on stockmaster right?

Or it should be a different table so we could record all lifecycle with starting dates?
stocklifecycle: stockid, cyclecode, date
with a cycles table: cyclecode, cyclename

BTW: One of the nice things of using stockcategory as proposed is that webERP will take care of all GL postings as needed. On B/S we have stock account(which is meant to be quite liquid) and a bad stock account (which is almost non-liquid, as you can not think on it being converted into sales easily). Using stockcategory allows to do the postings automatically, just when you change the stockcategory

Using the cycle flag as you proposed will mean to double the work, as later on some human user will need to change the stockcategory.

I have been thinking abbout this life cycle control for many months and this is the best way I found to control it on webERP.

As usual, I'm open to change my mind, but should be a better proposal. SO far, the audit one seems not practical, more difficult to code and more difficult to extract data from it.

Adding one field to stockmaster allows the development of a full module .

Also, if the philosophy of webERP is the non addition of fields where the information already exists in the application elsewhere, why do we have the table chartdetails? It's just a compilation of gltrans data. Why don't we go to audit (or directly to gltrans) to grab the data? Sometimes it gets corrupted (chartdetails), so we need at least 2 Z_ scripts to return it to life.

Well, just trying to be consistent. I do really think my approach is much better for the reasons explained in previous posts than the audit one.

Hope you change your mind or we can find a workable approach to solve this business need in a general way. Also, more comments for different developers could help both of us to see light, one way or another.

Regards,
Pak Ricard
Find all posts by this user
Quote this message in a reply
06-10-2012, 08:42 PM
Post: #14
RE: Adding some dates
Dear all:

It's a very constructive discussion.

I agree that it's not suitable to retrieve data from audit trail since it only keep limit time. And some users even don't keep the audit record.

It's better to add a dateadded field for the stockmaster, since it'll provide more useful function for business to evaluate product performance. If other changes are minors, I cannot find the benefit to keep the update history.

Moreover, it's maybe a opportunity to review the fields needed for stockmaster. I noticed that in 3.11 version, there are records for pdf file, it's a very useful function for users to keep related documents, but it disappeared in version 4.07. I suggest to get the function to get the function back.

Just my2cents.

Best regards!

Exson
Find all posts by this user
Quote this message in a reply
06-11-2012, 07:35 AM (This post was last modified: 06-11-2012 07:44 AM by phil.)
Post: #15
RE: Adding some dates
The other way to do this ito log all changes to stock category (if deemed really necessary) is to have a new table stockcategorychanges:

stockid,
oldcategoryid,
newcategoryid,
datechanged

this way we record all changes made not just the last one - as we would not wish to have multiple additional fields in the stock master for the change before last and the change before the change before last etc. This is what we should have done/do with the cost update too.

The append pdf file to invoice was nice functionality. It was lost before 4.07 though because it was written using the FPDFI (I think it was called) class which was specific to FPDF. We had to make a call between utf-8 which required TCPDF and appending pdfs using the extension to the FPDF class which didn't work with TCPDF. It needed someone who needed this functionality to step up to figure out a way we could continue with it - but no one did. I did raise the issue and appeal at the time I think. Probably time to lose this field in the stock master now - unless anyone is prepared to dig in on this one?

In relation to Tim's suggestion, I see what you are getting at but this seems like massive overkill to me! Imagine the changes required to every script in the code base to link on stockmaster.stockid which is no longer unique and adding another criteria to all those queries that link to "the" record on the stockmaster to get the current live stockmaster record - a performance penalty on every query involving stockmaster. Also, it is just not simple and adds complexity throughout. IMHO we must strive to retain the simplicity of the system and adding complexity like this for such little gain - well it's a terrible idea.

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
Quote this message in a reply
06-11-2012, 11:41 AM
Post: #16
RE: Adding some dates
Hi all:

it's becoming a constructive brain storming ;-)

1) Tim's proposal I think is the most flexible but also I think it means a very large revision of all the scripts. It could be done just with a flag "active record" and then add a AND stockmaster.activerecord = 1 to all queries, but even so it's a major work. BUT on the long run would be the best one.

2) Following Phil's last post idea we could have a table stockmasterchanges with:
stockid,
fieldname,
oldvalue,
newvalue,
date
That will allow to add more fields (not only the stockcategory).

3) Exson's idea to add the creation date of a stockmaster record is also wise. For how long did we had this item? is a useful question. Now we could reply by indirect means (first PO, first WO, first reception, etc) but not a direct one.

4) I'm still wondering if the performance penalty for adding just one (or a few) field to stockmaster is so large that makes sense to add a new JOIN on some queries. What is faster, retrieving an slightly larger record or producing a JOIN?

For the sake of simplicity of code I prefer number 4) but trying to get a good compromise that works Ok for everyone I think we could go for option 2) and 3).

Regards,
Pak Ricard
Find all posts by this user
Quote this message in a reply
06-12-2012, 08:46 AM (This post was last modified: 06-12-2012 08:48 AM by phil.)
Post: #17
RE: Adding some dates
I like the idea of building some business logic around product life cycle. However, I am a bit unsure about the logic you are proposing nor how it should be done.

I guess we would want to know when and item became TEST - so the stockitemcreateddate is necessary. Then how long was it in TEST (perhaps a new field for categorychangedtoactivedate - if it is in BAD - how can we now tell as the last category change was from ACTIVE to BAD. How does the period it was in ACTIVE give you any indication of when to change it to BAD? I guess the table I proposed for changes in the productlifecycle flag would give you the dates logged (if necessary - read on). I would have thought that the sales performance of the product in relation to the stock holding and the existence and capability/pricing of competing products would be more of an indicator of when to change it in the life cycle flag - it is not really about the passage of time at all... is it? (Interested in your comments here Ricard - why is time important in determining where a product sits in it's lifecycle - I can think of some products that keep on giving?)

I think that the stock categories based on where a product is in it's life cycle is an interesting idea, but not what I had really intended stock categories for. Normally I would expect the stock category to group like products not based on performance or position in their life cycle but on the function/type of the product. Using stock categories as you are proposing is a fudge for what your particular business is trying to acheive rather than a generically useful model IMHO. Perfectly valid for your business, but not for many/most.

Categorising items based on their life cycle I think is a good idea. But using the stock category to group products based on their life cycle doesn't seem like a great plan to me and I expect would not have generic appeal.
e.g. I would want to know not just how many items I have at the BAD stage, but how many "Set Top Boxes" I have at the BAD stage as well - where "Set Top Boxes" is an inventory category in a consumer electronics store.

I really do think a different field for stageinlifecycle is appropriate. You could make it so changing this flag alters the GL postings. Perhaps we create a table as we have for sales postings for stock postings so GL posting codes are derived from a combination of factors rather than being solely on stock category as things stand.

What we need I think is a method for webERP to determine those products that had a peak sales that have now tapered off - this then alters the flag to BAD when the sales reach say 5% of their peak or other configurable percentage. This will have to be done on some statistical basis where sales units for the last period are gathered from sales analysis and the statistics run - with periods of no stock removed - to get the trend. This mechanism would need to factor out those products whose sales have fallen off because of periods of stock outs.

An interesting topic and an area I don't know enough about to be really useful sorry.

Phil Daintree
webERP Admin
Logic Works Ltd
http://www.logicworks.co.nz
Visit this user's website Find all posts by this user
Quote this message in a reply
06-12-2012, 12:05 PM (This post was last modified: 06-12-2012 12:08 PM by PakRicard.)
Post: #18
RE: Adding some dates
(06-12-2012 08:46 AM)phil Wrote:  why is time important in determining where a product sits in it's lifecycle - I can think of some products that keep on giving?)

Why timing is important?

Usually tests are done on limited locations with limited stock. Once the test is successful, then more stock is produced or ordered and it is sold on more locations.

Example:
You bought / produced 50 units of product X to be tested in 3 locations of your 10 available locations.

You start selling and after 10 days you have sold 25 units. Congratulations! You’ve found a great product, so you need to hurry up and order / produce more, get more shelf space for it, print promotional material, etc. If you react only after the 60 days, you missed 50 days of good sales. As soon as you detect a new item is a good seller, it should be removed from TEST and changed to ACTIVE, get more stock, send it to more locations, increase price, etc.

On the other side: Let’s say after the 60 days test you have sold 10 units out of the 50. Oh s***! You chose a bad one. For the 40 remaining stock it is better you get rid of it asap. Sell on discount, send it to outlet type locations, take it out from prime expensive shelves, etc. So change from TEST to BAD asap is also important.

For sure pricing, competing products, etc also affect, but for retail businesses timing is important. I can understand it does not make much sense to a machinery workshop or to carburator producers (having much longer product lifes). In retail some products have 3 months life, so reaction should be fast based on what happens related to a period of time.

(06-12-2012 08:46 AM)phil Wrote:  I really do think a different field for stageinlifecycle is appropriate. You could make it so changing this flag alters the GL postings. Perhaps we create a table as we have for sales postings for stock postings so GL posting codes are derived from a combination of factors rather than being solely on stock category as things stand.

Regarding GL postings, I’m not sure how will work when we have for one item 2 different fields indicating GL postings.

Currently categoryid indicated the correct GL accounts for stock. Stocks.php change the postings if the item has changed category. But if we add the lifecycle field on it, could cause errors. What should take precedence for posting? Lifecycle or categoryid?

That’s why I think categoryid fits for this purpose as well (and follows the KISS principle). Following your example: You could have “Test Set Top Boxes”, “Active Set Top Boxes” and “Bad Set Top Boxes”, all of them pointing to the appropriate GL accounts. Once the category is changed, the GL postings follow automatically.

Of course it implies a multiplication of stock categories.

I will be really happy to get a new field lifecyclestage if we are able to manage the GL postings accordingly (no clue how to do it, sorry).

(06-12-2012 08:46 AM)phil Wrote:  What we need I think is a method for webERP to determine those products that had a peak sales that have now tapered off - this then alters the flag to BAD when the sales reach say 5% of their peak or other configurable percentage. This will have to be done on some statistical basis where sales units for the last period are gathered from sales analysis and the statistics run - with periods of no stock removed - to get the trend. This mechanism would need to factor out those products whose sales have fallen off because of periods of stock outs.

About getting an automated (or almost automated) method fitting a wide range of businesses to determine how to change stages in life cycle I think it is extremely difficult. I would be happy to get some reports or selection of items so webERP makes product manager tasks easier.

Some of the key questions that can be done are:

1) List of items in one stage with very good sales. Very good sales could be a percentage of sales out of stock available, or speed of sales (units/day), gross profit, on X top sales hall of fame, etc. Useful to extract TEST items that should be changed to ACTIVE,

2) List of items in one stage with very bad sales. Again the definition of bad sales can be done in several ways: percentage of stock available, speed of sales, gross profit below certain point, etc. Useful to

3) List in one stage for more than X days. Will help to detect those items forgotten by other reports, but that should be revised. Some metrics would help the product manager to decide what to do.

Again, these scripts should be a help selecting or guiding the product manager, but many different reasons can be taken into consideration (some of them not accountable, as it is a very different/funky/blinky/cool product attracting passing by customers to our shop, but it is extremely expensive, so we do not sell many but it acts as a “magnet”, so it is worth keeping it ACTIVE even if its sales performance is bad).

Just reducing the desk work load of the product manager to 50% with some scripts or reports will be a big success.
We could start with some report type scripts and later on someone bright can get the automatization stage, as happened with inventory planning and MRP previously ;-)

Regards,
Pak Ricard
Find all posts by this user
Quote this message in a reply
06-13-2012, 01:27 PM
Post: #19
RE: Adding some dates
Hi, Richard,

Thank you for your details analysis.

I think we can add a table which record about product life cycle properties. Then we can use the table information to do more things such as sales analysis, quality management etc.

Best regards!

Exson
Find all posts by this user
Quote this message in a reply
06-14-2012, 06:29 PM
Post: #20
RE: Adding some dates
OK, then. Seems a majority of us will be happy with:

New table lifecyclestages (stageid, stagename) This table should be managed via a script from Setup tab
New table stocklifecycles (stockid, stageid, date) This table should be managed similar to prices.

The question now is how to manage automatic GL postings when changing the stageid (as we do now when we change categoryid for one item). How should it be done? Which one will take precedence?

P.S.: Another nice side effect for this approach is we can keep the stockitemproperties when changing the lifecyclestage. With my previous approach, at every change of stock category we lose them (unless changed how it is managed in stocks.php, but seems not nice to do it).

I will code this, but will someone help me with the automatic posting issues? Amongst many other things, I'm really bad at accounting, so I'm afraid to screw up all the nice accounting schema we have now.

Regards,
Pak Ricard
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)