Sage 100

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON
------------------------------

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Exactly along the line of what @David Overholt and @Eric Lunceford said, I have a customer on v2020 with Scanco MB / WMS who had this problem and traced it herself to clicking the Cancel button in S/O Entry in her case. As a matter of practice, she made sure that her staff, before clicking on Cancel or Delete in S/O Entry that they "zero out" the Qty Ordered of each line on a SO. This solved her problem. I imagine that it's really just the Cancel button not Delete that causes the Qty on SO in IM_ItemWarehouse to not get reset. To make life easier, I created a simple button script for them called "Zero Out"  they click on as needed to zero out Qty Ordered for each line before they click Cancel or Delete. I'm sure there are several other causes too.

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Exactly along the line of what @David Overholt and @Eric Lunceford said, I have a customer on v2020 with Scanco MB / WMS who had this problem and traced it herself to clicking the Cancel button in S/O Entry in her case. As a matter of practice, she made sure that her staff, before clicking on Cancel or Delete in S/O Entry that they "zero out" the Qty Ordered of each line on a SO. This solved her problem. I imagine that it's really just the Cancel button not Delete that causes the Qty on SO in IM_ItemWarehouse to not get reset. To make life easier, I created a simple button script for them called "Zero Out"  they click on as needed to zero out Qty Ordered for each line before they click Cancel or Delete. I'm sure there are several other causes too.

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Thank you everyone!  Now I have figured out that with True Commerce, if an item is on an incoming order that is not in Sage, however the rest are it increases the qty ordered on SO even though an SO is not created until the missing item is created in Sage.  I upgraded them to 2023 in February.  True Commerce did not cause this in version 2020.  I will be calling True Commerce.

Exactly along the line of what @David Overholt and @Eric Lunceford said, I have a customer on v2020 with Scanco MB / WMS who had this problem and traced it herself to clicking the Cancel button in S/O Entry in her case. As a matter of practice, she made sure that her staff, before clicking on Cancel or Delete in S/O Entry that they "zero out" the Qty Ordered of each line on a SO. This solved her problem. I imagine that it's really just the Cancel button not Delete that causes the Qty on SO in IM_ItemWarehouse to not get reset. To make life easier, I created a simple button script for them called "Zero Out"  they click on as needed to zero out Qty Ordered for each line before they click Cancel or Delete. I'm sure there are several other causes too.

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON

Since this is somewhat of a post on sort tables and rebuilding, does anyone use task scheduler to rebuild after hours or is this an impossible task to schedule?  Client just called wanting to schedule the rebuild.

Thank you everyone!  Now I have figured out that with True Commerce, if an item is on an incoming order that is not in Sage, however the rest are it increases the qty ordered on SO even though an SO is not created until the missing item is created in Sage.  I upgraded them to 2023 in February.  True Commerce did not cause this in version 2020.  I will be calling True Commerce.

Exactly along the line of what @David Overholt and @Eric Lunceford said, I have a customer on v2020 with Scanco MB / WMS who had this problem and traced it herself to clicking the Cancel button in S/O Entry in her case. As a matter of practice, she made sure that her staff, before clicking on Cancel or Delete in S/O Entry that they "zero out" the Qty Ordered of each line on a SO. This solved her problem. I imagine that it's really just the Cancel button not Delete that causes the Qty on SO in IM_ItemWarehouse to not get reset. To make life easier, I created a simple button script for them called "Zero Out"  they click on as needed to zero out Qty Ordered for each line before they click Cancel or Delete. I'm sure there are several other causes too.

Some questions will live on, long after we are gone. 

Thanks!  That's what I say and they keep asking me why.

Didn't @Thomas Rogers post a comment once that he had verified both PO and SO entry increments/decrements the quantity on order as the entry is being done even though the actual write of the order hasn't occurred yet? For sure ungraceful exit from the task would not back off the quantity, but I think he discovered even cancelling the order didn't correct the quantity on order. 

My answer is it is what it is and that is why Sage gives us the utility to recalculate and you should do it periodically. 

I found one pattern (multiple open PO receipts, against the same PO, corrupted the OnPO number)... but Sage fixed that many years ago, after I reported the details. 

There isn't really a lot of understanding how the numbers get thrown off.  Timing of data entry, deleted transactions, odd transaction patterns... there are many possibilities, but few real answers.

------------------------------
Kevin Moyes
Technical Systems Analyst
Munjal White Consulting Co.
Toronto ON