Answers to
your questions

Yes. Each product can have a bill of materials with several levels — a semi-finished product feeding a higher one — with material substitutes and a quantity per unit, plus the operations and work centres for each step. We configure that structure against your real product tree and verify the levels by running production, not on paper.

Both, and that is the point: the standard cost is built from the bill of materials and expected operation time for comparison and pricing, while the actual cost is built from what was really consumed and the time logged on operations. The gap between them shows in a per-order variance report — the first indicator that exposes a quantity or time problem rather than a price one.

Yes. Materials can be sent to an external factory and the finished product received back, with the sent and received quantities tracked and the subcontracting cost recorded; goods at the vendor show as entrusted stock rather than as in-house inventory. We configure this route where part of production genuinely happens outside your plant.

Yes. Each karat is its own item with its own balance and price, and karats can be converted with the loss recorded.

Yes. Price lists are tied to the day’s rate, so a single update reprices the catalogue.

Yes. We enable e-invoicing and ZATCA requirements and map items to the correct tax.

No. We are a systems company: not a bank, a finance company, a payment service provider or an investment firm, holding no licence from any regulator, representing none and handling no licensing procedures. What we do is build the system that runs and documents the operation, while licensing, regulatory compliance and the responsibility for regulatory reporting remain with the **licensed entity** — and we say so at assessment stage, before the contract rather than after it.

No. A return is set by the market, the asset, risk and timing, and collection is set by clients’ ability, your procedures and the market — neither is controlled by an administrative system. What we do commit to is that every contract, instalment schedule, collection movement, expense and actual return is **recorded** with its conditions, and that ageing and reconciliations are read from matching figures rather than estimates. Anyone guaranteeing a return or a collection rate in this sector guarantees what they do not own, and we do not offer it.

No. We give no investment, financial, tax or statutory accounting advice, and we issue no Shariah ruling or opinion on the permissibility of a product or a financing structure — that belongs to **your Shariah advisor**, your statutory accountant and your auditor. Our role is to build the system that records what has been agreed and produces its documents; if the product itself is subject to a Shariah or regulatory opinion, the decision is not ours and we do not build on an assumption of our own.

When standard software fails for a **substantive** reason rather than a cosmetic detail: a process or rule you run that packaged software cannot represent even with configuration, an integration between two systems that cannot be replaced, a legacy system that must stay and needs a bridge, or an operational function no package sells because it is specific to your field. If the difference is a form field, a report or a permission, then configuration or training beats code you maintain for years. The analysis tells you which case you have.

By scope rather than guesswork: after the needs analysis, the written scope and the acceptance criteria, we estimate the phases, durations and hours from written items rather than from “a complete application”. Change is handled through estimated change requests: anything added after the scope is approved is estimated and approved before it is built, so neither the invoice nor the schedule grows silently. We give no binding price before the analysis and no binding duration before the scope.

The code is yours: delivered into **your repository** with clear branches, architectural documentation and an operations guide, and the build environment is pinned so another developer can run the project from the documentation without secret knowledge held by us. We hand over credentials and accounts, run a knowledge-transfer session, and stay available for the new team’s questions for an agreed period. We hold no code hostage and keep no undocumented knowledge that has no replacement.

No, and nobody honestly can: ranking is the search engine’s decision and depends on competition, content, user behaviour and algorithm changes. What we do commit to method is implementing what is **actually ours to control**: clean URL structure, correct titles and meta, structured data, sitemaps, load speed, readable content and connected analytics. Then we measure impressions and visits and show the difference against a baseline — with no promise of a position or a visit count.

A marketing site presents your business and collects enquiries; its user reads and then makes contact. A web application is a work tool: users with permissions, data entered and edited, reports, and a workflow with states and approvals. The difference is not the look but the **rules**: a web application needs permissions, change logs and handling of bad input, so it is scoped differently. In the assessment we tell you which of the two you actually need.

