[BUG]/[DOCS]: Varying behaviour regarding order of returned receipts and transactions

[WheelerCC]

Describe the bug There is inconsistent behaviour regarding the order of receipts returned from getShopReceipts and getShopReceiptTransactionsByShop. Neither endpoint's documentation seems to state how the results returned should be ordered. getShopReceipts sorts the receipts in order of creation_date, and getShopReceiptTransactionsByShop sorts the transactions in order of transaction_id. I don't think this makes sense from an end user's perspective, and if it is an intentional discrepancy it should be included in the docs. Some other endpoints include the ability to change how the returned results are sorted, which could be valuable here. At the moment, getShopReceiptTransactionsByShop being sorted by transaction number instead results in a really close to create_date ordered list, but not quite. It just makes it quite bizarre to use. I'm not sure of a use-case where it's advantageous to have it sorted by a slightly random transaction_id instead of creation date.

To Reproduce

1. Call getShopReceipts endpoint (https://openapi.etsy.com/v3/application/shops/{shop_id}/receipts)
2. Call getShopReceiptTransactionsByShop endpoint (https://openapi.etsy.com/v3/application/shops/{shop_id}/transactions)
3. Compare the order of the retrieved results

Expected behavior I would expect the behaviour of getShopReceiptTransactionsByShop to match that of getShopReceipts, with the results returned in order of creation_date. Sorting by transaction number doesn't have any apparent benefit.

Screenshots See below the results of the first 20 receipts and transactions retrieved, i=0 being the first for both endpoints.

[chrisrogala]

@etsyachristensen is there any update on this? @WheelerCC says the getShopReceipts sorts on created_timestamp but I am not seeing this. I have the following query parameters in my request:

/receipts?was_paid=true&limit=100&offset=5700&min_last_modified=1639446775

last_modified: Tuesday, December 14, 2021 1:52:55 AM

There are 5709 records so this should be near the end of the record set. However, in the 10 records returned, I get the following results:

1. 1637161848: Wednesday, November 17, 2021 3:10:48 PM
2. 1636999003: Monday, November 15, 2021 5:56:43 PM
3. 1636758467: Friday, November 12, 2021 11:07:47 PM
4. 1636758467: Friday, November 12, 2021 11:07:47 PM
5. 1636699864: Friday, November 12, 2021 6:51:04 AM
6. 1636667019: Thursday, November 11, 2021 9:43:39 PM
7. 1636658409: Thursday, November 11, 2021 7:20:09 PM
8. 1635356329: Wednesday, October 27, 2021 5:38:49 PM
9. 1618285143: Tuesday, April 13, 2021 3:39:03 AM
10. 1612841978: Tuesday, February 9, 2021 3:39:38 AM

At first glance, one would think this is in order, but there are thousands of receipts between line 1 and line 10 in this result. As mentioned above, the documentation does not provide guidance on how these records are sorted. The worst part about this is that I am not sure the query parameter is even working. It does not appear to be returning receipt when working through the pages so I have a strong suspicion that the query parameters in this endpoint are invalid.

[etsyachristensen]

The endpoint is not at this time set to sort in any particular order. We will add this to our list things to address.

[chrisrogala]

@etsyachristensen Is there a time table on this? The only reason I ask is because this bug was reported over a year ago. Thanks!

[etsyachristensen]

We have now added sort_on (updated, created, receipt_id) as sort field options and sort_order (asc, desc) for sort direction for the getShopReceipts endpoint.

[chrisrogala]

@etsyachristensen Thank you! I'll working on integrating this into our application this weekend! Also, is there any way you can look into https://github.com/etsy/open-api/issues/604

There are several open issues with the same request. https://github.com/etsy/open-api/issues?q=is%3Aissue+cancelled

It really does cause a lot of pain since we have to traverse all the open orders to locate the current status since they do not get returned in the getShopReceipts. Within a month, we will probably have 1000+ open orders and this means we have to make 1000 calls to determine if any are cancelled. The issue was originally mentioned back in 7/22/2021.