I am attempting to use the Epicor REST API’s to add materials to a job.
So far, I am able to add material to a job by using the Epicor Rest API method Erp.BO.JobEntrySvc/JobMtls (POST) endpoint with the following parameters:
export interface AddJobMaterialParams {
Company: string;
JobNum: string;
AssemblySeq: number; // 1
PartNum: string;
RequiredQty: string;
Description: string;
RowMod: string; // "U"
// SchedGrpId - schedule group date determines Related Operations (week) the part is needed by
SchedGrpID_c: string;
SchedGrpDesc_c: string;
// Related Operation set to 1 as default, should change later based on SchedGrpID
RelatedOperation: string;
IUM: string;
}
However, I notice that new parts that are added to the Job’s material list do show up on the PO suggestions.
Moreover, the Related Operation for any new part addition is always 1. This is expected when the part/material is first added to the job, as I believe we have some background automations which should update the Related Operation by checking the date of the Schedule Group (schedGrpID) assigned to the part/material line item and changing the Relation Operation to whatever week that Schedule Group falls into.
Additionally, I tried adding a part to the material list; this time adding a part number that already exists in the material list (with a Relation Operation of week 12), using the same Schedule Group. However, after running PO suggestions, the part remains linked to Related Operation 1 and does not show up in PO suggestions, despite the original part/material line showing up in PO suggestions for the correct date falling Week 12.
I am unsure what is causing the issue, but I think it could be something to do with one or more of the following:
Missing parameters when calling the POST endpoint in the REST API.
One of our automations is not working or requires additional (missing) parameters.
There is no Parent QTY for the part, despite there being a RequiredQty. I am unsure if this matters in regard to generating PO suggestions.
Epicor Pilot - possible some nuances and differences here
The REST API is limited in documentation, so I would really appreciate some guidance here. Please let me know if there is any more information I can provide to help.
I’m going to offer what I usually do for all the struggles you’re having.
Create the logic to add the material in an Epicor Function. Don’t put Epicor Business Object calling syntax in your local client. This decouples your client’s logic from Epicor. With a Function, you have full control of the calling signature, you’re going to make fewer calls with smaller payloads over the wire, and it will make your client more resilient to Kinetic upgrades.
You still need to know the calling sequence and there are a couple of trace utilities here on the list that can help you. ALWAYS do a trace. If there is documentation, it would be out of date anyway. You can’t go wrong using the same steps that Epicor uses.
Can you define/provide references to Epicor Functions? Would this be the same as a uBAQ? I built a uBAQ for adding materials to a job but was later advised to use Epicor’s built in Erp.BO.JobEntrySvc/JobMtls method instead.
Regarding trace utilities - where can I find these utils, and do you have any references on how they are used?
Regarding the following statement,
Don’t put Epicor Business Object calling syntax in your local client
I am unsure if you mean that I should either…
Not use REST API call from the client (front-end) of an App.
If I can still call the REST API from an app, as long as the function is running on the server (not client).
I should not be using REST API at all for this kind of process.
Background: I built an (React) app to allow users to make BOM change requests for specific jobs. The next step is automating the processing of the requests in Epicor (e.g. Open Job Entry, Open Material list, manually enter new material line and part, etc.). The REST API endpoint and function lives on the server but is invoked from the client side using a “Process in Epicor” button which calls my POST endpoint.
I am still learning Epicor, its nuances, and how to properly take advantage of the built in tools and understanding when custom solutions should be used.
Thank you again for your advice and feedback on this.
UBAQs are what we used before functions, and they still have their place for certain scenarios like Dashboards with mass update. Epicor Functions are C# code that can be exposed via REST. The Kinetic browser uses REST to communicate with the server, and we want to do the same.
So, as a React programmer, would you like to define the API that you’re calling or do you like to figure out what the hell some programmer you’ll never meet was thinking?
IMHO, always use REST, and define your own API via functions. There are lots of examples here to help.
EDIT: If you are at 10.1.600, you won’t have functions.
Assuming I do not have access to functions (e.g. v10.1.600), would you then recommend using a custom uBAQ or the ERP.BO via REST — or maybe even neither?
I’d also like to clarify that I am able to successfully add materials to a job via /JobMtls (POST 200); the issue is that the parts do not show on PO suggestions, and I thought that this couldpossibly be related to how I am adding parts via the REST API — e.g. maybe calling the endpoint without the VendorNum parameter returns as a (200) success because the VendorNum parameter is optional, but the background process for PO suggestions may require that the VendorNum exist on the material line for the part to be included in the PO Suggestions.
That said, I think I need to do additional research now that I have more information. The resources and feedback you provided should serve as a solid foundation for debugging, thank you.
Right. The best way to know how to automate is to do it manually and see what is passed back and forth using the trace. You’re just trying to look like the Kinetic browser to the server. There is a REST endpoint for BAQs, so you might be able to do the UBAQ route as well.
If I had to call a BO via REST, I will use the RPC (non-OData) version since it is one less layer of abstraction and closer to what I would do in a Function.
