Skip to content

Order Management UX/UI Requirements

Overview

Order Management functionality is access by the users through the UI.

The Information Structure that the User will interact with is shown in the diagram below. Note that this is an abstract representation of the information structure and does not prescribe the actual UI layout. E.g. The different boxes could be designed as nested menus on the left side of the application, tabs within an Ordering section or as options withing a single screen (e.g. a toggle to see Open Orders, Submitted, etc… as in a filter selector).

  • Boxes represent information offered to the user.
    • Gray Boxes group a set of information presentations that share a common actions.
    • Blue Boxes represent a List of elements (Table Component). When another box is joined to a blue box (under it), it means that it can be accessed by selecting an element from the Blue Box and asking the system to view it.
    • Green Boxes show a read-only display of a single element with a designed layout.
    • Pink Boxes Allow the user to edit a single element with a designed layout.
    • Yellow Boxes Represent a Lookup and selection of a single element from a set.
  • Red Text represents actions that a user can take when presented with the information on their parent box. For Grey Boxes, the actions are available on any of its child boxes.

User Information Structure

uml diagram

Information Presentation

uml diagram

uml diagram

Views

Lists

These are Table View interactions, with all the capabilities of Table Views and Editable Table Views when editing actions are permitted.

Order Queue

  • Contents: Cards in REQUESTED STATE
  • Actions:
    • Create Order
    • Add Lines to Order

All Order Lists

  • Contents: Orders
  • Actions:
    • Single Select
      • View Header
      • View Lines
      • Annotate
    • Multi-Select
      • Print
Open List
  • Contents: Orders in DRAFT/OPEN STATE
  • Actions:
    • Single Select
      • Edit Header
      • Add Lines
      • Remove Line
      • Receive
    • Multi Select
      • Submit
      • Cancel
Submitted List
  • Contents: Orders in SUBMITTED STATE
  • Actions:
    • Multi-Select
      • Confirm
      • Receive
      • Complete
      • Archive
Confirmed List
  • Contents: Orders in CONFIRMED STATE
  • Actions:
    • Multi-Select
      • Receive
      • Complete
      • Archive
Receiving List
  • Contents: Orders in RECEIVING STATE
  • Actions:
    • Multi-Select
      • Receive
      • Complete
      • Archive
Archive List
  • Contents: Orders in ARCHIVED STATE
  • Actions:
    • None

Order Lines

  • Contents: Order Lines for a given Order
  • Actions:
    • Single Select
      • View Line
      • Annotate Line
      • Edit Line (only if Order in Open state)
    • Multi-Select
      • Depending on the state of the Owning Order:
        • Open, Submitted, Confirmed, Receiving:
          • Receive
      • Archive:
        • None

Details

Read-Only views of the Specified Content

View Header

  • Contents: Properties of an Order Header as described in Order. Note that for complex properties, they may be shown in specialized sub-views (e.g. An address)
  • Actions: Same as the List view that originates it.

View Line Details

  • Contents: Properties of an Order Line as described in Order Line.
  • Actions: Same as the Order LinesList view that originates it.

Editors

Editable views of the Specified Contents

Header Form

  • Contents: Properties of an Order Header as described in Order Information Contents. Note that for complex properties, they may be rendered and edited in specialized sub-views (e.g. An address)
  • Actions: Same as the List view that originates it.

Edit Line Form

  • Contents: Properties of a single Order Lines as described in Line Information Contents.
  • Actions: Same as the List view that originates it.

Annotation

  • Contents: The privateNotes property of an Order or an Order Line, presented in an editable “long-text” format.
  • Actions:
    • Save, Cancel with the option to close the editor or move to the next or previous element of the originating list (Order, Order Line list views)if the editor is opened from a list view.

Receive

  • Contents:
    • A Read-Only view of the Order Quantity of an Order Line
    • An editable field with the value of the receivedQuantity.amount of the Order Line
  • A read-only view of the receivedQuantity.unit, which must match the orderQuantity.unit
  • Actions:
    • Save, Cancel with the option to close, move to the next or previous element of the originating list (Order, Order Line list views)if the editor is opened from a list view.

Lookups

These views are used to find and select an element of information of the system. They have a text input field that serves as a search/filter input. The matching entries are displayed in a simple view with strictly the minimum information for the user to make a decision to select one. The user selects one that is then used as input for the action that triggered the lookup in the first place.

Note

Advanced versions of a lookup may offer additional sub-actions including:

  • Advanced search that offers the user the ability to search by multiple criteria, sort, paginate and see more information about the results.
  • Add New: Offers the user the ability to create a new element of information on-the-fly and use it right away.

Lookup Order

  • Contents: Orders
  • Search: Order Number, Supplier Name
  • Display: Order Number, Supplier Name, Order Date, State

Lookup Cards

  • Contents: Kanban Card Details
  • Search: Item Name
  • Display: Item Name, Card Number, State

Lookup Items

  • Contents: Items
  • Search: Item Name, SKU, PrimarySupply.Supplier, SecondarySupply.Supplier
  • Display: Item Name, SKU, Location, Preferred Supplier
  • Additional Actions: Add New Item

