The Problem
When I was building VMMS — a voucher management system for government offices — I needed to calculate processing deadlines for each department.
Simple enough, right? Just add X days to the current date.
Wrong.

Government offices don't work on weekends. They don't work on holidays. A voucher submitted on Friday shouldn't have a Monday deadline if Monday is a holiday.
I needed a deadline calculator that was aware of all of this.

The Approach
Instead of hardcoding holidays, I stored them in a database table. This means adding new holidays requires no code changes — just a new database record.

Schema::create('holidays', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->date('date');
    $table->timestamps();
});

Building the DateHelpers Service
I created a dedicated service class to handle all date calculations:

<?php

namespace App\Services;

use Carbon\Carbon;
use App\Models\Holiday;

class DateHelpers
{
    protected array $holidays;

    public function __construct()
    {
        $this->holidays = Holiday::pluck('date')
            ->map(fn(\(d) => Carbon::parse(\)d)->toDateString())
            ->toArray();
    }

    public function isNonWorkingDay(Carbon $date): bool
    {
        return $date->isWeekend()
            || in_array(\(date->toDateString(), \)this->holidays);
    }

    public function addBusinessDays(Carbon \(date, int \)days): Carbon
    {
        \(result = \)date->copy();
        $added = 0;

        while (\(added < \)days) {
            $result->addDay();
            if (!\(this->isNonWorkingDay(\)result)) {
                $added++;
            }
        }

        return $result;
    }
}

How It Works
The addBusinessDays method loops day by day — skipping weekends and holidays — until it has counted the required number of business days.
For example — if today is Friday and you need 3 business days:

Saturday → skip (weekend)
Sunday → skip (weekend)
Monday → count (1)
Tuesday → count (2)
Wednesday → count (3) ← deadline

If Monday is a holiday:

Saturday → skip (weekend)
Sunday → skip (weekend)
Monday → skip (holiday)
Tuesday → count (1)
Wednesday → count (2)
Thursday → count (3) ← deadline

Using It in the Application
php\(dateHelpers = new DateHelpers();
\)deadline = $dateHelpers->addBusinessDays(Carbon::now(), 3);
When a department receives a voucher — the deadline is calculated automatically and stored in the audit trail:

AuditTrail::create([
    'transaction_id' => $transaction->id,
    'processing_offices' => $department->name,
    'process_initiate' => now(),
    'deadline' => $dateHelpers->addBusinessDays(Carbon::now(), 3),
]);

Caching for Performance
Since holidays don't change often — I cached the holidays list to avoid hitting the database on every request:

public function __construct()
{
    $this->holidays = cache()->remember('holidays', now()->addDay(), function () {
        return Holiday::pluck('date')
            ->map(fn(\(d) => Carbon::parse(\)d)->toDateString())
            ->toArray();
    });
}

This caches the holidays list for 24 hours — refreshing automatically every day.

Checking for Overdue Deadlines
With Carbon's diffInDays you can easily check if a deadline has passed:

\(deadline = Carbon::parse(\)auditTrail->deadline)->startOfDay();
\(daysLeft = (int) Carbon::now()->startOfDay()->diffInDays(\)deadline, false);

// Negative = overdue, Positive = days remaining, Zero = due today
if ($daysLeft < 0) {
    // Flag as overdue
}

The false parameter makes diffInDays return negative numbers for past dates — useful for overdue detection.

Managing Holidays
Since holidays are stored in the database — admins can manage them through a simple CRUD interface:

// Add a holiday
Holiday::create([
    'name' => 'Independence Day',
    'date' => '2026-06-12',
]);

// Get all holidays for the year

Holiday::whereYear('date', now()->year)->get();

No code deployments needed when a new holiday is declared — just add it to the database.

What I Learned

Keep business logic out of the database — date calculations belong in PHP, not SQL
Cache holiday lookups — they rarely change but get queried often
Use Carbon consistently — mixing Carbon with raw date strings causes subtle bugs
Test edge cases — Friday submissions, holiday Mondays, and long weekends all need testing

