# Troubleshooting & Reference Muhasib ERP outcome-based user guide. # 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](https://docs.muhasiberp.com/link/393) - [Transaction Status and Lifecycle Reference](https://docs.muhasiberp.com/link/396) - [Guide Evidence, Verification, and Known Limitations](https://docs.muhasiberp.com/link/404) ### What to do next
[**Muhasib Navigation and Common Controls Reference**](https://docs.muhasiberp.com/link/393).
# 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](https://docs.muhasiberp.com/link/481) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) - [Resolve a Closed or Invalid Working Period](https://docs.muhasiberp.com/link/581) ### What to do next
[**Set Report Date, Company, Location, Terminal, and Entity Filters**](https://docs.muhasiberp.com/link/481).
# 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](https://docs.muhasiberp.com/link/403) - [Guide Evidence, Verification, and Known Limitations](https://docs.muhasiberp.com/link/404) - [Roles, Permissions, Features, and Limits Reference](https://docs.muhasiberp.com/link/395) ### What to do next
[**Version, Build, Database Revision, and Release Notes Reference**](https://docs.muhasiberp.com/link/403).
# 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](https://docs.muhasiberp.com/link/403) - [Hidden, Deferred, Legacy, and Development-Only Features](https://docs.muhasiberp.com/link/402) - [Data Safety, Privacy, Backup, and External-Effects Reference](https://docs.muhasiberp.com/link/401) ### What to do next
[**Version, Build, Database Revision, and Release Notes Reference**](https://docs.muhasiberp.com/link/403).
# Common Controls and Keyboard Actions Use common screens, keyboard and scanner input, printing, previews, labels, and receipts. # 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 - A hidden control can reflect permission, feature, setting, limit, or record state. - Do not double-click state-changing buttons after delayed responses. ### Related guides - [Navigate the Muhasib Back Office](https://docs.muhasiberp.com/link/568) - [Roles, Permissions, Features, and Limits Reference](https://docs.muhasiberp.com/link/395) - [Recover from an Interrupted Save, Finalize, or Conversion](https://docs.muhasiberp.com/link/586) ### What to do next
[**Navigate the Muhasib Back Office**](https://docs.muhasiberp.com/link/568).
# 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 - Scanner suffixes can trigger unintended Enter actions. - Do not publish shortcut claims until verified on the target POS/form generation. ### Related guides - [Find and Add an Item to a Sale](https://docs.muhasiberp.com/link/526) - [Print Item Labels](https://docs.muhasiberp.com/link/335) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) ### What to do next
[**Find and Add an Item to a Sale**](https://docs.muhasiberp.com/link/526).
# 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 - Correct source data before printing; never edit output as a substitute. - Mark duplicate financial/customer documents according to policy. ### Related guides - [Resolve Muhasib Printing Setup Problems](https://docs.muhasiberp.com/link/173) - [Print, Export, or Email a Report](https://docs.muhasiberp.com/link/484) - [Print Item Labels](https://docs.muhasiberp.com/link/335) ### What to do next
[**Resolve Muhasib Printing Setup Problems**](https://docs.muhasiberp.com/link/173).
# Permissions, Plans, and Restricted Access Understand roles, permissions, subscription features, limits, and restricted actions. # 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 - Granting View does not grant Add/Update/Delete. - Some forms reuse unexpected permission names; check system behavior. ### Related guides - [Resolve a Permission or Subscription Restriction](https://docs.muhasiberp.com/link/578) - [Grant and Revoke Muhasib Permissions](https://docs.muhasiberp.com/link/187) - [Review and Maintain Muhasib Licence Access](https://docs.muhasiberp.com/link/561) ### What to do next
[**Resolve a Permission or Subscription Restriction**](https://docs.muhasiberp.com/link/578).
# 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 - View permission does not imply Add/Update/Delete. - Do not grant administrator access merely to diagnose one missing operation. ### Related guides - [Grant and Revoke Muhasib Permissions](https://docs.muhasiberp.com/link/187) - [Review and Maintain Muhasib Licence Access](https://docs.muhasiberp.com/link/561) - [Roles, Permissions, Features, and Limits Reference](https://docs.muhasiberp.com/link/395) ### What to do next
[**Grant and Revoke Muhasib Permissions**](https://docs.muhasiberp.com/link/187).
# Validation and Dependency Errors Resolve validation, fiscal year, working period, account mapping, and dependent-record 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 - Do not bypass check by entering placeholder data. - If the message is generic, collect safe diagnostics before retrying repeatedly. ### Related guides - [Collect Safe Diagnostic Evidence for Support](https://docs.muhasiberp.com/link/594) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) - [Recover from an Interrupted Save, Finalize, or Conversion](https://docs.muhasiberp.com/link/586) ### What to do next
[**Collect Safe Diagnostic Evidence for Support**](https://docs.muhasiberp.com/link/594).
# 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 - Do not alter dates solely to bypass the error. - Never overlap fiscal years or reopen a closed year without accounting approval. ### Related guides - [Create and Activate a Fiscal Year](https://docs.muhasiberp.com/link/176) - [Resolve a Closed or Invalid Working Period](https://docs.muhasiberp.com/link/581) - [Close a Financial Period Safely](https://docs.muhasiberp.com/link/249) ### What to do next
[**Create and Activate a Fiscal Year**](https://docs.muhasiberp.com/link/176).
# 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 - Do not change workstation date to bypass controls. - Reopening a period can alter finalized reports and requires documented approval. ### Related guides - [Open a POS Register](https://docs.muhasiberp.com/link/523) - [Close and Reconcile a POS Register](https://docs.muhasiberp.com/link/550) - [Resolve a Missing Active Fiscal Year](https://docs.muhasiberp.com/link/580) ### What to do next
[**Open a POS Register**](https://docs.muhasiberp.com/link/523).
# 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 - Do not map everything to suspense merely to bypass check. - Do not edit source-generated journal lines directly. ### Related guides - [Configure Accounting Settings](https://docs.muhasiberp.com/link/230) - [Trace a Source Transaction into the General Ledger](https://docs.muhasiberp.com/link/237) - [Build and Maintain the Chart of Accounts](https://docs.muhasiberp.com/link/231) ### What to do next
[**Configure Accounting Settings**](https://docs.muhasiberp.com/link/230).
# 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 - Do not remove dependents merely to enable deletion. - A gateway, account, or status reported “in use” must be reassigned or retained. ### Related guides - [Correct Data without Deleting History](https://docs.muhasiberp.com/link/596) - [Update or Retire Payment and Tax Masters](https://docs.muhasiberp.com/link/255) - [Retire a Manufacturing Setup Record Safely](https://docs.muhasiberp.com/link/342) ### What to do next
[**Correct Data without Deleting History**](https://docs.muhasiberp.com/link/596).
# 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 - A spinning UI can accompany active database work; do not kill it blindly. - Never treat a smaller diagnostic report as proof the full report completed. ### Related guides - [Recover from an Interrupted Save, Finalize, or Conversion](https://docs.muhasiberp.com/link/586) - [Collect Safe Diagnostic Evidence for Support](https://docs.muhasiberp.com/link/594) - [Understand Back Office Background Operations](https://docs.muhasiberp.com/link/287) ### What to do next
[**Recover from an Interrupted Save, Finalize, or Conversion**](https://docs.muhasiberp.com/link/586).
# 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 - Do not reinstall or clear local offline data before preserving it. - A crash after clicking Save may still have committed the record. ### Related guides - [Recover from a Database or Startup Failure](https://docs.muhasiberp.com/link/579) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) - [Recover from an Interrupted Save, Finalize, or Conversion](https://docs.muhasiberp.com/link/586) ### What to do next
[**Recover from a Database or Startup Failure**](https://docs.muhasiberp.com/link/579).
# 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 - Never use undocumented offsets to conceal errors. - Do not delete a dependent or externally accepted record to force correction. ### Related guides - [Resolve a Referenced or Dependent Record Error](https://docs.muhasiberp.com/link/584) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) - [Transaction Status and Lifecycle Reference](https://docs.muhasiberp.com/link/396) ### What to do next
[**Resolve a Referenced or Dependent Record Error**](https://docs.muhasiberp.com/link/584).
# Database and Startup Recovery Recover from database or startup failures and identify the installed version and revision. # 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 - The available source says 2.0.0 build 12, Development, DB q354; do not call it current production without confirmation. - Older designer text such as v1.3.7 may be replaced dynamically. ### Related guides - [Check the Installed Muhasib Version and Database Revision](https://docs.muhasiberp.com/link/572) - [Hidden, Deferred, Legacy, and Development-Only Features](https://docs.muhasiberp.com/link/402) - [Guide Evidence, Verification, and Known Limitations](https://docs.muhasiberp.com/link/404) ### What to do next
[**Check the Installed Muhasib Version and Database Revision**](https://docs.muhasiberp.com/link/572).
# 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 - Do not create a new empty database merely because the existing one is unreachable. - Never restore over the target without explicit authorization and a pre-restore backup. ### Related guides - [Connect Muhasib ERP to an Existing Database](https://docs.muhasiberp.com/link/554) - [Restore a Database Backup Safely](https://docs.muhasiberp.com/link/284) - [Collect Safe Diagnostic Evidence for Support](https://docs.muhasiberp.com/link/594) ### What to do next
[**Connect Muhasib ERP to an Existing Database**](https://docs.muhasiberp.com/link/554).
# Transaction, Stock, and Financial Corrections Correct transaction, stock, batch, serial, valuation, payment, and ledger problems safely. # 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 Status history, linked documents, stock, party, payment, tax, external, and journal states form one consistent chain.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Save and Finalize are not interchangeable. - Never infer failure from a missing success message alone. ### Related guides - [Correct Data without Deleting History](https://docs.muhasiberp.com/link/596) - [Recover from an Interrupted Save, Finalize, or Conversion](https://docs.muhasiberp.com/link/586) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) ### What to do next
[**Correct Data without Deleting History**](https://docs.muhasiberp.com/link/596).
# 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 - Never add incompatible units without conversion. - Negative stock and backdating can distort valuation. ### Related guides - [Review Stock by Location, Batch, and Serial](https://docs.muhasiberp.com/link/298) - [Review Inventory Movement and Valuation](https://docs.muhasiberp.com/link/301) - [Reconcile the Stock Ledger to Physical Stock](https://docs.muhasiberp.com/link/299) ### What to do next
[**Review Stock by Location, Batch, and Serial**](https://docs.muhasiberp.com/link/298).
# 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 - Never change payment direction by editing labels or one journal side. - Confirm each report's sign convention. ### Related guides - [Trace a Source Transaction into the General Ledger](https://docs.muhasiberp.com/link/237) - [Reconcile a Payment Account Statement](https://docs.muhasiberp.com/link/236) - [Review an Account Ledger](https://docs.muhasiberp.com/link/239) ### What to do next
[**Trace a Source Transaction into the General Ledger**](https://docs.muhasiberp.com/link/237).
# 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 - Do not enable negative stock simply to complete a transaction. - Never reuse or fabricate serial/batch values. ### Related guides - [Review Stock by Location, Batch, and Serial](https://docs.muhasiberp.com/link/298) - [Reconcile the Stock Ledger to Physical Stock](https://docs.muhasiberp.com/link/299) - [Create an Inventory Adjustment](https://docs.muhasiberp.com/link/291) ### What to do next
[**Review Stock by Location, Batch, and Serial**](https://docs.muhasiberp.com/link/298).
# 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 - Never delete one side of an integrated transaction to make counts match. - Use supplier/customer invoice and external IDs as duplicate controls where needed. ### Related guides - [Recover from an Interrupted Save, Finalize, or Conversion](https://docs.muhasiberp.com/link/586) - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) - [Correct Data without Deleting History](https://docs.muhasiberp.com/link/596) ### What to do next
[**Recover from an Interrupted Save, Finalize, or Conversion**](https://docs.muhasiberp.com/link/586).
# Integration and Synchronization Recovery Resolve rounding, message delivery, e-commerce, offline POS, and tax integration problems. # 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 - Do not force agreement with unrelated discounts or charges. - Multi-unit and tax-inclusive comparisons are common sources of apparent differences. ### Related guides - [Change Sale Line Quantity, Price, Discount, Tax, or Location](https://docs.muhasiberp.com/link/528) - [Allocate Purchase Discount, Tax, Cost, and Location](https://docs.muhasiberp.com/link/381) - [Read Report Totals, Signs, Running Balances, and Age Buckets](https://docs.muhasiberp.com/link/482) ### What to do next
[**Change Sale Line Quantity, Price, Discount, Tax, or Location**](https://docs.muhasiberp.com/link/528).
# 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 - “Sent” can mean submitted, not delivered. - Never expose credentials or private message bodies in tickets. ### Related guides - [Review SMS History and Delivery Evidence](https://docs.muhasiberp.com/link/263) - [Configure Email Delivery](https://docs.muhasiberp.com/link/264) - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) ### What to do next
[**Review SMS History and Delivery Evidence**](https://docs.muhasiberp.com/link/263).
# 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 - Avoid overlapping background and manual synchronization. - Do not use the source-visible sale delete action to fix duplicates. ### Related guides - [Synchronize E-Commerce Orders](https://docs.muhasiberp.com/link/268) - [Reconcile E-Commerce Orders and Muhasib Sales](https://docs.muhasiberp.com/link/271) - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) ### What to do next
[**Synchronize E-Commerce Orders**](https://docs.muhasiberp.com/link/268).
# 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 - Closing the sync form stops its form timer. - Never clear/reinstall local offline data before checking. ### Related guides - [Recover from Partial Offline POS Synchronization](https://docs.muhasiberp.com/link/274) - [Monitor Automatic Offline POS Synchronization](https://docs.muhasiberp.com/link/273) - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) ### What to do next
[**Recover from Partial Offline POS Synchronization**](https://docs.muhasiberp.com/link/274).
# 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 - Never retry accepted or unknown submissions blindly. - Never delete stored responses to force submission. ### Related guides - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) - [Review FBR Tax Transactions](https://docs.muhasiberp.com/link/281) - [Prepare Muhasib for Tax Integration](https://docs.muhasiberp.com/link/275) ### What to do next
[**Recover from Tax Submission Failure**](https://docs.muhasiberp.com/link/282).
# Data Safety, Privacy, and Support Information Protect private data, resolve backup problems, and collect safe support evidence. # 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 - Stop when target, scope, environment, or consequence is uncertain. - Rotate credentials immediately if exposed. ### Related guides - [Prepare a Safe Integration Environment](https://docs.muhasiberp.com/link/256) - [Create and Verify a Manual Database Backup](https://docs.muhasiberp.com/link/283) - [Correct Data without Deleting History](https://docs.muhasiberp.com/link/596) ### What to do next
[**Prepare a Safe Integration Environment**](https://docs.muhasiberp.com/link/256).
# 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 - Desktop path access does not prove SQL Server service access. - Never overwrite the only known-good backup. ### Related guides - [Create and Verify a Manual Database Backup](https://docs.muhasiberp.com/link/283) - [Restore a Database Backup Safely](https://docs.muhasiberp.com/link/284) - [Monitor Automatic Backups and Retention](https://docs.muhasiberp.com/link/286) ### What to do next
[**Create and Verify a Manual Database Backup**](https://docs.muhasiberp.com/link/283).
# 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 - Redact rather than blur if image metadata/export could reveal data. - Never paste `.env`, tokens, passwords, or full connection strings. ### Related guides - [Request Muhasib Support](https://docs.muhasiberp.com/link/573) - [Check the Installed Muhasib Version and Database Revision](https://docs.muhasiberp.com/link/572) - [Data Safety, Privacy, Backup, and External-Effects Reference](https://docs.muhasiberp.com/link/401) ### What to do next
[**Request Muhasib Support**](https://docs.muhasiberp.com/link/573).
# Known Issues and Deprecated Workflows Understand interrupted, legacy, hidden, deferred, and development-only 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 - A missing success message does not prove failure. - Do not delete partial records without clear approval and dependency analysis. ### Related guides - [Prevent and Resolve Duplicate Transactions](https://docs.muhasiberp.com/link/585) - [Collect Safe Diagnostic Evidence for Support](https://docs.muhasiberp.com/link/594) - [Correct Data without Deleting History](https://docs.muhasiberp.com/link/596) ### What to do next
[**Prevent and Resolve Duplicate Transactions**](https://docs.muhasiberp.com/link/585).