Store Locator Plus® Internal Docs

Goal: Create a persistent accounting information data store using the built-in WordPress Multisite database surfaces.

The table should follow some standard rules that will allow us to implement CRUD operations via REST endpoints in the MySLP Dashboard plugin.

Tasks

• One time task “Create Or Update The Database” when the MySLP Dashboard version indicates a change.
• Create a Monthly Ledger User Interface to allow for manual CRUD operations on the slp_accounting_monthly_history table.

Monthly History Data : Environment

Environment

All accounting history data will reside in tables for the main WordPress super admin account.

The Main WordPress Super Admin account site ID is stored in the PHP constant SITE_ID_CURRENT_SITE and should be 1.
The database table prefix should come up as wp_ unlike user accounts that start with wp_<user_site_id>.

slp_accounting_monthly_history Table

The table should be named $wpdb->prefix . “slp_accounting_monthly_history” resulting in a table name of wp_slp_accounting_history.

slp_accounting_monthly_history Structure

• ID – a unique ID to allow for explicit record I/O for CRUD operations.
• KEY – a short string indicating the type of monthly data for example:
  • “SAAS_REVENUE”
  • “PLUGIN_REVENUE”
• AMOUNT -an integer representing the numeric value for the key for example:
  • 3500 which may represent “35.00” or 35 dollars in our UI surfaces
• DATE – a date and time for they entry representing the date this value represents NOT when the data was created or modified
• YEAR – the 4-digit year represented by DATE
• MONTH – the 2-digit month represented by DATE
• DAY – the 2-digit day represented by DATE

slp_accounting_monthly_history Example Data

• ID | KEY | AMOUNT | DATE | YEAR | MONTH | DAY
• 1 | SAAS_REVENUE | 299000 | 2026-03-01 00:00:00 | 2026 | 03 | 31
• 2 | SAAS_REVENUE | 302000 | 2026-04-01 00:00:00 | 2026 | 04 | 30
• 3 | SAAS_REVENUE | 303000 | 2026-05-01 00:00:00 | 2026 | 05 | 31

slp_accounting_monthly_history Data Use Case

This Accounting Monthly History Data interface will run various monthly cron jobs to collect data and store it in this table.
We will use this data to product things like monthly revenue graphs for the SaaS Account Overview dashboard.
The graph will show SaaS Revenue from active accounts on a monthly basis.

We will do the same providing a manual process to add other revenue such as WordPress plugin revenue under “PLUGIN_REVENUE” keys.

We will allow for users to change the Line Chart revenue graph to show “monthly” or “yearly” graphs.
Future data keys may warrant daily graphs.

Task: Create Or Update The Database

When the MySLP Dashboard module version (plugin version) changes, run a database “create or update” hook to create the table or modify it as needed.

Copy the design pattern in the Store Locator Plus plugin in the \SLP_Admin_Activation class.
wp-content/plugins/store-locator-plus/include/module/admin/SLP_Admin_Activation.php
This is fired from \SLPlus::initialize_after_plugins_loaded
When the Store Locator Plus version reported is newer than the installed version for the plugin (see version_compare( $this->installed_version, SLPLUS_VERSION, ‘<‘ )) , the MySLP Dashboard should follow that pattern.

Task: Monthly Ledger User Interface

Admin Menu

• Add a submenu with the label “Monthly Ledger” under the “Accounting” admin sidebar menu we created in \MySLP::create_network_admin_menu.

		$this->menu_hooks[ MYSLP_ACCOUNTING_MENU_SLUG ] =
			add_menu_page( __( 'Accounting', 'myslp' ),
				__( 'Accounting', 'myslp' ),
				'manage_network_options',
				MYSLP_ACCOUNTING_MENU_SLUG,
				array( $this, 'render_accounting_page' ),
				SLPlus::menu_icon,
				1.50
			);

Initial User Interface

• Add a new My MySLP_Account_MonthlyLedger PHP React loader and helper class.
  Follow the design pattern of \MySLP_Accounting in wp-content/plugins/myslp-dashboard/include/accounting/MySLP_Accounting.php
  Place it in the same directory as MySLP_Accounting.php as a sibling.
  