Conclusion
Holiday-aware deadline calculations sound simple but have more edge cases than you'd expect. A dedicated service class with a database-driven holidays table keeps the logic clean, flexible, and easy to maintain.
This pattern works for any system that needs business day calculations — leave requests, SLA tracking, invoice due dates, and more.

Want to see this in action?
I built VMMS — a complete Voucher Management & Monitoring System using everything covered in this article.
🔴 Live demo: https://vmms-app-production.up.railway.app/login
💰 Get the full source code: https://getvmms.gumroad.com/l/zeroqz
Happy to answer any questions in the comments! 🚀

So here it is.

https://www.youtube.com/watch?v=6LBbOwvri3I&t=2s

It's about 3 minutes. Walks through the Admin dashboard, how Staff process and forward requests between departments, and the Client-side pipeline tracker that shows you exactly where your request is in real time.

The pipeline stepper was honestly the part that took the longest — getting the green/active/waiting states to feel right without being annoying. Worth it though.

If you've been following the other posts, this is what all of that code actually looks like in action. And if you're new here — the live demo is open, no signup needed:

https://vmms-app-production.up.railway.app

Feedback always welcome. 🙏

When I was building VMMS — a voucher management system
for government offices — everything worked fine locally.

MySQL. Clean queries. Fast results.

Then I deployed to a server running MariaDB.

Half my charts broke.

The Problem

I had written date queries like this all over the codebase:

// This breaks on MariaDB
DB::table('voucher_transactions')
    ->selectRaw('MONTHNAME(created_at) as month, COUNT(*) as total')
    ->groupByRaw('MONTH(created_at), MONTHNAME(created_at)')
    ->get();

MONTH() and MONTHNAME() are MySQL functions. They work
fine on MySQL but behave differently on MariaDB — especially
when combined with GROUP BY.

The result? Months showing up in the wrong order.
Duplicate entries. Missing data.

Why This Happens

MySQL and MariaDB have diverged over the years. They share
a lot of syntax but handle certain functions differently —
especially around date grouping and ordering.

The safe rule is: if you want your app to work on both,
don't rely on database-specific date functions.

The Fix — Pull the Data and Use Carbon

Instead of doing date calculations in SQL, I pulled the
raw data and used Carbon to handle everything in PHP:

// DB-agnostic approach
\(rows = VoucherTransaction::where('user_id', \)userId)
    ->whereYear('created_at', $year)
    ->whereNull('deleted_at')
    ->get(['created_at', 'status']);

$byMonth = [];
foreach (\(rows as \)row) {
    \(m = (int) \)row->created_at->format('n');
    \(status = strtolower(\)row->status);
    \(byMonth[\)m] = \(byMonth[\)m] ?? ['accomplished' => 0, 'rejected' => 0];
    if (\(status === 'accomplished') \)byMonth[$m]['accomplished']++;
    if (\(status === 'rejected')     \)byMonth[$m]['rejected']++;
}

ksort($byMonth);

Then to get the month name I used Carbon instead of
MONTHNAME():

\(monthName = Carbon::create(\)year, $m, 1)->format('F');
// Returns "January", "February", etc.
// Works the same on MySQL and MariaDB

Building the Full Year Chart

For charts that need all 12 months — even empty ones —
I use range(1, 12) and fill in zeros for months with
no data:

return collect(range(1, 12))->map(function (\(m) use (\)byMonth, $year) {
    \(d = \)byMonth[$m] ?? ['accomplished' => 0, 'rejected' => 0];
    return [
        'month'        => Carbon::create(\(year, \)m, 1)->format('F'),
        'accomplished' => $d['accomplished'],
        'rejected'     => $d['rejected'],
    ];
});

This guarantees all 12 months always appear in the chart
— even if there's no data for some months. Clean and
predictable.

What About Performance?

You might be thinking — isn't pulling all rows and
processing in PHP slower than doing it in SQL?

For most applications — yes, SQL aggregation is faster.

But in practice for this use case:

• The data is filtered by user and year first

• The result set is small (max 365 rows per year per user)

• The PHP processing is negligible

If you're dealing with millions of rows this approach
needs rethinking. But for typical business applications
it's fast enough and the portability is worth it.

Other Carbon Tricks I Use in VMMS

Comparing dates without time:

