Issues with pegging
Ash
Apologies if this is a duplicate, I tried to post a lengthy one earlier and it seems to have failed to upload. I'm going to post this in pieces.
I’m finding several issues with pegging information in Frepple version 6.9.0. I’m wondering if I have set something up incorrectly, or if there is a bug. Does anybody have ideas?
Issue 1: there are opplans in the pegging that don’t exist. This is causing weird behavior, like the “plan” screen showing an MO that is a child of a PO.
The problem is that there is an intermediate opplan that doesn’t exist. This “phantom” opplan is completely unnecessary and screws up the depth/lvl. The depth showns above is 0,2,3,3,4,5,5. It should be 0,1,2,2,2,3,3.
Why are there opplans in pegging that do not exist? Is this a setup issue on my end, or a bug?
SQL to generate this view:
select
d."name" as demandid
,p.value->>'level' as lvl
,p.value->>'opplan' as opplan
,p.value->>'quantity' as quantity
,p.ordinality as seq
,o2.item_id
,o2."type"
from
demand d
cross join
lateral jsonb_array_elements(plan->'pegging') with ordinality p
left join
operationplan o2
on p.value->>'opplan' = o2.reference
where
d.name='S000004449-003'
Issue 2: The depth is wrong, per my comment above.
Ash
I’m finding several issues with pegging information in Frepple version 6.9.0. I’m wondering if I have set something up incorrectly, or if there is a bug. Does anybody have ideas?
Issue 1: there are opplans in the pegging that don’t exist. This is causing weird behavior, like the “plan” screen showing an MO that is a child of a PO.
The problem is that there is an intermediate opplan that doesn’t exist. This “phantom” opplan is completely unnecessary and screws up the depth/lvl. The depth showns above is 0,2,3,3,4,5,5. It should be 0,1,2,2,2,3,3.
[IMG1]
Why are there opplans in pegging that do not exist? Is this a setup issue on my end, or a bug?
[IMG2]
SQL to generate this view:
select
d."name" as demandid
,p.value->>'level' as lvl
,p.value->>'opplan' as opplan
,p.value->>'quantity' as quantity
,p.ordinality as seq
,o2.item_id
,o2."type"
from
demand d
cross join
lateral jsonb_array_elements(plan->'pegging') with ordinality p
left join
operationplan o2
on p.value->>'opplan' = o2.reference
where
d.name='S000004449-003'
Issue 2: The depth is wrong, per my comment above.
Ash
Issue 3: The quantities in pegging are sometimes wrong. The issue appears to be related to “approved” supply orders (child, not parent), but doesn’t affect newly “proposed” supply orders. I am putting ERP released manufacturing orders as approved, so that the system will reschedule them based on calculated bottlenecks
Here is an example from the same SO as above. The -130 part number has a quantity pegged of 0.132; this is the only pegging of this item against the SO.
Pegging is the same if I look at pegging for 5470912
However the operationplanmaterial for 5470912 calls for 2.11, and there is plenty of inventory.
This is not a bottleneck for the sales order. The bottleneck
is -310.
Any ideas?
Ash
Issue 3: The quantities in pegging are sometimes wrong. The issue appears to be related to “approved” supply orders (child, not parent), but doesn’t affect newly “proposed” supply orders. I am putting ERP released manufacturing orders as approved, so that the system will reschedule them based on calculated bottlenecks
Here is an example from the same SO as above. The -130 part number has a quantity pegged of 0.132; this is the only pegging of this item against the SO.
[IMG3]
Pegging is the same if I look at pegging for 5470912
[IMG4]
However the operationplanmaterial for 5470912 calls for 2.11, and there is plenty of inventory.
[IMG5]
This is not a bottleneck for the sales order. The bottleneck
is -310.
[IMG6]
Any ideas?
Johan De Taeye
Hi Ash,
It’s impossible to answer the questions in detail from the pictures alone.
We are not aware of any bugs in the pegging right now.
Tricky cases for the pegging would be supply paths with loops, where the same material is used at multiple points in the path, or paths that are diverging and converging again.
Are any of these present in your supply paths?
Stay safe,
Johan De Taeye
Mob: +32 477.385.362
Skype: jdetaeye
Visit us at https://frepple.com
--
You received this message because you are subscribed to the Google Groups "frePPLe users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to frepple-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/frepple-users/53ff908c-f0ae-43a3-8904-188f9d747404n%40googlegroups.com.
Ash Rice
This part is not used in multiple places in the part path, but that does happen with other parts
You received this message because you are subscribed to a topic in the Google Groups "frePPLe users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/frepple-users/zvnj8Ks__kA/unsubscribe.
To unsubscribe from this group and all its topics, send an email to frepple-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/frepple-users/e5e4d388b609c6d8be06d750cef40e22%40mail.gmail.com.
Johan De Taeye
>>By loops do you mean circular references? If so, that does not exist
Yes.
Eg Item A consumes part B. Part B consumes A again.
>>Can you elaborate on what you mean by diverging and then converging? I don't understand.
You get this when some operations are done in parallel.
Eg Item A consumes B and C. B consumes D. C also consumes D. D consumes E. In this case the bill of material expands/diverges at item A. At item D the supply paths collapse/converge again.
The problem is that there is an intermediate opplan that doesn’t exist. This “phantom” opplan is completely unnecessary and screws up the depth/lvl. The depth showns above is 0,2,3,3,4,5,5. It should be 0,1,2,2,2,3,3.
Why are there opplans in pegging that do not exist? Is this a setup issue on my end, or a bug?
To view this discussion on the web visit https://groups.google.com/d/msgid/frepple-users/CAMT0sv1b7iz6Vv-7CkAhRn5EufMWDxOM2sj6gM9O3mi3Zu9e6Q%40mail.gmail.com.