This table is used within the simulation-based experiments only (Simulation, Variation, Comparison, Safety Stock Estimation, Risk Analysis).

The shipping table defines policies describing how products are sent:

• what vehicle type to use
• which order to ship first
• when to ship

The shipping policies are considered only if the required amount of products has been reserved at the source site's inventory. If there is not enough inventory, the order will be kept in the site's backlog until it can be reserved.

Shipping is not possible if no Path is defined for the Source / Destination pair of objects.

Properly defined shipping is required to visualize connections on the GIS map.

Learn more on how shipping works.

Column	Description
Sources	Defines possible product sources. It can be any supplying facility (defined in the DCs and Factories, Suppliers and Groups tables), except for a Customer.
Destination	Defines who the product is shipped to. It can be any facility (Customer, DC, or Factory), except a Supplier. You can use the following techniques when working with the drop-down list of possible sources: To set / unset a facility as a source, select / clear the checkbox next to the list item
Product	The product for which the shipping policy is defined. The cell contains a list of products (defined in the Products table).
Vehicle Type	The vehicle type(s) (previously defined in the Vehicle Types table) that the policy will choose from to transport the order. The selected vehicle provides the Capacity value that is used for calculating the amount of products it can carry in case the order is divided.
Type	A shipping policy regulates the handling of the orders for the amount smaller than the selected vehicle capacity. anyLogistix offers a set of standard order handling policies: FTL FTL with periodic check LTL LTL with periodic check Pending orders Push: schedule Push: uniform Prohibited
Parameters	Sets parameters for the policies defined in the Type column. The set of parameters differs for each policy type.
Priority	Sets the priority, according to which the orders are shipped. For more details refer to how shipping works. FIFO — (First In, First Out) orders are sent in the order, in which they are received, i.e., the first received order has the highest priority. ELT — order with the least lead time is the highest priority. Big first — order with the biggest demanded volume of products is the highest priority.
Days of Week	Defines the days on which the shipping policy can be initiated to choose the optimal delivery route. E.g. If the policy type is set to LTL with periodic check, and the Period, days parameter is set to 5, the optimization process will be triggered each 5 days. If it is triggered on Tuesday, while Tuesday is not checked, the shipping policy will not be initiated.
Start Time	Defines the start of the time period within the day when shipping becomes possible.
End Time	Defines the end of the time period within the day when shipping is no longer possible.
Time Period	The time period during which the shipping policy will be considered. The cell contains a list of periods (previously defined in the Periods table).
Inclusion Type	Defines the status of the given shipping policy: Include — include this shipping policy into supply chain configuration. Exclude — exclude this shipping policy from supply chain configuration. If selected, the table record ill be grayed out to denote the current inclusion type. The table record stays editable.

Let us assume that we have an LTL shipping policy with a DC supplying a group of customers. Once something happens (e.g. inventory changes, order is received) the optimization process is triggered:

If there is insufficient inventory at the source site to reserve the required amount of product(s), the shipping policy will not be triggered.

1. It checks Days of Week to see if the shipping policy can be initiated on this day. If the day is checked (by default all days are checked) the policy starts choosing the optimal route.
2. Now the policy checks the Priority column to prioritize the orders that need to be delivered. This might be a queue of orders for various reasons (lack of free vehicles, previously insufficient inventory, increase in demand, etc.) and the policy will choose an order according to the defined priority. In case of:
   • FIFO — the first received order has the highest priority.
   • ELT — order with the least lead time is the highest priority.
   • Big first — selects the biggest order (demanded amount). In this way the destination becomes known.
     Now the policy checks if there are other orders from this customer that need to be delivered. In case there are 2 or more orders, the policy will prioritize them again to choose the biggest one.
