# Integrations & Automation Muhasib ERP outcome-based user guide. # Integration Safety and Credentials Prepare credentials, test external connections safely, retry failures, and protect business data. # Prepare a Safe Integration Environment ### How to Prepare a Safe Integration Environment in Muhasib ERP ### Overview This guide will help you prepare a non-production environment where integrations can be tested without sending live messages, filings, orders, or data. Integration behavior can be measured without affecting production counterparties or statutory systems. ### Who can do this You need access to Authorized integration/settings administration and access to a disposable documentation database. ### Before you start Get sandbox accounts, synthetic data, approved endpoints, a database snapshot, network controls, and a credential-handling procedure.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → Administration/Essentials and the relevant module settings. ### Prepare a Safe Integration Environment #### Step 1: Clone or seed a non-production database #### Step 2: Replace customer, supplier, phone, email, and tax identities with test Replace customer, supplier, phone, email, and tax identities with test data. #### Step 3: Configure sandbox or blocked endpoints and test credentials #### Step 4: Disable unattended schedules until configuration is reviewed #### Step 5: Record baseline counts, balances, and settings without exposing secrets #### Step 6: Run one controlled test and preserve request ID, response, and Run one controlled test and preserve request ID, response, and local result. ### Check your work Confirm no production endpoint/recipient is reachable and the environment can be restored to its baseline.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Stop testing if any production identifier or endpoint appears. - Rotate any credential accidentally exposed in logs or screenshots. ### Related guides - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) - [Create and Verify a Manual Database Backup](https://docs.muhasiberp.com/link/283) ### What to do next
[**Diagnose an External Integration Failure**](https://docs.muhasiberp.com/link/257).
# Diagnose an External Integration Failure ### Diagnose an External Integration Failure ### Overview This guide will help you identify whether an integration failed before submission, in transit, at the provider, or during local persistence. The incident has a failure stage and a safe next action rather than an uncontrolled retry. ### Who can do this You need access to Relevant transaction/inquiry access and authorized diagnostic/log. ### Before you start Have timestamp, company, terminal, user, local document number, external ID, action, sanitized error, and connectivity status.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Open the failed workflow, its inquiry/history, notifications, and authorized logs. ### Diagnose an External Integration Failure #### Step 1: Confirm the intended company, environment, and endpoint #### Step 2: Check local validation and permission failures #### Step 3: Check connection, DNS/TLS, authentication, and provider availability #### Step 4: Determine whether a request was submitted and capture its external ID #### Step 5: Check provider acceptance/status separately from transport success #### Step 6: Verify whether Muhasib stored or posted the local result #### Step 7: Classify the failure before any retry ### Check your work Evidence identifies one local record, zero or one provider request, its status, and any mismatch requiring checking.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Never paste secrets or full private payloads into tickets. - Treat timeouts as unknown outcomes until provider/local history is checked. ### Related guides - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) - [Request Muhasib Support](https://docs.muhasiberp.com/link/573) - [Understand Back Office Background Operations](https://docs.muhasiberp.com/link/287) ### What to do next
[**Retry a Partially Successful Integration Safely**](https://docs.muhasiberp.com/link/258).
# Retry a Partially Successful Integration Safely ### Retry a Partially Successful Integration Safely ### Overview This guide will help you retry only failed integration records while protecting successful records from duplication. Failed records are recovered without intentionally duplicating accepted transactions. ### Who can do this You need access to Relevant execute/retry permission plus inquiry/history. ### Before you start Classify each record as successful, rejected, failed before submission, unknown, or locally inconsistent; keep all IDs and responses.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Open the integration's inquiry, synchronization result, or failed-record list. ### Retry a Partially Successful Integration Safely #### Step 1: Freeze the original batch evidence #### Step 2: Exclude confirmed-success records #### Step 3: Query unknown outcomes by external ID before resubmission #### Step 4: Correct deterministic validation or mapping failures #### Step 5: Retry one failed record first #### Step 6: Reconcile provider and Muhasib state #### Step 7: Process remaining eligible failures once Process remaining allowed failures once. ### Check your work Every source record maps to no more than one accepted external/local result and the control count/value reconciles.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Stop on duplicate-key or already-processed responses. - Escalate local/provider state disagreement instead of deleting either side. ### Related guides - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) - [Recover from Partial Offline POS Synchronization](https://docs.muhasiberp.com/link/274) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) ### What to do next
[**Diagnose an External Integration Failure**](https://docs.muhasiberp.com/link/257).
# Send a Message to Multiple Recipients ### How to Send a Message to Multiple Recipients in Muhasib ERP ### Overview This guide will help you send an approved message to multiple valid recipients and record individual failures. Muhasib attempts recipients individually and reports invalid or failed numbers before its overall completion message. ### Who can do this You need access to SendSMS and access to a location with an assigned gateway. ### Before you start Confirm consent, recipient list, number format, message content, provider balance/limits, location gateway, 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 → Send SMS. ### Send a Message to Multiple Recipients #### Step 1: Confirm the active terminal location and gateway #### Step 2: Enter or select recipients #### Step 3: Validate each number and remove duplicates #### Step 4: Enter and review the approved message #### Step 5: Send once #### Step 6: Record every number-specific validation or provider failure #### Step 7: Do not resend successful recipients when correcting failures ### Check your work Compare and Confirm intended recipients to successful, failed, and invalid results, then check SMS Inquiry/provider evidence.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Do not interpret “All Messages Sent” as proof every handset received a message. - Retry only recipients whose outcome is confirmed failed. ### Related guides - [Review SMS History and Delivery Evidence](https://docs.muhasiberp.com/link/263) - [Send a Transaction SMS](https://docs.muhasiberp.com/link/549) - [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).
# Prepare Muhasib for Tax Integration ### How to Prepare Muhasib for Tax Integration in Muhasib ERP ### Overview This guide will help you prepare company, terminal, customer, item, tax, invoice, and connectivity data for an approved tax integration. The environment is ready for connector-specific testing without assuming legal compliance from settings alone. ### Who can do this You need access to Tax integration/settings administration, tax master access, sales access, and responsible tax approval. ### Before you start Confirm jurisdiction, registration identifiers, branch/terminal IDs, scenario, credentials, sandbox URL, invoice numbering, item/service classification, rates, units, buyer rules, and response-retention policy.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → Administration/Settings and Muhasib Financials → Manage Tax. ### Prepare Muhasib for Tax Integration #### Step 1: Obtain current official specifications and sandbox access #### Step 2: Validate company/branch/terminal registrations #### Step 3: Map customer and item tax identities, classifications, units, rates, and Map customer and item tax identities, classifications, units, rates, and exemptions. #### Step 4: Configure sandbox endpoint and credentials securely #### Step 5: Disable live submission and unattended retry during setup #### Step 6: Submit representative sandbox cases and retain sanitized requests/responses #### Step 7: Obtain tax-owner approval before production activation ### Check your work Each required scenario validates in the sandbox and maps to the intended Muhasib transaction/tax accounts.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Stop when authority documentation and software fields disagree. - Never expose tokens, credentials, or taxpayer personal data. ### Related guides - [Configure and Test FBR POS Integration](https://docs.muhasiberp.com/link/276) - [Configure and Test FBR Digital Invoicing](https://docs.muhasiberp.com/link/277) - [Review Tax Transactions and Summaries](https://docs.muhasiberp.com/link/246) ### What to do next
[**Configure and Test FBR POS Integration**](https://docs.muhasiberp.com/link/276).
# Submit and Verify a Tax-Integrated Sale ### Submit and Verify a Tax-Integrated Sale ### Overview This guide will help you submit one allowed sale once and prove whether it was accepted, rejected, or remains unknown. The sale has both a local state and a provider state that may temporarily disagree. ### Who can do this You need access to POS Sale add plus needed tax-integration permission and master. ### Before you start Confirm environment, connector, seller/buyer/item/tax mappings, stock, totals, connectivity, and duplicate search by local/external reference.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Open the set up POS/invoice workflow. ### Submit and Verify a Tax-Integrated Sale #### Step 1: Create and validate the sale #### Step 2: Preview taxable values, rates, taxes, and total #### Step 3: Submit/complete once #### Step 4: Capture the local transaction number immediately #### Step 5: Capture authority request/reference and response status/message #### Step 6: Print only the response-backed invoice format required by policy #### Step 7: Reconcile local tax, stock, payment, and ledger effects ### Check your work Classify it as accepted, rejected, or unknown using provider evidence; never infer acceptance from local save alone.
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 another sale after a timeout. - Use the failure-recovery workflow for rejected or unknown outcomes. ### Related guides - [Review FBR Tax Transactions](https://docs.muhasiberp.com/link/281) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) - [Create a POS Sale](https://docs.muhasiberp.com/link/524) ### What to do next
[**Review FBR Tax Transactions**](https://docs.muhasiberp.com/link/281).
# Create and Verify a Manual Database Backup ### How to Create and Verify a Manual Database Backup in Muhasib ERP ### Overview This guide will help you create a SQL Server.bak backup and prove it is usable through controlled verification. SQL Server creates a database backup file; file existence alone does not prove recoverability. ### Who can do this You need access to Backup & Restore access, SQL Server backup rights, and filesystem access to the selected server-visible location. ### Before you start Confirm active database, backup destination, free space, encryption/retention policy, maintenance window, and unique filename.
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 → Backup and Restore → manual backup. ### Create and Verify a Manual Database Backup #### Step 1: Confirm the intended company database and record its identity #### Step 2: Select an approved .bak destination visible to SQL Server #### Step 3: Start backup once and wait for the success message #### Step 4: Confirm file exists with plausible size and timestamp #### Step 5: Record database/version/date and checksum/hash where policy requires #### Step 6: Test restore into an isolated non-production database ### Check your work An isolated restore opens successfully and key company, settings, master, and transaction control totals match.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - SQL Server service identity, not only the desktop user, needs path access. - Never overwrite the only known-good backup. ### Related guides - [Restore a Database Backup Safely](https://docs.muhasiberp.com/link/284) - [Configure Automatic Database Backups](https://docs.muhasiberp.com/link/285) - [Recover from a Database or Startup Failure](https://docs.muhasiberp.com/link/579) ### What to do next
[**Restore a Database Backup Safely**](https://docs.muhasiberp.com/link/284).
# Restore a Database Backup Safely ### How to Restore a Database Backup Safely in Muhasib ERP ### Overview This guide will help you restore an approved.bak into the intended isolated or authorized target and validate its contents. The target database state is replaced by the selected backup; later target changes may be lost. ### Who can do this You need access to Backup & Restore access, SQL Server restore rights, target-database authority, and explicit business approval. ### Before you start Confirm exact target server/database, backup provenance, version compatibility, pre-restore backup, user outage, rollback plan, file integrity, and written 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 → Backup and Restore → restore database. ### Restore a Database Backup Safely #### Step 1: Stop and confirm the target is not an unintended production database #### Step 2: Create and verify a pre-restore backup of the current target #### Step 3: Disconnect or coordinate active users/services #### Step 4: Select the approved .bak file #### Step 5: Review target identity and confirm restore once #### Step 6: Reconnect, launch Muhasib, and run post-restore checks #### Step 7: Preserve logs and both backups ### Check your work Confirm database identity/revision, company, users, settings, masters, transaction counts/totals, reports, and application startup.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Do not repeatedly restore after an error without preserving evidence. - Resolve version, active-connection, path, permission, and file-integrity issues first. ### Related guides - [Create and Verify a Manual Database Backup](https://docs.muhasiberp.com/link/283) - [Connect Muhasib ERP to an Existing Database](https://docs.muhasiberp.com/link/554) - [Recover from a Database or Startup Failure](https://docs.muhasiberp.com/link/579) ### What to do next
[**Create and Verify a Manual Database Backup**](https://docs.muhasiberp.com/link/283).
# Configure Automated Temporary-Sale Conversion ### How to Configure Automated Temporary-Sale Conversion in Muhasib ERP ### Overview This guide will help you configure an approved rule for automatically converting allowed temporary sales while excluding unsafe records. Eligible temporary sales may be converted by background logic; exact timing and effects require verification. ### Who can do this You need access to Relevant global/instance settings and temporary-sale/POS conversion permissions. ### Before you start Confirm product support, schedule, eligibility statuses, payment/credit treatment, stock rules, customer handling, tax/integration behavior, numbering, cutoff, retry, 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 Back Office → Administration/Settings → temporary-sale automation settings, when exposed. ### Configure Automated Temporary-Sale Conversion #### Step 1: Keep automation disabled while defining rules #### Step 2: Record current settings and pending temporary-sale population #### Step 3: Configure schedule and explicit eligibility criteria #### Step 4: Exclude incomplete, disputed, unmapped, or already converted records #### Step 5: Enable only in a cloned environment first #### Step 6: Process one known eligible record Process one known allowed record. #### Step 7: Approve production activation only after reconciliation ### Check your work One source temporary sale maps to one final invoice with correct status, stock, customer, tax, payment, and ledgers.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - If no active UI/scheduler is found, classify the feature as hidden/deferred. - Do not enable broad criteria against unreviewed historical records. ### Related guides - [Verify Automated Temporary-Sale Conversion](https://docs.muhasiberp.com/link/289) - [Convert a Temporary Sale to an Invoice](https://docs.muhasiberp.com/link/543) - [Understand Back Office Background Operations](https://docs.muhasiberp.com/link/287) ### What to do next
[**Verify Automated Temporary-Sale Conversion**](https://docs.muhasiberp.com/link/289).
# Verify Automated Temporary-Sale Conversion ### How to Verify Automated Temporary-Sale Conversion in Muhasib ERP ### Overview This guide will help you compare and confirm an automated conversion run and prove every allowed temporary sale was converted exactly once. The automated run has a reconciled control result and exception list. ### Who can do this You need access to Temporary Sale and Sale Inquiry/report access, plus stock/payment/tax/ledger visibility. ### Before you start Capture the pre-run eligible/excluded population, settings, cutoff, source references, and expected totals.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Temporary Sales Inquiry, Sale Inquiry, background notifications/logs, and relevant stock/financial reports. ### Verify Automated Temporary-Sale Conversion #### Step 1: Record eligible and excluded source IDs before the run Record allowed and excluded source IDs before the run. #### Step 2: Observe one scheduled execution without parallel manual conversion #### Step 3: Match each eligible source to a final invoice Match each allowed source to a final invoice. #### Step 4: Confirm source status and absence of duplicates #### Step 5: Reconcile customer, items, stock, prices, tax, payments, and ledgers #### Step 6: Classify failures and retry only confirmed failed records ### Check your work Eligible count/value equals successful conversions plus documented failures, with one final invoice per successful source.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Stop automation on duplicate or unexplained conversion behavior. - Preserve source and final records; do not delete either to force checking. ### Related guides - [Configure Automated Temporary-Sale Conversion](https://docs.muhasiberp.com/link/288) - [Convert a Temporary Sale to an Invoice](https://docs.muhasiberp.com/link/543) - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) ### What to do next
[**Configure Automated Temporary-Sale Conversion**](https://docs.muhasiberp.com/link/288).
# FBR Digital Invoicing and FBR Configure FBR POS and Digital Invoicing, submit transactions, and review tax results. # Configure and Test FBR POS Integration ### How to Configure and Test FBR POS Integration in Muhasib ERP ### Overview This guide will help you configure FBR POS identifiers and successfully validate a representative sandbox sale. Muhasib stores the local sale and FBR response according to the connector path; acceptance must be verified from the response. ### Who can do this You need access to FBR/tax settings, terminal/location, item/customer tax, and POS sale permissions. ### Before you start Complete tax-integration preparation and get approved sandbox endpoint, token/credentials, POS/branch IDs, scenarios, and test data.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → tax/global/terminal settings, then POS Sale. ### Configure and Test FBR POS Integration #### Step 1: Record current non-secret settings #### Step 2: Enter approved sandbox endpoint and protected credentials #### Step 3: Map company, branch, terminal/POS, invoice, tax, item, unit, and customer Map company, branch, terminal/POS, invoice, tax, item, unit, and customer identifiers. #### Step 4: Create a controlled sale representing an approved scenario #### Step 5: Submit once #### Step 6: Capture FBR request/reference, response code/message, assigned number/QR where returned, and Capture FBR request/reference, response code/message, assigned number/QR where returned, and local status. #### Step 7: Reconcile tax and totals ### Check your work One local test invoice maps to one accepted FBR reference and all quantities, taxable values, rates, taxes, and totals agree.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Do not retry a timeout before checking FBR status by reference. - Resolve invalid registration, item, unit, tax, or scenario mappings at source. ### Related guides - [Prepare Muhasib for Tax Integration](https://docs.muhasiberp.com/link/275) - [Submit and Verify a Tax-Integrated Sale](https://docs.muhasiberp.com/link/280) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) ### What to do next
[**Prepare Muhasib for Tax Integration**](https://docs.muhasiberp.com/link/275).
# Configure and Test FBR Digital Invoicing ### How to Configure and Test FBR Digital Invoicing in Muhasib ERP ### Overview This guide will help you configure the FBR Digital Invoicing connector and validate representative invoices in an authorized sandbox. Muhasib serializes invoice/header and item data into the connector model and stores or displays the returned result according to system behavior. ### Who can do this You need access to Tax integration settings plus invoice/sale and relevant master-data permissions. ### Before you start Get current FBR sandbox specification, credentials/token, seller/buyer rules, scenario IDs, item/service codes, units, tax mappings, and approved samples.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → tax/global settings and the needed invoice workflow. ### Configure and Test FBR Digital Invoicing #### Step 1: Configure only the approved sandbox endpoint and protected credentials #### Step 2: Map seller, buyer, document, scenario, item, unit, value, rate, and Map seller, buyer, document, scenario, item, unit, value, rate, and tax fields. #### Step 3: Test registered and unregistered buyer cases as applicable Test registered and unregistered buyer cases as needed. #### Step 4: Submit one representative invoice once #### Step 5: Preserve sanitized request and full response identifiers/status #### Step 6: Reconcile response line results to local lines #### Step 7: Test approved rejection and recovery scenarios before go-live ### Check your work Every sandbox scenario receives the expected status and each response line/value maps unambiguously to the local invoice.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Treat schema-valid and authority-accepted as different states. - Do not infer current field requirements solely from bundled models. ### Related guides - [Prepare Muhasib for Tax Integration](https://docs.muhasiberp.com/link/275) - [Submit and Verify a Tax-Integrated Sale](https://docs.muhasiberp.com/link/280) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) ### What to do next
[**Prepare Muhasib for Tax Integration**](https://docs.muhasiberp.com/link/275).
# Review FBR Tax Transactions ### How to Review FBR Tax Transactions in Muhasib ERP ### Overview This guide will help you compare and confirm FBR-related transactions, local documents, response identifiers, statuses, and tax totals for a selected period. You get a filing/control population and exception list; report output is not itself a statutory filing. ### Who can do this You need access to FBRTaxReport and relevant sale/tax inquiry. ### Before you start Know company/registration, period, terminal/location, connector type, expected submissions, statuses, and tax control totals.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Open FBR Tax Report from its set up reporting/module path. ### Review FBR Tax Transactions #### Step 1: Select exact company, registration, date, and terminal scope #### Step 2: Review local transaction and FBR identifiers #### Step 3: Classify accepted, rejected, pending/unknown, and missing submissions #### Step 4: Reconcile quantities, taxable value, tax, and gross total #### Step 5: Open source sales and stored responses for exceptions #### Step 6: Compare totals with general tax reports and tax accounts ### Check your work Each allowed local transaction has the correct unique FBR outcome and report totals compare and confirm to source and tax controls.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Confirm date and registration scope before investigating omissions. - Never change a stored response to make a report appear accepted. ### Related guides - [Submit and Verify a Tax-Integrated Sale](https://docs.muhasiberp.com/link/280) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) - [Review Tax Transactions and Summaries](https://docs.muhasiberp.com/link/246) ### What to do next
[**Submit and Verify a Tax-Integrated Sale**](https://docs.muhasiberp.com/link/280).
# SRB and PRA Configure and test Sindh Revenue Board and Punjab Revenue Authority integrations. # Configure and Test SRB Integration ### How to Configure and Test SRB Integration in Muhasib ERP ### Overview This guide will help you configure SRB integration and validate an needed service invoice without affecting production reporting. Muhasib attempts SRB submission through the set up path; acceptance is established only by the authority response. ### Who can do this You need access to SRB/tax settings, needed service-sale, terminal/location, and tax permissions. ### Before you start Get current SRB specifications, sandbox endpoint/credentials, registration/branch/POS identifiers, service codes, tax rates, buyer rules, and test scenarios.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → tax/global/terminal settings, then the needed sales workflow. ### Configure and Test SRB Integration #### Step 1: Confirm whether the runtime uses the legacy or newer SRB protocol #### Step 2: Configure sandbox endpoint and protected credentials #### Step 3: Map seller, buyer, service, tax, document, and terminal values #### Step 4: Create one approved sandbox service transaction #### Step 5: Submit once and preserve response ID/code/message #### Step 6: Reconcile local and SRB values/status ### Check your work One local transaction maps to one accepted sandbox response and taxable value/tax/total 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 if system protocol cannot be established. - Check registration, service code, date, tax rate, credentials, and endpoint before retry. ### Related guides - [Prepare Muhasib for Tax Integration](https://docs.muhasiberp.com/link/275) - [Submit and Verify a Tax-Integrated Sale](https://docs.muhasiberp.com/link/280) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) ### What to do next
[**Prepare Muhasib for Tax Integration**](https://docs.muhasiberp.com/link/275).
# Configure and Test PRA Integration ### How to Configure and Test PRA Integration in Muhasib ERP ### Overview This guide will help you configure PRA integration and validate an needed service invoice in a controlled environment. Muhasib attempts PRA submission; transport success alone does not prove authority acceptance. ### Who can do this You need access to PRA/tax settings, needed service-sale, terminal/location, and tax permissions. ### Before you start Get current PRA specifications, sandbox endpoint/credentials, registration and terminal identifiers, service codes, rates, buyer rules, and test scenarios.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → tax/global/terminal settings, then the needed sales workflow. ### Configure and Test PRA Integration #### Step 1: Confirm the connector is active for the selected company/location #### Step 2: Configure sandbox endpoint and protected credentials #### Step 3: Map seller, buyer, service, tax, document, and terminal values #### Step 4: Create one approved test service transaction #### Step 5: Submit once and retain response identifiers/status #### Step 6: Reconcile authority response to local transaction values ### Check your work One local transaction maps to one accepted sandbox response and all tax values 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 - Check applicability and current official rules before configuring. - Resolve identifiers, classifications, credentials, and endpoint errors before retry. ### Related guides - [Prepare Muhasib for Tax Integration](https://docs.muhasiberp.com/link/275) - [Submit and Verify a Tax-Integrated Sale](https://docs.muhasiberp.com/link/280) - [Recover from Tax Submission Failure](https://docs.muhasiberp.com/link/282) ### What to do next
[**Prepare Muhasib for Tax Integration**](https://docs.muhasiberp.com/link/275).
# SMS and Email Set up SMS and email, assign gateways, send messages, and review delivery evidence. # Create an SMS Gateway ### How to Create an SMS Gateway in Muhasib ERP ### Overview This guide will help you create an SMS gateway definition with the provider URL, recipient parameter, and request method. The gateway becomes available for assignment to a location. ### Who can do this You need access to SMSSettingsAdd. ### Before you start Have provider documentation, approved URL, request method, recipient/message parameters, credentials, encoding, test number, and data-security 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 SMS Settings. ### Create an SMS Gateway #### Step 1: Start a new SMS gateway #### Step 2: Enter a unique Short Description #### Step 3: Enter the provider URL #### Step 4: Enter the Send To parameter name #### Step 5: Select the request method #### Step 6: Enter other provider parameters without exposing secrets in descriptions #### Step 7: Save once ### Check your work Reopen it and confirm description, URL, recipient parameter, method, and protected credentials match the approved settings.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - The source requires Short Description, URL, Send To parameter, and request method. - Do not embed production secrets in screenshots or documentation. ### Related guides - [Assign an SMS Gateway to a Location](https://docs.muhasiberp.com/link/260) - [Test and Maintain an SMS Gateway](https://docs.muhasiberp.com/link/261) - [Send a Message to Multiple Recipients](https://docs.muhasiberp.com/link/262) ### What to do next
[**Assign an SMS Gateway to a Location**](https://docs.muhasiberp.com/link/260).
# Assign an SMS Gateway to a Location ### Assign an SMS Gateway to a Location ### Overview This guide will help you assign the intended SMS gateway to the location used by a terminal. SMS sends from that terminal can resolve the gateway through its location. ### Who can do this You need access to Location update plus SMS gateway view. ### Before you start Confirm gateway, company, location, terminal, provider region, and restart window.
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 Locations → SMS gateway setting. ### Assign an SMS Gateway to a Location #### Step 1: Open the terminal's assigned location #### Step 2: Select the approved SMS gateway #### Step 3: Save the location once #### Step 4: Confirm the terminal is assigned to that location #### Step 5: Close active work safely and restart Muhasib as instructed by Close active work safely and restart Muhasib as instructed by the source error message. #### Step 6: Run a controlled test ### Check your work Reopen the location and confirm assignment; the send form no longer reports that a gateway must be assigned and software restarted.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Check the active terminal and its location, not only the company. - Restart after changing the assignment. ### Related guides - [Create an SMS Gateway](https://docs.muhasiberp.com/link/259) - [Test and Maintain an SMS Gateway](https://docs.muhasiberp.com/link/261) - [Understand Company, Location, Terminal, and Licence Identities](https://docs.muhasiberp.com/link/165) ### What to do next
[**Create an SMS Gateway**](https://docs.muhasiberp.com/link/259).
# Test and Maintain an SMS Gateway ### Test and Maintain an SMS Gateway ### Overview This guide will help you test a gateway and update or retire it without disrupting locations that depend on it. The gateway is validated or safely taken out of use; the source blocks deletion while it is assigned. ### Who can do this You need access to SMSSettingsUpdate; deletion also requires SMSSettingsDelete and explicit removal approval. ### Before you start Use a sandbox/test recipient, keep the old settings, identify assigned locations, and get provider/change 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 SMS Settings. ### Test and Maintain an SMS Gateway #### Step 1: Open the exact gateway and record non-secret current values #### Step 2: Update URL, method, or parameters only from approved provider documentation #### Step 3: Save and restart affected Muhasib sessions where required #### Step 4: Send one test message #### Step 5: Verify submission and delivery evidence separately #### Step 6: Reassign all dependent locations before any approved retirement/removal ### Check your work Confirm a test result, inquiry record, provider status, and all location assignments.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - A send-success response may not prove handset delivery. - Never delete a gateway that the application reports as in use. ### Related guides - [Assign an SMS Gateway to a Location](https://docs.muhasiberp.com/link/260) - [Review SMS History and Delivery Evidence](https://docs.muhasiberp.com/link/263) - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) ### What to do next
[**Assign an SMS Gateway to a Location**](https://docs.muhasiberp.com/link/260).
# Review SMS History and Delivery Evidence ### How to Review SMS History and Delivery Evidence in Muhasib ERP ### Overview This guide will help you trace a message to its recipient, content, timestamp, local status, and available provider evidence. You get the strongest available evidence of submission or delivery and a basis for safe retry. ### Who can do this You need access to SMS Inquiry/report access and authorized customer/message scope. ### Before you start Have recipient, date/time range, transaction/reference, sender/terminal, or message fragment without exposing sensitive content.
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 → SMS Inquiry. ### Review SMS History and Delivery Evidence #### Step 1: Select company and a narrow date range #### Step 2: Filter by recipient or reference where supported #### Step 3: Open the individual SMS detail/report #### Step 4: Confirm number, message, time, gateway, and local result #### Step 5: Compare with provider request/delivery ID where available #### Step 6: Record discrepancies without resending automatically ### Check your work Match one local message to one intended recipient and at most one accepted provider request.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Local success may mean submission rather than handset delivery. - Restrict access because message content can contain personal data. ### Related guides - [Send a Message to Multiple Recipients](https://docs.muhasiberp.com/link/262) - [Test and Maintain an SMS Gateway](https://docs.muhasiberp.com/link/261) - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) ### What to do next
[**Send a Message to Multiple Recipients**](https://docs.muhasiberp.com/link/262).
# Configure Email Delivery ### How to Configure Email Delivery in Muhasib ERP ### Overview This guide will help you configure approved email delivery for Muhasib report messages. Eligible Email Report actions can submit messages through the set up server. ### Who can do this You need access to Relevant global/instance email settings administration. ### Before you start Have approved SMTP host, port, security mode, sender, username/secret, test recipient, firewall requirements, and credential-storage policy.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → Administration/Settings → email settings, as exposed by the deployment. ### Configure Email Delivery #### Step 1: Record current non-secret settings #### Step 2: Enter approved host, port, security, and sender identity #### Step 3: Enter credentials through protected fields #### Step 4: Save once and restart only if required #### Step 5: Email a non-sensitive test report to a controlled recipient #### Step 6: Verify submission and mailbox receipt ### Check your work Confirm sender, recipient, subject, attachment, timestamps, SMTP result, and mailbox receipt.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Check TLS mode, port, authentication, firewall, and sender authorization. - Never expose passwords in screenshots or logs. ### Related guides - [Email a Muhasib Report Safely](https://docs.muhasiberp.com/link/265) - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) - [Manage Global and Instance Settings](https://docs.muhasiberp.com/link/206) ### What to do next
[**Email a Muhasib Report Safely**](https://docs.muhasiberp.com/link/265).
# Email a Muhasib Report Safely ### How to Email a Muhasib Report Safely in Muhasib ERP ### Overview This guide will help you send the correct filtered report to verified recipients without disclosing unauthorized data. Muhasib submits the message through set up email delivery; submission does not prove recipient acceptance. ### Who can do this You need access to Report view and email action access, plus authorization for the data and recipients. ### Before you start Confirm report filters, recipient identities, purpose, classification, attachment format, email settings, 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 and filter the report → Email Report. ### Email a Muhasib Report Safely #### Step 1: Generate the report with exact company/date/entity filters #### Step 2: Review totals and sensitive fields #### Step 3: Open Email Report #### Step 4: Enter and verify To/Cc recipients, subject, and message #### Step 5: Confirm attachment/preview matches the filtered report #### Step 6: Send once and retain the result ### Check your work Confirm send result and controlled mailbox receipt with the correct attachment and scope.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Do not retry a timeout until sent-mail/provider evidence is checked. - Remove unauthorized recipients before sending. ### Related guides - [Configure Email Delivery](https://docs.muhasiberp.com/link/264) - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) - [Print, Export, or Email a Report](https://docs.muhasiberp.com/link/484) ### What to do next
[**Configure Email Delivery**](https://docs.muhasiberp.com/link/264).
# Shopify and WooCommerce Connect online stores, synchronize orders, validate mappings, and convert orders into sales. # Configure Shopify Integration ### How to Configure Shopify Integration in Muhasib ERP ### Overview This guide will help you connect an approved Shopify test store and define how its orders map into Muhasib. Muhasib can request Shopify orders and present them for mapping/conversion according to settings. ### Who can do this You need access to E-commerce/global settings administration and Shopify app/store authorization. ### Before you start Have sandbox store URL, approved credentials/token, API scopes, order-status policy, customer/item/tax/shipping/payment mappings, and a baseline backup.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → Administration/Settings → Shopify/e-commerce settings. ### Configure Shopify Integration #### Step 1: Confirm the environment is non-production #### Step 2: Record current non-secret integration settings #### Step 3: Enter store URL and credentials through protected fields #### Step 4: Configure order status, tax calculation, customer, item, shipping, and payment Configure order status, tax calculation, customer, item, shipping, and payment mappings. #### Step 5: Disable unattended synchronization until testing is complete #### Step 6: Save once and retrieve a controlled test order ### Check your work Confirm one known test order is retrieved once with correct external ID, customer, lines, tax, shipping, payment, and status.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Check API URL/version, scopes, token, clock, and firewall. - Never expose the token in documentation or screenshots. ### Related guides - [Synchronize E-Commerce Orders](https://docs.muhasiberp.com/link/268) - [Map and Validate an E-Commerce Order](https://docs.muhasiberp.com/link/269) - [Prepare a Safe Integration Environment](https://docs.muhasiberp.com/link/256) ### What to do next
[**Synchronize E-Commerce Orders**](https://docs.muhasiberp.com/link/268).
# Configure WooCommerce Integration ### How to Configure WooCommerce Integration in Muhasib ERP ### Overview This guide will help you connect an approved WooCommerce test store and define how its orders map into Muhasib. The shared order workflow can retrieve and display WooCommerce orders for review and conversion. ### Who can do this You need access to E-commerce/global settings administration and WooCommerce REST API authorization. ### Before you start Have sandbox store URL, consumer credentials, HTTPS/API access, status policy, customer/item/tax/shipping/payment mappings, and a backup.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → Administration/Settings → WooCommerce/e-commerce settings. ### Configure WooCommerce Integration #### Step 1: Confirm the environment and store are non-production #### Step 2: Record current non-secret settings #### Step 3: Enter store URL and credentials through protected fields #### Step 4: Configure order status and all Muhasib mappings #### Step 5: Keep unattended synchronization disabled during testing #### Step 6: Save and retrieve one controlled WooCommerce order ### Check your work Match one external ID and its customer, lines, tax, shipping, payment, and status to the test store.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Check HTTPS, REST API access, credentials, permissions, and permalink/API settings. - Never record consumer secrets in articles or tickets. ### Related guides - [Synchronize E-Commerce Orders](https://docs.muhasiberp.com/link/268) - [Map and Validate an E-Commerce Order](https://docs.muhasiberp.com/link/269) - [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).
# Synchronize E-Commerce Orders ### How to Synchronize E-Commerce Orders in Muhasib ERP ### Overview This guide will help you retrieve allowed Shopify or WooCommerce orders without creating duplicates or importing unintended statuses. Eligible external orders appear for check; retrieval alone must not be assumed to post a sale. ### Who can do this You need access to E-Commerce Orders and set up integration. ### Before you start Confirm provider, company, last successful cursor/time, allowed statuses, external IDs, mappings, network, and whether background sync is active.
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 → E-Commerce Orders, or monitored Back Office synchronization. ### Synchronize E-Commerce Orders #### Step 1: Confirm the intended company/store and synchronization window #### Step 2: Check whether a background run is already active #### Step 3: Start one manual retrieval only when safe #### Step 4: Review retrieved count and external IDs #### Step 5: Separate new, existing, rejected, and unknown records #### Step 6: Preserve errors and cursor/time evidence before retrying ### Check your work Match provider allowed count to retrieved/new/existing/rejected outcomes with no duplicate external IDs.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Avoid overlapping manual and background runs. - Query unknown external IDs before repeating a timed-out request. ### Related guides - [Map and Validate an E-Commerce Order](https://docs.muhasiberp.com/link/269) - [Reconcile E-Commerce Orders and Muhasib Sales](https://docs.muhasiberp.com/link/271) - [Understand Back Office Background Operations](https://docs.muhasiberp.com/link/287) ### What to do next
[**Map and Validate an E-Commerce Order**](https://docs.muhasiberp.com/link/269).
# Map and Validate an E-Commerce Order ### Map and Validate an E-Commerce Order ### Overview This guide will help you resolve an external order to the correct Muhasib customer, items, quantities, tax, shipping, payment, and totals. The order is validated for conversion; no sale should be assumed until the POS action succeeds. ### Who can do this You need access to E-Commerce Orders plus customer/item lookup and any authorized master-maintenance rights. ### Before you start Have the external order, approved mapping rules, item variants/SKUs, customer policy, tax/shipping treatment, payment method, and stock/location rules.
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 → open the external order. ### Map and Validate an E-Commerce Order #### Step 1: Confirm provider and external order ID #### Step 2: Match or create the customer only under approved rules #### Step 3: Match each SKU/variant to the exact Muhasib item and unit #### Step 4: Confirm quantities, prices, discounts, tax, shipping, and payment #### Step 5: Resolve missing or ambiguous mappings instead of substituting items #### Step 6: Compare external and Muhasib-calculated totals #### Step 7: Mark the order ready for conversion where supported ### Check your work Every external line maps once and recalculated subtotal, discounts, tax, shipping, and grand total 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 - Review `shpy_tx_cal`/tax policy when totals differ. - Never map an unknown SKU to a merely similar item. ### Related guides - [Convert an E-Commerce Order into a POS Sale](https://docs.muhasiberp.com/link/270) - [Create a Customer](https://docs.muhasiberp.com/link/367) - [Update an Item Safely](https://docs.muhasiberp.com/link/324) ### What to do next
[**Convert an E-Commerce Order into a POS Sale**](https://docs.muhasiberp.com/link/270).
# Convert an E-Commerce Order into a POS Sale ### Convert an E-Commerce Order into a POS Sale ### Overview This guide will help you convert one validated e-commerce order into one Muhasib POS sale. Muhasib creates a POS sale through the set up POS type; source and provider status behavior requires verification. ### Who can do this You need access to E-Commerce Orders, PosSale, and PosSaleAdd; all referenced customer/item/payment permissions also apply. ### Before you start Confirm external ID is not already converted, mappings/totals are correct, stock is available, register/period is ready, and payment/delivery policy is approved.
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 → open validated order → POS/conversion action. ### Convert an E-Commerce Order into a POS Sale #### Step 1: Search Muhasib for the external order ID #### Step 2: Open the validated order and recheck customer, lines, totals, tax, Open the validated order and recheck customer, lines, totals, tax, shipping, and payment. #### Step 3: Start the POS conversion once #### Step 4: Complete any required POS fields #### Step 5: Confirm once and retain Muhasib sale number plus external ID #### Step 6: Review source order status and provider acknowledgement ### Check your work Match one external ID to one sale and compare and confirm stock, customer, payment, tax, delivery, receipt, and provider state.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - The source separately demands PosSale and PosSaleAdd access. - Never use the source-visible delete action to fix a duplicate without clear approval. ### Related guides - [Map and Validate an E-Commerce Order](https://docs.muhasiberp.com/link/269) - [Reconcile E-Commerce Orders and Muhasib Sales](https://docs.muhasiberp.com/link/271) - [Correct or Reverse a Customer or Agent Transaction](https://docs.muhasiberp.com/link/214) ### What to do next
[**Map and Validate an E-Commerce Order**](https://docs.muhasiberp.com/link/269).
# Reconcile E-Commerce Orders and Muhasib Sales ### How to Reconcile E-Commerce Orders and Muhasib Sales in Muhasib ERP ### Overview This guide will help you compare and confirm retrieved external orders to Muhasib sales, payments, stock, tax, and remaining exceptions. The integration population is reconciled and exceptions have controlled owners/actions. ### Who can do this You need access to E-commerce, sale inquiry, payment, stock, and tax report. ### Before you start Have provider order/export data, Muhasib external IDs/sale numbers, synchronization window, status mapping, and settlement data.
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, Sale Inquiry, payment reports, Stock Ledger, and tax reports. ### Reconcile E-Commerce Orders and Muhasib Sales #### Step 1: Define the exact provider/company/time/status population #### Step 2: Match each external ID to zero or one Muhasib sale #### Step 3: Reconcile customer, lines, totals, tax, shipping, discounts, and payment #### Step 4: Reconcile stock and returns/cancellations #### Step 5: Classify missing, duplicate, rejected, or state-mismatched records #### Step 6: Correct through source workflows and retain evidence ### Check your work Provider and Muhasib counts/values agree for the same scope, subject only to documented timing or rejected records.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Separate order time, sync time, and sale-posting time. - Do not delete unmatched records to force counts to agree. ### Related guides - [Synchronize E-Commerce Orders](https://docs.muhasiberp.com/link/268) - [Convert an E-Commerce Order into a POS Sale](https://docs.muhasiberp.com/link/270) - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) ### What to do next
[**Synchronize E-Commerce Orders**](https://docs.muhasiberp.com/link/268).
# Offline POS and Synchronization Configure offline POS sync, monitor transfers, and recover from partial synchronization. # Configure Offline POS Synchronization ### How to Configure Offline POS Synchronization in Muhasib ERP ### Overview This guide will help you configure whether offline POS data synchronizes automatically and at what interval. The sync form checks automatic eligibility on its one-minute timer and uses the set up interval to decide when to process. ### Who can do this You need access to Offline POS synchronization and relevant global-settings administration. ### Before you start Confirm central database, company/terminal identity, network, duplicate policy, pending local data, maintenance window, and rollback snapshot.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office → Administration/Settings → Offline POS settings and Sync Offline POS Data. ### Configure Offline POS Synchronization #### Step 1: Preserve pending offline data and record current settings #### Step 2: Confirm the central target database/company #### Step 3: Configure offposautosync as approved Configure `off_pos_auto_sync` as approved. #### Step 4: Configure offpossynctimeinterval; verify its runtime unit before production use Configure `off_pos_sync_time_interval`; check its system unit before production use. #### Step 5: Save and restart/reopen the sync form if required #### Step 6: Test one known transaction family ### Check your work Confirm settings save and one test record reaches the intended central company 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 infer that the setting interval is minutes without system proof. - Stop if the central company or database is wrong. ### Related guides - [Monitor Automatic Offline POS Synchronization](https://docs.muhasiberp.com/link/273) - [Recover from Partial Offline POS Synchronization](https://docs.muhasiberp.com/link/274) - [Create an Offline POS Sale](https://docs.muhasiberp.com/link/546) ### What to do next
[**Monitor Automatic Offline POS Synchronization**](https://docs.muhasiberp.com/link/273).
# Monitor Automatic Offline POS Synchronization ### Monitor Automatic Offline POS Synchronization ### Overview This guide will help you confirm automatic offline synchronization is running at the intended cadence and processing each transaction family once. You get evidence of scheduler cadence and family-level synchronization health. ### Who can do this You need access to Offline sync and access to local pending and central transaction inquiries. ### Before you start Know the enabled setting, set up interval, last run, pending counts for sales, credit notes, quotations, and temporary sales, and central baseline.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Open Sync Offline POS Data and relevant central inquiries. ### Monitor Automatic Offline POS Synchronization #### Step 1: Confirm the sync form remains open and connected to the correct company #### Step 2: Record pending counts by transaction family #### Step 3: Observe the next eligible automatic run Observe the next allowed automatic run. #### Step 4: Capture successes and errors by family #### Step 5: Compare local pending state with central records #### Step 6: Confirm the next run does not duplicate successes ### Check your work Pending decreases match central additions and every external/offline reference appears no more than once.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - The source timer ticks every minute, but set up eligibility may be less frequent. - Closing the form stops and disposes its timer. ### Related guides - [Configure Offline POS Synchronization](https://docs.muhasiberp.com/link/272) - [Recover from Partial Offline POS Synchronization](https://docs.muhasiberp.com/link/274) - [Synchronize Offline POS Sales](https://docs.muhasiberp.com/link/547) ### What to do next
[**Configure Offline POS Synchronization**](https://docs.muhasiberp.com/link/272).
# Recover from Partial Offline POS Synchronization ### Recover from Partial Offline POS Synchronization ### Overview This guide will help you recover a sync run where some offline sales, credit notes, quotations, or temporary sales succeeded and others failed. 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 partial batch is reconciled without intentionally duplicating successful records. ### Who can do this You need access to Offline sync plus all affected central transaction inquiry/correction rights. ### Before you start Preserve offline data and logs; record pending/success/error counts and references for every transaction family.
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 Sale, return/credit, Quotation, and Temporary Sale inquiries. ### Recover from Partial Offline POS Synchronization #### Step 1: Stop automatic retries while classifying outcomes #### Step 2: Match every offline reference to central records #### Step 3: Mark confirmed successes and exclude them from retry #### Step 4: Investigate failed sales, credit notes, quotations, and temporary sales separately #### Step 5: Correct deterministic master, stock, permission, or validation errors #### Step 6: Retry one confirmed failure and reconcile it #### Step 7: Resume remaining failures and then automatic sync ### Check your work Local pending plus central success plus documented rejected totals equal the original control population by family.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - A final completion message does not erase earlier family-specific errors. - Never clear local offline data until all references compare and confirm. ### Related guides - [Configure Offline POS Synchronization](https://docs.muhasiberp.com/link/272) - [Monitor Automatic Offline POS Synchronization](https://docs.muhasiberp.com/link/273) - [Retry a Partially Successful Integration Safely](https://docs.muhasiberp.com/link/258) ### What to do next
[**Configure Offline POS Synchronization**](https://docs.muhasiberp.com/link/272).
# Scheduled Operations and Automatic Conversion Manage automatic backups, background work, and scheduled temporary-sale conversion. # Configure Automatic Database Backups ### How to Configure Automatic Database Backups in Muhasib ERP ### Overview This guide will help you enable automatic backups with an approved location, interval, and retained-file count. Muhasib uses aut\_bkp\_en, aut\_bkp\_loc, aut\_bkp\_intr, and aut\_bkp\_cnt; the service creates the directory and prunes older backups beyond retention. ### Who can do this You need access to Software Backup settings administration and SQL/filesystem backup rights. ### Before you start Choose a secure SQL Server-visible location, approved interval, retention count, free-space monitor, off-host copy, and restore-test schedule.
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 → Backup and Restore → Automatic Backup. ### Configure Automatic Database Backups #### Step 1: Confirm the Automatic Backup tab is available #### Step 2: Enable automatic backup #### Step 3: Select an approved backup location; source validation requires one when Select an approved backup location; source check requires one when enabled. #### Step 4: Enter interval and retained quantity according to policy #### Step 5: Save once and confirm the success message #### Step 6: Observe the first scheduled backup ### Check your work Confirm a new `.bak`, plausible size/time, instance last-run state, retention behavior, and an isolated restore test.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - The source defaults observed were interval 300 and retention 20; check units and policy rather than accepting blindly. - Keep an off-host backup because local retention is not disaster recovery. ### Related guides - [Monitor Automatic Backups and Retention](https://docs.muhasiberp.com/link/286) - [Create and Verify a Manual Database Backup](https://docs.muhasiberp.com/link/283) - [Understand Back Office Background Operations](https://docs.muhasiberp.com/link/287) ### What to do next
[**Monitor Automatic Backups and Retention**](https://docs.muhasiberp.com/link/286).
# Monitor Automatic Backups and Retention ### Monitor Automatic Backups and Retention ### Overview This guide will help you confirm backups run on schedule, retained files are healthy, and pruning does not remove required recovery points. Backup health and recovery readiness are evidenced rather than inferred from settings. ### Who can do this You need access to Backup settings/status and authorized filesystem. ### Before you start Know expected interval, location, retention count, last successful run, database size, storage alert threshold, and off-host copy policy.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Automatic Backup settings, set up backup folder, notifications/logs, and instance status. ### Monitor Automatic Backups and Retention #### Step 1: Confirm automatic backup remains enabled #### Step 2: Compare last backup timestamp to the expected schedule #### Step 3: Check newest file name, size, and database identity #### Step 4: Confirm file count follows retention without removing protected recovery points #### Step 5: Review errors and disk space #### Step 6: Periodically restore a selected file in isolation ### Check your work Scheduled files appear, retention matches policy, off-host copies exist, and restore tests succeed.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - A set up path with no recent file is a failed control. - Stop pruning/cleanup investigation before manually deleting backup evidence. ### Related guides - [Configure Automatic Database Backups](https://docs.muhasiberp.com/link/285) - [Restore a Database Backup Safely](https://docs.muhasiberp.com/link/284) - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) ### What to do next
[**Configure Automatic Database Backups**](https://docs.muhasiberp.com/link/285).
# Understand Back Office Background Operations ### Understand Back Office Background Operations ### Overview This guide will help you identify which background services may run while Back Office is open and monitor them without starting duplicates. Background work has visible ownership, evidence, and safe manual-intervention rules. ### Who can do this You need access to Relevant settings/status access; operational permissions vary by service. ### Before you start Know active company, enabled schedules, last runs, external endpoints, backup path, offline/e-commerce state, and maintenance window.
Before saving, check that the correct company is open and that you have permission to complete this task.
### Where to find it Back Office workspace, notifications, service-specific settings/inquiries, and authorized logs. ### Understand Back Office Background Operations #### Step 1: Inventory enabled background features and their owners #### Step 2: Record configured schedules and last successful results #### Step 3: Avoid overlapping manual work with an active background run #### Step 4: Monitor notifications, logs, external IDs, files, and transaction counts #### Step 5: Classify partial or unknown outcomes before retry #### Step 6: Disable only through approved settings when maintenance requires it ### Check your work Each enabled operation has a known cadence, one active execution path, a last-success record, and reconciled output.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Do not assume closing one child form stops all Back Office services. - Preserve evidence before restarting after an unknown outcome. ### Related guides - [Monitor Automatic Backups and Retention](https://docs.muhasiberp.com/link/286) - [Synchronize E-Commerce Orders](https://docs.muhasiberp.com/link/268) - [Monitor Automatic Offline POS Synchronization](https://docs.muhasiberp.com/link/273) ### What to do next
[**Monitor Automatic Backups and Retention**](https://docs.muhasiberp.com/link/286).
# Integration Monitoring and Recovery Find failed external operations, protect successful work, and retry only the failed part. # Recover from Tax Submission Failure ### Recover from Tax Submission Failure ### Overview This guide will help you resolve a rejected or unknown tax submission without duplicating the local sale or authority invoice. 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 submission reaches a known, reconciled state or is escalated with complete evidence. ### Who can do this You need access to Tax inquiry/retry and source-sale correction rights, with tax-owner approval. ### Before you start Preserve local document, request ID, response, timestamp, payload hash/sanitized evidence, provider query result, and current stock/payment/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 the source sale, tax/FBR report, response/history, and authorized retry action. ### Recover from Tax Submission Failure #### Step 1: Classify failure as local validation, no request sent, rejected, accepted Classify failure as local check, no request sent, rejected, accepted but not stored, or unknown. #### Step 2: Query authority status using the original reference where supported #### Step 3: Do not retry accepted or unknown submissions blindly #### Step 4: Correct only rejected validation/mapping data through authorized source workflows #### Step 5: Retry one eligible failed submission once Retry one allowed failed submission once. #### Step 6: Reconcile provider and local state, then document resolution ### Check your work One local transaction maps to at most one accepted authority invoice and all local/provider identifiers and totals agree.
Take a moment to check your work before closing the window. This small check can save time later.
### If something goes wrong - Follow current authority cancellation/credit-note rules for an accepted wrong invoice. - Never delete the local sale or response to force a retry. ### Related guides - [Diagnose an External Integration Failure](https://docs.muhasiberp.com/link/257) - [Review FBR Tax Transactions](https://docs.muhasiberp.com/link/281) - [Correct or Reverse a Customer or Agent Transaction](https://docs.muhasiberp.com/link/214) ### What to do next
[**Diagnose an External Integration Failure**](https://docs.muhasiberp.com/link/257).