{"id":32965,"date":"2026-10-19T07:03:22","date_gmt":"2026-10-19T07:03:22","guid":{"rendered":"https:\/\/inspurtech.com.my\/?page_id=32965"},"modified":"2026-10-19T07:03:24","modified_gmt":"2026-10-19T07:03:24","slug":"autocount-support-request-version-plugin-example","status":"publish","type":"page","link":"https:\/\/inspurtech.com.my\/zh\/autocount-support-request-version-plugin-example\/","title":{"rendered":"How to Prepare an AutoCount Support Request Without Sending Your Whole Accounts Database"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

How to Prepare an AutoCount Support Request Without Sending Your Whole Accounts Database<\/h1>

A clear request starts with the failed task<\/h2>

An AutoCount support request should identify the product and deployment, the action that failed and the result you expected. Start with a small description and a sanitised example. Sending an entire accounts database is not the default first step.<\/p>

This article explains how to prepare a support brief. It does not prescribe a universal menu path, certify plugin compatibility or give tax advice. AutoCount desktop products, Cloud products, releases and licensed modules must be distinguished.<\/p>

\"How<\/figure>

Record the product and environment<\/h2>

Write down whether the issue concerns Accounting, Payroll or another product, and whether the environment is desktop or Cloud. Include the version or build available to the authorised user, the relevant module and any plugin involved. Do not substitute a Windows version for the application version.<\/p>

Also explain whether one user or several users see the problem. A report that differs for one login and a document that fails for everyone deserve different follow-up questions; neither observation alone proves the cause.<\/p>

Describe expected and actual results separately<\/h2>

Use three short statements: what you selected, what appeared and what you expected. For a report question, name the report and the agreed reporting period. For a document question, identify the document type without publishing customer names or financial values.<\/p>

Where a screenshot is useful, remove confidential information first and preserve the visible error text. A screenshot with no explanation can leave the support person guessing about both the task and the business expectation.<\/p>

Treat a plugin as a distinct dependency<\/h2>

Record the plugin name, its supplier if known and the task it performs. Explain whether the problem also occurs in the standard workflow. Do not disable production plugins, alter accounts data or install an update simply to complete the support brief.<\/p>

A proposed plugin change needs its own scope: affected fields, a sample input, the expected output and an approval owner. Availability of an integration concept does not establish that a particular version can use it.<\/p>

Agree secure access and acceptance<\/h2>

If closer investigation needs a backup or remote access, agree the authorised contact, secure transfer route and data scope before sharing. Keep passwords and customer records out of public comments and group messages.<\/p>

Finally, identify who can approve the business result. Technical support can examine software behaviour, while accounting treatment and statutory submissions need the appropriate business or professional approval. INSPUR TECH can discuss AutoCount support and plugin requirements against the actual installation; compatibility, work scope and pricing remain subject to assessment.<\/p>

Preparation checklist<\/h2>