Takealot Store Management

This is the installation, operations and accounting guide for Takealot Store Management. It distinguishes the public catalogue build from privately supplied support builds; support-only behavior is labelled explicitly.

Technical name	takealot_store_management
Odoo versions	17.0, 18.0, 19.0 (Community or Enterprise)
Current public catalogue version	17.0 → 17.0.2.1.12, 18.0 → 18.0.2.1.12, 19.0 → 19.0.2.1.12
Privately supplied verified support build	19.0 → 19.0.2.1.31
Price	$499 USD — one-time, per Odoo version
Odoo module licence	OPL-1
Category	Connector

Private Odoo 19 support build 2.1.31 is self-contained

The privately supplied, verified Odoo 19 support build has no separate ECOSIRE runtime dependency or key check. It is not the public catalogue archive. Install the connector archive itself and the standard Odoo dependencies listed below.

Requirements

Requirement	Detail
Odoo	17.0, 18.0 or 19.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, knowledge — Odoo installs any that are missing
ECOSIRE dependency	None for the privately supplied Odoo 19 support build 19.0.2.1.31
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
Takealot Shop URL	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 4 behaviour checkboxes — auto_validate_inventory, auto_confirm_order, auto_create_invoice, auto_validate_invoice. 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 13 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: Webhook Health Check	60 minutes	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, Webhooks

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.
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	Public catalogue build
17.0	17.0.2.1.12
18.0	18.0.2.1.12
19.0	19.0.2.1.12

ECOSIRE module versions are <odoo major>.<module major>.<minor>.<patch>. The privately supplied, verified Odoo 19 support build is 19.0.2.1.31; it is not the general public catalogue build. Your installed version is shown in Apps.

Private support-build changes after public 2.1.12

2.1.31 (privately supplied Odoo 19 support build)

• 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 now supported — register, list, test and delete them from Odoo. Earlier documentation stated this module was polling-only; that was wrong.
• Return disputes can be raised and updated. 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.
• 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.

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