Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Current »

Following a meeting 18th March 2022 ROOM the following was discovered with regards to the ROOM software design:

ROOM Process Flow

ROOM have the following entities in their system

  • Sales Orders - SKUs to be sent from the warehouse

  • Purchase Orders - Services on the Sales Order SKUs. eg. delivery, installation

There is currently one API with SEKO White Glove which can contain information for both sales orders and purchase orders on the same end point. Some ways to allow all data to be sent to room are as follows:

Communication ROOM - SEKO

Suggestion 1

Allow both API calls to the same end point which overlay data for the White Glove booking

The payload for ROOM for sales orders and purchase orders goes to the same end point and has the same reference number (SEKO External Ref). In this way the White Glove data would end up with SKUs and instructions on the same booking.

Suggestion 2

ROOM combine data into one API call

ROOM could choose to combine all the data into one API call which would exactly match the SEKO White Glove API.

SKU Layouts

ROOM SKU Layout V1 2020 - 2022

There was always a parent SKU with an apparently unordered set of child SKUs

Parent SKU which has no specific meaning

Child SKUs containing whatever the required items

Suggestion

ROOM sends the SKUs as parent and all children including with no direct link between parents and children

ROOM SKU Layout V2 2022 -

Kits (eg. complete meeting rooms)

Parent (SKU box 4)

Child SKUs making up the room,

  • items which are common across all meeting rooms

  • configurable items, eg. region specific adapters

Suggestion

ROOM sends the SKUs as parent SKU (box 4) and all children including box 4

Maintenance items

Every item is a parent SKU, there are no children

Suggestion

ROOM sends all the SKUs as parents

Serial Numbers

ROOM rely on serial numbers for customer services to be able to identify the piece in question.

Dispatch note / API contains all SKUs which are picked and their serial numbers. There is no concept of parents and children.

QUESTION

Serial numbers are allocated on picking from a location (correct?). Are serial numbers allocated only when they leave the warehouse and not during the manufacturing process? if they were to be tracked from the manufacturing process they would be able to be tracked all the way back there, not sure if that is possible now.

Suggestion

The sales order is sent to the warehouse; this includes a list of SKUs

On dispatch

Not sure what the relevance of serial numbers are prior to installation. Are the serial numbers relevant from a “parent/child” perspective before the products are installed or only afterwards?

  • the list of SKUs is sent to ROOM with serial numbers

  • the list of SKUs is sent to White Glove with serial numbers

  • Q: Could there be an assembly guide made from parents and children, with relevant serial numbers, as communicated by White Glove to WMS when sales order sent?

    • Could this data be sent back to White Glove for storage?

  • Q: Could the serial numbers be recorded once they’ve been put in place by the installers as an email etc?

  • No labels