Yes, and that is a design requirement rather than a feature: an admin panel for text, images and pages, fields shaped for each section, and protection against edits that break the layout. We train whoever will own the updates and leave an illustrated guide. If you later need changes the panel cannot do — a new section or a new function — that is separate development scope with a clear estimate, not permanent dependence on us to change a line.

We publish no such description unless there is a **written agreement, permission to publish and a scope we can show**. We do not grant ourselves the title of “certified partner”, “agent” or “reseller”, and we do not ask any company for a badge to hang on the page. Until something documents it, we describe the relationship precisely: “implemented integration” or “joint work”, with no logo and no title. If you are shown many logos with no inspectable trace behind them, the question is not hostile but practical: where is the agreement, and what is its scope?

With four conditions together: a **written agreement** defining the scope, **explicit permission to publish** from the other party, a **scope we can show** (what was implemented and what is excluded), and an **update when the relationship ends** so the mark is removed in its time rather than lingering as a trace of a finished relationship. If one condition is missing, we publish neither name nor logo — which is why this page has no logo wall: not because we work with nobody, but because we announce only what can be evidenced.

Yes — Odoo (odoo.com) is listed in the official Solution Providers directory of the Zakat, Tax and Customs Authority (ZATCA), qualified for Phase One: generation and storage. The listing can be verified directly in the directory on ZATCA’s website. To be precise, ZATCA attaches a disclaimer to that directory: it is indicative and non-binding, it is not an approval by the authority of the solutions listed in it, and a taxpayer is entitled to work with any provider, listed or not. Phase Two (integration) is not qualified at brand level: the Compliance CSID and the Production CSID are issued to a single entity bound to its tax number (TIN), and they do not transfer to another entity. In practice, Odoo ships the Saudi localisation (l10n_sa) and e-invoicing (l10n_sa_edi) modules in its standard distribution, and we deliver the full certification path for your entity through to production — with no accreditation claim of our own.

Technically yes, but it adds another maintenance vendor and an upgrade path separate from your Odoo version. The l10n_sa and l10n_sa_edi modules are part of the standard distribution, so we start there unless you have a specific reason not to.

No. We configure and test in the sandbox without touching your current invoicing, and only move to production once the test is passed and your team is trained on the new procedure.

Six outputs: an on-site survey report, an approved slotting and route design, item coding with scan-ready labels, configured receiving, delivery and reordering rules, an opening count that builds correct balances plus a cycle-count plan after it, and team training with written operating procedures. After go-live: measurement against an agreed baseline.

The default is Odoo, because it covers stock and accounting on the same database. If you already run a warehouse system you want to keep, we first inspect its APIs and its ability to exchange movements, then decide: integrate, replace gradually, or keep it and connect reporting only. We will not promise an integration before inspecting the interfaces.

Both. In an existing warehouse we start with the survey and re-slot in stages without stopping work, because shutting the warehouse for a full rearrangement costs selling days. In a new warehouse we join at the design stage before the racks are installed, because fixing a layout after installation is expensive.

It does not start with dashboards but with two things: an **agreed definition** for each figure, and the **quality of what was entered**. We begin with a definitions session: what does “a sale” mean — the order, the delivery or the invoice? Is a return deducted in the month it happened or in the original sale’s month? Is a discount charged to the rep or to the branch? Then we review the data: duplicated items, unclassified customers, branches without addresses. Without those two steps you get a handsome report nobody can rely on.

Usually not. We work with what you have: Odoo, another system, or exported files where no API exists. If your system does not capture enough — it does not store a discount per line, or no item cost — we say so plainly: that gap needs a system change or extra entry, and it cannot be solved in the reporting layer, because reports do not create data that was never captured.

The default is Odoo CRM, because it shares one database with inventory and accounting — a quotation becomes a sales order and then an invoice with no re-keying. If you run a sales system you want to keep, we first inspect its APIs and its ability to exchange customers and orders, then decide: integrate, replace one channel gradually, or keep it and connect reporting. We will not promise an integration before inspecting the interfaces.

