I'm having a puzzling experience with Lightspeed Retail (R-Series) and I'd appreciate any insights, especially from those who've worked with retail or POS systems. Here's the situation: I processed a test transaction that resulted in Sale ID 60916 at 15:10. Right after, at 15:11, I issued a refund that created Refund ID 60873. Strangely, the refund received a lower sale ID despite being a later transaction. This seems to violate the idea that sale IDs are usually sequential and assigned in real time, which is crucial for auditing and reconciliation. Lightspeed support claims that sale IDs are globally assigned, but that doesn't make sense in my case since there were no other active registers and the logs show the refund ID was created after the sale ID. This raises concerns about audit trail integrity and financial reconciliation. I'm wondering if anyone else has experienced similar issues with Lightspeed or other POS systems, or if there could be a legitimate explanation for this behavior, like rollback-safe ID pools or potential ID reuse after voided sales. Or is this likely a bug?
2 Answers
It definitely sounds like a database issue. Having IDs assigned like that shouldn't happen if the system is operating correctly.
Good luck with that! I've faced issues with Lightspeed R too. Transactions seemed to come through from random registers, and it took ages for their support to acknowledge the problem. Their logs are pretty sparse as well. We eventually found it was a bug linked to a bigger issue, but getting resolution took almost a full year. Ridiculous!
Wow, that's frustrating! We once had a bug that allowed data to get overwritten between item IDs. Even after it was 'fixed', we still noticed issues. Their support just kept denying it. It's alarming how data integrity seems to falter.