Takealot Store Management

This is the installation, operations and accounting guide for Takealot Store Management. It describes the latest release on every Odoo version and says, where it matters, which release a behaviour arrived in.

Technical name	takealot_store_management
Odoo versions	17.0, 18.0, 19.0, 20.0 (Community or Enterprise)
Current shipped version	20.0 → 20.0.2.2.2, 19.0 → 19.0.2.2.3, 18.0 → 18.0.2.2.2, 17.0 → 17.0.2.2.2
Earlier catalogue builds	17.0 → 17.0.2.2.0, 18.0 → 18.0.2.2.0, 19.0 → 19.0.2.1.12 (the Apps Store listing moves to the current version as each release reaches it)
Price	$499 USD — one-time, per Odoo version
Odoo module licence	OPL-1
Category	Connector

The 2.2 releases are self-contained on every Odoo version

17.0.2.2.2, 18.0.2.2.2, 19.0.2.2.3 and 20.0.2.2.2 have no separate ECOSIRE runtime dependency, licence-client module or key check. Install the connector archive itself and the standard Odoo dependencies listed below. Only the older public 19.0.2.1.12 build still needs the ECOSIRE licence client; upgrading to 19.0.2.2.3 removes that need.

Requirements

Requirement	Detail
Odoo	17.0, 18.0, 19.0 or 20.0, Community or Enterprise. Self-hosted or Odoo.sh — Odoo Online (SaaS) cannot install third-party modules
Odoo apps	base, sale_management, stock, account, delivery, mail, web, portal, product, contacts, digest — Odoo installs any that are missing
ECOSIRE dependency	None for the current builds 17.0.2.2.2, 18.0.2.2.2, 19.0.2.2.3 and 20.0.2.2.2 (the older public 19.0.2.1.12 still requires the ECOSIRE licence client)
Python packages	requests
Platform account	A Takealot account with API access

Install the Python packages into the same interpreter that runs Odoo:

sudo -u odoo pip install requests

Installation

1. Obtain the archive for your Odoo version

Use the archive supplied through your purchase or project-delivery channel. Do not install an archive built for a different Odoo major version.

2. Extract into your addons path

unzip takealot_store_management_v19_*.zip -d /opt/odoo/addons/
ls /opt/odoo/addons/takealot_store_management/__manifest__.py   # sanity check

The module must end up as a single top-level takealot_store_management/ directory with __manifest__.py directly inside it. If your ls check fails, the folder landed one level too deep or too shallow — move it so the path above resolves.

3. Restart Odoo and install

sudo systemctl restart odoo

1. Go to Apps and click Update Apps List (developer mode must be on).
2. Search for Takealot Store Management and click Install.
3. Odoo installs the standard Odoo apps listed above automatically.

When the install finishes, a Takealot menu appears in the main Odoo app switcher.

Configuration

Connect to Takealot

Create a connection record on the takealot.instance model. The fields the module defines for the connection are:

Field	Technical name	Type	Required
Instance Name	name	Char	Yes
Seller Account Reference (local label, never sent to Takealot)	shop_url	Char	Yes
Company	company_id	Many2one	Yes
API Key / Client ID	api_key	Char	No
API Password	password	Char	No
Client Secret	shared_secret	Char	No
Access Token	access_token	Char	No

The fields marked Yes are enforced by the model — Odoo will not let you save the record without them. The technical name is the reliable identifier if your screen wording differs.

The same record carries behaviour checkboxes — auto_confirm_order, auto_create_invoice, auto_validate_invoice and auto_register_payment. Deliveries are not validated automatically. They gate what the module is allowed to do automatically once it is connected. Leave anything you are not ready for switched off, and turn them on one at a time.

The module's own source contacts this host: seller-api.takealot.com. Your firewall must allow outbound HTTPS to them.

South African VAT: VAT-inclusive prices (since 2.1.8)

Takealot quotes prices to shoppers with VAT already inside them, while a standard Odoo sales tax treats the price as VAT-exclusive and adds 15% at invoicing — that combination turns an R249 listing into an R286.35 invoice. To invoice at the listing price:

1. Accounting → Configuration → Taxes — open (or duplicate) your 15% sales tax and, on Advanced Options, tick Included in Price.
2. On the connection's Order Workflow tab set Takealot Sales Tax (sale_tax_id) to that tax. The module refuses to save a tax that is not price-included — that is the exact misconfiguration this setting exists to prevent.
3. Optionally set Zero-Rated / Exempt Tax (zero_rated_tax_id) to a 0% sales tax. Products flagged ZA VAT Zero-Rated or ZA VAT Exempt on the product form's Takealot tab (basic foodstuffs, exports) then take that tax on import instead.

A product whose ZA VAT 15% Inclusive flag is unticked declares its price VAT-exclusive and keeps its own Customer Taxes. Leave Takealot Sales Tax empty and the importer changes nothing — every product's own Customer Taxes apply, as in earlier versions.

Scheduled actions

The module installs 12 scheduled actions (Settings → Technical → Scheduled Actions):

