From a technical perspective, the following attributes should be sent for your product:

• article_number
• article_name
• default_unit_quantity
• uom_code
• unit_quantity

(Weight and dimensions are needed, but can be added by Bring for an additional cost. EAN/Barcodes on the physical product are recommended to be sent as part of the product data, but it’s not a technical requirement)

If the product is typically sold individually, the Default Unit Quantity is usually set to 1.

Some product attributes cannot be changed after they are set. This is because warehouses do not allow changes (e.g. weight and volume) from external systems after creating an item. We have different solutions for changing the product attributes if necessary. If so, please contact Bring and we will assist you.

The Create endpoint is in V2 because it uses the reworked version of the data model.

country_of_origin and hs_code should be passed to us.

Set batch_handling to True.

Set serial_number_handling to True.

Set expiry_date_handling to True.

You can send all EAN/barcodes associated with one product. Please note that barcodes cannot be updated. If there is a need to send a new EAN/barcode to us, please contact Bring and we will assist you.

UN Numbers are numeric. For example, if your UN Number is UN1234, you should use 1234.

Valid UOM-code for a Units Of Measure. The following codes are supported:

• “UNKNOWN”: Unknown,
• “202”: PalletISO2,
• “AA”: IBCPallet,
• “BA”: Barrel,
• “BBG”: BagInBox,
• “BE”: Bundle,
• “BG”: Bag,
• “BLK”: BLK,
• “BO”: Bottle,
• “CA”: Can,
• “CN”: Container,
• “CS”: Case,
• “CT”: Carton,
• “KGM”: Kilogram,
• “LAY”: Layer,
• “LTR”: Litre,
• “MTR”: Metre,
• “PCE”: Piece,
• “PF”: Pallet,
• “PK”: Package,
• “PR”: Pair,
• “PU”: Tray,
• “RO”: Roll,
• “SA”: Sack,
• “ST”: Sheet,
• “SX”: Set,
• “T3”: ThousandPieces,
• “TY”: Tank,

Master data for all order lines must be sent to Shelfless before a PO can be sent to Shelfless. Preferbly through API integration.

All of the above can be sent to Bring along with the purchase order if the information is available in the client system. If not available in the client system, Bring can fetch the information from the physical goods as part of the inbound process.

If the above is sent and/or fetched as part of the inbound process, batch, expiry date, and serial numbers are sent to the client in the sales orders status. For example, the sales order contains information about which batch, expiry date, and serial number were picked for a specific product.

Use the static value PO.

Use PCE.

Only the supplier name is mandatory. Details regarding the ordering party and receiver are optional.

Purchase Orders can only be updated if they have no Status or their Status is Received. They cannot be updated once the warehouse starts working on them.

We report the actual quantity that was received. It will be reflected in a complete status. “Complete” represents the quantity received so far. There can be multiple “Complete” statuses for one Purchase Order. If we expected 10 pieces for a certain Purchase Order line but only received 8, we update the Purchase Order’s Status to Complete and report that we received 8 in the API.

In the agreement with Bring Shelfless it’s included what transport companies and services to be used to ship your sales orders. If you have a website and a checkout page, the delivery option is often chosen by the end customer during the checkout procedure. The delivery option available at your website must be mapped with the transport services agreed with Bring Shelfless. If the end customer for example choose “Home Delivery Standard”, that should be translated to the service code representing this delivery option, for example:

• transport_company > party_id: ‘BPN’
• service > code: '5600'
• service > addon_codes: '2084'

If the service chosen is a pickup point service (Hentested or box) and end customer also selected a specific pickup point, a pickup point ID needs to be provided. That should be sent in:

• pickup_point > id: '12345'

For sales orders to be picked up at warehouse, party_id and service > code should be ‘HENT’ for both.

addon_codes is related to additional services a carrier can provide, for eample end customer delivery notification.

Order types should be agreed upon with the warehouse. Their main use is to differentiate between Sales Orders if needed. The following are our standard order types:

• B2C Standard - 320
• B2C Express - 324
• B2B Standard - 420
• B2B Express – 424

