Troubleshooting & Reference

Muhasib ERP outcome-based user guide.

Terminology and Data Scope

Understand Muhasib terms, dates, references, feature status, evidence, and guide limitations.

Terminology and Data Scope

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.
Terminology and Data Scope

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.
Terminology and Data Scope

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.
Terminology and Data Scope

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.

Common Controls and Keyboard Actions

Use common screens, keyboard and scanner input, printing, previews, labels, and receipts.

Common Controls and Keyboard Actions

Muhasib Navigation and Common Controls Reference

Muhasib Navigation and Common Controls Reference

Overview

This guide will help you navigate the workspace and use common form, grid, lookup, action, and confirmation controls safely.

You can move through Muhasib without confusing navigation, lookup, save, or state-changing controls.

Who can do this

You need access to Controls appear only when the active role, feature, scope, and record state allow them.

Before you start

Confirm the active company, user, location/terminal, and whether the screen is a master, transaction, inquiry, report, or nested dialog.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Back Office → module tile/button → form; Quick Launch may provide an alternate route.

Muhasib Navigation and Common Controls Reference

Step 1: Read the window title and active company before entry

Step 2: Use New Record/Create to begin and Save to store once

Step 3: Use Select/lookup (... or similar) to choose stable master records

Step 4: Use Add/Edit line actions for nested grids

Step 5: Use Update only after opening the intended record

Step 6: Treat Finalize/Convert/Sync/Submit/Restore as higher-risk state changes

Step 7: Use Inquiry/View Record to verify after every consequential action

Check your work

Window title, selected IDs/names, active company, and stored status all match the intended workflow.

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

Navigate the Muhasib Back Office.
Common Controls and Keyboard Actions

Muhasib Keyboard and Scanner Input Reference

Muhasib Keyboard and Scanner Input Reference

Overview

This guide will help you use keyboard and barcode/scanner input efficiently without entering data into the wrong field or duplicating an action.

Input reaches the intended field and produces one verified selection/action.

Who can do this

You need access to Same as the active form; input devices do not bypass permissions.

Before you start

Confirm keyboard layout, Num Lock, scanner prefix/suffix, barcode symbology, focused control, and test item/customer data.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the intended form and place focus in its documented search/input field.

Muhasib Keyboard and Scanner Input Reference

Step 1: Verify the cursor/focus before typing or scanning

Step 2: Use Tab/Shift+Tab to move through fields; verify runtime behavior before

Use Tab/Shift+Tab to move through fields; check system behavior before relying on Enter/Escape/function keys.

Step 3: Scan one known barcode and confirm the resolved item/quantity

Step 4: For serial/batch input, verify each identity is entered once

Step 5: Avoid repeated Enter/scan while lookup/save is processing

Step 6: Test configured shortcuts in a safe transaction before operational use

Check your work

The shown item/customer/value and resulting line count match the physical input exactly.

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

Find and Add an Item to a Sale.
Common Controls and Keyboard Actions

Resolve Printing, Preview, Label, or Receipt Problems

How to Resolve Printing, Preview, Label, or Receipt Problems in Muhasib ERP

Overview

This guide will help you isolate whether an output problem comes from data, template, permission, printer, paper, driver, or delivery settings.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The problem is isolated and output is reproduced without changing the source transaction.

Who can do this

You need access to Source view plus PrintReports/print/export rights and operating-system printer.

Before you start

Record source document, preview result, template/layout, printer, paper size, copies, workstation, message, and a known-good comparison.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the saved source/report → Preview/Print; check Manage Printers and layout settings as authorized.

Resolve Printing, Preview, Label, or Receipt Problems

Step 1: Confirm source data and document status are correct

Step 2: Open preview and distinguish missing data from layout/driver failure

Step 3: Confirm template, company/location/terminal printer, paper size, orientation, margins, and copies

Step 4: Test a non-sensitive output to PDF or alternate approved printer

Step 5: Check PrintReports permission and Windows printer/driver state

Step 6: Correct configuration and reprint a controlled copy

Check your work

Printed/exported content matches preview and source values, is legible, and is uniquely identified.

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

Resolve Muhasib Printing Setup Problems.

Permissions, Plans, and Restricted Access

Understand roles, permissions, subscription features, limits, and restricted actions.

Permissions, Plans, and Restricted Access

Roles, Permissions, Features, and Limits Reference

Roles, Permissions, Features, and Limits Reference

Overview

This guide will help you explain why an action is available or blocked by evaluating every access-control layer.

An action is available only when all enforced layers allow it.

Who can do this

You need access to Users can read their context; role/licence changes require administration authority.

Before you start

