We uncommitted Inventory from a sales order, and t...
# general
a
We uncommitted Inventory from a sales order, and that inventory got automatically reallocated to a different order. How can I determine which order it got reallocated to?
a
you can visit the reallocate items page, it should show you where it is committed
a
Yes, but I am still having issues determining which one received the allocation. For example, 100 orders are displayed and we have 80 committed. If I uncommitted one order and the inventory gets reallocated to another. It doesn't show me which new order it got reallocated to.
t
I feel your pain but I don't know if there is a better solution than what @al3xicon said.
a
The line level history on the order probably shows the change in the committed quantity, but I don't believe you can report on that like you can with system notes at the header level. There's no direct link between orders when committed stock from one is reallocated to another.
βœ… 1
a
@al3xicon That is what I was afraid of; I appreciate your input. Thank you!
s
Had a similar issue and created a new line field of β€œLast Committed Quantity” and use a scheduled WF to set it when it does not equal quantity committed. You could then use system notes to see what SO lines recorded a change. However there would be a delay of up to 30 minutes before you would see it.
a
Was sort of thinking about something like this, wonder if a UE script would fire when the committed qty changes, but doubt it
s
No it doesn't
d
πŸ‘‹ hey, guess what I've gone and done
here's the results of two reallocation events:
a
Nice!
d
criteria is just
Type is Sales Order
and
Line System Notes : Field is Committed
summary criteria is just
COUNT Internal ID greater than/equal to 2
edit see below, one more summary criteria to add See screenshots of results, snippet of formula to follow
s
How dod you do it?
a
I'll have to remember linesystemnotes, sweet
s
Cool
d
formula:
if any of you are PL/SQL experts, please have a look at my question on #suiteql about cleaning up these formula:
almost forgot, you have to add this summary criteria, otherwise you'll get false-positives (see screenshot) for transactions that increase inventory:
Copy code
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Summary Type β”‚       Field       β”‚ Description β”‚                                            Formula                                            β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚     SUM      β”‚ Formula (Numeric) β”‚     is 0    β”‚ TO_NUMBER(NVL({linesystemnotes.newvalue}, 0)) - TO_NUMBER(NVL({linesystemnotes.oldvalue}, 0)) β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
a
Right that makes sense. Thanks again..I took a look at the SuiteQL post but it is beyond me unfortunately
πŸ‘ 1
d
one thing you may need to account for is particularly big reallocation events that produce line system notes in two different minutes. I don't know how to fix this, as you could round the
{linesystemnotes.date}
to the nearest 10s/minute/whatever, but you'd still get cases that straddle that rounding border