Scheduled action	Runs every	Enabled on install
Takealot: Sync Products	30 minutes	Yes
Takealot: Sync Orders	15 minutes	Yes
Takealot: Sync Customers	60 minutes	Yes
Takealot: Sync Inventory	10 minutes	Yes
Takealot: Process Queue Jobs	5 minutes	Yes
Takealot: Import Payout Reports	6 hours	Yes
Takealot: Import Refunds	30 minutes	Yes
Takealot: Auto Risk Detection	30 minutes	Yes
Takealot: Generate Analytics	4 hours	Yes
Takealot: Cleanup Old Logs	24 hours	Yes
Takealot: Process Workflows	10 minutes	Yes
Takealot: Daily Summary Report	1 day	Yes

Intervals above are the shipped defaults. Adjust them to your volume — but be aware that the platform, not Odoo, sets the API rate limits, and shortening a sync interval is the usual cause of throttling errors in the logs.

Using the module

The module's menu is laid out as:

• Takealot → Dashboard
• Takealot → Orders
• Takealot → Refunds
• Takealot → Products
• Takealot → Customers
• Takealot → Payouts
• Takealot → Analytics
• Takealot → Operations — Run Operations, Queue Jobs, Logs
• Takealot → Premium & Compliance — VAT201 Schedules, DC Inbound Shipments, Pickup Points, Mr D Food Orders, Superbalist Listings, Settlements
• Takealot → Configuration — Instances, Locations, Payment Gateways, Scheduled Actions

A normal first run is:

1. Save the connection record and confirm the module reports a successful connection before importing anything.
2. Review the mapping records so imported data lands on the right Odoo records.
3. Run a small import first — restrict it by date or by a handful of products — and check the results before letting the scheduled actions take over.
4. Watch the log records during the first full sync. Failures are recorded there rather than raised at the user.

Statement-to-bank workflow

Takealot publishes each weekly statement as a document. The Seller API exposes the period and a download link, but the sales, fee, VAT, funding and disbursement figures needed for accounting are inside the workbook. Treat that workbook as the financial source and keep it attached to the settlement.

Before starting, configure these fields on the Takealot instance:

• a bank journal for Takealot disbursements;
• a miscellaneous journal for settlement posting;
• a clearing or bank-suspense account;
• an input-VAT account; and
• a default marketplace-fee expense account.

Use a Finance or Takealot Administrator user for the steps below.

1. Upload and read the statement workbook

1. Download the period's .xlsx workbook from Takealot Seller Portal → Financials → Statements.
2. In Odoo, open Takealot → Premium & Compliance → Settlements and create or open the matching period.
3. Confirm the instance, statement start, statement end and settlement date.
4. Upload the original workbook in Statement File and click Read Statement.
5. Compare the imported row count and totals with the workbook: gross sales, commission, service fee, payment fee, distribution-centre fee, refunds, input VAT, net payout, brought-forward balance, funding repayment and closing balance.

Reading the file does not post accounting. Odoo imports the source rows and checks Takealot's balance identities. Revenue for last N days held back is an explanatory closing-balance note, not an extra deduction.

2. Review and reconcile the settlement

The settlement must show Statement Ties and a Statement Variance of exactly zero. Click Reconcile only after comparing the displayed totals with the attached workbook.

From 19.0.2.1.14, reconciliation preserves the audited workbook totals. It does not replace them with totals from the separate per-order relation. A non-tying statement stays blocked so a materially wrong settlement cannot move to posting.

If the variance is not zero, verify the selected period, confirm every workbook section was read, and compare brought-forward, funding-repayment, debit-order and closing-balance rows. Do not post until the source arithmetic ties.

3. Post the settlement journal entry

After reconciliation, click Post Journal Entry. Open the linked entry and verify all of the following:

• the entry is Posted and identifies the settlement;
• total debit equals total credit;
• clearing, fee, refund and input-VAT amounts use the configured accounts; and
• any foreign-currency values use the Odoo exchange rate applicable to the entry.

The settlement retains its link to the posted entry, keeping the workbook, review decision and accounting result in one audit chain.

4. Create or import the payout

Open Takealot → Payouts. Import the payout metadata from Takealot or create the payout from the verified statement. Confirm the payout reference, Takealot document identifier, instance, date, receiving bank journal, total, fees and net amount.

In a single-currency Odoo database the Currency field is normally hidden. From 19.0.2.1.15, the payout defaults to the active company's currency, so the form saves without enabling multi-currency. If the real payout is in another currency, enable multi-currency and select that currency before continuing. The Takealot payout identifier is unique per instance and must not be reused.

5. Create and link the bank statement

Once the payout is imported, click Create Bank Statement. Odoo creates the statement in the selected bank journal for the verified net amount and links it back to the payout. In the privately supplied support line, build 19.0.2.1.16 uses the connector's supported payout-to-statement link instead of writing removed custom fields on Odoo's core bank-statement models.

The posted settlement entry records the marketplace economics; the payout and bank statement record cash movement. Use the shared clearing account to join those two events without posting the statement twice.

6. Reconcile transaction lines

Click Reconcile Transactions only when the payout contains real transaction rows and the matching Odoo orders or invoices exist. The connector matches actual records; it does not invent per-order lines.

