Administration
Everything a tenant administrator or BPLO chief configures and governs: who can do what, how the module identifies your LGU and numbers permits, how requirement and fee rules are controlled, what publishes to the public, the API surfaces, the scheduled jobs, the dashboard widgets, the owner portal, and — most importantly — the boundaries of what eBOSS is allowed to do. For first-time setup, do Getting Started first.
Permission matrix
eBOSS ships its own permission group (category eBOSS, with per-office sub-categories), added to Settings → Roles while the module is enabled. Grant permissions by office. The base key Business Licensing (eBOSS) is the master switch — without it, the whole group is hidden. Admins bypass every check, so keep the admin role small.
| Category | Permission key | What it grants |
|---|---|---|
| eBOSS | bplo | Base access — the module-level toggle that reveals the sidebar group and every screen. |
| Registry | bplo_registry (+ _create/_update/_delete) | View and maintain businesses, branches and activities. |
| Registry | bplo_parties (+ _create/_update/_delete) | Maintain owners and representatives. |
| Applications | bplo_applications (+ _create/_update/_delete) | The application inbox and workspace; internal intake and draft editing. |
| Applications | bplo_applications_review | Submit, transition state, and manage deficiencies. |
| Applications | bplo_applications_assign | Assign applications to offices/users. |
| Applications | bplo_applications_hold | Place and release application holds. |
| Applications | bplo_documents_verify | Accept/reject uploaded documents and link them to deficiencies. |
| Governance | bplo_rules_manage | Draft the requirement catalog, rule sets and rules. |
| Governance | bplo_rules_activate | Activate/retire rule sets & checklists — hold this separately from bplo_rules_manage for four-eyes control. |
| Governance | bplo_charter_manage | Manage Citizen's Charter services and publish versions. |
| Clearances | bplo_clearances_review | Approve/reject clearances and set conditions. |
| Clearances | bplo_clearances_manage | Manage clearance types. |
| Inspections | bplo_inspections_schedule | Schedule and dispatch inspections. |
| Inspections | bplo_inspections_perform | Perform inspections, record findings, review corrective actions. |
| Inspections | bplo_inspections_manage | Manage inspection types and checklists. |
| Assessment | bplo_assessments_prepare | Prepare, recompute and submit assessments. |
| Assessment | bplo_assessments_approve | Approve/supersede assessments — the engine enforces approver ≠ preparer. |
| Assessment | bplo_fee_rules_manage | Manage fee rule sets and rules. |
| Payments | bplo_payments_manage | Create payment references and record receipts. |
| Payments | bplo_payments_reconcile | Reconcile, reverse, and post payments to Finance. |
| Issuance | bplo_permits_issue | Gate-check, generate, issue, release and reprint permits. |
| Issuance | bplo_permits_sign | Sign permits (Signatory). |
| Issuance | bplo_permits_revoke | Suspend / reinstate / revoke / supersede permits. |
| Lifecycle | bplo_lifecycle | Start renewal / amendment / retirement cases. |
| Compliance | bplo_compliance | Obligations, violations and notices. |
| Compliance | bplo_compliance_manage | Manage violation codes and issue notices. |
| Reports | bplo_reports | View and export reports and analytics. |
| Portal | bplo_portal_claims | Review owner-portal business claims. |
| Privacy | bplo_sensitive_view | Reveal sensitive/masked registry fields — each reveal is audited (revealed:bplo_sensitive). |
| Administration | bplo_settings | Module settings, LGU profile and numbering. |
bplo_sensitive_view for the few
who genuinely need masked PII.
Module settings & numbering
Open Business Licensing (eBOSS) → Settings (bplo/settings,
bplo_settings). Values are stored per tenant; every save is audited
(updated:bplo_settings). The Settings screen edits the LGU profile, permit
year, application-reference format, and SLA targets; the remaining keys below are read by
the pipeline and set by an administrator.
| Setting key | Purpose |
|---|---|
module_bplo | Master enable flag (toggled in Settings → Manage Modules, not here). |
bplo_lgu_name, bplo_lgu_type, bplo_lgu_province, bplo_lgu_psgc, bplo_lgu_address | LGU profile — the identity that prints on permits and shows in public verification. |
bplo_current_permit_year | The permit/fiscal year new applications default to (falls back to the current year). |
bplo_app_ref_format | Application reference format (default {TYPE}-{YEAR}-{SEQ6}). |
bplo_sla_days_new, bplo_sla_days_renewal, bplo_sla_days_amendment, bplo_sla_days_retirement | Citizen's-Charter processing-time targets (calendar days) per application type. |
bplo_deficiency_response_days, bplo_sla_pause_on_deficiency | Deficiency response window, and whether the SLA clock pauses while a deficiency is open. |
bplo_permit_prefix, bplo_permit_padding | Permit-number prefix (default MP) and zero-padding width (default 6). Numbers are reserved atomically at issuance and never reused. |
bplo_finance_cash_account, bplo_finance_revenue_account_default | Finance GL account numbers used when posting a reconciled payment (defaults 1010 / 4000). |
bplo_verify_show_activity | Whether public verification shows the primary business activity (default on). |
bplo_notify_user_ids | Comma-separated user IDs of the compliance officers who receive the scheduled-job alerts. |
bplo_renewal_reminder_days | How many days before expiry the renewal-reminder job fires (default 30). |
bplo_template_version_mayors_permit | The active permit template version (default v1). |
The Settings screen also includes a read-only number-series viewer so you can audit the current running number for each series.
Rule governance (requirements & fees)
The two rule engines that decide what applies and what it costs are both versioned and both use four-eyes activation — the person who drafts a version is not the person who makes it live.
Managed in Permit Adviser & Rules (bplo/rules).
A draft rule set is built with bplo_rules_manage; a different person
activates or retires it with bplo_rules_activate (activated:bplo_rule_set).
The active set is what the adviser runs.
Managed in Assessment & Billing → Fee Rules. A set runs
DRAFT → ACTIVE → RETIRED; its rules are editable only while it is a DRAFT.
Activation requires the activator to differ from the author and auto-retires any
other active set sharing the same code (activated:bplo_fee_set). A pure
Test Calc lets you preview a fee formula against sample facts without saving.
Citizen's Charter
The Citizen's Charter admin (bplo/charter-admin,
bplo_charter_manage) is where you maintain the published services — the
requirements, fees, processing times and legal basis for each business-permit transaction
under RA 11032 (Ease of Doing Business / ARTA). Publishing a version
(published:bplo_charter_version) makes the public Citizen's Charter page
live at bplo/charter. Both the charter and the public verify page are declared
as public pages, so the CMS "Sync Public Pages" tool can wrap them in your site theme
without changing their content.
API surfaces
eBOSS ships both of ERPat's API stacks, module-owned and documented in the generated OpenAPI specs.
/api/v1/bplo/*Machine-to-machine, OAuth2 client-credential access via the
Bplo_api controller. Reads require the bplo:read scope;
mutations require bplo:write. Endpoints cover the command-center dashboard,
businesses, applications (incl. submit), permits (incl. suspend/revoke), assessments,
obligations, violations, and an executive report.
/v1/api/me/bplo/*Employee self-service via the Bplo_euapi controller.
Read-only and self-only — the signed-in officer's own eBOSS work queue:
me/bplo/assignments and me/bplo/inspections. Each action gates
on the module being enabled plus the base bplo permission.
Scheduled jobs (Advanced Cron)
Four per-tenant jobs run in the ERPat cron runtime. Each self-gates on module_bplo,
is defensive on lagging tenants, is idempotent, and (where it alerts) emails the compliance
officers in bplo_notify_user_ids. Read-only sweeps never mutate permit status —
expiry is a derived, read-time fact.
| Slug | Schedule | What it does |
|---|---|---|
bplo_sla_sweep | Daily 01:15 | Flags active SLA clocks whose target has passed as breached and notifies compliance officers (feeds the Reports SLA-compliance rate). |
bplo_renewal_reminder | Daily 01:30 | Digests permits expiring within the reminder window (bplo_renewal_reminder_days) so owners can be reminded. Read-only. |
bplo_permit_expiry_sweep | Daily 01:45 | Digests issued/released permits already past validity for enforcement follow-up. Read-only — permit status is never changed. |
bplo_compliance_obligation_sweep | Daily 02:00 | Generates annual-renewal obligations from issued permits, flags open obligations overdue, and spawns the next occurrence of completed recurring obligations. |
Dashboard widgets
Three staff dashboard widgets surface the command-centre stats through the core Dashboard. Each is gated by module_bplo plus the base bplo permission, and is on by default:
Active (non-terminal) applications for the current permit year.
Permits whose validity ends within 30 days.
SLA clocks past target (persisted breaches plus not-yet-swept active breaches).
Owner self-service portal & claim approval
A customer-type user linked to a registry party can use the Owner Self-Service
Portal (bplo/portal) to see only the businesses they own or represent —
their applications, permits, bills and profile — and to submit a non-enumerating
"claim a business" request. The scope is a single choke-point (owned businesses +
active representative grants); anything outside it returns a 404, not a 403, so resource
existence is never leaked, and every portal response is masked to public-safe fields.
A BPLO officer reviews those requests in Owner-Portal Claims (bplo/claims,
bplo_portal_claims): approve binds the claimant's party to the business as
an owner (bringing it into their portal scope, approved:bplo_portal_claim);
reject records an internal-only reason. Both are audited.
Multi-tenancy notes
- eBOSS is available on both the main and tenant databases. On a multi-tenant install, run the module migrations for each tenant and enable the module per tenant.
- All data (registry, applications, assessments, permits, settings) is per tenant; nothing crosses tenants.
- The scheduled jobs and the public verify page resolve the tenant per run/request; verify uses the
company_keybaked into each permit's QR to switch to the right tenant, sessionlessly.
Authority boundaries (read this)
eBOSS enforces a process; it does not create legal authority. It does not replace an ordinance, does not certify anyone as compliant, and never issues a document that impersonates a national-agency permit. BFP FSIC/FSEC, DENR ECC/CNC, FDA LTO, and DTI/SEC/CDA registrations are referenced and verified only — the officer records and confirms an external number; eBOSS never generates those documents.
The final fees, forms, authorized signatories, and processing times the module enforces are the ones your LGU's Legal Office, BPLO, Treasurer, and reviewing offices approved and loaded. Confirm your Data Privacy practices before go-live. Configuration is your authority; eBOSS is the discipline around it.