PaymentsByDay unexpected behavior on offset change with spanning store payments between offsets
So I have been running some reports for Journal entries for my accounting system and found that Lightspeed API is not consistently returning data correctly when the offset is changed to the next page. I see this in the paymentsbyday endpoint. Example: My stores have 7 payment methods and I have 20 stores and I'm pulling data for the day (or month), but because of 100 limit factor, all the data will have to be returned in multiple requests. In the first request (offset=0) only 4 of the payments methods are listed before the limit is reached, so I record the 4 received, then I retrieve the next 100, expecting the first 3 records of the second request to make up the total of 7 (4 from first offset, 3 from second offset). What I consistently see is that I do receive the 7 payment methods, but one of them is always a duplicate of the previous page, so I loose a payment record on every offset change when a store's payment methods span two requests.
Like many of us, we know how to deal with poorly planned frameworks and unacceptable defects but I give financial reporting errors a much higher rant level since it should have been tested six ways from Sunday for the sake of system integrity.
Here is a work around: As you are going through your first dataset, throw away the last store results and set the offset accordingly to where that store started from the default limit of 100. So in the above example, my second dataset result would start at offset = 96 instead of the customary 100.