Problem; Allow derivatives from existing global providers but extend with custom processing rules

If you just copy all of RGS 3.5, 3.7 etc into every companys gl_accounts youll quickly get:

• thousands of rows per company (RGS has 4k accounts depending on version)

• and for 1000 companies, thats 4 million rows, most of which they’ll never use

• it makes upgrades messy (if you clone accounts and later need to apply version changes)

question for our prestined register accountant, RA S. Capaz

Option A — Keep Templates Global, Link Companies

Instead of duplicating, store accounts once in gl_account_templates and link companies only to the accounts they actually use

Option B — Hybrid

• Keep gl_account_templates global

• Copy only the subset of accounts actually needed into gl_accounts per company

• Use rules or defaults to decide which subset to instantiate (e.g. “only Assets + Liabilities + Revenue accounts initially”)

Option C — Views Instead of Duplication

• Store all RGS accounts globally in gl_account_templates

Build a company-specific view that filters by company’s chosen provider/version:

*view= a view in this definition is like a pre-filtered table but still derived from the larger underlying table
so if i make a View of Sayits audit_logs out of the massive audit_log table
I would theoretically get an audit_log table but ONLY the ones that belong to Sayits user_id

Problem is they all rot with different baggage issues;

If you want companies to use accounts as is from RGS → Option C (views) is leanest

If you want companies to customize their CoA slightly (rename, deactivate some accounts) → Option A (link table) is best

If you want complete independence per company, even if bloated → Option B (subset copy)