We configure sources and channels (advertising, search, referral, exhibition, direct call) with campaign tags, and connect the website forms to them, so the source is recorded automatically when a lead arrives through a digital channel. Non-digital channels — a call, a visit, a verbal referral — depend on whoever logs them being disciplined, so we make the source field mandatory on the entry form. Without that rule the reporting stays incomplete no matter how good the system is.

Yes. A separate pipeline can be defined per team or product line, with its own stages and a win probability per stage, plus automation rules that move a deal when a condition is met (a quotation sent, a customer reply). We configure the stages around your actual sales cycle rather than a ready template, because a stage nobody uses corrupts every report built on it.

By fit rather than price: a **single shop** suffers because everything lives in the owner’s head — so it starts with a clean catalogue with barcodes and units, a till that reconciles daily, a known cost, and installing loyalty or multi-warehouse transfers is waste. A **chain** suffers from disunity: different prices per branch, undocumented transfers, and reports collected into a spreadsheet at month-end. A **multi-channel** retailer suffers because shelf and website do not know each other: an item sold twice because stock lives in two systems, and an online return never entered against the shelf. In the assessment we tell you which of these you are.

No, and no system can: sales follow location, price, offer, competition, season and shopper behaviour, and retail shifts for reasons a program does not own. What we do commit to is that your decisions rest on correct figures: a balance that matches physically, a margin computed on real cost, returns whose cause is known, and a per-branch report with one definition. The system removes the reasons you lose money without noticing — selling from a phantom balance, pricing below cost, invisible shrinkage — but it does not create demand.

No. Card data never passes through our systems, is never stored and is never processed; the payment happens on the licensed **payment provider’s** terminal or gateway, and we connect only the result of that transaction to the system (amount, status, reference). That reduces your compliance scope, and you should ask your provider about its certification and level of compliance. We claim no compliance we do not hold, and we give no legal advice on data protection.

Odoo is a suite of integrated business applications (ERP) covering sales, accounting, inventory, purchasing, manufacturing, HR, POS, e-commerce and more. It runs on one database, so you can start with the apps you need and add more later.

Community is the open-source edition covering the core functionality. Enterprise is the commercial edition adding further official apps plus platform support and official upgrades. The right choice depends on required apps and licence budget.

Cost depends on three factors: how many apps, how much customisation and integration, and how much data migration. A single blanket number before an analysis session would be misleading. We provide a detailed proposal with a clear scope and phases, and delivery can be staged to fit budget.

Yes. The payroll module ships a Saudi localisation covering wage, contribution and end-of-service rules. We configure the contributory wage, its thresholds and ceiling to your establishment’s situation, and post the monthly gratuity accrual to accounting. The figures are reviewed with you in a trial cycle on real data before go-live.

The payroll file has a KSA-specific structure and field set that does not ship ready-made inside the product. We map salary components to the file’s fields, add validation rules (such as IBAN and account-name checks), and produce and review the file with you before submission. Uploading to Mudad and statutory compliance remain the employer’s responsibility.

Yes. Odoo’s payroll module ships a Saudi localisation covering salary and allowance rules, GOSI contributions and end-of-service gratuity. We configure the salary structure, payslip lines and deductions to your policy, and set up the Wage Protection System (WPS) and Mudad file within the delivery scope. Statutory compliance and submissions on official platforms remain the employer’s responsibility.

No. The system produces the data, files and reports those platforms need — the contribution register, the payroll file, contract and entitlement data — but submission itself and statutory compliance remain the employer’s responsibility on the official platforms. We configure the outputs, train your team to review them, and document the responsibility boundary in the proposal.

It depends on the device model and how it exports data. We verify this during analysis before fixing the scope: some devices connect directly, some through a scheduled intermediate file, and some cannot be integrated at all, in which case we propose an alternative. We will not promise a connection before inspecting the device.

No. We are a systems implementation and integration company, not a certification body. What we do is build the system an audit asks for: policy and objectives, a control plan with inspection points and acceptance criteria, written procedures, retrievable records, and documented non-conformance and corrective-action handling. Certification itself is issued by an accredited body the client chooses, and that body’s decision, fees and audit date are outside our scope.

