redhuan d. oon
I have upgraded Libero plugins for iDempiere 3.0 development branch. You may take and test it on iDempiere 3.0 (Jetty edition) only:
1. Libero Manufacturing with 2Pack - http://sourceforge.net/projects/red1/files/p2/LiberoMFG/org.libero.manufacturing_3.0.0.201502230749.jar/download
2. Libero Mfg Swing forms - http://sourceforge.net/projects/red1/files/p2/LiberoMFG/org.libero.manufacturing.swing_3.0.0.201502230749.jar/download
Further progress here http://red1.org/adempiere/viewtopic.php?f=45&t=1775&p=8640#p8640
Pritesh Shah
org.adempiere.pipo2.exception.POSaveFailedException: Failed to save column Movement Quantity- Does any of the above plugin changes or override the existing code ?
- Does any of the above plugin changes or override existing db tables ?
- What is the difference between the above two plugins ?
- Does above plugin changes or override the existing code ?
- Does above plugin changes or override existing db tables ?
redhuan d. oon
I will also check deeper by restoring a fresh source from my bitbucket and do another ground test pack in via Eclipse as i detected anomalies with the Packins in other DB users.
About your questions:
1. Libero Mfg: there is no model structure change and backward compatibility is maintained. However i done an important naming schema change to replace eevolution as its a commercial vendor name that no longer maintains this package for at least 8 years. I replaced it with Libero as its authoritative FOSS project name. I still maintain chief copyright attribution to Compiere and eEvolution as main package creators.
Such name changes should not affect user data, but mostly code and thus process and form calling from metadata are changed. If you are using an older version of Libero, the PackIn should resolve all that. Otherwise what i written here and in my forum can be a guide.
This time around, as reported in the forum, i also made a good enough completion of the Swing BOM Drop Configurator and am negotiating with Hiep to help in the ZK version of it.
2. WMS: Again, it is just a porting over from ADempiere to iDempiere with new InfoWindow replacing SmartWindow. Of course like in Mfg i tidy up some bugs and spanish wordings to English.
However I was not happy with this work because i did not receive good real world practice as reference. However in my recent trip again to Slovakia and discussed with such a big world reference done by Multimage, Norbert Bede does need help in preparing documentation for his WMS which is used at Kia Motors there. We planned to spend a whole October month this year in Bratislava to do just that, besides trying to contribute also their Magento, Alfresco and Cloud integration works.
To repeat what i have presented in my forum postings, Libero packages are poorly documented and even coded (and i still welcome other peer reviews to challenge my findings). There are great works in concept and even design. But in ERP space, without documentation, you are as good as in the stone age without a map. What we are doing and still at it is writing out the first maps. Few months back in Denmark, a reference who is a manufacturer of wind turbines and truck bodies gave me better insight into what Libero should be. He also showed me other proprietary software. I already wrote about it in the same forum thread linked above. A month prior to that, in Laos, Nakarat who has ERP and Mfg experience from Thailand shared with me how other MFGs does it. I am also guided by my French partner, Andre Legendre who did French branded automotive shopfloor systems. But my frustration has been, you guess it, poor documentation or in better sense, an analysis of what the gap is with Libero and how to bring it forward. The exception been the finest analytical and constructive critique thus far by Chuck Boecking in another thread. Nevertheless if you come across anything further, i be glad to have them.
I am delayed to release the Libero Mfg 3.0 due to present work occupying me in Russia to upgrade the SFAndroid to SpinSuite, so i reckon i have to wrap it up before 2015 ends.
But thank you for testing at your end. And i will get back on further testing this side soonest possible.
Pritesh Shah
redhuan d. oon
The important advancement in the OSGi plugin approach is to keep as clean a decoupled module where it extends core either as fragments or wrappers and never changing core without the best team review and permission. You can follow our JIRA trackers particularly submitted by me (not many) towards the core thanks to some discovery during the making of such modules. This is so important in terms of lowest worry over the long term and lowest maintenance cost possible. That is why i strongly recommend for ERPs to follow this iDempiere project. It is technically most sound and open with no direct commercial ownership.
redhuan d. oon
Ferry Irawan
Have you ever seen this error every time completing a sales order ?
50001 is sales order document with organization Fertilizer with product Fertilizer#50 with BOM type Current Active. If I change BOM type becomes Make-To-Order or Make-To-Kit, these error is gone and new manufacturing order is created.
But my requirement is not "make to order",let MRP calculation run and create manufacturing order then (not automatically from sales order).
Any suggestion for me?
Thanks before.
redhuan d. oon
Ferry Irawan
Thank you for your feedback.
I will try to add some screenshots and log. FYI this error also apply for idempiere 2.1 also.
1. Firstly BOM type is "Current Active" (screenshot 1)
2. Complete a Sales Order and get error (screenshot 2)
3. Server log
15:14:27.930-----------> Msg.translate: NOT found: PP_ProductBOM_ID [182]
15:14:27.930-----------> Msg.translate: NOT found: PP_ProductBOM_ID [182]
15:14:27.930===========> MOrder.saveError: Error - * Not found * PP_ProductBOM_I
D [182]
15:14:27.930===========> MOrder.saveError: Error - * Not found * PP_ProductBOM_I
D [182]
15:14:27.930-----------> MWFActivity.run: MWFNode[185-(DocPrepare),Action=Docume
ntAction=PR] [182]
java.lang.Exception: SaveError
at org.compiere.wf.MWFActivity.performWork(MWFActivity.java:1047)
at org.compiere.wf.MWFActivity.run(MWFActivity.java:874)
at org.compiere.wf.MWFProcess.startNext(MWFProcess.java:373)
at org.compiere.wf.MWFProcess.checkActivities(MWFProcess.java:283)
at org.compiere.wf.MWFActivity.setWFState(MWFActivity.java:277)
at org.compiere.wf.MWFActivity.run(MWFActivity.java:891)
at org.compiere.wf.MWFProcess.startWork(MWFProcess.java:505)
at org.compiere.wf.MWorkflow.start(MWorkflow.java:687)
at org.adempiere.util.ProcessUtil.startWorkFlow(ProcessUtil.java:313)
at org.compiere.apps.AbstractProcessCtl.startWorkflow(AbstractProcessCtl
.java:391)
at org.compiere.apps.AbstractProcessCtl.run(AbstractProcessCtl.java:209)
4. Change BOM type is "Make-To-Order"(screenshot 3)
5. Complete a Sales Order and success creating manufacturing order.(screenshot 4)
6. MRP info(screenshot 5)
Thanks,
Ferry
redhuan d. oon
if( bom != null
&& !MPPProductBOM.BOMTYPE_Make_To_Order.equals(bom.getBOMType())
&& !MPPProductBOM.BOMTYPE_Make_To_Kit.equals(bom.getBOMType()) )
{
throw new AdempiereException("@NotFound@ @PP_ProductBOM_ID@");
}It seems to be a purposely done code where only two BOM types are allowed above. Please review if such feature is wrong in subject matter. It is best to look through the whole class as it is very elaborate and complex in its logic. So outright objection to the above snip is not recommended without a subject matter analysis of the whole class at least. (It involves more classes later).
ferry.ir...@gmail.com
Hi Red1,
Thanks for your feedback, as I know that manufacturing module must support 2
types of manufacturing order.
First, manufacturing order created to fulfill the stock and achieve level of
availability ( called Make To Stock or MTS), requirement can be taken from
monthly demand or forecasting.
Second, manufacturing order created base on order(called Make To Order or MTO).
In Libero, I see MTO scenario is supported but not MTS.
So I try MTS scenario by using bom type "Current Active" because "Make-To-Stock" or "Make-To-Kit" is already designed to support MTO scenario only.
I change MMPMRP.java at line 127 becomes
//Validate BOM
if(bom == null && pp != null)
{
bom = new MPPProductBOM(ol.getCtx(), pp.getPP_Product_BOM_ID(), ol.get_TrxName());
if( bom != null
&& !MPPProductBOM.BOMTYPE_Make_To_Order.equals(bom.getBOMType())
&& !MPPProductBOM.BOMTYPE_Make_To_Kit.equals(bom.getBOMType()) )
{
/*FERRY 12.12.2015
* If BOM Type is current active not need to create MO
*/
if ( MPPProductBOM.BOMTYPE_CurrentActive.equals(bom.getBOMType()) )
{
return null;
}
else
{
throw new AdempiereException("@NotFound@ @PP_ProductBOM_ID@");
}
}
}
I test it and so far it works. I can create sales order well, the it created "DEMAND" on MRP View, then I run Calculate Material Plan and system creates draft of manufacturing order base on totally demand(check on screenshot).
Demand Qty: 5 + 4 + 3 + 250 = 262
On Hand Qty: 160
New Manufacturing Order = 262 - 160 = 102 , because on my setting a manufacturing order must be multiplied by 24 (1 lot = 24) then system proposes 144 ( 6 x @24)
Thanks,
Ferry Irawan
redhuan d. oon
Thanks for the subject matter explanation and real life usage on this. If you can confirm that this must be part of the Libero MFG universally, and others who are using it have no objection, then i will incorporate your change into it.
ferry.ir...@gmail.com
In my opinion, MTS scenario must be supported too. Because not every case must be implemented with MTO, especially with high demand finish good (better to stock previously).
MTO more to specific finish good because the demand is not regular(example product with specific formula).
I try to compare libero with another commercial ERP, if both scenario work with Libero. I think Idempiere + Libero can be nice and attract many industries to use.
Thank you.