JobEntrySvc — BuyIt / Purchase Direct cannot be set via API nor Epicor UI?

Epicor ERP 10
, , , ,
1

Greetings,

I am running into a pretty frustrating issue regarding using the REST API custom methods to set “BuyIt = true”.

  1. No matter what I do, and which fields I set in my API calls (dspBuyit, direct, buyIt), refreshing the Epicor UI shows all feilds added properly except the buy it field, which can never be marked true.
  2. I have even tried manually marking said parts to purchase direct via the JobEntry menu and Purchase Direct checkbox; but saving will always uncheck the checkbox and set the BuyIt field to False.
  3. I have seen some post here stating that technically BuyIt does not even exist on JobMtl, despite Epicor telling me it does (e.g. JobMtl.BuyIt); which is very confusing and usure if that is true or not.

I feel like I am missing something, but have spent hours trying to solve this problem. I never had this issue using OData REST API, as buy it would be set automatically without needing to pass the field; and now that I have migrated towards using Custom Methods via the REST API, I am not able to mark a part as purchase direct; even via the Epicor JobEntry UI after the line item is added via the REST API.

What am I missing here? Is JobMtl.buyIt just fake news? Why would OData default it to true, while custom methods default to false?

I do understand that there could be some business logic in the background which stops specific parts from being marked Purchase Direct — but I have tried adding various parts in both the UI and Rest API which I know for a fact can be marked purchase direct (we do it all the time) but are now failing.

Can someone please point me int he right direction?

[Epicor BO] After ChangeJobMtlBuyIt job has 421 operation(s), 1 material line(s)
[Epicor BO] Pre-Update JobMtl row (idx=0, part=12345a): {
  "MtlSeq": 1230,
  "AssemblySeq": 1,
  "PartNum": "12345a",
  "QtyPer": 1,
  "RequiredQty": "1.0",
  "FixedQty": false,
  "BuyIt": true,
  "EnableBuyIt": true,
  "EnablePurDir": false,
  "dspBuyIt": false,
  "Direct": false,
  "PurPoint": "",
  "RelatedOperation": 1,
  "RowMod": "A",
  "IUM": "EA"
}
[Epicor BO] forceBuyItTrue Pre-Update JobMtl row (idx=0, part=12345a): {
  "MtlSeq": 1230,
  "AssemblySeq": 1,
  "PartNum": "12345a",
  "QtyPer": 1,
  "RequiredQty": 1,
  "FixedQty": false,
  "BuyIt": true,
  "EnableBuyIt": true,
  "EnablePurDir": false,
  "dspBuyIt": false,
  "Direct": false,
  "PurPoint": "",
  "RelatedOperation": 1,
  "RowMod": "U",
  "IUM": "EA"
}

I appreciate any and all feedback and advice — thank you.

2

I ran into the same issue before. One of the fields is a fake one that breaks things, the other field is the correct one. I dont remember which though. I had the same issue with it breaking the material on the Job, even using the actual menu screen.

Youll want to delete the material on the job, re-add it manually, then call that with the api to see what fields got set as what and copy that.

If I get the chance today Ill dig around and see if I can find what I used for field settings for it.

3

It looks like “dspBuyIt” is the important one?

Dont quote me on it because I dont have the code for it anymore unfortunately, but looking at the api calls job entry does for it thats all I could find that was different.

As a sidenote, using a json comparer to figure out what is different is a good way to figure out what you need to change.

4

Confirmed — dspBuyIt is the correct field.

I was able to confirm this by running GET JobMtl on a part which already had the Purchase Direct field checked; which showed buyIt as false, but dspBuyIt as true.

The specific solution for us seems to be to send only the dspBuyIt field in the API Payload. Setting both the dspBuyIt and buyIt fields to true in the API payload will result in neither field being set to true.

Note: Epicor Field Help in the Job Entry menu, as well as the column descriptions in the BAQ designer, both show JobMtl.BuyIt as the field to be edited, which is misleading.

Thank you for your help; for the second time in 7 days — Cheers!