Have user, role, company, location, terminal, exact action, AccessType where known, plan/feature, capacity, licence/lease, and message.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

User Management → Users/Roles and Licence Information.

Roles, Permissions, Features, and Limits Reference

Step 1: Confirm active user and company assignment

Step 2: Check module/form View permission

Step 3: Check exact Add, Update, Delete, Print, or custom operation

Step 4: Check licensed feature/add-on/plan

Step 5: Check user/company/location/terminal/product/customer/supplier limits

Step 6: Check active/Allow Login and restricted/read-only licence state

Step 7: Apply approved least privilege and restart/sign in again if required

Check your work

The user can complete only the approved action and cannot access out-of-scope companies/data.

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

Resolve a Permission or Subscription Restriction.
Permissions, Plans, and Restricted Access

Resolve a Permission or Subscription Restriction

How to Resolve a Permission or Subscription Restriction in Muhasib ERP

Overview

This guide will help you determine whether a missing or blocked action is caused by role rights, subscription features, limits, company assignment, location/terminal scope, or restricted licence mode.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The action becomes available only when every enforced permission, feature, scope, and licence condition is satisfied.

Who can do this

You need access to Users may inspect their context; changes require user-role, subscription, or company administration authority.

Before you start

Record user, company, location, terminal, module/action, message, expected right, plan/feature, capacity, licence state, and recent permission changes.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Back Office → User Management and Licence Information, as authorized.

Resolve a Permission or Subscription Restriction

Step 1: Confirm the correct user and company workspace

Step 2: Check account active/Allow Login/company assignment

Step 3: Check module View and exact Add/Update/Delete/custom operation

Step 4: Check subscription feature and applicable user/company/location/terminal/entity limit

Check subscription feature and needed user/company/location/terminal/entity limit.

Step 5: Check licence lease/restricted mode

Step 6: Apply only the approved least-privilege change

Step 7: Sign out/restart if required and retest

Check your work

The intended user can complete only the approved action in the approved company/scope.

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

Grant and Revoke Muhasib Permissions.

Validation and Dependency Errors

Resolve validation, fiscal year, working period, account mapping, and dependent-record errors.

Validation and Dependency Errors

Read and Respond to a Muhasib Validation Message

Read and Respond to a Muhasib Validation Message

Overview

This guide will help you use a check message to correct the actual prerequisite or field without creating duplicate or compensating records.

The transaction proceeds only after its stated check is satisfied.

Who can do this

You need access to Access to the attempted workflow; some corrections require separate setup authority.

Before you start

Record the full message/title, screen, action, company, transaction/reference, time, and field values without exposing secrets.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Remain on the screen that shown the message and identify the referenced field or prerequisite.

Read and Respond to a Muhasib Validation Message

Step 1: Read both message title and body

Step 2: Classify it as missing input, invalid value, dependency, permission/feature, stock,

Classify it as missing input, invalid value, dependency, permission/feature, stock, period, or system error.

Step 3: Preserve entered data where safe

Step 4: Correct the named field or prerequisite through its proper workflow

Step 5: Recheck the full transaction, not only the flagged field

Step 6: Submit once and verify the stored result

Check your work

The check no longer appears and exactly one correct record is stored with expected downstream effects.

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

Collect Safe Diagnostic Evidence for Support.
Validation and Dependency Errors

Resolve a Missing Active Fiscal Year

How to Resolve a Missing Active Fiscal Year in Muhasib ERP

Overview

This guide will help you establish the correct active fiscal year so an authorized transaction date can be recorded.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

Eligible transactions can reference the active fiscal year.

Who can do this

You need access to Transaction access; fiscal-year creation/update requires Manage Fiscal Year authority.

Before you start

Confirm active company, transaction date, approved fiscal calendar, existing years, closed periods, opening/closing status, and accounting approval.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Back Office → Essentials Setup → Manage Fiscal Year.

Resolve a Missing Active Fiscal Year

Step 1: Exit or preserve the unposted transaction

Step 2: Confirm system date and intended transaction date

Step 3: Review existing fiscal years for gaps, overlaps, inactive status, or

Review existing fiscal years for gaps, overlaps, inactive status, or wrong company.

Step 4: Create or activate only the approved year

Step 5: Confirm start/end dates and period controls

Step 6: Reopen the transaction and verify the displayed fiscal year

Check your work

The form shows the correct date range and a controlled test transaction/report falls into it.

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

Create and Activate a Fiscal Year.
Validation and Dependency Errors

Resolve a Closed or Invalid Working Period

How to Resolve a Closed or Invalid Working Period in Muhasib ERP

Overview

