• Saves Time on Daily Tasks: Handles routine, repetitive operations so you can complete everyday workflows faster.
• Supports Dev & Testing Teams: Quickly prepares test data and scenarios, saving engineering and QA teams time on setup.
• Locate Missing Stock: You don’t find a pallet in your warehouse? ask Jarod to track its latest movements.
• Extracts Data & Reports: Quickly retrieves the information and reports you need without manual searching.
• Executes Admin Tasks & Analysis: Handles administrative duties and performs deep data analysis on demand.

As usual, if you prefer watching a video instead of reading check it out here:

Before we start

We integrated Jarod natively into our TLP platform so that every solution built on top of TLP, such as our WMS can automatically leverage its capabilities, here are some key-decisions we took in the design of Jarod:

1. Jarod operates using your current user permissions. If your account is restricted from adjusting stock units, Jarod is subject to the exact same restriction..
2. We integrate with multiple LLM providers such as: Claude, Gemini, DeepSeek, and OpenAI.
3. To manage costs effectively, system administrators can assign specific LLMs by user role; for example, granting managers access to top-tier OpenAI and Claude models while restricting operators to DeepSeek.
4. Jarod is environment-aware. In development and quality environments, it has greater operational freedom, for instance, allowing users to manually create batches. In production, however, Jarod capabilities are restricted by business rules. Actions like creating batches cannot be performed manually in production, as those records must be imported directly from SAP.

Jarod is always accessible from the top-right corner, directly below your avatar image (as shown in Figure 1). Simply click the button to open the panel. You can choose to view the panel as an overlay on top of your content (My preferred view), side-by-side, or as a pop-up window.

Todays Scenario

In this post I will show you a concrete example related to stock unit genealogy, but to be able to request a genealogy we need to first do some material transfers between stock units and since we are talking about AI why not let Jarod prepare the data for us :)

Data Preparation

To prepare the genealogy data I will first ask Jarod to create an initial stock unit, run a series of splits and transfers, and print the labels of the generated stock units too on a label printer.

Here is the prompt:

- Create a stock unit of 100 PCS (you choose the material and the location). This will be our INITIAL stock - unit.
- From the INITIAL stock unit split 11, 21, and 51 pieces.
- From the INITIAL stock unit split 11, 21, and 51 pieces.
- From the stock unit with 51 pieces split 5, 12, and 17 pieces.
- Transfer 3 pieces from the stock unit with 17 pieces to the INITIAL stock unit.
- Merge the stock units with quantities 5 and 12 into a new stock unit, then transfer 8 pieces from it to the INITIAL stock unit.
- Print all the labels on printer LBL-01.
- Show me a summary of what you did, including the stock unit code, initial quantity, current quantity, and notes.

In this video you can see the prompt (in italian) and how stock units are created by Jarod and labels printed on the physical printer.

The end-result of the previous prompt is that Jarod created an initial stock unit SU26-0000000001 and then executed several splits, transfers, and merges starting from this unit. The following table summarizes what happened:

Testing the genealogy

Now that our scenario is ready, we can move on to the actual test. so we ask Jarod the following prompt:

Show me the forward genealogy of the INITIAL stock unit.

And the answer of Jarod is the flowchart shown in Figure 2, Let’s walk through the graph in Figure 3 to see what happened:

