CodeCanyon M-Store - WordPress Plugin

A Practical Guide to CodeCanyon M-Store: Managing Multiple Locations Without Inventory Confusion

This guide to CodeCanyon M-Store will help you determine whether the system fits your sales model, prepare a separate environment for recordkeeping, build a clear model for products and locations, configure sales and installment-payment controls, and verify the numbers before real operations begin. This is not a guide to installing another module in a website dashboard: M-Store is delivered as a standalone PHP and CodeIgniter web application with a MySQL database, so the practical path starts with the server, database, and staff procedures rather than the Plugins section in WordPress.

This distinction matters for more than terminology. If you mistake the application for a WordPress plugin, it is easy to begin with the wrong actions: look for a ZIP file in the site menu, enable it alongside a theme, or expect a catalog to appear automatically on the public-facing site. M-Store serves a different purpose. According to the product listing, it includes accounting, invoicing, data analysis, multi-store management, purchasing, and installment sales. That makes it closer to an internal system for a retail business than an online storefront.

Below, we will cover not only the initial launch sequence but also the approach to a safe rollout: from a unified product catalog to reconciling activity by location, from an installment-payment arrangement to verifying that a report does not create a false sense of precision. Where public materials do not confirm the exact name of an interface item, this guide uses a clear operating principle rather than inventing a menu path. Before taking action, always compare it with your own package and its built-in documentation.

What the System Controls and Where Its Scope Ends

CodeCanyon M-Store is intended for businesses that have products, purchasing, sales, and more than one location, and whose owners want to view that chain in one system. The product listing explicitly identifies the application as a PHP solution built on CodeIgniter and lists PHP and MySQL among its technology requirements. Its stated feature set includes multiple stores, accounting functions, invoices, analysis, purchase orders, and installment sales. It is more useful to view these features not as a list of buttons, but as connected parts of one operational process.

For example, receiving a product affects more than the inventory balance. It is normally preceded by a supplier and a purchasing decision. Receiving creates a movement record. The item then becomes available at the selected location. A sale changes the available quantity and creates a financial record. If the customer pays in installments, the outcome cannot be assessed solely by one day's revenue: you need to see the obligation, payments received, and overdue items. The system is useful when these relationships are supported by disciplined source data.

Do Not Confuse Recordkeeping With a Website Storefront

WordPress and M-Store can serve different purposes within the same business. A WordPress site can present products, attract visitors, and collect inquiries. M-Store can serve as the internal source of employee transactions. A public website does not automatically become an inventory system, and an accounting application does not automatically become an online store. The publicly available M-Store description does not confirm built-in synchronization with WordPress, WooCommerce, POS hardware, marketplaces, or banks. Do not build those connections into your process until you have verified the contents of your specific package and the developer's documentation.

A practical way to use both systems together is to keep content and inquiries on the website while a manager creates or confirms the transaction in the internal system under an approved procedure. This is slower than promised "automation," but it prevents invisible duplicate entry during the initial rollout. Once a technical data exchange is confirmed, test it first on a database copy and with a few sample products. There must be one source of truth for inventory; otherwise, two dashboards can show plausible but conflicting numbers at the same time.

What Types of Businesses This Model Fits

The system can suit a retail network with several physical locations, a small wholesaler that fulfills orders from different sites, a trading company with a central warehouse and branches, or a business that needs separate control over installment transactions. Its impact is especially noticeable when employees previously maintained inventory in separate files and only discovered a shortage after promising an item to a customer. In that situation, M-Store becomes more than a place to enter sales: it becomes a shared queue of confirmed changes.

• One product catalog is used across multiple locations, while each location needs its own available inventory.
• Purchases and sales must be tied to documents, not verbal agreements between employees.
• Installment sales need separate monitoring, because goods delivered and money received may occur at different times.
• The owner needs a regular overview of movements, sales, and data rather than a manually assembled month-end summary.

This model has a cost: it cannot be introduced casually. You need to assign ownership of reference data, define when a document is posted, and agree that employees will not rewrite history for convenience. Without that agreement, any recordkeeping system becomes little more than a polished interface over chaos.

When a Different Approach Is Better

Do not start with M-Store if the task is limited to publishing a catalog on one WordPress site and does not require internal management across multiple locations. It is also a poor choice for a team that critically needs a confirmed, ready-made integration with a specific online store, cloud POS system, or delivery service when the package contains no description of such an exchange. In those cases, first look for a solution with documented integration rather than trying to connect unrelated systems manually.

