Ctrlk
API documentationIncident managementFeedback
For the complete documentation index, see llms.txt. This page is also available as Markdown.
Store Operations

Packing

Pack jobs are designed to pack already picked items into boxes or bags. In addition, documents can be printed and added to the parcel. This part is especially relevant for ship-from-store orders, as shipping labels and other documents are usually printed and added to the parcels here. Once orders are packed, they are typically stored for handover.

Packing container types

Packing containers represent physical containers in which picked items are packed for handover. For example, packages for shipping orders or bags that are handed over to a customer in a store. When creating a packing container, one of the preconfigured types must be chosen.

  • Packing container types handle:

    • Name, description, and icon

    • Dimensions (optional)

    • Maximum weight a packing container can carry (optional)

See Operative container types for more information.

Packing configuration

The packing configuration allows users to define rules for the packing process, such as scanning requirements, container handling, and document inheritance. The packing configuration is available at /api/configurations/packing (see the packing configuration endpoint section for more information) and affects the whole system regardless of the user role or the facility.

In the packing configuration, you can define:

Scanning type configuration

The scanning type configuration defines whether a physical scan of all pack line items' codes is required to complete a pack job.

This field can be set to one of the following values:

  • MUST_SCAN_EACH: Each item must be scanned before it can be packed.

  • SCAN_NOT_REQUIRED: Scanning isn't required. Items can be confirmed manually without scanning.

This configuration has no backend logic and is solely used by the client.

Packing container required configuration

The packing container required configuration determines whether the packer must select a target container (for example, a box or a parcel) during the packing process.

This field can be set to one of the following values:

  • true: The packer must select a container to be packed. Search is enabled for containers.

  • false: Selecting a container isn't required. Items can be packed without adding a container. Search isn't enabled for containers.

This configuration has no backend logic and is solely used by the client.

Packing item confirmation needed configuration

The packing item confirmation needed configuration determines whether the packer must explicitly confirm each item (for example, by tapping or scanning) before it counts as packed.

This field can be set to one of the following values:

  • true: The packer must check off each pick line item to be packed.

  • false: Checking off each pack line item isn't required. Items can be packed without explicitly confirming each item.

This configuration has no effect when the scanning type is set to MUST_SCAN_EACH. In this case, scanning each pack line item is mandatory to complete a pack job.

This configuration has no backend logic and is solely used by the client.

Packing source container configuration

The packing source container configuration enables the concept of a source container during packing. A source container represents the container (for example, a tote bag or a bin from the picking process) from which items are packed.

This field can be set to one of the following values:

  • true: Packing source containers are automatically created when a pack job is generated from a pick job.

  • false: A packing source container isn't created.

To be able to search for pack jobs via the scanned code of a load unit packing, both packingContainerRequiredConfiguration and packingSourceContainerConfiguration have to be set to true.

Document handling configuration

The document handling configuration controls the inheritance of external documents into the process for a pack job.

When a document is added to the documentSets of a pack job, it can be inherited to its related process as an external document. Once added to the process, any related entity (order, pick job, pack job, handover job, and so on) can inherit the external document provided the corresponding configuration on that entity is active.

See the External documents article for more information.

The inheritedDocumentConfigurations array in the packing configuration defines which section the inherited document belongs to. This field can be set to one of the following values:

  • ORDER: The external document(s) are inherited to the order.

  • PACKJOB: The external document(s) are inherited to the pack job.

  • PICKJOB: The external document(s) are inherited to the pick job.

  • HANDOVERJOB: The external document(s) are inherited to the handover job.

  • PARCEL: The external document(s) are inherited to the parcel.

  • PACKING_TARGET_CONTAINER: The external document(s) are inherited to the packing target container.

Although inheritedDocumentConfigurations is an array, only the first entry is currently evaluated. Only one section is supported at this time.

Packing configuration endpoints

To access the current packing configuration, use the endpoint below:

To update the current packing configuration, use the endpoint below:

Update packing config

patch
Authorizations
AuthorizationstringRequired
Bearer authentication header of the form Bearer <token>.
Body

VersionedResource

createdstring · date-timeOptional

The date this entity was created at the platform. This value is generated by the service.

Example: 2020-02-03T08:45:51.525Z
lastModifiedstring · date-timeOptional

The date this entity was modified last. This value is generated by the service.

Example: 2020-02-03T09:45:51.525Z
versioninteger · int64Required

The version of the document to be used in optimistic locking mechanisms.

Example: 42
Responses
200

The packing central configuration was successfully updated.

application/json

VersionedResource

createdstring · date-timeOptional

The date this entity was created at the platform. This value is generated by the service.

Example: 2020-02-03T08:45:51.525Z
lastModifiedstring · date-timeOptional

The date this entity was modified last. This value is generated by the service.

Example: 2020-02-03T09:45:51.525Z
versioninteger · int64Required

The version of the document to be used in optimistic locking mechanisms.

Example: 42
patch/api/configurations/packing
PATCH /api/configurations/packing HTTP/1.1
Host: your-tenant-name.api.fulfillmenttools.com
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 395

{
  "created": "2020-02-03T08:45:51.525Z",
  "lastModified": "2020-02-03T09:45:51.525Z",
  "version": 42,
  "documentHandlingConfiguration": {
    "inheritedDocumentConfigurations": []
  },
  "packingContainerRequiredConfiguration": {
    "active": false
  },
  "packingItemConfirmationNeededConfiguration": {
    "active": true
  },
  "packingSourceContainerConfiguration": {
    "active": false
  },
  "scanningConfiguration": {
    "scanningType": "MUST_SCAN_EACH"
  }
}
{
  "created": "2020-02-03T08:45:51.525Z",
  "lastModified": "2020-02-03T09:45:51.525Z",
  "version": 42,
  "documentHandlingConfiguration": {
    "inheritedDocumentConfigurations": []
  },
  "packingContainerRequiredConfiguration": {
    "active": false
  },
  "packingItemConfirmationNeededConfiguration": {
    "active": true
  },
  "packingSourceContainerConfiguration": {
    "active": false
  },
  "scanningConfiguration": {
    "scanningType": "MUST_SCAN_EACH"
  }
}
PreviousHeadless picking
NextPacking endpoints

Last updated

Was this helpful?