3. Then it checks the vehicle type(s) that can be used to deliver the order(s), and tries to load all orders from this customer that can fit in the vehicle's capacity (Min load ratio is considered in case of FTL).

   The example below shows how it works in case of Big first priority, but it works the same for all priority types.

   E.g. One of our customers has placed 5 orders (for 60m³, 30m³, 20m³, 10m³, 10m³) until one of them met the current policy requirements i.e., appeared to be the biggest order in queue among the orders from all the customers that need to be delivered (Big first).

   The source site has a fleet with 1 vehicle that has a capacity of 100m³.

   The policy loads the biggest order (occupies 60m³ out of 100m³), and prioritizes the orders again to take the next biggest order (30m³). We have occupied 90m³ out of 100m³. The policy once again takes the next biggest order (20m³), which does not fit in, but we still have 2 orders for this customer, so the policy takes the "second best" to see if it fits (10m³), and it does. Now the customer will receive 3 orders via 1 shipment. The rest of the orders will get back to the general queue of orders from all customers to be checked again when the shipping policy is triggered next time (p.2 of this scenario).

Partial delivery is available if either LTL or LTL with periodic check is set in the Type column.

We will assume that:

• Source site has a fleet with 1 vehicle that has a capacity of 100m³.
• Priority is set to Big first.
• Partial delivery is allowed

This is how it goes:

1. The policy chooses the biggest order from the queue (130m³), which exceeds the vehicle's capacity (100m³).
2. Since partial delivery is enabled. the vehicle takes 100m³ and sets off to deliver this part of the order. The customer does not consider this order to be completed. The customer waits for the rest of it (30m³) to be delivered.
3. The vehicle returns to the source site. The policy is triggered and it chooses the biggest order again from the general queue of orders from all customers. The partially delivered order is treated by the policy by its initial volume (130m³), so the new orders that have been added to the queue have to be 131m³ or more to be the biggest orders. Unless they are, the vehicle will take the 30m³ the customer is expecting, check if there are any other orders from that same customer it could fill the rest of its capacity with (70m³) and sets off to complete the order.

   In case one of the new orders is 131m³ or more, the vehicle will fetch it first. Again, only part of it will be taken, so we will have two partially delivered orders that are waiting until their initial volumes will be the biggest among all other orders in queue.

Full Truck Load — order(s) will not be shipped until at least one vehicle is fully loaded (in accordance with the Min load, ratio value).

For example, if an order is received for 0.1 amount of vehicle capacity and Min load, ratio is set to 0.7, the order will not be shipped. If the next order is received for the amount of 1.4 units of a vehicle capacity, the total ordered volume will constitute 1.5 units which is enough to cover the threshold ratio of two trucks. As a result both orders will be shipped in full scope.

FTL parameters

• Min load ratio — the value sets the threshold for the ratio between the ordered product amount and the vehicle capacity. If the threshold is exceeded, the vehicle is treated as fully loaded. The value is provided as a fraction in the interval between 0 and 1. For example, the Min load, Ratio of 0.7 implies that if a vehicle load exceeds 0.7 of its capacity, the vehicle is treated as fully loaded.

  The system compares the product amount and the vehicle capacity based on their mass and volume characteristics. The data for the comparison is taken from the Products and Vehicle Types tables, respectively. As a result, two separate ratios are produced: the masses ratio and the volumes ratio. If any of these ratios exceed the Min load, Ratio, the vehicle is treated as fully loaded.

Same as FTL but it is checked once a defined period (the Period, days) with the date of the first check also defined by the user.

FTL with periodic check parameters

• Min load ratio — the value sets the threshold for the ratio between the ordered product amount and the vehicle capacity. If the threshold is exceeded, the vehicle is treated as fully loaded. The value is provided as a fraction in the interval between 0 and 1. For example, the Min load, Ratio of 0.7 implies that if a vehicle load exceeds 0.7 of its capacity, the vehicle is treated as fully loaded.

  The system compares the product amount and the vehicle capacity based on their mass and volume characteristics. The data for the comparison is taken from the Products and Vehicle Types tables, respectively. As a result, two separate ratios are produced: the masses ratio and the volumes ratio. If any of these ratios exceed the Min load, Ratio, the vehicle is treated as fully loaded.

• Period, days — defines the time period during which the policy is triggered. The default value is 1, i.e., the policy is triggered every day.
• First check — allows a user to define the date of the first periodic check. The calculation of the defined period (Period, days) starts from this date.

Less than Truck Load — the truck does not need to be necessarily fully loaded. An order for any amount is shipped.

LTL parameters

