REST Api - QuoteSvc - Not consistently return results

I have been working with the QuoteSvc in the REST Api. In my query, I am using the QuoteNum field to return all of the QuoteDtls records of a quote. My issue is that for some quotes, the service returns data and for others it does not.

I have verified there is data on the quotes through the Epicor Thick Client and SSMS. Just curious to know what might cause the service to not return rows each time?

REST call… Erp.BO.QuoteSvc/QuoteDtls?$filter=Company%20eq%20’ABC’%20and%20QuoteNum%20eq%2012345

Epicor version = 10.2.200

Please let me know if more information is needed. Thanks.

Are you using Swagger to test this or Postman? As far as I can tell, the Swagger UI only returns the first 100 recs, so that might be why you’re seeing inconsistent results

My initial test was through a C# app. When I didn’t receive any results, I did test using the Swagger, but get the same results if I use Insomnia (rather than Postman) or a C# app.

try adding $top= or using $top plus $skip to page through the results. We have a default page size baked into the odata methods so that it takes an intentional request to get the full firehose of data back rather than having endpoints where trying it out might return millions of records

So like Erp.BO.QuoteSvc/QuoteDtls?$filter=Company%20eq%20’ABC’%20and%20QuoteNum%20eq%2012345&$top=1000&$skip=1000 would be 1000 records per page, second page for this filter

Added $top to my querystring and received back the expected results. When I added $skip the results were blank again because the query paged past my record.

Just curious to know… wouldn’t having the QuoteNum as filter criteria query only for that record? Or are all the records pulled each time and then filtered?

@bconner Would you be willing to explain a bit more about the default page size in the oData methods? Is there a way to modify that page size? Would I better off using the Custom methods? It looks like those methods return all of the related data.

Thanks for your insights on this.

Just curious to know… wouldn’t having the QuoteNum as filter criteria query only for that record? Or are all the records pulled each time and then filtered?

I feel like maybe i’m missing your point, but it should apply your filter, and then apply the top/skip paging limiting to the results of that filter, yes.

If I don’t have $top=1000 in my querystring, the value attribute is empty in the response.

:expressionless: welp that sounds like a bug to me if that’s what it’s doing. i’ll have someone check this out. you shouldn’t have to guess at result count to get any results.

Do you have an idea of when this fix might be in place? Thanks for your help on this topic.

Sorry i can’t comment on fix timelines until we know if/what the issue is.

Note: Officially speaking the way to get this info from us as we figure it out is with a linked support case so I recommend you drop a support case in and if it turns out to be a bug as it sounds to me then we can link the issue in there.

If you have a ticket number then we can investigate. Please include the sample URLs as you have above and give us the ticket number - or ask your friendly neighborhood support rep who will have same information when it is triaged / a workaround is determined!

When you retrieve data not from parent, but only from child table, odata has to retrieve from parent table as well, to know what records to return in child table. Without explicit where clause, all parent records are retrieved. But as record limit is defined, only first 100 parent records are retrieved and the record you need is not among them. That is why you don’t have the result back.

1 Like

Just wondering how the $top and $skip parameters are working in OData methods.

My understanding is that $top indicates the page size of records to be returned and $skip indicates where to start in the record list.

I have an OData query looking for the 102nd record in the table. When I use $top=200, my record is returned. When I use $top=100&$skip=100, my record is not returned.

Am I not understanding the use of these parameters? Thanks for your insight.

It is used for paging. and it overrides limit you encountered earlier.
what if you use $top=200$skip=100?

I still receive back an empty Value attribute in the response body. It doesn’t seem to matter how I combine the $top and $skip parameters.

{
“odata.metadata”: “https:////api/v1/Erp.BO.QuoteSvc/$metadata#Epicor.RestApi.QuoteDtls”,
“value”: []
}

Strange, you probably need to look how stored procedures are called in sql profiler.

And to make it work in all cases you have to remove limit for the records. Or rewrite your query to get parent record first and then its children records.

I did receive an appSetting to add to the web.config. The appSetting removes the query limit from REST calls. When using the QuoteSvc/QuoteDtls method, I am now receiving back results of queries for records after the 100th position. However, the $top and $skip parameters still don’t seem to work.

The interesting thing I found is I tried using both the UD01Svc and the UD02Svc. When querying for rows, I can get back any row regardless of where it is in the table. Also, the $top and $skip parameters work correctly.

What would cause this discrepancy?

UD01 and UD02 are single tables where the QuoteSvc is retrieving all parent records according to Olga previously in this thread. An alternative to the QuoteSvc is to write a BAQ to return the fields (already linked and filtered) and use the BAQSvc.

Mark W.