Merit · E-Commerce Solutions · Product
One plan, one phase numbering, and a clear answer to where Odoo fits. Written 4 August 2026 to replace two competing versions of the roadmap that were circulating at once.
Two different phase numberings have been in use since June. The implementation update posted to the channel describes four phases. The Problem Statement and Plan, which declares itself the workstream's source of truth, describes five. They use overlapping names in different positions, so "Phase 2" means different things depending on which document the reader last opened.
That ambiguity is not cosmetic. It is why Finance has raised requirements that sound out of scope but are not, why the relationship to Odoo keeps being re-litigated, and why the same conversation has now happened three times in two weeks.
This plan reconciles the two into one numbering, states what each phase delivers and what it achieves, and shows exactly where the Odoo integration attaches.
The single most important thing on this page
The Data Lake is where this system reads gift card values from. It is an input, not a destination. What the accounting system eventually consumes is the auto-generated Statement of Account, produced from the transaction ledger in Phase 4. That is the deliverable Odoo waits on, and it is the only one.
The chain
The concern raised on 4 August was that if this automation does not connect to Odoo, then Odoo goes live as a standalone system fed by manual Excel work. The concern is valid. The answer is that this system's job is to produce a correct, automated Statement of Account, and that is what accounting consumes.
Figure 1 · Inputs, approval, and what accounting receives
Card values are read in from the Data Lake, supplier rates and client discounts arrive as proposals, and nothing goes live until Finance approves it. The Master Catalogue is the only record that counts, and it propagates to client catalogues and MGC in Phase 2. The transaction ledger and the Statement of Account are Phase 4, and the SOA is what the accounting system consumes. The accounting side itself is built by the Odoo implementation, not here.
Supplier costs, client discounts, card values read from the Data Lake, VAT, FX and revenue share, calculated by rule instead of by hand.
The per-transaction ledger and the auto-generated Statement of Account per client, formatted to match the accounting system.
Chart of accounts, supplier and customer master lists, accounting mapping and the invoice module. This is the Odoo implementation, run separately.
Why this ordering and not the reverse
Connecting Odoo to a Data Lake that is still inconsistent and manually assembled would encode today's problems into the new ledger permanently. Getting the data correct first is what makes the connection worth making. This is also why the 20 percent naming-exception cleanup matters more than it looks: it is a prerequisite, not housekeeping.
Reconciliation
Both documents were right about the work. They disagreed only about labels. This table maps them onto each other and fixes the canonical numbering going forward.
| Canonical | Name | Problem Statement and Plan | Implementation update in channel |
|---|---|---|---|
| P1 | Visibility Foundation | Phase 1, Visibility Foundation | Phase 1, Master Catalog and Initial Controls |
| P2 | Master to Client Sync and Revenue Models | Phase 2, Master to Client Catalogue Price Sync | Phase 2, System Sync and Revenue Models |
| P3 | Supplier Rate Submission and Approval Workflow | Phase 3, Supplier Rate Submission | Not represented |
| P4 | Transaction Ledger, SOA Automation, Multi-Level Revenue, AM Catalogue and Notifications | Phase 4, Transaction Ledger and SOA Automation | Phase 3, AM Catalog Gen and Notifications |
| P5 | Supplier Routing and Golden Catalogue | Phase 5, Automated Supplier Routing | Phase 4, Buy Box Rules and Data Cleanup |
The collision that caused the confusion
Account Manager catalogue generation and client notifications sat at Phase 3 in the channel update but at Phase 4d in the plan. Anyone reading the channel therefore believed notifications were closer than they were, and anyone reading the plan believed supplier ingestion came first. Both were reading correctly from different maps.
The Problem Statement and Plan is the single source of truth for sequencing, as its own ground rules already state. The canonical column above is now the only numbering used in status updates, Slack, and requirement documents. The implementation update is superseded and should not be cited for phase numbers.
Delivery
Sequencing is deliberate. The highest-leverage, independently shippable chunk ships first, ahead of supplier-side ingestion, because all the data it needs already sits inside Merit.
19 May to 9 June 2026
Establish the Master Catalogue and the initial controls around it. Get sight of what is actually in the catalogue, who changes it, and where the manual steps sit.
We can now see the problem. Before this, pricing changes were invisible until a margin loss surfaced in a month-end reconciliation.
Build not started · awaiting Rajaa's approval since 20 July
A single price or discount change entered once in the Master Catalogue propagates automatically to every client catalogue that maps that product, and syncs to MGC. Revenue calculation is done by the system: card values read from the Data Lake, discount or markup, VAT on margin only and in-country only, activation and handling fees, FX at transaction-date spot plus three percent.
One price change is entered once instead of per client catalogue, and the revenue figure behind it is computed by rule rather than by hand. It removes the manual propagation step and the margin-loss case where a fixed client discount silently outlives the supplier margin it was priced against.
What this phase does not do
It does not produce a Statement of Account, a transaction ledger, or per-client reporting currency. Finance's month-end reporting work is untouched by Phase 2. That is Phase 4, and saying so plainly is what stops this phase being oversold to the people waiting on the other one.
After Phase 2
Suppliers submit their own rate changes instead of Merit chasing them. Three intake modes feed one approval queue: API push for the confirmed discount-API suppliers, a portal form for small and mid suppliers, and structured CSV for transition cases. Finance approves or rejects with a written reason, with a full audit trail.
Closes the gap Phase 2 knowingly leaves open. Phase 2 propagates whatever is entered, correct or not. This phase removes the manual entry point where the error originates.
Dates not set
The phase Finance actually feels. Every order records supplier used, discount rate applied, client, product and timestamp, with the rate snapshotted and immutable. Revenue share becomes configurable per level with cascading priority from catalogue default down to product-level exception. The Statement of Account is generated from ledger data automatically, formatted to align with the accounting system.
Month-end Excel reconstruction disappears entirely. This is the phase that produces what Odoo consumes and what Finance has been asking for. It is currently two phases away with no dates against it.
Requires the Phase 4 ledger to be live
The system selects the optimal supplier automatically, using historical fulfilment rate and margin data from the Phase 4 ledger. One SKU equals one product equals one golden record, following an Ops-led deduplication sprint.
Zero duplicate SKUs, which is the precondition for Buy Box rules to function at all, and for ERP to hold a clean product master.
Mapping
Raised by Mohamed Farid in writing and re-raised on the 4 August call. None of them are rejected. Four of the five are already inside the plan; only one sits outside it, and it sits outside for a stated reason.
| Requirement | Lands in | Position |
|---|---|---|
| Link the Discount, Activation, Handling and VAT columns to the SOA report extracted from the Data Lake | P2 P4c | The calculation itself is section 2.1 of the sign-off document and is built in Phase 2. The SOA report that presents those columns is generated in Phase 4c. |
| Add a calculation column into the Data Lake to compute revenue by the agreed methodology | P2 | In scope now. This is the revenue calculation engine, already specified: discount or markup, VAT on margin, fees, FX. |
| Segregate clients by reporting currency | P4c | In scope. FX itself is Phase 2. Producing per-client statements in each client's own reporting currency is part of the SOA generator in Phase 4c. |
| Enable SOA extraction for specific date ranges per client | P4c | In scope. Requires the per-transaction ledger from 4a to exist first, since a date range is only meaningful against transaction-level records. |
| Reflect final revenue figures on the customer invoice module in Odoo | Odoo | Outside this workstream. This is a write into the accounting system and belongs to the Odoo implementation. This plan delivers the data it reads. |
The honest read
Three of these five need Phase 4, which currently sits behind Phase 3. Phase 3 serves suppliers and Partnership. Finance's entire ask therefore queues behind a phase that delivers Finance nothing, while the Odoo go-live is fixed at 31 August. That sequencing question, not the Odoo connection, is the real decision on the table.
And Finance has already said this out loud
Mohamed Farid, 3 August: "the calculations only takes one day, this was not the main issue for finance, the main issue is really the Data lakes, accounting system reflection and the SOA deliverables to the clients."
That is Finance's revenue SME naming Phase 4 content as the real need, in writing. It is the strongest available argument for re-sequencing, and it came from the person the re-sequencing would serve.
Pull 4a and 4c, the transaction ledger and the auto-generated SOA, forward so they run in parallel with or ahead of Phase 3. Phase 3 removes manual entry error at the supplier end, which is valuable but not dated. Phase 4 produces the reporting layer Odoo needs, which is dated at 31 August.
This is a re-sequencing, and ground rule six of the plan states that re-sequencing happens only through a written change to the plan, not in a call. That is the correct process and it should be followed here rather than worked around.
Where we actually are
Figure 2 · Sign-off state, Gift Card Revenue Model
Build does not start until all four sign. Three signed on 16 July. The fourth has been open for fifteen days on a single stated objection.
Rajaa's blocking comment on 20 July was short: "as discussed, I need more details on the exceptions before proceeding further." It has been chased at least three times since, and the answer has never been supplied.
On the 4 August call she gave the substance of it. Merit has roughly 20 percent exception cases in the catalogue, including the same product carrying different profit margins for different customers and inconsistent naming that breaks even a simple lookup. Her position is that she will not build a system on exceptions, and that the fix is Finance and account management going back to those customers as a restructuring exercise.
That is not a new topic. It is Open Decision 6 in the plan, open since June: finalise the full list of revenue-share exception models as input to Decision 1 and Phase 4, owned by Amr and Finance. It is also entangled with Open Decision 1, the Phase 2 blocker, which asks whether the revenue-share model sits at top client-catalogue level or is bifurcated by country, brand and product.
What this reorders
The path to Rajaa's signature is the exceptions list, not the Odoo timeline. The Odoo conversation is a symptom of the delay, not its cause. Closing Open Decision 6 unblocks Open Decision 1, which unblocks the Phase 2 build, which is what makes the Data Lake trustworthy in time for the go-live.
| # | Decision | Owner | Status |
|---|---|---|---|
| 1 | Does the revenue-share model sit at top client-catalogue level, or bifurcated by country, brand and product? Engineering effort scales directly with this. This is the Phase 2 blocker. | Finance, Rajaa and Amr | Open |
| 2 | Declare the single source of truth and canonical data flow; formally connect the supplier portal to the online catalogue. | Brian and Tahsin propose, Finance, Ops and Partnership ratify | Drafted |
| 3 | Approve the approved-rate flag plus the both-directions alarm as a hard prerequisite before any auto-pull. | Brian and Tahsin draft, Finance and Partnership approve | Drafted |
| 4 | Grant Ops read access to online-catalogue discounts, yes or no, with scope. | Finance, Rajaa | Open |
| 5 | Definitive list of suppliers with a catalogue API, defining Phase 3 scope. | Tahsin and Rohit | Done 22 Jun |
| 6 | Finalise the full list of revenue-share exception models as input to Decision 1 and Phase 4. | Amr and Finance, Faras compiles | Open, and now the critical path |
Actions
Figure 3 · Dependency chain, and the one thread that unblocks it
Everything downstream of the exceptions list is currently waiting on it. It has been open since June and is owned by Finance, which means Merit product cannot close it unilaterally, only make it easy to close.
| # | Action | Owner | When |
|---|---|---|---|
| 1 | Settle whether Phase 2 pushes to the Data Lake. The June implementation update says yes, Mohamed Farid has asked for written confirmation of no. Until this is answered, the scope of the phase awaiting sign-off is not actually agreed | Brian, Tahsin | Before anything else |
| 2 | Confirm to Farid in writing that Phase 2 does not touch the accounting system or produce SOA, which is exactly what he asked to have confirmed, and that Phase 4 is where that work sits | Brian | 5 Aug |
| 3 | Reconcile the two phase numberings into the canonical set in this document, and supersede the implementation update as a source of phase numbers | Brian, Tahsin | 5 Aug |
| 4 | Get the revenue-share exception list compiled and in front of Rajaa. This is Open Decision 6 and it is what her signature is actually waiting on | Amr, Faras compiles | Urgent |
| 5 | Joint session with Thrishan Padayachi and Tahsin Ali: confirm what Odoo reads from the Data Lake, and test whether pulling Phase 4a and 4c ahead of Phase 3 is viable | Brian | 5 Aug |
| 6 | Pressure-test the one-week integration estimate in the Odoo project plan against what Phase 4 actually requires | Brian, Thrishan | In session |
| 7 | Give Rajaa dates for Phase 2 and Phase 4 that she can report, once the session has happened | Brian | After 5 |
| 8 | Add the Data Lake relationship to the Finance sign-off document as an addendum, so the Odoo question stops being reopened verbally | Brian | After 1 |
Sourcing rule for this document
Everything here traces to the Problem Statement and Plan, the PRD, or the Finance sign-off document. Claims that appeared only in the June implementation update, including a Phase 2 push into the Data Lake, have been removed rather than carried forward, because that update is not the source of truth and is superseded on phase numbering.