Eight outputs: scope, policy and quality objectives; a control plan with inspection points and written acceptance criteria; standard operating procedures written in the language of the shop floor rather than of the auditor; retrievable forms and records; a non-conformance log with defined dispositions; corrective and preventive actions with effectiveness follow-up; supplier qualification and evaluation; and an equipment calibration record — plus configuring the inspection points inside Odoo and measuring the indicators.

We usually start from what exists. We collect what is genuinely being applied, separate a written procedure nobody follows from a practice that works but is not documented, and build on the second. Starting from scratch happens only for operations with no procedure at all, or where current procedures contradict what actually happens on the floor.

Yes. You can define several warehouses, and inside each one a hierarchy of storage locations (zone → aisle → shelf), with operation routes that decide how goods move: a direct receipt or one through an inspection area, a one-step or two-step delivery. We configure those routes around how your warehouse actually works, not around the default.

Yes. Odoo’s barcode app runs on a phone or a connected scanner and covers receipts, deliveries, transfers, counts and label printing. Scanning the item instead of typing it removes the single biggest source of balance drift. The scanner hardware itself we inspect first — model and how it outputs data — before it goes into the scope.

Yes. A valuation method is set per product or category (standard cost, FIFO, or weighted average), and with automated valuation the accounting entries follow each stock movement: receipt, delivery, and adjustment. During analysis we confirm the chosen method matches what your accountant applies before anything goes live.

By fit rather than price: **last-mile** suffers from evidence — who received it, when, and against what collection? So it starts with documented proof of delivery and matching collection, and installing advanced route planning before that is waste. A **third-party warehouse** suffers because what is on the shelf is not its own: it needs storage locations, documented movement and an invoice built on measured space or throughput rather than an estimate. An **own fleet** suffers because a trip is known by its fuel receipt rather than its cost: it needs the trip as a cost centre, recorded maintenance and consumption per route. **E-commerce fulfilment** suffers from custody of another merchant’s stock: it needs balance accuracy with clear storage contracts, billing on movement, and returns entered against the same balance. In the assessment we tell you which of these you are.

We guarantee no time at all, and no system can: timing depends on the road, congestion, weather, customs schedules, vehicle availability and the recipient’s behaviour, none of which we control. What we do commit to is that the promise is **measured** against the stated time on every shipment, that the cause of any delay is known by its cause rather than by a verbal explanation, and that proof of delivery is complete. Any time commitment or compensation for delay is a service agreement between you and your customer, not a promise from a system.

No. We are a systems company: we do not carry goods, do not broker freight, do not clear customs, do not issue transport licences and accept no statutory liability for cargo. What we do is build the system that runs the operation: delivery orders, proof of delivery, collection, trip cost, client stock, service invoicing and on-time reporting — while licensing, clearance and carriage remain the responsibility of the licensed party. We say so at assessment stage, before the contract.

No, and we are neither an education provider nor an accrediting body: what we build is an **internal attendance certificate** issued by your institution from its own system — it evidences that a student attended the course and completed its hours, and claims no accreditation, equivalence or recognition from anyone. Any accreditation or licence remains the institution’s responsibility and its process with the competent authority, and we produce the document from recorded data rather than from a ready template. Anyone selling you a “certified certificate” as a system is selling a promise they do not own.

No. Student results are set by teaching, content, the student, the family and circumstances, not by an administrative system. What we do commit to is that grades, attendance, absences and appeals are **recorded** in order and with their source, that who changed a grade, when and why is known, and that every document is verifiable from its data rather than from a separate file. A promise of a pass-rate improvement in this sector is a promise its maker does not control, and we do not make it.

By four rules: the data **stays in the institution’s systems** and remains its property; we use it for nothing beyond the scope of work; **we share it with no third party**; and we minimise what is collected to what genuinely serves the operation — no extra data “just in case”. Since many students are minors, the lawful basis for collection and guardian consent are the **institution’s** responsibility rather than ours, and we implement the technical controls it requires: least-privilege permissions, an access log and a defined retention period. We issue no compliance certificate and give no legal advice.

