Daily Operations

Using eBOSS

Daily Operations

The click-by-click procedures your BPLO offices run every day. Each section follows one business permit down the pipeline — from a receiving officer opening an application to a released, publicly verifiable permit — plus the after-issuance work: renewals, amendments, retirements, and compliance. Every action here is recorded to the audit trail and gated by the permission for that office (see Administration → Permissions).

1 · Intake — register the business & open an application

Everything starts from one authoritative record. The business, its branch/location, and its activities are entered once in the Business Registry and reused by every application and reviewing office — never re-keyed.

1. Find or create the business

   Open Business Registry (bplo/businesses). Search first — if the business already exists, reuse it. Otherwise add the business, then add a branch/location and its activities (line of business).

2. Link the owner & any representative

   In Owners & Representatives (bplo/parties), add the owner and link them to the business as an owner. Record an authorized representative (with a grant that can be verified and later revoked) when someone transacts on the owner's behalf.

3. Create the application

   Open Applications (bplo/applications) → new application for that business/branch. The application begins in DRAFT and picks up a reference number in your configured format.

2 · Run the Permit Adviser

The Permit Adviser is what makes the requirement list right and explainable. Instead of a fixed national checklist, eBOSS runs your LGU's versioned requirement rules against the business facts (activity, size, risk, location) and materialises the exact requirements that apply, with the reason each one was raised.

1. Answer the adviser

   On the application, run the adviser. It reads the currently active requirement rule set (managed in Permit Adviser & Rules) and produces the application's requirement list. This is logged as decision_created:bplo_requirement.

2. Review what was decided

   Each requirement shows whether it is blocking or informational, and why it applies. An officer with the right permission may waive a requirement (recorded as waived:bplo_requirement) — waivers are audited.

3. Submit the application

   When the applicant has what they need, move the application from DRAFT to SUBMITTED. BPLO then does a preliminary assessment of completeness.

3 · Verify documents & issue one consolidated deficiency

Reviewing offices should never send an applicant back three times for three different gaps. eBOSS collects the shortfalls into one consolidated deficiency notice.

1. Verify each uploaded document

   On the application's Requirements tab, review each uploaded file and mark it accepted (verified:bplo_document) or rejected with a reason (rejected:bplo_document). Document verification is gated by bplo_documents_verify.

2. Issue a deficiency if something is missing

   From the Deficiencies tab, issue a deficiency listing everything outstanding at once (issued:bplo_deficiency). The application moves to DEFICIENCY; if configured, the SLA clock pauses while the ball is in the applicant's court.

3. Resolve & return to review

   The applicant responds (responded:bplo_deficiency); the officer confirms it and resolves the deficiency (resolved:bplo_deficiency), returning the application to preliminary assessment / validated.

4 · Drive parallel inter-office clearances

Once VALIDATED, the application enters parallel clearance review: each reviewing office (Barangay, Zoning, Sanitary/Health, Environment, Fire liaison, Building/Occupancy) works its clearance at the same time, each with its own owner and state — nothing waits in a single queue.

• Each clearance runs its own lifecycle: REQUIRED → READY_FOR_REVIEW → UNDER_REVIEW → APPROVED, or a rejection with reason. Approvals/rejections are gated by bplo_clearances_review.
• A clearance may route through inspection (INSPECTION_TO_SCHEDULE …) and come back COMPLIANT / CONDITIONALLY COMPLIANT before it can be approved.
• The full clearance state map is on Reference → State lifecycles.

5 · Schedule & perform risk-based inspections

Where a clearance needs an on-site check, an inspector runs it from Clearances & Inspections (bplo/inspections) against a versioned checklist.

1. Schedule

   Dispatch the inspection (scheduled:bplo_inspection, permission bplo_inspections_schedule). It runs REQUESTED → SCHEDULED → IN_PROGRESS → COMPLETED (or NO_ACCESS/CANCELLED).

2. Perform & record findings

   The inspector completes the checklist and records any findings (issued:bplo_finding) and the result. Performing inspections is gated by bplo_inspections_perform.

3. Corrective action & re-inspection

   For a finding, the business submits a corrective action (submitted:bplo_corrective_action); the office reviews it (reviewed:bplo_corrective_action) and, if needed, re-inspects. A FAILED inspection blocks issuance until cleared.

