Is there a logic block that will pick an individual sales order line rather than looping through all of the details? Would that be UpdateSalesOrderCommitmentsAndReservations
? I am not seeing that practice in our logic so I want to confirm before proceeding. I currently have a flow that calls OnDemandReleaseSalesOrderLines
which then calls ReleaseSalesOrderLinesBySalesOrderHeader
.
To confirm, are you referencing Releasing Sales Order lines for picking or actually picking the sales lines?
Jumping ahead of a response to Ross above, There is no current LB option within the application to release aka process a single line, from Sales Orders for fulfillment. There are some work arounds that may or may not accomplish your need such as
- Calling UpdateSalesOrderCommitmentsAndReservations as you suggested, passing a single SO Detail or from a loop of your eligible detail lines. With this option, you’ll need to be cognizant of a number of processes. Including impact of transactions and records in separate boundaries, error handling and any messaging you may or may not desire.
- Clearing the Scheduled Pick Date value of lines not desired to move prior to processing the order for fulfillment in your current flow. You will have to manually or programmatically add this value back to process these lines in the future.
- Use the header row action (OnDemandReleaseSalesOrderLines), then subsequently cancel the pick request using the detail row action (CancelPickRequestWrapper) individually OR together (Loop) using multi line select for lines not to be included in fulfillment.
But generally speaking, the Ready to Pick row action or the LB OnDemandReleaseSalesOrderLines (Which is a mimic of using the application row action) from Sales Order will send all eligible lines through to the pick release process or next steps in fulfillment depending on your flow.
There is also a scheduling option or Job Scheduler which will send each individual line which is meets defined eligibility attributes which you could configure to run on any cadence you desire.
Actually picking the lines. For this use the case the lines will already be at open
Okay thanks Aaron that helps! We have a process where we want to automate picking from the PO side when there is a receipt so current functionality with header row actions/job scheduler does not quite work, but will keep this in mind in case we are blocked.
Thank you both! Miss y’all and hope all is well
If I understand correctly, is the goal to Hard Commit, Release for Picking, and Pick when stocking an item receipt? It sounds like there’s a lot of actions you want to result from the PO Receipt. We might need some more information about the exact context and process, but the above is not currently supported with base functionality (for a variety of reasons) and would require extension logic or possibly custom events to design and implement well.
There is a means to picking an individual line if it has already been released, but that conflicts with the statement that the Sales Order Detail is currently Open
.
Yes we have developed the logic for this flow since it is not delivered from NW. I am running into a problem where lines are moving to ready to invoice so looking into individual picking since I think some rapid queuing is happening. I will try using UpdateSalesOrderCommitmentsAndReservations like Aaron recommended to see if that resolves this issue.
I agree with Ross, more information is needed if you continue to run into issues. We do have some new features coming as well which will allow for Automatic Release from Open also. Doesn’t help you currently but we are working to make this process of moving from Open through picking more flexible and streamlined if that informs your development at all. You’re likely running into a double workflow queue or your details are not satisfying the correct workflow decision if you are ending up at the wrong status
Sounds good, I am going to using this logic for now and shall see if it makes a difference. Since LB queueing does not leave any trace in errors and eventing does not work for app monitoring I am in a bit of a tough position to figure out why exactly I am ending up at this state but I think it probably has something to do with picking logic happening for split lines as well as new lines that are getting inserted. I will reach back out if I uncover anything useful for this discussion. Thank you both!! Reservations team forever
What about backordered lines, do y’all recommend I call the same logic (UpdateSalesOrderCommitmentsAndReservations) for that use case (individual line call)?
@ellen.kaufman I would not send Backordered lines (assuming ZERO Quantity To Pick) through this logic. Those lines are typically filtered out in our base product. I think there is potential you run into an unexpected workflow queue but the results would be unknown from our end as we do not make any attempt to release fully backordered lines from that flow.
In other words, a call to that logic should involve a prior call to create commitments for that sales order line and transition it back to the corresponding workflow status (likely Open). After that process is done for newly-received goods, in this case, you can call UpdateSalesOrderCommitmentsAndReservations
to ready the individual line for picking. After that, callingWriteInventoryCommitments
with corresponding picked quantity and a workflow queue will automatically callPickConfirmation
and perform the pick.
Okay I do think I am going to need to implement this flow as Cox is doing a workaround calling DemandOrderRelease and using a boolean to limit the lines being passed through but I don’t think this is the cleanest option. I will attempt what you are reccomending above @ross.blackburn . These are open lines just to be clear, we initially send back order lines through the backorderrelease logic provided.
Good luck! Keep in mind that it’s important to pay attention to transaction boundaries. Grouping multiple Sales Order lines into a single transaction and attempting to Ready To Pick, Pick Release, and Pick will lead to Lock Timeout errors and potential for Deadlocks if the sequence is not carefully determined.
We would recommend processing each Sales Order line in an individual database transaction (and possibly three transactions per line, one for each of Ready To Pick, Pick Release, and Picking) given the amount of background logic that could unintentionally get coupled into a large process.