In the privately supplied 19.0.2.1.17 support build, genuine per-order reconciliation follows each transaction's stored statement_line_id link. It no longer searches for the removed takealot_transaction_id field on Odoo's core bank-statement-line model.

Takealot's Seller API does not publish the workbook's per-order settlement rows as a structured feed. An aggregate-only workbook can therefore be reviewed, reconciled and posted, and its cash payout can be linked to a bank statement, but it cannot prove order-level matching by itself. With no transaction rows, Odoo posts Nothing to reconcile in the chatter and leaves the amount visibly unreconciled. Capture genuine transaction rows or import the supporting orders and invoices before claiming transaction-level reconciliation.

Verified support-build behavior (2.1.31)

The privately supplied 19.0.2.1.31 support build was verified in an isolated Odoo 19 QA environment with executed settlement, payout and reconciliation regressions. It is not the public catalogue archive.

The verification confirmed that:

• the connector installs and upgrades as 19.0.2.1.31;
• statement review preserves imported totals and blocks reconciliation when the variance is not zero;
• payout creation uses the active company's currency and retains the supported bank-statement link; and
• when an aggregate source contains no genuine per-order transaction rows, Reconcile Transactions returns Nothing to reconcile instead of claiming an order-level match.

Before booking a real statement, confirm the workbook totals, zero variance, posted entry and bank-statement link in your own review flow.

Troubleshooting

Settlements and payouts

Symptom	Cause and fix
Missing required value: Currency	Ask support for the privately supplied 19.0.2.1.15 support build or later. Payouts default to the active company currency. Enable multi-currency and choose the actual currency for a foreign-currency payout.
Reconcile changed statement totals to zero	Ask support for the privately supplied 19.0.2.1.14 support build or later. Re-read the original workbook, confirm zero variance and reconcile again before posting.
Statement does not tie	Compare the source rows and period, especially carried balances, debit orders, held-back revenue and funding repayments. Odoo blocks reconciliation until the variance is zero.
Nothing to reconcile	The payout has no genuine transaction rows. The aggregate settlement and cash payout may still be recorded, but order-level matching requires real order, invoice and transaction data.
Create Bank Statement is unavailable	The payout must be imported and a bank journal selected. Confirm both fields, then retry.
Invalid field takealot_payout_id while creating the bank statement	Ask support for the privately supplied 19.0.2.1.16 support build or later. Bank-statement creation uses the payout's supported statement_id link.
Invalid field takealot_transaction_id while reconciling a genuine order row	Ask support for the privately supplied 19.0.2.1.17 support build or later. Transaction reconciliation follows the connector-owned statement_line_id link.
The requests library is required	Install requests in the same Python environment that runs Odoo, then restart Odoo.

Syncing

Symptom	Cause and fix
The connection will not validate	Re-check every required field in the table above. Most failures are a mistyped secret, or credentials created for a sandbox while the module points at production (or vice-versa).
Nothing syncs even though the connection is fine	The scheduled actions are disabled at the Odoo level, or Odoo's cron worker is not running. Check Settings → Technical → Scheduled Actions and that --max-cron-threads is greater than zero.
Sync starts then stops part-way	Read the module's log records for that run. Rate limiting and rejected field values are the two common causes; both are logged with the platform's own error text.
Records import but map to the wrong Odoo values	Fix the mapping records under the module's configuration, then re-run the import.
Test Connection failed but the record still reads Connected, and there is no Login button	Fixed in 17.0.2.2.1, 18.0.2.2.1, 19.0.2.2.1 and 20.0.2.2.1: a failed test now leaves the record in its failed state, so the Login button is offered again. Upgrade, then run Test Connection once more.
"Last Sync" on the dashboard reads days old although imports run	Upgrade to 19.0.2.2.2 / 20.0.2.2.2. "Last Sync" then shows the later of Sync Now and the last import that finished without failing, including scheduled ones.
An import says another run of the same kind is already in progress	Expected from 19.0.2.2.2 / 20.0.2.2.2. Products, orders, customers and returns each run once at a time per store; the second run leaves the work to the first. Wait for the first to finish (see the log), then run again only if needed.
A shipped order stays Unfulfilled	Upgrade to 19.0.2.2.2 / 20.0.2.2.2. Status is read per order line from the quantity actually delivered, so validating the delivery updates the order at once, even when a cancelled item still has an open delivery. Orders already delivered are re-read during the upgrade.
Export Stock Levels reports success but Takealot shows the old stock	Upgrade to 19.0.2.2.0 or later and map your own warehouses under Takealot → Configuration → Locations. Earlier builds sent nothing; the Operations Center now tells you when no warehouse is mapped.
A normal user gets an access error at the end of a bulk statement-file import	Fixed in 19.0.2.2.2 / 20.0.2.2.2: every connector log line now records its company, so the import completes for finance users who are not the administrator.
The dashboard's Order Status chart is blank, or the dashboard stays light in dark mode	Upgrade to 19.0.2.2.3, 18.0.2.2.2 or 17.0.2.2.2. The chart draws, dark mode is applied, and a load failure shows a message with Retry at the top of the dashboard.
Duplicated products or customers	Run the initial import once. If a first attempt half-finished, check the existing records before re-running rather than importing on top.