This guide will help you identify the correct business/register/working period and process a transaction without unauthorized backdating or reopening.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The transaction is recorded in the correct open period or routed to an approved adjustment process.

Who can do this

You need access to Transaction access; opening/closing/reopening periods requires specific authority.

Before you start

Confirm company, location, terminal, user, transaction date/time, fiscal year, register, period status, day-end state, and approval.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Back Office → Sales & Customers → Working Period/POS Register, or needed period administration.

Resolve a Closed or Invalid Working Period

Step 1: Stop and record the message and intended transaction time

Step 2: Confirm active company, workstation clock, terminal, and location

Step 3: Identify the relevant fiscal, working, and register periods

Step 4: Check whether the transaction belongs in the current period or

Check whether the transaction belongs in the current period or needs approved correction treatment.

Step 5: Open/reopen only through authorized policy

Step 6: Retest once and verify reporting cutoff

Check your work

Source document, register/day-end, and financial reports include it in the intended period exactly once.

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

Open a POS Register.
Validation and Dependency Errors

Resolve a Missing or Invalid Account Mapping

How to Resolve a Missing or Invalid Account Mapping in Muhasib ERP

Overview

This guide will help you identify the missing or unsuitable account default and restore correct posting without editing generated ledger lines.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

New allowed transactions can post to the intended account; historical reposting is not assumed.

Who can do this

You need access to Source transaction and accounting-settings view; mapping changes require accounting administration authority.

Before you start

Record transaction, message, company, item/party/tax/payment master, expected debit/credit accounts, current settings, period, and approval.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Back Office → Muhasib Financials → Accounting Settings, Chart of Accounts, and affected master.

Resolve a Missing or Invalid Account Mapping

Step 1: Identify the posting component that lacks an account

Step 2: Trace the mapping precedence from company settings to item/category/tax/payment/expense master

Step 3: Confirm the target account exists, is active, posting-enabled, and correct

Confirm the target account exists, is active, posting-enabled, and correct type.

Step 4: Apply the approved mapping

Step 5: Test one representative transaction in a clone

Step 6: Reconcile generated journal and source record

Check your work

The test transaction generates a balanced journal in the approved accounts and reports compare and confirm.

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

Configure Accounting Settings.
Validation and Dependency Errors

Resolve a Referenced or Dependent Record Error

How to Resolve a Referenced or Dependent Record Error in Muhasib ERP

Overview

This guide will help you identify which record depends on the target and choose safe retirement, reassignment, reversal, or retention.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

Future use stops safely while transaction history remains interpretable.

Who can do this

You need access to View access to target and dependents; changes require each workflow's authority and explicit removal approval for deletion.

Before you start

Record target stable ID/name, message, active/historical references, replacement, business impact, and approval.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the target maintenance form and related inquiries/reports.

Resolve a Referenced or Dependent Record Error

Step 1: Confirm the exact target record

Step 2: Inventory active and historical dependencies

Step 3: Reassign only open/future records where valid

Step 4: Set inactive/retired when supported

Step 5: Preserve historical references

Step 6: Delete only when proven unused and separately approved

Check your work

New selectors exclude the retired record and historical documents/reports remain intact.

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

Correct Data without Deleting History.
Validation and Dependency Errors

Diagnose Slow, Frozen, or Unresponsive Muhasib Screens

Diagnose Slow, Frozen, or Unresponsive Muhasib Screens

Overview

This guide will help you distinguish active work from a failed/frozen operation and collect evidence without causing duplicate writes.

The operation completes, is proven failed, or is safely stopped with duplicate-prevention evidence.

Who can do this

You need access to Normal workflow access; system/log/performance diagnostics require administration authority.

Before you start

Record screen/action, start time, data/filter size, company, workstation, network/SQL status, background operations, CPU/memory/disk symptoms, and message.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Remain on the affected screen; use authorized Windows, SQL, network, notification, and log diagnostics.

Diagnose Slow, Frozen, or Unresponsive Muhasib Screens

Step 1: Stop repeated clicks and wait for observable progress within local

Stop repeated clicks and wait for observable progress within local policy.

Step 2: Check whether the window/process is responding and whether SQL/network/background activity

Check whether the window/process is responding and whether SQL/network/background activity continues.

Step 3: For reports, reduce scope only to diagnose, not to declare full success

Step 4: For writes, query inquiry/history from another safe session only if

For writes, query inquiry/history from another safe session only if authorized.

Step 5: Preserve logs/timestamps before ending the process

Step 6: Restart only after classifying the operation outcome

Check your work

Application responsiveness returns and the requested write/report result is verified at its full intended scope.

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