As a programme, not an installation. We start with mobilisation and governance, then current-state analysis and fit-gap, then the approved blueprint, then configuration and build — with data, integration and change running in parallel — then testing and training, then cutover and hypercare. Between phases there is a gate: we do not move on until the phase’s deliverables are earned, and the decision at that gate belongs to the steering committee rather than to the vendor.

We give no binding duration before the scope analysis, and anyone who gives one before that is selling a promise rather than a plan. What this page gives are planning ranges per phase to help you build your own schedule. The real duration is set by the number of legal entities and sites, the number of business processes, the volume of data and its migration path, the number of integrations with other systems, and the speed of the client’s own decisions — the last of which delays projects more than anything else in practice.

Yes — Odoo (odoo.com) is listed in the official Solution Providers directory of the Zakat, Tax and Customs Authority (ZATCA), qualified for Phase One: generation and storage. The listing can be verified directly in the directory on ZATCA’s website. To be precise, ZATCA attaches a disclaimer to that directory: it is indicative and non-binding, it is not an approval by the authority of the solutions listed in it, and a taxpayer is entitled to work with any provider, listed or not. Phase Two (integration) is not qualified at brand level: the Compliance CSID and the Production CSID are issued to a single entity bound to its tax number (TIN), and they do not transfer to another entity. In practice, Odoo ships the Saudi localisation (l10n_sa) and e-invoicing (l10n_sa_edi) modules in its standard distribution, and we deliver the full certification path for your entity through to production — with no accreditation claim of our own.

Usually yes. We start from your current chart and restructure it only where needed so reporting and analytic accounting work, and you sign off the final version before configuration. We do not impose a template chart when yours is sound.

We reconcile the trial balance before and after migration, match receivables, payables and assets item by item, and hand you a documented difference report. The first period is not closed until you approve it.

One of our experts who works on Odoo — implementation and training — with more than ten years across different projects, not a salesperson. They may be joined by a specialist closest to your sector (manufacturing, retail, contracting, services) depending on your question. If the matter requires regulated-sector expertise such as pharmaceuticals or food with its statutory requirements, we say so plainly and refer a specialist, because that responsibility is not ours to carry on your behalf.

Five minutes to understand your business, your size and what the team works on today; ten minutes to diagnose the problem or pending decision you describe; ten minutes for a clear first recommendation — what we believe is right, what we believe is wrong, and what needs more data; and five minutes for the next step if you want one. It is not a company introduction and not a sales pitch — the whole time is on your question.

Free with no counter-obligation: no card, no contract and nothing to buy in exchange for the session. Why we offer it is straightforward and we say it plainly: this is our field, and the session shows us whether your situation warrants working together. If it does, we send a proposal afterwards with no obligation on you; if it does not, we say so and advise you on what is enough without us. We do not sell inside the call because that would spoil its value.

Yes. Billing cycles follow the contract — monthly, quarterly or annual — with a clear payment schedule.

Yes. Scheduled alerts a configurable period before expiry, so nothing renews or lapses unnoticed.

Yes, and it is the case we implement most: tables and open orders, adding items to an order after it opens, a kitchen display that routes items to the right station, editing an order or cancelling a line with a reason, splitting the bill across several payments, variable-price items (weight or add-ons), and printing at several points (till, kitchen, bar). We configure the kitchen display around your actual preparation flow, not a ready template.

Yes. The till runs in offline mode, records sales locally and syncs them when the connection returns, so selling does not stop because of the network. But we say plainly that syncing is not magic: it needs the products and prices prepared correctly in advance, a review of the pending sales list once the line is back, and we verify the network and devices during configuration before relying on this mode at peak time.

Yes, with compatible hardware. Before anything is relied on we verify each device’s model and how it connects: barcode scanner, receipt printer, cash drawer, customer display and payment terminal. On electronic payment specifically: we verify the provider you use and its ability to integrate, and we claim no certification from any payment scheme or device manufacturer — that evidence comes from the provider itself.