When every clearance is resolved, the application reaches CLEARANCES_READY and is ready to assess.

6 · Prepare & approve the assessment (one bill)

The Assessment & Billing hub (bplo/assessments) consolidates every local tax and fee into one bill. Money math runs through a pure fee calculator against your active fee rule set; the result is a versioned assessment.

1. Prepare

   From the Assessment Queue, prepare an assessment for an eligible application (Clearances Ready or later). It is created as DRAFT and can be recomputed while still draft. Preparing is gated by bplo_assessments_prepare.

2. Submit for approval

   Send the draft for approval (FOR_APPROVAL).

3. Approve — four-eyes

   A different officer with bplo_assessments_approve approves it. The engine enforces approver ≠ preparer and, above a configured threshold, requires a second approval. Approval freezes the assessment (APPROVED, approved:bplo_assessment), creates the billing link, and advances the application to AWAITING_PAYMENT.

7 · Reconcile payment & post to Finance

Payment lives in the Payments & Reconciliation tab of the assessment hub. In v1 the owner pays at the treasury/cashier and staff record the reference — there is no online payment gateway yet (see Known limitations).

1. Create a payment reference

   Against the open bill, create a payment reference for the expected amount and channel (INITIATED). Managing references is gated by bplo_payments_manage.

2. Record the receipt

   When the owner pays, record the official receipt reference and received amount (RECEIVED, received:bplo_payment).

3. Reconcile → post to Finance → settle the bill

   An officer with bplo_payments_reconcile reconciles it (RECONCILED). This posts a summarized journal entry to the ERPat Finance General Ledger — one cash debit and revenue credits allocated per assessment-line accounting code — and settles the bill. When fully covered, the application advances to PAID.

8 · Gate-check, generate, sign, issue & release the permit

The Issuance hub (bplo/issuance) is the controlled release point. A permit can only be produced when every mandatory gate passes — the gate is re-checked on the server at generation time, so a stale queue can never sneak a permit out.

The issuance gate

The gate lists every unmet condition before you can generate. It blocks on:

1. Gate check

   In the Issuance Queue, open the Gate Check for the application. A green "Ready" chip means clear; a red chip lists the blockers.

2. Generate

   When clear, Generate the permit. eBOSS reserves a race-safe permit number (never reused), inserts a GENERATING permit, and renders the QR-bearing PDF. A failed render voids the permit — the consumed number is never recycled. Requires bplo_permits_issue.

3. Sign

   The authorized Signatory (bplo_permits_sign) signs it (SIGNED). v1 records an authorized e-sign approval; the PNPKI digital-signature seam is left for a later release (see Known limitations).

4. Issue

   Issue the signed permit (ISSUED, issued:bplo_permit) — this stamps the validity window (default: to Dec 31 of the permit year).

5. Release

   Record the release channel and recipient (RELEASED, released:bplo_permit). The owner now holds a verifiable permit.

9 · Verify a permit in public

Every issued permit carries a QR code that resolves to a public verification page (bplo/verify). Anyone — a customer, a bank, another agency — can confirm a permit without logging in.

• Scan the QR, or paste the printed permit number into the verification form.
• The page returns a derived, revocation-aware status: Valid, Suspended, Revoked, Superseded, or Expired — never a single trusted flag.
• It shows only public, PII-free facts: LGU, permit number, business (trade) name, barangay + city, primary activity, issue/validity dates, and a short document fingerprint. It never exposes owner identity, TIN, balances, deficiencies, findings, or internal notes.

10 · Manage a permit's status after issuance

From the Permit Registry, an officer with bplo_permits_revoke can act on a live permit — always with a reason and an authority reference, always audited:

11 · Renewals, amendments & retirements

The lifecycle cases reuse the same spine as a new application and are started from the application's Lifecycle tab (permission bplo_lifecycle):

12 · Post-issuance compliance

The Compliance hub (bplo/compliance) tracks obligations, violations, and notices after a permit is live (permission bplo_compliance, and bplo_compliance_manage to manage violation codes / issue notices):

• Obligations — recurring duties (e.g. annual renewal) that the compliance sweep generates from issued permits, flags overdue, and rolls forward on completion.
• Violations — recorded against a violation-code catalog; resolved when fixed, or escalated to a permit action (e.g. suspension) for serious cases.
• Notices — issued to the business (issued:bplo_notice) and acknowledged when received.

---