Data Setup¶

The core of our Logiwa settings: order types, damage reasons, pack types, product types and groups, and location groups. Everything else is defined using these parameters.

Check with Accounting before changing order types

PO and SO types are used as conditions in client billing contracts. Notify Administration or Accounting before you create or delete one.

Auto Code Generation Preferences¶

You don’t need to modify this setup. It controls the generation of order codes: each time a manual order is created in Logiwa, the system automatically assigns a unique order code, unless the client chooses to override it.

Purchase Order Type¶

Each purchase order (PO) type defines the receiving workflow. If you create or remove a PO type, make sure to notify Administration so they can update client contracts, as these PO types are used to apply specific billing fees per client.

The Inbound team should typically use the following:

flowchart TD
  A([New inbound]) --> B{What is arriving?}
  B -- Full container or truck --> C{Which one?}
  C --> C1[53 ft Truck]
  C --> C2[40 ft Container / 40 ft Floor Container]
  C --> C3[20 ft Container / 20 ft Floor Container]
  C --> C4[HC Container]
  B -- 1–10 pallets or master cartons --> D{Many SKUs in mixed cartons?}
  D -- Yes --> D1[Open Receipt 2: scan one by one]
  D -- No --> D2[Open Receipt]
  B -- Return without a matching order --> E[Open Return]
  B -- Crossdock --> F[Crossdock]
  B -- Salesupply client --> G[ASN]
  B -- Client migration with serial numbers --> H[Migration Inventory]

Figure 1. Choosing a purchase order type. Details for each type are below.

Open Receipt / Open Receipt 2: Both have similar behavior. The key difference is that Open Receipt 2 requires scanning items individually (one by one). This is useful when receiving POs with many different SKUs and mixed cartons. For POs with fewer SKUs but large quantities, use Open Receipt. These types are generally used for smaller inbound volumes (e.g., 1–10 pallets or master cartons, less than a full container).
Migration Inventory: Used for inventory migrations and not included in billing contracts. It allows adding inventory when onboarding a client to Logiwa. However, using inventory adjustments via Excel is recommended instead. Note that POs do not allow receiving damaged products unless they are scanned individually. This PO type is useful when migrating SKUs with serial number tracking enabled, as scanning serial numbers is required and can only be done through a PO.
ASN: Use only for Salesupply clients.
Crossdock: Used for crossdock operations. Confirm with Accounting whether this PO type is tied to billing.
Open Return: Used for returns received without sufficient information to match an existing order in Logiwa, or for items originally shipped from other warehouses (e.g., Amazon, TikTok, or another 3PL). Since these cannot be processed through the return station, they must be received as standalone POs not linked to a shipment or sales order.
53 ft Truck: Applies a specific fee defined in the client contract. Use when receiving a 53 ft container.
40 ft Floor Container: Applies a specific fee defined in the client contract. Use when receiving a 40 ft floor container.
20 ft Floor Container: Applies a specific fee defined in the client contract. Use when receiving a 20 ft floor container.
HC Container: Applies a specific fee defined in the client contract. Use when receiving a high cube container.
40 ft Container: Applies a specific fee defined in the client contract. Use when receiving a 40 ft container.
20 ft Container: Applies a specific fee defined in the client contract. Use when receiving a 20 ft container.

For more information on how purchase order types work, please refer to the documentation here.

Shipment Order type¶

Each shipment order type (SO) defines the outbound workflow. Do not create or delete any SO types without first coordinating with Accounting, as they are used as conditions in billing contracts.

Below is an overview of each SO type:

flowchart LR
  A([New shipment order]) --> B{Type}
  B --> D2C[D2C Order: small direct-to-consumer orders, default]
  B --> B2B[B2B Order: business orders, FBM, large orders]
  B --> FBA[FBA Order: Fulfillment by Amazon]
  B --> SO[Sales Order] -. automated workflow converts .-> D2C
  B --> RI[Remove Inventory: IT only, not billed]

Figure 2. Shipment order types. Sales Order exists only because of a past integration error and is converted to D2C automatically.

