1. Platform Overview

1.1 What HandlaOnline is

HandlaOnline is an integrated digital commerce platform designed to run B2B and B2C webshops, a content management system (CMS), and an order/customer operations layer on a single technical foundation. It is built and operated by DataPartner and is positioned for Swedish and Nordic companies that need to digitalise sales while keeping master data, pricing, discounts and order flow synchronised with their back-office (ERP) system.

The platform is more than a webshop. It is a commerce operations system, combining:

• a storefront for B2C consumers and B2B business buyers,
• a CMS for marketing pages, forms, documents and media,
• a product information layer synchronised with an ERP (Visma-shaped data),
• a customer & company directory mirrored from the ERP,
• an order capture, validation, and export pipeline with email confirmations and XML export,
• an operations dashboard for administrators,
• and an integration layer (XML sync, REST API, Klarna Checkout).

Confidence: VERIFIED.

1.2 What it is used for

HandlaOnline is used by companies that need to:

• Sell digitally to businesses (B2B) with customer-specific prices, discount letters (kundrabattbrev), invoice payment and contracted terms.
• Sell directly to consumers (B2C) with a fast, modern storefront and Klarna Checkout as the payment experience.
• Operate both modes from a single platform with a shared catalog, shared media, and shared content.
• Keep their webshop catalog, customers, contacts, prices, discounts and orders synchronised with their ERP so that web and finance work on the same data foundation.
• Run marketing pages, blog posts, downloadable documents, contact forms and other content-driven activities through an admin dashboard.
• Provide their B2B customers with self-service tools: order history, order templates ("mallorder"), reorder from a previous order, calendar view of orders, and delivery management.

1.3 Core value proposition

Confidence: VERIFIED.

1.4 Where HandlaOnline fits in the operating model

HandlaOnline is positioned between three operational domains:

1. Front-of-house commerce — public storefront, category browsing, product pages, search, cart, checkout, customer self-service.
2. Back-of-house operations — admin dashboard for catalog, content, customers, orders, settings, shipping, discounts, integrations.
3. System layer — XML sync with the ERP, REST API for external machines, payments (Klarna), email pipelines, sitemap and SEO.

This three-layer model means that one platform handles what the customer sees, what staff does, and how data moves between systems — without requiring separate webshop, CMS, and middleware tools.

2. Business Model Overview

2.1 Three operating display modes

HandlaOnline supports three high-level "display modes" that determine how the storefront behaves. The active mode is configured per installation by the Super Admin and stored as the {{PH_1}} in the system display table.

Confidence: VERIFIED.

2.2 Multi-segment selling on one site

The platform is designed so that a single installation can serve mixed audiences. In a B2C installation, an authenticated B2B customer can still receive their own prices and addresses because pricing is driven by the {{PH_1}} (customer number) and {{PH_2}} (customer discount/agreement number) attached to their account.

Conversely, a B2B installation can declare which customer category ({{PH_1}}) represents a "private customer" so the platform applies consumer-style rules to that segment without breaking the B2B model. This is configured under Admin → Customer settings → choice_off_private_customer.

Confidence: VERIFIED.

2.3 Commercial behaviours that change by mode

Confidence: VERIFIED.

2.4 Revenue scenarios supported today

1. Pure B2B operations — Companies sell to vetted business customers using login-gated catalogs, customer-specific pricing, invoice payment, template orders for repeat purchases, and ERP-synced order export.
2. Pure B2C retail — Companies sell consumer products using public browsing, Klarna Checkout, and standardised confirmation emails.
3. Mixed model — Single site serves both businesses and consumers, distinguishing by login + customer category.
4. Catalog-and-quote (CMS + login wall) — Show product information publicly but require login to see prices and place orders.

3. Platform Architecture Overview

This section provides the minimum architectural context needed by an enterprise customer to understand how the system is deployed, integrated, and operated. It deliberately avoids low-level developer detail.

3.1 High-level building blocks

┌─────────────────────────────────────────────────────────────┐
│                       Front-of-house                        │
│  Storefront · Cart · Checkout · Klarna · User Self-Service  │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│                       Operations layer                      │
│  Admin Dashboard · CMS · Catalog · Orders · Customers       │
│  Settings · Shipping · Marketing · Reporting                │
└─────────────────────────────────────────────────────────────┘
                              │
┌─────────────────────────────────────────────────────────────┐
│                       System layer                          │
│  XML Sync (Visma) · REST API · API Keys · Email · Sitemap   │
│  Statistics · Session logs · Security headers · CSP         │
└─────────────────────────────────────────────────────────────┘

Confidence: VERIFIED.

3.2 Front, admin, and super-admin

The platform exposes three clearly separated user-facing areas:

Each area uses its own header/menu layout but shares the same underlying engine.

Confidence: VERIFIED.

3.3 Integration model

HandlaOnline integrates with the surrounding business systems through three well-defined channels:

1. XML Sync (file-based, batch) — The dominant integration path. The ERP drops XML files into a sync folder; the platform parses, validates, stages, and applies them through stored procedures into the production tables. Outgoing orders are exported as Visma-shaped XML for re-import into the ERP.
2. REST API (JSON, machine-to-machine) — A versioned API (/api/v1/...) protected by API keys and secrets, supporting structured sync, status checks, customer endpoints and an order-export endpoint scaffold.
3. Klarna Checkout — Direct API integration for B2C payment, including iframe rendering, server-side push (webhook) confirmation, and Klarna order acknowledge.

Confidence: VERIFIED.

3.4 Data foundation

The data model can be grouped into three families:

Confidence: VERIFIED.

3.5 Deployment context

• The platform runs as a PHP web application (CodeIgniter 4 framework) backed by a MySQL database.
• The storefront uses Vue.js 3 (mounted across templates) and the Metronic admin theme for the dashboards.
• A scheduled CLI command (php spark sync:files) drives XML synchronisation; another (php spark generate:sitemaps) regenerates the sitemap.
• Email is delivered via the standard email transport configured per installation, and every outbound mail is logged in sent_emails.

Confidence: VERIFIED for general deployment shape; per-installation environment details (server, cron schedule) live in the deployment plan.

4. B2B Commerce Capabilities

4.1 Overview

The B2B side of HandlaOnline is designed for business buyers who already have a relationship with the seller — they have a customer number (kundnr) in the ERP, possibly a price agreement (kundrbtnr / prislista), and they pay by invoice. The platform delivers their personalised assortment, applies their negotiated pricing, and exports their order back to the ERP for fulfilment and invoicing.

Confidence: VERIFIED.

4.2 Business value

4.3 Main features

4.3.1 Customer recognition

