Issues with pegging

36 views
Skip to first unread message

Ash

unread,
Nov 19, 2020, 4:52:56 PM11/19/20
to frePPLe users

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

unread,
Nov 19, 2020, 4:59:34 PM11/19/20
to frePPLe users
Reposting with pictures as attachments

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.

IMG1.png
IMG2.png

Ash

unread,
Nov 19, 2020, 5:04:41 PM11/19/20
to frePPLe users

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

unread,
Nov 19, 2020, 5:11:17 PM11/19/20
to frePPLe users
Let's try this yet again with images as attachments:

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?

IMG6.png
IMG4.png
IMG3.png
IMG5.png

Johan De Taeye

unread,
Nov 20, 2020, 1:17:27 AM11/20/20
to freppl...@googlegroups.com

 

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

unread,
Nov 20, 2020, 12:14:09 PM11/20/20
to freppl...@googlegroups.com
By loops do you mean circular references? If so, that does not exist
This part is not used in multiple places in the part path, but that does happen with other parts
Can you elaborate on what you mean by diverging and then converging? I don't understand.

I'm trying to distill this issue down to a simplified model that I can share. Will advise.

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

unread,
Nov 21, 2020, 4:26:36 PM11/21/20
to freppl...@googlegroups.com

 

>>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.

 

Johan De Taeye

Mob: +32 477.385.362

Skype: jdetaeye

Visit us at https://frepple.com

 

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?

Ash Rice

unread,
Nov 23, 2020, 5:20:41 PM11/23/20
to freppl...@googlegroups.com
Okay, I figured out what was going on with "Issue 3". It was related to data setup and is not a bug; it just wasn't showing what I expected. My open manufacturing orders were showing a quantity of 1 in operationplan, with a operationplanmaterial of the actual expected production quantity (they don't have to be the same). The pegging is calculated based on the quantity in operationplan, not the quantity that the manufacturing order produces in operationplanmaterial. 

In the example above, the MO was producing 16, so 0.132*16 = 2.116; that's exactly what I expected.

I've now changed the data setup so that the MO quantity matches the actual production quantity.

The depth is still wrong, but it's not important enough for me to spend time distilling an example down to share with this forum.
Reply all
Reply to author
Forward
0 new messages