FAQ: How are return references created and how do they match the outbound shipment references?

Return references are generated based on the order code or movement demand reference (if provided), not the outbound booking reference.

Q: Why do the return references (e.g. Return-12345-#1) not match the outbound shipment references (e.g. 12345, 12345-#2, 12345-#3) exactly?

Great question! While the naming may appear mismatched, the actual mapping between bookings is correct. Here's a quick breakdown:

What you’re seeing

In some cases, you may notice that the return references (e.g., Return-12345-#1, #2, #3) don’t appear to line up numerically with the outbound shipment references (e.g., 12345, 12345-#2, 12345-#3).

This can happen because the suffixes (e.g., #1, #2, etc.) for both outbound and return bookings are assigned based on the Movement Demand (MD) creation time—not by the outbound booking they are linked to. Since return MDs can be created in a different order than the originals, the numbering in the return reference may not directly match that of the outbound shipment.

Let’s look at an example:

• Outbound shipment ref: [pick list / booking no.] (12345) → Return-12345-#2

• Outbound shipment ref: [pick list / booking no.] (12345-#2) → Return-12345-#1

• Outbound shipment ref: [pick list / booking no.] (12345-#3) → Return-12345-#3

Even though the naming between outbound and return references seems inconsistent, each return booking is correctly linked to its respective outbound shipment.

How return references are generated

1. Base reference
   Return references are generated using the order code by default (e.g., 12345). If a Movement Demand (MD) reference is provided, that will be used instead.

2. Suffixes (#1, #2, #3, etc.)

   • For outbound shipments, suffixes like #2 or #3 are assigned based on the Movement Demand creation time.

   • The return bookings also follow the Movement Demand creation time for assigning #1, #2, etc.

   This can result in naming mismatches (like #2 outbound linking to #1 return), simply because the return MDs may have been created in a different order than the original shipments.

Key points to remember

• Naming mismatches are cosmetic — the system correctly maps return bookings to their respective outbound bookings.

• The return address remains the same across all linked returns in these cases.

• The outbound booking reference is not used when generating the return reference, as it isn’t available at the point of return creation.

Note: What is a Movement Demand?

A movement demand (or pick list) can only be loaded into the 7bridges software via the API or in some instances a file upload process.

Once received into the software, this will enable the customer to book the shipment within the software interface or via API.

The movement demand is essentially the pick list instruction that the customer makes use of in their warehouse/process to prepare the goods for shipping. This links to the order data that has already been provided via API. There may be instances where the 7bridges software receives multiple movement demands linked to the same order; for example, is they are part fulfilling from different locations. 

The customer can use the pick list references to search for and process the shipment booking within the software interface.