Each B2B buyer is bound to a Visma customer record (visma_kund) through a contact record (visma_kundkontakt). When the user logs in, the platform:

• loads the company (kund),
• loads the contact (kundkontakt),
• attaches the kundnr, kontaktid, kundkat (customer category),
• determines the price list (prisl) and discount-letter number (kundrbtnr).

This is then used by every pricing and display decision downstream.

Confidence: VERIFIED.

4.3.2 Customer-specific pricing — kundrabattbrev

Prices are resolved from three priority levels (the "kundrabattbrev" / customer discount letter):

1. Priority 1 — specific article on the customer's price list.
2. Priority 2 — article group on the customer's price list.
3. Priority 3 — whole price list fallback.

The result is materialised into web_kundrbtnr_pricces_* tables during XML sync so prices and discounts can be displayed quickly. A real-time lookup service (KundRabattBrevService) is also present in the codebase.

Confidence: VERIFIED (materialisation pipeline confirmed; live UI of discount letter is PARTIAL).

4.3.3 Catalog gating

The B2B mode supports two flags:

4.3.4 Multiple delivery addresses

At checkout, the system computes up to three address candidates:

1. Leveransadress 1 — primary delivery address from the company record.
2. Leveransadress 2 — invoice address used as delivery fallback.
3. Leveransadress 3 — the contact person's own address (kundkontakt).

Only addresses that pass validation are shown.

Confidence: VERIFIED.

4.3.5 Template orders ("mallorder")

B2B buyers can save a previous order as a template, give it a name, and use it repeatedly. The user area exposes:

• a list of templates with filtering,
• a calendar view of order activity (FullCalendar),
• per-template editing (lines, quantities, notes),
• "Restore to original" to undo changes,
• "Copy" and "Delete" actions,
• "Add to cart from template" to spin up a fresh order from a saved template.

Confidence: VERIFIED.

4.3.6 Reorder

A simple "Beställ igen" action converts any previous web order — or a Visma orderrow — back into a cart, automatically matching the customer's current prices.

Confidence: VERIFIED.

4.3.7 Per-row and per-order notes

B2B buyers can attach:

• row remarks (per cart line) stored in web_cart_rowtxt,
• order remarks (whole-order comment) stored in web_cart_ordertxt.

These travel through to the order record and into the XML export and the confirmation emails.

Confidence: VERIFIED.

4.3.8 Invoice payment

B2B orders are sent without a card flow. The payment method is recorded as "Invoice" (Faktura). The order is exported to the ERP as XML and invoiced from there.

Confidence: VERIFIED.

4.4 Operational notes

• B2B users who attempt Klarna Checkout are explicitly blocked (the system enforces "B2B = invoice, B2C = Klarna" to protect data integrity).
• The order is wrapped in a database transaction with logging into web_order_logs.

4.5 Limitations

• Card payments for B2B are not currently activated.
• The interactive customer "discount letter" view (front of dashboard) is not fully exposed — material data is generated, but a dedicated front display module is PARTIAL.

5. B2C Commerce Capabilities

5.1 Overview

The B2C side is intended for consumer retail: an open public storefront, public prices, standard checkout, and Klarna Checkout as the payment experience.

Confidence: VERIFIED.

5.2 Business value

5.3 Main features

• Public product detail pages with images, attributes, related products and inquiry form.
• Public category pages with paginated, filterable product lists.
• Wishlist (per customer; persisted to web_wishlist).
• Product inquiry email ("Skicka produktinquiry") for items that need contact instead of immediate purchase.
• Optional B2B/B2C toggle in B2C installations (so the same site can serve both private and business consumers when configured).
• Klarna Checkout integration with server-side push confirmation.
• Standardised confirmation emails to both customer and admin.

Confidence: VERIFIED.

5.4 Operational notes

• The platform tracks statistics per page (which products/categories are visited) and aggregates them in the admin dashboard.
• Session activity is recorded with cart snapshots, abandon detection, and auto-logout logging.

5.5 Limitations

• A dedicated promotion/coupon module is not exposed in the current admin menu (campaign menu entries exist but are commented out in the navigation). Discounts arrive primarily through price-list logic.

6. Dashboard Overview

HandlaOnline ships with three dashboard layers, each with its own navigation and audience.

6.1 Admin Dashboard (/admin)

The admin dashboard is built on the Metronic theme and is organised into the following top-level menu sections:

Confidence: VERIFIED (menu layout, page list, and route mapping confirmed in the navigation views).

6.1.1 Default landing

The Admin Main page (/admin/main) shows today's most-visited categories and exposes JSON endpoints for getCategoryStats and getProductStats to display top categories/products with GeoIP-resolved visitor locations.

6.2 Super Admin Dashboard (/sadmin)

The super admin dashboard is intentionally compact and operational:

Confidence: VERIFIED.

6.3 Customer Dashboard (/myaccount)

The customer dashboard is rendered on the storefront layout. The available tabs depend on enabled modules:

Confidence: VERIFIED.

7. User Roles & Permissions

7.1 Defined groups

The platform uses CodeIgniter Shield for authentication with the following groups configured:

Confidence: VERIFIED.

7.2 Permission matrix (high level)

Confidence: VERIFIED.

7.3 Route-level guards

Access to backend areas is enforced through filters:

Confidence: VERIFIED.

7.4 Display-mode role behaviour

When an admin or superadmin is logged in to the storefront, the platform automatically renders the CMS display mode and suppresses the category navigation, so administrators always see the content-only view of the site they manage. This avoids accidental admin-purchases and keeps the admin context clean.

Confidence: VERIFIED.

7.5 Customer profile

The customer profile (group user) is not just a username and password. It is bound to ERP records:

• auth_identities — email and credentials,
• visma_kundkontakt — the customer contact (kontaktid),
• visma_kund — the company they belong to (kundnr),
• visma_kundrbtheader / visma_kundrbtrows — their pricing agreement,
• web_orders — their previous web orders,
• web_template_orderhead / web_template_orderrow — their saved templates,
• web_wishlist — their saved products.

Confidence: VERIFIED.

7.6 Operational responsibilities by role

8. CMS Module

8.1 Overview

The CMS lets administrators publish and manage pages, page components, page elements, forms, documents and media. It is the visual and informational backbone of the public site and supports both pure CMS installations and content sections of B2B/B2C webshops.

Confidence: VERIFIED.

8.2 Purpose and business value

• Decouple site content from technical deployment.
• Empower marketing and operations to publish, edit and reorganise pages without a developer.
• Centralise downloadable documents (price lists, brochures, certificates) and reuse them across pages and products.
• Capture leads and inquiries through configurable forms.

8.3 Main features