// Use DATE() in SQL to avoid time comparison issues
->whereRaw('DATE(deadline) >= ?', [$now->toDateString()])
->whereRaw('DATE(deadline) <= ?', [$now->copy()->addDays(7)->toDateString()])

Calculating days left:

\(deadline = Carbon::parse(\)t->deadline)->startOfDay();
\(daysLeft = (int) \)now->copy()->startOfDay()->diffInDays($deadline, false);

The false parameter makes diffInDays return negative
numbers for past dates — useful for overdue detection.

Calculating processing time:

\(minutes = Carbon::parse(\)row->process_initiate)
    ->diffInMinutes(Carbon::parse($row->process_accomplished));

The Lesson

Don't assume your local MySQL behavior will match
production. If your app might run on MariaDB, PostgreSQL,
or any other database — keep your date logic in PHP
with Carbon and use only standard SQL for filtering.

It's a small habit that saves a lot of debugging time.

About VMMS

This and many other lessons came from building VMMS —
a complete voucher management system for government
offices, companies, and educational institutions.

🔴 Live demo: https://vmms-app-production.up.railway.app/login

Available on Gumroad:
👉 https://getvmms.gumroad.com/l/zeroqz

Happy to answer any questions in the comments! 🚀

The Core Concept
Instead of hardcoding approval steps, I built a pipeline where each document has a current stage, and the next stage is determined by a department configuration stored in the database — not in the code.
This means you can add, remove, or reorder departments without touching a single line of PHP.

Database Structure
Here are the key tables:

// vouchers table
Schema::create('vouchers', function (Blueprint $table) {
    $table->id();
    $table->string('title');
    $table->foreignId('current_department_id')->constrained('departments');
    $table->enum('status', ['ongoing', 'accomplished', 'rejected']);
    $table->timestamps();
});

// departments table
Schema::create('departments', function (Blueprint $table) {
    $table->id();
    $table->string('name');
    $table->integer('order'); // determines routing sequence
    $table->timestamps();
});

Routing Logic
When a staff member approves a voucher, it automatically moves to the next department based on the order column:

public function approve(Voucher $voucher)
{
    \(currentOrder = \)voucher->department->order;

    \(nextDepartment = Department::where('order', '>', \)currentOrder)
        ->orderBy('order')
        ->first();

    if ($nextDepartment) {
        $voucher->update([
            'current_department_id' => $nextDepartment->id,
            'status' => 'ongoing'
        ]);
    } else {
        // No more departments — voucher is complete
        $voucher->update(['status' => 'accomplished']);
    }

    // Fire event for email notification
    event(new VoucherAdvanced($voucher));
}

Email Notifications
I used Laravel Events and Listeners to trigger email notifications every time a voucher moves to the next stage:

// VoucherAdvanced Event
class VoucherAdvanced
{
    use Dispatchable, InteractsWithSockets, SerializesModels;

    public function __construct(public Voucher $voucher) {}
}

// Listener
class SendVoucherNotification implements ShouldQueue
{
    public function handle(VoucherAdvanced $event): void
    {
        \(voucher = \)event->voucher;
        \(staff = \)voucher->department->staff;

        foreach (\(staff as \)member) {
            Mail::to(\(member->email)->send(new VoucherNotification(\)voucher));
        }
    }
}

Role-Based Access
Each department only sees vouchers assigned to them using Laravel Policies:

public function view(User \(user, Voucher \)voucher): bool
{
    return \(user->department_id === \)voucher->current_department_id
        || $user->role === 'admin';
}

Real-Time Pipeline Tracker
To show users where a voucher is in real time, I built a simple status tracker on the Vue 3 frontend that reads the current department and renders it as a progress indicator — no websockets needed, just a clean Inertia.js page refresh on action.

What I Learned

Keep routing logic in the database, not the code — it makes the system far more flexible
Laravel Events are perfect for notifications — clean, queueable, and easy to extend
Policies over middleware for row-level access — much cleaner when you have complex role rules

Conclusion
This pattern works for any multi-step approval system — not just vouchers. You could use it for leave requests, purchase orders, or any document that needs to pass through multiple departments.
If you want to see the full system in action, check out the live demo of VMMS: https://vmms-app-production.up.railway.app/login
Happy to answer any questions in the comments!

