Settings

This standard governs the Platform's settings: the two stores that look like one, what each holds, who may change each class of value, and what a change causes. Confusing the two stores is the source of half of all "it was changed and nothing happened" reports. The System Administrator owns the settings stores; money, tax, and payment values are changed only with the Accounting Manager's concurrence, under Accounting of this library. Every change made through the administrative settings screens is recorded: who changed what, and when: and that record is where an operator looks first when figures look wrong after a change. A setting never overrides a governing legal document: fees exist only as the Seller Fee Schedule states them, tax is applied as Taxes and the Marketplace Facilitator Tax Policy state it, and no setting changes an obligation stated in §2 of this library.

The two stores

1. The administrative settings store holds the content values every screen in the settings hub reads and writes: business profile, brand, booking rules, processor connection, invoices, portals, social, and system: grouped as general, contact, social, hours, and footer values. Where the store cannot be reached, the screens fall back to the built-in defaults rather than failing. A settings page showing suspiciously clean defaults is therefore reporting that the database connection is down, not that the settings were wiped; the operator checks the connection before touching any setting, under Troubleshooting (Organization Settings Troubleshooting).
2. The runtime settings store holds the key-and-value rows the storefront and scheduled work read directly: pricing, catalog, stock, synchronisation, shipping, telehealth, and breed data. Reads are held briefly in a short-lived copy before refreshing, and a missing or malformed row yields the documented default rather than a failure. A change here takes effect within that refresh interval, not instantly.

Company and currency

The tenant-level facts: legal name, doing-business-as name, tax identifier, support contacts: are set in the business profile under Organization and appear in settings for a different purpose: compliance, not identity. The legal name and tax identifier here shall match the payment processor's records for the Company. Mismatches do not fail quickly; they fail expensively: a year-end tax form under the wrong name, a payout held for verification.

The tenant's default currency, United States dollars, is the currency of record. Changing it on a live business is a migration, not a switch, and is never done as a settings change. See Organization.

Taxes: the displayed rate is derived, not stored

The tax rate shown in the business profile is not stored anywhere. It is a live view of the tax rules, computed on every read, because the register prices from the tax rules and the displayed rate is derived so that no separate copy can drift from them.

Operationally

1. The tax rate is not set in Settings. The operator maintains the tax rules, under Taxes, and the displayed rate follows.
2. Saving a new rate in the business profile rebalances the tenant's tax rules to the new total; it never writes a rate value into the settings store. Where tax totals look wrong, the operator checks the rules, not the settings screen: the screen is a mirror, and the rules are the thing.
3. A companion set of tax definitions carries each tax's name, rate, type, whether it compounds, and whether it is enabled. Rate-change discipline: where a rate changes, the old definition is disabled and a new one created with the new rate and its effective date in its name. Historical invoices keep pointing at the rate actually in effect when they were issued, which is what an examiner wants. Editing a rate in place rewrites history, and rewritten history is what gets questioned.
4. Jurisdiction comes from the location involved in the sale, under Organization, not from a global switch. A pickup at the Memphis store and a shipment to Nashville can carry different treatment. Where tax totals look wrong, the operator checks the location's address data before the tax definitions: the rate is usually right, and the jurisdiction is usually what is off.
5. The whole tax setup is reviewed with the Company's accountant annually. Tax rules change quietly, and the cost of being wrong accumulates with every transaction.

Pricing, shipping, and the runtime keys

The runtime values that shape what customers pay and see include

1. The markup multiplier, which derives retail prices from cost. This is a business-strategy figure wearing a settings costume: changing it reprices the pricing basis for every cost-derived product. Before touching it, the operator establishes whether stored prices recompute or only new ones do. The pricing rule itself is stated in Sales and Purchases.
2. Autoship discounts: the first-order and recurring subscribe-and-save economics.
3. Shipping values: the shipping tiers, the holiday surcharge, and the shipping club's monthly and annual amounts, as data.
4. Stock values: the low-stock threshold (default 5), whether exact counts are shown (default off), and whether backorders are allowed (default off). These shape the urgency a customer sees and whether out-of-stock items remain purchasable.
5. Catalog values: products per page and whether empty categories are hidden. Presentation values, but they interact: hiding empty categories while showing exact stock counts produces a very different browsing experience from either alone.
6. Synchronisation values: whether feed synchronisation is enabled, its interval in minutes, and its rate-limit pause in minutes.

