Recommending the optimal packages for orders

Our package optimization API will attempt to pack a set of products into one of your available packages as tightly as possible.
It stands at the core of Skrym's products, being used in, for example, our  or .
While the API can be called anytime, we usually highlight two main scenarios:

Pre-payment: e.g. during checkout on an e-commerce website.
The response can then be used to validate the availability, cost and emissions of different delivery methods.
Post-payment: e.g. when the order is received in a warehouse.
The response can then be used to streamline operational efficiency, such as grouping picking orders on package, allowing warehouse workers to pick items directly into the final package, and save costs for filling/packaging materials.


    The package optimization offers a degree of customization and flexibility which is important to get right to get the most out of the API.
    We therefore recommend you to first head to the  to see if any preferences might be useful to you.


Optimization

There are two ways you can customize the behaviour of our package optimization: by setting available hyperparameters, and by ammending product attributes.
Setting hyperparameters
Our supported optimization hyperaparameters are listed in the table below.
To set or or check your parameters, you can refer to  or use our .
We continuously expand on these and if you have any questions feel free to reach out to .

  
    
      **Hyperparameter**
      **Type**
      **Description**
      **Default**
    
  
  
    
      `SortingMethod`
      ENUM
      Defines the sorting method for optimization. Available options are `BASE_AREA` and `VOLUME`.
      `VOLUME`
    
    
      `SortingDirection`
      ENUM
      Determines the sorting direction for optimization. Options are `ASC` and `DESC`.
      `DESC`
    
    
      `NumberOfSplits`\*
      NUMERIC
      Specifies the number of splits an order can be divided into. It allows for efficient distribution of items across packages.
      `10`
    
    
      `PreserveOrderLines`\*\*
      ENUM
      Dictates how order lines are preserved. Options: `HARD_PRESERVE`, `SOFT_PRESERVE`, and `NO_PRESERVE`.
      `NO_PRESERVE`
    
  

* NumberOfSplits: This hyperparameter requires you to have a special permission, otherwise Skrym will not conduct splitting.
You can read more about order splitting 
** PreserveOrderLines: We define order line as a unique product with certain quantity.
The HARD_PRESERVE mode will aim to keep each order line within the same package and return error if that is not possible.
The SOFT_PRESERVE mode will do the same, but will try to split the order lines if they cannot be hard-preserved instead of failing.
The NO_PRESERVE mode will treat each item individually, irrespective of the order lines.
Changing product traits
As default behaviour, Skrym deals with products as solid, rigid cuboids.
For certain product catalogues or use-cases, this however does not quite cut it.
So far, we have rolled out support for the following product traits:

    {/* TODO: once the product pages are published, we can uncomment and finish this table too */}
    {/* 
    
     */}
    
  
    
      **Trait**
      **Description**
    
  
  
    
      
      Products that need extra padding (to avoid breakage) can be given a fragility score which is proportional to the *amount* of padding applied.
    
    
      
      Certain products, such as textiles, can be compressed while packed. Compressibility is a score given to a product to determine how much it can be compressed. 
    
      
      description.
    
      
      description.
    
    
      
      description.
    
      
      Some product may contain spaces or holes within them (think about a mug or a doughnut). Skrym will try to utilize those empty spaces for packing. 
    
  

To learn more about what they are how to handle them kindly see the .

Preferences

Recommending multiple packages for single order

Order splitting is a feature that allows you to split a single order into multiple packages.
This can be useful for large orders that would otherwise not fit into a single package, or for orders that need to be split for other reasons.

    Order splitting is a feature that requires special permission. 
    If you are interested in using this feature, please contact us at .

How it works

   B{Attempt to place all products in one package}
      B -->|Fits| C[Place all products in the package]
      C --> I[End]
  B -->|Does not fit| D{Maximum allowed splits reached?}
  D -->|No| E[Create a new package]
  E --> F{Preserve order lines?}
  F -->|No| G[Place remaining products in new package]
  F -->|Yes| H{Hard or soft preservation?}
  
  H -->|Hard| I1[Do not split order lines]
  H -->|Soft| J1[Try to avoid splitting, but allow if necessary]
  G --> J{Products remaining?}
  I1 --> J
  J1 --> J
  J -->|Yes| B
  J -->|No| I[End]
  
  D -->|Yes| K[Error: Unable to fit products]
`}

/>

At the time of writting, our order splitting functionality operates on a split-when-full basis.
In simple terms, Skrym will try to place all the products in the order into the smallest possible package, but upon failing to fit into the largest package, it will attempt to place the remaining products into the next smallest possible package.
This process will be repeated until all products are placed inside a package or until the maximum allowed splits is reached.
For splitting, the NumberOfSplits and PreserveOrderLines hyperparameters are especially important (see ). They determine the maximal number of splits and how strict the splitting is, respectively.
The splitting is baked into all of our optimization endpoints so with the appropriate permission, it can be triggered by calling, e.g. .

Order splitting

In this section, we cover cases that might require a bit more attention when optimizing orders.
Special cases are often industry specific and we are happy to extend our solutions based on a need-be basis.
If you have any special requirements, feel free to let us know at . and we will be happy to open a discussion.
For instance, we have came across the need to support .

Special cases

REST API endpoints for package optimization

This section contains all of the API references for endpoints that are related to package optimization.
We have split this into two broad sub-sections:

One that deals with endpoints which fascilitate package optimization, and
Second sub-section that deals with endpoints which handle optimization hyperparameters.
{/* NOTE: we can add more here, such as for fetching results or statistics */}

If you have any questions, then as always, don't hesitate to reach out to .