Version history

Odoo version	Current shipped version	Earlier catalogue build
20.0	20.0.2.2.2	—
19.0	19.0.2.2.3	19.0.2.1.12
18.0	18.0.2.2.2	18.0.2.2.0
17.0	17.0.2.2.2	17.0.2.2.0

ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>. Your installed version is shown in Apps. The Odoo 20 build carries the same fixes as the Odoo 19 build of the same number.

What changed in 19.0.2.2.3, 18.0.2.2.2 and 17.0.2.2.2

These releases change how the Dashboard and the connector's lists look and report their state. No data, sync or accounting behaviour changes.

• The Order Status chart draws. It could stay blank under its legend; it now shows the completed, pending, failed and cancelled split.
• Dark mode is applied. With Odoo set to dark, the dashboard now uses dark cards and readable text instead of staying light.
• Load errors are visible. If the dashboard cannot load its data, a red message appears at the top with Retry and Sync Logs, the status chip reads Unavailable, and figures show "—" instead of zeros.
• Loading shows placeholders, never zeros, until the figures arrive.
• Before a store is configured, Sync Health and Sync Rate show "—" with No sync has run yet instead of 100 %, the setup message sits at the top, and empty charts say No sales in this period / No orders in this period.
• On a phone, the store-name chip no longer runs off the screen.
• Lists (Instances, Orders, Locations, Customers) no longer show an empty Active column. Archived records are still found with the Archived filter.

What changed in 2.2.0–2.2.2

2.2.2 (Odoo 19 and 20)

• The bulk statement-file import no longer fails for a normal user. The summary line of a statement import belongs to no queue job, and the log's company rule reached the company only through a job, so a finance user who is not the administrator was refused at the end of the import. Every log line now records its own company (from its job, or from the store it is about).
• An order reads Fulfilled as soon as its goods have left. Status is now read per order line, from the quantity actually delivered to the customer, over the lines Takealot still expects. Validating a delivery updates the order at once, an order sync keeps what the deliveries prove (partial as well as fulfilled), and an order whose cancelled item still had an open delivery no longer stays Unfulfilled. Orders already delivered are re-read when you upgrade.
• "Last Sync" on the dashboard and the store form shows the truth. It shows the later of Sync Now and the last import that finished without failing, whether a scheduled action or a button ran it.
• Two imports of the same kind can no longer run over each other. Products, orders, customers and returns each run once at a time per store. A second run says so in the log and on screen, leaves the work to the first and does not count as a finished sync; a long order history keeps its place from the first slice to the last. A return that another process was changing at the same moment is imported again automatically instead of being counted as an error.
• The "Log Event" workflow step writes its log line against the right order and that order's company, instead of under an unrelated queue job.

2.2.1 (Odoo 17, 18, 19 and 20)

• A failed Test Connection no longer leaves the record reading Connected. The failure status is recorded on its own short transaction, so it survives the error and the Login button stays available to re-authorise. On Odoo 17 and 18 this fix first shipped as 2.1.13; 17.0.2.2.1 and 18.0.2.2.1 carry the same code, numbered above the earlier 2.2.0 builds so Odoo and the Apps Store treat them as an upgrade.

2.2.0 (Odoo 19 and 20)

• Your stock levels now actually reach Takealot. Export Stock Levels used to report success while sending nothing, and the product export sent stock under a field name Takealot ignores. Stock is now sent per warehouse, the way Takealot documents it, from the warehouses mapped under Takealot → Configuration → Locations. With no mapping, the Operations Center tells you so instead of reporting success.
• Takealot-fulfilled warehouses are left alone. Stock held in a Takealot distribution centre belongs to Takealot; only your own warehouses are exported to.
• A product with no price, or a price of zero, is refused instead of listed, with the reason in the log; the rest of the export carries on.
• Prices are sent as whole rands. A price such as 499.99 is rounded and the rounding is written to the log.
• "Created On" and "Last Updated" show real dates on queue jobs and the connector log.
• Fields you record yourself can now be filled: the inbound booking reference, actual arrival date and booking date on a DC shipment (the booking date is stamped when you move it to Booked); the SARS response, error code and message on a VAT201 return; the Superbalist listing ID and rejection reason; the refresh date on a pickup point; and the Primary / Takealot-fulfilled flags on a location. These values live in the Seller Portal, on SARS eFiling or with Superbalist, not in the API.
• "Eligibility Check" replaces "Eligibility Result" on DC shipments: Takealot decides DC eligibility inside the Seller Portal and publishes no check, so the box holds your own notes.
• New: Export Products (Bulk Batch) in the Operations Center sends the whole catalogue through Takealot's bulk offer upload, up to 10,000 offers per call. Any offer Takealot rejects is logged with the reason and marked as an error on the product.
• New: Check Enabled Regions on the Takealot instance records which regions your seller account may sell into, useful when an offer is live but not buyable.
• Single-offer lookups and updates by SKU or barcode use Takealot's documented offer identifier form.

