Pallet Allocation Setup

These settings control how pallets are assigned to outbound or transfer orders and how loading instructions are generated.

Pallet Sample Split ID Suffix

A single character (e.g., “S”) added to the end of a Pallet ID when a pallet is split for a sample inspection. For example, splitting pallet “APPLE001” creates a new sample pallet “APPLE001S”. The split reduces the quantity on the original pallet line and generates a second pallet line carrying the split-off Pallet ID and quantity. This is equivalent to a pallet breakdown and buildup. Required if you use the Split for Sample Inspection feature.

Suppress Allocation Batching

  • OFF (default): When allocating pallets, the system groups allocations into batches and presents a confirmation step before releasing each batch. Provides a review checkpoint, useful for high-volume operations.
  • ON: The batch confirmation step is skipped. Allocations release immediately. Faster workflow but removes the review gate.

Note

Allocation batching is primarily associated with the legacy allocation method, where allocation is performed without the use of produce orders. Produce orders do, however, also support allocation batching.

Outbound Loading Instruction Lines Source

This setting applies specifically to loading instructions generated via the Issue Loading Instructions job queue entry. It does not affect loading instructions that users generate manually using the Loading Instruction buttons in the report sections of a Transfer Produce Order, Outbound Produce Order, or Freighter Trip Leg — those always use the allocated pallets.

For job-queue-generated loading instructions, this setting controls what each line represents:

  • Allocated Pallets (default): Each line represents a specific physical pallet that has been allocated to the order. Requires pallets to be pre-allocated before the job runs.

  • Order Lines: Each line represents a line from the produce order, using shortcut codes and/or fruit specification values. Use this when pallet IDs are not yet known and pallets cannot be pre-allocated — the loading instruction is generated from order intent rather than actual pallet assignments.

Transfer Loading Instruction Lines Source

Same as above, but applies to job-queue-generated loading instructions for transfer orders.

Default Organisation Code

When loading instructions are generated from Order Lines (not allocated pallets), this Organisation Code is used as the default on those lines.

Check Produce Order Mandatory Fields

  • OFF (default): No mandatory field checks are applied when working on produce orders.

  • ON: Allows the business to define which fields may not be left empty on a produce order when it is submitted for booking or released — both of which typically represent a handover to the next user in the workflow. This minimises back-and-forth between users when the receiving user needs to perform the next task but finds that required information was not completed by the previous user. This is the recommended setting.

Require Fully Allocated Produce Orders

  • OFF (default): Produce orders can be confirmed even if some or all lines have no pallets allocated to them.

  • ON: The system blocks confirmation of any produce order that has lines which are not fully allocated. Every order line must have its full quantity allocated to pallets before confirmation is allowed.

Delete Unallocated Order Lines on Produce Order Confirmation

Controls what happens to unallocated produce order lines when a Produce Order Confirmation pallet file is processed:

  • OFF (default): All order lines are retained after the confirmation file is processed, including lines with no pallet allocation or partial allocation.

  • ON: Any order lines with zero allocated pallets are automatically deleted as part of processing the Produce Order Confirmation pallet file. The produce order ends up in a clean state that reflects only the quantities and specifications that were actually loaded.

Allow Outbound Order Allocation for Transit Pallets

  • OFF (default): A pallet that is currently in transit cannot be allocated to an outbound produce order. The pallet must first arrive at its transfer destination before outbound allocation is possible.

  • ON: Pallets that are currently in transit can be allocated to outbound produce orders.

    Note: a separate rule always applies regardless of this setting — if a pallet is already allocated to an outbound produce order and a user wishes to also allocate it for transfer, the transfer destination must be one of the loading freight points from which the outbound produce order is due to load. If the destination does not match, the system will reject the transfer allocation.

Enable Vitrax Consignment Release

  • OFF (default): Vitrax integration is hidden. No Vitrax-related actions or fields are visible.

  • ON: Enables integration with the Vitrax system. An “Issue Consignment Release” action becomes available on produce order pages, which triggers a job queue entry that generates a file for Vitrax to import. When Vitrax processes this file, it unlocks the consignment on their side so that corrections or changes can be made before a new pallet out file (PO file) is transmitted. Relevant for businesses operating consignment arrangements where pallet data is managed in Vitrax.

Use Produce Shipments

  • OFF (default): Outbound operations are purely order-based. The Produce Shipments document type is unavailable.

  • ON: Activates the Produce Shipments module, which introduces an extra grouping layer between produce orders and freight. A Produce Shipment can group multiple produce orders for the same customer on the same freighter trip leg. This reduces manual work — for example, instead of updating the trip leg code on ten produce orders individually, a user can change it on the parent Produce Shipment and the system cascades the change to all related orders automatically. Any other updates that apply to all orders in the shipment can similarly be made once at the shipment level.