Recover from an Interrupted Save, Finalize, or Conversion.
Validation and Dependency Errors

Recover Safely after Application or Workstation Failure

Recover Safely after Application or Workstation Failure

Overview

This guide will help you restore safe access after a crash, power loss, forced restart, or workstation failure and compare and confirm in-progress work.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

Application access is restored with in-progress outcomes classified and duplicates avoided.

Who can do this

You need access to Normal login/inquiry access; database, backup, or settings recovery requires administration authority.

Before you start

Record failure time, user, company, terminal, open forms/actions, pending offline data, background jobs, external requests, and last known backups.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Restart workstation/application only after basic safety checks; then use relevant inquiries/status screens.

Recover Safely after Application or Workstation Failure

Step 1: Preserve workstation/local offline data and logs

Step 2: Confirm hardware, power, network, SQL Server, and storage stability

Step 3: Relaunch Muhasib and confirm database/company identity

Step 4: Search every in-progress transaction before re-entry

Step 5: Reconcile external submissions, offline sync, backup, and background operations

Step 6: Resume only confirmed incomplete work

Check your work

Source transactions, stock, parties, payments, tax/external states, and journals compare and confirm to the failure cutoff.

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

Recover from a Database or Startup Failure.
Validation and Dependency Errors

Correct Data without Deleting History

Correct Data without Deleting History

Overview

This guide will help you correct master or transaction data using the safest auditable method available.

The corrected state is achieved with the original and correction relationship retained.

Who can do this

You need access to View and record-specific update/reversal authority; deletion requires separate clear approval.

Before you start

Identify original stable ID, error, downstream dependencies, correct result, period/status, physical/external effects, evidence, and approver.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the original record through its inquiry/history and use supported Update, Cancel, Reverse, Inactive, or replacement workflow.

Correct Data without Deleting History

Step 1: Preserve original evidence and full dependency chain

Step 2: Update only non-substantive fields where safe

Step 3: Set unused masters inactive/retired instead of deleting

Step 4: Reverse/cancel posted economic events and create one correct replacement

Step 5: Correct external accepted records using provider/statutory procedure

Step 6: Reconcile all downstream stock, party, payment, tax, and ledger effects

Check your work

History shows who changed what and all source/subledger/ledger/external controls compare and confirm.

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

Resolve a Referenced or Dependent Record Error.

Database and Startup Recovery

Recover from database or startup failures and identify the installed version and revision.

Database and Startup Recovery

Version, Build, Database Revision, and Release Notes Reference

Version, Build, Database Revision, and Release Notes Reference

Overview

This guide will help you identify the exact Muhasib application/database baseline and choose documentation or release notes that apply to it.

Support and documentation decisions are tied to a concrete application/database version.

ℹ️ Note
Static reference. The available baseline is not confirmed as the current production release.

Who can do this

You need access to About/version viewing is generally available; upgrade/migration access requires administration authority.

Before you start

Have workstation, executable/source identity, shown version/build/channel, database revision, company/database, installation date, and recent upgrade history.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Back Office → About/Version and Help Center → Release Notes & Updates.

Version, Build, Database Revision, and Release Notes Reference

Step 1: Record runtime product version, build, and channel

Step 2: Record database revision without exposing connection credentials

Step 3: Compare with applicable release notes and guide baseline

Compare with needed release notes and guide baseline.

Step 4: Distinguish designer placeholder labels from runtime-populated labels

Step 5: Before upgrade, verify backup, migration path, compatibility, and rollback plan

Step 6: Revalidate affected guide articles after change

Check your work

Version/build/channel/revision agree across About, diagnostics, source/release evidence, and the selected guide baseline.

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

Check the Installed Muhasib Version and Database Revision.
Database and Startup Recovery

Recover from a Database or Startup Failure

Recover from a Database or Startup Failure

Overview

This guide will help you identify the startup stage that failed and restore safe application access without risking the database.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

Startup resumes at the correct stage or the issue is isolated without uncontrolled database changes.

Who can do this

You need access to Application launch is general; connection, SQL Server, migration, restore, and settings changes require administration authority.

Before you start

Record stage, full sanitized message, time, version/build, server/database identity, last successful launch, recent changes, service/network state, free space, and verified backup.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Launch Muhasib and use Database Setup/Connection Manager only after identifying the failure stage.

Recover from a Database or Startup Failure

Step 1: Stop repeated launch attempts if migration or write activity is possible

Step 2: Confirm executable/version and workstation clock/resources

Step 3: Check SQL Server service, network, server name, authentication, and database

Check SQL Server service, network, server name, authentication, and database availability without printing credentials.