Remove Inventory: Used only by the IT department to remove inventory. It is not tied to billing contracts and does not impact client invoicing.
Sales Order: Created in error for a custom integration (Mudify Dropstream) and cannot be deleted. It should not be used for processing orders. Some clients using custom integrations or manual entry may still select it; however, an automated workflow converts it to a D2C Order after creation. Do not use this type in automations or allocation logic.
D2C Order: Used for direct-to-consumer shipments (typically small orders). This is the default SO type in most cases and is included in billing contracts.
B2B Order: Used for business-to-business shipments, including FBM (e.g., TikTok fulfillment) and larger orders above a defined threshold. This type is included in billing contracts.
FBA Order: Used exclusively for Fulfillment by Amazon (FBA) shipments. This type is also included in billing contracts.

Although the configuration settings for the three primary SO types (D2C, B2B, and FBA) are identical, they serve as logical distinctions for operational clarity and billing purposes. Partial shipments are typically not allowed, and no changes to these settings are required.

If you need to modify settings or create a new SO type, refer to the documentation in the link below for more details.

Work Order Type¶

Each order type (WO) defines the assembly workflow. You generally don’t need to create or delete additional types unless you want to introduce more complexity into the allocation algorithms for work orders. Both work order types share the same billing conditions.

The difference lies in their workflow:

flowchart LR
  A[Work Order] --> P[Pick job] --> K[Kit created]
  B[Backflush] --> K2[Components converted directly into kits to stock]

Backflush: Used when you want to skip the picking stage and directly convert components into “kits to stock”. This type does not create a pick job since there is no picking stage.
Work Order: This follows the standard assembly process. It does create a pick job, which must be completed before the kit can be created.

For more detailed information, click the following link.

Damage Reasons¶

Here, you can create new damage reasons to be used in Logiwa.

As a note, the only way to assign a “Missing” status to a product is through picking jobs.

For more detailed information, click the following link.

Pack type¶

You can create new pack types here that will be available for all products. However, as a standard practice, we assign “Each” as the default Unit of Measure (UoM). In some specific cases, we use “Unit” instead (e.g., for products like Hot Chocolate or Tu Salud Íntima).

To maintain consistency, it is recommended to standardize pack types across clients by using “Each”, as we have been doing.

That said, this section also allows you to define additional pack types for hierarchical or irregular packaging structures. These are useful when products can be sold in multiple configurations, such as master carton, pallet, or carton.

Some clients rely heavily on hierarchical pack types for all their SKUs—for example, Sense Condoms—so in those cases, a more detailed pack type structure is required.

For more detailed information, click the following link.

Product type¶

You can create product types to help filter data in views and to use as conditions when configuring allocation, replenishment, and putaway algorithms.

They can also be applied to filter picking, replenishment, and counting jobs. Product types are especially useful for replenishment, as they allow you to build dynamic algorithms that can differentiate by client—something that cannot be done directly when creating replenishment jobs. For example, the product type T1TAN is used specifically for this purpose.

In addition, product types can be used as conditions to control certain workflows and to configure packing station warnings.

In summary, product types act as flexible filtering tools that help control behavior across multiple processes and automations.

Product group¶

Initially, product groups were intended to provide a higher level of product classification. However, in practice, we currently use only the following:

Oversized: Used to identify heavy or bulky items that should not be processed by the D2C department. Instead, they are handled by the B2B small orders department through specific job workflows. This is currently applied to clients such as Heria and Thenx.
Velocity Groups (AA, A, B, C, D): Assigned to products based on demand. These groups are fundamental to the velocity-based replenishment algorithms. Refer to the Algorithms section for more details on how they are used.

Any other product groups are not actively used. They do not drive any system behavior within Logiwa and are considered non-functional. But I do not recommend to delete them because we have many products which use them and it could break the database if the interface allow you to delete them.

Location Group¶

Location groups are essential for applying storage fees in billing, for use as conditions in allocation, replenishment, and putaway algorithms, and for creating replenishment and counting jobs.

Whenever you create new locations, you should assign the appropriate location group to maintain a logical warehouse layout.

Note: For locations of type Rack, the location group should always be left empty to maintain standardization.

Location Zone¶

No content yet in Notion.