Caution is also needed when deploying on a modern server. The product listing states compatibility with PHP 7.x and MySQL 5.x-8.x, while its publicly listed update date is not recent. This does not prove incompatibility with a newer environment, but it does mean something else: before moving real data, you must run an isolated test on your own hosting environment. Do not enable an untested archive on a production domain, and do not assume that an older PHP version is acceptable simply because it appears on the listing.

Recordkeeping Rules Come Before Fields and Documents

The main mistake when implementing multi-location recordkeeping is creating hundreds of product records immediately. During the first few hours, that can look productive, but within a week you may find duplicates, inconsistent units of measure, and uncertainty about where inventory is actually held. First, define which events change the data and who is allowed to confirm them. Only then should those rules be translated into reference data and documents within M-Store.

A useful minimum chain looks like this: a purchase confirms the intent to receive goods; receiving confirms the actual arrival; an internal transfer changes the place of responsibility; a sale reduces availability at a specific location; and a return or adjustment does not erase history but creates an understandable reverse movement. Installments add a second layer: after goods are delivered, a schedule for receiving payment begins. If the team cannot identify the source document behind any change, the inventory report cannot be treated as evidence.

Launch rule: do not allow employees to both "fix the inventory" and "sort it out later." Record the reason first, then create a document with the date, location, responsible person, and comment. This leaves an audit trail for reconciliation rather than hiding the problem.

Preparing the Server and Team Before the First Launch

Preparation for M-Store has two equally important parts. The technical part confirms that the application can run on the selected server. The organizational part defines which data employees will regard as correct. You cannot solve the second problem by installing an archive, and you cannot solve the first by creating an attractive product table. If either layer is skipped, the first business day will turn test figures into a disputed source of information.

The public product listing confirms that the package includes PHP, CodeIgniter, MySQL, JavaScript, HTML, CSS, and SQL. This implies a basic arrangement: the web server passes requests to the PHP application, which uses CodeIgniter configuration and stores operational data in MySQL. Before deployment, get the hosting administrator's specific constraints rather than relying on the vague statement that "PHP is supported." Important details include the PHP runtime version, the mysqli extension or other database driver in use, the ability to create a separate database and user, permissions for required directories, backup procedures, HTTPS, and error logs.

Technical Readiness Checklist

Prepare a separate test hostname or isolated directory that cannot accidentally be used by employees or customers. Create a new empty database and a dedicated database user with only the permissions required for that database. Do not use a shared server account or send its password through messages. The production password should be unique, and access to the hosting panel should be restricted.

Next, determine which installation document is included in the archive. Public materials confirm the technology stack but do not show the exact folder layout of your package. Do not invent an import path or replace the author's instructions with a generic recipe. Locate the guide file, requirements list, SQL dump, and configuration template in the archive. Before importing anything, save the original unextracted copy in protected storage. It will be useful if you need to compare local changes with the supplied package.

1. Document the environment: the domain or test subdomain, database host, PHP version, backup method, and responsible administrator.
2. Create a separate database and user: the database should not be the same as the website database unless the architecture requires it and a qualified specialist has confirmed the design.
3. Inspect the archive before launching it: it should contain application code, SQL data, and a clear installation guide or support instructions.
4. Define restricted access: while the system is being tested, search crawlers and ordinary visitors must not see the login screen, customer data, or reports.
5. Assign backup ownership: this person must be able to identify the location of the latest database copy and explain how to restore it on a test environment.

CodeIgniter 3 recommends configuring the base URL and database settings in its configuration files, and its security guidance recommends exposing only the public entry point and static resources to the web. For M-Store, this means checking the configuration after extraction: confidential files and backups must not be accessible through a direct browser address. Ask the administrator to enforce this through server configuration, not merely by relying on an obscure folder name.

Rules to Agree on With Staff

Before the technical installation, hold a short working meeting. Its outcome should not be a presentation but several agreements that can be applied the next day. First: what counts as a product and how its SKU is constructed. Second: whether the same item can be held in different places. Third: who creates receipts, who may confirm a sale, who handles returns, and who enters adjustments. Fourth: when an installment sale is considered completed and who monitors the next payment.

Document exceptions in a separate list. For example, damaged stock must not silently disappear from availability. A return without a source document should not become an arbitrary inventory increase. A transfer from a central warehouse to a store is not a sale and must not change revenue. A partial payment is not the same as full payment. The earlier these definitions are agreed upon, the less temptation there is to "make the numbers fit" when a report shows an unexpected figure.

A Permission Matrix Without Unnecessary Detail

The public description mentions users and management but does not disclose the exact role model for the specific version. A safe starting point is therefore the principle of least privilege. A cashier does not need database settings or global reference data. A warehouse employee does not need the ability to delete financial documents. A manager may need to view reports but should not automatically be allowed to change past transactions. The technical administrator is responsible for installation and backups but does not need to enter daily sales.

