Set default value with workflows of type Date

Hi ​@ZFTKMARTELE 

There is a post about how to use dates and timestamps in workflows. You can get an idea from that.
https://oneifs.workplace.com/groups/352666655725801/permalink/1174556653536793/

I have created a sample workflow to set the date as a default value. Hope this helps you.

1. Use script task to set the date

   

2. By using the Process Enrichment task, register the variable.

3. Set the projection action with action type CALL and call name must be default method of the respective entity.
    

4. Result

   

    

pdollk wrote:

Hi ​@ZFTKMARTELE 

There is a post about how to use dates and timestamps in workflows. You can get an idea from that.
https://oneifs.workplace.com/groups/352666655725801/permalink/1174556653536793/

 

I have created a sample workflow to set the date as a default value. Hope this helps you.

1. Use script task to set the date

   

 

2. By using the Process Enrichment task, register the variable.

 

3. Set the projection action with action type CALL and call name must be default method of the respective entity.
    

 

4. Result

   

    

 

Hi,

Thanks for the response and sample.

But I have still receive an error.
See my code and debug values.

Date is correct and filled in

But I still receive error when trying to execute my workflow.
 

Extra screenshots

Hi ​@ZFTKMARTELE ,

I tried with the same workflow I created in the previous example to set the default value for EffectiveDate using IfsApp.MultilevelPromotionHandling.MultilevelPromotionVirtual_Default().
I tested it in one of the master dev environments, and the EffectiveDate was set as expected.

Workflow settings

Projection Action 

Result

OData Response

As I can see in your screenshots after debugging, there are no visible issues.
A few questions:

1. What track are you working on? It might be a track-specific issue, but not sure.

2. If you remove the EffectiveDate, are the other values being set correctly?

3. Have you checked the Network tab in the browser's debug console (Inspect)? Is there any exception logged?

Hi ​@pdollk 

What is RegulatoryBodyHandling because I don’t have that projection in IFS. We are currently on version 23R1SU7 and we will go soon over to 23R1SU23. We are in Belgium can it be something to do with regional settings?

I’m also using 

IfsApp.MultilevelPromotionHandling.MultilevelPromotionVirtual_Default(). I made the projection action again to be sure but same problem

1. What track are you working on? It might be a track-specific issue, but not sure.

   1.  What do you mean with that?

2. If you remove the EffectiveDate, are the other values being set correctly?

   1. It works perfect without the date

3. Have you checked the Network tab in the browser's debug console (Inspect)? Is there any exception logged?

Hi ​@ZFTKMARTELE ,

When I recreated this scenario in the 23R1 central dev environment, I encountered the exact same issue. Then I looked into a defect we had previously fixed related to default calls. There is a similar defect that matches your case, but not 100% sure.

It occurs due to a mismatch in the return type of the object which prevents setting default values for timestamp and date attributes via workflow. If that’s the root cause of your issue, it might also be present in the 23R1SU23 version.

This issue was fixed in 24R1 onwards by setting the expected object type for all attributes before the request reaches the OData layer. I believe this fix could also resolve your issue, but further investigation is needed.

If you don’t have a workaround or alternative solution, you can raise a support ticket.

furthermore,

• Don’t worry about the RegulatoryBodyHandling projection — I used it just for testing.

• This issue is not dependent on regional settings.

• By track, I meant the version. As you said, your current track is 23R1.
   

🙂

Hi, ​@pdollk 

Thanks for the info and the support.
It is not that big problem (just one click more) and I’m happy that the other values are filled in, that saves me more time.

I will park this problem for the moment and will test it again in 24R1, we are starting to prepare everything and do heavy testing in the coming weeks.

Thanks again and have a good day