• Starting from the INITIAL stock unit of 100 pieces, the user with trigram ENZ (which is Enzo) split 11, 21, and 51 pieces, which created three new stock units: SU#2, SU#3, and SU#4.
• Next, SU#4 was split again into 5, 12, and 17 pieces, which created SU#5, SU#6, and SU#7.
• 3 pieces were transferred from SU#7 back to the INITIAL stock unit.
• SU#5 and SU#6 (of 5 and 12 pieces) were merged into SU#8 with 17 pieces.
• 8 pieces were transferred from SU#8 to the INITIAL stock unit.
• Matching arrow colors and labels (e.g., blue arrows marked Trx #1) indicate actions executed within the same transaction. Separate transactions are distinguished by different colors and updated transaction numbers.
• All the operations are registered under the logged-in user: enzo, not under a generic AI user, because Jarod always acts on behalf of the currently logged user.

Summary

In this post we introduced Jarod, the AI assistant of the TLP platform. The key takeaways from todays post are:

• Describe it, don’t build it. Jarod turns a plain-language description into a complete test scenario in seconds, with stock units, splits, transfers, merges, it can even print labels!
• Same permissions as the user. Jarod acts with the profile and permissions of the logged-in user, and in production its capabilities are restricted to respect business rules.
• Your choice of model. Administrators decide which AI models (OpenAI, Claude, Gemini, DeepSeek) each user can use, which keeps costs and performance under control.
• Platform-wide. Since Jarod lives in the TLP platform, every solution built on top of it, including custom ones, can use it.

In the next posts I’ll show more use cases where artificial intelligence can make our operations simpler, faster, and more efficient. stay tuned!

In this exercise we are going to satisfy the following requirements:

• Inventory allocated to drawer-level storage must be trackable without the use of physical labels.
• The WMS must support a configurable location policy Single Material / Single-Batch that restricts a drawer to a single SKU and batch number.
• The WMS must support a configurable location policy Single Material / Multi-Batch that restricts a drawer to a single SKU while allowing differing batch numbers.

Modeling drawer locations

Every compartment within the drawer must be assigned a unique location name and labeled with its designated location barcode, we can use the Add Bulk Locations functionality to quickly create our desired locations as shown in the Figure 1 below, refer to this post for more details on creating locations and printing their barcodes.

The end result is that we get the following 12 locations that represent our 3x4 drawer bins.

Now that we created the locations in our system, we can print their labels and physically apply them to the drawer bins, the final result is something similar to Figure 3, we can observe the following:

• The drawer is composed of three columns 01-01, 01-02, and 01-03.
• Each column is composed of four bins A, B, C and D.

Business rules

A Business Rule is a configurable policy attached to a location (or a location class) that the system fires automatically whenever a relevant warehouse action happens, for example when someone relocates stock into that location. Business rules can by used to execute:

• Checks before/after an action is executed, for example making sure that the relocated stock unit has the same bin material.
• Actions before/after an action is executed, for example merging the relocated stock unit into the bin stock unit.

Business Rules can be assigned to locations however in a real scenario a single drawer might have hundreds of locations, thus it is generally suggested to configure them at a higher level following this process:

1. Create a Location Class for example SB-DRAWER-BIN for bins that accept single batches.
2. Assign the desired business rules to the location class.
3. Assign the class to the desired locations.

As you can see in Figure 4 we assigned classes as follows:

• Column 01-01 locations -> No location class, thus they act as normal locations.
• Column 01-02 locations -> SB-DRAWER-BIN thus the Single-Batch rule is enforced.
• Column 01-03 locations -> SM-DRAWER-BIN thus the Single-Material rule is enforced.

Testing

To test the system behavior lets create 4 stock units in an initial storage location, for example A1-T01.

• SU#1, SU#2 have the same material and batch.
• SU#3 has the same material as SU#1 and SU#2 but with a different batch number.
• SU#4 has a different material.

No business rules

If you recall, column 01-01 bins are configured with no business rules, which could represent a scenario in which we want to put multiple bags in a single bin but maintain a strict stock separation.

Lets use the mobile Move app to relocate both SU#1 and SU#2 to location 01-01-A and see what happens.

As you can see in Figure 5, nothing special happened, both SU#1 and SU#2 simply changed location from A1-T01 -> 01-01-A, however they remained intact.

Similar batch

Drawer column 01-02 represents the scenario in which we don’t want to allow mixing stock of different batches in the same bin, in other words we can store both SU#1 and SU#2 in the same bin because they have the same material and batch number B26000001, however we cannot store SU#3 in the same bin because although it is of the same material HEX-M06-050-SS its batch B26000002 is different.

Figure 6 illustrates the end-result of moving SU#1 and SU#2 to 01-02-B, here is what happened:

• The Move transaction was accepted because both stock units have the same material and batch.
• A new stock unit SU26-0000000005 was automatically created in 01-02-B, the new stock unit inherited the same material HEX-M06-050-SS and batch number B26000001 of the moved stock-units.
• The quantities of SU#1 and SU#2 was transferred to SU26-0000000005 which has the quantity of 200 PCS.
• Stock-units SU#1 and SU#2 where logically deleted since their quantity became 0 PCS, and they are not visible anymore.

But what happens if we try to move SU#3 to the same bin 01-02-B?

Since the stock unit has a different batch the system generates an error preventing the user from executing such action, the error says: Location A1-Z1-01-02-B accepts similar batches only, relocated batch B26000002 is different from current batch B26000001.

Similar material

Drawer column 01-03 represents the scenario in which we want to allow mixing stock of the same material even though they have different batches, so differently from the previous case we should be able to store SU#3 and SU#5 in the same bin even though they have different batches, however we cannot store SU#4 in the same bin because it has a different material HEX-M06-020-SS.

Figure 7 illustrates the end-result of moving SU#3 and SU#5 to 01-03-C, here is what happened:

• The Move transaction was accepted because both stock units have the same material.
• A new stock unit SU26-0000000007 was automatically created in 01-03-C, the new stock unit inherited the same material HEX-M06-050-SS.
• Since the moved stock units had different batches, a new batch B26000004 was created.
• The quantities of SU#3 and SU#5 was transferred to SU26-0000000007 which has the quantity of 300 PCS.
• Stock-units SU#3 and SU#5 where logically deleted since their quantity became 0 PCS, and they are not visible anymore.

Now if we try to move stock unit SU#4 to bin 01-03-C we get the following error because the system does not allow mixing different materials in the same bin: Location A1-Z1-01-03-C accepts similar materials only, relocated material HEX-M06-020-SS is different from currently stored material HEX-M06-050-SS.

Summary

In this tutorial we modeled a warehouse drawer in our WMS solution and used business rules to control how its bins behave. The key takeaways are:

• Drawers are just locations. Each bin is modeled as its own location with a barcode label, and Add Bulk Locations creates an entire drawer in a few clicks.
• Business rules enforce policies at the location level. Some rules run checks, such as rejecting a batch or material that doesn’t belong in a bin, while others run actions, such as merging incoming stock units into a single one.
• Location classes keep configuration manageable. Rather than attaching rules to hundreds of individual bins, you define a class such as SB-DRAWER-BIN once, assign its rules, and apply it to every bin that shares the same policy.

With these building blocks, modeling a drawer in TLP WMS is quick, and the system keeps it consistent: stock stays where it belongs, and operators get clear feedback on their mobile devices when a move would break the rules.

In todays post we are going to see how to enable label printing on a Zebra ZD421 printer for the following deployment scenario:

• A local Zebra ZD421 label printer configured with IP address 192.168.1.201.
• The TLP Server is installed on the cloud.
• The TLP Server cannot communicate directly with the label printer.

Deployment architecture

Since the TLP Server cannot communicate directly with our printer we need to install and configure an external print-engine on an on-prem computer, in our example I will install the print-engine on my laptop.

As you can see in Figure 1, my laptop can communicate with both the TLP Server (installed on the cloud) and the ZD421 Printer, the print-engine will pull print jobs scheduled on the printer and print them on the label printer.

Printer configuration

To create the printer in the system I logged to the MDC organization and from the Printers application I created a new printer named LBL-01 and configured it as follows:

• Specified the name LBL-01.
• Specified the queue type to be Pull which means that print jobs will be pulled by the print-engine instead of being pushed by the server.
• Specified the IP address of my printer as 192.168.1.201 and port 9100.

The Pull queue type is required because in our scenario the server cannot push print jobs directly to the printer, it is the print-engine running on my laptop that will periodically pull print jobs from the server.

Print first label

Lets print our first label following the instructions shown in Figure 3, and then navigate to the Print Jobs tab to see the generated print job.

The print job was created and is currently marked as Scheduled. This is expected because the print-engine is not yet configured. Once the engine is configured and started, the label will be printed.

Configure the print-engine

On my local computer I downloaded the print-engine and installed it under D:/temp/PrintEngine1 and using a text editor I modified the configuration file as shown in Figure 5 specifying:

• The global name of our printer org[MDC].LBL-01.
• The baseUrl, username, and password of the TLP server.

Starting the print-engine

The print-engine can either be installed as a service or run manually, since we are conducting a test we will simply run it manually by double clicking the /bin/start.cmd command.

As soon as the engine starts it will poll the TLP server for print jobs scheduled on the configured printer org[MDC].LBL-01 and print them. Figure 6 shows the engine logs in which we can observe that the print job was processed successfully.

We can also observe that the print job status changed from Scheduled to Processed as shown in the image below.

Summary

The TLP Platform is designed taking in consideration different deployment scenarios, wether its installed on premise or on the cloud or as a saas it should be possible to easily configure printers and print labels and reports on them.

In this post we illustrated how easy it is to configure and print labels on a local printer in a hypothetical deployment scenario in which the TLP Server is running on the cloud and cannot communicate directly with a local printer, hence an external print-engine was used to allow printing.

Also, we observed that even if the print-engine is not running, print jobs are not lost, they are scheduled by the system and printed as soon as the engine is started, system administrators can see exactly what, who, and when print jobs where printed on a printer.

To illustrate this integration concept, we will use a simple warehouse process: relocating stock to a new storage location.

Mobile

Industrial mobile devices used on the shop floor are generally equipped with 1D/2D barcode scanners. TLP integrates seamlessly with such devices to properly receive and process scanned barcodes. How barcode scans are managed depends on the mobile device — for example, ZEBRA handles them differently from HONEYWELL — so we need to make sure the device type is correctly set in the application settings, which in our demo is a Zebra TC5x device.

To test the barcode scanner we will use the warehouse Relocate application to relocate two stock units to location DOCK-02, using the application you can observe the following:

• Users can start scanning stock units immediately upon opening the app, there is no need to select the desired field before scanning.
• Scanning each stock unit increases the counter, showing the total number of items that will be relocated.
• The application automatically recognizes different barcode types; for example, scanning a location barcode immediately populates the Target Location field.
• The application includes built-in action triggers; for instance, scanning a storage location barcode twice (referred to as Double Scan) executes a transaction confirmation.

The following is a video that illustrates how barcodes are scanned when relocating stock-units in your warehouse.

Manual Input

On those rare occasions (for example because the barcode is damaged) you might need to enter the barcode value manually instead of scanning it. In such a case, you have to tap the manual input icon in the header, which opens a bottom sheet that lets you enter the value using the keyboard.

Desktop

On the desktop side, barcode integration is more interesting because some functionalities are barcode aware while others are not. The first step is to make sure that barcode scanning is enabled, which is visible in the footer as shown in the image below. Clicking on the barcode icon opens the Scanner Settings popup, from which you can:

• Enable / Disable capturing scanned barcodes.
• Manually simulate scans if required.
• See a history of the last scanned barcodes.

Opening the Relocate functionality, you can notice a small barcode icon on the top left, which indicates:

• The functionality is barcode aware.
• The pulsing green background indicates that it is currently linked to the scanner, thus scanned barcodes will be captured and processed by this popup.

Scanning the barcodes DOCK-02, SU26-0000000001, and SU26-0000000002 will automatically populate the screen as shown in the image below, you can observe that DOCK-02 populated the TARGET LOCATION field, while the other two barcodes populated the list of UNITS TO RELOCATE.

If we open the Scanner Settings popup from the footer we can see the list of scanned barcodes from the previous transaction.

Finally, if we focus a text field — for example, the Search field in the main screen — the popup will be temporarily disconnected from the scanner, allowing the user to scan values directly into the focused field, as shown in the image below.

Summary

The TLP platform is designed for the shop floor, where fast data entry and minimal human error are essential, barcode scanning is central to that goal. The key takeaways are:

• Device-aware handling, mobile scanning behavior adapts to the connected device (ZEBRA or HONEYWELL), configured once in the application settings.
• No field selection needed, on mobile, operators can start scanning immediately; the barcode type is recognized automatically and routed to the right field.
• Double Scan confirmation, scanning a location barcode twice executes the action, letting operators confirm transactions without touching the screen.
• Manual fallback, when a barcode is damaged or unreadable, its value can be entered manually from the same screens used for scanning.
• Barcode-aware desktop popups, functionalities like Relocate can link to the scanner to populate fields directly from scans, and automatically release that link when a text field is focused so operators can type or scan into it directly.

This barcode integration consolidates our countless years of experience on how shop floor applications should be designed.

While many of our users love the robust features of MSSQL, we know that the open-source community and the flexibility of PostgreSQL are high priorities for modern engineering teams.

Why this matters:

• Open Source Freedom: Leverage the power of a community-driven database without being locked into proprietary licenses.
• Cost Efficiency: Reduce overhead costs by utilizing high-performance, open-source infrastructure.
• Advanced Features: Benefit from Postgres’ rich support for complex data types, JSONB, and extensibility.
• Choice: Whether you prefer the reliability of MSSQL or the agility of Postgres, the choice is now yours.

Our mission is to meet you where your data lives. By adding Postgres to our supported ecosystems, we’re making it easier for you to scale on your own terms.

Today we are glad to introduce our Mobile Quick Actions application that is designed to solve a common shopfloor need in an elegant way, the key benefits of Mobile Quick Actions are:

1. Super fast scanning.
2. Can be added through configurations (no development needed).
3. Can be configured with minimal effort (hours).

As always, for those in a hurry here is a video that DEMOs the functionality.

Mobile Quick Actions

If you think about it, many shopfloor operations can be represented as a sequence of barcode scans, and most importantly over time operators develop a muscle-memory for these sequences much like a typist whose fingers find the keys instinctively without conscious thought.

Lets for example think about the process of relocating a handling unit in a warehouse, it could be represented in the following sequence:

Step 3 is the interesting one, we asked ourselves a question: why don’t we represent such action with a barcode an operator can scan to tell the system his intent? so we did! and we called it a Mobile Quick Action or simply MQA, so the original sequence to relocate a handling unit became:

Iterating over and over the original concept we refined it more as follows:

• Allow scanning multiple Handling Units and Stock Units.
• Ignored the scanning sequence, operators can scan the target location barcode first or last.
• Provided a way to configure the executed logic through scripting.

And now, we have a framework that allows our customers to implement any sequence of scans as an MQA in a matter of hours through configurations! Lets see how it works.

MQA Relocate

Before looking into the specifics of the Relocate MQA, lets have a basic understanding of how the MQA framework works.

The MQA application is displayed on the mobile home page as shown in Figure 3, by default its enabled for all users, however each user can see and execute only the actions to which he has the corresponding permission.

Another important aspect is the MQA label, such labels can be printed from the desktop application and placed physically where actions are executed, for example the Relocate MQA could be placed on shelves; users should double-scan the MQA barcode to confirm the operation.

Tapping on the MQA application you get the list of available actions, you don’t need to select an action; you can start scanning barcodes immediately and then double scan the desired action barcode.

Testing time, in this video we simulate relocating 10 handling units HU26-01, HU26-02 up to HU26-10 to a new target location named DOCK-01, we scan the barcodes in the following order:

• Scan all 10 handling units.
• Scan target location DOCK-01.
• Double scan the relocate MQA to confirm the operation.

Summary

This post introduced Mobile Quick Actions, a TLP framework designed to streamline repetitive shopfloor operations through barcode scanning. The key takeaways are:

• Scan-driven workflow — any multi-step shopfloor operation can be reduced to a sequence of barcode scans, letting operators rely on muscle-memory for fast and accurate execution.
• MQA barcodes — actions are represented as physical barcodes placed at the point of use; a double-scan confirms the operation, eliminating the need to navigate menus.
• Flexible scanning order — operators can scan handling units and the target location in any order before confirming with the MQA barcode.
• Configuration over code — new actions can be introduced through scripting and configuration in a matter of hours, with no custom development required.

The TLP Scheduling Module is a versatile engine designed to schedule (either manually or fully automated) various operational demands such as transport orders, picking and production orders. It generates a list of tasks assigned to available executors — for example: warehouse personnel, work-centers, AGVs … etc.

Imagine a WMS that doesn’t just store data, but actively orchestrates your floor. A system that directs every operator’s current task and future move, dynamically shifting priorities in real-time. Today, we’re exploring this ‘What If’ through the lens of stock replenishment—though the same logic can be scaled across your entire operation.

Scenario

In our scenario we will demonstrate how TLP can satisfy the following user requirements realted to WMS and scheduling:

Figure 1 gives a visual overview of how we want to manage material reordering in locations of bays 01-01 and 01-03 of area A1.

1. Bay 01-01 should store stock of material HEX-M05-010-SS, which represents stainless steel bolts of 10mm length.
2. Bay 01-03 should store stock of material HEX-M05-020-SS, which represents stainless steel bolts of 20mm length.
3. Shelves C-G act as reserve locations and have a capacity of 1 pallet.
4. When a pallet is removed from shelves C-G, the system should automatically pull a new pallet — of the same material — from the overstock area in A2.
5. Execution of transport orders is restricted to users with the Material Handler role. Furthermore, picking pallets from high shelves H, I, and J requires a high-reach truck and the corresponding High Reach skill; standard forklifts cannot be used to pick from these locations.

We will also assume we have the users listed in the table below. Note that Enzo can only operate a classic forklift, while Luca is also qualified to operate high-reach trucks for picking pallets from high shelves.

Table 2: Users

FL: Fork Lift | HR: High Reach

Avatar	Username	Role	Description	FL	HR
	Elena	Supervisor	The warehouse supervisor with NO training for driving forklifts or high-reach trucks.	-	-
	Enzo	Material Handler	A material handler trained and certified to drive a forklift.	x	-
	Luca	Material Handler	A material handler trained and certified to operate both a forklift and a high-reach truck, the latter being required when picking from high shelves H, I, and J.	x	x

Location Configuration

Now that the requirements are clear, let’s see how locations in bays 01-01 and 01-03 are configured in TLP to meet those business requirements. Key points to note:

• All locations are configured with a capacity of 1 WHU, meaning at most one warehouse handling unit can be stored in each location.
• Locations 01-01-C through 01-01-G have their reorder attributes configured to match the scenario requirements: when the location quantity reaches or falls below the reorder point of 0 WHU, a new HU with material HEX-M05-010-SS is automatically pulled from an overstock location.
• The same logic applies to locations 01-03-C through 01-03-G, but for material HEX-M05-020-SS.

Triggering Reorder Logic

For our first test, let’s assume the warehouse locations are in the state shown in Figure 3:

• All reserve locations are currently filled with an HU. For simplicity, HU names follow the format HU26-01 instead of HU26-0000000001.
• Overstock locations in area A2 contain enough handling units of materials HEX-M05-010-SS and HEX-M05-020-SS for our test.

We can observe location status in the system using the Counters View. The Current column shows 0 for pickface locations (shelves A and B) and 1 for reserve locations (shelves C-G).

To trigger the reorder logic, we use a mobile quick action to relocate handling unit HU26-01 from 01-01-C to 01-01-A, thereby freeing location 01-01-C.

Within a few seconds, the WMS reorder logic detects that location 01-01-C is empty and generates a transport order to pull a new handling unit from overstock area A2. The effect is visible in Figure 6:

• Location 01-01-C current count changed from 1 → 0 (due to the relocation).
• Location 01-01-A current count changed from 0 → 1 (due to the relocation).
• Location 01-01-C incoming count changed from 0 → 1, indicating a transport order was automatically created to bring a new HU to this location.

Transport Order Scheduling & Execution

Now to the interesting part: how are transport orders communicated to forklift operators and executed? TLP has a powerful and efficient Scheduling Module designed to create and assign tasks to available executors. In our scenario:

• Tasks are Transport Orders.
• Executors are users with the Material Handler role connected to a handheld device — in other words, Enzo and Luca. The handheld device could also be a Vehicle Mount Computer such as the Zebra VC8300.

The previously created transport order is scheduled automatically by the system and assigned to Enzo.

Following the system instructions, Enzo proceeds to location 01-01-B in area A2 and performs a double-scan of HU26-09 to verify he picked the correct unit before transporting it to location 01-01-C in area A1.

Upon arriving at location 01-01-C, Enzo double-scans the target location barcode to complete the transport order, physically deposits HU-09 there, and moves on to the next task.

After completing the transport order, location 01-01-C counters update as follows:

• Current count changed from 0 → 1.
• Incoming count changed from 1 → 0.

Multiple Transport Orders

Let’s ensure only Luca is connected to the system and relocate 6 handling units from reserve locations to outbound docking location DOCK-01. This action frees 6 locations, causing the system to pull 6 new handling units from overstock area A2 and assign them all to Luca.

Of the 6 transport orders, 3 of them — TO26-32, TO26-33, and TO26-34 — pick from high shelves I, H, and J.

Now let’s disconnect Luca and log in as Enzo. After a few seconds the Scheduling Module reschedules and reassigns tasks to Enzo.

Notably, only 3 of the 6 tasks are reassigned — because Enzo does not have the skill required to pick from high shelves.

Finally, connecting with two devices simultaneously — one for Enzo and one for Luca — the Scheduling Module distributes the workload across both operators, respecting each person’s skills.

Summary

This post demonstrated how TLP handles end-to-end material replenishment, from detecting an empty location to scheduling and executing transport orders on the warehouse floor. The key capabilities covered were:

• Location-level reorder configuration — each bin can have its own reorder point, quantity, and target material.
• Automatic reorder triggering — the system monitors locations and generates transport orders without manual intervention.
• Skill-aware task scheduling — the Scheduling Module considers operator certifications (e.g., High Reach) when assigning tasks, ensuring only qualified personnel receive specific jobs.
• Dynamic rescheduling — as operators connect and disconnect, the scheduler continuously rebalances the workload across available executors.

Smooth operations don’t happen by accident. That’s where Elena comes in. From system monitoring to exception management, her supervisory role is the glue that holds the workflow together—more on that in our next post!

If there’s one thing we’ve learned from years on the shop floor, it’s this: the most powerful WMS or MES solution is only as good as the device in the operator’s hand. too often, handheld integration is treated as an afterthought, for this reason we designed and built TLP Mobile to be straightforward to configure and seamless to operate.

In this post, I will walk you through the installation, configuration, and initial setup of TLP Mobile, along with some key concepts. As always, if you are in a hurry here is a quick video:

Installation

TLP Mobile is an Android application shipped as an APK file within the TLP distribution. While it can be installed directly on a handheld device, companies using MDM tools like Microsoft Intune, VMware Workspace ONE, or ManageEngine can distribute it automatically by:

• Uploading the APK to the MDM’s app repository.
• Assigning it to the relevant device groups.
• Setting the installation type to “Required” or “Silent Install”.

Once installed, tap the application to open it. You will be taken to the Select Profile screen, if you see it, the installation was successful.

Configuration

Add Profile

You might be wondering — what is a Profile? A profile tells the mobile application which TLP Server to connect to. In most cases, a handheld device connects to a single server (the production server), but during implementation and testing you will typically point it to a Dev or Test server first.

The following image illustrates a mobile configured to connect to three different environments, Dev, QA, and Prod, to avoid logging on the wrong profile it is possible to configure each profile with a dedicated color.

Adding a profile is straightforward. An IT administrator logs into the TLP desktop application, clicks on the system version shown in the footer to reveal a QR code, and then scans it from the handheld device as shown in the example below.

After scanning the QR code, you will see the new profile added to the list — in this example, it is called QA. Tap on it to proceed to the login step.

Add Login

Adding a login (or user) is also straightforward, the user — in this example we will use lisa, logs into the TLP desktop application using her credentials, clicks on the Mobile Login to reveal a QR code that represents a PAT (Personal Access Token), and then scans it from the handheld device. See the example below.

After scannng the QR code, you will see the new user added to the list. Tap on it and specify either the PIN or password to login to the mobile application.

Congratulations! you just installed and configured the TLP mobile application.

Testing

To test the mobile lets try to relocate multiple handling units HU(s) using the MQA (Mobile Quick Action) application, here is what we will do:

1. Open the MQA application
2. Scan the barcodes of the handling units to relocate
3. Scan the barcode of the target location
4. Scan the barcode of the desired action — in our case Relocate
5. Scan the barcode of the desired action — in our case Relocate a second time to confirm the operation

Summary

TLP Mobile is a core module of our TLP platform, we designed it to maximize operator efficiency in the shop-floor. It supports both handheld devices (eg. Zebra and Honeywell), as well as vehicle-mounted devices (VMDs).

If you are in a hurry, you can watch this video, the first part provides an explanation about the warehouse we are going to model, while the second part shows how our TLP platform is used to create the warehouse locations, if you are not in a hurry then I suggest to read through this article and then watch the video.

Pragma-Bolts

Pragma-Bolts is a leading company that produces and sells bolts, company operations spans four geographically distributed warehouses, produced bolts are shipped and stocked in the Main Distribution Center known as MDC.

The MDC serves as a central hub, replenishing stock for three retail shops MILANO, ROMA, and VENEZIA which handle B2C consumer sales. Additionally, MDC manages a B2B channel by shipping products directly to other businesses.

What is a Location?

A Location represents the physical (or virtual) places within a warehouse. These can include bays, shelves, bins, floor locations and so on. In a WMS, each location is defined with attributes such as unique name, capacity, storage policies and rules.

By mapping the physical warehouse into a logical system, the WMS gains real time visibility and control over inventory movement and storage. An accurate mapping of physical warehouses locations provides multiple benefits such as:

• Improved Inventory Accuracy: Accurate locations are the backbone of inventory accuracy. When every inventory item is assigned to a specific location, the WMS can track stock levels in real time.
• Faster Operations: Storage locations directly impact picking and putaway efficiency, WMS uses location data to guide warehouse operators to the optimal place to store incoming goods (put-away or check-in) and the fastest path to retrieve them during the picking process.
• Better Space Utilization: Warehouse space is expensive. A WMS that leverages accurate storage location data can optimize how space is used by considering factors such as item dimensions, weight, turnover rate, and compatibility with other products.
• Enhanced Traceability and Compliance: For industries such as food, pharmaceuticals, and manufacturing, traceability is critical. Storage locations allow the WMS to track where each batch, or stock unit is stored at any point in time.
• Scalability and Operational Consistency: As warehouses grow or change, having a standardized location structure within the WMS ensures consistency across operations. New staff can be trained faster, processes become repeatable, and expansion or reconfiguration becomes easier to manage.

Naming Locations

Generally locations are identified by their coordinates, for example assuming that the following rack is physically located in a zone named A1-Z1 and aisle 01, we could model it with 6 locations following the pattern {Zone}-{Aisle}-{Column}-{Level} as follows:

• A1-Z1-01-01-A
• A1-Z1-01-01-B
• A1-Z1-01-01-C
• A1-Z1-01-02-A
• A1-Z1-01-02-B
• A1-Z1-01-02-C

The following is an example of a location label, labels have a barcode that is scanned by operators when moving or picking stock from the location.

When a single shelf is partitioned into multiple locations, we can include a {Bin} coordinate into the naming schema: {Zone}-{Aisle}-{Column}-{Level}{Bin}. For instance, if shelf A1-Z1-01-01 contains four distinct bins, they would be identified as:

• A1-Z1-01-01-A1
• A1-Z1-01-01-A2
• A1-Z1-01-01-A3
• A1-Z1-01-01-A4

Modeling in TLP

Now that we have a basic understanding about Pragma-Bolts operations and what locations are and how they are named, let’s deep dive in a practical example in which we model the different warehouse areas.

Organizations

Initially, we modeled each Pragma-Bolts plant as a distinct Organization to ensure data segregation. This structure allows for overlapping naming conventions; for example, both MDC and MILANO organizations can maintain independent locations named A1-Z1-01-01-A without conflict.

The following organizations were created:

• MDC
• MILANO
• ROMA
• VENEZIA

Users assigned to multiple organizations can switch between them using the organization selector in the header.

The following table summarizes warehouses of all four organizations, and how they are structured, next sections will provide more insights about each one of them:

MDC Area A1

The image below illustrates a top view of MDC area A1 which is composed of 8 aisles; each aisle consists of 10 bays on each side; and each bay has 7 levels of shelves; in total area A1 has a capacity of 8 x 20 x 7 = 1120 HUs.

The image below illustrates a front-view of one of the racks in aisle 01, we can observe that shelves A and B are configured as pick-face locations, while shelves C-G are configured as reserve locations, the process is designed as follows:

• Operators pick StockUnits from shelves A and B only.
• When quantities in pick-face locations A and B go below a certain level known as reorder-point WMS generates an automatic task to replenish it by transferring stock from the reserve locations.
• When a reserve location is emptied, WMS generates an automatic task to replenish it by transferring stock from an overstock location (see MDC Area A2).

MDC Area A2

MDC area A2 is configured as an over-stock that replenish area A1 reserve locations, it is composed of 4 identical zones Z1, Z2, Z3, and Z4; each zone is composed of 6 aisles; each aisle has 20 bays; each bay has 10 shelves, total capacity of area A2 is 4 x 6 x 20 x 10 = 4800 pallets.

Shop Area A1

All shops MILANO, ROMA, and VENEZIA have an identical warehouse that is composed of 4 aisles; each aisle consists of 8 bays on each side; each bay has 3 levels of shelves; shelves A and B has 8 plastic bins; in total the warehouse has a capacity of 1088 Locations of which 1024 are plastic bins.

The following is a front-view of one of the racks, note that shelves A and B have 8 plastic bins each, each bin stores bolts of the same SKU.

Creating Areas and Locations

Now that we know how the MDC warehouse is structured, let’s see how those locations can be created, for this we prepared a video, at high level the steps are:

1. Log to the desired organization, for example MDC
2. Create area A1
3. Create locations of area A1
4. Configure location details
5. Print labels
6. Release locations
7. Repeat the same process for area A2 and then for the other organizations.

Summary

In this tutorial we saw how to model warehouse locations using TLP, in the next tutorial we will take a look on the replenishment process.

Today I am thrilled to uncover a new TLP module … introducing our powerful Jobs Engine module! The Jobs Engine is used whenever you need to execute background tasks (we call them jobs).

Jobs come to rescue in many scenarios, here are some:

• Receiving messages from external systems, for example receiving MATMAS IDOCs from SAP.
• Executing long running tasks, for example when exporting grid data to an excel from the UI.
• Executing maintenance tasks, for example every week-end a job to archive records that exceeded their retention period.
• Monitoring a local or FTP directory and process any files placed in it.
• When sending data to external systems, messages are typically created as jobs and dispatched asynchronously. This job-based delivery ensures that if the external system is temporarily unavailable, the data stays safely queued preventing any data loss.

So lets deep dive into the jobs engine module, as usual we will do it with a real case scenario. today we are going to implement a MATMAS channel to receive material master data from SAP and create/update materials in TLP.

Architecture

The Job Engine architecture is flexible, powerful, and super fast, the image below followed by the key-concepts will help you better understand at high level the engine architecture:

• Orchestrator: the orchestrator periodically fetches jobs, organizes them in logical queues and dispatches them to available TLP nodes. At any given time one and only one TLP node can act as the orchestrator, by default any TLP node can act as the orchestrator (see TLP node1), orchestrator election is managed automatically by TLP.
• Executor: the orchestrator dispatches jobs to executors, executors processes them, each TLP node is by default an executor node (see TLP node1, node2, and node3). To increase parallelism each TLP executor node instantiates multiple threads to process jobs in parallel.
• Queue: is a logical grouping of jobs whose execution must be sequential, for example if SAP creates two materials: A and B and soon after updates material A, we will receive three jobs. The two jobs related to material A will form a logical queue Q1 while material B job will form Q2. Processing Q1 jobs the engine must first process the job that created material A and then the job that updated it, if the creation job fails for whatever reason it will block Q1; the 2nd job will not be processed until the 1st is either successfully processed or archived. Q2 jobs can be processed any time even before Q1.
• Job: is a single task, jobs are created by external systems or by the engine itself in case of scheduled jobs.
• Job Type: defines a specific type of job, for example MATMAS is one job type, while BATMAS is another, the Job Type specifies the processor that knows how to process that specific job.

In the above architecture, if node1 goes down for whatever reason (e.g. maintenance) available nodes - in a matter of seconds - will automatically elect a new orchestrator (e.g. node2) and any dispatched queues to node1 will be re-dispatched to available nodes.

MATMAS job

Now it is time to implement logic to receive and process MATMAS IDOCS from SAP, the job type will be named SAP-I-01 and its processor class is very simple.

The following is a simplified example of a MATMAS IDOC generated by SAP, our SAP-I-01 processor will parse such XML and create or update materials in TLP, in our case we are interested only in the following attributes:

• MATNR: Material number
• MTART: Material type, we will use the same type of SAP.
• MEINS: Base unit of measure, we will use the same UM of SAP.
• MAKTX: Default material description

<MATMAS05>
  <IDOC BEGIN="1">
  
    <!-- IDOC header -->
    <EDI_DC40 SEGMENT="1">
    	...
    </EDI_DC40>

    <!-- Mandatory Base Segment -->
    <E1MARAM SEGMENT="1">
      <MSGFN>005</MSGFN>        
      <MATNR>A000123</MATNR>   <!-- Material Number -->
      <ERSDA>20250804</ERSDA>  
      <ERNAM>SMITHJ</ERNAM>    
      <MTART>FERT</MTART>      <!-- Material Type -->
      <MBRSH>01</MBRSH>        
      <MATKL>1010</MATKL>      
      <MEINS>EA</MEINS>        <!-- Base UoM -->
      <COMPL>00</COMPL>        
    </E1MARAM>

    <E1MAKTM SEGMENT="1">
      <MSGFN>005</MSGFN>
      <SPRAS>E</SPRAS>            
      <MAKTX>Standard Widget</MAKTX>	<!-- Material Description -->
    </E1MAKTM>

  </IDOC>
</MATMAS05>

Based on the above, here is the code of our processor the calculateQueue is responsible to calculate the logical queue which in our case is the material number, while the process method will upsert the received material.

public class SapI01MaterialMasterDataProcessor extends BaseJobProcessor {

	@Override
	public String calculateQueue(Job job) throws Exception {
		var doc = parse(job);
		var xpath = XPathFactory.newInstance().newXPath();
		
		return xpath.evaluate("/MATMAS05/E1MARAM/MATNR", doc);
	}

	@Override
	public void process(Job job) throws Exception {

		var doc = parse(job);
		var xpath = XPathFactory.newInstance().newXPath();

		var matnr = xpath.evaluate("/MATMAS05/E1MARAM/MATNR", doc);
		var mtart = xpath.evaluate("/MATMAS05/E1MARAM/MTART", doc);
		var meins = xpath.evaluate("/MATMAS05/E1MARAM/MEINS", doc);
		var maktx = xpath.evaluate("/MATMAS05/E1MAKTM/MAKTX", doc);
	
		// Create material if it doesn't exist
		var material = materialRepo.findByName(matnr);
		if (material == null) {
			var ctx = new CreateMaterialCtx();
			ctx.setNumber(matnr);
			ctx.setVersion("1");

			material = materialService.create(ctx).getMaterial();
		}

		// Update the material
		var ctx = new UpdateMaterialCtx();
		ctx.setMaterial(material);
		ctx.setStockUom(Optional.ofNullable(uomCache.getByName(meins)));
		ctx.setDescription(Optional.ofNullable(maktx));
		ctx.setMaterialType(Optional.ofNullable(mtart));

		materialService.update(ctx);
	}
	
	
}

Testing the job

Its testing time! in this video we explain the architecture of Job ZILLA and simulate receiving multiple MATMAS messages from SAP using a simple python script.

Stress test

In this test we will process 10000 jobs in an attempt to stress the system, for our test we used an old Lenovo ThinkCentre M720q with an Intel(R) Core (TM) i5-8400T CPU @ 1.70 GHz , 6 logical processors, and 16 GB of RAM, the computer runs all TLP nodes and the database.

To better observe what is happening, we conducted the test as follows:

• We paused the Orchestrator, Poller, and Executor this way jobs remain in status created.
• We started the Orchestrator to see how jobs will be dispatched, in a couple of seconds jobs were dispatched to all three nodes.
• Finally we started the Poller and Executor so jobs got processed, overall it took the system 70 seconds to process all 10000 materials.

Resilience

Job ZILLA was crafted on the premise that TLP is a distributed platform, in an event of a node failure for whatever reason one of the following happens:

• If the node is NOT the Orchestrator, then the Orchestrator will re-dispatch all jobs assigned to the failing node to available executor nodes.
• If the node is an Orchestrator, then available nodes will elect a new orchestrator which in turn will re-dispatch all jobs assigned to the failing node.

To see it in action, you can watch this video on our YouTube channel.

Summary

Job ZILLA is an important module in our TLP platform, we use it to manage asynchronous tasks efficiently, it was crafted from scratch taking in consideration:

• That the TLP platform is a distributed system, thus it utilizes all nodes to quickly process jobs.
• Resiliency, maintenance activities or un-expected failures of some application nodes MUST NOT impact jobs processing.
• User friendly management, a simple and intuitive UI to manage jobs and easily see what is happening in the system when needed.
• Years of experience in implementing solutions that require message exchanges between systems.