Decision register

The cahier ends with « Décisions restantes à valider : tarification exacte, règles de stock, modes de paiement, plafond de crédit, politique de fidélité, tolérance GPS, fréquence de localisation, intégrations de livraison, langues, iOS et durée de conservation des données » (cahier §15). Those eleven are D-01 to D-11 below, in the cahier's order. D-12 onwards are the decisions the specification work surfaced. Ids are stable: a decision is never renumbered, and a withdrawn one keeps its id with the status Superseded.

How decisions are handledCopy Anchor Link

The first pass over this register is the cadrage workshop (PRJ-03).

Decided by the team on 17 October 2026Copy Anchor Link

These product decisions were taken by the team after the first drafts and apply everywhere; they are presented to HOCO at the cadrage. Their remaining open points have their own ids.

RegisterCopy Anchor Link

18 October 2026 — defaults applied. Implementation starts before the cadrage workshop, so every open decision below takes its default if undecided from today: the schema, contract and code are built on those defaults. HOCO can still decide otherwise at the cadrage; a different answer is then a change request with its impact (change requests).

DecisionsCopy Anchor Link

D-01 — Exact pricing: customer-type criteria and the three pricesCopy Anchor Link

Question. The price model is decided — three selling prices per variant (Super-gros, Demi-gros, Détail), the reseller's customerType selects one, promotions apply on top. What qualifies a reseller for each type, and how are the three prices supplied and maintained?

