ReceiptSvc.GetPOInfo REST error

I’ve been trying to implement a PO Receive feature in a web application using the Epicor REST api; however, I’ve hit a wall with the first method in the trace log “GetPOInfo”.

I get a “Record Not Available” error every time I call this endpoint, both in my application and the swagger site. I’m developing for 10.2.500, but experience the same error in my 11.1 and 11.2 test environments. I’ve resorted to manually building the default dataset using other api calls but this is a big pain to say the least.

I suspect that it requires a full ReceiptDataset parameter, but based on the swagger documentation the purpose of GetPOInfo() is to generate this defualt dataset. Typically in these situations I just include an empty ds object parameter and things work out, but it’s not working for this method.

Has anyone else had this problem with this particular service?

{
  "HttpStatus": 400,
  "ReasonPhrase": "REST API Exception",
  "ErrorMessage": "Record not available.",
  "ErrorType": "Ice.BLException",
  "ErrorDetails": [
    {
      "Message": "Record not available.",
      "Type": "Error",
      "Table": "RcvHead",
      "Program": "Erp.Services.BO.Receipt.dll",
      "Method": "getRcvHeadRow",
      "ColumnNumber": 17,
      "LineNumber": 4804
    }
  ]
}

Yes, it requires the whole receipt tableset:

image

I would suggest turning on the server trace and do what you want to achieve through the Epicor interface. Then, in your REST call(s), your goal is to call the same methods in the same order as in the trace log. Possibly a custom function would be the best here.

2 Likes

Hi there, thanks for your input. I’ve done all the usual Trace stuff. It’s actually the first method in the trace stack which is why it’s a head scratcher. My app interacts with tons of Epicor BO’s via the REST api and this is the first time I’ve ran into this problem.

As a workaround, I’m just calling the POSvc/POes() method to get what I need. The rest of the methods in ReceiptSvc work as expected.

Hmm, did a quick trace and I can see a few called before GetPOInfo:

GetNewRcvHead
GetAvailTranDocTypes
GetNewRcvHeadWithPONum
GetPOInfo

Dragos

If you can, I’d steer you towards using a BAQ to get the info you need. The BAQSvc endpoint is super helpful and doesn’t require you to call a RPC. Build your BAQ to your specifications and call it, its that easy.

1 Like

Strange my Trace is not in that same order.
image

Hi thanks for the suggestion.The POSvc oData methods are super quick and easy so it works for my needs here. I just need to get some PO-specific fields to plug into the GetByIdChkContainerID() method then I’m off to the races.

I think there is a weird bug or something with the GetPOInfo() when called via REST.
Once I have the PONum,VendorNum,Purpoint, etc I can call the GetByIdChkContainerID() method and it gives me the full ReceiptEntry dataset without any errors. Maybe GetPOInfo() secretly needs the smart client juice to work properly. In any case, it looks like I can get by without it.

It could be, which is why I am suggesting a) if you’re orchestrating a transaction, use an Epicor function and save yourself the headache of replicating a historical fat client transaction on a web app or b) if you’re just retrieving specific data, use a BAQ and again save yourself the headache.
The REST API is a layer built on top of the WCF services. It was not designed with web app transaction ease in mind. However, functions and BAQ services will get you to wherever you want to go and much faster. My 2 cents at least :slight_smile:

2 Likes

Thanks for the helpful suggestions, Aaron. Your advice is very sound; however, I’m personally not a fan of developing with Epicor Functions. I love the idea but the tooling situation always ends up frustrating me to the point of wanting to throw my computer out the window. The more I can stay in VS code the better for my own sanity :melting_face:

I also haven’t been a fan of the BAQ/REST performance issues, but External BAQ’s have made BAQ’s great again.

Fortunately I’ve got a functional workaround in place so crisis averted. Thanks again for taking the time to help out :handshake:

1 Like