Step 4: Confirm configuration points to the intended database

Step 5: Preserve logs and create/verify a backup before migration or repair

Step 6: Reproduce on an isolated copy where possible

Step 7: Escalate with sanitized evidence if integrity is uncertain

Check your work

Muhasib reaches login/company workspace and representative read-only reports show expected data/version.

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

Connect Muhasib ERP to an Existing Database.

Transaction, Stock, and Financial Corrections

Correct transaction, stock, batch, serial, valuation, payment, and ledger problems safely.

Transaction, Stock, and Financial Corrections

Transaction Status and Lifecycle Reference

Transaction Status and Lifecycle Reference

Overview

This guide will help you choose the correct action for a record based on whether it is new, saved, approved, finalized, converted, settled, closed, cancelled, reversed, or otherwise completed.

You select a valid next action without repeating a completed transition or editing around dependencies.

Who can do this

You need access to View access to status/history; transitions require workflow-specific authority.

Before you start

Identify the source record, current status, downstream records, physical/external effects, period, and intended business outcome.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the record through its Inquiry/history and inspect status plus linked documents.

Transaction Status and Lifecycle Reference

Step 1: New/unsaved: no durable record is assumed

Step 2: Saved/draft/open/initiated: a record exists but may not have final stock/account/external

Saved/draft/open/initiated: a record exists but may not have final stock/account/external effects.

Step 3: Approved/finalized/posted: consequential effects may exist and correction must preserve them

Step 4: Converted/fulfilled/settled/closed: inspect the linked target/payment/receipt/close record

Step 5: Cancelled/reversed: preserve original and reversal; exclude only according to report

Cancelled/reversed: preserve original and reversal; exclude only according to report rules.

Step 6: Rejected/failed/unknown: classify local and external outcomes before retry

Check your work

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

Correct Data without Deleting History.
Transaction, Stock, and Financial Corrections

Stock, Batch, Serial, Location, and Valuation Reference

Stock, Batch, Serial, Location, and Valuation Reference

Overview

This guide will help you distinguish stock identities, quantity states, movement directions, and value concepts across Muhasib.

Stock questions are answered at the correct identity, state, and valuation basis.

ℹ️ Note
Static reference. Availability and costing methods require system/database verification.

Who can do this

You need access to Relevant stock/report access; cost visibility may be separate.

Before you start

Know item/variant, base unit, location, batch, serial, expiry, cutoff, cost method, and whether the question concerns physical, on-hand, reserved, in-transit, available, forecast, or WIP stock.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Items & Advanced Inventory → Stock, Detailed Stock, Batch, Movement, or Stock Ledger reports.

Stock, Batch, Serial, Location, and Valuation Reference

Step 1: Identify exact stock identity and unit

Step 2: Select company/location and cutoff

Step 3: Separate on-hand, reserved, in-transit, available, forecast, and WIP quantities

Step 4: Trace movement source and direction

Step 5: Confirm batch/serial/expiry integrity

Step 6: Reconcile quantity and value using the configured costing method

Check your work

Detailed identities sum to Stock Report and movements roll into Stock Ledger closing quantity/value.

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

Review Stock by Location, Batch, and Serial.
Transaction, Stock, and Financial Corrections

Debit, Credit, Payment Direction, and Ledger Reference

Debit, Credit, Payment Direction, and Ledger Reference

Overview

This guide will help you interpret debit/credit and money direction correctly across source transactions, payment accounts, party ledgers, and the general ledger.

You can distinguish receipt/payment direction from debit/credit presentation and avoid reversed entries.

Who can do this

You need access to Relevant transaction/report access; posting changes require accounting authority.

Before you start

Know the business event, account types, party role, whether money is received or paid, and set up mappings.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open source transaction, Payment Account Statement, party ledger, Journal Ledger, and Account Ledger.

Debit, Credit, Payment Direction, and Ledger Reference

Step 1: Describe the business event without accounting labels

Step 2: Identify assets, liabilities, equity, income, expenses, party balances, and payment

Identify assets, liabilities, equity, income, expenses, party balances, and payment accounts affected.

Step 3: Confirm money direction separately from debit/credit wording

Step 4: Trace the source-generated journal

Step 5: Recalculate ledger running balances using their displayed convention

Step 6: Reconcile subledger and general-ledger controls

Check your work

Generated journals balance and source, party, payment-account, and general-ledger totals agree.

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

Trace a Source Transaction into the General Ledger.
Transaction, Stock, and Financial Corrections

Resolve Insufficient, Negative, Batch, or Serial Stock Errors

How to Resolve Insufficient, Negative, Batch, or Serial Stock Errors in Muhasib ERP

