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:

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

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

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

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

What to do next

Version, Build, Database Revision, and Release Notes Reference.