red1.org

[red1]

As we have achieved a BOMFlatView, we will later make it into a modeler that will take over the Product-BOM Window for configuring qtys and relationships within a master BOM. Meahwhile, since i m fresh from coding it, i will just see if i can quickly perfect the BOMFlatView as per Usman's request for this POC:

[red1]

redhuanoon: anyway i have asked Gan to keep track of the MSProject for me...just keep an eye of what we miss... we hope to adjust during review meeting at monthly basis or while in medan
redhuanoon: u can forward in your post to timeline thread a "Request for Change to Timeline" and provide your request + substantiation
usman1yap: yes i think that's will perfect...
redhuanoon: on my part i wana push and finish all that i plan to do ... then i can help u on our other parts..
redhuanoon: and your other parts
redhuanoon: u have to ask your ppl there what they think of the BOMView and Q system... we need feedback
redhuanoon: that is very very important... cos we dont want to make changes later...but now at the design and proto stage
redhuanoon: they must push all their ideas now
usman1yap: hv give some comment on that ...
redhuanoon: then we sieve thru and filter to what is important and phase them
usman1yap: will keep update it soon get more feedback...
redhuanoon: ok... i will now try to figure out the blanks in the BOMView as your post
redhuanoon: we cant achieve all but we put in more
redhuanoon: finally we will have like a Windows menu tree that u click on the + to show more childs
redhuanoon: when u '-' to parent only it will show the summary costs at that parent
redhuanoon: this will be really cool as per your post
usman1yap: that's is what in my mind...
redhuanoon: that i need deep sessions with Sam.. as he is the genius in such programming
redhuanoon: so far i manage to proof that all formulas can be figured out in BOMView... so basically it is no problem
redhuanoon: i also studying the Compiere structure into M_Storage where Inventory reserving happens...
redhuanoon: need to figure out best plan to interject Medan alongside it
usman1yap: hv u see my post re. virtual child in BOM ?
redhuanoon: so far it seems that we wont use BOM drop for sure
usman1yap: then..
redhuanoon: i will read that and respond there
usman1yap: so far we keep trying on bom drop...
redhuanoon: BOM drop is ok... but its not used like that anymore
redhuanoon: BOM is used in 2 areas
redhuanoon: 1) BOM DROP (2) Production Plan
redhuanoon: we now use (2)
redhuanoon: as that give proper accounting consequence
redhuanoon: the BOMView doesnt care which way u use
redhuanoon: i just make it point to the Production instead of the BOM
usman1yap: ok, then i will hv a look at (2)...
redhuanoon: but they both use same concept
redhuanoon: in Production the system will pull lines from BOM
redhuanoon: just like BOMView
redhuanoon: but BOMView is for drilling and have more flat view of everything in the BOM
redhuanoon: so its useful just like that
redhuanoon: in Production is where u can adjust the lines to be more peculiar to that particular job
redhuanoon: i.e. change the raw materials and its qtys
redhuanoon: so we will make another BOMview just for Production
redhuanoon: later we decide which to become the modeler... BOM or Production
redhuanoon: that will adjust those figures without going into BOM or Production
redhuanoon: or just View only that means change them in Compiere part.. and let Medan only be the viewer
redhuanoon: in Production... when u create the master product i.e. GA*... and u press process... it will pull all childs into lines...
redhuanoon: then press process again... it will remove those materials from storage and convert to one parent
redhuanoon: but it seems to miss one step as compared to SO
redhuanoon: in SO it reserves materials first
redhuanoon: then remove them from storage when its shipped out
redhuanoon: u look into org.compiere.model.MOrder.java under base package
redhuanoon: and the DB procedure M_Production_Run
redhuanoon: we want to make the first Production process to reserve storage just like SO. This is so that Store can see what is needed... then 2nd process will convert children stocks to master-product
usman1yap: ok, it's like combi of BOM drop and production plan...
redhuanoon: later in queue system will consume the stocks as each shopfloor queue happens... but this may be complex ...and we have to discuss that after POC as i m still not clear of your stock accuracy.. ie.. how many times more stocks u carry vs the shopfloor WIP usage... if its many times more ...then such accuracy not important.. but if your stocks is cukup-cukup for shopfloor WIP... then such movement is needed.
redhuanoon: if BOM drop like what we discussed on last day before we left Medan... it wont show the parent product but all the children as if sending all children to customer which we dont want... we want to send just parent... so in Compiere's Production it already solve that... just say what parent... and it will gather the children and convert in the stock to finished goods
redhuanoon: just that compiere's production dont have the queue system to keep track of production... now we going to have... so i dont wana bite off too much.. so lets get the queue system up... then fine tune the queue stock detailed movement... but without that also we can get an overall stock control.. which is big stuff

[red1]

Gud news! We now have more of what Usman wanted!

pls see http://compiere.red1.org/BOMflatView.html and http://compiere.red1.org/BOMSub.html

Now parents can tell what is the price at its level and total for the master product. These extra info is shown within brackets. Pls check if figures are correct.

David can checkout again from CVS to try it out. This time the codes are more challenging but ingenuis *haha*