8.3.1 Pages

• Hierarchical page tree (parent/child) with drag-and-drop sort.
• Per-page status (published / unpublished), private flag (visible only to logged-in users), order, slug.
• Per-page SEO meta data, Schema.org image, social media image, canonical URLs.
• Per-page custom URL slug stored in unique_slugs, with automatic redirect handling.
• 404 routing logic that attempts to interpret an unknown URL as a CMS page before falling back to sitemap-based 301 redirects.
• A "Skapa redirect" companion service that maintains the redirect table to absorb URL changes.

Confidence: VERIFIED.

8.3.2 Page builder — components and elements

Each page is constructed from components (e.g. banner_text, banner_video, carousel, gallery, service_box, slider, team_box, text, text_image), and each component is filled with elements. The admin can:

• choose from existing component templates (page_templates, pages_components),
• add, sort, deactivate, and remove components,
• create new components from templates and reuse them.
• attach images to elements (with per-image SEO tags), reorder elements, and delete elements.

Confidence: VERIFIED.

8.3.3 SEO tools per page

• Tag statistics (counts of H1/H2/H3, etc.).
• SEO optimisation evaluation with a structured response.
• SEO title and description suggestions for categories.
• Schema.org image upload and metadata.

Confidence: VERIFIED.

8.3.4 Forms

Forms are fully data-driven:

• Create reusable forms with custom IDs.
• Define groups and individual elements (forms_elements).
• Define field type, placement, ordering, required, group structure.
• Choose form method (POST/GET), recipient email, grid layout (form_grid), enctype.
• Reuse forms across multiple pages or documents.

When a form is submitted on the storefront, the platform emails the submission through the standardised EmailSenderService and the audit log records it in sent_emails.

Confidence: VERIFIED.

8.3.5 Documents

• A central document library categorised by document type, category, and language.
• Uploads stored under FCPATH/documents/.
• Documents can be selected for a page (downloadable links) or attached to specific products.

Confidence: VERIFIED.

8.3.6 Media

A media library page exists at /admin/media_admin for browsing uploaded images and assets. The dashboard exposes the page; richer media curation is PARTIAL in current build.

Confidence: VERIFIED for the entry point; PARTIAL for advanced media features.

8.4 User roles

• Admin owns CMS day-to-day: pages, forms, documents, media.
• Super Admin does not normally touch CMS — they own system-level activities.

8.5 Available settings

• Page-level: status, private, ordering, slug, SEO data, schema.org, social image.
• Component-level: status, order, layout.
• Element-level: order, images, alt/title tags.
• Form-level: recipient, layout, method, enctype.

8.6 Automation

• Sitemap is regenerated on page changes (and via the daily CLI command).
• Slug uniqueness is enforced through unique_slugs.
• Old URLs are kept alive through automatic redirect table updates.

8.7 Limitations / partial areas

• The Blog module (both /admin/blog and /blogg/... front controller) is currently a stub: the front controller responds with empty output and the admin controller is a placeholder. Blog routing is in place but blog rendering and admin tooling are not implemented. Confidence: PARTIAL.
• /admin/productsettings controller is a stub. Confidence: PARTIAL.

9. Product Management

9.1 Overview

Products in HandlaOnline are the Visma articles (visma_artiklar) enriched by web-layer information (images, recommended products, SEO slugs, filters, attributes, custom properties, documents, status flags). The Admin Products page (/admin/products) is the operational hub for catalog work.

Confidence: VERIFIED.

9.2 Purpose and business value

• Single source of truth for what is shown in the webshop.
• Drive the online assortment independently of the ERP master without breaking the data contract.
• Maintain rich product presentations (images, attributes, documents) that the ERP does not store.

9.3 Main features

• Product grid with category, variant, and filter joins.
• Bulk actions: edit "general" data across selected products, bulk status change, bulk image apply, bulk delete images, bulk alt/title tags, bulk add related product.
• Image management: per-product image upload, drag-sort, per-image SEO tags (alt, title), bulk apply tags to all, delete one image, delete all images, fetch with sort data.
• Related products (web_product_recommended): add to single product, add to all selected, remove from single, remove from selected.
• Status flags: visible / hidden / published.
• Webshop visibility: based on the article's webshop = 'True' flag and category/variant configuration.
• SEO slug via unique_slugs (entity_type = 'product').

Confidence: VERIFIED.

9.4 User roles

• Admin owns catalog operations.
• Super Admin does not normally touch the catalog directly — they manage the synchronisation that feeds it.

9.5 Available settings

Most product field values come from the ERP via XML sync. The admin layer overlays:

• assignment to categories (web_productcategories),
• assignment to variants / groupings (web_producttillhor),
• filters (web_productfilters),
• product properties / egenskaper (web_producttegenskaper),
• product documents (web_product_x_document),
• images (web_product_images),
• related products (web_product_recommended).

9.6 Operational notes

• Adding or removing categories/variants does not delete underlying article data — only the web-layer associations.
• All slug operations go through SlugLibrary which enforces uniqueness.

9.7 Limitations

• Product import is XML-only; there is no admin CSV upload flow for products in the current build.
• Stock and pricing are read-only from the ERP feed; admin cannot directly overwrite them in the webshop layer.

10. Categories & Attributes

10.1 Overview

Categories (web_productcategories) are the navigational and merchandising spine of the catalog. Attributes (web_productfilters, web_producttegenskaper) describe what a product is and how customers filter for it.

Confidence: VERIFIED.

10.2 Main features

10.2.1 Category management (/admin/products_cat)

• Tree-based view: list categories with drag-and-drop sorting.
• Sort and reparent categories without losing assignments.
• Per-category status (visible/hidden), SEO data (title, description, suggested SEO), and slug.
• Category images: upload, tag, sort, delete, bulk delete.
• A dedicated "menu image" per category for navigational displays.
• Per-category product list with manual sort or automatic ASC/DESC by selected criterion.
• View the list of products assigned to a category and reorder them.

Confidence: VERIFIED.

10.2.2 Filters (/admin/products_filters)

• Manage the catalog filters used on category pages.
• Reorder filters, reorder filter values.
• Set value-level sort (ascending/descending or custom).
• Bind filters to underlying Visma article columns (e.g. colour, material).
• Maintain a display mode per filter (e.g. web_productfilters_display_mode).

Confidence: VERIFIED.

10.2.3 Product properties / egenskaper (/admin/productegenskaper)

A separate workspace to maintain product properties (web_producttegenskaper). The admin can:

• list configured properties,
• update display order, label, status,
• pick distinct values from referenced article columns.

Confidence: VERIFIED.

10.3 User roles

• Admin maintains category/attribute structure.

