Arabic-English role training and hypercare plan for Saudi Odoo teams

Start with a role, entity and language matrix

List each role by legal entity, branch, operating language, Odoo company access and responsibilities. Separate accounts payable, accounts receivable, tax review, payroll, purchasing, inventory, sales, point of sale, branch management, system administration, integration support and executive approval where those roles exist.

For each role, record the workflows to perform, exceptions to recognise, records to approve, Arabic documents to inspect, English supplementary material needed and the person authorised to assess competence. Include the client's product owner and local champions as participants in design, not only as attendees after materials are complete.

The matrix drives the training plan and the test plan. A user should not receive access that has not been exercised, and a workflow should not be marked trained merely because a presentation covered its menu path.

Validate access profiles before teaching the workflow

Create test identities that represent actual role and company combinations. Confirm record rules, company restrictions, approval rights, journal access, accounting posting rights, credential boundaries and export permissions. Users should see the records required for their work without inheriting an administrator shortcut.

Test both the permitted action and an action that should be denied. For example, a branch user may need to process local orders without changing another entity's sales journal, and an operational user may create an adjustment request without approving its fiscal submission. Record expected and actual behaviour with the role owner.

Language preference is part of usability, not a security control. Arabic and English users with the same role should have equivalent functional rights unless the responsibility matrix says otherwise. Any difference requires a documented business reason and test.

Build role curricula around complete work scenarios

Finance training covers master-data review, VAT treatment, receivables and payables, invoice and note processing, reconciliation, period review and escalation. Include standard and simplified invoice scenarios where the role uses them, the separation of VAT and Zakat returns, and the evidence required before declaration or submission by the responsible adviser.

Operations training follows real purchasing, sales, stock, project, manufacturing or service journeys from initiation to financial impact. Users practise approvals, exceptions, returns and adjustments, and see how their data affects the invoice and downstream reports. Branch and entity variation is demonstrated with their own scenarios.

Administrator and support training covers configuration boundaries, user access, sales-journal onboarding responsibilities, environment identification, integration monitoring, redacted evidence collection and escalation. OTP and CSID handling is taught through the approved responsibility process without placing secrets in exercises or screenshots.

Write Arabic and English SOPs with the same controls

Give every SOP a stable ID, role, entity, process owner, language, version and approval date. Use numbered steps that name the starting record, required inputs, action, expected result, control point, exception route and evidence to retain. Screenshots support the instruction rather than replacing the expected business outcome.

Prepare the Arabic SOP as professional business guidance, not a word-for-word conversion of English menu labels. Keep technical tokens such as ZATCA, XML, CSID, Sandbox and Production consistent and legible. Then review both versions together for responsibility, sequence, approvals and exception handling.

A bilingual reviewer and the process owner approve content parity. Where an Odoo screen label differs by interface language, record the exact current label used by learners and recheck it against the agreed Odoo 19 environment. Outdated screenshots are replaced through document change control.

Test Arabic invoices and notes as a practical exercise

Reviewed 5 November 2026. Human-readable invoices and associated notes must be in Arabic; additional languages are allowed. Technical XML elements can be English. The Odoo 19 Saudi localisation and ZATCA's detailed guideline provide the product and regulatory starting references.

Give learners representative standard, simplified, credit-note and debit-note scenarios. They create or review the transaction, generate the intended customer output and inspect Arabic shaping, fonts, alignment, headers, footers, page breaks, totals, party identifiers, addresses, VAT numbers, reasons and original-invoice references.

Include long Arabic names and descriptions and mixed-direction tokens such as Odoo, ZATCA, XML and product codes. Compare the human-readable output with the source transaction and structured XML. Phase 2 submission is XML; PDF/A-3 generated through Send is reviewed separately as a sharing format with embedded UBL 2.1, not as the clearance payload.

Assess competence through observed work

Each assessment identifies the role, scenario, starting data, required steps, expected output, control checks and assessor. The learner performs the work in a controlled training or test environment and explains how they would handle a relevant exception. Attendance and quiz recall alone do not demonstrate operational competence.