Actions

  • Create order
  • Add Lines to Order
  • Annotate
  • Print
  • View
  • Edit Header
  • Edit Line
  • View Line
  • View Item
  • Edit Item
  • View Cards
  • Remove Line
  • Cancel
  • Submit
  • Confirm
  • Receive
  • Complete

Create Order

Input

A set of Cards

  • Validation: The selected Cards must have a “compatible” supplier, i.e. There is a supplier that is availble to every card (card.XXXsupply.supplier) or the card has not specified suppliers.

Effect

A new Order is created with the selected Cards

  • One line per group of Cards that share the same Item and the same UnitOfMeasure
    • The quantity is the largest of:
      • The sum of the quantity of the cards
      • The maximum of the min order quantity of each card
    • The Supplier is one of the compatible suppliers of the cards
      1. The one with the most cards that specify it as a PrimarySupply.
      2. The one with the most cards that specify it in any way.

Add Lines to Order

Input

  • An Existing Order in Draft/Open state.
  • A set of Cards that have a supplier compatible with the selected Order.
    • It is either the Order Supplier
    • Or the Order has no Supplier and the Cards have a compatible supplier with the
      other cards already

Note

This action can be performed from the Order Queue starting with a selection of Cards or from the Order List (Open Orders) starting with the selection of an order

Effect

The Selected Order is updated with:

  • Updated Quantities for existing lines that have new Cards matching their Item and UnitOfMeasure.
  • New Lines for any Cards that do not match any existing lines.

Annotate

Input

  • An Existing Order.
  • A Text Note.

Effect

The Selected Order is updated with its privateNotes field set to the provided Text Note.

Print

Input

  • An Existing Order.
  • A Selection of a Print Format from a pre-defined list.
    • The predefined list will be customizable by tenant in the future. Initially, defined at the
      system level.
    • If no Print Format is selected, a Default will be picked by the system. In the future, the default will be customizable by tenant.

Effect

A PDF file is generated and presented to the user for printing or downloading.

  • The PDF file should contain the date-time of the print operation.

View Order

Input

  • An Existing Order
  • An Intent/Selection of whether to view the Order Header or Lines.

Effect

The Selected Order is presented to the user in a viewable, read-only format. The system will present the View Header or View Lines based on the user intent. From one view, the user should be able to switch to the other view without having to go back to the list of orders.

The View Order display should allow the user to navigate to the next and previoius order in the underlying list of orders.

View Line

Input

  • An Existing Order.
  • A Selection of one Line in the order (from View Lines).

Effect

The Selected Order Line is presented to the user in a viewable, read-only format.

The View Line should allow the user to go next & previous line in the underlying Order.

Edit Header

Input

  • Selection of an Existing Order in Draft/Open state.

Effect

  1. In-Line: In the Open Order List, if the user wants to edit one of the “simple columns” that are shown, it can use the “in-line” editing of a table row.
  2. Form: For more complex edits, or edits of complex properties, the system presents the user with an editable form of the order header populated with the current values of the order, allowing the user to modify them. Once the user submits the form, the order is updated with the new values.
  • Validation: If the values provided by the user are invalid, the system should present the user with a list of errors and prevent the order from being updated.
    • The Supplier should be compatible with all the lines of the order.
    • The deliverBy date should be after the orderDate.

Edit Line

Input

  • An Existing Order in Draft/Open state.
  • A Selection of one Line in the order to edit.

Effect

  1. In-Line: In the View Lines table, if the user wants to edit one of the “simple columns” that are shown, it can use the “in-line” editing of a table row.
  2. Form: For more complex edits, or edits of complex properties, the system presents the user with an editable form of the order header populated with the current values of the order, allowing the user to modify them. Once the user submits the form, the order is updated with the new values.
  • Validation: If the values provided by the user are invalid, the system should present the user with a list of errors and prevent the order from being updated.
    • The Supplier should be compatible with all the lines of the order.
    • The deliverBy date should be after the orderDate.

The system should present the user with the ability to Save the changes or cancel the changes. In either case, the user should be able to indicate the next action to perform.

  • Close the editing form.
  • Navigate to the next line
  • Navigate to the previous line.

Remove Line

Input

  • An Existing Order in Draft/Open state.
  • A Selection of one Line in the order to remove.

Effect

  • The Line is removed from the Order. The system should prompt for confirmation to remove the line.
  • The Order is updated (e.g. total cost of goods, …)
  • The View Lines table is updated and refreshed.

Cancel

Input

  • An Existing Order in Draft/Open state.

Effect

  • The Order is canceled and removed from the Open Orders
  • Any cards attached to lines in the Order are returned to the Order Queue

Note

The Order is not actually removed from the system but it is no longer accessible to users. In the future a list of Cancelled Orders may be made available to users to be able to copy them, analysis, etc..

Submit

Input

  • An Existing Order in Draft/Open state.

Effect

Confirm

Receive

Input

Effect

Complete

Input

Effect

Input

Effect


Copyright: © Arda Systems 2025-2026, All rights reserved

Comments