2.1.33 (Odoo 19)

• Your own contacts stay yours on every import. Every import pass fills in only the fields you left empty, adds tags instead of replacing them, and never changes whether a contact is a company or a person.
• Imports no longer stamp their marks on contacts they merely found. The Takealot: <id> reference, the Takealot Buyer tag and the import note go only onto contacts the connector created; your contact still receives the delivery distribution-centre tag.
• New read-only field Created by Takealot Import on contacts, set only at creation. The duplicate repair trusts only this field and treats a contact as untouched history only if it has no order, invoice, payment, delivery, addresses, messages or notes.
• Buyer names containing _ or % are matched literally, and a buyer with an email but no usable name is filed instead of failing.
• Contact books duplicated by a version before 2.1.33 are left alone unless you deliberately run repair_duplicate_buyer_contacts(apply=True, legacy_provenance=True) after reviewing its report.

2.1.32 (Odoo 19)

• Importing customers no longer duplicates your contact book. The order and customer imports now resolve a buyer through one shared lookup, so the customer import enriches the existing contact instead of creating a second one.
• A repair for databases that already ran both imports: env['takealot.customer'].repair_duplicate_buyer_contacts() from an Odoo shell reports what it would change; add apply=True to carry it out. Duplicates are archived, never deleted, and never touched if they hold a document or you created them.
• Takealot identifies a buyer to sellers by display name only, so two different people with the same display name resolve to one contact.

Changes in 2.1.13–2.1.31 (Odoo 19)

2.1.31 (Odoo 19)

• A multi-unit order is imported at the price the customer actually paid. Takealot's sales feed gives each order line its total price (quantity x unit price). The importer read that total as the unit price and Odoo multiplied it by the quantity again, so five units at R249 -- R1,245 -- were created, invoiced and paid through the clearing account at R6,225. Single-unit orders were unaffected, which is why it stayed hidden. The unit price is now the line total divided by the quantity.
• Existing orders are repaired on upgrade where that is safe. Lines on quotations that are still editable and not invoiced are corrected in place. Confirmed or invoiced orders are left exactly as they are and listed in the Takealot log (order, line, stored amount, expected amount), so the correction is made deliberately as an accounting entry and never silently.

2.1.30 (Odoo 19)

• History imports work for ranges longer than six months. The Seller API refuses a date filter wider than six months outright, so importing history from December 2023 to today failed on its very first request and brought back nothing. Any From/To range is now split into consecutive six-month requests, oldest first, and each slice is imported fully before the next begins.
• A long history run keeps what it has already imported. Each completed slice is saved as the walk progresses; if a later slice fails, the error names the exact date window that failed and everything imported before it stays in Odoo. Re-running the same range resumes rather than starts over, because re-imported orders update in place instead of duplicating. Every slice leaves a line in the Takealot logs (window, pages, rows).
• A date range that ends before it starts is refused up front, naming both dates, instead of being sent to Takealot to fail.

2.1.29 (Odoo 19)

• Upgrading corrects the Reconciliation Variance already on screen. 2.1.28 fixed how the variance is worked out, but the figure is stored on the settlement and Odoo does not rework a stored figure just because the rule behind it changed -- so a settlement imported before the upgrade kept its old number. Upgrading reworks the variance on every existing settlement. Nothing is posted, and no journal entry is created, changed or unposted.
• A debit order that really was a deduction keeps reconciling.

2.1.28 (Odoo 19)

• A debit order is treated as money paid in to the Takealot balance, and the journal entry posts it in the correct direction.

2.1.27 (Odoo 19)

• Import Stock Levels names the stock it could not import instead of finishing quietly.

2.1.26 (Odoo 19)

• Import Statement Files (Premium & Compliance menu). The Seller API does not serve every week a long-standing seller ever traded, but the Seller Portal offers every statement as a downloadable workbook. The new wizard takes those workbooks -- one, or a few hundred -- and builds one settlement per disbursement period through the same reader the Read Statement File button uses, carrying the workbook, every row as published and the audited totals, plus one payout per period. Dry Run parses every file and reports the periods covered, the totals per year and any file it could not read, without writing anything. The import is repeatable: a period that already has a settlement is reported as already imported and left alone, and each file runs independently, so one unreadable workbook never costs the run the files before or after it. Finance and administrator users only.
• Probe Statement Window (instance form). Read-only. Walks the Seller API's statement listing and records the earliest and latest period it serves, the document count per year and the earliest document id -- the measurement that decides where the API import stops and the statement-file import starts on a historical load.
• The location mapping now explains the two separate Takealot stock pools: CPT, JHB and DBN rows are units already held at Takealot, while a merchant warehouse row is your own lead-time stock. Mapping several rows to one Odoo warehouse still aggregates them, but the help text warns against mixing the two pools by accident.
• A subscription fee and its reversal now classify as a service fee. The reversal was previously bucketed as a customer refund.

2.1.25 (Odoo 19)