Overview

This guide will help you correct a stock-availability or identity problem without inventing quantity or bypassing record history.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The source stock position becomes accurate enough for the intended transaction or the shortage remains a valid control.

Who can do this

You need access to Source transaction and stock inquiry access; master/adjustment changes require separate authority.

Before you start

Record item, unit, requested quantity, location, batch, serial, date, available/on-hand result, pending movements, and message.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open Stock Report, Detailed Stock, Item Batch, and Stock Ledger for the item.

Resolve Insufficient, Negative, Batch, or Serial Stock Errors

Step 1: Confirm exact item/variant/unit and conversion

Step 2: Confirm company, location, batch, serial, and cutoff

Step 3: Reconcile on-hand, reserved, in-transit, and available values

Step 4: Find missing/unposted/backdated source movements

Step 5: Select correct stock identity or complete the valid source transaction

Step 6: Use an approved adjustment only for a verified physical difference

Check your work

Physical stock, stock ledger, identity details, and available quantity agree before retrying once.

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

Review Stock by Location, Batch, and Serial.
Transaction, Stock, and Financial Corrections

Prevent and Resolve Duplicate Transactions

Prevent and Resolve Duplicate Transactions

Overview

This guide will help you prevent duplicate entry and compare and confirm suspected duplicates without deleting audit history.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

One valid business event remains with an auditable correction chain for any duplicate.

Who can do this

You need access to Source inquiry access; correction/reversal requires transaction-specific authority.

Before you start

Have source reference, party, amount, date/time, external ID, terminal/user, response/log, and expected record count.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the relevant module inquiry and linked external/history reports.

Prevent and Resolve Duplicate Transactions

Step 1: Search by stable document/external/reference ID before entry or retry

Step 2: After timeout, treat outcome as unknown rather than failed

Step 3: Compare suspected records across party, lines, amounts, times, user/terminal, and

Compare suspected records across party, lines, amounts, times, user/terminal, and links.

Step 4: Identify the valid original and downstream effects

Step 5: Reverse/correct the duplicate through approved workflow

Step 6: Preserve external and local evidence

Check your work

Source, stock, party, payment, tax, external-provider, and journal controls include the event once.

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

Recover from an Interrupted Save, Finalize, or Conversion.

Integration and Synchronization Recovery

Resolve rounding, message delivery, e-commerce, offline POS, and tax integration problems.

Integration and Synchronization Recovery

Quantity, Unit, Price, Discount, Tax, and Rounding Reference

Quantity, Unit, Price, Discount, Tax, and Rounding Reference

Overview

This guide will help you review transaction calculations consistently and identify whether a difference comes from units, pricing, discounts, taxes, or rounding.

Numeric differences have an identifiable calculation source.

Who can do this

You need access to Underlying transaction/report access; override rights are separate.

Before you start

Know base/transaction unit, conversion, quantity precision, price level, currency, discount order, tax inclusivity/rate/base, and company decimal places.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open the relevant transaction lines and corresponding detail report.

Quantity, Unit, Price, Discount, Tax, and Rounding Reference

Step 1: Convert quantity to the verified base or comparison unit

Step 2: Confirm selected price/cost source and unit

Step 3: Apply line and header discounts in the verified order

Step 4: Determine tax-inclusive versus tax-exclusive calculation

Step 5: Apply additional charges/withholding as configured

Apply more charges/withholding as set up.

Step 6: Round at the actual line/document stage using company decimal places

Step 7: Compare line sum with document/report totals

Check your work

Representative lines and document totals reproduce independently within the verified rounding rule.

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

Change Sale Line Quantity, Price, Discount, Tax, or Location.
Integration and Synchronization Recovery

Resolve SMS or Email Delivery Problems

How to Resolve SMS or Email Delivery Problems in Muhasib ERP

Overview

This guide will help you determine whether a message failed check, gateway/SMTP submission, provider acceptance, or final delivery and retry safely.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The send has a known outcome or is escalated without duplicate messaging.

Who can do this

You need access to Relevant send, settings, inquiry, and diagnostic.

Before you start

Have recipient, sanitized content, timestamp, company/location/terminal, gateway/server, local result, provider/message ID, and consent.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open SMS Inquiry or email/provider evidence plus the needed settings.

Resolve SMS or Email Delivery Problems

Step 1: Validate recipient address/number and consent

Step 2: For SMS, confirm gateway is assigned to the terminal's location

For SMS, confirm gateway is assigned to the terminal's location and restart occurred.

Step 3: Check URL/method/parameters or SMTP host/port/TLS/authentication

Step 4: Determine whether provider accepted the request

