I’m new to REST/API integrations in general so forgive me for being naive and lacking on some details.
For context: we generate sales orders in Kinetic using a MuleSoft integration. Previously it was homegrown but two weeks ago we launched the MuleSoft version.
The issue I’m finding is this:
An order is placed for a customer who has a credit limit of $1.
The customer is not on credit hold and has no previous order history.
Our integration creates the sales order by making POST calls against the Erp.BO.SalesOrderSvc.SalesOrders endpoint (to create the order header), then the Erp.BO.SalesOrderSvc.OrderDtls endpoint to create the order lines.
At no point is the credit hold triggered. The order is created without any holds.
In using the REST Help Page, I’ve tried to mimic a POST call to the OrderDtls endpoint and it returns a 201 - line created message, implying that it didn’t encounter any issues with a credit limit?
If anyone has any experience around this I would be very grateful for the insight.
Try using the custom methods of the api, my best guess is that MasterUpdate will perform the credit checks while the regular Update/UpdateExt will not, which is what the OData endpoints use.
I suggest you create the order manually in the browser and take a look at the network calls, then replicate that in your integration.
A lot of data integrity is managed client-side. One of the various outcomes of this approach is that DMT, REST, and CMD are clients too, but tend to get overlooked when data integrity controls get hashed out in the user client. It’s always something to be aware of. Critical financial data tends to have a lot more server-side data integrity management, but don’t bet on it. Jobs and part revisions are pretty hackable, you can (conveniently?) do all kinds of things to closed jobs and locked-down revisions.
Security (menus, groups, and users) is oddly wide open. Proceed with extreme caution here.
Like John says, it shouldn’t be. Even before REST when we wrote C# programs against the Business Objects, we had the same issue.
It is called Menu Security after all. Process Security, Field Security, and BPMs can all be used to validate data.
There are some who don’t access the REST calls directly and instead do the Epicor work in Epicor Functions and then call those via REST. It simplifies the interface and reduces the number of calls made on the wire. More advanced usage, one can write a backend for front end (BFF) which creates an API with better security over client-side API-KEYs.
This has been an exciting (read: stressful) exercise but we’re finally looking at a solution.
The problem resides in the body of the POST request being made to BO.SalesOrderSvc.OrderDtls (using the OData calls). We missed mapping the field “UnitPrice” and this is resulting in the request payload containing “UnitPrice”: 0.
Other price fields are mapped correctly, like DocUnitPrice, and therefore we didn’t see any problem with the sales order when looking in Kinetic. I’m assuming credit limits are calculating the UnitPrice field because once we populated that value correctly, the order (and customer) went on credit hold.
Thanks again for everyone’s input, I’ve learned a lot over the last 48 hours!