Terminology and Data Scope Understand Muhasib terms, dates, references, feature status, evidence, and guide limitations. Muhasib ERP Glossary Muhasib ERP Glossary Overview This guide will help you interpret the core Muhasib terms consistently across setup, transactions, stock, finance, manufacturing, integrations, and reports. Terms can be used consistently when following or reviewing the guide. ℹ️ Note Static reference. Runtime and product-owner confirmation is required for deployment-specific terms. Who can do this You need access to None to read; referenced screens remain permission-controlled. Before you start Use the active company's policies when a business term has a local legal or operational definition. Before saving, check that the correct company is open and that you have permission to complete this task. Where to find it Help Center → Troubleshooting & Reference → Muhasib ERP Glossary. Muhasib ERP Glossary Step 1: Identify the term in the screen/article Step 2: Match it to the relevant domain below Step 3: Follow its linked workflow for operational meaning Step 4: Confirm deployment-specific usage where noted Key terms: Company: An authorized business workspace and reporting scope. Location: A business/stock context used by terminals, inventory, and settings. Terminal: A set up Muhasib workstation/POS identity, normally assigned to a location. Fiscal Year: The accounting date range required by financial transactions. Working Period / Register: Operational POS session/cutoff used for sales and checking. Master: Reusable setup data such as item, customer, supplier, tax, account, or status. Transaction: A dated business record that may affect stock, parties, payments, tax, or accounts. Inquiry: A source-document search/detail screen. Report / Summary / Dashboard: Read-oriented analysis at detail, grouped, or visual level. Ledger: Opening balance plus movements and running/closing balance. WIP: Work in process between manufacturing stages. BOM: Bill of materials defining required components. Finalize: A state-changing confirmation distinct from saving a draft/record. External ID: Provider/source identifier used to compare and confirm integrations and prevent duplicates. Check your work Confirm a term's definition against its source workflow and linked report before making a consequential decision. Take a moment to check your work before closing the window. This small check can save time later. If something goes wrong Runtime labels may contain legacy spellings such as Finilize; the guide uses standard wording. Escalate ambiguous local accounting or statutory terminology. Related guides Muhasib Navigation and Common Controls Reference Transaction Status and Lifecycle Reference Guide Evidence, Verification, and Known Limitations What to do next Muhasib Navigation and Common Controls Reference. Document Numbers, References, Dates, and Cutoffs Reference Document Numbers, References, Dates, and Cutoffs Reference Overview This guide will help you identify transactions uniquely and compare them using the correct document, reference, date, and cutoff fields. Transactions can be traced across modules and reports without conflating different identifiers or dates. Who can do this You need access to Same as the underlying workflow or report. Before you start Distinguish internal ID, transaction number, document number, supplier/customer reference, external ID, invoice/order date, due date, posting date, and synchronization time. Before saving, check that the correct company is open and that you have permission to complete this task. Where to find it Open the source form and its inquiry/report. Document Numbers, References, Dates, and Cutoffs Reference Step 1: Use stable internal/document IDs to locate the exact record Step 2: Use external/provider IDs to prevent integration duplicates Step 3: Treat party-supplied invoice/reference numbers as duplicate controls where applicable Treat party-supplied invoice/reference numbers as duplicate controls where needed. Step 4: Identify which date drives fiscal period, working period, due/ageing, stock, Identify which date drives fiscal period, working period, due/ageing, stock, tax, and report inclusion. Step 5: Record time zone/business-day cutoff for terminal operations Step 6: Preserve all identifiers through corrections/conversions Check your work One source event maps consistently to its inquiry, stock/payment/journal entries, and external result. Take a moment to check your work before closing the window. This small check can save time later. If something goes wrong Transaction date and sync/posting date can differ. Do not change dates merely to force report inclusion. Related guides Set Report Date, Company, Location, Terminal, and Entity Filters Prevent and Resolve Duplicate Transactions Resolve a Closed or Invalid Working Period What to do next Set Report Date, Company, Location, Terminal, and Entity Filters. Hidden, Deferred, Legacy, and Development-Only Features Hidden, Deferred, Legacy, and Development-Only Features Overview This guide will help you recognize source-visible functionality that must not be presented as an active production workflow without further evidence. Unsupported or ambiguous source artifacts are not mistakenly taught as production features. ℹ️ Note Static reference for the available development baseline; product-owner/system classification remains required. Who can do this You need access to None to read; testing hidden/deferred workflows requires an isolated database and explicit authority. Before you start Distinguish compiled source presence, active hub launch, role/feature visibility, reachable system behavior, and product-supported production status. Before saving, check that the correct company is open and that you have permission to complete this task. Where to find it Help Center → Troubleshooting & Reference → this reference; consult the source coverage ledger internally. Hidden, Deferred, Legacy, and Development-Only Features Step 1: Treat a feature as active only when its launch path, Treat a feature as active only when its launch path, permission, subscription/setting gate, and system operation are verified. Step 2: Treat commented-out actions as unavailable Step 3: Treat unreachable forms as hidden/deferred Step 4: Treat legacy duplicate implementations as unresolved until the runtime selector Treat legacy duplicate implementations as unresolved until the system selector is known. Step 5: Label development-only behavior explicitly Step 6: Obtain product-owner confirmation before customer-facing availability claims Known examples requiring caution include Purchase Apply Debit, requisitions, four POS implementations, legacy BackOffice/Quick Launch surfaces, auto item barcode, temporary-sale cheque paths, automated temporary-sale conversion, and unfinished WLM conversion surfaces. Check your work Every listed feature has a coverage-ledger status and evidence before publication. Take a moment to check your work before closing the window. This small check can save time later. If something goes wrong Source class existence is not production support. A hidden control may also reflect permission or subscription rather than deprecation. Related guides Version, Build, Database Revision, and Release Notes Reference Guide Evidence, Verification, and Known Limitations Roles, Permissions, Features, and Limits Reference What to do next Version, Build, Database Revision, and Release Notes Reference. Guide Evidence, Verification, and Known Limitations Guide Evidence, Verification, and Known Limitations Overview This guide will help you understand which guide claims are source-confirmed, system-confirmed, database-confirmed, or awaiting product-owner confirmation. Readers and maintainers can distinguish documented evidence from unresolved behavior. Who can do this You need access to None to read; executing check cases requires the relevant application and environment authority. Before you start Know the target version/build/channel/database revision and whether you are using production, test, or documentation data. Before saving, check that the correct company is open and that you have permission to complete this task. Where to find it Help Center → Troubleshooting & Reference; internal maintainers use docs/source-coverage-ledger.md and phase analysis files. Guide Evidence, Verification, and Known Limitations Step 1: Treat Source-confirmed as behavior established by active code paths Step 2: Treat Runtime-confirmed as observed safely on the target build Step 3: Treat Database-confirmed as reconciled persistence, relationship, or posting evidence Step 4: Treat Product-owner-confirmed as resolved intent/availability/version policy Step 5: Read each draft warning and prerequisite before following it Step 6: Do not use unverified financial, stock, tax, sync, restore, or Do not use unverified financial, stock, tax, sync, restore, or deletion claims in production. Check your work Every published claim maps to evidence in the coverage ledger and unresolved discrepancies remain visible in editorial findings. Take a moment to check your work before closing the window. This small check can save time later. If something goes wrong Related guides Version, Build, Database Revision, and Release Notes Reference Hidden, Deferred, Legacy, and Development-Only Features Data Safety, Privacy, Backup, and External-Effects Reference What to do next Version, Build, Database Revision, and Release Notes Reference.