Context. Cahier §4.3 (« Prix d'achat, prix revendeur, prix conseillé et remises par quantité »), §5.1 (« Les prix revendeur sont calculés selon le profil »), §8 (« Prix défini par segment, niveau, volume ou accord spécifique ; historique des modifications »). PRC-01, PRC-02, AUTH-11; ProductVariant.priceSuperGros, priceDemiGros, priceDetail in centimes HT, plus vatRate, recommendedPrice and the restricted purchasePrice. Per-reseller agreements are V2 (PRC-03); quantity tiers are D-37.

Sub-questions: the criteria text shown at sign-up for each type (volume, kind of shop) and who reviews the declaration at validation; whether HOCO's price grid makes the HT or the TTC price round (storing HT means a round TTC such as 1 850,00 DA needs an HT with centimes); how price changes are scheduled (immediate, or effective from a date); whether a promotion may go below the super-gros price.

Options.

1. Three HT prices per variant supplied by HOCO in the product import and edited in the product editor (BO-28) — exact control; three columns to maintain.
2. One reference price and two coefficients (for example Demi-gros = Super-gros × 1.05) — less data entry; prices may end on awkward values and every exception needs an override field.
3. Three TTC prices supplied, HT derived — round prices for resellers; HT and VAT computed with centime rounding on documents.

Recommendation. Option 1, with HOCO's sheet giving whichever price is round and the import computing the other; type descriptions agreed at the cadrage.

D-02 — Stock rules: warehouses, thresholds, overridesCopy Anchor Link

Question. How is stock organised and protected from overselling?

Context. Cahier §4.3 (« Stock global ou par entrepôt, stock réservé et seuil d'alerte », « Une commande ne peut être validée au-delà du stock disponible sauf autorisation explicite »), §8. Display to resellers is decided: availability only (STK-07). Overrides are recorded by a stock.validate holder (order transitions). Reservation timing is D-22; which system is the stock master is D-34.

Sub-questions: one depot or several, and which wilayas each serves; default alert threshold per variant; who may override available stock at confirmation.

Options.

1. Single warehouse "Dépôt principal", threshold per variant from the import (default 20), override by stock.validate holders with a reason — simplest.
2. Several warehouses with stock per warehouse and an order assigned to a warehouse by wilaya — accurate for multi-depot logistics; per-warehouse imports and picking; about 1–2 days more server and back-office work.

Recommendation. Option 1 unless HOCO already ships from more than one depot.

D-03 — Payment methods at launchCopy Anchor Link

Question. Which payment methods does checkout offer, and to whom?

Context. Cahier §4.7 (« Paiement à la livraison, virement, CCP, BaridiMob ou crédit »), §5.3. PaymentMethod; enabled methods are a setting; online card payment is not in the cahier.

Sub-questions: enabled methods; restrictions by customer type or reseller; cash on delivery with carriers (the carrier collects) or own fleet only; the HOCO account details shown for transfer, CCP and BaridiMob.

Options.

1. All five methods, CREDIT only for resellers with a limit (D-29) — maximum flexibility; finance verifies declarations (D-26).
2. Cash on delivery and credit only — simplest finance workflow; resellers who pay by transfer must call.
3. Option 1 plus online card payment (CIB/Edahabia) — needs an acquiring contract and a payment-gateway integration; change request.

Recommendation. Option 1.

D-04 — Credit limit policyCopy Anchor Link

Question. What happens when an order paid on credit exceeds the reseller's available credit, and what counts as used credit?

Context. Cahier §4.7 (« Le dépassement du plafond peut bloquer la commande ou exiger une validation »), §5.3, §8. V1 is basic control (FIN-05); terms and automatic blocking are V2 (FIN-06). Setting credit.overLimitPolicy (lifecycles).

Sub-questions: exposure = unpaid invoice balances + confirmed orders on credit not yet invoiced; limit of a new reseller; who changes limits (finance.administer, audited in CreditLimitChange); opening balances at go-live (D-31).

Options.

1. BLOCK — checkout refused with 422 CREDIT_LIMIT_EXCEEDED; the reseller pays another way — strict and simple; some orders are lost.
2. REQUIRE_APPROVAL — the order is submitted and held PENDING with the credit control failed; a finance.validate holder approves with a recorded override — sales keep flowing, every override is audited.

Recommendation. Option 2: every order is reviewed by the back-office anyway (no automatic confirmation), so an over-limit order is just one more flagged item in the queue.

D-05 — Loyalty policy (V2)Copy Anchor Link

Question. How are points earned, validated, expired and redeemed, and what are the level thresholds?

Context. Cahier §4.4 (« Les points de fidélité sont crédités après livraison ou paiement selon le paramétrage »), §4.6 (Bronze, Silver, Gold, VIP; « Les niveaux sont calculés selon une période et des seuils validés par le client »), §5.5. Loyalty is V2 (LOY-01–LOY-05); the split itself is D-16.

Options.

1. Points on paid invoices (HT, 1 point per 100 DA, 12-month expiry, levels over a rolling 12 months) — immune to unpaid orders; easy to explain.
2. Points on delivery, reversed on cancellation and return — faster reward; more reversals.
3. No points, levels from purchase volume only — no rewards catalogue to run.

Recommendation. Decide after the pilot with real order data; option 1 as the design hypothesis.

D-06 — GPS check-in toleranceCopy Anchor Link

Question. How far from the point of sale may a delegate check in, and what happens beyond?

Context. Cahier §6.3 (« L'arrivée peut être soumise à une distance maximale du point de vente »; « Le bouton Arrivé enregistre la position et ouvre la visite lorsque la tolérance GPS est respectée »), §8, §12 (GPS scenario). Settings field.gpsToleranceMeters, field.gpsMaxAccuracyMeters, field.allowOutOfToleranceCheckIn; errors GPS_OUT_OF_TOLERANCE, GPS_ACCURACY_TOO_LOW, GPS_MOCK_LOCATION.

Options.

1. Blocking at 150 m with accuracy ≤ 100 m, plus « Signaler une position erronée » that creates a back-office task to correct a wrong store pin — matches the cahier's acceptance criterion; visits can be blocked by wrong pins until corrected.
2. Warn: check-in allowed beyond the radius with a mandatory justification, flagged on BO-25 — never blocks field work; weaker proof of presence.
3. Larger radius in rural communes (300 m) — fewer false refusals; a per-zone setting.

Recommendation. Option 1 for the pilot; review the distribution of check-in distances at the pilot go/no-go.

D-07 — Location sampling frequency and visibilityCopy Anchor Link

Question. When and how often is a delegate's position recorded, who sees the trail, and for how long?

Context. Cahier §6.3 (« La position est utilisée uniquement selon les règles validées par le client »), §8 (tolérance, fréquence, consentement, conservation), §10 (« Consentement et transparence concernant la géolocalisation des délégués »). FLD-15, SEC-07.

Options.

1. Only while a tour is IN_PROGRESS, every 5 minutes or 200 m, kept 90 days, visible to field.view holders — live map and kilometres for the closing summary (§6.9); moderate battery use.
2. Only at check-in and check-out — strongest privacy; no live trail; kilometres estimated from stop-to-stop distances.
3. Every minute or 50 m — precise trails; battery and data cost; harder to justify as proportionate.

Recommendation. Option 1.

D-08 — Delivery carriers and integrationsCopy Anchor Link

Question. Which carriers does HOCO use, and is any integrated by API in V1?

Context. Cahier §4.4 (« Affectation du transporteur et suivi de livraison »), §11 (« Connexion aux agences disposant d'une API ; sinon gestion manuelle structurée »), §14.2. DLV-02, DLV-04, DLV-05; integrations.

Sub-questions: own fleet versus carriers; the carriers used and which expose an API; cash collected by carriers and its settlement; tracking URL format.

Options.

1. V1 structured manual (carrier list, tracking number, proof of delivery in BO-42); API in V2 for the one or two main carriers — as planned (SRV-17, SRV-34).
2. V1 API for one carrier — automatic tracking from day one; about 3 days on the critical lane plus carrier onboarding delays.

Recommendation. Option 1.

D-09 — Languages at launchCopy Anchor Link

Question. Which languages are active at launch, and when is Arabic switched on?

Context. Cahier §9 (« Français en V1 ; arabe et anglais prévus selon validation »). Every interface is built RTL-ready with fr, ar and en message files from day one (NFR-06, cross-cutting requirements).

Sub-questions: who supplies and validates translations; Modern Standard Arabic for the interface; Latin digits (as in the ar-DZ locale) and the currency label (DA or د.ج); Arabic product content or French only.

Options.

1. French only at launch; Arabic activated by change request after the pilot, translations supplied by HOCO — no delay.
2. French and Arabic interface at launch (product content in French) — wider adoption; about 2 000 strings to translate across the four interfaces and an RTL QA pass on every screen before the pilot (estimate: 3–5 days of QA and fixes across the team) — which does not fit the three-month frame without moving other V1 scope (D-38).
3. Option 1 plus English later — mostly useful to staff.

Recommendation. Option 1, with Arabic on the reseller app first if pilot resellers ask for it.

D-10 — iOS appsCopy Anchor Link

Question. Do the reseller and delegate apps ship on iOS, and when?

Context. Cahier §9 (« Android prioritaire ; iOS selon décision du client »). NFR-04. The plan holds MOB-16 (3 days) in generalisation, after the pilot; the reseller web, part of V1, already serves iPhone users in the browser from go-live.

Options.

1. Android only for V1 — no Apple costs; MOB-16 is freed for pilot improvements.
2. Reseller app on iOS, delegate app on Android only — covers iPhone shop owners; needs an Apple Developer Program organization account (D-U-N-S number, annual fee), a macOS build runner, and App Review (in-app account deletion, permission texts).
3. Both apps on iOS — useful only if delegates use iPhones; background location review and QA on iOS too.

Recommendation. Option 1 unless HOCO's resellers show a significant iPhone share, then option 2. Apple enrollment takes time: decide at the cadrage even if the build comes later.

D-11 — Data retention and deletion requestsCopy Anchor Link

Question. How long is each category of data kept, and how are deletion requests handled?

Context. Cahier §10 (« Politique de confidentialité, propriété et durée de conservation des données à valider avec le client »), §8 (GPS retention). Law 18-07 on personal data. Google Play requires an in-app and web path to request account deletion for apps that let users create an account. The proposed table is in cross-cutting requirements.

Options.

1. The proposed table (positions 90 days, accounting documents 10 years, inactive prospects anonymised after 3 years, application logs 30 days…) — to validate with HOCO's counsel and accountant.
2. Shorter position retention (30 days) — more privacy-friendly; kilometre history beyond 30 days kept only as daily totals.

Recommendation. Option 1; deletion requests close the account and anonymise personal data while keeping legally required records.

D-12 — Final domain names and DNSCopy Anchor Link

Question. Which domain does the platform use, and who manages its DNS?

Context. Every page uses hoco.dz as a placeholder. Invitation links and QR codes (https://app.hoco.dz/i/AB12CD34) are printed on flyers (DQA-07) and verified as Android App Links; session cookies are scoped to the parent domain; the email sender domain needs SPF, DKIM and DMARC. A .dz name is registered through the national registry (NIC.DZ) and requires an Algerian entity — check the lead time.

Options.

1. HOCO's domain (existing or new) with api, admin, app, cdn and their -staging and -preprod variants — one cookie domain, brand-consistent.
2. A dedicated domain (for example a .com) — quicker to register; weaker brand link.

Recommendation. Option 1 on a DNS host with an API (fast changes, ACME DNS challenges); Anis gets delegated access.

D-13 — SMS gateway providerCopy Anchor Link

Question. Which gateway sends the one-time codes and critical SMS?

Context. Cahier §11 (« SMS / Email : OTP, invitations, confirmations et relances »), INT-03. OTP is on the sign-up path: without SMS, no reseller can sign up. Evaluation checklist in integrations; the SMS whitelist in the notifications matrix.

Options.

1. An Algerian aggregator or a mobile operator's A2P offer, sender ID HOCO on the three networks, invoiced in DZD — local billing and delivery; sender-ID registration delay.
2. An international messaging platform — fast API onboarding; foreign-currency payment; Algerian delivery quality and sender-ID rules to verify.
3. Two providers (primary plus fallback for OTP) — resilience; two contracts.

Recommendation. Option 1 as primary; the adapter can add option 3 later without code changes in the modules.

D-14 — Maps providerCopy Anchor Link

Question. Google Maps Platform or Mapbox for maps, geocoding and distances?

Context. Cahier §11 (« Google Maps, Mapbox ou service équivalent »), INT-01. Comparison in integrations.

Options.

1. Google Maps Platform — best coverage and geocoding for Algerian addresses; native mobile map loads free; billing account with an international card.
2. Mapbox — generous free tiers; weaker geocoding of Algerian addresses; a different Flutter plugin from the planned stack.

Recommendation. Option 1.

D-15 — Hosting provider and data locationCopy Anchor Link

Question. Where are servers and data hosted, and is the database managed or self-hosted?

Context. Cahier §13.2 (« Configuration du serveur, base de données, stockage et sauvegardes »), §10. Law 18-07 restricts transfers of personal data abroad — to validate with HOCO's counsel. Sizing in deployment and operations.

Options.

1. VPS at a European cloud provider (Dokploy), self-hosted PostgreSQL with point-in-time recovery to off-site object storage — low cost, 30–60 ms from Algeria, mature tooling; cross-border question.
2. Same with managed PostgreSQL — better recovery objectives, less operations; higher monthly cost.
3. Algerian data centre or hosting provider — data stays in Algeria; fewer managed services; check S3-compatible storage and backup offers.

Recommendation. Option 1 or 2 by budget, unless counsel requires option 3.

D-16 — V1/V2 split for loyalty and packsCopy Anchor Link

Question. Do loyalty points and profitable packs ship in V1, as the client's reference screens suggest, or in V2, as the cahier recommends?

Context. The reference screens show points, levels and packs (home and Promotions & fidélité); §14.1 V1 = « promotions simples »; §14.2 V2 = « Fidélité avancée, packs rentables ». Returns and after-sales moved to V1 on 17 October (team decisions); loyalty and packs did not. In the plan they are SRV-30, SRV-31, DSH-21, MRA-20 in P4.

Options.

1. Both in V2 — V1 dates hold; V2 screens designed during the build (DES-30).
2. Packs in V1, loyalty in V2 — about 2–3 days on Anis's critical lane (SRV-31 and part of DSH-21) and 1.5 days for Imad; Anis's lane has no slack in the three months, so go-live moves by about the same unless other V1 scope moves out (D-38).
3. Both in V1 — about 6 days on Anis's lane and 3 for Imad; breaks the three-month frame.

Recommendation. Option 1.

D-17 — Prices displayed TTC or HTCopy Anchor Link

Question. Are reseller prices shown including or excluding VAT in the catalog and the cart?

Context. VAT 19 % by default per product; the API returns both values (Price { ht, ttc, vatRate }); documents show HT, VAT and TTC (PRC-04); prices are stored HT (D-01).

Options.

1. TTC everywhere, HT in the cart breakdown and on documents — what the reseller pays.
2. HT first, TTC below — natural for VAT-registered businesses.
3. By the reseller's tax regime — exact; one more reseller field and two display modes to design and test.

Recommendation. Option 1.

D-18 — Prices visible before account validationCopy Anchor Link

Question. Guests see no prices (decided). Does a reseller who has signed up but whose account is still PENDING_VALIDATION see prices — and which ones?

Context. AUTH-10, AUTH-11, RA-41, RA-06. The team's default is right away, with the declared customer type; ordering still requires validation. Risk: anyone can sign up, declare Super-gros and read HOCO's lowest prices before a human has reviewed the account.

Options.

1. Right away, prices of the declared type — best engagement; exposes super-gros prices to unreviewed accounts.
2. Right away, but the Détail price for everyone until validation — prices are visible (engagement), wholesale prices stay protected; the reseller sees their own type's prices from validation.
3. Only after validation — strictest; a priced catalog only after a delay.

Recommendation. Option 2.

D-19 — Minimum order amount and quantity rulesCopy Anchor Link

Question. What minimum order amount and per-product quantity rules apply?

Context. Cahier §5.3 (« Le montant minimum et les quantités minimales sont contrôlés »), §5.2 (« La quantité ne peut dépasser le maximum autorisé ni le stock disponible »), §8. ORD-02; errors ORDER_MIN_AMOUNT_NOT_MET, QUANTITY_NOT_ALLOWED.

Sub-questions: one minimum or one per customer type; a lower minimum for the first order; minimum, step and maximum per variant (cartons of 10, allocation of scarce products); whether the minimum is measured before or after discounts and delivery fees.

Options.

1. One minimum (10 000,00 DA TTC after discounts, delivery excluded); per-variant minimum, step and maximum from the product import.
2. A minimum per customer type (higher for super-gros) — matches volumes; three values to maintain.
3. Option 1 with a lower first-order minimum — eases assisted first orders (§6.7).

Recommendation. Option 2 if HOCO already works with type-based minimums, otherwise option 1.

D-20 — Delivery feesCopy Anchor Link

Question. Are delivery fees charged, and how are they computed?

Context. DLV-06 (reference screen 5 shows a delivery line), PromotionType.FREE_DELIVERY, Totals.deliveryFee (0 shows « Offerts »).

Options.

1. Free delivery for every order above the minimum — simplest; HOCO absorbs the cost.
2. Fee table per wilaya with a free-delivery threshold — recovers costs in distant wilayas; HOCO supplies the table.
3. Carrier tariff passed through (V2 with a carrier API) — exact; depends on D-08.

Recommendation. Option 1 for the pilot zone; option 2 ready as a setting for generalisation.

D-21 — Invoice legal mentions and stamp duty on cash paymentsCopy Anchor Link

Question. Which mentions must invoices and credit notes carry, and how is the stamp duty (droit de timbre) on cash payments applied?

Context. Cahier §4.4, §4.7; FIN-01, FIN-08; document templates in DQA-09 (NIF, NIS, RC, AI, VAT). Invoices paid in cash carry a stamp duty whose scale has changed in recent finance laws — HOCO's accountant must confirm the current rule.

Sub-questions: HOCO's identifiers and legal form; reseller identifiers required on invoices to professionals; the stamp-duty scale, rounding and whether it applies to cash on delivery; numbering (FAC-YYYY-NNNNNN, per year, no gaps) and the credit-note number format; invoice language.

Options.

1. The accountant supplies mentions and the stamp-duty rule; the rule is a setting applied when the payment method is CASH_ON_DELIVERY — compliant invoices from the platform.
2. Invoices issued from HOCO's accounting system, the platform showing a pro forma — no fiscal responsibility in the platform; double entry and no immediate invoice for resellers.

Recommendation. Option 1.

D-22 — Stock reservation and deduction statusesCopy Anchor Link

Question. At which order statuses is stock reserved and deducted?

Context. Cahier §8 (« Stock disponible = stock physique - stock réservé ; contrôle au panier et à la validation »), §12 (« Les quantités sont réservées ou déduites selon le statut configuré »); STK-03; settings stock.reserveOn, stock.deductOn (order stock). Cancellation and return reception restock automatically (decided). Because no order is confirmed automatically, the time between SUBMITTED and VALIDATED is the back-office queue time.

Options.

1. Reserve at VALIDATED (the back-office confirmation), deduct at SHIPPED — stock locked only for accepted orders; two orders waiting in the queue can compete for the last units, resolved at confirmation.
2. Reserve at SUBMITTED — first come, first served; refused or cancelled orders free stock late; orders on hold lock stock.
3. Deduct at READY — physical stock matches the shelf earlier.

Recommendation. Option 1, measuring the median queue time during the pilot; switch to option 2 if it exceeds about four working hours.

D-23 — Assisted-order confirmation delayCopy Anchor Link

Question. How long does a reseller have to confirm an assisted order, and what happens after?

Context. Cahier §4.4 (« Une commande assistée doit être confirmée par le revendeur ou validée par l'administration »), §6.7; ORD-08; AssistedConfirmation.EXPIRED; setting orders.assistedConfirmationHours.

Options.

1. 72 h, reminder 24 h before expiry, then EXPIRED and the order cancelled; the administration can confirm on the reseller's behalf with a note — default.
2. 24 h — fresher prices and stock; more expiries for shops that rarely open the app.
3. No expiry, the delegate cancels by hand — stale orders accumulate.

Recommendation. Option 1.

D-24 — Background location on AndroidCopy Anchor Link

Question. How does the delegate app record positions with the screen off during a tour?

Context. D-07; cahier §10 consent. Google Play requires a declaration and a video for ACCESS_BACKGROUND_LOCATION, and a declaration of foreground-service types for recent target SDKs (integrations).

Options.

1. Foreground service of type location started by « Démarrer la tournée » and stopped at suspension or closing, with a persistent notification; no background-location permission — simpler review; works with the screen off; positions only during tours.
2. ACCESS_BACKGROUND_LOCATION — keeps sampling if the service is killed; heavier review, stronger consent wording, more battery.
3. No background sampling — equals D-07 option 2.

Recommendation. Option 1.

D-25 — Ownership of store, cloud and provider accountsCopy Anchor Link

Question. Under whose accounts are the apps, the Firebase and Google Cloud projects and the provider contracts created?

Context. Cahier §11 (« Les frais, comptes, abonnements, limites d'API et délais de validation imposés par les fournisseurs externes doivent être identifiés séparément et validés par le client »), INT-07. Google Play and Apple require a D-U-N-S number for organization accounts; moving an app between Play developer accounts is possible but slow; foreign providers need an internationally accepted payment card.

Sub-questions: Google Play Console, Apple Developer (if D-10), Firebase and Google Cloud (FCM, Maps billing), SMS and email contracts, hosting, domain; who pays; team roles; ownership of the code repositories (AnisBetehi/hoco, hoco-mobile on Imad's account) at the end of the contract.

Options.

1. Everything under HOCO's organization accounts, team members invited with least-privilege roles — HOCO owns its assets; HOCO must start early (the D-U-N-S lookup can take days to weeks).
2. Provider-owned accounts transferred at go-live — fast start; transfers are slow and the Play transfer needs both parties.

Recommendation. Option 1 for Play, Apple, Firebase and billing accounts; repositories mirrored to a HOCO organization at the end of the warranty (contractual).

D-26 — Payment-declaration proof requirementsCopy Anchor Link

Question. What must a reseller provide when declaring a transfer, CCP or BaridiMob payment?

Context. Cahier §4.7 (« Paiements partiels et rapprochement »); FIN-03; PaymentStatus; FilePurpose.PAYMENT_PROOF (private, ≤ 10 MB); payment lifecycle.

Options.

1. Proof mandatory (photo or PDF of the receipt or screenshot) with amount, payment date and transaction reference; invoices to pay optional (finance allocates) — verifiable; duplicate-reference warning.
2. Proof optional, reference mandatory — fewer abandoned declarations; more verification calls.

Recommendation. Option 1, with a verification target of one working day.

D-27 — Scope of "Messages" in the delegate appCopy Anchor Link

Question. Is Messages a one-way announcements inbox or a two-way chat with the back-office?

Context. Cahier §6.1 (« Accéder aux prospects, rapports et messages »); NOT-07; DA-23.

Options.

1. One-way announcements plus the notification inbox — as planned; no new module.
2. Two-way chat delegate ↔ back-office — conversations, attachments, unread states, live delivery, moderation; change request (rough estimate: 4–6 days server and back-office, 3–4 days mobile).
3. Option 1 plus « Répondre sur WhatsApp » on an announcement, opening the author's WhatsApp — quick replies; no history in the platform.

Recommendation. Option 1, option 3 if HOCO wants replies.

D-28 — Reseller sign-up: open or invitation-onlyCopy Anchor Link

Question. Can anyone sign up as a reseller, or only with an invitation code?

Context. AUTH-03 (optional invitation code), cahier §6.6, §4.2 (validation by an authorised user); guest mode lets anyone browse first (AUTH-10).

Options.

1. Open sign-up with back-office validation — growth by word of mouth; validation workload.
2. Invitation-only — no unknown sign-ups; growth limited to the delegates' reach.

Recommendation. Option 1, combined with D-18 option 2 to protect wholesale prices.

D-29 — Credit eligibilityCopy Anchor Link

Question. Which resellers may choose « Crédit (paiement différé) » at checkout?

Context. Cahier §4.7; FIN-05; detailed credit is V2 (FIN-06). Related: D-04.

Options.

1. Only resellers given a limit by finance (default 0 = no credit) — explicit and audited (CreditLimitChange).
2. Automatic eligibility after a number of delivered and paid orders, with a default limit — scalable; risky if the rule is loose.

Recommendation. Option 1 in V1; option 2 considered with V2 detailed credit.

D-30 — Who validates new points of saleCopy Anchor Link

Question. Who validates new reseller accounts and points of sale created in the field, and the declared customer type?

Context. Cahier §4.2 (« La validation du compte est réalisée par un utilisateur autorisé »), §4.5 (« Validation des nouveaux points de vente »); CRM-09, FLD-14, AUTH-11; queue BO-13; permission crm.validate.

Options.

1. crm.validate holders (default role: commercial admin) validate accounts, points of sale and the customer type, with a reason on rejection — one queue.
2. Two steps: commercial validation, then finance when credit is requested — tighter credit control; slower.
3. Field points of sale auto-validated when the delegate captured GPS and a façade photo; self sign-ups validated by hand — less workload; relies on delegates.

Recommendation. Option 1, with finance involved only for credit (D-29).

D-31 — Data import sources and formatCopy Anchor Link

Question. From which systems and in which format does HOCO supply products, stock, resellers, users and balances for the initial import?

Context. Cahier §13.2 (« Import initial des produits, revendeurs et comptes utilisateurs »); ADM-06, CAT-06; plan in deployment and operations.

Sub-questions: current sources (accounting software, spreadsheets, phone lists); the data owner on HOCO's side for each set; product images; reseller GPS and customer types; opening balances (unpaid invoices become used credit); the freeze date before go-live.

Options.

1. HOCO fills the platform's XLSX templates (one per data set); the provider cleans with HOCO; dry-run on pre-production — predictable.
2. The provider converts HOCO's raw exports — less work for HOCO; mapping effort and errors move to the provider (extra days in SRV-27 and LCH-01).

Recommendation. Option 1, with samples early to tune the templates.

D-32 — Pilot group and pilot lengthCopy Anchor Link

Question. Which delegates, resellers and zone take part in the pilot, and does it last two weeks or one?

Context. Cahier §14 (Phase 9 « Déploiement avec un groupe limité de délégués et revendeurs »); OPS-06. The pilot starts right after the production go-live of early January and ends before Ramadan, so field conditions are representative; its timing is set by the three-month frame. Shortening it is one of the levers of the timeline (D-38). Go/no-go criteria in deployment and operations.

Sub-questions: the zone (one wilaya or a delegate zone close to HOCO's depot); the delegates (two or three, with phones that have Google Play services); the resellers (a mix of customer types, some already ordering by phone, some prospects to convert); who at HOCO confirms the pilot orders every day.

Options.

1. Two weeks, 2–3 delegates and 20–40 resellers in one zone — enough tours and orders to judge the go/no-go criteria.
2. One week, then the rest folded into the first generalisation wave — recovers a week if the build slips; fewer data points for the go/no-go.
3. Larger group (a whole region from day one) — faster adoption; support load and risk concentrated in the first days.

Recommendation. Option 1; option 2 only as a slip lever.

D-33 — Back-office sessions and two-factor authenticationCopy Anchor Link

Question. How long do back-office sessions last, which actions require re-authentication, and is a second factor required for sensitive roles?

Context. Cahier §10 (« Gestion des sessions, expiration, révocation et limitation des tentatives »); AUTH-06, SEC-02. Working default: 7 days sliding with re-authentication for sensitive actions.

Options.

1. 7 days sliding; password re-entry when the last authentication is older than 15 minutes for role and permission changes, settings, credit limits, user status changes and exports of personal data.
2. Option 1 plus TOTP two-factor authentication for super admins and finance managers — stronger; about one day (Better Auth two-factor plugin and screens).
3. 8-hour sessions without re-authentication — simpler rules; more sign-ins.

Recommendation. Option 1 at go-live, option 2 before generalisation.

D-34 — ERP, accounting and stock-system integrationCopy Anchor Link

Question. Which accounting, ERP and stock systems does HOCO use, which system is the master of each data set at go-live, and what should V2 synchronise?

Context. Cahier §11 (« ERP / comptabilité : import, export ou API selon le système existant du client », « Stock : synchronisation avec le système de stock existant si disponible »); INT-06, STK-09, FIN-09 (V2); SRV-32, SRV-37.

Options.

1. The platform is master for orders, invoices and stock from go-live; accounting receives file exports; V2 adds API synchronisation where the systems allow it — as planned; HOCO stops double entry in the old stock tool.
2. The existing system stays master for stock in V1, imported daily — no change of habit for the stock team; a daily import routine (about 1–2 days) and stock that is stale between imports.

Recommendation. Option 1; option 2 only if HOCO cannot stop its current stock system at go-live.

D-35 — Return and after-sales windows, warranty rulesCopy Anchor Link

Question. Within which delays can a reseller request a return or open an after-sales claim, and which warranty and restocking rules apply?

Context. Returns and after-sales are V1 (ORD-13, SUP-04, FIN-08); the product warranty is a product field (cahier §15.4 Garantie, CAT-03); setting returns.windowDays (default 7). Reception re-enters accepted quantities automatically (STK-03); claims resolve as REPLACEMENT, RETURN, CREDIT_NOTE, REPAIR or REJECTED (AfterSalesResolution).

Sub-questions: return window after delivery and accepted reasons (commercial return of unsold goods or only errors and damage); claim window per brand or product (warranty months); evidence required (photos, packaging, serial or batch); who carries goods back (delegate on the next visit, carrier, drop at the depot) and who pays; defective units — not re-entered as sellable stock (quarantine or write-off); credit note only, or cash refund too; replacement subject to available stock.

Options.

1. Returns within 7 days of delivery for wrong, missing or damaged items; claims within the product warranty with photos; credit notes only; defective units recorded on the return but not restocked as sellable — clear and safe for stock.
2. Option 1 plus commercial returns of unsold goods within a longer window (for example 30 days) — friendlier to resellers; more stock movements and margin risk.

Recommendation. Option 1, with the warranty months supplied per brand in the product import.

D-36 — Support regions and their WhatsApp numbersCopy Anchor Link

Question. How are the wilayas grouped into support regions, and which WhatsApp number and opening hours serve each region?

Context. SUP-05, ADM-08; SupportRegion, SupportRegionWilaya; BO-70; support.whatsapp resolves the region from the account's wilaya when signed in, else from the device location, else a wilaya picker or the default number (integrations).

Sub-questions: number of regions and the wilayas of each; one WhatsApp Business number per region and who answers it; hours (Sunday–Thursday?) and the message outside hours; the default number; numbers on the WhatsApp Business app (free) now, the Business Platform in V2.

Options.

1. Regions such as Centre, Est, Ouest, Sud, each with its number and hours — local answers; four phones to staff.
2. One national region and number at launch, regions added later in BO-70 — nothing to staff beyond today; the feature works unchanged when regions are added.
3. One number per delegate zone — personal contact; many numbers to keep staffed.

Recommendation. Option 2 for the pilot if staffing is limited, option 1 at generalisation.

D-37 — Quantity tiers dropped from V1Copy Anchor Link

Question. Does HOCO confirm that V1 has no quantity-based price tiers (« remises par quantité »), the three customer-type prices and promotions covering volume incentives?

Context. Cahier §4.3 lists « remises par quantité »; the team decided on 17 October 2026 that customer-type prices replace segment lists and quantity tiers in V1 (PRC-01, PRC-02); promotions can still target volume (PRM-02). Consistency note — the operations admin.variants.tiers and admin.priceLists.crud/items and screen BO-31 Price lists & agreements are still marked V1 in the spec files; once this decision is confirmed they move to V2 (agreements) or are removed (tiers).

Options.

1. Confirm: no tiers in V1 — customer-type prices plus promotions.
2. Keep tiers in V1 (« à partir de 10 pièces » on the product page and in the cart) — about 1.5 days server and back-office on the critical lane and 1 day mobile.
3. Tiers in V2 with agreements (PRC-03).

Recommendation. Option 1 (option 3 if HOCO wants tiers later).

D-38 — Three-month commitment: what moves after go-live if a slip happensCopy Anchor Link

Question. V1 is committed to three months — design, development and deployment, from the cadrage to mid-January, with production at the start of January and the pilot right after. If the build slips, does HOCO prefer to keep the dates and move scope after go-live, or keep the scope and move the dates — and which scope moves first?

Context. Team decision of 18 October 2026; the plan is built to the frame and its milestones table checks Production go-live and Pilot starts against the deadline (see the timeline). Anis's lane — server, back-office and reseller web — fills the three months with no slack (releases and team); the other lanes have small buffers. A slip of a few days on the critical lane moves go-live by the same amount unless something is moved out. The cahier's validation sheet (Clause de périmètre): « Toute fonctionnalité non décrite ou non validée dans le présent cahier des charges fera l'objet d'une analyse complémentaire, d'un chiffrage séparé ou d'une planification dans une version ultérieure ».

Ordered deferral list (the levers of the timeline, in the order the team would use them; each item moves to the first weeks after go-live, not to V2):

1. Spend the visible buffers (Imad's late-December buffer, Akram's gaps between design-QA rounds) — no scope change.
2. Some back-office reports beyond the essential ones (ANA-04 success KPIs, secondary reports of ANA-03) — the dashboards stay.
3. The product import wizard screen (BO-32) — the initial import for the pilot is run by script with the same dry-run report (CAT-06, ADM-06).
4. Stock inventory sessions (STK-06) — receipts and adjustments stay.
5. Announcements (NOT-07) — notifications stay; urgent messages go through the regional WhatsApp numbers meanwhile.
6. Shorten the pilot to one week (D-32 option 2).
7. Other SHOULD and COULD items, by HOCO's choice: audit-log viewer (AUD-03), segments screen (CRM-06), recommended visit order (FLD-17), barcode scanner (CAT-10), per-wilaya delivery fees (DLV-06).

Items that never move: everything a priority acceptance scenario needs (cahier §12), the decided product rules of 17 October (order confirmation queue, live status, customer-type prices, guest mode, filters, regional WhatsApp, after-sales and returns), security and backups.

Options.

1. Dates hold, scope moves along the ordered list, each move agreed in the Thursday review and recorded as a change — go-live and pilot stay in the frame.
2. Scope holds, dates move — the plan recomputes go-live; the pilot may then overlap Ramadan, which starts shortly after the planned pilot.
3. Capacity is added — a second TypeScript developer on the back-office halves the longest lane, at the cost of onboarding and review time; useful only if decided early in the build.

Recommendation. Option 1, with option 3 kept ready if a slip is detected before the back-office work starts.

D-39 — Smart notifications: anti-fatigue caps and priorityCopy Anchor Link

Question. How many promotional pushes may a reseller receive, and which one wins when several compete?

Context. HOCO's document 03 (18 October 2026) adds about twenty commercial notification types (smart notifications, NOT-17). The client wants the app to stay present without feeling intrusive (« ما يحسش التطبيق يزعجو »). The matrix already has notifications.promotionalDailyCap = 1. A reseller who mutes the app at the system level is lost to every channel, transactional ones included.

Options.

1. 1 per day, 3 per rolling 7 days, inbox beyond; priority flash sale → back in stock → abandoned cart → commercial push → price drop → low stock → promotion → reorder → complement → new arrival → trending → catalogue; merge within 24 h; one product per reseller per 7 days; back-off after 5 unopened pushes. Lowest fatigue; every notification is still in the Notification Centre.
2. 2 per day, 7 per week. More reach. Higher risk of mute or uninstall, mostly on resellers who receive several targeted types.
3. No cap, only quiet hours. Simplest. Not recommended.

Recommendation. Option 1. Review the open rates after the pilot (notification_opened) and raise the weekly cap if they stay high.

D-40 — HOCO Academy (videos, quizzes): a module or notCopy Anchor Link

Question. Does HOCO want a HOCO Academy module (training videos, quizzes, Academy missions), and with what content and owner?

Context. Document 03 cites Academy notifications (SN-10, SN-11) and missions (watch a video +100, five videos +500, pass a quiz). The cahier has no learning module. It would need video hosting or embedding (the MinIO storage serves files, not adaptive streaming), lesson and quiz authoring in the back-office, a section in both reseller apps, progress tracking, and someone at HOCO to produce the content. The Notification Centre keeps an Academy group, hidden while empty (NOT-09).

Options.

1. Not now. Re-estimate after V2 if HOCO has content. Nothing to build; the group stays hidden.
2. Light Academy in V2. Unlisted YouTube videos embedded by link, a lesson list, a watched flag, no quiz. About 3 days across server, back-office and apps, plus design.
3. Full Academy. Hosted videos, quizzes with scoring, points through loyalty. A separate quote.

Recommendation. Option 1 until HOCO has at least ten lessons ready, then option 2.

D-41 — Method for « Suggestions IA » (bought together)Copy Anchor Link

Question. How are the « Les revendeurs qui ont acheté X ont aussi acheté Y » suggestions (SN-13) computed?

Context. The client compares it to Amazon. A useful co-purchase signal needs months of orders. At go-live there is no order history: the import excludes past orders (D-31). V1 covers the need with complementary pairs configured by HOCO (SN-14, NOT-15). Advanced analytics is V2 (ANA-06).

Options.

1. V1: configured pairs only. V2: co-purchase statistics (lift on order pairs over 180 days, minimum support of 20 orders, nightly job). Explainable, no external service.
2. An external recommendation service or model. Needs a provider, sends data outside, and is hard to justify at HOCO's volume.
3. Manual pairs only, for good.

Recommendation. Option 1.

D-42 — Top 3 resellers: prize budget and criteria weightsCopy Anchor Link

Question. What monthly budget does HOCO commit to the Top 3, and how are purchase volume, number of orders and activity in the app weighted?

Context. Document 03 proposes vouchers of 20 000, 10 000 and 5 000 DA (35 000 DA a month), the badges Meilleur Revendeur, Top Revendeur and Top 3 Revendeur, a month on the home page for the winner, and three criteria with no weights (LOY-07, V2). With volume alone, the same super-gros resellers would win every month. The same decision covers the mission cadence (Daily / Weekly / Monthly) and the wilaya Top 10 mentioned in SN-07.

Options.

1. 35 000 DA a month; score = 60 % volume, 30 % number of orders, 10 % activity (days with a session or an app order), each normalised within the month; one national ranking; a winner can win again only after 3 months.
2. Volume only. Simple, but predictable and discouraging for small resellers.
3. One Top 3 per customer type (super-gros, demi-gros, détail). Fairer, but triples the budget.

Recommendation. Option 1 at the start. Option 3 if HOCO wants to motivate détail resellers.

D-43 — Back-in-stock look-back windowCopy Anchor Link

Question. Which resellers are told that a variant is back in stock?

Context. The client: « إذا كان التاجر سبق وشراه، الإشعار يجيه هو برك، ماشي كامل التجار » (only the reseller who bought it before, not every reseller). SN-02 (NOT-12). The setting is smart.restockLookbackDays. Favorites and carts show interest without a past purchase.

Options.

1. Ordered in the last 90 days (order not refused or cancelled), plus favorites, plus carts holding the variant.
2. Ordered in the last 180 days, plus favorites and carts. Reaches more resellers, more of whom may have stopped selling the product.
3. Past buyers only, any date.

Recommendation. Option 1.

D-44 — Abandoned-cart delayCopy Anchor Link

Question. How long after a reseller leaves products in the cart is the reminder sent, and how often?

Context. The client: « بعد ساعتين » (after two hours). SN-20 (NOT-14). The cart is server-side and shared by the app and the web. Quiet hours defer the push. The setting is smart.abandonedCartDelayHours.

Options.

1. 2 h after the last cart change, once per cart version, at most once per 24 h, cancelled by a checkout.
2. 2 h, then a second reminder after 24 h. More reach; counts twice in the caps.
3. Next morning at 09:00. Calmer, but the purchase intent has gone.

Recommendation. Option 1.