• Stock import writes to the product each offer is mapped to. Import Products records which Odoo product every Takealot offer belongs to, but the stock importer never read it -- it re-guessed the product from the offer's SKU, barcode and title. A live offer whose SKU is not the product's internal reference therefore resolved to nothing, or to whichever other product carried that reference, while a retired offer carrying the old SKU resolved fine and wrote its zero. The importer now resolves each offer through its mapping first, and falls back to the SKU, barcode and title guess only for offers nobody has mapped. An offer that resolves to no product is logged as a warning naming the SKU.
• Paid versus In Payment on the clearing journal is decided by the journal's own account, not by its type. When the journal's own account is the Takealot Clearing account, Odoo treats the payment as already matched and the invoice reads Paid at once. When the journal has its own separate account and Takealot Clearing is its Outstanding Receipts account, the invoice reads In Payment until the Takealot deposit is reconciled. The connector logs a warning when the two accounts coincide.

2.1.24 (Odoo 19)

• One Takealot offer can no longer overwrite another on the same Odoo product. Where two offers resolve to the same product -- typically a retired offer alongside the current one -- each used to write its own quantity, and a stock write is a set rather than an increment, so whichever offer came last in the feed decided the result. A disabled offer with zero stock could therefore wipe the live offer's quantity. The feed is now resolved to one quantity per product before anything is written: live offers are summed, and retired offers contribute only when no live offer carries a quantity for that warehouse. The decision is logged per product.
• Clearing payments produce real journal entries. Odoo 19 takes a payment's outstanding account from the payment method line alone, and a journal created by hand starts with that account empty -- so the payment was created with no journal entry at all while the invoice still read In Payment, with no error anywhere. Setting the Takealot Clearing Journal now configures the Outstanding Receipts account on that journal's incoming payment methods; an account you chose yourself is never overwritten, and an existing installation is corrected on upgrade. If no account can be resolved, the invoice is left open with an explanatory message instead of being marked In Payment with nothing behind it.

Payments created before 2.1.24

Payments already created without a journal entry are not repaired automatically, and the upgrade lists them in the server log. To correct one: open Accounting -> Customers -> Payments, filter on the Takealot Clearing journal, and for each payment showing no journal entry, cancel it, reset it to draft and delete it -- there is no accounting entry behind it, so nothing is lost and the invoice returns to Not Paid. Then open the invoice, click Register Payment, choose the Takealot Clearing journal, set the payment date back to the invoice date and confirm. Re-posting the original payment instead of replacing it does not work.

2.1.23 (Odoo 19)

• Imported invoices and clearing payments use the Takealot company's local order day. A sale at 23:06 UTC on 31 August is 01:06 on 1 September in South Africa; imports running as a UTC user previously dated both accounting records on 31 August.
• Automatic order re-import no longer reopens a locally fulfilled order. The sales feed carries no seller-side delivery status, so its missing value normalised to Unfulfilled on every run. A Fulfilled status backed by validated Odoo deliveries is now preserved.
• Analytics follows the Takealot company's local calendar. Period bounds and Sales Trend grouping convert Odoo's UTC datetimes to the company timezone, so early-morning South African orders stay on the correct day. Customer Growth is grouped by each customer's first Takealot order for the instance rather than the shared contact's creation date.

2.1.22 (Odoo 19)

• The Analytics charts fill their cards. 2.1.21 connected the four charts to their data, but each drew at the canvas's default width inside a much wider card, leaving roughly 40% of all four cards blank.

2.1.21 (Odoo 19)

• The four Analytics sections draw their data. Sales Trend, Customer Growth, Top Products and Inventory Status were static placeholders reading "Generate analytics to view chart"; the figures behind them were always computed, only the charts were missing.
• Confirming an imported order no longer overwrites its Takealot order date.
• A month of analytics no longer loses its last trading day.
• The automatic clearing payment is dated on the invoice, not on the import.

2.1.20 (Odoo 19)

• Settlement input VAT is the VAT Takealot actually charged. The poster derived a blended VAT rate from the statement header and applied it to the fee aggregates. On a real statement the VAT column sits on the fee rows and the customer-order rows are zero, so a statement carrying R880.81 of fee VAT was posted as R328.70 -- input VAT under-claimed and fee expense overstated by the difference. Where the statement rows are present the entry now takes the VAT-exclusive expense and the VAT from those rows, to the cent.
• Fee reversals net against their own fee instead of counting as refunds. A "Success Fee Reversal" row was bucketed as a customer refund, so the entry credited the clearing account with the gross fee while Takealot had deducted the net -- drifting the clearing balance and overstating commission by every fee reversal. Only a Customer Order Reversal is a refund.
• The settlement entry carries tax grids, so the Tax Report populates. Journal items posted straight to a VAT control account carry no tax tags, and Odoo's tax reports are computed from those tags, so the Tax Report read R0.00 while the ledger held the input VAT. A new instance setting, Fee Purchase VAT Tax, puts that tax's grids on the fee and input-VAT lines. Left empty, posting is unchanged and the settlement's chatter says the VAT will not reach the Tax Report.
• Seller Capital repayments and debit orders are booked. Both were parsed and used in the reconciliation identity but never appeared in the journal entry, so the payout could not reconcile to the cent. They are now posted against a Seller Capital Account and an optional Debit Order Account.
• Imported Takealot invoices can be paid automatically. Auto Register Payment previously lived only on the per-financial-status workflow record, selected by a field the sales feed does not publish -- so the payment step was unreachable in every configuration and every imported invoice stayed open in Debtors. Auto Register Payment and a Takealot Clearing Journal are now instance-level settings applied right after the invoice is validated.
• Backfilled invoices are dated on the Takealot order date, not the import day. Odoo stamps a draft invoice with today's date at posting, so importing history dumped every one of those invoices into the import month's VAT period. A date inside a closed period falls forward to the first open day with a note on the invoice.
• Returns imported before their order now relink. The returns feed reaches further back than the order window, and a refund's order link resolved once at creation and never again, leaving Sale Order and Credit Note permanently empty. Refunds are relinked automatically when the covering orders are imported, and a Relink Order button does it on demand.
• Credit notes reduce the VAT201 boxes instead of increasing them. The schedule summed amounts Odoo keeps positive on a credit note, so a posted customer refund would have added to boxes 1 and 4, increasing the VAT declared to SARS.

