- Add migration for consolidation approvals table and status enum
- Create ConsolidationApprovalService to handle approval logic
- Implement repository for managing consolidation approvals
- Add entity for consolidation approval with necessary fields
- Develop frontend components for displaying and managing consolidation approvals
- Create tests for consolidation approval service to ensure correct behavior
- Add migration for consolidation approvals table and status enum
- Create ConsolidationApprovalService to handle approval logic
- Implement repository for managing consolidation approvals
- Add entity for consolidation approval with necessary fields
- Develop frontend components for displaying and managing consolidation approvals
- Create tests for consolidation approval service to ensure correct behavior
- Added support for viewing and managing consolidated bookings in BookingRequestDetailPage.
- Enhanced BookingRequestsPage to display paired bookings in a single row.
- Introduced pairedDecision method in bookings service to handle decisions for both halves of a consolidated pair.
- Updated contracts service to include methods for manual consolidation of odd-20ft bookings.
- Created new components for selecting and editing consolidation partners.
- Added tests for paired decision logic and manual consolidation scenarios.
- Updated UI to reflect changes in booking handling and provide user feedback for odd container counts.
Confirmed live 2026-08-17: buyer profiles store just the sub-city name
("Bole", "Arada") as their woreda, never the source CSV's specific
example-woreda name ("Bole Woreda 01") — hit for three different
buyers in a row (Bole, Arada, Lemi Kura) before any got past this
check. Since the CSV lists exactly one representative woreda per
Addis sub-city, alias the bare name to that same code instead of
waiting on a fuller table — use what's already been supplied first.
Lemi Kura itself isn't in the source CSV at all (one of Addis
Ababa's newer sub-cities) — still needs its real code from MoR.
The switch clears the registration but not the tax number, so the company step
reopens with the old TIN and RHF re-seeds the field when the profile refetch
lands. A TIN typed before that arrived was silently replaced by the stored one
and the lookup ran against the wrong number.
The spec now waits for the rehydrated VAT value, then asserts the field holds
what it typed before waiting on eTrade.
A resumed onboarding asked for the per-role business licence again and refused
to submit until it was uploaded a second time, however many were already on
file. `getInfo` never populates `companyProfiles[].licenseFiles`, and the
wizard validates against exactly that — so every profile looked empty, while
`markOnboardingComplete` would have accepted the application as it stood.
Validation now reads `licenseProfiles[].uploaded` from the onboarding
requirements: the server's own verdict, already fetched by the step, and the
same source the API enforces on submit.
Reachable today by anyone who resumes onboarding after a licence upload, and by
every company that switches back to eTrade registration — which is where the
e2e suite hit it.
Five journeys, one file each, every one of them crossing from the portal into
the backoffice and cross-checking the database rather than the screen:
- ethiopian eTrade verified, Fayda, approved, contract wizard reachable —
including the dead end a TIN with no trade licence is for an
ordinary company
- investor foreign investment licence: nothing on file at eTrade, typed
registration, passport identity, per-role licence still owed,
and the backoffice's manual-entry badge and banner
- cooperative no foreign option, no freight-forwarder role, the co-operative
document set, no licence cards, its own badge and banner
- switch_back settings → switch to eTrade → registration cleared, company
pending, wizard reopened on the company step → re-run through
eTrade → the flag is gone from the backoffice
- guards the refused combinations, and the mid-wizard un-tick that has
to clear the typed registration
Replaces the old onboarding.cy.ts (removed a commit earlier by accident of a
staged deletion): it drove a wizard shape that no longer exists — Fayda before
the company step, a "Personnel" step — so it could only ever have been red.
Notes for whoever edits these next. Attach files to the FIRST empty dropzone,
never by index — SmartFileInput removes the input once a file is on it. Resolve
the company from the database after any cross-origin hop, never from module
state: Cypress re-evaluates the spec bundle and Date.now() with it, which is
what latestJourney's run-stamp cutoff is for. And the deliberate eTrade 400 is
ignored as an uncaught exception — the portal handles that outcome on screen
but leaves the rejected request unhandled at the promise level.
Every TIN resolved to the same canned company, so the premise of both manual
routes — eTrade holds nothing — could not be reached at all, and neither could
the dead end an ordinary company hits on a TIN with no trade licence.
The answer now follows the TIN's leading digit, so a spec picks its outcome by
picking its number and no per-spec stubbing is needed: 9… returns a
registration with no businesses (the co-operative / investor case, where the
API's resolveCompanyData finds no licence), 8… 404s the registration lookup
entirely, anything else behaves as before.
The Company, Owner, Contact and Power of Attorney tabs had drifted from the
onboarding wizard while the manual-registration routes were added, and each
divergence locked somebody out of their own account:
- VAT was validated as 10-or-11 digits here and by onboarding's rule there. A
foreign company's VAT is its own tax authority's and a co-operative's follows
neither, so the stricter copy failed every save on the tab, not just the VAT
field. The schema now reuses onboarding's, with a test pinning both rules.
- Fayda's phone claims are normalized on read, as the wizard does — the
registry holds local numbers that neither the form nor the API's
@IsValidPhone() accepts.
- The eTrade manager is shown read-only, because that record is exactly what
the backoffice checks the company against; leaving it editable let a customer
overwrite the value under review.
- A co-operative's per-role licence cards are hidden on the Documents tab. The
API lifts the requirement, so the slots could never be filled or cleared.
Both manual-registration routes exist for one reason — eTrade holds no record
to fetch — so leaving one is the same act whichever it is. A co-operative that
has since taken out a trade licence had no way out at all: the flag is chosen
in the wizard, and an onboarded company can no longer reach it.
revert-to-etrade now accepts either flag and strips both, and a co-operative's
ACTIVE roles go back to Pending with it: those approvals were granted without a
per-role business licence, because a co-op owes none, and the moment it stops
being one that licence is due. Rejected, suspended and blacklisted roles are
left alone — promoting a blocked role to "awaiting approval" would launder a
staff decision away. An investor's roles are untouched; their licences were
always due and already reviewed.
Switching INTO a route stays with the wizard's nationality/role step, which
owns the mutually-exclusive rules; a second entry point would restate all three.
The Region select called setValue without shouldDirty. `region` is an
eTrade-bundle key, and stepPayload sends those only when the customer changed
them this session — so for the two routes that type their address by hand (a
co-operative, a foreign investor) the region was dropped on every save while
zone, woreda and kebele went through, because those are registered inputs and
are dirty by construction.
Found by the new onboarding e2e suite: both manual-route companies finished
onboarding with zone/woreda/kebele on file and region empty.
Going back in the wizard and un-ticking co-operative or investment licence used
to write the flag and nothing else. The registration the customer had typed
stayed on the company row, so `hasRegistrationDetails` still read as a passed
eTrade lookup, resume dropped them at their furthest step rather than the
company one, and the application could be finished on unverified data with no
flag left on it for the backoffice to show.
That transition now costs what the settings switch costs: the eTrade-sourced
columns and the manager captured beside them are cleared, and onboarding drops
back to the company step so the TIN actually goes through eTrade. Both the
reset payload and the attribute strip are now shared with
`revertToRegularCompany`, which did this correctly already.
Two kinds of customer reach approval with a registration nobody checked: a
co-operative union or farm, which holds no trade licence, and a foreign
investor, whose licence comes from the Investment Commission rather than the
trade registry. Both were reviewed on screens that read exactly like an
eTrade-verified company's, with only a small Registration field naming the
difference.
They now carry an orange "Manual entry" badge in the customers list and beside
the company name, and their overview opens with an alert saying the name,
registration and address below are the customer's own statement — pointing the
reviewer at the paper that stands in for the licence (the co-operative
certificate, or the investment licence) before approving. Approval itself is
not blocked.
A company that ticked the investment-licence box by mistake, or that has since
been registered with the trade registry, had no way back — the flag is chosen
once, on a step onboarding never returns to.
The Company tab now carries a Registration source card for those companies.
It is a re-application rather than a settings edit, so the confirmation says
so outright: the typed registration is cleared, the company returns to pending
and the wizard reopens on the company step, while documents, owner and contact
details stay. Hidden for everyone else, and disabled while a profile change
request is under review — switching then would strand it.
A foreign company can now say it operates on an investment licence, on the
same step as its nationality and roles. The box only appears for a foreign
company, and moving the nationality answer back to Ethiopian drops it — the
API refuses both pairings.
The company step's eTrade gate now reads `manualRegistration`
(co-operative OR investment licence): the TIN lookup still runs, but finding
nothing is an expected outcome rather than a blocker, and the registration
section is typed instead. What stays keyed to `cooperative` alone is the
per-role business licence — an investor holds one, a co-operative does not —
so the licence cards and their validation are unchanged for investors.
Also carries the client plumbing for the revert endpoint the settings card
uses next.
A foreign company licensed by the Ethiopian Investment Commission is not on
the trade registry, so eTrade holds no record for its TIN and the lookup the
company step is built around returns nothing. Those customers could not get
past onboarding at all.
They now take the same route a co-operative does: an `investorLicence` flag in
`attributes`, and `applyEtradeSourcedFields` skips the eTrade re-check for any
company `usesManualRegistration` covers, so the registration they type is
persisted as sent instead of 400'ing "no registration found for this TIN".
Unlike a co-operative they still hold a business licence per operational role,
so that requirement is untouched, and the foreign document set already asks for
the investment licence itself — no new set.
Only a foreign company may carry the flag, and never alongside the
co-operative one: the two resolve to different document sets.
`POST /companies/onboarding/revert-to-etrade` gives it back. It clears the
typed registration rather than keeping it — the wizard treats a populated
registration block as a passed lookup, so leaving it would walk the customer
straight past the eTrade step the switch exists to reach — and returns the
company to pending, since an approval granted against typed data must not
carry over to a record that now claims to be eTrade's.