Sales orders are locked after they are sent to Bring.
However, a grace period can be set up in agreement with Bring. Within this grace period, sales orders are kept in our order control system and can be updated as needed. They can also be canceled. Once the grace period ends, the sales order will be released to Bring WMS and locked from further changes.

Yes, information to the warehouse can be sent in delivery > delivery_information in the Create Sales Order API. This field is optional.

Yes, information to the transporter/carrier can be sent in delivery > delivery_information in the Create Sales Order API. This field is optional.

Yes, incoterms or Terms of Delivery can be sent in delivery > terms_of_delivery in the Create Sales Order API. This can be set to values like DDP, DAP etc.

Set buyers_order_number to your Reference Order Number.

Our Order Control System (OCS) has a backorder feature. If a sales order cannot be fully fulfilled and the backorder feature is activated, OCS will hold the full order as a backorder until there is enough stock to fulfill it. If the backorder feature is deactivated, OCS will send all orders to WMS and the available qty will be picked and the rest will be automatically canceled. You as a customer decide if backorder feature should be on or off for your sales orders.

No, you do not need to add a warehouse/ID to Sales Orders. These are enriched based on which warehouse you use. We also support multiple warehouses, which checks what warehouse a Sales Order needs to be fulfilled from.

No, but we recommend keeping poll intervals to five minutes or longer.

On shipments with multiple packages, if labels are created with, for example, three packages in total, the package will be marked with three labels: 1 of 3, 2 of 3, and 3 of 3. There will also be a common Shipment Number that leads to the three package numbers.

No. If phone number validation is configured, we only check if a value was provided.

The Sales Order Data Validation feature is designed to streamline the order processing workflow by automatically verifying critical customer and order details before they are given to the warehouse system. This feature is configured on client level and can performs one or multiple of the following validations:

• Agreed Shipping Code: Ensures that the correct shipping codes are provided for each order. For each client the agreed shipping codes will be setup in OCS. The given codes on each sales order will be compared with the setup codes in OCS and if they don’t match the shipping code validation will fail
• Email Address: Ensures that an email address is supplied for communication and order tracking
• Phone Number: Verifies that a phone number is supplied for communication and order tracking
• Pickup point ID: OCS are using Posten Transport API to lookup the pickup point id given by client to verify it’s a valid pickup point ID within Posten network of available pickup points
• Zip code for nordic countries: Ensured that a zip code in correct format is given
• Zip code for common European countries: Ensured that a zip code in correct format is given
• Customs validation: Ensures that required customs data is provided along with the order:
  • Incoterm
  • Freight cost
  • Order line price
  • Order line currency
  • Country of origin
  • HS code

The following configurations can be made on client level and field level:

• Validation on and stop order: Validation is on and if an order fails validation it will be held in OCS until it has been corrected. The failed validation is stored in OCS
• Validation on with pass through: Validation is on but if an order fails validation it will be sent to WMS anyway. The failed validation is stored in OCS
• Validation off: No validation is taken place and nothing is stored

Sales orders failing validation will be communicated in two ways:

• Notification will be sent to MyBring Portal no matter of sales order source. The notification will include the full order as well as information of what failed, for ex, “invalid carrier code”. Based on this notification the client can make changes to the order in the portal. Once changes been done OCS will re-run the validation and if it goes through the sales order will be sent to WMS. Otherwise a new notification will be sent to Portal
• If sales order is created through SHIP API, the integration layer will respond with an error. Clients are obligated to review the response from the integration layer (system wise) and if it’s not a “success” message the need to have a mechanism to act on it. A notification will also be sent to Portal. See point 1 above

Poll the Get Stock Adjustment API to see what has happened to a Stock.

BalanceType is the type of Stock that was processed and has the following categories: Available, Physical, Blocked, and Inbound. This is similar to the Stock Status in SAP.

Each Stock Adjustment has an ID that lets you save the ones you are interested in rather than new ones.

Yes, our warehouse system and Mybring Portal supports serial and batch numbers on stock level. However, integration does not.

In Mybring portal, click on the “select area” button on the upper left corner and then click on the menu option “Invoices”.