IMI

This guide provides detailed instructions on setting up the integration between IMI Go and Skrym. The integration supports:

• Syncing product data between Skrym and IMI
• Providing post-payment optimization recommendations for packing stations
• Polling new sales orders into repo and initializing tracking when permitted

The integration allows users to easily maintain up-to-date product information and enhance warehouse operations through effective packing recommendations.

1. Product Data Sync

Purpose

To maintain a consistent and synchronized product catalog between IMI Go and Skrym:

1. If you do not already have a Skrym API key, contact your system administrator to obtain one.
2. Share the API key with the IMI Go team to enable the integration.
   • It is currently not possible to set up the integration without help from the IMI Go team.
3. Test the integration by adding or adjusting products.
   • Ensure that the product data has been updated in Skrym by checking the Products page

Limitations

• Due to limitations in how IMI Go stores product data, special attributes and irregular shapes need manual handling and are not covered by this automated integration.
• Updating the product data in Scope will not automatically update the product data in IMI Go, as this is considered important master data.

2. Optimization

Purpose

To provide real-time packing recommendations at packing stations using the Skrym optimization algorithms.

Setup Steps

1. If you do not already have a Skrym API key, contact your system administrator to obtain one.
2. Contact IMI Go to trigger an event when an order is released to the packing station.
3. Ensure you have synced or inserted your product data and package data into Scope.
   • You can easily set an alias for each package that will be displayed to have a more human-readable name.
4. Test releasing an order to a packing station and check that it appears on the Orders page.
5. Monitor the packing station to ensure that the recommendations are displayed correctly.

Support

For any issues encountered during the setup or operation of this integration, please contact our support:

• Skrym Support

By following these setup instructions, you can successfully integrate IMI Go and Skrym systems to streamline your warehouse operations and maintain accurate product data.

Order and consignment polling

The IMI integration card also supports importing new sales orders from Alyson. This uses a separate HTTP Basic-auth connection; the optimization connection continues to use its existing bearer-token authentication.

Configuration