The discipline for all of them: change deliberately, one at a time, know what reads each value before changing it, look at the storefront after each change, and never change two money-related settings at once.

Payments and the processor connection

The processor connection is held as an account reference, a connection state (connected, not connected, or pending), and a mode (live or test) in the settings store, together with the tenant-level connected account reference in Organization.

1. The default mode is test, and the default account reference is a placeholder. An operator who has never completed the connection flow is looking at placeholders, not a live connection; connection is verified in the processor's own console, not only in the settings screen.
2. The two flags that matter day to day are whether charges are enabled and whether payouts are enabled. Charges without payouts means the Company can take money it cannot receive: an unpleasant discovery on payout day. Where onboarding stalls, the operator checks the processor's console for outstanding verification requirements before treating the Platform as at fault.
3. The money arrangement these settings control is stated in Payments (Accounting Payments): connected accounts with destination charges, the platform fee taken at capture, a 7–14 day rolling payout delay, and clawbacks as transfer reversals. The settings are the control surface for that arrangement, not a substitute for understanding it.

Processor credentials are never shared between operators, never recorded in a settings note or any other document, and never read back from a screen to be written down. A credential is verified as configured, never copied.

Financial connections

Connected bank accounts are recorded with a name, the bank, identifiers, the currency, the processor linkage, and the last synchronised time.

1. Accounts are named clearly: an operating checking account named for its bank and purpose, not "Account 1": because the name is what an operator reads during a midnight reconciliation, under Banking.
2. Where the last synchronised time goes stale, the operator re-authenticates the connection; the record is never edited by hand. Editing a bank record by hand is how the Platform and the bank begin to disagree about what the account is, and that is how reconciliation breaks.
3. Access to financial connections is the most restricted in the administrative surface: few enough holders to count on one hand, with every change attributable. Bank fraud does not look like a break-in; it looks like a legitimate-looking change by someone with legitimate-looking access. The grant discipline in Admin Users exists for exactly this: the Accounting module is granted narrowly, and grants are reviewed when anyone with access changes roles or leaves.
4. Adding or replacing an account: add the new one, verify a small test transaction, then remove the old. The only payout destination is never removed while payouts are pending; the failure that follows is not an error message, it is money with nowhere to go.

Controls

• Who may change each class of setting. General, contact, social, and footer values: the System Administrator and the Organization Administrator. Booking values: the Booking Operations Administrator, under Booking Operations. Pricing, shipping, and stock values: the System Administrator with the Accounting Manager's concurrence. Tax values: only through the tax rules, under Taxes. Processor and bank connection values: the System Administrator and the Accounting Manager jointly, and no one else.
• What a change causes. Administrative settings take effect as the screens next read them; runtime settings take effect within their refresh interval. A change to a money value affects new transactions only; it never reprices, retaxes, or re-fees a completed transaction, which is corrected only under Books.
• A setting never overrides a governing legal document. Where a setting value and a document in §2 of this library: a fee schedule, a tax policy, the Selling Terms of Service: differ, the legal document governs and the setting is corrected to match.
• Every change through the administrative settings screens is recorded with its maker and time; an unrecorded change is treated as not having been made through an approved path and is investigated.

Records created and where they are kept

Setting values in both stores, the change record for every administrative change, processor and bank connection records, and test-transaction results are kept in the Platform's settings and administrative records and retained under the Regulatory Record Retention Policy.

Escalation

A change that takes effect wrongly, a money or tax value changed without the concurrence this standard requires, or a bank connection change nobody can account for goes to the System Administrator and the Accounting Manager the same day; suspected fraud goes to legal@aapawz.com. Settings that will not save or that show defaults go first through Troubleshooting (Organization Settings Troubleshooting), then to support@aapawz.com.

Review cadence

Money, tax, pricing, and connection settings are reviewed quarterly against the governing documents they implement. The full settings position is reviewed annually with the Company's accountant for tax values. This standard is reviewed whenever a new settings store, class, or key is introduced.