No. We are an implementation and training company, not a certification body or an accredited institute, and we do not issue an “internationally accredited” certificate. What we issue is an internal attendance and assessment certificate belonging to your organisation, documented with the assessment results, the training hours and the modules covered, and usable in the employee’s file. If externally accredited certificates are required, we refer specialist bodies and take no commission from them and no part in issuing their certificates.

We start from the roles, not the modules: we establish who will actually work in the system and what each of them does every day, then build a track for each role carrying only the modules that concern it. Training runs on your own operations with realistic data in a separate training environment, with a pre-assessment to establish the level and a post-assessment to measure what was reached, then a ladder that ends with an internal trainer we have prepared.

We give no binding duration before knowing the number of roles, the number of users per role and the volume of modules covered. What we give are planning ranges: several short sessions beat one exhausting full day, and training is spread before, during and after go-live, because learning settles through repetition on real work rather than one session. More importantly, training is scheduled so the team actually attends — freeing staff for training is a management decision, not a training one.

By fit rather than price: a **contractor** suffers because a project is known from spending rather than from progress, so it needs documented items and claims with on-site proof of execution, and running an asset-management system before that is waste. An **operator** suffers because maintenance is reactive, so it needs a preventive schedule, a fault log with causes, and spare parts tied to the asset. A **renewable asset owner** suffers because warranty and performance are scattered between vendor files and invoices, so it needs an asset record linking the panel or inverter to its warranty and to production readings. An **efficiency provider** suffers because savings are claimed without a baseline, so it needs measurement before and after on a published method with written reference conditions. In the assessment we tell you which of these you are.

No. We guarantee no saving percentage, no generation figure, no uptime and no efficiency improvement, because those are set by the tariff structure, the weather, the equipment used, consumption behaviour and maintenance — none of which an administrative system controls. What we do commit to is that what happens is **measured**: a documented baseline before implementation, readings recorded with their reference conditions, a published calculation method written into the contract, and a result presented as it is even when it falls short of expectation. A guaranteed figure in this sector is a promise nobody making it actually controls.

No. We are a systems company: we do not undertake EPC works or electrical installations, we supply and install and calibrate no panels, inverters, meters or sensors, we issue and stamp no certified engineering design, and we do not handle regulatory or utility approval procedures. What we do is build the system that runs the work: work orders with proof of execution, the maintenance schedule, the asset and warranty register, progress claims, and the reading and measurement record. Design, installation and approvals remain the responsibility of the licensed party.

With a scoping session rather than a quotation: we define the primary user, the problem the app solves, the smallest version that proves the idea (not every feature), and what the first release explicitly excludes. That protects the budget from creep and makes release one measurable. The session produces a written scope and an initial screen map — before any code and before any financial commitment.

We build both platforms from one codebase where the operation allows it, because it is faster and cheaper to maintain. But that is a **trade-off, not a rule**: apps relying on deep system features — advanced camera work, Bluetooth, always-on background work, heavy graphics — may need native code per platform, and we say so in the scoping session. The decision follows the requirements, not a technical preference.

The account is in the **client’s name**, not ours: the Apple Developer or Google Play account is opened under the client’s ownership with the fees on them, because the app is a company asset and should not hang off a vendor. We handle the technical preparation — signing and certificates, store listing, screenshots, age rating, data-collection declarations — then the upload and the review follow-up. If you already have an account, we work with it directly.

You open it from the form on this page or through your contracted channel (support email or mobile), and it reaches us with the description, the impact and the evidence. We classify by impact rather than by arrival order, then diagnose and give either a fix or a temporary workaround that keeps work going, then close it once you confirm work is back — and review the cause to prevent recurrence. You can follow its state with the reference number you receive on opening.

We publish no single number for everyone, because the target is set in the service agreement according to the classification and the coverage hours you choose. What we publish here is the method: the impact classification (critical, high, medium, change request), the ticket path, and the channel hours as configured in the system. Every target figure lives in your agreement, and the monthly performance report shows actual times against target — not a marketing page.