[Usman]

Nice, now we hv all the prices.
Pls. put UOM after quantum and also currency before total price it will give more clear information.

[red1]

Have just put in UOM after quantum and Currency before TotalPrice. Pls check the screenshots again.

Code is sent to CVS.

Can u tell me in what way is this module useful. In what way is it better than the Clipper version? I need to get a sense of comparison, so that i understand how to improve it further.

Basically i see that when u began to configure other processes such as Casting, HT, etc into the Compiere BOM the same way we did for moulding, it shuld throw up a master product with all the sub-costs given.

Yesterday while discussing with Gan we also trash out how to best resolve the double or triple etc items per mould and wonder if that is easily solve by just putting the mould cost as 0.5 or 0.33 or 0.25 qty in the overall BOM. This means that all costs are amortised to quantum usage.

As u hilite what other info demands of users, ideas may come up on how best to fulfill them.

[Usman]

Hv Successfully map out complete moulding bom hirarcy, but need to perfect your bom flat view.

Study below case :

======================================================Qty====Unit Price====Quantum===TtlPrc
Total Moulding Labor + Overhead ==================== 1.0==== 24.445436==== (each)=== USD24.445436
|
|--Mother Mould Labor + Overhead =================== 6.03=== 3.6693363==== (each)=== USD22.126099
| |--MotherMould Labor cost==================== 1.0==== 2.3193364==== (each)=== USD13.9855995
| |--Moulding Overhead ==================== 1.0==== 1.35==== (each)=== USD8.1405
|
|--Core Mould Labor cost================================ 1.0==== 2.3193364==== (each)=== USD2.3193364

As u can see overhead cost calculation is depend on time length of mother mould making (6.03 hr).
Ofcourse we also can configure moulding overhead independently (different parent) but in the real life situation,
when material list grow deeper and wider this loose structure can cause unwanted mis updated problem,
such as when we want to update and change mother mould making to let's say 5 hr there is a possibilty to mis update overhead.
But following above rule sometimes can cause awkward and/or not informative view for other ppl.

We need a feature to eazily rearrange/reconsolidate above view to become more understandable view as follow :

Total Moulding Labor =============================== 1.0==== 16.30493==== (each)=== USD16.30493
|--MotherMould Labor cost ======================= 6.03=== 2.3193364==== (each)=== USD13.9855995
|--Core Mould Labor cost ================================ 1.0==== 2.3193364==== (each)=== USD2.3193364

Moulding Over head ================================= 6.03=== 1.35==== (each)=== USD8.1405

Hope u can in corporate this in your bom modeller.

[red1]

Just synched with CVS on the latest codes for BOM Modeller. Now it can save your BOM Model to CACHE, and GET from CACHE.. Not yet able to CALCULATE when changes done to BOMQtys. Working on it now.

(notice that SourceForge gave a different name path in its website for CVS. Gan also noted that and posted complete namestring). U have to clear your old CVS info, by >Eclipse > Project > Team > Disconnect > Delete CVS info. Then share back and override & update

New table to create is

[red1]

Hey! Usman! Wake Up! Now the BOM Modeller is almost complete. Only left is Commit: DB. ( i been programming non-stop from this morning to get to this stage).

Pls take from CVS and test it torohly to see that it is safe and sound. It will allow editing of BOMQtys and CALCULATE will quickly give complete answers without Compiere. Then u can save those new results to CACHE. And recall again (Get: Cache) for further formula changes. Finally when satisfied we will have Commit:DB that will write to the Compiere BOM table.

This modeller can also do consolidated view. To save time do consolidate from the cache and not from DB. I turned off edit fields when in consolidated view as edit needs non-consolidated layout.

I have tested with Get:DB (GA-M2209) > Commit:Cache > Get:Cache> consolidate, Calculate, Commit:Cache few times changing the formula of sand qty and it gives clean results and speeds. I m still not sure if its 100% working so u need to try and confirm.

Happy testing, Usman!

[Usman]

my comment :
1. Get DB still very slow, i think u need to fine tune to get it much more faster.
2. What if one same BOM is Get DB from 2 different machine at same time (not sure, but when i try after commit : cache and get : cache from each machine the total sum is change, maybe cause by double up record)
3. Cannot make new child.
4. Auto commit : cache at the first get : DB will be helpful, bcoz
if get : DB , change some value and directly commit : calculate,
will return null screen.
5. I'm using linux machine (192.168.10.206) with no oracle, and if i run tomcat/medan on my machine to access oracle sit on anna's pc (192.168.10.26), i can't get any result.

[red1]

i found out some way to improve the Get:DB. Working on it now. Also the fill up higher prices not ok in cache, toh the grandtotal is correct. That will solve one shot.

What u mean by 2 different machines? different PCs?

[Usman]

yes 2 diff machine = pc or ip
try it out if u commit:cache same bom from 2 different pc at the same time,
it will cache the record wrongly.

[red1]

The BOMFlatView and vm has been updated. Pls take from CVS.

1) Commit:DB done! (pls run script below first to reset.)

2) GET:DB for GA-job now takes 40secs! (previously 90 secs).