Step 5: Check provider delivery/bounce status separately

Step 6: Retry only a confirmed failed recipient once

Check your work

One local send maps to at most one accepted provider message and intended recipient evidence.

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

Review SMS History and Delivery Evidence.
Integration and Synchronization Recovery

Resolve E-Commerce Synchronization Problems

How to Resolve E-Commerce Synchronization Problems in Muhasib ERP

Overview

This guide will help you resolve missing, rejected, duplicated, or state-mismatched Shopify/WooCommerce orders without losing either system's evidence.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The order is retrieved/converted once, intentionally excluded, or escalated with complete evidence.

Who can do this

You need access to E-Commerce Orders, integration settings/inquiry, and relevant POS/master permissions.

Before you start

Have provider/store, external ID, status, timestamps, cursor/window, local record/sale, sanitized error, mappings, and last successful run.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

E-Commerce Orders, integration settings/logs, Sale Inquiry, and provider admin/API evidence.

Resolve E-Commerce Synchronization Problems

Step 1: Confirm intended company/store/environment

Step 2: Check credentials, endpoint/API version/scopes, network, and provider availability

Step 3: Confirm order status/window/paging eligibility

Step 4: Search Muhasib by external ID before retrieval or conversion retry

Step 5: Correct customer/item/tax/shipping/payment mappings for rejected orders

Step 6: Reconcile provider and Muhasib states; retry only confirmed failures

Check your work

Each allowed external ID maps to one intended local order/sale and all totals/statuses compare and confirm.

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

Synchronize E-Commerce Orders.
Integration and Synchronization Recovery

Resolve Offline POS Synchronization Problems

How to Resolve Offline POS Synchronization Problems in Muhasib ERP

Overview

This guide will help you recover failed or partial offline POS synchronization while protecting successful records and local pending data.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

Pending data is reconciled without intentionally duplicating previously uploaded records.

Who can do this

You need access to Offline sync plus relevant central inquiry/correction rights.

Before you start

Preserve local data/logs and record central database/company, pending counts/references by family, last run, successes, errors, and connectivity.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Sync Offline POS Data plus central Sale, return/credit, Quotation, and Temporary Sale inquiries.

Resolve Offline POS Synchronization Problems

Step 1: Stop automatic retry while classifying outcomes

Step 2: Confirm central server/database/company and stable connectivity

Step 3: Match each offline reference to central records by family

Step 4: Exclude confirmed successes

Step 5: Correct master, stock, period, permission, or validation errors

Step 6: Retry one confirmed failure and reconcile before the rest

Check your work

Original pending population equals central successes plus remaining/documented failures for each family.

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

Recover from Partial Offline POS Synchronization.
Integration and Synchronization Recovery

Resolve Tax Integration Problems

How to Resolve Tax Integration Problems in Muhasib ERP

Overview

This guide will help you classify and resolve a tax-integration check, transport, rejection, unknown, or local/provider mismatch safely.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

One local transaction reaches one known authority state or is escalated with evidence.

Who can do this

You need access to Tax integration inquiry/retry, source-sale correction, and responsible tax approval.

Before you start

Preserve local transaction, request/reference, response code/message, timestamps, sanitized payload evidence, provider query result, tax values, and ledger state.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open source sale, tax/FBR report/history, settings, and authorized authority query/retry tools.

Resolve Tax Integration Problems

Step 1: Confirm company, registration, connector, environment, and endpoint

Step 2: Classify local validation, authentication/network, rejected, accepted-not-stored, or unknown outcome

Step 3: Query provider status by original reference

Step 4: Correct rejected seller/buyer/item/unit/scenario/tax mappings at source

Step 5: Retry only confirmed unaccepted eligible records once

Retry only confirmed unaccepted allowed records once.

Step 6: Use official correction/cancellation/credit rules for accepted wrong invoices

Check your work

Local/provider identifiers, statuses, lines, taxable values, taxes, totals, and ledgers compare and confirm.

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

Recover from Tax Submission Failure.

Data Safety, Privacy, and Support Information

Protect private data, resolve backup problems, and collect safe support evidence.

Data Safety, Privacy, and Support Information

Data Safety, Privacy, Backup, and External-Effects Reference

Data Safety, Privacy, Backup, and External-Effects Reference

Overview

This guide will help you classify a Muhasib action by data risk and apply the required safeguard before proceeding.

The action is performed with proportionate safeguards and recoverable evidence.

ℹ️ Note
Static reference. Deployment policies and legal requirements must be applied.

Who can do this

You need access to Reading is general; every consequential action requires its specific role and business authority.

Before you start