• Create a new React component that allows basic CRUD operations on the slp_accounting_monthly_history Table.
  Attach it to the MySLP_Account_MonthlyLedger PHP React loader.
  Follow the UI design pattern of the AccountingPanel React component at wp-content/plugins/myslp-dashboard/src/accounting/accounting.tsx
  Use a MUI X DataGridPro component as the primary table interface.
  Allow for pagination, starting with a default page length of 25 records.
  Sort the records by DATE descending on initial load so we see newer records at the top.
  Provide an add record interface where a user can enter the KEY, AMOUNT, DATE.
  Provide an inline edit record interface on the DataGridPro table to allow users to click on they KEY, AMOUNT, or DATE field on an existing record and change it.
  Provide a delete option for each record.

Data Interface

Use REST for all CRUD operations and to fetch the initial data set.

When records are added the backend data interface should:

• Ensure all keys entered are trimmed (no leading/trailing spaces) and are shifted to uppercase.
• AMOUNT is stored only as an integer.
• DATE field needs to allow for flexible input converting text input into a best guess for the date to be stored as a date-time entry in the database. Examples:
  • “05/2026” is May 2026 which should be recorded as the date time 2026-05-01 00:00:00
  • “05/01/2026” is May 1st 2026 which should be recorded as the date time 2026-05-01 00:00:00
  • “May 2026” is May 2026 which should be recorded as the date time 2026-05-01 00:00:00
  • Allow for various separators such as / or – or .
    • 05-01-2026 is the same as 05/01/2026
    • 05.01.2026 is the same as 05/01/2026
  • Use standard Date/Time JavaScript or React libraries for data manipulation.
  • The manipulation can be not the front-end (React/JavaScript) before communicating with the REST endpoint.
• The backend should do basic sanitation before recording data.

The “Buffer” For Overages

Legacy billing was sometimes strict on the overage policy. The revised automated report, not so much as there is a 100 views “free buffer” on overages.

2026 : Jan | Feb | Mar | April | May

Acct ID	Spreadsheet	New50
BRmarket	0 – 0 – 15 – 0 – 20	0 – 0 – 15 – 0 – ?
MKbevis	0 – 0 – 5 – 0 – 0	0 – 0 – 0 – 5 – 5
TKESeck	0 – 0 – 0 – 5 – 0	0 – 0 – 0 – 0 – 0
Arbor	0 – 0 – 0 – 0 – 35	0 – 0 – 0 – 0 – 35
UWS	0 – 20 – 25 – 45 – 115	15 – 20 – 25 – 45 – 115
Gary	10 – 15 – 20 – 25 – 25	0 – 15 – 20 – 20 – 25

The actual billing and monthly views do not always match.

Part of this is the monthly view total is triggered when the Stripe billing renews.
When a Stripe renewal is successful the SLP SaaS platform records the current view count to a permanent record of views for the previous customer billing period (prior month).
The system is imperfect and need refinement as Stripe sometimes needs to reprocess subscription renewals for a myriad of reasons.
As such the view tally is sometimes recorded more than once and reset more than once.
This impacts the total view count recorded for the month as well as the billing.

Starting in June 2026, we are using the new monthly views report as the source of truth.
This may not be perfect during the period we work to resolve these corner cases with Stripe renewals.
The map views will never be OVER actual usage.
Worst case, we bill a little LESS due to this issue.

Overages remain billed at $5 for a block of 1,000 extra views.
As an unofficial policy while we work toward resolution, all accounts now have a “100 free overage views” allowed on their account.
Thus, if an account is over views we don’t charge for the block until the new block gets 101+ views.
Examples:
limit is 5,000 – actual views is 5099 – billing is 0 extra blocks as 99 is under the 100 grace = $0
limit is 5,000 – actual views is 5250 – billing is 1 extra block at 250 exceeds the 100 grace = $5

limit is 5,000 – actual views is 8099 – billing is 3 extra block as 99 is under the 100 grace = $15

limit is 5,000 – actual views is 8250 – billing is 4 extra blocks = $20
(1 extra block: up to 6,000 views, 2: up to 7,000 views, 3: up to 8,000 views, 4: up to 9,000 views) = $20

As a result, months prior to June 2026 may not align with billing and view count.