10.4 Available settings

• Category status, sort order, parent, SEO data, slug, menu image.
• Filter status, order, display mode.
• Property visibility and display.

10.5 Automation

• Automatic slug creation (unique_slugs) when a category is saved.
• Automatic redirect when a slug changes.
• Bulk SEO suggestions per category.

10.6 Limitations

• The reordering API works on visma_artiklar directly; large catalogs may need backend tuning. Indexes are defined in migrations (Add Index* migrations) to support this.

11. Product Groups & Relations

11.1 Overview

The platform supports two relational structures:

1. Product variants ("tillhör") — web_producttillhor groups articles that belong together (variants of a parent product). The "tillhör" display mode controls how they render together (single grid, dropdown selector, etc.).
2. Related/recommended products — web_product_recommended lets the admin push cross-sell or up-sell products on product detail pages.

Confidence: VERIFIED.

11.2 Main features

11.2.1 Variants (/admin/products_variant)

• List product groups with the articles assigned to each.
• Edit the variant configuration of any product.
• Configure how variants are displayed on the storefront (display mode per variant group).
• Tied to filters (web_productfilters) so that filtering by attributes implicitly selects the correct variant.

Confidence: VERIFIED.

11.2.2 Recommended products

• From the products admin, an admin can:
• assign one or more recommended products to a single product,
• assign one recommended product to all selected products at once,
• remove single, all-for-single, or all-for-selected relations.

Confidence: VERIFIED.

11.3 Business value

• Better merchandising and bigger basket sizes (cross-sells).
• Better customer experience on products with multiple variants.

11.4 Operational notes

• Variant groups are derived from the ERP data structure (article grouping). The admin enriches and curates the presentation.

12. Inventory & Stock Management

12.1 Overview

Stock visibility on the storefront is driven from the ERP feed. The platform stores per-article status and quantity through the XML sync (tmp_* staging then production tables). The admin can decide whether to show stock on the storefront through a webshop setting (show_stock).

Confidence: VERIFIED.

12.2 Main features

• Show or hide stock for products (per display mode: shows in B2B/B2C if enabled).
• Stock status is presented to the customer based on the ERP-supplied value.
• Out-of-stock behaviour is determined by the article's webshop = 'True' flag and stock value.

Confidence: VERIFIED.

12.3 Limitations

• There is no admin stock-override UI; stock is read-only from the ERP. Confidence: VERIFIED.
• The platform does not perform on-site reservation or live stock decrement; the ERP remains the source of truth.

13. Customer Management

13.1 Overview

The customer model in HandlaOnline distinguishes between a company (ERP customer record / kund) and a contact (ERP kundkontakt). A storefront login is always attached to a contact, and through the contact to the company.

Confidence: VERIFIED.

13.2 Main features

13.2.1 Customer registration

• A public storefront registration page (/registrering) collects company-style information (country selector covers EU + extras). The registration controller renders the page; account creation flow may operate through the registerCustomer endpoint on the front controller, which emails a B2B-registration request to the configured contact email.
• An invitation flow exists for admin users — a "send reset" link can be issued from the Super Admin Users page.

Confidence: VERIFIED for registration page + invite flow.

13.2.2 Customer login behaviour

• Login is managed by Shield (auth_identities).
• On login, the platform loads display data, company data, contact data, and personalises menus and pricing.

13.2.3 Customer activity (Admin → Users)

The Admin Users page (/admin/users) provides:

• Logins overview: all contacts (visma_kundkontakt) with their last login IP, last login time, GeoIP-resolved city/country.
• Per-user login history: all auth_logins entries for a given identifier.
• Session statistics: visits over time, active sessions, idle sessions.
• Session logs: granular session activity (logged through session_logs).

Confidence: VERIFIED.

13.2.4 Private-customer classification (Admin → Customer settings)

Admin can configure which customer category (kundkat) in the ERP represents the "private customer" segment. This drives:

• whether the storefront shows the "Skicka order" (B2B invoice) button,
• whether Klarna or invoice is offered,
• B2B vs B2C addressing logic.

The page also lists customers and lets the admin override the classification.

Confidence: VERIFIED.

13.3 Operational notes

• Reset password and "set password" magic-link flows are implemented with rate limits and CAPTCHA on the public reset page.
• Each transactional email related to customers is logged via SentEmailService.

13.4 Limitations

• There is no general "edit customer" CRUD page in the admin (customers are sourced from the ERP); only the private-customer classification override exists. Confidence: VERIFIED.

14. Company Management

14.1 Overview

Company management here means managing the seller's own company / brand profile in the platform — not the buyer's company (which is sourced from the ERP).

Confidence: VERIFIED.

14.2 Main features (Admin → Settings)

A tabbed configuration interface exposes:

Each tab supports reset of fields and removal of uploaded images.

Confidence: VERIFIED.

14.3 Operational notes

• These values are loaded into the base controller on every request and made available across the storefront — header, footer, schema.org metadata, transactional emails.
• They are the source of seller branding for emails, sitemap pings, and SEO output.

15. Order Management

15.1 Overview

Orders are the heart of the operational layer. Every web order is captured into a normalised set of tables and (for B2B) exported back to the ERP via XML.

Confidence: VERIFIED.

15.2 Database structure

Confidence: VERIFIED.

15.3 Order list (Admin → Beställningar)

The Admin Orders page (/admin/order) exposes:

• Server-side paginated list with full-text search.
• Date range filtering.
• Joins to visma_kund for company info and visma_kundkontakt for contact info.
• Per-order details modal showing line items.
• Reconciliation with cart-time comments (web_cart_ordertxt, web_cart_rowtxt).
• Aggregate order statistics endpoints.

Confidence: VERIFIED.

15.4 Order processing pipeline

The OrderService is the single entry point for order creation and supports two flows:

15.4.1 B2B invoice flow (processOrder)

1. Detect whether the cart is a template order (mall order) — if so, branch to mall order processing.
2. Validate the user is a business customer (kundkat ≠ private category).
3. Open a database transaction.
4. Insert the order header into web_orders (with addresses, totals, payment method "Invoice", status Pending).
5. Insert each cart line into web_order_details.
6. Pull comments from web_cart_ordertxt and web_cart_rowtxt.
7. Log the order via OrderLog.
8. Generate B2B-style XML via OrderXmlService and write to visma_webb/download.
9. Send admin and customer confirmation emails through EmailSenderService and log via SentEmailService.
10. Mark the cart paid and destroy the cart session.

Confidence: VERIFIED.

15.4.2 B2C Klarna flow (processOrderFromKlarna)