No. Support covers the agreed behaviour: a system defect, a usage question, or configuration inside the approved scope. New development, additional reports and changes to processes or permissions are **change requests**, estimated with their own scope and time — so support hours are not consumed by projects at the expense of system stability.

Manufacturing is execution: a work order, material consumption, an operation, time and cost. Planning is the decision before it: what to make and what to buy, in which quantity, by which date, and whether capacity allows it. They run on the same database, which is why we usually configure both — planning without execution stays a spreadsheet, and execution without planning stays a reaction.

Both, and that is the point: confirmed demand — sales orders, manufacturing orders, minimum stock — is combined with a forecast entered by hand or calculated from consumption history, and both appear in the net requirement with an option to exclude forecast already covered by real orders. We set which source is trusted per product family instead of applying one rule to the whole plant.

It subtracts what is available, reserved and already allocated to other documents from the requirement, then generates component requirements through the bill-of-materials levels, and proposes either a purchase, a manufacturing order or subcontracting for each shortfall — dated from the lead time or production time rather than from today. We configure the reordering rules, minimum order quantities and purchase packaging so the proposals are actually executable.

Business Solutions is a Saudi company headquartered in Jeddah, specialising in integrated technology solutions, business and financial consulting and AI services, working with clients across Saudi Arabia.

Business Solutions was founded in 2014, with over 10 years of experience delivering technology solutions and consulting in the Kingdom.

Yes. Odoo POS keeps taking orders offline and syncs them when the connection returns — essential during peak hours.

Yes — we connect delivery channels so the order reaches the kitchen directly. Scope depends on each app’s available API.

A single branch typically takes two to four weeks depending on branch count, menu complexity and integrations. You get a firm schedule after the analysis session.

The default is an Odoo store, because it shares one database with inventory and accounting — so stock is deducted when the order arrives and the invoice is created with no re-keying. If you already run a store (Salla, Zid, Shopify or a custom build) and want to keep it, we first inspect its APIs and what it genuinely supports for syncing products, stock and orders, then decide: full integration, partial sync, or keep it and move reporting. We will not promise an integration before inspecting the interfaces.

The order reserves stock from the same inventory the till and the warehouse deduct from, so nothing sells that is not there; on delivery the invoice and the accounting entries are created automatically, and shipping and return costs land in their own accounts. That is the difference between a store that manages orders and one that manages the business: the first displays, the second knows what is left and what was earned.

We connect what you actually use: couriers according to the APIs and coverage areas they offer, the payment provider you hold a merchant account with, and cash on delivery if you want it. We say plainly that the merchant account, its fees and its contract are your responsibility, while we handle the technical connection and testing. Before any commitment we inspect the provider’s API; some providers offer no direct connection and are handled through a scheduled intermediate file.

No, and we are not qualified to: we are a systems company and provide no diagnosis, no treatment recommendation, no triage and no clinical decision support of any kind, and we issue no opinion on the suitability of a treatment, a dose or the interpretation of a test result. What we build is the **operation**: the appointment, the procedure record, the stock, the claim, the cost and the documentation. Any clinical function remains the licensed physician’s decision and responsibility, and we do not build a system that suggests a clinical decision.

By three rules: the data **stays in the facility’s systems** and remains its property; we use it for nothing beyond the agreed scope of work; and we move it to no other tool or service without written approval — and we never share it with a third party. Permissions are built by role: who sees what, in which department, with a change log for every access or edit. We issue no compliance certificate: the facility is the **data controller** and carries the statutory responsibility, and our role is to implement and document the technical controls it requires.

No. Waiting is set by the number of physicians, rooms and emergencies, by season and by how appointments are distributed, and the clinical outcome is set by medicine, the patient and adherence — not by an administrative system. What we do commit to is that durations, missed appointments, reasons for failure and reasons for claim rejection are **measured**, and that where time is lost is known by a figure rather than an impression. Anyone promising a clinical outcome or a waiting-time reduction percentage in this sector is promising what they do not control.

