WP ERP is a three-in-one plugin: CRM contacts and companies live in wp_erp_peoples with relations in wp_erp_peoples_meta, HR data lives in wp_erp_hr_employees, wp_erp_hr_leaves, and related tables, and accounting lives across the wp_erp_acct_* family for invoices, bills, ledger entries, and chart of accounts. The plugin's choice of dedicated tables (rather than custom post types) was specifically designed to scale and keep each module's schema clean.

SleekView reads each module directly. A CRM contacts view joins wp_erp_peoples_meta for typed custom-field columns and wp_erp_peoples type filters for contact-vs-company segmentation. An HR employees view joins wp_erp_hr_leaves to show open leave requests inline. An accounting view over wp_erp_acct_invoices filters by status and due date with the customer pulled from peoples for AR follow-up.

Each module gets a focused workspace with capability gating per role, so HR sees employees and leave without seeing accounting ledgers, and finance sees invoices and bills without exposed CRM contact details. The default WP ERP UI is competent for one record at a time. SleekView covers the cross-record questions ops teams actually ask.

Bundled ERPs that combine CRM, HR, and accounting in one plugin face a hard UX problem: each module wants its own workspace conventions but shares the same admin shell. WP ERP's dedicated tables solve the data side cleanly; the per-module list screens it ships with are competent for one record at a time but cannot give a sales team a stage-and-owner-filtered ranked workspace, an HR lead an employees-with-open-leave view, or a finance lead an AR-by-due-date view from one place. The cross-record and cross-module questions are exactly where the day-to-day operational work lives.

Reading the erp_ tables directly turns each module into the workspace it deserves. Sales gets contacts with custom-field columns and saved owner-and-stage filters. HR gets employees with leave context inline.

Finance gets invoices and bills filterable by aging bucket. Capability gating keeps each role scoped to its own data, and the underlying tables are already indexed for the queries each view runs. The plugin already collected the data; SleekView just lets each role read it the way they actually need to.