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

What to do next

Collect Safe Diagnostic Evidence for Support.

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.

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.

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.

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.

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.

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.

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.