Application Manual

Use this guide to operate records, inventory, purchases, sales, financial routines, and pricing intelligence in an integrated way.

This online manual is part of the application and is structured to be translated later into all supported languages.

Record Operations (Create, Edit, Delete, Notes)

Context

Apply the same quality standard across all entities such as customers, suppliers, products, inputs, orders, sales, purchases, payables, and receivables.

Procedure

Operational quality is achieved when records are treated as system contracts, not only as form submissions. Every update should preserve traceability, ownership, and consistency between commercial, financial, and stock modules.

  • Create records from each module list using New/Create actions and complete required fields first.
  • Edit records from details pages and keep business-critical fields synchronized with operational reality.
  • Delete records only when there is no historical dependency; otherwise use status deactivation.
  • Use Notes/Observation fields for contextual business information not covered by predefined fields.
  • When a related entity is missing during a transaction, use quick-create flow and return to the original form. Category forms automatically use the signed-in company context, so there is no company selector.

Validation

  • Confirm that at least one create, one edit, and one deactivation flow are completed for each operationally critical entity before go-live decisions.
  • Review related modules after updates (sales, purchases, receivables, payables, stock) to ensure references and totals remain coherent.

Common Failures

  • Treating deletion as the default cleanup action and removing records that already have transaction history.
  • Updating master data without checking downstream effects in financial or stock modules, causing hidden integration drift.

Conclusion: record governance is the base layer for reliable KPIs, auditable financial closure, and predictable automations.

Customer Status Actions (Deactivate vs Delete)

In Customers, action buttons have different effects.

Status handling should reflect business continuity. Deactivation preserves legal and operational context, while physical deletion should be a rare cleanup operation for records with no transaction footprint.

  • Deactivate changes status from ACTIVE to INACTIVE. The record stays in the database and can be reactivated later.
  • Delete attempts physical deletion only when the customer has no linked sales or receivables.
  • If linked sales/receivables exist, delete falls back to logical deactivation (status INACTIVE) to preserve history and financial traceability.
  • Use deactivation for temporary suspension and use deletion only for records with no operational history.

Conclusion: prefer reversible status changes for operational safety and reserve deletion for strictly orphan records.

New User Quick Start (Recommended Sequence)

Follow this order to reduce setup errors and ensure full cross-module integration from day one.

The sequence is intentionally staged: first define company and control rules, then complete foundational records, and only after that execute transactional flows. This order minimizes rework and prevents inconsistent postings.

  1. Complete Setup with company identity, jurisdiction, and base operational settings.
  2. Configure tax and accounting defaults used by purchases, sales, and pricing routines.
  3. Register master data foundations: categories, brands, units, payment terms, and carriers.
  4. Register Suppliers and Customers with complete business and address data. In customer forms, use a single fiscal document field whose label adapts by country/person type (for example CPF, CNPJ, VAT ID, or Tax ID), do not use tenant company as a customer attribute, require responsible/contact name when the customer type is Company, and always choose Country from the predefined country selector (never free-typed text). In quick-add flows (new and edit screens for Sales, Quotes, Orders, Purchases, Payables, Receivables, Planner Tasks, Bank Movements, and Cash Movements), prefer masked fields (tax ID, phone, postal code), and use postal code lookup to auto-fill street, neighborhood/district, city, and state/province when available for the selected country.
  5. Register Inputs and Products, including costs, prices, stock minimums, and Notes. Product, customer, and service maintenance forms support quick-select relations (category, brand, supplier, salesperson) with direct links to full registration pages when deeper setup is required.
  6. Post opening stock or first Purchases to establish real inventory baseline. Purchase item lines support quick-select product typing, and purchase receipt supports quick-select bank account assignment for payable settlement routing.
  7. If manufacturing applies, execute first Production posting to consume inputs and increase finished goods stock. Output and input product fields support quick-select typing with direct links to full product registration when additional setup is needed.
  8. Create first Order and first Sale to validate commercial and stock flow. In quote, order, and sale item lines, use quick-select typing for products and open the full product form when catalog setup is still incomplete.
  9. Review generated Payables, Receivables, Bank Movements, Accounting Control (CSV export), Accounting Journal (CSV export), Trial Balance (CSV export), General Ledger (CSV export), and pricing reports to confirm end-to-end integration. Payables and receivables maintenance support quick-select classification for category and settlement account without leaving the screen, and bank movement import supports quick-select account and category routing. Date and time display in operational list screens should follow user locale (or browser locale fallback) instead of hardcoded country formats.

Conclusion: complete this onboarding cycle before scaling users or automations to guarantee that reports and controls start from clean baseline data.