webERP Forum

Full Version: Work Orders With Multiple Items - Context?
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5
This does not seem to work at all. Costing appears to be okay but Issue and Status seem to mix items together.
Looking at the SQL queries there is no way this will work given all material is grouped together at the Work Order level using reference field in stockmoves.

Again this whole Work Order feature appears to be only half baked or never thoroughly tested.

Sorry guys but this is VERY irritating...
Should not the SQL used for WorkOrderStatus.php and WorkOrderIssue.php be the same?

Why do we have Group BYs in Issue SQL but not in Status SQL?

Are these pages supposed to be per WO or per WO item?

Very confusing...
It appears Issue is for the entire Work Order but Status is for a Work Order item?

In some places Issue has GROUP BY and $_POST['StockID'] in the WHERE clause.
From what I can see there I no way to associate StockMoves with individual items in a Work Order. We would have to add more data to the reference field (e.g., X.Y where X=WO and Y=Line Number or ParentStockId).

If we are going to allow multiple items on a Work Order I believe we must use a reference as stated above
Okay... I have removed grouping from Issue and changed StockMoves/Reference to be WO.ParentStockID and all appears to be working.

Since we are on the verge of releasing 4.15.1 I suggest we defeat multiple items on Work Orders UNLESS somebody has time to check all the changes to my scripts. if any of you want to take on this task let me know and I will post all my files...
I don't quite understand this ... work orders can be for multiple items by design from the very start.
Yes stockmoves from work order receipts associate a stockid with the work order and stockserialmoves associate individual lots with a stockmove id
Yes they can be made but when you do a partial receive things go sideways. WorkOrderCosting.php works as expected. Now try WorkOrderIssue.php and WorkOrderStatus.php and you will see mixed parts from the BoMs. There is no way it can work as designed by using the reference field in the StockMoves table as it is constructed. If I have a Work Order with many parent items each with many BoM items they all go to the StockMoves table with the exact same reference. How then can we unravel which moves are associated with which BoM part in which WO line item?

Try it with a partial receive and you will see the problem quite quickly...
Also... We are passing StockID but showing ALL the items in the WO? Either the StockID is not required or the results are not correct:


So WorkOrderIssue.php should be for one item but shows all items? WorkOrderStatus.php mixes ALL item issues together. Note how two partial receipts result in all going to either one of the items:

[attachment=888] [attachment=889]

Given what I see below BOTH WorkOrderIssue AND WorkOrderStatus should be in context of the WO item, not the entire WO:


I have developed all my new scrips to be in context of each WO item but perhaps we wanted them to be in context of the entire WO? That seems redundant to the purpose of WorkOrderCosting and the hyperlinks per WO item imply in-context data to follow.

All VERY confusing... And does NOT work... And can NOT work as designed...

I can only guess nobody is really using Work Orders or nobody has ever used it with multiple items or nobody has ever used it with multiple items and partial receipts.

We really should fix all this prior to release of version 4.15.1...
I want to finish by stating LOUDLY and CLEARLY that we LOVE webERP and we are very grateful for all the hard work that went into it.

But... These sort of half-baked and/or untested features really irritate me...
You obviously loose any reference to the finished item for the components required for work orders with multiple outputs. How could it be any different. If you issue an item to a work order then it could be a component of any of the output items.
Yes we need to consider the entire WO
I need to dive back into this to understand what is wrong.
You cannot relate any issues to a particular BOM part only that there was an issue of item X to work order Y. Equally it is possible to issue non-BOM'ed items to the WO too. This is not a mistake - but by design.
There are many areas of webERP that are "half baked" - it is a work in progress.... Sales order properties, item properties, capacity planning, work centres and routings, EDI .... your irritation would be understandable if you had paid something :-)
If there are multiple items on the WO then the WO will refer to multiple items ... if you call up a WO with multiple items they will all show against that WO.
The answer in your situation I suspect is to make the WO for just a single item!!
Agreed and I realize my words were a bit harsh but I sort of expected it to work out of the box. Just cerate a new WO with two items with BoMs that share common components. A component of type LABOR in each BoM is a very good start. You will see the scripts present data that is not correct.

I will gladly share all my revised scripts as they have addressed this issue and allow for granularity at the WO item level. Before I do though, I need to know the EXPECTED operation of the scripts. I do not want to throw users into the ditch due to revised context functionality.

The good news is Costing works as expected but we still have the issue that WO items with Labour and/or Overhead costs get lost and throw the inventory value off. I have also addressed this issue in my scripts. See here:

This is another piece that really threw me off the rails...
Yes - I will need to study and possibly fix - I'd rather not ditch what we have until I am confident I have properly messed up.
How about i send you my scripts via email. That way you can verify them and we will not throw other webERP users off track.

My approach is that Costing is for the entire WO and Issue/Status is in context of WO items.

Also... Any changes must be backwards-compatible...
Also... CollectiveWorkOrderCost.php is not grouping like items together when they exist in BoMs for each parent item in the WO.

This change, which adds SUM and GROUP BY, seems to work:

PHP Code:
            //lets do the workorder issued items retrieve
$sql "SELECT stockmoves.stockid,
                SUM(qty) AS qty,
                FROM stockmoves INNER JOIN stockmaster
                ON stockmoves.stockid=stockmaster.stockid
                WHERE stockmoves.type=28
                AND reference IN (" 
$WOSelected ")
                GROUP BY stockmoves.stockid,
                ORDER BY reference"

I have looked long and hard at all this and I still feel the best way is to fill the StockMoves.Reference field with WOId and ParentStockId instead of just WOId. This gives us enough granularity to manage WOs and every WO item in the context of any report we may need.

But... This presents an issue with respect to backwards compatibility. In our case I believe we MUST have the granularity stated above but I do not really want to maintain a special fork of the code. The obvious fix seems to be to never place more than one item on a Work Order, which seems reasonable, and perhaps even good practice. It also allows for much easier time capture as all time goes against an entire WO, not a certain WO Item. WOs with many items could get confusing very quickly.

We still have the issue that Labour and Overhead costs are not coming over during WO receipt and causing a mismatch with respect to inventory value. The obvious fix seems to be to never use these two fields for items with BoMs but then it is my opinion we should hide these input fields for items with BoMs. My new scripts accommodate Labour and Overhead at the parent level for items with BoMs but again this may present a backwards compatibility issue and, again, I do not really want to maintain a special fork of the code.

So... What do we think about disallowing multiple items on Work Orders (perhaps a system setting) and hiding Labour and Overhead standard cost inputs for items with BoMs? This seems to be a very good compromise in that it prevents these issues from occurring and, in my opinion, makes weERP safer and more intuitive for new users. This forces webERP users to create Stock Categories for Labour and Overhead to be used in BoMs. Does this make sense?

I also have Work Center setup working but that is a whole topic on its own...
So now... What about M parts with no BoM? These parts should have Labour and Overhead costs associated with them. If we add these sort of parts to a WO and receive them do we still have the same issues? My guess is inventory value will again be mismatched after receipt of WO items. As stated above my scripts have addressed Labour and Overhead costs associated with them but not Material for items without BoMs.


So... Do we disallow these sorts of items from being placed on WOs?

Many Use Cases for WOs and all should be visited...
Pages: 1 2 3 4 5