# 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).