Finance assessments can include reviewing a tax scenario, correcting party data through the approved route, processing a note and reconciling the result. Operations assessments can include completing a purchase or sales flow, handling a return and explaining stock or service impacts. Administrator assessments can include granting approved access, identifying an environment and escalating a redacted failure pack.

Record pass, targeted retraining or follow-up evidence with the assessor and date. Any internal completion or certification label must state that it is programme-specific competence signoff, not an Odoo-issued qualification, ZATCA endorsement or statutory approval. Users who have not yet demonstrated a critical task receive supervised practice and a named follow-up owner.

Prepare champions as first-line process owners

Select champions for their process knowledge, communication and availability, not language alone. Give them deeper scenarios, defect triage, SOP maintenance and coaching practice. They should understand when to solve a data or usage question and when to escalate a configuration, integration, statutory or credential issue.

Champions help review Arabic and English materials, gather role-specific questions and observe early operational work. They do not become uncontrolled administrators by default. Their access remains role-appropriate, and their support decisions follow the same change and approval controls.

Create a champion handover for each entity or major function. It names coverage, backup, recurring review, common issues and the route to Oakland or another agreed support owner during hypercare. This reduces dependence on one individual without hiding accountability.

Schedule learning around rehearsals and real release responsibilities

Sequence foundational access and process learning before scenario practice, then use migration rehearsals and invoice acceptance as applied exercises. Users work with production-shaped data and documents where appropriate so that training exposes real questions before cutover.

The schedule records participant availability, Gulf working-hour overlap, language group, role owner, environment, material version, assessor and follow-up. It avoids fixing an arbitrary elapsed duration before the number of roles, entities, scenarios and learner readiness is understood.

Use rehearsal outcomes to revise learning. Repeated data errors may require a master-data exercise; an unclear rejection path may require a support simulation; Arabic page overflow may require both a template correction and a new document-review exercise. The second migration rehearsal can then confirm that the revised process and guidance work together.

Run hypercare with bilingual triage and visible ownership

Publish one intake route with severity definitions, business impact, entity, role, language preference, scenario ID and required evidence. Users can describe the problem in Arabic or English while the underlying requirement and defect IDs remain stable. Screenshots and logs follow redaction rules for credentials and personal data.

Triage distinguishes training, source data, master data, configuration, migration, Arabic rendering, integration, provider and statutory-review questions. Each category has a named resolver and escalation route. A support response does not silently change tax treatment, production credentials or invoice templates without the required approval.

Review recurring questions and actual process usage with champions. Are invoices reaching their expected final status, are receipts and deliveries completed, are adjustments referenced correctly and are users avoiding unapproved side spreadsheets? The answers guide targeted coaching and controlled corrective work.

Exit hypercare on evidence and complete the handover

Hypercare exit criteria cover critical defects, migration exceptions, invoice and integration status, reconciliation, role competence, SOP completion, recurring questions and support ownership. A calendar date alone is not sufficient, and new optimisation is not used to disguise a release defect.

The handover includes role and access profiles, approved Arabic and English SOPs, assessment results, champion coverage, open-item owners, integration and journal runbooks, template versions and acceptance evidence. Residual training needs receive dates and accountable managers once operationally agreed.

Conduct a final bilingual review with process owners. Confirm that users can find the current SOP, complete their critical workflow, recognise an exception and reach the right support owner. Record any restrictions explicitly and carry them into the continuing support arrangement.

Label Odoo tours, OXP2026 sessions and version demonstrations accurately

Odoo tours can help learners navigate a feature, but they do not replace customer-specific SOPs, role access testing or observed competence. Select only tours that match the agreed Odoo 19 workflow and supplement them with the organisation's data, controls and exceptions.

Public OXP2026 sessions on role and access-based training, Arabic and RTL report-engine limitations, workstreams and governance and rehearsals and adoption are educational delivery material only. They are not Saudi regulatory evidence, Oakland references, customer stories or endorsements.

Odoo 20 report-engine or other demonstrations are separate educational context and are not presented as Odoo 19 capability. Official Odoo 19 Saudi fiscal localisation, Saudi payroll localisation and ZATCA sources control product and regulatory statements; the organisation's own assessments control training acceptance.