Transaction Archiving
In this article
Overview
Transaction Archiving in LS Central is a feature that offers a few options aimed to keep the transaction-related tables lean.
It offers two complementary tiers of archiving:
- Move older transactions from primary transaction tables to archive tables (inside the LS Central / Business Central database).
- Move archived transactions to external storage - a container in an Azure Storage Account where each transaction is saved as a JSON file.
Why archive transactions?
- Move older transactions from primary transaction tables to archived tables (inside the LS Central / Business Central database).
LS Central allows posted transaction records to be moved to archived tables. This reduces the load on the primary transactional tables and optimize overall system performance.
Key benefits:
- Improved performance - With fewer records in the primary transaction related tables, searches, calculations, and operational processes run faster.
- Reduced database size - Archive tables carry fewer indexes and therefore after moving records to these tables, it occupies significantly less space than in the main transactional tables.
- Move archived transactions to external storage
LS Central also allows archived transaction records to be exported from the archive tables and stored externally in an Azure Storage Account, where each transaction is saved as a JSON file inside a container.
Key benefits:
- Substantial database size reduction — Once exported, the records can be removed from the archive tables, significantly reducing the overall size of the LS Central / Business Central database.
- Lower storage costs — Storing data in Azure Storage is considerably cheaper than purchasing additional Business Central database capacity, making long‑term retention more cost‑efficient.
Archiving flow
- When a transaction is posted it is stored in the primary transaction tables (LSC Transaction Header and related tables such as LSC Trans. Sales Entry, LSC Trans. Payment Entry, etc.).
- A scheduler job runs periodically and moves transactions older than the configured retention period from the primary tables → archive tables (still inside the LS Central database).
- A second scheduler job runs periodically and moves transactions older than a separate retention period from the archive tables → external Azure Storage container.
Both retention thresholds are configured in Retail Setup:
| Threshold | Meaning |
|---|---|
| Days Before Trans. Archive | Days a transaction stays in the primary tables before it becomes eligible to move to the archive tables. |
| Days Before Archive Transaction External | Days a transaction stays in the archive tables before it becomes eligible to be exported to Azure Storage. |
Flow of retrieving archived transactions
If an archived transaction requires refund or exchange, the behaviour depends on whether the POS is online or offline to Head Office:
- POS online to Head Office. The POS calls the GetTransactionV2 web service. If the original transaction has been archived (internally or externally), the service restores it back to the primary tables at HO before returning it to the POS - the cashier sees no difference.
- POS offline to Head Office. When the POS later reconciles with HO, the archived transaction is restored automatically as part of the GetTransactionV2 flow. No manual intervention is required at the POS.
If an archived transaction requires refund or exchange, there are two scenarios:
- If the POS is online to HO it needs to be first be imported back to the Head Office database from external storage to the Archived Transaction table and restored to the Transactional tables. This is a two-step process that needs to be done manually (more details on this process in step 1.2 and 2.2 below)
- If you are running the POS offline to the Head Office the process uses GetTransactionV2 web service to retrieve the transaction automatically from external storage. The POS calls the web service to retrieve the original transaction from Head Office. If the transaction has been externally archived, it is first imported and restored in Head Office, after which the web service returns the original transaction.
Manual retrieval is also available for administrators who need to bring archived transactions back outside the refund/exchange flow - for example for audit, reporting, or correction work. See Restoring transactions in the step-by-step guide for both internal-archive and external-archive procedures.
Running the archiving processes
Both archiving processes are normally driven by Scheduler Jobs that run on the schedule the administrator configures. Either process can also be triggered manually for testing:
- The internal archive process is also exposed as the Archive Transactions report, available under LS Central → BackOffice → Store Management → End of Day → Archive Transactions.
- The external export process is triggered manually by running the configured scheduler job on demand.