If the M-Store interface offers predefined roles, first compare them with this matrix using test accounts. If the roles are too broad, reduce access or adjust the process so that risky actions require additional review. Do not give everyone one shared "administrator" account: if a discrepancy appears, it will be impossible to determine where the transaction came from.

After completing the matrix, run one simple test: have a person with a restricted role sign in and process an ordinary transaction. Then try opening configuration, deleting a past document, or viewing another person's financial section. The outcome should be predictable. If access is broader or narrower than the process requires, correct permissions before loading the real catalog.

Installing CodeCanyon M-Store as a Standalone Application

Installation is not a single "enable" action. It is a sequence in which every stage has a verifiable outcome. Refer to the guide included with your package for the exact file and screen names. The steps below provide a safe approach consistent with a typical CodeIgniter application deployment using MySQL, but they do not replace the developer's instructions. They do not cover purchase, keys, or licensing; they concern only launching an existing package in a prepared environment.

1. Deploy the code in the test area. Place the application files where the web server can serve the entry point, while keeping configuration and internal directories inaccessible directly.
2. Import the initial data structure. Use the SQL file supplied with your package in a new empty database. Do not import it over an existing production database or mix it with WordPress tables.
3. Enter connection settings. In the supplied configuration, specify the database name, dedicated user, password, database server, and application address. Do not publish these values in an article, screenshot, repository, or shared chat.
4. Configure the base URL and environment mode. The address must match the actual test-site domain. A detailed error screen must not be visible to ordinary users.
5. Open the initial screen over HTTPS. Confirm that the browser shows no warnings and that the application does not redirect to an incorrect path.
6. Sign in using a test account only. Do not reuse production passwords in testing, and immediately replace any demonstration data that may have been included in the package.

During import, it is useful to keep a log: date, environment, backup name, person performing the work, sign-in result, and issues found. This does not need to be a complex system. A protected document is enough if it makes clear which database can be removed after testing and which one must not be touched. It is especially helpful when the project is revisited weeks later and no one remembers which environment was only a trial.

Post-installation check: a successful login screen does not prove readiness. Create a test product, open it at the required location, run a test transaction, sign out, and sign back in with a restricted role. Only when the data persists, permissions behave as expected, and a backup can be restored to a separate database should the environment be prepared for migration.

A Unified Catalog and Multiple Locations: The Foundation of Reliable Inventory

After installation, do not rush to load the entire product catalog. In multi-location recordkeeping, a product record has a longer life than an individual sale. An error in its name, unit of measure, or SKU spreads through receipts, transfers, invoices, and reports. The first real M-Store configuration step should therefore not be a report or an attractive dashboard, but a small reference set of data on which the team can test its rules.

Create three to five products that the company actually sells, but do not use real inventory balances or customer data. For each product, define a clear name, internal SKU, unit of measure, base price or pricing rule, allowed locations, and minimum stock level if that option exists in your package. If the product has variants such as color, size, or packaging, decide in advance whether they are separate items. You cannot track one part of the assortment "by boxes" and another "by units" without defining how one converts into the other.

A SKU Is a Reconciliation Key, Not Decorative Code

A good SKU does not need to look attractive to a website visitor. Its purpose is to distinguish one specific tracked item unambiguously from another. One product name may have two package sizes, two dimensions, or two purchase batches with different terms. If they differ physically and financially, record the distinction in the product record and labeling from the beginning. Otherwise, an employee may sell "the same product" while the system cannot show which inventory balance was actually reduced.

Do not overload a SKU with information that changes frequently. A code such as TSH-BL-XL can be useful if the team consistently understands its structure. But if the assortment changes often, continuity and the absence of duplicates matter much more than trying to encode the entire supply history in one identifier. Store the scheme description separately: which symbols represent the category, variant, packaging, and when the code is assigned. This helps a new employee avoid creating a second product record with an almost identical name.

Location, Warehouse, and Area of Responsibility

A multi-location setup is useful only when locations reflect actual movement. Do not call every shelf a separate store if staff cannot maintain independent records for it. Conversely, do not combine a central warehouse and retail store into one location if products are moved between them regularly. In the latter case, you will have a total balance but lose the answer to the key operational question: where can the item be handed to a customer right now?

Create a short profile for each location. Specify its purpose, responsible person, access mode, starting recordkeeping date, inventory-count method, and permitted transaction types. The central warehouse may receive purchases and send transfers. A retail location may receive a confirmed transfer and process sales. A service area may hold products that cannot be sold until inspection. This arrangement does not require complex automation, but it makes future reports explainable.

