FR EN DE ES IT

Presentation Guide — OMS Module
Catalogues, customer portal, customer orders and automatic movement orders

Everything you need to understand and show, explained simply, with real examples from the demo database (25 portal accounts, warehouse [ALIMENTATION] - P2, [ALIM] products). The demo database currently holds neither a catalogue nor a customer order: this guide has you create them live — the best demonstration there is.

Prepared on 05/09/2026 · Demo environment: https://app.gse-web.online → organisation demo → account demo@gse-web.online · password gse-web.online (public credentials, the ones on the website's "Demo access" page)
📢 This guide may be freely reused Preparing an internal presentation of the module for your teams? Help yourself: the demo walkthrough, the worked examples and the answers to frequently asked questions in this guide are at your disposal, without restriction. The demo environment (account demo@gse-web.online, password gse-web.online) is public — you can replay every example there.

1The OMS in 2 minutes

OMS = Order Management System, the management of customer orders. In GSE-Web: your customers browse a catalogue you have chosen for them, order from a portal, and every validated order becomes a movement order in the WMS — in the same write, with no retyping. The warehouse worker prepares it, the customer follows progress from "My orders".

The simple analogy It is an online shop plugged straight into your warehouse. The customer fills their basket; at checkout (validation), the picking ticket comes out immediately on the warehouse side. And if, at the customer's, a manager has to sign off purchases, the ticket waits for their signature — by e-mail, with a deputy if they are away.

❌ Before (without OMS)

  • The order arrives by phone or e-mail; someone retypes it into a movement order, sometimes the next day.
  • The customer sees your whole catalogue, including what is not meant for them — or sees nothing at all.
  • The price applied depends on who took the order; the shortage is discovered at preparation time.
  • The customer calls back to find out where their delivery is.

✅ After (with OMS)

  • One catalogue = one warehouse = one site: the customer only sees the stock that concerns them, with public access or on login.
  • The price is resolved by the server, in a fixed order: customer price, else list price, else zero — never invented, never entered by the customer.
  • Validation creates the movement order in the same transaction: there is no such thing as a validated order without a movement order.
  • The customer follows, line by line, what has been prepared and what remains; a backorder is announced to them.
Where to find it in the application In the side menu, a dedicated OMS section groups 3 entries:
🛒 Order management 👥 Customer management 🏪 Catalogue management
On the customer side, the portal is a separate space: a catalogue's public link, a customer login page, the catalogue, My basket, My orders, "My account". On the WMS side, the "OMS" column of Movement order management flags the orders born from a customer order. The section title carries an orange badge with the number of orders awaiting validation.

The section only appears if the user holds at least one of the permissions OMS_ORDERS ("Validate, delete customer orders"), OMS_ACCOUNTS ("Create/edit customer portal users") or OMS_CATALOG ("Create/edit catalogues"). Portal accounts, for their part, hold no internal permission: they are separate identities, with no access to the management application.

Availability: an optional module of v3, enabled for your organisation; it relies on the Projects, Customers and Movement orders modules. Portal accounts do not consume user seats.

2Glossary for newcomers

The terms in the order you will meet them, each illustrated with the demo database (collected on 05/09/2026 — the database is shared, another visitor may have changed it).