3) CALCULATE for changed BOMQtys in GA-job now done instantly! with no error observed.

Pls test and report back steps to replicate any error found.

[Usman]

Wrongly cache record still happen.
Try this step :
1. get:DB same bom from 2 different pc or ip ie. P_MOulding
2. commit:Cache at same time from both PC
3. get:Cache
4. screen will show up double record.

Speed is much more increasing but to get BOM of GA-M2209
still need around 1 minute 8 sec can we go lower (our legacy takes no more than 1 second).

speed of get:cache, commit:calculate and commit:cache is improve much now.

[red1]

pls give steps on how to get from 2 different PCs. And why must BOM be taken from 2 different PC/DBs? (If u need to chat with Gan, u can explain to him so that i can get answer from him later. I m busy at the moment working on a excel reporter engine for the system).

The speed from DB is the best i can do to maintain that the module is portable to future versions. To make it faster is to lock at Oracle layer (using stored views) which i dont want to do.

The idea is to use cache to do all further estimations and not even need to write and get from DB again. Cos the BOMs in DB has no real use except for initial framework and final Sales Order (OC). That means u read from DB probably once and write back to it also once, as final OC.

[Usman]

eventhou now we only hv one estimator but in future we cud add more, which means there is a possibility for mentioned case and can lead to severe wrong overcalculate price and cost structure.
u can easily create virtual pc in your notebook using vmware to simulate this case or ofcoz u can also hv gan's notebook connect to yours.
to avoid it, i suggest u to put flag to the BOM so when someone get:DB then next user only can view it, not edit or commit:cache, basically it is
similar to one invoice edited by two user which is prohibited (basic transactional rules)...
ok, i agree to not use stored views, but not with the usage of BOM.
Estimator or other user review boms from time to time, and responsive
speed is very helpfull and needed (fast and accurate estimation).
understand that it is still a prototype, but later on u can review and enchance it for the feasiblity in real situation.

[red1]

Some more gud news about the BOMModeller. I have added the Child adding feature to avoid going to Compiere just to add a BOM child. U can now do it right from the BOM Modeller! However after adding childs, they wont show in the Viewer until u Get:DB. This feature creates only records in M_ProductBOM table and increment CurrentNext ID in AD_Sequence. Tested ok.

Sent to CVS:
> BOMFlatView.java
> BOMFlatView.vm
I will take note all issues on this Modeller for future version review.

Also gud news for David/Eddie. I have created the getNextID and incrementID methods within the BOMFlatView for reuse by any outside class.

Take a look at the codes and u will see how easy it is to use it for your Requisition Module.

[Gan MH]

From my understanding, Usman is trying to simulate get:Cache action from two separate estimators/users at two different terminals. The simultaneous commit:Cache action from these two users has resulted in two sets of cache records. I guess the questions are how often do two commit:Cache actions happen at the same time? And how long does it take for one commit:Cache action? The problem shall not arise if there is no simultaneous action as system will always delete the old cache before committing a new one. Shall we make the latest one overwrite the earlier cache record? Or we will have to figure out disabling any write action when there is an active commit:Cache action.

[Usman]

yes, gan got my point.
I think your approch of how often do two commit:cache, is not the answer we expect. it means there is still a trap hole in side, and eventhou very small possibilty of occurance but when it happen it can cause serious problem and it is crucial to patch this hole.
i leave it to u how to code it, as long as we can get correct and clean result.

[Usman]

just found out simple way to test commit:cache problem.

1. open two window of internet explorer.
2. get:DB same BOM.
3. simultaneously click commit:cache for both windows. (several times)
4. get:cache and u will see the problem.

[Usman]

some add BOM line finding :
1. close loop problem.
* child and parent is the same
example : parents: silicon child : silicon

* add own parent as child.
example: parents : silicon child : P_Casting

i suggest to verify BOM before add new line.

2. how to create new parents ?

[red1]

Thanks and take note when instructing users not to use those loopholes temporarily. Force used onto depts to discover other issues so that we save time solving all these stuff one-shot

All comments shall be alotted to future version (ver 2.0) - Learning oppurtunities for internal development team en route, but they have their priority before revisiting non-critical issues.

About creating parents, they can be done by going back to the usual Compiere's Product window.

btw if i got time, i m a bit itchy to use Oracle materialised view to speed up really fast

[Usman]

yes, ofcourse compiere interface can do all the thing, but we need complete feature in your new BOM interface, including BOM type (alternative/optional/standard). we want to hv powerful, wyswyg, all in one screen and eazy to use interface. I believe u can provide that.

[red1]

The above as task assignments for David/Eddie to take up when they are ready. They should create separate Java copies and not overwrite my one.

State exactly what u want to do. and it shuld be small task. i.e. Make child selection not to include selected parent.

And wait for my go ahead before doing it, cos others may be doing it also.

[red1]

The speed to GET:DB is now 8 secs!

1) Checkout the latest BOMFlatView.java from CVS.

2) Run this script in TOAD.

[Usman]

yes, speed is improve very much. I think it should workable now.
found little bug : when get:DB the last child is not included / retrieve.