Do Not Confuse Stock on Hand With Availability

Physical stock on hand and availability for sale are not always the same number. An item may be at a location but reserved for a confirmed order, set aside for pickup, awaiting quality inspection, or included in an inventory count. The public M-Store description does not disclose which statuses and reservations are implemented in your version. Determine this first using test data. If no separate status exists, do not imitate it through hidden manual quantity edits. Instead, establish a clear rule for who records a reservation and where, then reconcile it with the physical storage area.

The practical sign of a healthy process is simple: a location employee can state the inventory available for a new sale and explain why it is lower than or equal to the physical quantity. If the answer is "the spreadsheet showed something else," the problem is usually not the report but an undocumented movement or unclear reservation.

Enter Opening Inventory Once, With a Signed Count Sheet

The riskiest moment during launch is transferring opening inventory. It is needed so that the first sale does not make inventory negative, but it cannot be derived by roughly adding up old files. Perform a short inventory count at a selected point in time. At each location, count the products, separate damaged stock from sellable stock, record units of measure, and have the responsible person sign the sheet. Only the approved count sheet should become the source for opening entry.

Do not try to reconstruct the entire store history for years on that day. This often creates an illusion of completeness while bringing old errors into the new system. Enter an agreed snapshot and keep the earlier history as a separate archive. Record all future transactions from the launch date only in M-Store. Then any difference after launch has a limited set of causes: sale, receipt, transfer, return, inventory count, or data-entry error. Those causes can be investigated.

1. Select a cutoff point: for example, after the business day closes, when new transactions are temporarily paused.
2. Count products physically and record the unit of measure next to each quantity.
3. Separate questionable stock: do not mix damaged, unidentified, or set-aside items with available inventory.
4. Approve the count sheet with the location owner and the person responsible for recordkeeping.
5. Load the snapshot into the test environment, then compare selected product records against the count sheet.
6. Repeat the entry in production only after the team understands the method and any discrepancies.

Configuring Operational Workflows After Installation

Detailed M-Store configuration should move from lower-risk to higher-risk areas. Start with reference data, then access, then documents, and only after that move to real payments and reports. The public listing confirms broad functional areas but does not list every on-screen setting. Do not select values simply because they are defaults. In every form, ask: what will this field affect, how can the effect be verified, and how can a test be reversed without losing history?

Reference Data: Products, Partners, and Locations

Start with locations, units of measure, and product groups. Then enter products, suppliers, and customers in the order the team will use them. For a supplier, record more than a name: use a clear identifier, the contact person, working currency where relevant, and the terms required for the purchasing document. For an installment customer, accurate identification and contact details matter, but collect only what the process truly requires and what your company is permitted to process.

Reference data should be protected from uncontrolled improvisation. If every seller can create a new supplier with arbitrary punctuation and create a new customer record for someone already in the system, the records will quickly fragment into duplicates. Assign an owner, set a search-before-creation rule, and agree on how erroneous records are consolidated. If your M-Store version can deactivate a record rather than delete it, that is usually safer for document history.

Documents and the Posting Point

The second configuration layer is the document sequence. Establish when a purchase becomes a receipt, when an internal transfer is considered received, when a sale is final, and who creates a return document. This should reflect what actually happens on the store floor, not merely the desire to close the day faster. A sale entered before goods are handed over may be appropriate only when there is a clear reservation status. If that status is not confirmed, it is better not to complicate the process and to record the sale at the agreed point of delivery.

Prepare a brief check for every document type: is there a date, correct location, counterparty, product, quantity, price, responsible person, and link to a paper source document if the company uses one? In a dispute, you will not need to reconstruct a conversation; you can open the specific document and its supporting evidence. A document number should help locate the original action, not replace an explanation.

Settings You Must Not Enable Blindly

Do not experiment in production with automatic recalculation, bulk adjustments, document deletion, changing the base currency, global tax rules, or broad user permissions. These settings can potentially alter many records or the interpretation of amounts. If your version has such options, first create a short test case in a test database: one product, one location, one transaction, and a known expected outcome. After testing, remove the test database completely or restore it from a clean copy rather than trying to manually erase the traces.

Configuration checkpoint: a system is not ready merely because every field has been filled in. It is ready when an employee can create an ordinary transaction, a manager can see it at the correct location, and the finance owner can understand which amount has already been received and which amount is still expected.

Purchasing, Sales, and Installments: Keeping One Financial Chain Intact

