Skip to main content

Customer upgraded from 2019 recently and the highlighted item below “Update IN – Confirmed not billable” is what he used to select when processing sales orders that did not need to be billed (such as when you send out a sample shipment to a customer). 


Does anyone know if this has been replaced or why this is no longer there?  Is there another way to have these items selected when processing shipments?

I confirmed it’s in 2020R1, not in 2020R2. Nothing in the initial release notes for 2020R2.
D100 training references it 2020R1 as well, and not in 2020R2. 

Oddly enough, the documentation still mentions the action: “Update IN - Confirm Not Billable: To generate inventory documents for shipments made for transfer orders and returns with replacements.”

Thx!

-Chad

» Screenshot from 2020R1

 

Pretty sure that is a customization, if you just did an upgrade you may just need to republish it. It’s also possible that the customization broke during the upgrade in which case you would need to have a developer update it to be compatible.

If you are automating it, you can apply filters based on the shipment fields available to only update inventory for specific shipments.

It’s the D100 training for 2020R1, and it’s in the documentation…

 

I’m hoping to understand why it’s not there anymore, before I go build some filters and workflow actions...

@clancour 

Since 2020R2 version, automation steps are deprecated and replaced with Automation Workflow

Unlike Automation steps (which distinguished Confirmed state of the Issue shipments and Confirmed Not Billable state of Transfer shipments), the automation workflow uses the single Confirmed state and the single Update In action.

Does this merge of action pose any real problem?

Hey MarkV-

Thanks for the insight as to how it behaved in the past.

Now that I understand the why, I will discuss with the client. They currently have biz process around Updating IN for TR’s and RR’s separately from the rest.

Reminder to let the doc team know about the discrepancy.

Thank You,
Chad

 @clancour , I do not see any discrepancy or missing functionality here. The merge of two  Update In actions into a single one does not seem to take away any  existing functionality and was a part of a switch to a new Automation Workflow engine. This new engine is extensively documented. You can start with the 

 https://community.acumatica.com/maintenance-and-troubleshooting-15/how-to-set-up-a-new-workflow-4817  and follow up links to help articles and release notes

Regarding the current problem - I believe, the customer wants to run the Update In action automatically only for shipments for TR and RR order types (non-billable). If this is the case, this can be as easily achieved by the customization of the workflow as it was done previously with automation steps:

  1. Create  a new workflow for the SO302000 screen based on the Default. (https://uploads-us-west-2.insided.com/acumatica-en/attachment/de7db25f-3a81-4b1d-8519-ea552e7fe338.png)
  2. In the new workflow, navigate to the COnfirmed state
  3. OPen the Actions tab and find the Update In action
  4. In the Auto-Run action column, specify the isNotBillable condition (which is the same condition that was previously used for the distinction between ‘regular’ and ‘non-billable’ shipments in automation steps )
  5. Activate the new workflow

(see https://uploads-us-west-2.insided.com/acumatica-en/attachment/8e595d9e-9a66-4cff-bbb7-2a118938ae18.png for steps 2-4)

Also, you can find the 

 post where this behavior was achieved without the workflow customization (actually, overwriting the workflow). But this does not add to transparency of system settings, and I would not recommend using this approach

“Regarding the current problem - I believe, the customer wants to run the Update In action automatically only for shipments for TR and RR order types (non-billable).”

  1. In the new workflow, navigate to the COnfirmed state
  2. OPen the Actions tab and find the Update In action
  3. In the Auto-Run action column, specify the isNotBillable condition (which is the same condition that was previously used for the distinction between ‘regular’ and ‘non-billable’ shipments in automation steps 

@mvolshteyn 

Perfect, Thank you for that solution. 

 

Reply


Terms & ConditionsCookie settings