English installation, configuration and practical user guide · Buyer-hosted control panel included
Bahar Plastic Factory Desktop & Web Management includes the original factory workspace and its buyer-hosted AppAdmin control panel. The desktop edition supplied here runs in a desktop browser or an installed browser PWA. The source ZIP does not include a native Windows EXE, Android APK, iOS IPA or Mac binary. Existing design, forms, stock and receivable formulas, five language choices and voice engine have been retained.
An owner can approve, block and monitor access for registered devices across their installations using their own controller. Business records remain on each browser/device. This is centralized ACCESS management, not centralized factory accounts, cross-branch stock synchronization, a consolidated multi-company balance sheet or staff roles/permissions. The Workers module is an operational employee register; it is not a role-management system. Device rows and app names identify connected installations; they do not upload production, sales or customer ledgers.
The original client login stores a salted SHA-256 password verifier in that browser's local account storage. The controller uses its own PHP administrator password hash and session/remember cookies. Local client login is a browser workspace gate, not encryption or a tamper-proof enterprise security boundary. Someone with access to browser developer tools or an unlocked computer can read or alter local storage. Use trusted devices, OS accounts and private backups. Never advertise the local database as centrally protected or encrypted.
Use HTTPS hosting, Apache 2.4, PHP 8.1 or later, PDO SQLite, writable controller storage and PHP sessions. Optional Azure speech requires PHP cURL and outbound HTTPS. Optional Web Push requires the bundled Composer dependencies and supported PHP OpenSSL/browser push capabilities. The controller interface also uses online assets; test internet connectivity. Current Chrome/Edge desktop or Android, Firefox and Safari support varies by feature.
Upload CONTENTS of source/ into an empty document root or new subfolder, for example public_html/factory/. Preserve hidden .htaccess files. The factory opens at /factory/ and the controller at /factory/controller/. Do not overwrite an existing installation first. The original hosted author's apps and account databases are not part of the sale package.
Typical permissions: directories755, ordinary files644. Grant only the PHP account necessary write access to controller/ for app_database.db; never use777. Apache must reject direct downloads of that database, journal/WAL/SHM files, private/ and controller configuration/vendor files. Before entering personal data, verify protection using a harmless test file or the temporary SQLite database created by first setup. A request for controller/app_database.db must return403. If your server ignores .htaccess, configure equivalent deny rules first. On Nginx, deny /factory/private/, /factory/controller/vendor/ and controller database/configuration filenames; do not assume Apache rules apply.
The main ZIP includes START-HERE.txt, English documentation, editable source, original image assets and the bundled controller dependencies. Keep the full ZIP, server backups and configuration outside publicly downloadable directories. No author password, existing device database or Azure speech key is included.
Open /factory/controller/ immediately after installation, before advertising the URL. The ORIGINAL administrator setup screen asks you to create and confirm your Admin Password. Use a unique long password and complete setup yourself. The first setup claims control of this new controller; protect the staging URL or keep it unpublished until this is complete. There is no supplied default admin password or author master password.
The controller stores a PHP password_hash verifier. Subsequent visits use the existing Login screen. Its original persistent remember-cookie behavior remains, so log out on shared computers. Back up the server-side SQLite database privately; never distribute an initialized production database to buyers or staff. The panel's existing password management and authentication behavior are retained. Recovery must be performed by the hosting owner using a private verified backup or reviewed maintenance process.
The optional mobile-gate deployment helper is not required for this bundled installation: app.html already includes the local script. The helper requires an authenticated administrator and CSRF verification in this package. Review its target directory and back up source files before applying it to additional installations. It modifies entry files; it is not a business-data synchronization tool.
In the factory Login screen choose Register. Enter name, username, mobile, optional email, password and confirmation. The original mobile validation expects a Bangladesh-style11-digit01 number; it is not a worldwide phone validator. Password minimum is the original6characters. Use a stronger password in practice. Registration stores a local browser account and attempts to send identity/device metadata to YOUR controller. The original Paid policy blocks new Full access by default: first choose Staff Preview (original Demo Login) to enrol the device in the panel. This is the existing access-policy workflow, not an installation error.
Open the controller in an administrator browser. Find the corresponding device using its serial, app name and user details. Inspect whether it is Pending, Approved, Active, Paid/Full, Demo or blocked according to the panel's existing controls. Select Move to Paid / enable Paid for the intended Demo device in the panel. Return to the factory and choose Officer Login (original Paid/Full Login) with the locally registered username/password. If this creates a separate Pending Full serial, approve that Full row in the panel and repeat Officer Login (original Paid/Full Login). Merely selecting Active without granting the Paid policy is insufficient. Confirm the device passes both the access policy and its device approval. Paid labels describe the owner's access policy; there is no automatic online checkout or payment gateway in this package.
For Staff Preview (original Demo Login) the original client collects name/mobile and reports to the controller. Its existing demo fallback can permit local demo access when the controller is temporarily unavailable, except explicit blocked/inactive responses. Do not present Demo as an enforced offline security boundary. Full access periodically checks controller status. Token resets or device bans should be used carefully and verified by logging in again on the affected test device. Ban/approval state does not erase business records.
Changing browser profile, clearing local storage or moving to another device can require registration and approval again. Do not overwrite a local account casually: one browser account context is retained, rather than a server account directory shared across devices. A username alone does not transfer a factory database.
The login screen buttons are Officer Login, Staff Preview and Admin Panel. Officer Login retains the existing full-access login. Staff Preview retains the password-free demo behavior and is NOT a subordinate account with restricted permissions. Admin Panel opens the separate password-protected owner controller. These labels do not add staff roles or a permissions system.
Keep one controller under the owner's hosting. Each factory/branch should have a distinct HTTPS origin, preferably separate subdomains, so its local browser data is isolated. Different folders on the same origin share the application's IndexedDB name and local account keys; folders alone DO NOT isolate factory data in one browser profile. Alternatively use separate browser profiles and maintain clear backup naming. Do not claim multi-tenant data isolation from a shared folder arrangement.
For the included single deployment no controller URL editing is needed: control-proxy.php invokes the bundled controller. To connect a separate factory deployment to a shared controller, edit server-only private/controller.php base_url to the owner's controller HTTPS URL without a trailing slash. In public buyer-config.js set controlBaseUrl to that same HTTPS controller path with a trailing slash for the mobile gate. Configure appName to a distinct descriptive name such as North Factory Plastic Management. No password or secret belongs in buyer-config.js.
Create/register a test device at the new factory and confirm it appears under the correct app name in the controller. Approve it, test full login, test status updates, then test a temporary ban and re-enable. Conduct this on a disposable test device before enrolling staff. Each branch exports its own business JSON; the controller's device history does not contain that branch's sales ledger. Source license scope and permitted installations depend on the license purchased through the marketplace.
The original application includes sample master records and transactions on first use. Practise in a separate test browser profile. Before replacing anything, use Backup and preserve the JSON. Blank-Workspace.json is provided only for a new installation: Restore REPLACES the complete current local business state. Do not restore it over unbacked-up real records. It does not reset the controller administrator password or the browser's registered login account.
Settings lets you change business name, tagline, owner, phone, WhatsApp, email, website, address, trade license, invoice note, logo and stock thresholds. Save, reopen Settings and confirm the changes. Replace the original sample contact details before handing the installation to staff. The author-hosted website links have been replaced with local documentation/configurable buyer URLs.
Create Raw Materials, Products, Suppliers and Customers before transactions. Raw Materials and Products have Opening Stock fields. Example: PP granules opening1000kg and buckets opening100pieces. Use the quantity actually counted at your cutover date. Do not also add a purchase/production row for the same opening stock. There are no dedicated opening customer/supplier due fields or opening cash/bank ledger. Keep pre-cutover receivables/payables and cash balances in a reviewed external schedule; do not invent new-period sales to hide an opening balance. If these opening financial ledgers are essential, a separately reviewed enhancement is needed.
Raw Materials → Add records code, name, category, unit, opening stock, minimum stock, colour/grade and note. Keep units consistent. The production form labels raw consumption as kilograms; if you choose grams, bags or litres for the material master, convert quantities consistently yourself. There is no automatic bag/gram/litre conversion.
Create suppliers, then Raw Purchases → Add. Select the material and supplier; enter invoice/date, quantity, rate, paid and note. Example: purchase500kg at120 gives Total60000. Paid40000 gives invoice due20000. Saving increases calculated raw stock by500. Total is calculated as quantity×rate. Later supplier payments belong in Payments with type Supplier and the correct supplier ID; do not also increase the original Paid for the same payment.
Raw Stock = OpeningStock + PurchasesQty − ProductionRawUsed. With opening1000, purchases500 and production consumption200, stock is1300kg. The displayed average purchase rate is a weighted rate from purchase rows only; it does not value opening stock separately. Check supplier invoices, weighing records and cash receipts before saving. Negative stock, duplicated invoice references and inconsistent quantities are possible in the original forms and require operator review.
Products → Add records product code/name, category, unit, opening stock, minimum stock, sale price, optional photo and note. Product photos are stored with local business data and enlarge backups. Machines and Workers should be entered before production if you want useful references. Machine/service dates and worker details are operational records, not automatic payroll or maintenance billing.
Production Batches → Add. Choose product, machine and one raw material; enter batch number/date, raw used, GOOD production quantity, reject quantity, waste kg, shift, operator and note. Example: raw200kg, good400pieces, reject10pieces, waste7kg. These are separate measurements, not automatically convertible mass/quantity totals. Good400 increases product stock by400; raw200 reduces raw stock by200. Reject10 is descriptive and is not subtracted again from good400. Do not enter gross output in the Good field and expect rejects to be deducted automatically.
Finished Stock = OpeningStock + GoodProductionQty − SalesQty. Opening100 plus good400 minus sales150 gives350pieces. The original batch supports one selected raw material; it does not expand a multi-material bill of materials or calculate a production cost automatically. Editing/deleting a batch changes derived stock immediately. Reconcile records with signed shift reports and physical inventory.
Quality Control records batch/product checks and inspection outcomes using the existing form. Record the inspection date, checked quantity, accepted/rejected results and notes accurately. A QC entry is an inspection record; it does not automatically rewrite the production batch or deduct another stock quantity. Correct the source production record separately if the recorded good output was wrong, preserving an explanation and backup.
Waste / Recycle records waste material/quantity, recycled quantity and notes. It supports operational waste reporting. Waste/recycling entries do not automatically return recycled material to Raw Materials stock. Likewise, the production waste field is separate from the Waste module; do not assume both are one automatically linked posting. Keep a reconciliation sheet to avoid counting the same waste twice in reports. Review the recycled-input treatment with your stockkeeper before entering any manual source adjustment. There is no dedicated stock-adjustment ledger or automatic yield-loss accounting engine.
Create the Customer and select the correct product in Sales → Add. Enter invoice/date, customer, quantity, rate, Paid and note. Example:150pieces×80=12000 with Paid7000 leaves5000 for that customer before later collections. Sales immediately reduce product stock; there is no separate delivery confirmation step. A sale does not create a production batch or reserve raw material.
Use Payments → Add for later customer collections. Choose Customer type and the matching customer, enter amount/method/date and note. A later2000 collection reduces the5000 balance to3000. Do not also change the original sale's Paid to9000 for that same receipt. Customer Due = sum(SalesTotal−SalesPaid) − customer collections. Supplier Due uses purchase totals/paid minus supplier-payment rows.
The party selector contains both customers and suppliers; match the Type and the party correctly. The original form does not enforce every combination. Negative due values can represent overpayment/credit and are not automatically floored to zero. A customer's previous debt is not inferred from their name or notes. Reconcile linked IDs, invoice totals and actual receipts. The Print action uses the current browser printing workflow; this is not a certified tax invoice/VAT compliance system.
Expenses records category, description, date, amount and notes. Examples: electricity6500 and overtime2200 give total expenses8700. Worker wages, machine service dates and electricity quantities do not automatically create expense postings. Enter the corresponding monetary expense once when appropriate and keep receipts.
The dashboard and Reports sum the existing records. Cash Result = SalesTotal − PurchasesTotal − Expenses. It uses billed totals, not actual cash received/paid, and excludes opening cash, loan flows and separate collection/payment timing. It is an approximate operating indicator, not closing bank balance, double-entry profit or an audited financial statement. Finished-stock value uses product sale price rather than a manufacturing cost valuation. Raw-material value uses the original average-purchase-rate calculation.
At shift/day close compare raw opening+purchases−consumption with physical raw stock; compare product opening+good output−sales with physical finished stock; reconcile customer and supplier dues against receipts. Search for wrong units, duplicate batches/invoices, missing purchases or incorrect party links before correcting records. Back up first. Deleting a linked customer/material/product can leave historical references; the original interface does not provide full referential-integrity protection.
Business branding is changed in Settings, including a company logo upload and reset-to-default option. For full source branding replace brand-logo.webp, login-plastic.webp, brand-icon-192.png, brand-icon-512.png and other supplied icons with artwork you own, preserving size/aspect ratio. Update manifest.webmanifest name/short_name, app title and optional assistant welcome text. Keep original IDs/classes so forms and voice hooks continue working.
Use the five language buttons: Bengali, English, Arabic, German and French. Translation dictionaries are in plastic-i18n.js, with offline-i18n.css handling language presentation. User-entered names/notes are business records and are not automatically translated. Existing translation coverage and source values are retained; some free text and original operational labels may remain in their original language. English is selected as the marketplace default in this package.
The original money function prefixes ৳ and uses Bengali numeric formatting. Language switching DOES NOT convert currency. To customize to USD, a developer can change money(v) in plastic-app.js to Intl.NumberFormat('en-US',{style:'currency',currency:'USD'}).format(num(v)), review any dictionary currency overrides and update labels. This changes presentation only. Do not relabel an existing BDT dataset as USD without a reviewed external conversion and separate backup. There is no built-in exchange-rate engine or multi-currency ledger.
Set supportPhone/supportWhatsApp in buyer-config.js to the buyer's support contact if desired. Leave blank to avoid displaying an external support destination. These public settings contain no secrets. Change appName there to distinguish branches, then clear only the old session and re-register an appropriate test device if the controller's app identity changes.
The original assistant and speech endpoint remain. Default voices are Bengali Nabanita, English Jenny, Arabic Zariyah, German Katja and French Denise. Nabanita is the assistant identity; this configuration does not ship one offline Nabanita model speaking all five languages. Original voice selections and playback logic have been kept.
Configure YOUR Azure Speech key/region in private/azure-speech.php or AZURE_SPEECH_KEY/AZURE_SPEECH_REGION server environment variables. Only PHP should read the key. Never put it in buyer-config.js, screenshots, browser JavaScript or customer ZIPs. Azure subscription/usage costs are separate. The endpoint's optional voices map accepts bn/en/ar/de/fr voice IDs for supported Azure voices. Verify every selected language and region.
The original assistant caches welcome audio. Matching cached welcome audio may play offline. Other page/button speech uses cloud speech online or the browser's available speechSynthesis voices as a fallback. Installed browser voices vary and may sound different. Clearing site cache can remove saved audio. New cloud audio needs internet and a configured service. Browser autoplay may require a user gesture. A five-language interface does not guarantee all five original cloud voices offline.
The retained mobile gate can request name/phone, device identity and location for the buyer's access policy. Browser permission is required for location. Explain this to staff and collect only information appropriate for your organization. Requests now target YOUR controller, not the author's domain. Do not promise that no information leaves the device: account/device/access/status metadata and, where the mobile gate is used and location granted, location information are sent to the controller.
Factory operational records—production, inventory, sales and business ledgers—remain local. Optional Azure speech sends help text and selected language to the speech service. Optional Web Push uses the browser push provider and owner-generated VAPID keys stored in the controller database. Notification permission is optional and must be granted by the browser user. Using a shared controller requires proper administrator access practices and retention/backups for device metadata.
Full control checks require a reachable buyer controller. Browser sessions and cached local data are not erased by a remote ban. Offline/demo fallback behavior is retained and documented rather than silently changed. Users with local computer access can manipulate client data; this product does not offer remote disk wipe, fleet device management, remote desktop control or guaranteed anti-tamper enforcement.
The top Backup button exports the current factory business state as JSON. Store dated private off-device copies. Restore selects a JSON file and replaces the current business state using the original normalization behavior. It is not a merge/sync operation. Back up the destination before restoring. Do not import unknown or partial JSON files into a live business. Check record counts, raw/product stock and both dues after restoration.
A business backup does not automatically transfer browser login credentials/device tokens or the server controller's administrator database. When moving to a new device, register/approve that device separately, restore its intended factory business backup, and compare totals. Back up controller/app_database.db privately through hosting; it contains security/device metadata and must never be publicly downloadable or shipped to a new buyer. Logo/product images can enlarge factory backups.
Each factory/origin needs its own backup schedule. Do not combine files by hand unless a developer validates every linked ID. Clearing browser site data, changing origin/profile or uninstalling a PWA can lose business data and identity tokens. The controller is not a business-data recovery service. Settings Reset returns to the original sample dataset after confirmation and overwrites local business state; it is not a blank-start button.
On a supported HTTPS desktop/Android browser choose Install app from the browser menu. On iPhone/iPad use Safari Share → Add to Home Screen. Capabilities vary. This package's Desktop wording describes browser/PWA use. Native installers, if separately supplied in the future, need their own editable source/configuration and verification against the buyer's controller before delivery.
After source changes increment the service worker CACHE name and test online in a separate browser profile. The service worker deliberately does not cache controller or PHP responses; cached admin pages must not expose an authenticated dashboard after logout. Back up business JSON before maintenance and never clear production storage casually. The source activation/control code has not been removed; its server dependency has been moved to the bundled/buyer-configured controller.
Acceptance checks: administrator setup/login/logout; new device registration; pending response before approval; approved full login; status refresh; ban and re-enable; demo behavior; all five languages; raw/product stock examples; customer/supplier payments; backup/restore on a disposable test profile; private database403; and optional configured speech. Verify additional branch connections separately. Current test evidence is provided in Verification-Report.json. An upload receipt is only created after actual marketplace submission; preparation files are not proof of approval.