Identify affected records/people/systems, reversibility, external effect, financial/stock/legal consequence, backup, test environment, approval, and audit evidence.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Use the relevant source workflow and its inquiry/report verification path.

Data Safety, Privacy, Backup, and External-Effects Reference

Step 1: Prefer read-only inspection first

Step 2: Verify exact company, target IDs, scope, and environment

Step 3: Back up and test on an isolated database for high-risk/bulk changes

Step 4: Protect credentials and minimize personal/commercial data in output

Step 5: Submit external actions once and retain IDs/responses

Step 6: Correct through update/reversal/inactive workflows rather than deletion

Step 7: Verify downstream effects

Check your work

Only intended records/systems changed, backups/evidence exist, and all source/subledger/external results compare and confirm.

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

Prepare a Safe Integration Environment.
Data Safety, Privacy, and Support Information

Resolve Backup or Restore Problems

How to Resolve Backup or Restore Problems in Muhasib ERP

Overview

This guide will help you diagnose backup/restore failures without overwriting the wrong database or losing the last valid recovery point.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

Backup creation or isolated restore succeeds, or the failure is safely bounded.

Who can do this

You need access to Backup/Restore, SQL Server, filesystem, and target-database authority.

Before you start

Record target server/database, file/path, SQL service identity, disk space, error, version/revision, last good backup, active connections, and rollback plan.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Backup and Restore, automatic-backup settings/folder, SQL Server status, and authorized logs.

Resolve Backup or Restore Problems

Step 1: Stop repeated restore/backup attempts

Step 2: Confirm exact source file and target identity

Step 3: Check SQL Server service, backup/restore rights, server-visible path access, disk

Check SQL Server service, backup/restore rights, server-visible path access, disk space, file integrity, and active connections.

Step 4: Preserve the target with a verified backup before restore

Step 5: Reproduce/restore into an isolated database first

Step 6: Escalate version or corruption errors with sanitized evidence

Check your work

File metadata is plausible and isolated restore passes database/application control checks.

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

Create and Verify a Manual Database Backup.
Data Safety, Privacy, and Support Information

Collect Safe Diagnostic Evidence for Support

Collect Safe Diagnostic Evidence for Support

Overview

This guide will help you create a useful support package that reproduces the issue without exposing credentials or unnecessary private data.

Support receives reproducible, scoped evidence while sensitive information remains protected.

Who can do this

You need access to Access to affected workflow and authorized logs; exporting business data requires separate approval.

Before you start

Know issue owner, data-classification rules, secure transfer channel, and the minimum evidence needed.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

About/Version, Request Support, affected inquiry/report, notifications, and authorized log locations.

Collect Safe Diagnostic Evidence for Support

Step 1: Record expected versus actual outcome and exact reproduction steps

Step 2: Record version, build, channel, database revision, company, user role, terminal/location,

Record version, build, channel, database revision, company, user role, terminal/location, time, and screen.

Step 3: Capture full error text and stable document/reference IDs

Step 4: Preserve relevant sanitized logs, responses, and screenshots

Step 5: Remove passwords, tokens, connection strings, personal data, and unrelated records

Step 6: Send through the approved support channel and retain case ID

Check your work

Another authorized person can reproduce or locate the issue using the package without requesting secrets.

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

Request Muhasib Support.

Known Issues and Deprecated Workflows

Understand interrupted, legacy, hidden, deferred, and development-only workflows.

Known Issues and Deprecated Workflows

Recover from an Interrupted Save, Finalize, or Conversion

Recover from an Interrupted Save, Finalize, or Conversion

Overview

This guide will help you determine the result of an interrupted action before safely resuming or correcting it.

If this issue is stopping your work, do not worry. Follow the steps one at a time, and check the result before trying again.

The action is verified, safely resumed, or corrected without intentional duplication.

Who can do this

You need access to Source inquiry/status access and transaction-specific correction authority.

Before you start

Record action, source ID, expected target ID, time, user, terminal, company, message, external response, and pre-action state.

Before saving, check that the correct company is open and that you have permission to complete this task.

Where to find it

Open source and target inquiries plus notifications/logs.

Recover from an Interrupted Save, Finalize, or Conversion

Step 1: Stop repeated clicks or retries

Step 2: Search source and expected target by stable identifiers

Step 3: Check source status and downstream stock/payment/journal/external records

Step 4: Classify outcome as complete, not started, partial, or unknown

Step 5: Resume only through a supported action for confirmed incomplete work

Step 6: Escalate partial/unknown states with evidence

Check your work

Exactly one valid final state and one consistent downstream transaction chain exist.

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

Prevent and Resolve Duplicate Transactions.