When I started building VMMS — a voucher management system for government offices — one of the hardest parts wasn't the UI or the database schema.

It was the workflow routing.

A voucher request doesn't just go to one office. It goes to multiple departments in a specific order — each one needs to process it before passing it to the next.

And at any point, a department can:

Complete their step and pass it forward Reject the entire request Flag it for missing documents and pause processing I needed a system that could handle all of that cleanly.

How I Modeled It

Every voucher type has a configurable processing flow stored in a transaction_flows table:

Schema::create('transaction_flows', function (Blueprint \(table) { \)table->id(); \(table->foreignId('voucher_id')->constrained()->cascadeOnDelete(); \)table->string('department'); \(table->integer('order_number'); \)table->timestamps(); }); When a client submits a request, the system reads the flow for that voucher type and routes it to the first department automatically.

Tracking Progress with Audit Trails

Every time a department processes a request, an audit trail record is created:

Schema::create('audit_trails', function (Blueprint \(table) { \)table->id(); \(table->foreignId('transaction_id')->constrained()->cascadeOnDelete(); \)table->string('processing_offices'); \(table->timestamp('process_initiate')->nullable(); \)table->timestamp('process_accomplished')->nullable(); \(table->date('deadline')->nullable(); \)table->timestamps(); }); process_initiate is set when a department starts processing. process_accomplished is set when they finish. If only process_initiate is set — that's the currently active department.

Finding the Current Department

This was trickier than I expected. Here's the logic:

\(activeAudit = \)auditTrails->first( fn(\(a) => \)a->process_initiate && !$a->process_accomplished );

if (\(activeAudit) { return \)activeAudit->processing_offices; }

// If no active audit, find the next step \(doneOrders = \)auditTrails ->filter(fn(\(a) => \)a->process_accomplished) ->map(fn(\(a) => \)flow->firstWhere('department', $a->processing_offices)?->order_number ?? 0);

\(lastDone = \)doneOrders->max() ?? 0; \(nextStep = \)flow->firstWhere('order_number', $lastDone + 1);

return $nextStep?->department ?? 'Completed'; The tricky part was handling edge cases:

What if a department is skipped? What if a request is returned for missing documents? What if the last department just finished? Each of these needed its own handling.

The Pipeline Stepper on the Frontend

On the Vue 3 side, I built a stepper component that shows each department as a step — green for done, pulsing for active, grey for pending.

const stepStatus = (req, step, stepIndex) => { const audits = req.audit_trails ?? []; const accomplishedCount = audits.filter( a => a.process_accomplished !== null ).length;

if (stepIndex < accomplishedCount)  return 'done';
if (stepIndex === accomplishedCount) return 'active';
return 'pending';

}; Simple logic but it took a few rewrites to handle all the edge cases correctly.

Missing Documents — Pausing the Flow

When a staff member flags a request for missing documents, the flow pauses. The client gets notified and needs to upload the corrected files before processing can continue.

I handled this through a separate requirement_validations table that tracks which transactions are waiting for documents from which user.

\(missingDocIds = RequirementValidation::where('receiver_id', \)userId) ->whereNull('resume_transaction') ->pluck('transaction_id') ->toArray(); When resume_transaction is filled — the flow resumes and the request goes back to the staff for continued processing.

What I Learned

1. Model the flow separately from the transaction Keeping transaction_flows separate from voucher_transactions made it easy to change the processing order for a voucher type without affecting existing requests.

2. Audit trails are your best friend Storing every processing event with timestamps made it easy to calculate processing times, track performance, and build analytics on top.

3. Edge cases will get you The "happy path" was easy. Missing documents, skipped departments, and rejected requests all needed separate handling. Budget time for this.

The Result

The pipeline tracker is now one of the most useful features in VMMS. Clients can see exactly where their request is in real time — no more following up in person.

If you want to see it in action:

🔴 Live demo: https://vmms-app-production.up.railway.app/login

VMMS is available on Gumroad if you want to use it or build on top of it: 👉 https://getvmms.gumroad.com/l/zeroqz

Happy to answer any questions in the comments!