Context
We are creating sales order in F&O from Commerce (we have a custom website that calls Commerce using the CSU OData APIs).
Here's the flow:
- Create and checkout a Cart in Commerce using the CSU OData APIs
- A batch job /P-0001/ creates a retail transaction from the Commerce cart
- A batch job RetailSyncOrdersSchedulerJob then create a sales order in F&O from the retail transaction.
Sometimes, the RetailSyncOrdersScheduler job cannot create a sales order because of rules in F&O that prevents it. For example: /Product ABC123 is on hold/.
The retail transaction status is now /Failed/. This is fine for us, we can detect the error and send an email to our internal staff to handle the order manually (create a new one without product ABC123, call the customer, etc).
The real problem here is that the job RetailSyncOrdersSchedulerJob continues to try over and over again to create a sales order from that RT (see the /retry count/ on the screenshot). So, if a week later, product ABC123 is no more on hold, the sales order will be created in F&O. But we don't want this, because we already handled this.
Workaround
For now, I found a quick & dirty workaround.
I have a program listening the RT created in data entity
RetailTransactionsAuditable and detects the new ones with status /Failed/. When a new one is detected, I set its status to /Editing/ to prevent the batch job to retry it as it's mentioned
here
in the Pending order status field, enter Editing, and then publish the change. In this way, you prevent the Synchronize order job that is running in batch mode from skipping this record during processing
OData request:
PATCH /data/RetailTransactionsAuditable(dataAreaId = 'foo', OperatingUnitNumber = 'bar', StoreNumber = '', RegisterNumber = '', TransactionId = 'baz')?cross-company=true{ /AsynchronousOrderStatus/: /Editing/}
But it's a dirty solution. And sometimes it doesn't work because a job can run and retry the RT before this update request is done.
Question
So my question is: is there a way to tell the RetailSyncOrdersSchedulerJob batch job to not retry /Failed/ retail transactions?
I guess some X++ code inheriting the default job might work but we try to avoid writing custom code in the ERP.