1. Receive the Klarna push (server-to-server).
2. Validate critical fields and check idempotency (checkExistingKlarnaOrder) to avoid duplicates.
3. Map Klarna fields into the internal order format.
4. Insert order header + lines in a transaction.
5. Append comments from cart.
6. Generate Klarna-specific XML for the ERP.
7. Acknowledge the Klarna order via Klarna API (/ordermanagement/.../acknowledge).
8. Send admin and customer confirmation emails.
9. Mark cart paid and destroy.

Confidence: VERIFIED.

15.5 Status fields

Every order tracks:

• order_status (Pending, etc.)
• payment_method (Invoice / Klarna / etc.)
• payment_status (Pending / Paid / etc.)
• vat_mode (resolved from customer/price list)
• currency_code
• total_amount, total_excl_vat, total_vat, includes_vat

15.6 Notifications

Two emails are generated per order:

• Admin notification with the full order summary (configurable recipient).
• Customer confirmation if send_order_confirmation_email = 1 and a recipient is resolved (selected address → order data → modules → DB).

Each is logged in sent_emails.

Confidence: VERIFIED.

15.7 Reorder

The Reorder service (addToCartFromOrder / addToCartFromWebOrder) lets a logged-in customer rebuild a cart from any previous order — pulling lines from visma_orderrow or web_orders.metadata, applying the customer's current prices, and routing through RebuildCartService.

Confidence: VERIFIED.

15.8 Template orders

Template orders are first-class entities and have their own dedicated workflow (see Section 28 and Section 4.3.5). They keep a copy of the cart contents under a customer-chosen name and can be edited, copied, deleted, restored, and used to seed a new cart.

Confidence: VERIFIED.

16. Checkout & Payments

16.1 Overview

Checkout in HandlaOnline supports two parallel flows: invoice (faktura) for B2B customers and Klarna Checkout for B2C. The platform enforces the boundary at the controller and service layer.

Confidence: VERIFIED.

16.2 The standard checkout (/checkout)

• Requires authentication.
• Shows the cart, allows the user to choose an address from the candidates computed at login (Leveransadress 1, 2, or 3).
• Allows a desired delivery date and pickup code to be added (used by ERP and warehouse).
• Allows whole-order comment and per-row comments.
• Submits via checkoutSubmitOrder which validates CSRF, requires login, and hands off to OrderService::processOrder.
• On success, the cart is marked paid, the session cart id is cleared, and the customer is redirected to a confirmation.

Confidence: VERIFIED.

16.3 Klarna checkout

• A dedicated route group: /klarna-start, /klarna-checkout, /klarna-confirmation, /klarna-terms, /klarna-push, /klarna-reset.
• The startCheckout action creates the Klarna order on the Klarna API, stores the HTML snippet in the session, and redirects the buyer to the iframe.
• The receivePush action is the server-side webhook that finalises the order based on Klarna's authoritative status.
• The confirmation page destroys the cart on checkout_complete status.

Confidence: VERIFIED.

16.4 Available payment methods

Active payment methods are pulled at runtime from the sys_payaments table and surfaced by DisplayService. Today the verified set is:

• Invoice (Faktura) — for B2B.
• Klarna Checkout — for B2C.

Other methods can be configured but require platform extension.

Confidence: VERIFIED for the two enabled methods.

16.5 Cart comments

Comments are attached to the cart before checkout:

• web_cart_ordertxt.local_remark — a single whole-order remark.
• web_cart_rowtxt.rowText — one remark per cart line.

These comments survive into the order (via OrderService) and into the confirmation emails and XML export.

Confidence: VERIFIED.

16.6 Limitations

• Card payment for B2B is not currently enabled.
• The unified "promotion / coupon" code module is not present in the current admin.

17. Klarna Integration

17.1 Overview

The Klarna integration is implemented through the KlarnaService and KlarnaController. It is a v3-style Klarna Checkout implementation with the following capabilities:

• Create order from cart with the customer's data (when known).
• Render the Klarna iframe to the buyer.
• Receive Klarna push server-side to finalise.
• Reset checkout, show terms, and show confirmation.
• Acknowledge the order with Klarna ordermanagement/.../acknowledge after the order is created internally.

Confidence: VERIFIED.

17.2 Settings and environment

The Klarna service reads its credentials from environment variables:

• KLARNA_API_URL
• KLARNA_API_KEY
• KLARNA_API_SECRET

Merchant URLs (push, confirmation, terms) are generated from site_url('klarna-*').

Confidence: VERIFIED.

17.3 B2B safety guard

If a B2B customer attempts to use Klarna, the OrderService rejects the request to enforce the policy that B2B = invoice and B2C = Klarna. This is a deliberate safeguard against accounting/data drift between the web and the ERP.

Confidence: VERIFIED.

17.4 Security context

Klarna's required scripts, frames and endpoints are explicitly allowlisted in the Content Security Policy filter. The X-Frame-Options header is relaxed for Klarna-checkout routes so the Klarna iframe can render.

Confidence: VERIFIED.

17.5 Idempotency

The push handler validates payload, looks up the cart by merchant_reference1, and uses checkExistingKlarnaOrder to ensure duplicate webhooks do not create duplicate orders.

Confidence: VERIFIED.

18. Shipping & Delivery

18.1 Overview

The platform supports delivery method management and shipping price rules per price list.

18.2 Delivery methods (/admin/shiping_settings)

• Lists all delivery methods (visma_levsaett) from the ERP feed.
• Allows the admin to mark a single method as the pickup method (is_pickUp = 1).
• The selection updates the storefront so the buyer can choose "pickup" at checkout.

Confidence: VERIFIED.

18.3 Shipping rules (/admin/frakt_standard)

• Configure shipping rules tied to a price list (visma_prisl).
• Each rule defines:
• Free shipping threshold (fraktfrigrens)
• Shipping price (frakt_pris)
• Carrier (speditor) from visma_speditor
• Display text for the shipping line.
• Stored in web_prislist_settings where frakt_prisl is set.

Confidence: VERIFIED.

18.4 Multiple price lists (/admin/multiple_settings)

• Enable multiple price lists per shop, useful for segmented B2B pricing.
• The admin can add or remove price lists from the multiple = 1 set.
• Used together with shipping rules to support per-list shipping.

Confidence: VERIFIED.

18.5 Operational notes

• Pickup methods are surfaced as pickupOptions in DisplayService and selectable at checkout.
• Shipping rules are computed alongside cart totals.

18.6 Limitations

• Carriers and delivery methods originate from the ERP feed and are not edited in HandlaOnline.

19. Discounts & Campaigns

19.1 Overview