2.1.19 (Odoo 19)

• Payouts inherit their amounts from the covering settlement.
• "Create Bank Statement" on a payout refuses to book a zero.
• The VAT201 schedule can leave Draft. The statusbar advertised a transition that could not be made.

2.1.18 (Odoo 19)

• The per-record "Import from Takealot" on a payout accepts the live epoch format the Seller API sends.

2.1.17 (Odoo 19)

• Genuine transaction reconciliation uses the stored bank-line link. The follow-on reconcile action no longer searches for the removed takealot_transaction_id field on Odoo's core bank-statement-line model.
• Added an executed regression with a real sale order, posted invoice, payout transaction and created bank statement.

2.1.16 (Odoo 19)

• Bank-statement creation uses supported links. Creating a bank statement no longer tries to write the removed takealot_payout_id or takealot_transaction_id fields on Odoo core models. The payout links to its statement through statement_id, and a genuine transaction links to its statement line through statement_line_id.
• Added regression coverage for payout and transaction linkage.

2.1.15 (Odoo 19)

• Single-currency payout creation works without exposing the Currency field. New payouts default to the active company's currency while foreign-currency payouts remain explicit when multi-currency is enabled.
• Added the detailed settlement-to-bank operating guide and troubleshooting controls.

2.1.14 (Odoo 19)

• Settlement reconciliation preserves the workbook-derived financial totals. It no longer replaces aggregate values with zeros when the separate per-order relation is empty.
• Non-tying statements remain blocked instead of advancing to accounting posting.

2.1.13 (Odoo 19)

• The Odoo connector was decoupled from the ECOSIRE runtime enforcement dependency. Standard Odoo access controls and business validations remain unchanged.

What changed in 2.1.11-2.1.12

2.1.12 (Odoo 17, 18 and 19)

• The connector can now read your Takealot statement file. Takealot's API publishes each weekly statement as a document rather than as numbers, so the fee, VAT, Seller Capital and disbursement figures were only available inside the downloaded file and had to be typed in by hand. Upload the file on a settlement and press Read Statement File: every row is imported as Takealot published it, the totals are filled in, and the statement is checked against Takealot's own arithmetic. See Statement-to-bank workflow.
• Seller Capital repayments and TFS charges are read with everything else. They are ordinary statement rows, and the deposit in your bank cannot reconcile without them.
• The VAT201 schedule no longer overstates the VAT payable. The input VAT boxes were shown on the form but never filled, while the net payable subtracted them, so every period overstated what was owed by the VAT already paid on Takealot's fees. Box 6 is now calculated from posted purchase documents and from the settlement entry's input VAT. Box 5 (capital goods) stays yours to enter, and the net payable now recalculates when you do.
• The Takealot breakout figures on the VAT201 schedule - marketplace sales, commission and DC fees - are filled from the settlements posted in the period instead of staying blank.
• The reconciliation variance now uses the whole statement, including the opening balance, reversals, Seller Capital and the balance Takealot holds back. A statement that ties correctly no longer shows a variance.
• A delivered Mr D Food order can no longer be deleted by accident. Orders from accepted through delivered refuse deletion and say which ones; new, rejected and cancelled orders can still be removed. Selecting a mixed batch deletes nothing.

2.1.11 (Odoo 17, 18 and 19)

• Packaging only: an internal review file was removed from the published module. No functional change.

What changed in 2.1.5–2.1.10

2.1.10 (Odoo 17, 18 and 19)

• Settlement and payout imports now search your whole statement history. Takealot serves the statement list 100 documents at a time, and the connector only ever read the first 100. A seller with a longer history could not reach anything past that, so Import Settlement and Import Payout Report reported "No Takealot statement document matches this settlement date" for statements that were genuinely there. Every page is now read before matching.
• The statement covering your settlement date is now found. Takealot sends statement periods as numeric timestamps. Settlement matching compared them as plain text, which ruled out every statement, so the match failed no matter which date you entered. Periods are now read correctly, and the matched statement is shown with readable dates instead of raw numbers.

