01
Read the chapter
Move page by page with the arrows. Each page gives you the click path, the action, and the evidence to check.
28 pages6 chapters← →
Systems Egypt · Delivery operations
Click-through manual.
Delivery Tracker, from demand to handoff.
A practical, screen-by-screen guide for the live Odoo workspace. Follow the click path, do the step, check the evidence, move on.
Simple. Limited edition.28 pages · 6 chaptersUse ← → to move
Orientation · 01Manual
Three ways to use this manual.
Read it end to end, take the guided tour, or print the page you need. Every operational screen links back to the live Odoo record.
02
Take the tour
Seventeen stops across the live screens. Start at the home screen and follow one clean chain to finance.
17 stops
03
Print the reference
Print all 28 pages to landscape PDF. Overlays disappear; screenshots, routes and the first-week checklist stay.
16:9
Recommended 45-minute walkthrough: 10 minutes on core delivery, 20 on augmentation, 10 on the operating rhythm, 5 on decisions.
G contents · T tour · P printOrientation · 02The shape of it
One request. One version. One chain of custody.
The app is a record of decisions, not a chat about them.
By the time a person starts work, the request, version, approval, assignment, project, booking and commercial packet should all point at the same story.
What it does not replace: judgement, client relationship, commercial policy, or a signed contract.
15request states, each with an owner and a timestamp
Dubai asks
AUG reference, sponsor, cost centre, need-by, role lines.
Egypt responds
Full, partial or none. Validity creates a time-bound hold.
PM mobilises
Named person, project, readiness, activation gate.
Finance records
Service acceptance, exit evidence, protected packet.
8assignment states
5activation checks
1booking per assignment
0side spreadsheets
Manual rule: if a step cannot be evidenced in Odoo, it is not finished.
Core delivery · 01Where am I?
The Delivery app is the spine.
Four families of work, one record trail. Click a card to jump to the chapter that explains it.
Plan & deliver
Projects, commitments and the work in flight.
ProjectsDeliverablesTasksRAIDStakeholdersHypercare
Jump to core delivery
Staff & approve
Demand, supply and the decision in between.
RequestsProposalsApprovalsAssignmentsReadinessResources
Jump to augmentation
Prove & control
Coverage, acceptance and the exit trail.
CoverageService periodsChangesExitExceptions
Jump to coverage
Commercial edge
Restricted terms and the finance packet.
Finance handoffsRateCurrencyPacketsReconciliation
Jump to Finance
Core delivery · 02Worked example
Follow one record from demand to packet.
This is the intended chain. Click a step to see who acts, what gets written, and why it matters.
Core delivery · 03Who does what
Five roles. One handoff chain.
Role 01
Dubai demand owner
Turns a business need into a request that Egypt can answer without guessing.
Owns
- Sponsor, cost centre, budget reference.
- Need-by and commercial context.
- Demand approval and branch start confirmation.
Good looks like
- Real dates and a named receiving owner.
- One request per demand, not per conversation.
- Approval on the current version.
Boundary
- Does not pick the person.
- Does not see the restricted finance packet.
Role 02
Egypt fulfilment owner
Acknowledges demand, records gaps, proposes supply, and protects capacity with a hold.
Owns
- Acknowledge, clarify, propose, release.
- Proposal outcome, dates and validity.
- Supply-side readiness and branch release.
Good looks like
- Partial is stated plainly, with the gap.
- Hold expiry is real, not a maybe.
- Clarification happens without duplicating the request.
Boundary
- Does not set sell rate or currency.
- Does not approve the Dubai budget.
Role 03
Project manager
Turns an approved supply commitment into a named person doing real work on a real project.
Owns
- Project, deliverables, tasks and RAID.
- Assignment, readiness and mobilisation.
- Hypercare, change and exit evidence.
Good looks like
- Project linked before activation.
- Mandatory readiness done or exception approved.
- Exit checks before capacity is released.
Boundary
- Does not replace branch approval.
- Cannot make an incomplete gate pass by saving.
Role 04
Finance
Owns the protected commercial packet and the evidence that the numbers match the service.
Owns
- Rate, currency, amount and basis.
- Packet revision, accepted FTE and terms version.
- Sent, acknowledged, reconciled, exception owner.
Good looks like
- One clean packet per accepted period.
- Duplicate is flagged and explained.
- FX set before the first live quote.
Boundary
- Finance access is model-level, not a branch rule.
- No rate history outside handoff records.
Role 05
Administrator
Keeps the workspace coherent, secure and recoverable. Configuration is not business approval.
Owns
- Groups, fields, views, actions and menus.
- Backups, Studio exports, sequences.
- Technical verification and access tests.
Good looks like
- Membership matches the real role.
- Sample data cleaned before live use.
- Branch rules tested with real users.
Boundary
- Does not approve demand or supply.
- Does not act as a human control.
Core delivery · 04Start here
Start every engagement with a project.
The project is the anchor for deliverables, tasks, RAID, hypercare, assignments and bookings. If it is not linked, it is not delivery.
- 1Create or open the project.
Reference auto-fills as SEG/2026/####. - 2Set the operating context.
Client, PM, stage, health, start/end, go-live and governance cadence. - 3Add weighted deliverables.
Due date, acceptance criteria, owner, billing amount and client sign-off. - 4Accept, don't just finish.
Accepted deliverables stamp completion and recalculate progress.
Progress is computed, not typed. It is accepted weight ÷ total weight. Health remains a human judgement.
InitiationDiscoveryDesignBuildSITUATCutoverHypercareWarrantyClosed
Live screenProject · form
Core delivery · 05Governance
Log the risk before it becomes a surprise.
Risk, Assumption, Issue, Dependency. One item per record, with a named owner and a response date.
3Medium
6High
9Critical
2Low
4Medium
6High
1Low
2Low
3Medium
Score
Probability × impact
Low = 1 · Medium = 2 · High = 3
Severity
≤2 Low · 3–4 Medium
5–6 High · ≥7 Critical
Escalated is a status, not an email. Move the item and update the owner, response date and mitigation.
Live screenRAID log
Core delivery · 06Post go-live
Hypercare is a workspace, not a stage label.
A plan carries the support window, model, lead, team, exit criteria and client sign-off. Issues carry severity, SLA and resolution evidence.
| Severity | Response clock |
|---|---|
| S1 | 1 hour |
| S2 | 4 hours |
| S3 | 24 hours |
| S4 | 72 hours |
Clock quirk: the SLA anchor is 09:00 on the logged date, not the actual log time. Nights and weekends count. It is a response clock.
Exit gate
Exit criteria met + client sign-off. Closed stamps actual exit; reopening keeps that history.
Live screenHypercare plans
Core delivery · 07Read the portfolio
Four questions the cockpit answers.
Are we on track?
Health is manual. Progress is accepted weighted deliverables.
What is blocked?
Open tasks, critical RAID and hypercare breaches.
Who is overloaded?
Allocation by person, project, period and percentage.
What needs a decision?
Pending approvals, expiring holds and exit checks.
Interactive, not prescribed. Use list, kanban, gantt, calendar and pivot. The named RPT-12–16 layouts are not built.
Filter At Risk / CriticalGroup by PMGroup by stagePivot by client
Live screenProjects · kanban
Augmentation · 01Click path
Raise demand once. Make it answerable.
Delivery→Augmentation→Staffing Requests→New
Start with the Request header. The project can be pending, but the demand context cannot be blank.
Requesting / supplying unitDubai asks, Egypt fulfils.
Receiving ownerWho must respond next.
End client & sponsorContext for client-facing demand.
Cost centre / budget ref.Commercial traceability.
Need-by dateDemand date, not start date.
Role lineAt least one line before submission.
Soft validation: submission records missing items and the next-response owner. It does not hard-block an incomplete request.
DraftSubmittedClarificationAcknowledgedFeasibilityProposal sentPending approvalApprovedMobilisingActiveOn holdOffboardingClosedDeclinedCancelled
Live screenStaffing requests · form
Augmentation · 02The commitment
The header is demand. The line is the commitment.
Each role line carries its own quantity, capacity, dates, timezone, work mode, location and need-by. This is what supply is responding to.
Requested FTE
quantity × capacity % ÷ 100Example
1 position at 100% = 1.0 FTE
2 positions at 50% = 1.0 FTE
Clarify
Use the request state and note.
Do not duplicate the record.
- Timezone and need-by are now on the line — use them.
- Approved proposal links at request and assignment level.
- Missing items and next response owner sit on the request.
The SDD Alignment group on the form is not extra work; it is the audit trail for the gate.
Live screenStaffing request · role lines
Augmentation · 03Supply answer
Respond with an outcome, not a maybe.
Egypt records a proposal against the request version: offered FTE, dates, gaps and validity. The outcome is explicit.
FullAll requested FTE and dates covered.
PartialSome supply; state the gap.
NoneNo viable supply; close the loop.
Draft or pending assignment→provisional hold→14 daysor earlier proposal expiry
- Holds count in capacity until they expire or are released.
- Cron 24 expires provisional holds and recomputes overlaps.
- Accepted proposal links to the request and the assignment.
Known gap: proposal lines are not a separate model yet. The header carries offered FTE, dates, outcome, gaps and validity.
Live screenSupply proposals
Augmentation · 04Decision record
Right branch. Right version. Right decision.
Approvals are recorded against the request and its version. An approval on an old version is history, not authority.
Dubaidemand
Egyptrelease
Clientif required
Financenot gated yet
- Version-stamped: the current-version flag is maintained by automation.
- Self-approval is flagged, not silently ignored.
- Delegation and decision time are recorded.
- Declined approvals surface in Exceptions — there is no unified register.
Important: prior request versions are not snapshotted. If the commitment changes, re-check the decision set manually.
Live screenBranch approvals
Augmentation · 05Placement
A named person. A named project. A named start.
Augmentation→Assignments→New
Create the assignment from the request line or the approved proposal. Request, role, proposal and hold derive from that link.
Do this
Resource, project, supervisor, dates, capacity, readiness.
Then
Mobilise. Do not jump to Active.
- Resource without a login is still bookable.
- Readiness: mandatory item, owner, due date, evidence or approved exception.
- One booking per assignment is updated, not versioned.
DraftPendingApprovedMobilisingActiveOffboardingEndedCancelled
Live screenAssignments · gantt
Augmentation · 06Training simulator
Five checks before capacity goes live.
Try the gate. In live Odoo the check is server-side; this simulator only teaches the order.
Mobilising · 5 checks open
Activation will be blocked and the reason written to blocked_reason.
Failure does not lose the form. The assignment returns to Mobilising with a reason; fix the missing check and retry.
Live screenAssignment · activation gate
Augmentation · 07Illustrative calculator
FTE is not headcount.
The line asks for FTE. Two half-time people can fill one full-time position. Do not count them as two positions.
1.0requested FTE
1.0filled FTE
1positions
Filled exactly. Each assignment counts once; coverage is capped at requested FTE.
Not time-sliced: overlaps are flagged by allocation, but coverage still sums approved, mobilising, active and offboarding assignments once.
Live screenResource allocation
The formula live Odoo uses
Filled FTE = approved + mobilising + active + offboarding, each assignment once, capped at requested. Positions = fulfilled FTE ÷ line capacity, rounded up, capped at quantity.
Augmentation · 08Close the loop
Capacity is not released by hope.
Service period
Accept what was delivered.
Pending → Accepted or Disputed. Record accepted/disputed FTE, evidence and client decision date. A dispute needs an owner and due date.
Change
Approve, then apply.
Extension, replacement, early release, capacity or cancellation. Proposer, notice, effective date and impacts are recorded.
Exit
Offboard before you release.
Access revoked and client acknowledged. Until both are true, the booking stays active and the reason is written to readiness.
Known gaps: approved changes apply immediately; there is no future-dated segment or automatic approval re-route.
Live screenService period · form
Augmentation · 09Restricted
Commercials live behind one door.
Finance HandoffsFinance group only
The model has no ACL for ordinary internal users. The menu is restricted too.
Rate · currency · amountPlanned commercial value.
Basis · SOW referenceWhat the number means.
Accepted FTE · terms versionWhat was delivered.
Packet revision / keyTraceable version.
Sent · acknowledgedDelivery evidence.
Reconciled · exceptionFinance close.
Duplicate handoffs are flagged, not blocked. A second packet on the same period gets a new revision but a duplicate warning. Explain it; do not delete history.
Not built: split internal/external terms, effective-dated rate history, counterparties, proration, handoff approvals. FX rates are still 1.0 — set them before quoting.
Live screenFinance handoff · form
Augmentation · 10People & signals
People, not seats. Signals, not promises.
Resource register
A bookable person.
Resource key, home unit, role, optional user, email, active and notes. A login is optional; capacity is not.
Notification log
An in-app record.
Recipient, channel, sent time, subject, body, event key, delivery state, last error and acknowledgement.
- No scheduling calendar is linked to the resource yet.
- No outbound delivery: there is no mail server; notifications do not retry.
- No Resource Manager group yet; access is still admin-heavy.
A notification record is not proof of delivery. It is evidence that the system recorded an event.
Live screenResources
Augmentation · 11Field notes
Where the edge cases go.
These are not exceptions to the process. They are the process telling you to look.
Counts until it expires.
Draft or pending assignments create a provisional hold — 14 days fallback, or the linked proposal expiry if earlier. Cron 24 releases.
Do: check expiry before promising capacity.
Flagged, not time-sliced.
The allocation engine flags an overbook, but coverage sums assignments without partitioning the period.
Do: resolve the overlap in the allocation view.
A second packet is visible.
Two handoffs on the same period get a duplicate flag and a new revision. There is no database uniqueness constraint.
Do: explain the revision; never delete history.
Exceptions is a filter.
Declined approvals surface in Exceptions. There is no unified exception register for every edge case.
Do: record the reason on the decision.
It is still in the database.
Records prefixed Sample -, sample projects and allocations against uid 2 remain.
Do: clean before live use.
All rates are still 1.0.
EGP, USD, AED, SAR, EUR, GBP and PKR are active, but no real rates are set.
Do: set rates before the first quote.
Run it · 0115 minutes
Run the week in fifteen minutes.
Same order every Monday. One screen, one owner, one decision. Expand a step for what to look for.
00–02Portfolio healthProjects
Look for: At Risk, Critical, past go-live without hypercare. Decide: which project needs escalation this week.
02–05Deliverables dueDeliverables
Look for: due this week, submitted but not accepted. Decide: who chases acceptance.
05–07RAIDRAID log
Look for: Critical/High open, stale response dates. Decide: mitigate, escalate or close.
07–09HypercareHypercare issues
Look for: open S1/S2, breaches, plans past exit. Decide: war-room focus and exit readiness.
09–12ApprovalsApprovals
Look for: pending on current versions, old-version approvals. Decide: who signs before the next mobilisation.
12–15Coverage & holdsCoverage / Allocation
Look for: gaps, overbook, holds expiring. Decide: release, rebook or escalate supply.
Rules of the room
No status round-robin.
- Open the record, not a slide.
- Name the owner and the next action.
- Stop when the decision is made.
If you only do three things: clear the Critical RAID, unblock pending approvals, and release or renew expiring holds.
15minutes
6checks
1owner
1decision log
Run it · 02Cadence
Close the period with evidence, not a chase.
Daily
Hypercare triage- Open S1/S2 first.
- Update resolution evidence.
- Check plan health.
Weekly
Delivery cockpit- Health and deliverables.
- RAID and approvals.
- Coverage and holds.
Monthly
Service close- Accept or dispute periods.
- Clear dispute owners.
- Reconcile handoffs.
Stage gate
Exit review- Exit criteria met.
- Client sign-off.
- Access revocation.
Month-end evidence close
- Every delivered period accepted or disputed.
- Disputes have owner and due date.
- Every handoff packet sent/acknowledged.
- Reconciliation and exceptions signed off.
- Changes applied or explicitly deferred.
No evidence, no close. If the service period is not accepted, the finance packet is not ready.
Live screenService periods
Run it · 03Diagnostics
When it will not move.
1 State2 Version3 Gate4 Booking5 Packet
Assignment will not activate
Check: readiness, Dubai approval, Egypt approval, client approval if client-facing, project, branch start acknowledgement. Fix: clear the specific blocked reason, save, retry.
Booking will not release
Check: assignment in Offboarding/Ended, access revoked, client acknowledged. Fix: complete the exit checks; capacity is intentionally held until then.
Coverage looks wrong
Check: line selected, assignment states, capacity, and cron 25. Fix: refresh coverage; overlapping bookings are flagged but not time-sliced.
Hold will not clear
Check: hold expiry, linked proposal expiry, cron 24. Fix: cancel the draft assignment or wait for expiry; do not ignore the hold.
Approval is missing
Check: request version and current-version flag. Fix: obtain a decision on the current version; an old approval is history.
Handoff is flagged duplicate
Check: same period and packet revision. Fix: explain the new revision, keep both records, reconcile explicitly.
No notification arrived
Check: notification log, delivery state and last error. Fix: use the in-app record; there is no mail server or retry yet.
Gantt or form is stuck
Check: wait for Odoo to paint, then refresh. Fix: use the list view at narrow widths; the allocation gantt returned an error there.
Run it · 04Be precise
What is live — and what is not.
Live & enforced
Operational core
- 11 models and 19 workspaces.
- Request, proposal, assignment and service states.
- Hold expiry and coverage crons.
- Activation and exit gates.
- Finance model ACL and menu restriction.
- In-app notification log.
Use these without caveat.
Partial
Use with a human check
- Request version snapshots.
- Per-assignment branch approvals.
- Duplicate constraints.
- Time-sliced coverage.
- Change approval re-routing.
- Named RPT-12–16 reports.
- Outbound delivery and retries.
The screen shows the gap; the manual names it.
Not built
Do not assume it
- Branch record rules.
- Split internal/external terms.
- Proposal-line child model.
- Database unique keys.
- Milestone and renewal reminders.
- Finance approval gate.
- UAT-15–27.
These are decisions and security work, not UI polish.
Do not call it production-ready until: branch rules are tested with real users, sample data is removed, FX is set, and business UAT is signed off.
Adopt · 01Saved locally
Your first week, in twelve checks.
Before day one
Day one–two
Week one
Before go-live
0%
First-week readiness
0 of 12 complete
Your checks are saved in this browser only. Printing keeps the state.
Adopt · 02Print this page
The route map.
Base:
https://systemsltd-1.odoo.com| 01 | Delivery home | /odoo |
| 02 | Projects | action-228 |
| 03 | Deliverables | action-231 |
| 04 | Tasks | action-232 |
| 05 | RAID log | action-233 |
| 06 | Hypercare plans | action-239 |
| 07 | Hypercare issues | action-240 |
| 08 | Allocation | action-245 |
| 09 | Staffing requests | action-247 |
| 10 | Assignments | action-248 |
| 11 | Resources | action-249 |
| 12 | Service periods | action-250 |
| 13 | Finance handoffs | action-251 |
| 14 | Coverage | action-264 |
| 15 | Supply proposals | action-265 |
| 16 | Approvals | action-266 |
| 17 | Readiness | action-267 |
| 18 | Changes / Exit | action-268 |
| 19 | Exceptions | action-269 |
| — | Hypercare detail | action-240 |
15 request states8 assignment states5 activation checks10 stage gates1/4/24/72h SLA2×50% = 1 position
Bookmark the workspace, not each record.Close · 28End of manual
Keep the chain intact.
The system is only as true as the record you leave behind.
One request. One version. One close.
- Open the record. Do not manage delivery from a side message.
- Use the gate. If it is blocked, fix the missing evidence.
- Close with proof. Acceptance, exit checks and the packet.