• Forbid partial delivery — is disabled by default. A vehicle is allowed to deliver part of the order that fits its capacity to later return, fetch and deliver the rest of it. See example for more details.

  Statistics do not show partially completed orders. An order is added to the statistics only when it is fully completed.

Same as LTL but is checked once a defined period (the Period, days parameter) with the date of the first check also defined by the user.

LTL with periodic check parameters

• Forbid partial delivery — is disabled by default. A vehicle is allowed to deliver part of the order that fits its capacity to later return, fetch and deliver the rest of it. See example for more details.

  Statistics do not show partially completed orders. An order is added to the statistics only when it is fully completed.

• Period, days — defines the time period during which the policy is triggered. The default value is 1, i.e., the policy is triggered every day.
• First check — allows a user to define the date of the first periodic check. The calculation of the defined period (Period, days) starts from this date.

Pending orders are orders not sent (kept at a facility) for a certain reason (e.g. it is never a priority).
This policy limits the time the delivery of such order can be pending.

Note that If:

• There is a number of orders with due date on the same day, then the existing priority rule will be applied to such orders.
• There is no available vehicle, the order will be considered for mandatory delivery again next time the vehicle comes back.
• Partial delivery is allowed (LTL / LTL with periodic check), the vehicle may take part of the pending order.

e.g. If the Waiting time, days parameter of this policy is set to 30, the order will be shipped out on the 30th day. If there are 2 or more orders to shipped on this day, the policy checks the priority and sends the biggest order (in case of Big first). The rest of the orders will be considered again when the policy is triggered.

Pending orders parameters

• Waiting time, days — defines the maximum period of time (for each received order) that an order can be kept on site (e.g. the order is never a priority). On the last day of this period the order will be obligatory shipped out, unless e.g. there is no available vehicle.

  e.g. If the Waiting time, days parameter is set to 30, the order will be shipped out on the 30th day. If there is a number of orders with due date on the same day, then the existing priority rule will be applied to such orders.

Defines the schedule, according to which the defined products will be taken to the required destinations regardless of demand.

Push: schedule parameters

• If not enough vehicles — defines the required action in case there is not enough products or vehicles to push-deliver the products:
  • Abort simulation — the experiment will be aborted, the error message will pop-up.
  • Skip — the issue will be skipped, the experiment will proceed. See the log file for details.
• Destination — the object that the product must be delivered to.
• Product — the products to deliver.
• Quantity — the amount of products to deliver to the Destination.
• Date & Time — the exact time when the products will be taken from the site's inventory an shipped to the Destination.
• Trip Id — the id (unique name) of the generated trip. A trip is a summary of every customer a vehicle visited, every job it did (loading/unloading, heading to/coming from), and all the covered distance within the day. Click the cell to edit the name if required. Make sure it is a unique name, otherwise the two (or more) trips that have the same Date & Time and Trip ID will be treated as one trip (1 vehicle will be delivering orders, instead of two).

  Each record, for which Trip Id is not defined, is considered as a separate trip.

• Order Index — the index number (ordinal), according to which the destinations visited.

Defines the maximum amount of product(s) the site's inventory can hold. On reaching this Limit, the product(s) will be taken in equal shares to the destination object(s) despite the lack/absence of demand.

e.g. The Limit is set to 100 m³, the Source is defined by a group of 5 customers. In this case the amount taken from the inventory will be evenly distributed among these 5 customers, i.e., each customer will receive 20 m³ of products.

Push: uniform parameters

• Product — the product or group of products the policy is applied to.
• Limit type — the type of limiting rule that is applied to the defined Product:
  • Any — limit is reached on any product of the group.
  • Each — limit is reached on every product of the group.
  • Total — limit is reached by the group.
• Limit — sets the limit, on reaching/exceeding which the push-delivery will be triggered.
• Unit — the measurement unit, in which the limit is estimated.
• If not enough vehicles — defines the required action in case there is not enough vehicles to push-deliver the products:
  • Abort simulation — the experiment will be aborted, the error message will pop-up.
  • Skip — the issue will be skipped, the experiment will proceed. See the log file for details.

Shipping is simply prohibited. No orders will be sent for this combination of source / destination objects. You may use this policy to e.g. prohibit deliveries for a certain period.

No additional parameters are required.

How can we improve this article?

Send