The primary discount engine in HandlaOnline is the customer discount letter (kundrabattbrev) model from the ERP. Discounts are not currently implemented as standalone campaign objects with rules engines; they are inherent to the customer pricing agreement and the price-list logic.

Confidence: VERIFIED.

19.2 Where discounts apply

Confidence: VERIFIED.

19.3 Visible to the buyer

When enabled (show_row_discount = 1), each cart row shows the applied discount and the effective price. When show_stacked_prices = 1, the storefront displays the original and discounted price side-by-side.

Confidence: VERIFIED.

19.4 Limitations

• There is no campaign engine for time-limited promotions, coupon codes, or buy-X-get-Y rules in the current admin. Adding such a module would be a platform extension. (Menu items hinting at "Kampanjer" exist but are commented out — PARTIAL.)

20. SEO & Marketing

20.1 Overview

SEO is treated as a first-class concern. The platform invests in slugs, schema.org metadata, sitemap generation, redirect handling, and per-page SEO tools.

Confidence: VERIFIED.

20.2 SEO features

Confidence: VERIFIED.

20.3 Sitemap automation

• A CLI command (php spark generate:sitemaps) regenerates the sitemap.
• The service reads the currently active customer (basic_customer), resolves their price list and discount letter, and uses these to scope the catalog appropriately.
• After generation, the service notifies search engines.

Confidence: VERIFIED.

20.4 Marketing settings

Confidence: VERIFIED.

20.5 Limitations

• No built-in newsletter subscription form, no mailing-list integration, no built-in A/B testing.

21. Analytics & Reporting

21.1 Overview

The platform records anonymous and authenticated activity to provide reporting and audit trails.

21.2 Built-in analytics

Confidence: VERIFIED.

21.3 Admin dashboard reports

• Top categories today with visit counts.
• Top products today with visit counts.
• Visitor location breakdown (country + city via GeoIP).
• Order list with date range and search.
• Order statistics endpoint (fetchOrdersStatistic, fetchOrderStats).
• Login statistics for system users.
• Session statistics for end users.

Confidence: VERIFIED.

21.4 Reporting limitations

• The platform does not currently surface GDP-style financial KPIs, time-series sales charts or revenue cohort dashboards out of the box. These can be added on top of web_orders via ad-hoc queries or BI tools, but are not built-in.

22. Settings & Configuration

22.1 Settings architecture

Configuration is divided across three distinct families:

Confidence: VERIFIED.

22.2 Company settings tabs (recap)

Confidence: VERIFIED.

22.3 Webshop general settings

The admin manages all webshop-wide flags through /admin/settings_general, including:

• basic_customer (the default customer number used for guests).
• show_webshop, show_prices, show_filters, show_stock, show_register_page, show_different_address.
• show_recommended_products, show_additional_info.
• show_row_discount, show_stacked_prices.
• send_order_confirmation_email, order_confirmation_email.
• cat_product_per_page and list view attribute slots (cat_list_att_1..4).
• prod_img_size_width, prod_img_size_height.
• shiping_txt_1..3 for the cart / checkout shipping description.

Confidence: VERIFIED.

22.4 Display & modules (Super Admin)

The Super Admin maintains the active display view (view_name = CMS / B2B / B2C) and the modules enabled for that view (sys_display_elements). Modules include payment configurations and feature toggles. Switching display mode resets and re-populates the active module list.

Confidence: VERIFIED.

22.5 Operational notes

• All settings are loaded once per request via companySettings service and DisplayService.
• Settings change immediately impact storefront behaviour without redeployment.
• Each setting save is server-validated and limited to its tab definition.

23. Integrations

23.1 ERP integration (XML Sync)

Purpose: Keep web and ERP in sync on customers, contacts, articles, prices, discounts, delivery methods, carriers, payment terms, customer categories, articles groups, and orders.

How it works:

• The ERP exports XML files into the platform's visma_webb/upload folder.
• The XML parser loads files, validates them, converts encoding (ISO-8859-1 → UTF-8), and inserts them into tmp_* staging tables.
• Stored procedures (*_iud) merge the staging data into the production visma_* tables.
• Specialised services maintain web-layer tables (web_productcategories, unique_slugs, web_producttillhor, web_kundrbtnr_pricces, etc.).
• Sync results are logged in web_xmlsync.
• Parsing failures send a notification email.

Triggers: Manual (Super Admin → XML-synkronisering → Synchronize) or scheduled CLI (php spark sync:files).

Confidence: VERIFIED.

23.2 Payment integration (Klarna)

See Section 17. Full Klarna Checkout v3 integration with iframe, server-side push, acknowledge, error handling and CSP-aware security.

Confidence: VERIFIED.

23.3 REST API

Purpose: Allow trusted external systems to push data into HandlaOnline and pull defined data sets.

Endpoints (verified):

• GET /api/v1/status — health check.
• POST /api/v1/sync — generic table sync (currently allowlisted to visma_levsaett_api, visma_kundkat_api; extensible).
• OPTIONS /api/v1/sync — CORS preflight.
• GET /api/v1/orders/new — placeholder for outbound order export (returns empty result today; PARTIAL).
• GET /api/v1/customers, POST/PUT/DELETE — RESTful resource controller for customers.

Security:

• Every request must include X-API-KEY and X-API-SECRET headers.
• Keys are validated against api_keys (active flag, IP whitelist optional).
• Every access is logged in api_access_logs; errors are logged in api_error_logs with payload context.

Management:

• Super Admin → API Keys (/sadmin/api-keys): create, list, revoke, toggle active.
• Super Admin → API Keys → Logs / Errors: review activity and failures.

Confidence: VERIFIED.

23.4 Email integration

• A standard EmailSender service wraps CodeIgniter's email transport.
• A SentEmail service logs every send into the sent_emails table for audit.
• Transactional emails include: order confirmation (admin + customer), product inquiry, registration request, contact form submission, password reset, magic-link / invitation, XML sync error notification.

Confidence: VERIFIED.

23.5 Search engines / sitemap

• SitemapService generates sitemap.xml and notifies search engines (notifySearchEngines).
• A CLI command schedules this nightly.

Confidence: VERIFIED.

23.6 Future / partial integrations

• Outbound order export via REST API is scaffolded but not implemented (returns empty).
• The integration scaffolding is also extended for additional visma_*_api tables.

24. Notifications & Automation

24.1 Email notifications

Confidence: VERIFIED.

24.2 Session / activity automation

• Session activity logger updates last_activity for logged-in users every request and triggers an auto-logout log if the session times out.
• Session beacon endpoints (/api/session-heartbeat, /api/session-close, /api/session-hidden) record granular browser-side events (focus loss, tab close, etc.) into session_logs.
• Cart snapshot is captured during session logs to detect abandoned carts.