M-Store's stated purchase orders, invoices, accounting, and installment sales cannot be configured as unrelated sections. They describe different phases of one commercial story. When an employee records only a sale, the owner can see turnover but does not know where the product came from, how much money has actually arrived, or whether the customer still has an obligation. When accounting sees only payments without linking them to a specific transaction, it becomes impossible to verify the debt and the goods delivered. Configuration should therefore begin with a clear document flow, not an attempt to fill out the entire financial screen at once.

The Purchasing Flow: From Intent to Actual Receipt

A purchase order records the intention to acquire specific items from a supplier. Its value is that it separates the plan from reality. A supplier may deliver fewer items, substitute packaging, change the price, or divide delivery into several parts. If expected quantity is entered directly into records as received quantity, inventory becomes incorrect before the first sale. Enter an actual receipt only after the responsible person has seen the goods and matched them to the supplier's documents.

A simple operating process includes four roles: the person initiating the need, the person approving the purchase, the person receiving the goods, and the person reconciling the financial side. In a small company, these may be two people, but the steps are still worth separating. This prevents an owner from approving their own delivery retroactively and prevents a warehouse employee from deciding alone which cost should be assigned to the goods.

1. Define the need: which location, which product, what inventory level, and why an order is needed.
2. Create a purchasing document with the supplier, line items, and expected terms, if your package supports it.
3. Receive the goods physically: count the quantity and inspect the variant, packaging, and obvious damage.
4. Record the actual receipt, not the original plan, and specify the location where the goods actually arrived.
5. Reconcile the source documents: compare the receipt, supplier document, and agreement on the amount.
6. Check the product record: inventory changed only at the expected location and by the actual quantity.

If a delivery is incomplete, do not turn it into an "almost correct" document. Record the received portion in the way supported by your process and interface, and keep the shortage visible for follow-up. If the application provides no separate pending status, record the fact in the agreed document and do not increase inventory before physical receipt. This approach is more useful than assuming that "the rest will arrive later."

A Sale Is a Double Check of Goods and Money

Before completing a sale, an employee should check four things: the correct product, selected location, actual quantity, and payment method. This sounds obvious, but it is where the most costly errors occur: inventory is deducted from the central warehouse instead of the store, the wrong size variant is sold, a partial payment is treated as full payment, or a new customer record is created instead of using the existing one. A good interface helps, but it does not remove the need for visual verification.

Create a consistent routine for the cashier or manager. The employee finds the product by SKU or stable name, confirms the location in the document, shows the customer the item details, records payment, and issues confirmation under the company's internal rules. After saving, the employee should not immediately move to the next customer until they see the document number and final total. If a confirmation message disappears too quickly, introduce a temporary check in the transaction log.

An invoice or sales document is useful for more than the customer. Within the process, it joins the product side and the monetary side. Enter the actual counterparty when their obligation must be tracked. Do not use one generic "customer" record for installment transactions, because it will later be impossible to distinguish one payment schedule from another. The rule may differ for ordinary quick sales, but it should also be established in advance.

Installments: Separate Delivery of Goods From the Payment Schedule

According to its stated purpose, installment sales are what distinguish M-Store from a simple inventory list. But this mode becomes useful only when terms are defined strictly. When goods are delivered, a sale occurs. When the first payment arrives, a payment event occurs. The remaining obligation is not "unverified revenue"; it is the amount still to be collected under the transaction terms. If these concepts are mixed, a manager may mistake expected money for money already received.

Before enabling installments, agree on four fields: total transaction value, amount received initially, number or dates of payments, and the responsible person who reconciles incoming payments. Exact scheduling capabilities differ by version, so do not promise customers automatic reminders, penalties, or payment methods until you have seen them in your package. Start with a minimal, verifiable test: one product, one customer, one partial payment, and one expected balance.

Review Card for an Installment Transaction

To avoid mistakes, use a short review record for every such sale. It does not replace the M-Store document; it helps the employee avoid missing important fields. It should match the sale number, customer, product, pickup location, total amount, payment made, balance due, date of the next review, and responsible person. If any line is unconfirmed, do not close the transaction as fully paid.

After the first test transaction, leave the current screen and find it again through an available log, report, or customer record. A transaction cannot be considered completed while it is visible only in the form from which it was just saved. Reopening it the next day is a more honest test: it shows whether the relationship among the sale, inventory balance, and payment was preserved.

Accounting Data and Management Reports Do Not Replace Each Other

The M-Store listing mentions "full accounts" and data analysis, but its public description does not disclose the exact chart of accounts, inventory valuation method, tax treatment, or period-closing rules. Do not make legal conclusions or transfer figures into official reporting until a qualified accountant confirms that the configuration meets the requirements of your jurisdiction. For implementation, something else matters more: understanding which management question each report answers.

