Skip to content

Settings

The Settings screen exposes tenant-level configuration that affects every user of the organisation. It is restricted to owners (owner permission only).

Access

Settings is accessed from the Administration menu, or via the πŸ”§ button in the sidebar. Both the menu item and the button are hidden for non-owners. It opens as a standalone screen (desktop), outside the store tabs.

Settings vs Preferences

Settings holds organisation-wide configuration stored on the server β€” every user sees the same values. Preferences holds personal options (theme, language) saved on the local device. They are deliberately separate.


Screen layout

At present the screen has one card:

  1. Payment Methods β€” manage the list of payment methods used in the AR (customer payments) and AP (supplier payments) tables.

More cards will be added here as further organisation-wide settings are introduced.


Payment Methods

The Payment Methods card lists every payment method that exists on the account, combining two sources:

  • Standard methods β€” a fixed set that is always present even if no records have been entered yet. They appear at the top and cannot be renamed.
  • Custom methods β€” anything else that has appeared on at least one customer or supplier payment record. They are tagged with a small custom badge to make them easy to spot.

Each row shows:

Column Meaning
Method The method name as stored on payment records.
Records How many AR + AP records currently use this method.
(action) A Rename button on each custom method (owners only).

Standard methods (cannot be renamed)

Method Notes
BOLETO Bank slip (Brazilian boleto bancΓ‘rio).
CARTAO Card (credit or debit).
CHEQUE Cheque β€” links to the dedicated cheque tracking flow on AR.
DINHEIRO Cash.
PIX Brazilian instant transfer.
TRANSFERENCIA Bank transfer.

These names are fixed because the application special-cases them elsewhere β€” for example the CHEQUE flow opens an extra cheque section on the payment modal, and PIX, BOLETO and CARTAO reveal a notes field at payment time. Renaming them would silently break those flows, so the rename action is disabled on standard methods.

Custom methods

Anything that doesn't match a standard name is treated as custom β€” for example BOLETO BANCARIO, CARTAO DE CREDITO, CHEQUE TERCEIRO, DEPOSITO, PERMUTA. Custom methods come into existence naturally when a payment is saved with a method name that hasn't been used before on this account; there is no separate "create method" step.


Renaming a custom method

Renaming applies the new name to every AR and AP record that uses the old name (case-insensitive match). The change runs as a single database transaction, so either every affected record is updated or none of them are.

To rename:

  1. Find the custom method row in the table.
  2. Click Rename.
  3. Type the new name and click Save, or click Cancel to abandon the change.
  4. The list refreshes and a confirmation toast appears.

After a rename, the merged result is what you see β€” if you rename CARTAO CREDITO to CARTAO DE CREDITO and a row already existed with that target name, the two will appear as one row with the combined record count.

This is not a reversible undo

The rename is a direct UPDATE of the cltspmts and supspmts tables. To put a name back you have to rename it again.


Merging methods

The Merge Methods section appears below the table when there is at least one custom method to merge.

  • From β€” the source method (only custom methods are listed; standard methods can never be the source).
  • To β€” the target method (any method, custom or standard).
  • Merge β€” applies the change.

Merging is technically the same operation as renaming β€” it runs the same UPDATE ... WHERE UPPER(method) = UPPER(from) statement. The difference is intent: rename is for fixing a typo on a single row in the list, merge is for collapsing two methods that have always meant the same thing (CARTAO, CARTAO DE CREDITO, CARTAO CREDITO β†’ CARTAO).

After a successful merge the source method disappears from the list and its record count is added to the target.


Audit trail

Every rename or merge writes an entry to the audit log with type UPDATE. The entry records:

  • The original name and the new name.
  • How many AR records were updated.
  • How many AP records were updated.
  • The user who performed the action and the timestamp.

Owners can review these entries in the Audit Log screen.


Common tasks

Standardise card-payment naming

If your account has accumulated CARTAO, CARTAO DE CREDITO, CARTAO CREDITO and CARTAO DE DEBITO:

  1. Decide on the canonical names you want to keep β€” for example CARTAO DE CREDITO and CARTAO DE DEBITO.
  2. In Merge Methods, merge CARTAO CREDITO β†’ CARTAO DE CREDITO.
  3. The list refreshes; check the row counts on the surviving rows look right.

Fix a typo

  1. Find the misspelled row.
  2. Click Rename, type the corrected spelling, click Save.

See also

  • Audit Log β€” review who renamed what and when.
  • Customers and Accounts β€” the screens where payment methods are recorded in the first place.
  • Payment Modal β€” the payment-entry widget that uses this list.