Confidence: VERIFIED.

24.3 Statistics automation

• Every storefront request hits the statistics logger filter, which inserts a row into statistics (excluded paths are pre-configured to avoid spamming the table with admin or AJAX endpoints).
• The Admin Main page consumes these to render today's stats.

Confidence: VERIFIED.

24.4 Automated maintenance

• Sitemap regeneration (CLI).
• Slug enforcement (on every page/category/product save).
• Redirect maintenance (slug change adds redirect; slug reappears removes its redirect).
• Cart price recalculation (refreshCart).
• Cart cleanup on order completion.

Confidence: VERIFIED.

24.5 Scheduled / recurring orders

Database tables exist (scheduled_orders, scheduled_order_executions, scheduled_order_reminders, scheduled_reminder_logs) and a ScheduledOrderService is implemented with create/update/delete, pause/resume style operations, execution lifecycle, "prepare order from execution", and "mark execution as ordered" advancing the next run date.

However, the routes and the corresponding tab + modals are currently neutralised in the user dashboard (commented out in Routes.php and app/Views/Front/UserArea/index.php). The capability is therefore present at the data/service level but not exposed to end-users out of the box.

Confidence: PARTIAL (service VERIFIED, customer surface DISABLED).

25. Security & Permissions

25.1 Authentication

• Built on CodeIgniter Shield.
• Users live in users with credentials in auth_identities and group membership in auth_groups_users.
• Login attempts are recorded in auth_logins.

Confidence: VERIFIED.

25.2 Session security

• The platform uses CSRF tokens (header X-CSRF-TOKEN) for sensitive actions (e.g. changeCustomerView, checkout submit, customer/template operations).
• Session activity is tracked; idle sessions log out automatically and the auto-logout is recorded.

Confidence: VERIFIED.

25.3 Filters in front of routes

Confidence: VERIFIED.

25.4 Content Security Policy

The CSP filter explicitly allows the scripts, frames and connect endpoints needed for:

• Klarna Checkout and Klarna order management,
• Kustom Checkout,
• TinyMCE,
• YouTube,
• Stripe,
• and other configured third parties.

X-Frame-Options is relaxed only for the Klarna-checkout routes so the Klarna iframe can render.

Confidence: VERIFIED.

25.5 API security

• Per-key API access logging.
• Per-error API error logging with payload, IP and exception context.
• Optional IP allowlist per key.
• Active/inactive toggle and revocation from the Super Admin dashboard.

Confidence: VERIFIED.

25.6 Data protection

• Order tables include addresses, phone numbers and emails, all stored under the seller's database.
• The platform maintains an explicit privacy policy section (company_integritet) managed by Admin → Settings → policy.
• Customer-supplied input on the storefront uses Shield's validation and CodeIgniter's input sanitisation.

Confidence: VERIFIED.

25.7 Known security-hardening recommendations (from the codebase)

• A few super-admin endpoints have temporary debug-level error messages or hardcoded values flagged in code comments. These are operational debt rather than feature gaps.
• Review API error verbosity before production exposure (the API currently returns detailed error messages for triage).

26. Operational Workflows

26.1 Cart life cycle

1. Visitor adds a product (POST /addToCart).
2. The platform creates or updates a cart record (web_cart) and items (web_cart_items).
3. The cart is associated with the customer once login is detected; the price agreement is applied.
4. The customer can:

• update quantity (updateCartItem),
• remove a line (deleteCartItem),
• clear the cart (removeCart),
• add a per-line remark (updateProductCartComment) → web_cart_rowtxt,
• add a whole-order remark (updateCartComment) → web_cart_ordertxt,
• inspect totals (getCartTotal, getCartCount).

1. On checkout submit the cart is converted to an order and the cart is marked paid.
2. If the customer switches identity (e.g. via changeCustomerView) the cart is cleared and re-priced for the new customer.

Confidence: VERIFIED.

26.2 B2B order placement (end-to-end)

[Buyer logs in]
   │ kundnr / kontaktid / kundrbtnr resolved
   ▼
[Browses catalog – sees personalised prices]
   │ Adds products to cart, attaches comments
   ▼
[Opens checkout]
   │ Chooses delivery address, delivery date, pickup code
   ▼
[Submits "Skicka order"]
   │ CSRF + login validated
   ▼
[OrderService::processOrder]
   │ B2B guard → DB transaction → web_orders + web_order_details + logs
   │ XML generated to visma_webb/download
   ▼
[Emails sent: admin + customer]   [Cart marked paid + cleared]
   │
   ▼
[ERP imports the XML and invoices the customer]

Confidence: VERIFIED.

26.3 B2C order placement (end-to-end)

[Visitor browses + adds to cart]
   ▼
[Visits /klarna-start]
   │ Validate cart and totals
   ▼
[KlarnaService creates order with Klarna]
   │ HTML snippet stored in session
   ▼
[Iframe displayed at /klarna-checkout]
   │ Buyer completes Klarna flow
   ▼
[Klarna calls back /klarna-push (server-to-server)]
   │ Idempotency check → OrderService::processOrderFromKlarna
   │ DB transaction → web_orders + web_order_details + logs
   │ Klarna order acknowledged
   ▼
[Confirmation page at /klarna-confirmation]
[Customer + admin emails sent]
[Cart destroyed]

Confidence: VERIFIED.

26.4 XML synchronisation (end-to-end)

[ERP exports XML to visma_webb/upload]
   ▼
[Super Admin clicks "Synchronize" OR cron runs spark sync:files]
   ▼
[XmlSyncService::syncXml]
   │ Parser → tmp_* truncate + insert
   │ DatabaseCompareService → CALL <table>_iud()
   │ Web tables updated (categories, slugs, prices, recommended)
   │ Sync log written to web_xmlsync
   ▼
[On parse error: notification email]

Confidence: VERIFIED.

26.5 Template order workflow

[Customer opens "Tidigare beställningar"]
   ▼
[Clicks "Skapa order" on a previous order]
   │ Modal asks for template name
   ▼
[Server creates web_template_orderhead + web_template_orderrow]
   ▼
[Template appears in "Mina beställningar / order"]
   │ Customer edits lines, quantities, comments, notes
   │ Can copy, delete, restore-to-original
   ▼
[Customer clicks "Add to cart from template"]
   ▼
[Cart rebuilt with current prices via RebuildCartService]
   ▼
[Customer proceeds to checkout as a normal B2B order]

Confidence: VERIFIED.

26.6 Catalog publishing workflow

[ERP → new article / change article]
   ▼
[XML sync → visma_artiklar updated, slug created]
   ▼