A sales report answers a question about completed transactions during the selected period. An inventory report answers a question about products at a specific location. An installment list answers a question about uncollected payments. A financial report may provide a different perspective depending on its settings. Do not expect one metric to answer every question. Introduce regular reconciliation in which the owner reviews these views together and explains major discrepancies through documents, not guesswork.

Practical benchmark: after a test installment sale, three consequences should be visible at the same time: the product is no longer available at the location in the previous quantity, the sale exists as a document, and received and expected amounts are not mixed together. If even one consequence cannot be traced, it is too early to continue the rollout.

Working Example: Warehouse Receipt, Store Transfer, and Installment Sale

The best way to understand how to use CodeCanyon M-Store is not to read another feature list, but to run one connected example from beginning to end. Consider a hypothetical business with a central warehouse and one retail location. The company receives a batch of one popular product, transfers part of it to the store, and sells one unit to a customer with partial payment. This example assumes no hidden automation: its purpose is to show which facts should remain after every action and how to catch an error before it reaches the monthly report.

Before starting, confirm that the test environment already contains two locations, one supplier, one customer, one test product, and user accounts with restricted permissions. Use small sample quantities: ten units arrive at the central warehouse, four units are transferred to the retail location, and one unit is issued to the customer. Set monetary values so employees can calculate them without a calculator. Do not use real personal data or genuine payment details.

Goal and Expected State Before the First Action

The goal is not an attractive demonstration but four matching outcomes. After receipt, the central warehouse should show ten units. After the internal transfer, the central warehouse should show six and the retail location four. After the sale, the retail location should show three. After a partial payment, the sale should exist separately from the customer's outstanding balance. This is simple arithmetic, but it turns the test into evidence rather than clicks through forms.

At the beginning, record the starting state in the implementation log: quantity is zero at both locations, the product has no previous movements, the customer has no unidentified debt, and the supplier has no open test transaction. If the database is not clean, do not continue. You cannot honestly verify a change when the starting point is unknown. It is better to create a new test database from a clean installation file than to search for traces of earlier experiments.

Step 1. Receive the Batch at the Central Warehouse

Create a purchase document or receipt transaction using the form available in your version of M-Store. Select the central warehouse, supplier, and test product. Enter the quantity actually received: ten units. If the supplier delivered nine and promised the tenth later, do not enter ten "for convenience." You are testing not the ability to complete a form but the system's ability to reflect reality.

After saving, open the transaction list and the product record from another screen. The central warehouse should show exactly ten units. Confirm that the entry did not land in the retail location because of an old default value. Then ask a second employee with a restricted role to open the record without edit permission. They should see evidence of the receipt but should not be able to silently change the number. If the package in use displays a document number, record it in the scenario log.

Step 2. Transfer Four Units to the Retail Location

An internal transfer is not a sale and must not create revenue. Its purpose is to transfer responsibility and product availability from one place to another. Create a transfer document for four units from the central warehouse to the retail location. At this point, it is especially useful to agree on your procedure: does stock become available at the receiving location immediately after dispatch, or only after receipt is confirmed? Do not invent an interface status if one does not exist. Describe the actual rule in the operating procedure and make sure all employees follow it.

After confirmation, review the source location first and then the destination. Six units should remain in the central warehouse. Four should appear at the retail location. The total across both locations for this product remains ten. If the total inventory changes rather than only the distribution, the transaction was not posted as the process expects. Do not hide this with a new adjustment: open the document, check the source location, destination location, and quantity, then reverse or correct the transaction using the method provided by your version.

Step 3. Make the Sale From the Correct Location

Sign in under the test retail-employee role and start the sale from the retail location itself. Find the product by SKU or stable name, select one unit, and choose the customer from the prepared record. Before saving, check the location once more: if the employee accidentally works in the central warehouse context, all later reports may look reasonable in total while being wrong by distribution.

Record the total transaction value and the amount the customer pays now. There is no need to explain M-Store's own payment process here; this concerns only the installment-sale capability stated in the application listing. The document must show the goods issued and must not present a partial payment as a closed balance. If the screen does not allow these states to be distinguished, or if you have not found a confirmed procedure, stop the experiment and clarify it with the package author. Do not replace unknown behavior with a manual change to the inventory figure.

Step 4. Recheck at Three Levels

Verification now takes place outside the same window, using independent views. First, open inventory for the retail location. The expected quantity is three. Next, find the sales document. The product, quantity, customer, and total must match. Finally, go to the available debt, payment, or customer view and confirm that the amount paid is not the same as the remaining balance. Field wording and placement may differ, so verify the meaning rather than button names.

