Epicor Kinetic Rest-API Issue

I have a process that migrates PO automatically from one system to Epicor using the APIs, however after the recent Kinetic update this process has been halted due to the PO Details, the parts. I did some tests on Postman and the issue was that it wasn’t a valid part even if we use parts on-the-fly. I have to clearify that we use Job Material transaction only.

Postman shows this:

{
"HttpStatus": 400,
"ReasonPhrase": "REST API Exception",
"ErrorMessage": "A valid part is required",
"ErrorType": "Ice.Common.BusinessObjectException",
"ErrorDetails": [
{
"Message": "A valid part is required",
"Type": "Error",
"Table": "PODetail",
"Program": "Epicor.RESTApi.Common.dll",
"Method": "ThrowUpdateExtException",
"LineNumber": 27,
"ColumnNumber": 17
}
]
}

Any help is very welcome.

We have no clue, from your post, what you’re doing technically. We would need to see the business object calls you’re trying to make, maybe the entire integration/custom code block.

My b.

I’m using the endpoint that Epicor provides Erp.BO.POSvc/PODetails, the v1 to be precise. And tne json that im sending it is something like this.

{
	"Company": "",
	"PONUM": 56,
	"POLine": 1,
	"CalcTranType": "PUR-MTL",
	"PartNum": "82_30-1",
	"QtyOption": "Our",
	"CalcOurQty": "1.00000000",
	"CalcVendQty": "1.00000000",
	"IUM": "EA",
	"PUM": "EA",
	"ScrUnitCost": "30.0000",
	"DocScrUnitCost": "30.0000",
	"CostPerCode": "E",
	"LineDesc": "PLATE",
	"CalcJobNum": "82_30",
	"CalcAssemblySeq": 0,
	"CalcJobSeq": 610,
	"CalcJobSeqType": "M"
}

There’s something else that I’m missing?

You’d have to do a trace again of how that works, whatever you’re trying to do.

is PODetails a method?

Using OData vs. RPC, POSvc/PODetails lets you POST to call UpdateExt and create a row:

I’ve never done it that way (didn’t even know you could!) - but I would think there’s been a signature change to this method and you need to adjust what you are sending. Maybe RESTHelp can clue you in. My first thought was maybe you need RowMod=A, but since it’s using UpdateExt, it shouldn’t be that.

As your error is part related, i would check the part master to make sure the part is valid in the company/site that you are working in, and that the part is not marked invalid and exists. following that, check that you might need to supply something for the various part fields in that dataset, maybe something changed to be required.

“PartNum”: “string”,
“VenPartNum”: “string”,
“PartNumChgReq”: “string”,
“MfgPartOpts”: “string”,
“SubPartOpts”: “string”,
“MfgPartNum”: “string”,
“SubPartNum”: “string”,
“SubPartType”: “string”,
“BasePartNum”: “string”,
“CalcMfgPart”: “string”,
“calcPartPUM”: “string”,
“DisablePartRevBtn”: true,
“NonMasterPart”: true,
“PartQtyBearing”: true,
“PartNumTrackInventoryByRevision”: true,
“PartNumPricePerCode”: “string”,
“PartNumSalesUM”: “string”,
“PartNumSellingFactor”: 0,
“PartNumTrackSerialNum”: true,
“PartNumTrackInventoryAttributes”: true,
“PartNumPartDescription”: “string”,
“PartNumIUM”: “string”,
“PartNumTrackDimension”: true,
“PartNumTrackLots”: true,
“PartNumAttrClassID”: “string”,

2 Likes

Thanks Gabe, I was in middle of doing some reports and didn’t have the rest help open, had never seen that method before either. Learn something new every day!

Like @GabeFranco just said, @Lazo you’ll need to see if REst Help gives you anything.

1 Like

I’ve done some tries with “NonMasterPart” and it was a no go, but let me figure which one of those could be the new nuissance into this petitions to add them. I’ll trace it once again since it was working before this update.

Thanks @utaylor and @GabeFranco. I’ll update here once the tests are done!

1 Like

Thanks, yeah keep us updated, you never know who else may be having the same issue and needs help. Your response could be a huge help to them.

This is one of the downsides of using the REST endpoints directly. The client is tightly coupled with the server and when Epicor changes a signature, we have to fix all the clients. The alternative is to create your own API using Epicor Functions and call that API via REST. Abstracting that to a function also allows us to test it independently too. If there is a breaking change on the Epicor side, you just have to fix the one Epicor Function.

4 Likes

We sometimes make changes to UpdateExt to and missing data validations, this could be a new bug.

I’m still on pto but will check once I get back, in the meantime I suggest you contact support, if it’s a very basic scenario with parts on the fly they should be able to replicate and send to development.

3 Likes

Thanks Jonathan, I hope your PTO was enjoyable.

Contact support, the problem is the part is being validated using the default CalcTranType which is PUR-STK.

This is already fixed on 2026.1 so you can request an update of ERPS-301916 mentioning your business case and impact.

@utaylor Thanks :slight_smile:

3 Likes

I also have an integration built for creating PO’s through the REST API using Jitterbit. Prior to executing the POST on /Erp.BO.POSvc/PODetails, I execute the /Erp.BO.PartSvc/PartExists API with a simple JSON of:

{
“PartNumber”: “ABC”
}

Then, based on getting a True or False, I will set the CalcTranType to either PUR-UKN or PUR-STK as we don’t buy directly to Jobs so no need for PUR-MTL.

There was one update to Epicor that broke one of my integrations but I think that may have been within the Engineering Workbench. Since it was related to an upgrade, I immediately assumed it should be in the hands of Epicor Support but I also reported it to Jitterbit Support and after an Engineer looked deeper at the issue, he found a Jitterbit variable that needed to be set to a certain value to get me going again.

One thing I find interesting is that in your JSON, you are sending ScrUnitCost and DocUnitCost to /Erp.BO.POSvc/PODetails which didn’t work for me. I had to follow up with a PATCH to /Erp.BO.POSvc/PODetails(,,) to update those values after the line was created. Is it working for you to send them all in the original POST?

1 Like

First of all, thank you all for your responses.

I started tracing down again the method for this petitions but it was the same outcome with that error message. However I’ll try to see if it starts working with that version you mentioned @Jonathan thanks for the help!

As for your question @gsuderman yes, I send the batch of information including ScrUnitCost and DocUnitCost in the original POST to /Erp.BO.POSvc/PODetails, I also use PATCH but only when I detect that some changes are made to that line that I migrated.

1 Like