[Admin → /admin/products]
   │ Add images, set status, assign categories, attach documents
   │ Configure variants & filters
   │ Add SEO data and recommended products
   ▼
[Storefront immediately reflects changes]
   ▼
[Sitemap regenerated at next nightly run]

Confidence: VERIFIED.

26.7 CMS publishing workflow

[Admin opens /admin/pages_admin]
   │ Creates or selects a page
   ▼
[Edits page in /admin/page_edit/{slug}]
   │ Adds components from templates
   │ Adds elements, uploads images, sets SEO data
   │ Sets status to published
   ▼
[Page is visible publicly at /{slug}]
   ▼
[Sitemap updated; old slug (if any) covered by redirect]

Confidence: VERIFIED.

26.8 Customer-view switching workflow (B2B sales)

[Authenticated admin/seller]
   ▼
[POST /changeCustomerView with kundnr]
   │ CSRF validated
   │ Cart cleared
   │ DisplayService updated to view the catalog as that customer
   ▼
[Admin can now see exactly what the chosen B2B customer sees]

Confidence: VERIFIED.

27. Administrative Workflows

27.1 Daily catalog operations

27.2 Daily order operations

27.3 Marketing & content operations

27.4 Integration operations (Super Admin)

27.5 Customer-segment operations

28. Customer Workflows

28.1 B2C visitor

[Lands on home page]
   ▼
[Browses categories / search]
   ▼
[Opens product page]
   ▼
[Adds to cart] ↔ [Adds to wishlist]
   ▼
[Reviews cart, proceeds to Klarna]
   ▼
[Completes payment in Klarna iframe]
   ▼
[Sees confirmation page; receives confirmation email]

28.2 B2C consumer with account

Same as 28.1, plus access to:

• order history via /myaccount,
• wishlist persistence,
• saved profile.

28.3 B2B authenticated buyer

[Logs in with email + password]
   ▼
[Sees personalised home + assortment]
   │ Customer-specific prices and discounts applied
   ▼
[Builds cart or selects a saved template]
   │ Optionally adds per-line and per-order remarks
   ▼
[Checkout]
   │ Selects delivery address (up to 3 options)
   │ Selects delivery date and pickup code if relevant
   ▼
[Sends order via "Skicka order"]
   ▼
[Order is recorded, emailed, and exported as XML to the ERP]
   ▼
[Customer can view in "Tidigare beställningar", re-order, or save as template]

28.4 B2B template management

• Open "Mina beställningar / order".
• Filter and search templates.
• Edit a template's lines or quantities.
• Use "Sökresultat" to add products to a template (with Select2 product search).
• Save changes; "Återställ till original" reverts.
• Copy a template to make variants for different sites.
• Delete a template when no longer needed.

28.5 B2B calendar planning

• Open "Kalender".
• See orders plotted on the calendar by delivery date.
• Click an event to open a modal with order details.

28.6 Customer account management

• Open "Mina uppgifter".
• View contact details inherited from the ERP record.
• Sign out from the dashboard at any time.

Confidence: VERIFIED.

29. FAQ & Common Operations

29.1 How do I switch the site between B2B and B2C?

The Super Admin changes the display view in the system display configuration. The active view (view_name) determines storefront behaviour for non-admin visitors. Logged-in admins/superadmins always see CMS mode regardless.

29.2 How does a B2B customer get their own prices?

On login, the platform resolves the customer's kundnr, kontaktid and kundrbtnr/prisl from the synchronised ERP records. Pricing on every product is then computed (or read from materialised tables built nightly) using the kundrabattbrev rules: priority 1 article-specific, priority 2 article-group, priority 3 whole price list.

29.3 How does Klarna confirm an order if the buyer closes the browser?

Klarna sends a server-side push to /klarna-push. The platform validates the payload, resolves the cart by merchant_reference1, and finalises the order through OrderService. Idempotency prevents duplicates. Confirmation emails are then sent and the cart destroyed.

29.4 Can I run B2B and B2C from the same site?

Yes. The classification is done per customer category through Admin → Customer settings. Logged-in B2B customers get B2B rules; consumers and guests get B2C rules.

29.5 Where do orders go after being placed?

Orders are stored in web_orders (and web_order_details), available in Admin → Beställningar. For B2B they are also exported as XML to visma_webb/download for ERP import. The customer receives a confirmation email; the admin receives an admin notification email. Every email is logged in sent_emails.

29.6 How do I add a partner to the REST API?

Sadmin → API Keys → Create. Give the partner the generated api_key and api_secret, optionally restrict to specific IPs. Their requests must include the X-API-KEY and X-API-SECRET headers. All access is logged.

29.7 What happens if my XML sync fails?

The sync run is recorded in web_xmlsync. On parsing errors, a notification email is sent. Bad files are moved to an error area so the next run is not blocked.

29.8 How do I publish a new marketing page?

Admin → CMS → Sidor → Create. Provide a name and parent. Open the page editor (/admin/page_edit/{slug}), add components from templates, add elements and images, configure SEO, and set the status to published.

29.9 Can buyers download documents?

Yes. Admin → Document manages the central document library; Admin → Webshop → Produktdokument attaches documents to specific products; CMS pages can reference documents through the form/document selectors in the page editor.

29.10 Can a buyer change which company they buy on behalf of?

For internal sales/admin scenarios, the changeCustomerView endpoint allows switching the active kundnr (after CSRF validation) and re-priced the experience. For end users, login is bound to a contact / company.

30. Platform Capability Summary

30.1 At a glance — what HandlaOnline delivers

30.2 Why customers choose HandlaOnline

• One platform, two business models. B2B + B2C without compromising either.
• One source of truth. The ERP is honoured. The webshop does not duplicate masters; it synchronises them.
• Operational discipline. Order export, audit logs, sent-email log, session log — full traceability.
• Self-service for B2B buyers. Templates, reorder, calendar — designed to make repeat purchases trivial.
• Marketing flexibility. A real CMS, not just product pages — pages, forms, documents, schema.org.
• Modern checkout. Klarna Checkout for B2C, invoice flow for B2B, both safe and idempotent.
• Extensible by API. Versioned API with key management and access logs to integrate partners cleanly.
• Swedish-first. UI, conventions, ERP terminology and Klarna integration aligned to the local market.

Appendix A — Swedish / Business Glossary

Appendix B — Confidence Matrix

This matrix summarises confidence per module, based on direct verification in the platform's code, routes, and views.

Appendix C — Module → Dashboard Path Map

End of master document. This is the canonical enterprise reference for HandlaOnline as of the analysed codebase. Any departure from the behaviour described here should be treated as an incident or an undocumented change and reported to the platform owner.