1. Open Integrations → Systems → IMI → Configure and expand Order and consignment polling in Scope.
2. Enter the Alyson API URL (default https://api2.alyson.io), username and password. The saved password is never returned to Scope; leave the field blank to retain it.
3. Confirm Alyson's source timezone and enter its IANA name, for example UTC or Europe/Stockholm. Dates with explicit offsets retain those offsets; dates without offsets use this setting.
4. Add one or more DataGroups. Each group must belong to the selected retailer. They share the connection, polling interval and completed polling cursor.
5. Set the interval (1–1,440 minutes, default 5), enable polling, and choose Save polling settings. The same dialog contains a separate Optimization section with its own save action.

Polling settings, encrypted credentials, polling progress and sales-order ingestion are owned by the integrations service; optimization credentials remain in authentication. Sales-order ingestion uses the existing repo APIs to upsert products and orders, then queues tracking initialization. The tracking service owns tracking initialization and consignment ingestion, so shipment polling and backfills use the same tracked-order and shipment behavior.

Existing IMI integrations remain polling-disabled until explicitly configured. Optimization credentials are not required to enable sales-order polling. Polling starts from the connection’s first activation time; historical orders are not automatically backfilled. Disabling polling preserves progress, and re-enabling catches up from that progress. New or re-added DataGroups join the shared polling window; they do not trigger historical backfills.

Order numbers and sales-order IDs must be unique across the retailer's configured DataGroups and must not identify unrelated existing Skrym orders.

Imported data

• OrderNumber becomes the external order reference attributed to the retailer. SalesOrderId becomes a warehouse reference attributed to IMI.
• Order date and SHIPFROM/SHIPTO postal and country information use the existing repo order upsert behavior. Supplied values can update existing orders.
• Product numbers are resolved before order lines are inserted. Missing products are created with their names and supplied unit weights; changed names and supplied weights are updated while retaining other product master fields. UnitNetWeight is currently assumed to be kilograms and converted to grams per product, without multiplying by ordered quantity. Missing or null weights preserve existing weights; an explicit zero is stored as zero. The source unit may become configurable if some IMI connections use a different unit. SalesOrderLineId identifies the imported line. Replayed lines set the supplied quantity without accumulating it. Quantities must be positive whole numbers.
• Delivery codes use existing transport-method alias resolution. An unrecognized code does not prevent importing the order.
• Retailers with tracking permission receive a linked tracked order, including recipient details. Existing tracked orders gain missing references. Permission is checked again when processing tracking initialization.

Polling imports order creation and shipped consignments. Employee-event polling can additionally import warehouse activity as described below. Polling does not import cancellations or subsequent order changes. Granting tracking permission later does not initiate a historical tracking backfill.

Operation and recovery

The scheduler checks for due connections each minute. Each poll uses a fixed creation-date window and a five-minute overlap, bounded by activation time. Pages contain up to 100 orders and are published in messages containing at most ten orders, with smaller messages for large payloads.

A page advances only after all its messages have been published. Groups are processed sequentially within the same fixed window. After all sales-order groups complete, the same window is polled for consignments using startDateShipped and endDateShipped. Employee events, when configured, run after both phases. The shared latest_poll cursor advances only after all configured discovery work succeeds. The settings table holds the lease, current phase/group/page, latest poll and success/error status; no separate group table or configuration revision is used. Repo and tracking processing are asynchronous and tolerate redelivery. The last successful poll shown in Scope means discovery and publication completed, not that every downstream consumer has finished.

Connection/API failures preserve progress and retry after the configured interval. Worker interruption resumes the saved window and page. Saving settings invalidates active leases and replays the current window. Check the connection’s last-success/error status in Scope and the traced IMI polling, repo ingestion and tracking subscriptions when troubleshooting. Invalid source orders remain failed subscriber work; correct the source or mapping issue and replay the failed message rather than resetting the polling cursor.

Local and preview environments require invoking the private integrations.DispatchIMIPolling endpoint for testing because scheduled jobs do not run there automatically. Use test credentials and synthetic recipient data.

Consignment shipments

Consignment polling uses the same enabled setting, interval, Basic-auth credentials, DataGroups and source timezone as sales-order polling. Existing enabled connections automatically include consignments from their current polling window; historical consignments are not backfilled.

• CustomerReference matches an existing tracked-order reference within the retailer. Consignments do not create orders. If the tracked order is unavailable, the consignment is skipped; use manual consignment backfill after order initialization completes.
• ConsignmentId becomes the retailer shipment reference, and ConsignmentNumber becomes the carrier shipment tracking reference. For PostNord, the first nonempty GoodsItemNumber supplies that reference instead; a missing goods item number fails ingestion. Matching only an existing parcel reference can still create a duplicate shipment when its parent shipment reference differs.
• Each GoodsItemId becomes the retailer parcel reference. Barcode supplies the parcel tracking reference, falling back to GoodsItemNumber when empty. Shipment and parcel references remain distinct regardless of manual-input reference settings.
• BaseService.Code and CarrierServiceName use transport-method alias resolution. When BaseService is absent, Departure.DepartureName resolves the carrier through existing aliases. Numeric route suffixes are also removed as a fallback (POSTI (5) tries POSTI (5) and then POSTI). The selected order carrier/method is not used. An unresolved service or departure is logged with its source payload and skipped. Correct the alias mapping and use consignment backfill to recover skipped shipments.
• CONSIGNOR and CONSIGNEE supply shipment origin/destination postal and country codes. TransportAccountNumber supplies the carrier customer number.
• Tracking permission is checked during ingestion. Repeated discovery updates the same shipment and parcels instead of creating duplicates. Raw measurements, tracking URLs, customs data and departure dates are not imported.

Consignment pages use the same validation, payload bounds and checkpoint rules as sales orders. A failed consignment page retains its phase, window and page for retry. Downstream errors remain retryable subscriber work even after discovery finishes; monitor the ingest-imi-consignments subscription alongside order initialization.

Manually import older orders

Invoke the private integrations.BackfillIMISalesOrders endpoint in the Encore API explorer:

count accepts 1–1,000 across all configured DataGroups. The saved Basic-auth connection and source timezone must be configured; scheduled polling may be paused. The endpoint scans the requested source creation-date range and selects the most recent matching orders up to the requested count. Existing orders are included so IMI data can enrich orders originally created by another integration.

The response contains requestedOrders, queuedOrders, from, to, and scannedPages. Queued orders proceed through normal ingestion and permission-gated tracking initialization. Manual backfill does not modify activation, the polling cursor, or polling success/error status. It has a 90-second deadline and a maximum scan of 1,000 pages. Fetch or selection errors queue no orders. A publication failure may leave some batches queued; replay-safe ingestion allows retrying the request.

Manually recover missing shipments

Invoke the private integrations.BackfillIMIConsignments endpoint with organizationId and count (1–1,000). Optional offset skips candidate orders; optional maxPages limits the scan to 1–1,000 pages (default 100).

The endpoint requires tracking permission and selects the oldest tracked orders without shipments, including orders created outside IMI. It scans shipped consignment history across configured DataGroups, matching customer references and queuing matches for normal ingestion. Scheduled polling progress is unchanged.

The response reports checkedOrders, matchedOrders, queuedConsignments, scannedPages, and scanComplete. A page-limit stop returns partial results with scanComplete: false. Wait for ingestion before selecting the next candidate set. Correct unresolved carrier mappings before retrying recovery.

Employee-event polling

Retailers with tracking permission can select IMI event codes from the saved external event types used by event mapping, or type a custom code and choose Add in Employee event types in the IMI polling settings. Leaving the list empty disables employee-event polling. It shares the saved Basic-auth connection, polling interval, source timezone and DataGroups with order and consignment polling. Existing connections have an empty selection and remain employee-event-disabled until configured.

The supplied Alyson OpenAPI does not define an event-type enum or list all allowed values. It only gives PL_PICK_PIECE and SO_PACKED as examples of the eventTypes query filter. Obtain the complete list from IMI. Skrym accepts explicit code tokens (letters, digits and underscores), with up to 100 unique codes of 128 characters each. It does not invent or restrict the selection to the two examples.

The endpoint is GET /v1/employeeEvent?start=...&end=...&eventTypes=..., returning an array. It has no pagination or DataGroup query parameter. Skrym splits the fixed polling window into five-minute subwindows and locally filters by DataGroupName, selected EventTypeName and source timestamp before publication. Responses remain subject to the shared 16 MiB bound; an oversized response fails without advancing that subwindow. Batches contain at most ten events and 512 KiB. Empty arrays complete normally; malformed responses retain the current subwindow for retry.

Tracking permission is enforced when saving a nonempty selection, before each employee-event fetch, and again by the ingestion consumer. Permission revocation prevents API requests and processing of queued batches. Order and consignment discovery continue normally. Re-enabling permission or changing the event selection does not backfill history already passed by the shared cursor.

Tracking and source data

• EmployeeEventId, retailer and DataGroup identify each event, so overlap and redelivery do not duplicate records.
• The source fields, including employee identity, warehouse zones/locations, quantity, numeric event code and object identity, are retained in tracking's raw_event store. EventTypeName is the external event code under IMI for event mapping; observed codes are registered in the external event catalog.
• ObjectTypeName: SalesOrder resolves ObjectId against an IMI-created reference on that retailer's repo order (WAREHOUSE, or EXTERNAL after tracking mirroring), then uses its linked tracked order. An unrelated order with the same numeric order number cannot match. Missing orders or incomplete tracking initialization retry, with the raw data already saved.
• ObjectTypeName: Consignment resolves ObjectId against the retailer's shipment reference (ConsignmentId) and upserts the event on that shipment. Missing shipments retry; ambiguous references fail instead of choosing a shipment. SalesOrder and Consignment events use stable event IDs so repeated polls do not duplicate timeline events.
• Built-in defaults map SO_PACKED to Packed and PL_PICK_PIECE to Preparing, both outbound, with English and Swedish messages. Existing retailers receive the code-backed fallback; newly onboarded retailers also receive editable mappings. Retailer mappings take precedence. Picking one piece does not mark the whole order as packed, and the PickLine linking limitation still applies.
• Organization mappings for IMI's external event code provide the event type, status and message. Unmapped SalesOrder and Consignment events are recorded as notifications named after the source code, without an inferred status change.
• ObjectTypeName: PickLine identifies a picking line, not a sales order. The supplied API documents no read endpoint relating a PickLine ID to an order. PickLine and other unsupported object types are therefore stored as raw data only; they are not attached to an order or shipment. Resolving them later requires a documented source relationship and replay support.
• Offset-free DateCreated values use the configured source timezone; explicit offsets are preserved as instants. Warehouse labels are retained as source data, without guessing geographic locations.

Monitor ingest-imi-employee-events for downstream errors. The polling success timestamp indicates completed discovery/publication, not completed tracking ingestion. Manual sales-order backfill does not backfill employee events.