---
title: "Usage Guide & Workflow"
space: "NL Piece Rate Pay"
url: "https://docs.navari.co.ke/nl-piece-rate-pay/usage-guide-workflow"
updated: "2026-06-02"
---

## Stage 1: Set up the pricing *(one-time, then occasional)*

1. Create your **Activity Types** ("Loading", "Washing", "Offloading", …) if they don't already exist.
2. For each priced unit of work, create a **Casual Activity Item**: pick the activity, pick the item, and set the **Costing Rate** (the pay per single unit).
  - As a convenience, an Activity Type form carries a **"Casual Item Cost"** button that jumps straight to the filtered list of Casual Activity Items for that activity, so you can review or add pricing in context.
3. If a rate isn't defined for an activity+item pair, the daily payout will refuse to fetch a rate and will tell the operator to go and create the Casual Activity Item first. This is deliberate as it prevents silently paying KSh 0 for unpriced work.

## Stage 2: Capture the day's work and pay *(daily)*

**Prerequisite:** casual workers must have **clocked attendance on their dedicated casual shift** for the day. The app reads attendance because it does not create it.



In a new **Casual Payroll Payout**:

1. Set **Company**, **Shift Type** (the casual shift), and **Attendance Date**.
2. Fill the **Casual Payroll Payout Item** table for each activity done that day, choose the activity and item, and enter the quantity. The system fetches the rate automatically and computes each line's amount. The **Total Quantity** and **Total Amount** (the day's pay pool) update as you go.
3. Click **Get Employees**. The system pulls everyone whose attendance matches the chosen shift + date + company, and lists them in the **Casual Payroll Payout Employee** table and that includes their check-in/check-out times.
4. Click **Calculate Payout**. The day's **Total Amount is divided equally** among the fetched workers, and each worker's share is written to their row.
5. **Submit** the document.

> **Design note — equal split:** the daily payout distributes the *total* day's pool evenly across all present workers (Total Amount ÷ number of workers). It does **not** attribute specific piece-work lines to specific individuals. The model assumes the casual crew works the day's tasks collectively and shares the proceeds equally. If you need per-individual piece pay, that is outside what this tool does today.



## Stage 3: Roll up the period and push to payroll *(weekly)*

In a new **Casual Salary Structure Assignment Tool**:



1. Set the **Attendance Start Date** and **Attendance End Date** for the pay period.
2. Click **Calculate Payout**. The system finds every **submitted, not-yet-processed** Casual Payroll Payout in the range, sums each worker's daily amounts into a single per-worker total, and fills the **Casuals Weekly Amount** table. In the same step, each daily payout it consumes is marked **Payment Processed** so it can't be double-counted.
3. Choose the **Salary Structure** to assign. For the period in which statutory deductions should apply, pick the structure that **includes the NSSF component** so the deduction is taken in that run.
4. **Save and Submit.** On submission the tool creates one **Salary Structure Assignment** per worker, with:
  - **base** = the worker's total for the period,
  - **from date** = the period end date,
  - a back-reference linking the assignment to this roll-up document.

From here the workers are normal payroll subjects: the standard Frappe HR payroll run picks up their assignments and produces payslips with the right deductions.



## The "Payment Processed" lock and how it reverses

This flag is the integrity mechanism that stops the same day's money being paid twice.

- A daily **Casual Payroll Payout** starts **unprocessed**.
- When a period roll-up consumes it (during *Calculate Payout* on the assignment tool), it is flipped to **processed**. Processed payouts are *excluded* from future roll-ups — so re-running, or running an overlapping period, won't double-pay.
- If you **cancel** the period roll-up (the Casual Salary Structure Assignment Tool document), the app walks back through the processed daily payouts in that date range and **un-processes** them, returning them to the pool so a corrected roll-up can pick them up again.



In short: the flag is set when money is committed to a pay run, and released when that pay run is cancelled. Operators generally shouldn't toggle it by hand.