---
title: "Queue Processing System"
space: "Kenya Compliance via Slade360 Advantage"
url: "https://docs.navari.co.ke/kenya-compliance-via-slade360-advantage/processing-reporting/queue-processing-system"
updated: "2026-06-12"
---

The eTIMS Queue Processing System is responsible for managing how transactions are submitted from ERPNext to KRA eTIMS through Slade360 Advantage. It ensures that all submissions are processed in a controlled, sequential, and reliable manner without blocking ERPNext user workflows or overloading external APIs.

![](/files/queue.mp4)



## How the Queue Works

When a transaction becomes eligible for eTIMS submission, it is not sent immediately. Instead, it is placed into a managed processing queue.

The queue operates as follows:

- Each eligible transaction is added as a queue entry
- A background worker processes transactions **one at a time**
- Each request must complete (success or failure) before the next one begins
- This ensures controlled API usage and prevents system overload

This sequential processing guarantees stability when handling high transaction volumes and reduces the risk of API throttling or submission failures.

## Daily Transaction Sync

To ensure full accuracy between ERPNext and eTIMS, the system performs a **daily background synchronization**.

During this process:

- All relevant transactions are fetched and reviewed
- Missing or unprocessed entries are identified
- The eTIMS Ledger is updated to reflect the latest state
- Any discrepancies between ERPNext and eTIMS are flagged for correction

This ensures that the ledger always reflects a complete and up-to-date view of compliance activity.

## Automatic Retry of Failed Transactions

The queue system includes an automated retry mechanism for failed submissions.

If a transaction fails due to:

- Network issues
- Validation errors
- Temporary API downtime
- Processing delays from Slade or eTIMS

It is automatically re-queued based on the configured retry schedule (hourly or daily).

The retry system ensures:

- Failed transactions are not lost
- No manual intervention is required for temporary issues
- Stable recovery from intermittent system failures