We are using Epicor 10.2.700 on premise and i have the need to make quantity adjustments to the inventory as part of our integration with our field service management system.
Engineer van stock is held in bins per engineer in a specific engineer and transactions (i.e. stock usage on field service jobs) are captured and sent to an interface to be processed in Epicor via some middleware i’m creating.
Upon looking for a simple OData call to POST an inventory adjustment to the system I cant find one in the REST help page. The closest I can find is the InventoryQtyAdjSvc which only seems to have RPC endpoints rather than OData… Does it really not exist or am I not looking properly?
I’m using an azure logic app to integrate the two systems and not mad keen on the idea of making several calls to process an adjustment, with the latency between the calls and one system being on prem and the logic app running in azure it just seems more likely to go wrong and I need this to be pretty bombproof given the transaction volumes.
Anyone dealt with this before? I’ve never used Epicor Functions before but is this a good use case?
First, I only recommend inventory adjustment for rare cases. To me it means, “We’ve totally lost control of inventory control and the only way out is to adjust it.” If I am intentionally moving inventory, I prefer using the Issue or Return Miscellaneous Material. Yes, the accounting is the same but using them indicates intention.
Second, create Epicor functions to call Business Objects. I watch people here spend DAYS trying to figure out RPC calls. You are right to try to encapsulate the work into one call and Epicor Functions allows you to do just that.
Thanks Mark - I hadnt thought of Misc issue/return. On reading your reply i rushed to the REST help hoping there might be a nice single POST endpoint for me to hit, but it looks like the same deal as adjQty.
I take the point on QtyAdj vs Misc Issue but since i’ve just finished the function i need im going to hand wave that away by saying that using my specific reason codes for fitted on a service job is good enough
Sure, I am not dogmatic about it. It’s more of a mindset. For automation, you have it under control. Both transactions look the same in PartTran and Reason code is one of the few ways to see the difference.
I just think that there should be very, very few people who have access to Adjust Quantity UI command.
But the nice thing about functions is that you can do extra checking if you want to and keep that logic out of your client. When using rest, I try to limit myself to functions and BAQSvc only and call them from my own API. If you’re using V2 REST, this makes it possible to hide the API-KEY from your client too.
I know, I know. It’s extra work but as Jose says, convenience <> security.