If any view does not match, return not to the report screen but to the first document where the discrepancy appears. For example, inventory did not decrease but the sale exists. This may indicate an unconfirmed status, an incorrect location, or an issue in the behavior of your package. If inventory decreased but the sale cannot be found in the list, the problem is not solved merely because the item disappeared. A document is required, otherwise the financial side of the transaction is lost.

Scenario Verification Table

After successfully completing the example, repeat it with one deviation. For example, try to sell five units from a location that has only four, or apply payment to another customer. The purpose is not to look for loopholes but to understand the response of the system and the process. If the application does not block an obvious error, the operating procedure must compensate with an additional manual check. If it does block the action, document the rule in staff training so employees understand the message rather than trying to bypass it with repeated entry.

Verifying the Outcome: Turning Data Into a Management Decision

When the test flow works, the next trap appears: the team begins to trust every number on the screen. It is better to treat each report as a question that must be answered with source documents. An inventory figure should be explained by receipts, transfers, sales, and returns. An installment figure should be explained by sales, payments, and the unpaid portion. A location figure should be explained by transactions at that specific location, not by an accidentally selected global filter.

A Short Daily Reconciliation

At the end of the day, the responsible employee only needs to check a small number of signals, but do so consistently. Open the day's transactions, select the location, compare the number of sales with primary confirmations, review new receipts and transfers, then separately open transactions with partial payment. If there is a discrepancy, do not try to "close the day with a nice number." Flag the issue, preserve the evidence, and review it the next morning with the person who entered the transaction.

• Sales: the document exists, the correct location and product are selected, and the amount has not been lost.
• Inventory: changes can be tied to a specific movement rather than an unknown adjustment.
• Installments: a new transaction is not marked fully paid when the money has not been received in full.
• Users: a former or temporary employee does not retain unnecessary access.

A Weekly Reconciliation Without Self-Deception

Once a week, select a small random sample of products and one location. Count physical inventory, find the latest movement documents, and compare them with the number in the system. This does not replace a full inventory count; it is an early warning signal. It helps uncover problems with transfers between locations, incorrect units of measure, undocumented returns, or shared employee access while the error has not yet spread through the entire catalog.

At the same time, review the list of transactions with incomplete payment. For each one, ask: is there an agreed next step, who is responsible, and does the balance in the system match the internal payment confirmation? If the company maintains its own schedule in a separate document, that document number should be linked to the transaction number rather than to a customer name written in different ways. Verification is valuable because it finds exceptions, not because it quickly confirms obvious sales.

Production readiness: three independent people should be able to reproduce one example, explain inventory figures, locate the sale, and distinguish a full settlement from a partial payment. If only the technical administrator can do this, the system has not yet been adopted by the company.

Safe Process Improvements Without Modifying the Application Core

After a successful test, there is almost always an urge to immediately "customize the system." That is understandable, but for M-Store it is especially important to separate changing the process from changing source code. Public materials confirm PHP and CodeIgniter but do not provide a documented list of extensions, events, templates, or safe integration points for this specific version. It would therefore be dishonest to offer an arbitrary PHP snippet, call it an official mechanism, and recommend inserting it into application files.

It is safer to improve what does not require modifying the core first: access control, backups, document discipline, reconciliation templates, and a separate test environment. These measures are useful regardless of the exact interface and survive updates better than edits to supplied files. If you later genuinely need a report, printable form, or data exchange, treat it as a separate development task with a database copy, description of input data, expected output, and rollback plan. Do not call a customization "small" until it is clear which documents and permissions it will affect.

A Backup Must Be Tested Through Restoration

Having a backup file does not mean the business can recover. The database may be incomplete, the archive may be protected by an unknown password, or restoration may require access that was lost long ago. At an agreed interval, restore a backup into a separate test database and try three actions: sign in with a test account, open a recent sale, and view the inventory balance for one product. If restoration fails, the problem already exists now, not on the day of an outage.

Keep code and data separate. Before an update or configuration change, save a copy of the database and the original application archive. After the change, confirm that the previous copy is stored separately from the server you are modifying. Never download a backup into a publicly accessible website folder "for five minutes": the path may be indexed, and the file often contains customers and financial transactions. The technical administrator should maintain a list of storage locations and retention periods, while management should have confirmation that restoration testing was actually performed.

Handle Catalog Changes as Controlled Requests

Often the most dangerous "customization" is not technical but manual. A manager asks to change a product name, merge two records, change a unit of measure, or move inventory to another store. Some of these actions are safe only before the first transactions; others can alter the meaning of historical documents. Create a short request form: what will change, why, whether movements already exist, who approved it, and how the outcome will be verified.