We announce no certificate we do not hold, and our register below is **currently empty** — not one certificate. We say that plainly rather than hang a badge: a certificate is either valid, in our name, with its number, issuing body and dates, or it is not mentioned. If we obtain one later it will be listed with its full details, and you can then verify it with the issuing body rather than with our page.

We operate with written controls: least privilege and an access log, separated test and production environments, backups whose restore is tested, security-update management, documentation and handover, and a change log with periodic review. We call them **controls**, not certifications, because the difference is fundamental: a control is measured, implemented and documented, whereas a certification is granted by a third party after audit — and we should not call one the other to look better.

We claim none of that. We are a systems company: we issue no compliance certificate, accreditation or security clearance, and we assert no conformity with a national standard or integration with a specific platform before inspecting its interface and confirming availability. Any compliance requirement, classification or permit remains the **entity’s** responsibility and its process with the competent authorities. Anyone telling you the system is “compliant and accredited” without showing you the interface and the test is making a promise they do not own.

No. The system **records**, it does not decide: it gathers the request, its documents and its stages, raises them to whoever holds the authority, and documents the decision, its reason and its time. We build no logic that grants eligibility, rejects an entitlement or ranks beneficiary priority without a declared human approval, because that is a statutory decision belonging to the entity and its responsibility — and putting it in an algorithm transfers responsibility to a program that does not hold it. If automated filtering rules are requested, they are built as published rules approved in writing and their effect is logged.

For two reasons, neither of them marketing: first, our clients’ data is not ours to publish; second, our experience is that a logo on a page proves nothing — a logo can be bought or borrowed, whereas being able to speak to a similar client in your sector under an NDA is evidence that cannot be imitated. So we publish patterns without names and provide references on request. If what you want is logos, we will be direct: we do not put them on public display.

A pattern means: the sector, the approximate scale band, the situation that reaches us, what we implement and what becomes possible — with no attribution figure, because a figure without a baseline measured before the project is meaningless. Publishing “a 40% reduction” would be fabrication: no baseline was measured in those cases, and even if it had been, the result is shaped by the market, management and timing rather than by code alone. Instead we present what can be inspected: what was built, what is managed from the console, and how the process was run before it.

By fit rather than price: a **small** plant (one or two lines) suffers because production and cost live in one person’s head, so it starts with correct bills of material, disciplined stock and an acceptable estimated cost — while installing full capacity planning is waste. A **mid-size** plant (several lines, a warehouse, reps) suffers from disconnection: planning does not know stock and sales promises dates production has not confirmed, so it starts by connecting requirement and capacity planning to sales and purchasing. A **large** plant (multiple lines, warehouses and branches) suffers from governance: analytical cost per line and product, plan against actual, batch and quality traceability, and permission control. In the assessment we tell you which of these you are — not which one we prefer to sell.

No. Our scope is **business management systems**: planning, inventory, cost, quality and documents. We do not program PLCs, we do not build SCADA systems, we do not supply sensors or hardware, and we do not implement production-line control. When you need to read data from a machine we connect it **only through an interface that already exists** (a file or protocol the machine or its system exports), and only after inspecting it. If no interface exists we say so plainly and refer you to an automation specialist — because anyone promising to collect machine data with no interface is promising what they do not control.

Because it is not an outcome of software: real capacity is set by machines, maintenance, skill and the regularity of raw material, not by a program. An improvement measured in one plant would not apply to yours, and publishing it would be fabrication. What we measure and present is what belongs to us: bill-of-material accuracy, stock balance correctness, work-order completeness, the gap between estimated and actual cost, and the recorded defect rate — figures read from your system and about your operation. As for OEE, where a machine genuinely exports its data we present it as it is, and we do not improve the number by redefining it.

We offer 21 professional services in 3 categories: tech (ERP, Odoo, AI, Cloud, development), admin (consulting, digital transformation, HR), and financial (accounting, ZATCA, financial consulting).