Set a value for the whole Dataset

[Jrhodes1234 (John R)]

I am trying to help us get by until we are ready to turn on automated fulfillment. We would like to simplify the process and remove some clicks from the process. When you go to allocate lots/PCIDs, we want to automatically fill in the PartAllocLot.NewAllocatedQty with the PartAllocLot.AvailableQty. When I do a row update, it only fills in the first row. When I do a dataview-condition tied to multiple rows, I do an update, but it still only updates the first row.

Yes, I deleted my last post because I found the widget I thought I was looking for.

[dcamlin (David Camlin)]

Can you share your dataview-condition set up?

[GabeFranco (Gabriel Franco)]

The way the dataview-condition is set up there will only do one iteration,
if you want to iterate, you need to set up a separate event, and put it in the dataview-condition as an iterative event.

[Jrhodes1234 (John R)]

[Jrhodes1234 (John R)]

Like this or should I be changing the trigger?

[dcamlin (David Camlin)]

Nope, that should work. You dataview-condition is acting as the trigger. It will then do that row update for each row that matches the expression in your dataview-condition.

[Jrhodes1234 (John R)]

It runs gives me a generic error and then opens the screen and provides me with the same results. The first row is the only row that updates.

[dcamlin (David Camlin)]

What is your row-update? Are you updating AvailableQty.NewAllocatedQty?

[Jrhodes1234 (John R)]

Gonna feel stupid when the row update has been off this whole time

[dcamlin (David Camlin)]

@dcamlin

AvailableQty.NewAllocatedQty

change the Ep Binding to this: AvailableQty.NewAllocatedQty

[Jrhodes1234 (John R)]

@dcamlin

AvailableQty.NewAllocatedQty

Now i have to figure out why some of these are getting an error.

Edit:
Even weirder…

[GabeFranco (Gabriel Franco)]

For each row, is the goal to copy from that row to same row?
If so, target AvailableQty dataview in both Ep Binding and Expression.
Also, do not enclose expression in single quotes, as it is numeric.

[dcamlin (David Camlin)]

Oh change the value expression in your row update also: AvailableQty.AvailableQty

@GabeFranco beat me to it

[Jrhodes1234 (John R)]

Forgive me, It is already 230 pm and I haven’t had lunch so my brain is moving a little slow.

So inside of FulFillment Workbench on the Allocation By Lot / Bin slideout panel I want to default the PartAllocLot.NewAllocatedQty in the grid to PartAllocLot.AvailableQty value.

Which I think is this grid, based on my digging and testing.

[dcamlin (David Camlin)]

DataView-Conditions are kinda multi-purpose tools. I’ll try to summarize (sorry if it is long winded)…

Use Case One…
Evaluate my dataview and find records (rows) which match my expression/criteria. You can then create branches off of that and perform different actions based on the number of matches.

So, if I have a dataview (set of rows) that I want to evaluate, I can then set up options on what to do next.

OnNoMatch: Take a Nap
OnSingleMatch: Grab the fire extinguisher
OnMultipleMatch: Call the Paw Patrol!

In these “branch” cases… I’m not impacting the results… I’m just taking action based on the number of results (hopefully that makes sense).

Use Case Two…
The Iterative event is used when you want to do actions against each row that is put into the result dataset. So, for each row that meets the criteria, perform “this event”.

Here’s a rough explanation of the parameters:

The key thing to keep in mind is that Epicor is not “duplicating” data… your “AvailableQty” (result) dataview is NOT a separate dataset. Its a “window” into the PartAllocLot dataview. It references the same rows in the source dataview.

The iterative event iterates over the result dataview… not the source dataview.

This is why, in your iterative event, when you used PartAllocLot in your bindings, it only referenced the last active row in that dataview. So, all updates were applied using the same value.

By switching your iterative event row-update to reference the AvailableQty view, it then does your row-updates row-by-row, grabbing updated values from AvailableQty.AvailableQty and pushing them to AvailableQty.NewAllocatedQty.

But again, the changes done to this view are ACTUALLY being applied to the source dataview (PartAllocLot).

~*~
Anyway… When you use a dataview-condition, you can do branching… an iterative event against the matching rows… or both.

[Jrhodes1234 (John R)]

This was an amazing explanation, thank you very much. Okay, so by updating the AvailableQty.NewAllocatedQty will still, in fact, update the PartAllocLot.NewAllocatedQty that is used in the grid.

I am now getting no matching rows LOL

[dcamlin (David Camlin)]

The expression in your dataview condition DOES need to reference the PartAllocLot dataview… that’s the dataview you’re evaluating.

Everything else looks good (at first glance).

This was correct:

[Jrhodes1234 (John R)]

I feel like I am so close, but I might need to walk away for a bit.

I decided to Error message test like i use to in BPMs and old event code.

Is there a reason why both of those tables would not be matching?

Should I be looking at ONHand qty instead?
A bit of a backstory on why we are trying to do this manual process instead of auto fulfillment is because we cannot fully trust our inventory and some of our 3rd party connectors are not ready yet. With that being said in a perfect world auto fulfillment would be turned on with FIFO. We are fixing the inventory as we speak but the first party connectors will not be done till Feb.

[dcamlin (David Camlin)]

Well, my experience with the fulfillment WB is minimal, so how it actually works is still a mystery to me. I may not be too much help on that side of things.

[Jrhodes1234 (John R)]

Found a different solution…