2.1.9 (Odoo 17, 18 and 19)

• The 2.1.8 role roll-up now also repairs already-installed databases: upgrading the module (Apps → Upgrade) grants Managers and Administrators the Finance, Operations and Analytics roles on existing installs, not only on fresh ones.

2.1.8 (Odoo 17, 18 and 19)

• Administrators and Managers now see every screen. The Takealot Finance, Operations and Analytics roles were parallel roles, so the person who installed the connector could not see Payouts, Settlements, VAT201 Schedules, DC Inbound Shipments or Analytics without ticking three extra boxes on their user. Manager and Administrator now include those roles — upgrading the module repairs existing databases, no user editing needed.
• South African VAT-inclusive pricing is now a setting. Takealot quotes prices with VAT inside them; a standard Odoo sales tax adds 15% on top, so an R249 listing invoiced at R286.35. The connection's Order Workflow tab now carries a Takealot Sales Tax (the module refuses a tax that is not "Included in Price") and a Zero-Rated / Exempt Tax. The order importer applies them per line, honouring the per-product ZA VAT flags (inclusive / zero-rated / exempt) now visible on the product form's Takealot tab. Leave the setting empty and each product's own Customer Taxes keep applying, exactly as before.
• The dashboard shows your currency, not $. The trend-chart tooltip had a dollar sign written into it and the loading placeholders defaulted to dollars; every figure now derives from your company currency.
• The Customers card counts buyers. It previously counted customers touched by a sync in the window; it now counts customers whose orders were placed in the window, and the period-over-period deltas compare like with like.
• "Return Rate" is now "Cancellation Rate" — that is what the figure has always measured (cancelled orders as a share of imported orders).
• Reconcile on an empty payout says so. Pressing Reconcile on a payout with no captured transaction lines no longer reports success; it explains that Takealot's Seller API does not publish per-order settlement rows and points at the Settlements screen.
• The connection's Default Warehouse pre-fill is deterministic and its help text now explains it is a one-time default that does not follow warehouses you create later.

2.1.7 (Odoo 19)

• Stock import now reads both warehouse families in Takealot's offer feed: stock_at_takealot for Takealot distribution centres and leadtime_stock for merchant warehouses. Distribution centres are discovered into Configuration → Locations for mapping, quantities from several locations mapped to one Odoo warehouse are aggregated, and products created by the importer are stockable.
• Returns, statements and payouts now share one date parser for epoch seconds or milliseconds, ISO timestamps and date-only values. Those rows also respect the date window selected in Operations.
• The inventory schedule waits quietly until a stock-warehouse mapping exists, while the manual import still explains what must be configured. An API-key failure stops once per instance instead of repeating for every mapped location.

2.1.6 (Odoo 17, 18 and 19)

• Imported draft orders inherit the instance's Default Warehouse. Existing draft orders are backfilled on re-sync; confirmed orders keep their original warehouse so their stock reservations are not rewritten.
• Import Locations now creates or updates the merchant warehouses returned by Takealot instead of reporting success without records.
• Refund import now queries the real returns feed over the selected range, and checks whether the seller genuinely has no returns when the result is empty. Refund and payout imports both honour the dates selected in the Operations wizard.
• Missing financial permissions now produce a clear error. Archived ZAR is found and reactivated instead of causing a duplicate-currency failure, and Operations reports real created, updated and failed counts.

2.1.5 (Odoo 19)

• Order and customer imports always send both date bounds required by GET /sales/orders. The From Date and To Date selected in Operations are now passed through and honoured.

What changed in 2.1.2

Every API path in the module was re-verified against Takealot's live API specification and corrected where it did not match. Alongside that:

• Webhook subscriptions are supported by the connector's API client — register, list, test and delete. There is no in-app subscription screen yet, and record sync still runs on scheduled polling.
• Return disputes can be raised and updated through the connector's API client (not yet from an Odoo screen). This is the seller-side action the Seller API actually supports; there is no approve/reject call.
• Settlement amounts are read from the statement file, which is attached to the settlement record. The JSON listing exposes document metadata and a download link only, so no amounts are inferred from it.
• Fulfilment status is read-only. The Seller API has no seller-side shipment or order-status endpoint, so "Update Order Status" is now Update Local Fulfilment Status — it marks the Odoo-side mapping fulfilled from your completed deliveries and never claims to have updated Takealot.
• The API client's read coverage was extended to offer counts, stock counts and stock-health statistics, sales summary, per-order customer invoices, catalogue PLID lookup, category attributes, brand search and async report tasks (most of these are not yet exposed as Odoo screens).

What the Takealot Seller API cannot do

Takealot describes its Seller API as "the initial phase of the Seller API". These are not module limitations — the platform exposes no endpoint, and this module does not simulate one: pushing shipment or order status, approving or rejecting a return, writing stock quantities through a separate inventory API, reading payout or adjustment AMOUNTS from the API (the statement list carries document details only, which is why the module reads the statement file itself), requesting brand approval, or submitting new products. New products go through Add-a-Product or loadsheets in the Seller Portal.

Support

• General troubleshooting
• Email: info@ecosire.com
• Support portal