Hi.

I’ve tried this configuration and I’m afraid the behavior you want to achieve is not possible. I created the custom field “External Code” and it is possible to update it before status “Invoiced/Closed”. Example below:

But if I try to update “External Code” in status “Invoiced/Closed” I get an error:

The entity CustomerOrder probably has a validation that prevents updates on any attributes when the state is “Invoiced/Closed”.

Here is what the debug console shows:

Payload:

Even if you handle this with some kind of Command in the form that invokes a Workflow:

https://docs.ifs.com/techdocs/23r1/040_tailoring/225_configuration/200_client_configurations/300_commands/#adding_an_executeworkflow_type_command

you will have to use a Projection Delegate action to update the CustomerOrder which will fail in the same way as the form does because in reality you are using the same endpoint to PATCH the resource.

I think the only way to go here is to make a small development that will disable this validation for all custom fields. The section you would want to modify is the one below:

You could include in the exception fields all attributes that start by “CF$_”.

I made a small a quick/dirty change to exclude from validation the field CF$_EXTERNAL_CODE….

tested again the update and this time it worked perfectly:

Unless someone comes with a better alternative, I think you may go this way. The modification is not too invasive on core code and should not be a problem to stay Evergreen (apply SU and RU frequently).

Regards.

Gonzalo.

Hello Gonzalo,

I read your conversation and I have same case in my site,

Is this way safe and does not cause any issue in another page or in another step?

Thanks.

and what you mean here?

apply SU and RU frequently

thanks.

Hi Norahmf.

The modification proposed is very small and doesn’t harm any other page or functionality. You simply modify a section of the LU code to prevent raising an error when CF$_XXXXX fields are modified and there are invoiced lines.

This modification should be done using the LAA partial overtake concept trying to minimize the impact on the core functionality. That way, applying a Service Update (SU) or Release Update (RU) will be simple and can be done frequently to stay Evergreen.

Best regards.
Gonzalo. 

 

Hello Gonzalo ,

thanks for answer.

This modification should be done using the LAA partial overtake concept trying to minimize the impact on the core functionality. That way, applying a Service Update (SU) or Release Update (RU) will be simple and can be done frequently to stay Evergreen.

My plan now is update Order_Customer_Api _unpack Procedure for one time by database 

Is that enough?

Hi Norahmf.

Yes, you only need to modify Customer_Order_API.Unpack___ in the section of code that I’ve shown above.

Thank you much.

Best regards.

Gonzalo.

Thanks, I update this Procedure and it is working fine.

Nice work @Gonzalo this is a good solution.  Your response should be marked as best answer - @BHern12 please mark when you have a moment.