For example, if a product was created twice by mistake, do not rush to delete the record with history. First, locate all related receipts, sales, and movements. Then decide whether the extra record can be disabled for new transactions while the correct one is used going forward. Data merging, if it is required at all, should be performed only after making a database copy and testing in a test environment. This approach may seem slow, but it prevents a situation where today's correct inventory balance is achieved by deleting the explanation for yesterday's sale.

Using a Website Alongside the System: A Manual Flow Until Integration Is Confirmed

If the public website is built on WordPress, use it as a separate communication layer until technical integration is confirmed. A product page can contain a description, inquiry form, and fulfillment terms. The employee receives the request, checks availability in the internal system, then creates or confirms an operational transaction according to the approved procedure. This is not an official M-Store and WordPress integration. It is a cautious separation of responsibilities: the website does not publish inventory it cannot synchronize, and recordkeeping does not depend on page content.

Testing this arrangement is straightforward. Submit a test inquiry on the website, pass it to the responsible employee, create a test transaction in M-Store, and confirm that the customer receives only an approved confirmation rather than a promise of stock before availability has been checked. The rollback is also clear: if the process creates duplicate entry or delays, stop publishing live availability on the website and return to manager confirmation. Do not try to solve the problem by copying the M-Store database into WordPress or directly editing tables without a designed and tested exchange.

How to Train the Team So the System Does Not Become a Second Excel File

A new recordkeeping system fails not when an employee makes one mistake, but when the mistake cannot be noticed, explained, and prevented from happening again. Training should therefore be built around short, realistic workflows rather than a tour of every button. A new employee should be able to find a product, verify the location, perform an authorized transaction, understand their restriction, and report a discrepancy. A manager should be able to open a document from a report. An administrator should be able to restore a test copy. That is enough for the first stage.

Prepare a one-page procedure for each team role. For a seller, this is the sequence for checking the product, location, quantity, customer, and payment. For a warehouse employee, it is receiving, physical counting, transfer confirmation, and discrepancy recording. For the finance owner, it is reconciling the sales document with the amount received and monitoring partially paid transactions. For the manager, it is the daily and weekly questions to ask of the data. Do not include unnecessary screens that a specific role cannot access.

Test Knowledge Through a Reproducible Workflow

After training, do not ask whether "everything is clear." Give the employee a test product and a specific task: receive two units into the warehouse, transfer one to the store, make a sale with partial payment, and show where the outstanding balance can be seen. The observer should not prompt button names. If the person gets confused, it is not necessarily an individual mistake: the instructions may be missing a required rule, or the interface may allow an action without location context.

Record questions that appear twice. They almost always point to a process gap. For example, employees may not understand how to handle a returned partially paid purchase, how to record damage in the store, or what to do during an internet outage. Do not invent an answer on the spot. Document the case, determine which document is the source of truth, test the procedure on a database copy, and only then add the solution to the operating procedure.

The First Month After Launch: What Management Should Monitor

During the first weeks, do not evaluate implementation solely by the number of completed documents. It is much more useful to track the number of unidentified adjustments, duplicate product records, partially paid transactions without an owner, transactions at the wrong location, and cases where a physical count differs from the system. These indicators show process quality. If they are increasing, do not add more reference data and features. Stop, investigate the root cause, and simplify the action employees perform every day.

Also preserve the boundary between management information and legally significant reporting. M-Store may help management see transactions and outstanding balances, but tax configuration, charts of accounts, and mandatory reporting require separate professional assessment for the relevant country and business. Do not present a convenient internal report as an accounting conclusion until its rules have been confirmed by a specialist and company documents.

When CodeCanyon M-Store Is a Good Choice

M-Store makes sense when you are ready to maintain one disciplined view of product movement across multiple locations, connect receipts, sales, and financial documents, and monitor partially paid transactions separately. Its strength lies in the stated combination of multi-store recordkeeping, purchasing, invoices, analysis, and installments. Its limitation should also be accepted in advance: it is a standalone CodeIgniter application, not a WordPress plugin, and the public listing provides no basis for promising seamless integration with a website, POS system, or external services.

A sensible decision looks like this: deploy an isolated test environment, create a small reference catalog, run the example described above, and confirm that the team can explain every change. Only then move the agreed opening inventory and gradually enable locations. If testing reveals server incompatibility, unclear installment behavior, or a critical gap with your online store, that is not a failure. It is a useful outcome obtained before real data was put at risk.

Once the test flow is complete, the backup restores successfully, roles are separated, and reports are supported by documents, you can get the WordPress version and continue deployment in your controlled environment. Save the original archive and rollback plan first, then enter data by location using the approved cutoff date. This way, the solution will help manage products and obligations instead of adding another unclear spreadsheet to daily work.