Portal account (customer)
The identity a customer uses to log in to the portal. It is separate from the application's users: no internal permissions, no seat consumed, always attached to a customer record. The password is generated on creation and shown once (the administrator can reset it). 25 accounts: Nicolas AUBERT, Antoine BERNARD, Elodie BONNET, Julie CLEMENT… (test addresses at @yopmail.com).
Attached customer record
The customer record that will appear on movement orders (Customers menu). When a portal account is created without an existing customer, the application creates the customer record from the company entered — it is flagged "technical" and hidden from the customer list, but is still recognised wherever it needs to be found. 25 hidden technical customer records (one per portal account) next to the 11 "visible" customers: Le Haras de Jardy, Mairie de l'Etang-La-Ville, DEMIR KEBAB…
Manager, deputy, present / absent
Each account may designate a manager who validates its orders, and a deputy. An account marked "absent" hands over to its deputy. Without a manager and without direct validation, the order is refused on submission — never silently blocked. The 25 demo accounts have neither manager nor direct validation: to be configured before the demo (see §9).
Direct validation
Account option: the order is validated as soon as it is submitted, the movement order is created immediately. This is the "trusted customer" mode. To enable on Nicolas AUBERT for the demo.
Catalogue (public or internal)
A showcase addressed by a slug (the end of the URL), attached to one mandatory warehouse — from which the site derives —, with a visibility of Public (open link) or Internal (login required), prices shown or not, and an optional product list. No catalogue in the database: create alimentation on warehouse [ALIMENTATION] - P2 during the demo.
Visibility scope
The products a catalogue shows: those with a stock line (even at zero) in the warehouses of the catalogue's site, narrowed by the catalogue's list and then by the customer's allowed list, if they exist. A kit is only visible if all its components are. Warehouse [ALIMENTATION] - P2 holds some sixty [ALIM] references: Coca-Cola, Nutella, Badoit, 1664, Thé Vert…
Customer price
A price per customer, product and period: all portal accounts of the same customer share it. Setting a new price closes the previous one. Set a customer price on Coca-Cola 33cl (pack of 24) for Nicolas AUBERT's customer.
Price source
Each order line keeps where its price came from: customer_price (customer price), list_price (the catalogue's sale price), default_zero (no known price → 0, shown as such). On the portal, a manually entered price does not exist. Three products in the same basket, three possible sources.
Customer order — CMD-YYYY-NNNNN
The order submitted from the portal (or entered by a manager). Number drawn from an atomic sequence per organisation and year, lines with a frozen price, comment, requested delivery date, project. The first order of the demo will be CMD-2026-00001.
The statuses of an order
DraftPending validationValidatedProcessed; or Rejected (reason) / Cancelled. The state machine is fixed: a validated order never goes back to "pending". On the management side, the "To validate" filter groups the pending orders.
Validation token
The link e-mailed to the manager, valid for 7 days: it opens a page where they approve or reject (with a reason) without logging in. Once expired, validation is done from the management space. The e-mail goes to the account's manager; if they are "absent", to the deputy.
Automatic movement order
On validation, an outbound movement order is created in the same transaction as the status change, on the catalogue's project and warehouse, in the customer's name. Deleting the order cancels the linked movement order. Visible in WMS → Movement order management, "OMS" column.
Preparation tracking
In "My orders", the customer sees the movement order's status (To process, In progress, Partially prepared, Delivered…), the prepared and remaining quantity per line, and a "Backorder" banner if a partial preparation produced a -R1 order. To show after partially preparing the demo's movement order.
Lot traceability on the portal
For a logged-in customer, if lot quality control is active in the organisation, each lotted stock line exposes its lot number, status, expiry date, warehouse and location. Never for an anonymous visitor. The [ALIM] products carry lots with expiry dates (Coca-Cola: 3 lots).
Stale validations
A scheduled task chases validations that drag on: an order does not wait indefinitely for a manager to open their e-mail. Not applicable in the demo, but worth saying.

3How the data fits together

The chain runs from the site to the movement order. The catalogue is the hinge: it sets the warehouse, hence the site, hence what the customer sees and where their order will be prepared.

🏗️ Site (project)P20 — derived from the catalogue's warehouse; its warehouses define the scope of visible products. If the customer does not manage projects, the catalogue screen generates one automatically for the chosen warehouse ("Generate a project automatically" button, number P-OMS-<warehouse name>), attached in one click
🏬 Catalogue warehouseWarehouse [ALIMENTATION] - P2 — destination of the orders, stock read for availability
🏪 Catalogue"alimentation" — slug, public / internal visibility, prices shown, optional product list
🏢 Customer (customer record)Nicolas AUBERT's customer — customer prices, allowed products, address
👤 Portal accountnicolas.aubert@… — manager, deputy, present / absent, direct validation, accessible projects and catalogues, delivery address
🧾 Order CMD-2026-00001 → movement orderLines with frozen price and source; on validation, an outbound movement order on P20 / [ALIMENTATION] - P2

And around this tree, 5 satellites

  • Customer prices — per customer, per product, per period; shared by all the customer's accounts.
  • Validation tokens and e-mails — request to the manager, confirmation to the customer, reasoned rejection; chasing of stale orders.
  • Movement orders, reservations and backorders — held by the WMS's Movement orders module; that is where stock moves.
  • Availability — the portal reads the available stock (physical − reserved) of the catalogue's warehouse.
  • Published lots — for the logged-in customer, when lot quality control is active.
The sentence to remember Catalogue → warehouse → site: when a customer submits their order, GSE-Web generates the movement order in the WMS, attached to the warehouse's site — without anyone retyping anything.

4Guided tour, screen by screen

In teaching order: first the configuration (catalogues, customers), then the portal as the customer sees it, then order management and the movement order on the WMS side.

4.1 — "OMS: Catalogue management" (start here: this is the configuration)

What it is for: deciding what each customer can see and order, from which warehouse, with or without prices, in open access or on login.

How it works:

  1. New catalogue: a name and a slug (the end of the public URL), the warehouse (mandatory — the site is derived from it and shown read-only), the visibility Public (open link) or Internal (login required), whether prices are shown, an optional product selection (limited to the warehouse's stock), and the "Catalogue enabled" switch.
  2. The list shows each catalogue with its public link, its number of products and its enabled / disabled state. A built-in explanatory box ("What is a catalogue?") sums up the catalogue → warehouse → site link.
  3. The same catalogue can be opened to several accounts; an account can access several catalogues.

With the demo data: no catalogue. Create alimentation on warehouse [ALIMENTATION] - P2 (site P20), public, prices shown: some sixty [ALIM] products appear at once.

4.2 — "Customer management" (who orders, and who has to say yes)

What it is for: creating the portal accounts and setting, for each one, the validation workflow and the accessible catalogues.

How it works:

  1. New user: last name, first name, e-mail, company (the customer record is created if needed), delivery address (mandatory: it feeds the movement order), availability "Present (receives e-mails)" / "Absent (uses deputy)".
  2. Validation workflow: a manager, an optional deputy — or direct validation.
  3. Access: the accessible projects, then the associated catalogues ("All catalogues" requires "All projects").
  4. On creation, the generated password is shown once and sent by e-mail; Reset password generates a new one. An account is archived and restored, it is not deleted.
Anti-mistake subtlety to mention No account without a customer record: if it cannot be created, the account creation is cancelled with a clear message. That is what guarantees every order will have an identifiable customer on its movement order.

With the demo data: 25 accounts, all "present", with neither manager nor direct validation. Open Nicolas AUBERT, enable direct validation, give him access to project P20 and the "alimentation" catalogue, reset his password so you can log in to the portal.

4.3 — The portal, customer side (open it in a second tab)

What it is for: letting the customer browse, order and follow — without ever entering your management application.

How it works:

  1. Anonymous, on a public catalogue's public link: the products, the sale prices if the catalogue shows them, never a customer price, never a lot. On an internal catalogue: "Login required".
  2. Logged in: the catalogue restricted to their access, the warehouse's availability, the resolved prices (customer price first), the lots if quality control is active.
  3. My basket: quantities, then Confirm order — comment, address if different, requested delivery date, project. Result: "Order created! Order number: CMD-…".
  4. My orders: order status, movement order status, prepared and remaining quantities per line, "Backorder" banner where applicable.
Anti-mistake subtlety to mention An account with neither manager nor direct validation cannot order: the application says so at confirmation time ("no manager designated for this account"). Nothing goes off into the void.

With the demo data: log in with nicolas.aubert@yopmail.com (password reset in step 4.2); add Coca-Cola 33cl (pack of 24), Nutella and Badoit to the basket.

4.4 — "Order management" (validate, reject, track)

What it is for: handling the orders received: validating them (which creates the movement order), rejecting them with a reason, tracking the associated movement order, marking the order processed.

How it works:

  1. At the top, the counters: total, to validate, validated, rejected; filters by status, period, search by number or customer.
  2. Each card: date, amount, requested delivery, and the Movement order block — "Movement order created: status 'To process'", then the movement order's current status. If the movement order was missing (data taken over from a previous version), a button offers to recreate it.
  3. The lines: description, quantity, unit price, total; "Generate PDF", "Copy number".
  4. Actions: Validate, Reject (reason required), Cancel, "Mark as processed", Delete — with a warning that the associated movement order will be cancelled.
The rule to state during the demo Validating and creating the movement order is a single write: a double click on "Validate" does not create two movement orders, the second call is refused. And there is no such thing as a validated order without a movement order.

With the demo data: the order created in the previous step appears (validated directly if the account is on direct validation, otherwise "To validate").

4.5 — The movement order on the WMS side (Movement order management → Process a movement order)

In WMS → Movement order management, the OMS column carries the customer order number. The movement order follows exactly the movement order circuit (see the WMS guide, §4.5): claimed by a picker, prepared line by line — partial possible, automatic backorder —, delivered with "Collected by", closed. Each step feeds back to the portal in "My orders".

With the demo data: partially prepare CMD-2026-00001's movement order (for instance 20 Coca-Cola out of 24): on the customer side, the status becomes "Partially prepared" and a "Backorder" banner appears.

5From basket to movement order, step by step

The core mechanism: a price resolved by the server, a direct or delegated validation, a movement order created in the same write, a preparation the customer follows. Three examples.

Example 1 — price resolution

1. Customer price of the customer
€12.50
valid on the date → customer_price
2. Otherwise sale price
€15.00
current catalogue price → list_price
3. Otherwise
€0.00
shown as such → default_zero

In Nicolas AUBERT's basket: the Coca-Cola has a customer price → €12.50; the Nutella has none but has a sale price → €15.00; a product with neither → €0.00, visible as such. The line keeps its source. An unknown price is never invented, and the customer never enters a price.

Example 2 — direct validation or N+1 workflow

A useful anecdote: in the previous version, an order had once been validated without its movement order being created (the separate call had failed). In v3 that is structurally impossible: both writes are in the same transaction.

Example 3 — partial preparation as seen by the customer

  1. Order: Coca-Cola 24, Nutella 6, Badoit 12. When the movement order is confirmed, the WMS reserves what exists (24 / 6 / 12 if stock allows).
  2. The picker serves 20 Coca-Cola, 6 Nutella, 12 Badoit → movement order Partially prepared, backorder -R1 created for the 4 remaining Coca-Cola.
  3. "My orders": movement order status "Partially prepared", prepared quantities 20 / 6 / 12, remaining 4 / 0 / 0, banner "Backorder no. … — following a partial preparation".
  4. Delivery of the movement order ("Collected by") → "Partially delivered"; when the backorder is prepared and delivered in turn, the customer sees the remainder.
The 2 golden rules to remember (classic trick questions) 1️⃣ A validated order always has its movement order: both are written in the same transaction, and deleting the order cancels the movement order.
2️⃣ The customer never enters a price: the server resolves it in a fixed order (customer price → sale price → 0) and each line keeps its source.

6Which price, which products? The decision rules

Price = customer's negotiated price (valid on the date)catalogue sale price0

Visible products = stock lines of the site's warehousescatalogue listcustomer's allowed products

Destination = the catalogue's warehouse

Both lists are optional: when empty, they restrict nothing. A zero stock remains visible (the customer sees "unavailable", not a gap).

Illustrations

SituationPrice retainedSource
Valid customer price (€12.50), sale price €15.00€12.50customer_price
Expired customer price, sale price €15.00€15.00list_price
Neither customer price nor sale price€0.00default_zero
Catalogue without price displayamounts not shownthe line still keeps its source
Anonymous visitor on a public catalogue with pricessale price onlynever a customer price
SituationVisible on the portal?Why
Product at stock 0 in the site's warehouseYesit has a stock line; it appears as unavailable
Product in stock in a warehouse outside the siteNooutside the catalogue's scope
Kit with a component absent from the siteNoa kit is only visible if all its components are
Product outside the customer's allowed listNoinvisible, and refused if the order is forced
Projects module disabledExplicit refusalnever "all products" by default
How to sell it in one sentence "Each customer sees exactly the stock of their site, at their price, and not one product more; what they order reaches the warehouse as a movement order, without anyone retyping anything."

7How it ties into the WMS and the other modules

The OMS holds no stock: it reads the WMS to show availability and entrusts it with the movement order. Here is who does what, step by step.

Step of the circuitModuleWhat the OMS doesDemo example
1. The catalogue is createdProjects / WMS → OMSDerives the site from the chosen warehouse; reads the stock lines of the site's warehouses to build the scope."alimentation" catalogue on [ALIMENTATION] - P2 (P20)
2. The account is createdCustomers → OMSRequires a customer record; creates it from the company if needed (technical record, hidden from the customer list).Nicolas AUBERT and his customer record
3. The customer browsesWMS → OMSShows the availability (physical − reserved) of the catalogue's warehouse; publishes lots to the logged-in customer if quality control is active.Coca-Cola: 3 lots with expiry dates
4. The order is validatedNotifications → OMS7-day token, e-mail to the manager or deputy, confirmation or reasoned rejection to the customer; chasing of stale validations.Account with a manager
5. The movement order is createdOMS → WMS (movement orders)Creates an outbound movement order in the same transaction, on the catalogue's project and warehouse, in the customer's name; confirming the movement order reserves existing stock."OMS" column of Movement order management
6. The movement order is prepared, delivered, shippedWMS → OMSFeeds back to the portal the movement order's status, prepared and remaining quantities, the backorder."My orders" after partial preparation
7. Everything is tracedAuditValidations, rejections, cancellations, deletions and account creations are logged, like every write.Audit log (ADMIN section)
To say during the demo "The OMS is the shop window; the WMS is the back room. The customer's order becomes a movement order like any other — same picker, same screen, same traceability. What changes is that the customer sees progress without calling you."

8The complete workflow in 9 steps

  1. Attach the warehouse to a siteA catalogue requires a warehouse that has a project: that is what will carry the movement orders.
  2. Create the catalogueSlug, warehouse, public or internal visibility, price display, optional product list.
  3. Set the customer's pricesOptional: without a customer price, the sale price applies.
  4. Create the portal accountManager and deputy, or direct validation; accessible projects and catalogues; delivery address.
  5. The customer browses and ordersAnonymous or logged in; basket, comment, requested date; "Order created! CMD-…".
  6. ValidationDirect, or by the manager from their e-mail (7 days), or from "Order management".
  7. The movement order is created and preparedConfirmation (reservation), claim, line-by-line preparation — partial possible, automatic backorder.
  8. Delivery or shipment"Collected by"; grouping into a shipment if needed; "Mark as processed" on the OMS side.
  9. The customer followsMovement order status, prepared and remaining quantities, backorder — in "My orders".

9Suggested demo walkthrough (~15 min)

Before you start Open https://app.gse-web.online, log in with demo@gse-web.online, password gse-web.online (organisation demo). Have a second browser (or a private window) ready for the portal. The demo database holds neither a catalogue nor a customer order (state collected on 05/09/2026; the database is shared, check before you start): steps 1 and 2 are preparation to do before the meeting if you want to save 4 minutes, or live if you want to show how simple the setup is.
Step 1 · Catalogue management — a warehouse opened to the customer (2 min)

Menu OMS → Catalogue management, New catalogue: name "Alimentation", slug alimentation, warehouse [ALIMENTATION] - P2 (site P20 appears on its own), Public visibility, prices shown, enabled. Save: the public link appears, with the number of products.

"A catalogue is a warehouse of yours opened to a customer: they only see what is in it, and their orders land on the right site."
Step 2 · Customer management — who orders, and who has to say yes (2 min)

Menu OMS → Customer management, open Nicolas AUBERT: show "Present / Absent", the validation workflow (manager, deputy), direct validation, the accessible projects and catalogues. Enable direct validation, grant access to project P20 and the "Alimentation" catalogue, then Reset password and note it down.

"You decide who orders on their own and who has to be approved — by e-mail, with a deputy if the boss is away. And these accounts consume no seats."
Step 3 · The portal — what the customer sees (3 min)

In the second browser, open the catalogue's public link without logging in: the [ALIM] products and their sale prices, no lots. Then log in with nicolas.aubert@yopmail.com: availability, resolved prices, lots folded under each product (Coca-Cola: 3 lots with expiry dates).

Add to the basket Coca-Cola 33cl (pack of 24) × 24, Nutella × 6, Badoit × 12; Confirm order with a comment and a date. "Order created! Order number: CMD-2026-00001".

"The same catalogue shows the public price to a visitor and your negotiated price to the logged-in customer. No call, no e-mail: the order is with you before the customer has closed the page."
Step 4 · Order management → the movement order in the WMS (3 min)

Back in the application: the OMS section badge has changed. OMS → Order management: the order is there, validated (direct validation), with "Movement order created: status 'To process'". If you had left a manager, show Validate and the mandatory reason of Reject.

Then WMS → Movement order management: the OMS column carries CMD-2026-00001. Open the movement order in Process a movement order, claim it and prepare 20 Coca-Cola out of 24, the rest in full: status Partially prepared, backorder -R1 created.

"Validation and the movement order are a single write: there is no such thing as a validated order without a picking order. And the warehouse worker works exactly as for any other movement order."
Step 5 · "My orders" — the customer follows without calling (2 min)

In the customer's browser, My orders: movement order status "Partially prepared", 20 prepared / 4 remaining on the Coca-Cola, banner "Backorder no. … — following a partial preparation".

"Your customer no longer calls to find out where their order is: they see what has been prepared, what remains, and the number of the backorder that will follow."
Step 6 · Customer price — the same product, two prices (2 min)

From Nicolas AUBERT's customer record (or the customer prices screen), set a customer price on the Coca-Cola (€12.50). Reload the catalogue on the customer side: the price has changed for him alone; anonymously, the sale price has not moved.

"The price is resolved by the server, in a fixed order: your price negotiated with this customer, else your sale price, else zero shown as such. The customer never enters a price."
Plan B in a minute Catalogue and account prepared in advance, then steps 3, 4 and 5 only — "they order, you validate, the movement order exists, they follow" — in 8 minutes.

10FAQ — tricky questions and ready answers

"Do my customers need a GSE-Web account?"

No. A customer account in the OMS portal is a separate identity: it has no access and no permission in GSE-Web. You can create as many as needed.

"Can the catalogue be browsed without logging in?"

Yes, if the catalogue is public: the visitor sees the products and, if you have chosen so, the sale prices — never a customer price, never a lot. Ordering always requires an account. An internal catalogue is invisible to an anonymous visitor, to the point of responding as if it did not exist.

"What happens if stock is insufficient?"

The order goes through anyway; the movement order is confirmed with what actually exists and is never blocked by a shortage. At preparation, what is not served becomes a backorder that the customer sees in "My orders". Stock never goes negative.

"Can the customer choose or negotiate their price in the basket?"

No. On the portal, a manually entered price does not exist: the server resolves the price (customer price → sale price → 0) and freezes the source on the line. Customer prices are set on the management side, per customer.

"What if the manager does not respond?"

The validation link is valid for 7 days; if the manager is marked absent, the deputy receives the e-mail; a scheduled task chases stale validations. Once the deadline has passed, the link expires and validation is done from "Order management".

"Can an account with neither manager nor direct validation order?"

No: the application refuses when the basket is confirmed, with an explicit message ("no manager designated for this account"). Nothing goes off into the void and nothing is silently blocked.

"Why does the catalogue require a warehouse?"

Because the warehouse decides everything: the site, hence the scope of visible products, and the destination of the movement order. A catalogue without a warehouse used to produce orders that blocked at validation; it is refused at creation.

"Is stock decremented at ordering time? At shipping time?"

Neither. Stock is reserved when the movement order is confirmed, written by preparation, and delivery or shipment only records the handover. This is the standard movement order circuit (see the WMS guide).

"Do my suppliers go through the OMS?"

No: purchase orders, receipts and supplier invoices belong to the procurement module (PMS). The OMS is your customers. Both meet in the WMS, which holds the stock.

"How many customers can be created?"

Portal accounts do not consume user seats; their number is not what sizes your plan. Each account stays attached to a customer record, and is archived rather than deleted.