Front Systems
Omnium integrates with Front Systems to sync products, orders, customers, inventory and live cart calculations from 'carts' in POS
Stores
Stores are not synchronized automatically between Omnium and Front Systems.
To ensure inventory synchronization works correctly, each store in Omnium must be manually configured with external IDs that map to the corresponding identifiers in Front Systems:
- FrontSystemStockId → Maps to the StockId in Front Systems
- FrontSystemStoreId → Maps to the StoreId in Front Systems
Both IDs should normally be added as external IDs on the warehouse (store) in Omnium.
In some cases, you do not need to map StockId if the store in Omnium has been created with the same ID as in Front Systems (by convention).
However, in most cases explicit mapping is required.
When using explicit mapping, ensure that connector property IsStockIdExternalId is set to true.
Orders
Overview
'Click And Collect' and 'Ship From Store' orders can be created in Front Systems as 'Omnichannel orders'.
- Enable 'Omnichannel order' creation in Front System by setting connector custom property IsOmnichannelOrderEnabled to true
- Orders are exported to Front Systems using the ExportOrder workflow step
Click & Collect
Orders with ordertype "ClickAndCollect" in Omnium are sent to Front Systems as "reserved orders" in Front Systems. When updated in Front Systems, and event will trigger and update the order in Omnium. The changes that are reflected in Omnium includes:
- Order completion (order picked up)
- Order cancellations
- Partial cancellations (order line cancelled/quantity changed)
- Order line updates
Ship from Store
- If not type 'ClickAndCollect', it will be sent as 'Ship from store' order - regardless of order type. The main difference is that is contains both payment and shipment information.
- Otherwise it will listen to events from Front Systems just as the click and collect orders do
Sales posting Orders
- Completed online orders that are exported to Front will be posted as sales, which triggers inventory updates in Front Systems and records the order for financial reporting.
In-store Purchases
- POS orders (in-store purchases) are continuously retrieved by Omnium from Front via Scheduled Task FrontSystemsOrderScheduledTask in Omnium.
Workflow Configuration
- Use Export Order workflow step with property
Connector/FrontSystems
. - If the order has a Completed status, it will be exported as a Sale (not as an Omnichannel Order).
- For returns, add Export Order workflow step to statuses Partially Returned and Returned.
- This exports the return to Front Systems for sales posting and inventory adjustments.
Promotions
- Omnium is the master system for promotions.
- If activated in Front, all POS lookups are directed to Omnium, which calculates the correct prices.
- Basically what happens is that every time an item is scanned in POS, it is treated as a cart in Omnium and recalculated and returned to Front Systems with the correct prices and discounts
- Supports all Omnium promotion types, such as:
- "3 for 2" campaigns
- Loyalty club pricing
- Percentage discounts
- Ensures seamless promotion handling in Front POS.
Products
Front as Master
- Omnium syncs product base data from Front.
- Product enrichment can be performed in Omnium or in a third-party system.
Omnium as Master
- Omnium continuously updates product data in Front Systems.
- Minimum required properties: ProductId, SkuId, EAN/GTIN, Name.
- You can exclude certain products from syncing to Front by adding a custom property with key:
IsExcludedFromFront
and value:true
. - By default, products are exported with variants created as Product Sizes in Front Systems.
- If the connector property
IsVariantSplitToSingleProduct
is set totrue
, each variant will be created as a separate product in Front Systems. This allows:- Different prices per variant
- Simpler and more reliable product syncing if products are frequently split or merged (e.g., merging multiple products into a single product with multiple variants)
- Note: Enabling this setting('IsVariantSplitToSingleProduct') may result in a less optimal in-store experience, since different sizes of the same product will appear as separate items in the POS.
Field Mapping (Omnium → Front Systems)
The following table shows how Omnium product/variant data is mapped when exported to Front Systems:
Front Systems Field | Omnium Source |
---|---|
Description | Variant.Description (fallback: Product.Description, max 2000 chars) |
ExtId | Variant.SkuId (fallback: Product.SkuId) |
Name | Variant.Name (fallback: Product.Name) |
Color | Variant.Color (fallback: Product.Color) |
Gender | Variant.Gender (fallback: Product.Gender, default empty string) |
Variant | Product.SupplierSkuId (fallback: Product.ProductId) |
Number | Variant.SkudId OR by adding connector property 'NumberPropertyName' which should point to a property Key on the product, which wil then be used instead |
Price | Lowest available price on the variant / fallback to product |
Season | Variant.Season (fallback: Product.Season, fallback: connector option DefaultSeason , fallback: All ) |
IsDiscontinued | Inverse of Variant.IsActive (fallback: inverse of Product.IsActive) |
Upt | Product.Modified (last modified timestamp) |
SubgroupName | Outermost product category under GroupNameCategoryRoot (fallback: connector option DefaultGroupName , fallback: Assortert ) |
GroupName | First child category under GroupNameCategoryRoot (fallback: Assortert ) |
IsWebAvailable | Always true |
IsStockProduct | Always true |
Images | Variant.Assets URLs (fallback: Variant.MainImageUrl, then Product.Assets URLs, then Product.MainImageUrl) |
Cost | Variant.Cost (fallback: Product.Cost if > 0) |
ProductSizes | Always created as empty list (populated later if applicable) |
Brand | Product.Brand (fallback: connector option DefaultBrand , fallback: Annet ) |
Tags | Product.SupplierName (only if IsSupplierNameAddedAsTag = true in connector settings) |
Prices and price lists
Front as Master
- Product prices are synced from Front to Omnium as part of the product synchronization process.
Omnium as Master
Omnium can export product prices as prices lists to Front Systems using the scheduled task 'FrontPriceListScheduledTask'. The export builds or updates a Front price list per configured market, using GTIN as the unique key for each price entry and skipping unchanged prices to minimize writes.
Naming
Price list name format:
{PriceListPrefix} {Market.Currency} RRP {Market.MarketName}
If PriceListPrefix
is empty, only currency, "RRP", and market name are used. PriceListPrefix can be defined as a property on the connector level.
Market Scope
- Markets to export are controlled by connector property
EnabledPriceListMarketIds
(comma-separated list of market IDs). - For each market ID, Omnium loads market data and uses the market’s
ProductContentLanguage
to select products for pricing.
Data Source and Mapping
- Each price entry is keyed by
Gtin
; duplicates are removed per export run. - Only one price per GTIN is posted.
Create/Update Behavior
- If a price list with the computed name exists in Front, Omnium fetches its current prices.
- For each GTIN:
- If the new price equals the existing price, it is skipped (counted as “unchanged”).
- If different or not present, it is included in the update batch.
Deletions
- Existing prices in the Front price list that are not present in the current Omnium export set are considered for deletion.
- Deletions are controlled by connector setting
IsFrontPriceDeletionEnabled
.
Scheduling
- Implemented as a scheduled task:
FrontPriceListScheduledTask
.
Connector Settings
EnabledPriceListMarketIds
: Comma-separated list of market IDs to export (required for export to run).PriceListPrefix
: Optional text prefix added to the generated price list name.IsFrontPriceDeletionEnabled
: Boolean flag that enables deletion of prices no longer present in Omnium’s export set.
Notes
- GTIN is the unique identifier for price entries.
- The export uses per-market language filtering to ensure correct product-price selection.
- Posting is idempotent for unchanged prices; unchanged items are skipped to reduce load.
Inventory
Overview
Omnium synchronizes store inventory from Front Systems using the scheduled tasks FrontSystemsInventoryScheduledTask and FrontSystemsInventoryFullImportScheduledTask. Front Systems is the master system for store stock, and Omnium updates its records continuously to ensure that online and in-store stock levels remain aligned.
Scope
- All configured stores in Omnium are included in the synchronization.
- (Edge case) If multiple Front Systems companies are connected, each group of stores uses the correct credentials (based on the
FrontSystemsCompany
property).
Behavior
- Inventory items are retrieved from Front Systems and updated in Omnium at regular intervals.
- Only items with valid warehouse codes are processed.
- Remember: The StockId in Front Systems must match ExternalId FrontSystemStockId on the warehouses (stores) in Omnium
- If an item has been removed or is no longer present in Front:
- It may be deleted from Omnium, or
- Its inventory count may be set to 0, depending on configuration.
- Gift card SKUs are ignored
- By default, Omnium should fetch stock items and match by GTIN. Please ensure that property IsStockFetchedByGtin is set to 'true' in the connector properties
- If not, all products in Omnium must have a corresponding FrontSystemsId configured in their external Id. NOTE! This will be depracted
- If your products do not have the same value for SkuId and EAN/GTIN, please make sure that you property IsSkuIdLookup is set to true. Omnium will then map the inventory to the right sku based on the gtins returned by Front.
Deletions
- Deletions are controlled by connector settings:
- If removed items should be updated, the stock level is set to
0
. - If not, the items are fully deleted from Omnium.
- If removed items should be updated, the stock level is set to
- Reserved inventory is always preserved (items with reserved quantities are not deleted without first being adjusted).
Notes
- Inventory synchronization runs as a scheduled task: FrontSystemsInventoryScheduledTask which fetches changes since last run. FrontSystemsInventoryScheduledTask fetches all inventory from Front, and should be run once per day to pickup inventory items in Front that has changed but not neccessary been marked as modified in Front Systems.
Gift Cards
If you are going to use gift cards that will work in both Front Systems and for online purchases using Omnium, please follow the guidelines on how to setup gift cards in Omnium. After that is done, please do the following:
- Change the 'ProviderName' for the gift card payment method to "FrontSystems".
- For the 'VirtualShip' status, please add an "ExportOrder" workflow step, to register the sale in Front Systems:
- Modifiy the Front Systems connector setting and add 'IGiftCardProvider':
Please note that are some restrictions:
- It is not possible to use the "Import" feature for gift cards in Omnium.
- The gift card search in Omnium's UI is very restricted as gift cards are not stored in Omnium. You are only able to search for exact gift card codes.
Purchase Orders
- Omnium sends purchase orders directly from Omnium to Front.
Multi-company Setup
Omnium supports integration with multiple Front Systems companies, even when they do not share the same Front instance.
- Enable by setting
EnableMultiCompany
totrue
in the Front Systems connector properties. - For Front Systems company-specific users, add properties where the key is the company name and the value is that company’s API key. Example: key
SomeCompany
with valuethis_is_an_api_key
. - For each store in Omnium, add a property to link it to the correct Front Systems company:
- Store property key
FrontSystemsCompany
- Store property value equal to the company key you added above (for example
SomeCompany
)
- Store property key
This ensures each store is associated with the correct Front Systems company and API key.