#Your workspace

BSuit organizes work by business module. The navigation menu shows only modules and capabilities enabled for your organization and role.

#Find your work

1. Use the sidebar to browse by module.
2. Press Ctrl+K (or Command+K) to find a page or record.
3. Use notifications and My Tasks to return to work requiring your action.

#Before entering live data

Confirm the selected company, database, accounting period, and your user context. Your access and data scope can differ between companies.

#Open global search

1. Press Ctrl+K on Windows or Command+K on macOS.
2. Type a page, module, or supported record name.
3. Use arrow keys to select a result and Enter to open it.

#Navigation modes

BSuit supports mega, standard, and dock navigation. Change the mode in Settings. Your choice is saved on this device.

#Contextual help

Select the question-mark action in the top bar from any page. BSuit Help opens the closest matching guide in a new tab, so your current work remains open.

#Find records

1. Use search for a quick text match.
2. Open filters for field-specific criteria.
3. Save a view when you will reuse the same columns and filters.
4. Clear filters if expected records are missing.

#Create or edit

Required fields are marked. Field help, validation messages, and related-record selectors guide data entry. Save as draft when the business process supports it.

#Protected actions

Delete, post, approve, and bulk operations may require extra permission or confirmation. Posted business documents are normally corrected through reversal or cancellation rather than direct editing.

#Submit for approval

1. Complete required record information.
2. Resolve validation warnings.
3. Select Submit and add a useful comment when requested.
4. Track the record status or workflow timeline.

#Approve or reject

Open the assigned task, review the record and supporting files, then approve, reject, or return it according to your authority. The decision and comment are retained in the audit trail.

#How the app is organized

BSuit Smart is one installable app whose screens change based on who signs in — it is not separate apps per role. Point-of-sale personas: POS (checkout), Cashier (till sign-in/reconciliation), Sales Register, Restaurant (Floor/Order/KDS — kitchen display). Field/maintenance: PM (technician sign-in, asset scan via barcode/QR, device management, session log). Warehouse: receiving against a PO, box scan/detail, stock audit, inquiry. Delivery: Van (sell on the road). Self-service: ESS (attendance, expenses, approvals, documents) for employees, Patient (appointments, booking, lab results, bills) for HMS, Student (classes, assignments, attendance, discussions, event RSVP), Teacher (class roll-call, assignments, resources, marks) and Parent (children switcher, then their schedule, attendance, results and fees) for Campus — the same accounts as the Campus Portal web app. Driver (assigned deliveries, proof of delivery with photo and signature), Doctor (patients, prescribing) and Caregiver access (via the Patient area) complete the personal sign-ins. Every screen has its own guide under BSuit Smart, Driver, Doctor, Patient and the other areas in the directory.

#Where to start

1. Sign-in determines which persona’s screens appear — a technician signing in sees PM screens, a cashier sees till screens, and so on; there is no manual "switch persona" step.
2. PM’s Asset Scan uses the device camera against a physical barcode/QR on the asset — it needs the asset already registered in Plant Maintenance (see the Plant Maintenance guide) to resolve to anything.
3. Warehouse’s Receiving screen expects an approved Purchase Order or GRN already in Inventory & Warehouse to receive against.
4. Patient and Student personas are read-mostly self-service — most data (appointments, grades, attendance) originates from HMS/Campus staff-side pages, not entered in the app itself.
5. ESS mirrors the Employee Self-Service module’s own web pages, scoped to mobile-friendly use in the field.

#One portal, three homes

There is a single Campus Portal and a single sign-in form. Your school creates and invites your account; the portal decides from the type of account whether you are a Student, a Teacher or a Parent and shows the matching home page. There is no separate student site.

#What each account can open

#Phones and tablets

On a phone a bottom bar replaces the sidebar. Students see Home, Schedule, Learning and More (Attendance, Results, Fees, Courses and Events are under More). Teachers and parents see all of their pages in the bar.

#Student home

Shows a greeting, a “Needs your attention” area (for example a warning when outstanding fees are blocking exam eligibility, with a link to Fees), your next class with a Join live button when a live session is available, today’s schedule, assignments due soon and a summary of your progress and attendance.

#Teacher home

Shows the number of classes you teach, periods per week and teaching load in hours, today’s schedule with a link to the full week, and your classes with a link to all classes.

#Parent home

1. Open My children and choose a child.
2. Schedule, Attendance, Results and Fees then show that child’s information.
3. Use the “Choose which child to view” switcher in the top bar to change child.

#Signing in and out

1. Open the portal address your school gave you.
2. Enter your email and password. If you have not set a password, use the invitation link your school emailed.
3. Use “Forgot password” on the sign-in page to request a reset link; the link works once.
4. Use the account menu to sign out, especially on shared devices.

#Mobile app

The same accounts work in the BSuit Smart app, which offers Student, Teacher and Parent screens.

#If something is missing

1. A page you expect is missing: it may not belong to your account type (see the table above).
2. A parent sees no children: the school has not yet linked you to a student with portal access.
3. You cannot sign in: ask your school to resend the invitation or reset your access.

#Purpose

Use this chapter when a new organisation (tenant) or a new company is being prepared for use. It lists the configuration in dependency order: each step relies on the ones before it. Skipping ahead is the most common reason a first transaction cannot be saved or posted.

#What BSuit creates for you

When a tenant is provisioned, several masters are seeded automatically so you do not start from empty screens.

#Step 1 — Company, base currency and country

1. Open Administration › Companies and edit the company created for you (or create one).
2. Set the legal name, country, address and logo.
3. Set the company currency. This is the base currency used by foreign-exchange revaluation and consolidation.

#Step 2 — Install modules

Administration › Modules lists the modules available to your plan. Installing a module that depends on another is refused until the dependency is installed ("Module … depends on modules that aren't installed"). Only administrators can install modules.

#Step 3 — Taxes and exchange rates

1. Create each tax and its rate in Administration › Taxes; link product-specific taxes in Product taxes.
2. Check Administration › Exchange rates. The seeded provider fetches daily rates; add manual rates for currencies it does not cover.

#Step 4 — Fiscal year and periods

1. Open Finance › Fiscal years. The first year and its 12 monthly periods were created at install.
2. For later years, create the year, then open Finance › Fiscal periods and make sure its periods exist.
3. Postings are refused in closed periods, so check the current period is open before go-live.

#Step 5 — Chart of accounts

1. Review the seeded ledger groups (Asset, Liability, Income, Expense, Equity) and ledgers.
2. Create a ledger for each bank account and link it to the bank.
3. Make sure an Equity group exists: year-end close moves profit into Retained Earnings under Equity.
4. Choose the FX gain and loss ledgers if you use foreign currencies (needed for automatic revaluation).
5. Create the control and posting ledgers other modules need: inventory (stock, goods-received control, COGS, variance), purchase-invoice posting (AP control, default expense), payroll posting and travel-expense posting.

#Step 6 — Record types and numbering

Each voucher type (cash receipt, journal, sales invoice…) is a record type. Its prefix, next number, padding and reset rule decide the document number; its flags decide whether it needs approval, a party account, a project, and whether it moves stock.

#Step 7 — Approval workflows

1. Open Workflow automation › Templates to review the seeded approval templates.
2. Link each template to the record type it approves (only super administrators can change templates and links).
3. Set up delegations for approvers who will be away (Workflow automation › Delegations); a delegate can act only on steps that allow delegation.

#Step 8 — Users, roles and security

Create users in Identity › Users and give them roles. See the chapter “Roles and access” for how permissions work.

#Step 9 — Email and print templates

1. Add your mail server in Administration › Email configurations and use its Test action.
2. Review the seeded print templates and email templates and apply your branding.

#Before the first transaction: checklist

#Purpose and scope

This chapter covers buying goods and services with BSuit’s procurement documents: requisition, request for quotation (RFQ), purchase order (PO), goods receipt note (GRN), supplier invoice, payment and returns. Suppliers take part through the Vendor Portal.

#Two ways to buy — choose one

BSuit offers two purchasing models. They do not share documents, so pick one per organisation or per category of spend and use it consistently.

#Before you start

1. Suppliers (with a party ledger), products, units, warehouses, currencies and tax codes.
2. Inventory posting ledgers (stock, goods-received control, COGS, variance) in inventory posting configuration.
3. Purchase-invoice posting configuration (Invoice posting config): AP control ledger and default expense ledger.
4. Approval workflows for PREQ (requisitions), GRN-RCV (receipts) and BANK-PAY (payments).
5. Budgets per cost centre if you want spend control at requisition.

#1. Raise a purchase requisition

1. Open Requisitions and create a requisition with the items, quantities, priority (low, normal, high, urgent) and cost centre.
2. Choose Save & Submit (or Submit for approval on a saved draft).
3. BSuit checks the budget for the cost centre. A blocking rule stops submission; a warning rule lets it through with a warning.
4. The requisition goes to the PREQ approval workflow. Approvers act from their approvals inbox.

#2. Request and compare quotations (RFQ)

1. In RFQs create an RFQ with lines and scoring criteria.
2. Invite at least one supplier. The RFQ becomes Sent and invited suppliers respond in the Vendor Portal.
3. Score each response, then Award the winner. BSuit creates a draft purchase order from the winning response and marks the other responses rejected.

#3. Create and issue the purchase order

1. Open Purchase orders › New, or open the draft created by the award. A PO created from a requisition needs that requisition to be approved.
2. Choose the supplier, currency and lines. Choose Save draft or Save & issue.
3. Issue the PO. The linked requisition becomes Converted, blanket-agreement consumption is applied, and the supplier is notified.

#4. Receive the goods (GRN)

1. Open Goods receipt notes and create a receipt for the PO, with received quantities, warehouse, and batch or serial numbers where the product needs them.
2. Submit for approval if your GRN-RCV record type requires it.
3. Accept the receipt. Accepting is currently limited to superuser accounts.

#5. Supplier invoice and review

1. The supplier submits the invoice in the Vendor Portal (Invoices) against an issued or received PO.
2. Accounts payable opens Vendor invoices. Opening the review panel claims the invoice.
3. Approve, Reject (notes required) or Request more information (notes required).
4. Approval (finance manager or superuser) posts the purchase invoice automatically: debit expense and input tax, credit the supplier (or the AP control ledger).
5. Check Matching for the three-way match result between PO, receipt and invoice.

#6. Pay the supplier

1. Create payment orders in Payment orders, or use Payment run to propose payments from open posted bills and create them in one go.
2. Submit the payment order. It goes to the BANK-PAY approval workflow.
3. On approval BSuit posts debit supplier (beneficiary) ledger, credit bank ledger.
4. Initiate, then download the bank batch file and mark it transmitted (or failed).

#7. Returns to the supplier

1. Create a return in Return to vendors.
2. Submit it for approval (RTV workflow), then Approve and Complete (superuser).
3. Completing issues the stock out and posts debit COGS, credit stock.

#Reports

#Troubleshooting

#Purpose and scope

This chapter covers selling: CRM leads and opportunities, quotations, orders, delivery and shipments (including the driver app), invoicing, receipts and cash application, collections, returns and point of sale.

#Two kinds of sales order

BSuit has an accounting sales-order voucher and a separate operational sales order. They are not linked; know which one your team uses.

#Before you start

1. Customers: a CRM account with a customer ledger (needed to win a deal), and a customer ledger for invoicing.
2. Products, price lists (reference only — prices are not applied automatically), tax codes, warehouses.
3. Record types EST, SQ, SO, SI, SR, CASH-REC, BANK-REC, CHQ-REC and CN with approval workflows (seeded for SI, SO, SQ, SR, CN and receipts).
4. Sales posting configuration (Posting config) for web and POS sales.
5. Dunning levels if you chase overdue customers.

#1. Lead, opportunity and win

1. Capture leads in Leads; Convert a qualified lead — BSuit creates the account and an opportunity.
2. Work the opportunity in Opportunities or the pipeline board; add product lines and create quote versions for the customer.
3. Choose Win. BSuit checks the amount is positive and, when the opportunity has product lines, that the account has a customer ledger; with the JV-CRM-WIN workflow configured it then waits for approval.
4. When the win is approved, BSuit marks the opportunity won and creates a draft operational sales order from the product lines. Nothing is posted to the ledger: revenue is recorded when the sales invoice is posted.

#2. Quotation, order and invoice vouchers

1. Create the document in Sales transactions (Quotations, Orders or Invoices).
2. Choose the customer, add product lines; save as draft.
3. Submit for approval; approvers act in their inbox.
4. Post when approved.

#3. Confirm and deliver

1. Confirm the operational order in Sales orders (from draft).
2. Raise a delivery note from the confirmed order in Delivery notes; generate a pick list and assign a vehicle.
3. Dispatch: stock is issued from the warehouse and reservations are consumed.
4. Deliver, capturing proof of delivery.
5. On a dispatched or delivered note choose Create sales invoice: BSuit drafts the invoice priced from the sales order, with each line linked to the note.

#4. Shipments and the driver app

1. Plan shipments in Shipments, hand them to drivers in Handoff.
2. The driver, in the BSuit Smart app, starts the trip, marks Arrived, then Delivered (recipient name, signature, delivery code and photo as your shipment settings require), or Couldn’t deliver with a reason, or Return to warehouse. It works offline and syncs later.
3. Customers are notified of shipment status by email and in-app.

#5. Receive and apply payment

1. Record the payment as a Bank receipt, Cash receipt or Cheque receipt.
2. Enter the customer (or income) lines as credits. The bank or cash side is generated automatically and hidden.
3. Open Bill-wise and select the invoices this receipt settles; BSuit proposes open posted invoices for the customer.
4. Submit, approve and post.

#6. Collections

1. Review AR aging (buckets current, 1–30, 31–60, 61–90, over 90, by transaction date) and Statement of account.
2. Set up dunning levels, then run Dunning. BSuit ages open invoices by due date, logs a collection activity, emails the level’s template to the customer and puts the customer on credit hold where the level says so (lifting it when paid).
3. Track calls and promises in Collections.

#7. Returns and credit notes

1. Web-store returns: Returns — approve, receive (stock goes back to a warehouse and a credit journal is posted), then refund (store credit gift card or refund pending to the original payment).
2. Other credits: raise a Credit note against the customer.

#8. Point of sale

Terminal sales sync to POS transactions and post automatically using the sales posting configuration (debit cash/bank/customer, credit sales and tax). If the configuration is missing the sale stays in draft marked “failed — no config”. POS postings do not go through approval or the period and budget checks.

#Before you start

1. Warehouses, with “allow negative stock” and valuation method (weighted average by default; per product or per warehouse FIFO/LIFO possible).
2. Inventory posting ledgers: stock asset, goods-received control, COGS and stock variance.
3. Approval workflows for STK-TRF (transfers), STK-ADJ (adjustments) and CYC-CNT (counts) if your policy needs approval.

#1. Transfer stock between warehouses

1. Create the transfer in Stock transfers with source and destination warehouses (they must differ) and positive quantities.
2. Submit for approval (STK-TRF workflow) or approve directly (superuser).
3. Dispatch: stock leaves the source into an automatic “Goods in transit” warehouse. Then Receive at the destination. Or use Complete to do both in one step.

#2. Adjust stock

1. Create an adjustment in Stock adjustments; for each item enter the difference and a reason.
2. Submit for approval (STK-ADJ) — or a superuser approves directly.
3. Post (superuser). Stock is increased or decreased by each difference.

#3. Cycle count (stock count)

1. Create a count in Cycle counts and Start it — BSuit snapshots the system quantities.
2. Enter the counted quantity for every line, then Complete (all lines need a count).
3. Submit for approval (CYC-CNT), then Post adjustments (superuser, once only).
4. Variances are applied to stock and posted: stock asset against stock variance.

#4. Batches, quality and expiry

1. Batches are created on receipt (or automatically when a stock-moving purchase invoice is posted). Manage them in Batches.
2. Quality status: released, quarantine, testing or rejected. Stock in a batch that is not released cannot be issued.
3. A daily job marks batches expired and raises alerts at 90, 60, 30 and 0 days (Batch expiry alerts); acknowledge and resolve them.
4. Use first-expiry-first-out suggestions when picking.

#Reports

#Before you start

1. Statuses (seeded: open, pending, resolved, closed) and priorities (seeded: critical, high, medium, low) in Statuses and Priorities.
2. Agent groups (with auto-assign if wanted), business calendars and holidays.
3. SLA policies (SLA policies) and escalation rules.
4. Grant permissions to the seeded Service Desk Agent, Change Manager and Problem Manager roles — they are created empty.

#Default SLA targets

An SLA policy chosen on the ticket wins; otherwise BSuit picks the most specific match: priority and category, then priority, then category, then a catch-all. Due times follow the business calendar.

#1. Log and work a ticket

1. Create the ticket in Tickets (or Incidents / Problems): type, category, priority, channel and description.
2. BSuit applies the SLA and, if the agent group auto-assigns, assigns an agent.
3. Work your queue in My assigned. Set Pending while waiting on the customer — the SLA clock pauses and due dates shift when work resumes.
4. Resolve. The customer is emailed a one-time satisfaction survey.

#2. Escalation

Every minute BSuit marks tickets past their resolution due time as escalated and fires matching escalation rules (trigger “SLA breach”), notifying the agent, group or an email list, with repeats and levels. Other trigger types are not acted on.

#3. Problems and known errors

1. Link related incidents to a problem.
2. Record the root cause and workaround, then Promote to known error — it is added to the known-error database for agents to search.

#4. Change requests

1. Create the change in Change requests; submit it, or submit it for CAB review.
2. Add CAB approvers; each votes approved, rejected or abstain.
3. Move the change through approved → scheduled → implementing → implemented → closed (or failed).

#5. Customer support portal

1. Customers raise tickets at Support portal with their email and subject; attachments are virus-scanned.
2. They check progress with the ticket number and email, read the knowledge base, and rate the resolution (CSAT and effort, 1–5, once).

#6. Warranties and RMAs

Check coverage by serial number in Warranties (active, expired, not started, inactive). Service returns are handled in RMAs (requested → approved → received → inspecting → replaced, refunded, rejected or closed); a refund posts a journal through the JV-RMA-REFUND workflow. Warranty coverage is not checked automatically when a ticket is logged.

#Purpose and scope

This chapter covers the finance cycle from recording journals to closing the year: journal vouchers, recurring journals, bank reconciliation, foreign-exchange revaluation, the close checklist, period and year locking, and the financial reports. Sub-ledger processes (purchases, sales, payroll) feed it and are covered in their own chapters.

#Before you start

1. A fiscal year with periods covering the dates you post (see “Setting up BSuit”).
2. Chart of accounts with an Equity group (for Retained Earnings), bank ledgers linked to banks, and FX gain/loss ledgers if you use foreign currencies.
3. Record types JV and the payment/receipt types, with approval workflows where your policy needs them.
4. Permission to create/edit the voucher types you use (record_type.JV.create, …).

#1. Record a journal voucher

1. Open Transactions and choose the journal type.
2. Enter the date, narration and at least two ledger lines. Debits must equal credits.
3. Save. The voucher is a draft and gets its number from the record type.
4. Choose Submit for approval if the type requires approval. It becomes pending approval and is routed to the workflow linked to the record type.
5. After approval, choose Post. Posting runs the final checks (see below) and the voucher becomes posted.

#What is checked when you post

#2. Recurring journals

1. Open Recurring transactions and base a template on an existing voucher.
2. Choose the frequency (daily, weekly, monthly, quarterly, yearly), start and end, lead days, optional escalation % and skip dates.
3. Tick Auto-post if the generated vouchers should post automatically; otherwise they are created as drafts for review.
4. Use Run now to generate the next occurrence immediately.

#3. Bank reconciliation

1. Import the statement in Bank statement imports. The bank account must be linked to a GL ledger, and the same file cannot be imported twice.
2. Match statement lines to posted transactions. Only posted, non-cancelled transactions can be matched.
3. In Bank reconciliation, when every line is matched, choose Reconcile. The reconciliation records who reconciled it and when.

#4. Foreign-exchange revaluation

1. Open FX revaluation and choose the revaluation date.
2. Preview the open foreign-currency positions and the gain or loss for each.
3. Run. BSuit reverses the previous revaluation automatically (JV-FX-REVAL-REV) and posts the new one (JV-FX-REVAL).

#5. The close checklist (Financial Close Cockpit)

Open Period close, pick the period and start the close. BSuit copies a fixed 15-task checklist into the run; assign owners (they are notified) and mark tasks done, blocked or not applicable.

#6. Lock the period

#7. Close the fiscal year

1. Make sure no drafts remain in the year. In Fiscal years choose Close.
2. BSuit posts a year-end journal dated the last day of the year that moves all income and expense balances into Retained Earnings (creating the RETAINED-EARNINGS ledger under Equity if needed).
3. Every period is hard-closed and the year is marked closed.

#Reports to review

#Who can do what

Posting, submitting and cancelling a voucher need the edit permission on its record type. Closing, reopening, archiving and restoring fiscal years and periods, and signing off or reopening period-close runs, need the Finance Manager role (or a superuser); anyone else gets “403 Forbidden”. The Finance Manager role holds view/create/edit on finance records and nine voucher types.

#Before you start

1. Departments, designations and shifts.
2. Each employee record linked to the person’s user account — every self-service feature (attendance, leave, payslips, expenses) needs this link. BSuit links automatically where the email matches exactly.
3. Attendance geofences for sites where people check in by phone.
4. Leave types and the LEAVE-REQ approval workflow (seeded).
5. The careers portal feature switched on if you recruit externally.

#1. Requisition and job posting

1. Create a Job requisition and Submit it (JOB-REQ workflow).
2. Approve it (or reject). A posting linked to a requisition needs the requisition approved.
3. Create the Job posting. It shows on the careers site when it is published, active and before its closing date.

#2. Applications, interviews and offers

1. Candidates apply on the careers site with a PDF or Word résumé (up to 5 MB, virus-scanned) and must accept the data-processing notice.
2. Move applications through stages in Candidate applications or the board: Applied, Screening, Shortlisted, Interview, Assessment, Offer, Hired, Rejected, Withdrawn.
3. Schedule interviews (Interview schedules); candidates pick a slot. Record feedback and scorecards.
4. Create the Offer letter, Generate the letter (it is attached to the candidate), then set the status to Sent — candidates cannot see Draft offers.
5. The candidate accepts or declines on the careers site; expired offers cannot be accepted.

#3. Hire and onboard

1. Create the employee in Employees (department, designation, joining date, salary, manager) and link their user account.
2. Create onboarding tasks in Onboarding checklists: IT accounts (day 0), documents (+3 days), statutory and benefits enrolment (+7), orientation and buddy (+1), workspace (day 0), induction training (+14).

#4. Attendance and shifts

1. Employees check in and out on the phone app or at My attendance; location and accuracy are recorded.
2. Inside an active geofence the day is Present; otherwise, or with poor GPS accuracy, it is Pending review for the manager.
3. Supervisors can record attendance for their team in bulk (up to 500 people): Present, Absent, Half day, Late, On leave, Site duty, Training.
4. Plan shifts in Shift roster (up to 90 days at a time).

#5. Leave

1. The employee requests leave in My leave (web or phone).
2. The manager approves in My approvals or Team leave.
3. On approval the request is Approved (approver and time recorded); on rejection the reason is kept.
4. Leave balances are calculated by BSuit from each leave type’s accrual and carry-forward rules; there is no separate balances screen, so HR confirms a balance on request.

#6. Performance

1. Open a cycle in Performance cycles and set goals (Goals).
2. Employee completes the self-review; the self section locks when the manager starts.
3. Manager review follows (only after self-review is submitted), then HR finalises. A finalised appraisal needs HR to reopen it.

#7. Resignation and exit

1. The employee submits a resignation in My resignation with a reason and a future last day. They can retract it while open.
2. HR accepts or rejects it. Accepting creates the exit checklist from the template.
3. HR ticks checklist items; when all are done the resignation is completed.
4. Record the final settlement in Final settlements.

#Before you start

1. Salary components (earnings and deductions) and structures (Salary structures); each employee has a basic salary or a structure.
2. Country packs (Country packs) with effective-dated tax slabs and statutory deductions.
3. Payroll posting ledgers (salary expense, tax payable, statutory payable, net pay, employer contribution) in the payroll posting configuration.
4. The HR Payroll Admin role for the people who run payroll.

#1. Create and scope the run

1. In Payroll runs create a run for the month and year, optionally choosing a country pack.
2. While the run is Draft, you can limit it to selected employees.

#2. Execute

Execute (superuser or HR Payroll Admin) calculates every active employee of the company:

1. Gross = basic salary, or the sum of the structure’s earning components.
2. Proration by attendance when attendance exists: present, work-from-home, on duty, paid leave, holiday and week-off count as a full day; half day as half; anything else as zero.
3. Progressive income tax from the country pack plus the employee’s statutory deductions.
4. A payslip PAY-yyyyMM-<employee code> in Draft with basic, tax and statutory lines.

#3. Approve and post

1. On a Completed run choose Submit for approval (JV-PAYROLL workflow). If no workflow is configured it posts immediately.
2. On approval BSuit posts the payroll journal PAYRUN-yyyyMM: debit salary expense (gross); credit tax payable, statutory payable and net pay; plus the employer-contribution debit and credit.
3. If approval is rejected, fix and resubmit.

#4. Release payslips

Employees see only released payslips (web My payslips and the phone app). Releasing notifies them in-app, by push, email (with the PDF) and WhatsApp.

1. On a Completed, posted run open the run in Payroll runs and choose Release all payslips. Slips already released or cancelled are skipped.
2. To release one slip, choose Release on it in Salary slips.

#Before you start

1. Posting configuration in Posting config: the record type, bank ledger, default expense ledger and a ledger per expense category.
2. Per-diem rates by country (Per diem rates) if you pay allowances.

#1. Capture expenses

1. On the web, create a report in My expenses with a title.
2. On the phone, use Quick capture: photograph the receipt (JPEG, PNG, HEIC, WEBP or PDF, up to 20 MB) and enter category and amount; it is queued offline and added to a “Quick capture” draft report.

#2. Approve, pay and post

1. Finance opens Expense reports and approves submitted reports (currently superuser only).
2. Mark paid & submit: the report becomes Paid and its posting goes through the configured approval (or posts at once).
3. The journal debits each category’s expense ledger and credits the bank ledger; its number is the report code.

#Travel requests

Plan trips in Travel requests: draft → submitted → approved → booked → completed (or rejected).

#Where things are

Campus records live under Campus in the ERP menu (each list is a Campus page such as Academic years, Terms, Programs, Course offerings, Timetable versions, Admission applications, Students, Fee invoices). Teachers, students and parents use the Campus Portal or the BSuit Smart app. Field-level detail for every campus record is in the data reference for the Campus area.

#1. Academic structure and timetable

1. Create in order: campus, academic year, terms, departments, programs and program versions, courses and curriculum, batches, sections, course offerings, faculty assignments, periods.
2. Create a timetable version and its slots, or use Generate on the version to place sessions automatically (“Placed n session(s)”).
3. Set the timetable version to Published — only published timetables appear in the portals.

#2. Admission and enrolment

1. Set up admission cycles and seat matrices; record enquiries and applications (numbered from the CMP-APP series).
2. Record documents and assessments; compute the merit list (ranks applicants and marks Selected or Waitlisted against seats).
3. Issue offers and seat allotments.
4. On an Accepted offer choose Enrol student: BSuit creates the Student (CMP-STU), the enrolment for the batch and an Admitted status event, marks the application Enrolled and confirms the seat. Link guardians on the student.

#3. Give portal access

1. Open the student’s (or teacher’s) Overview page and use the Portal access card to Grant access. For a guardian, first tick portal access on the student–guardian link.
2. BSuit emails a one-time set-password link valid for 3 days (template campus_invite). Nobody sees or chooses the password.
3. Use Resend invite if it expires; Revoke switches access off without losing the link.

#4. Attendance and marks (teachers)

1. In the Campus Portal, open My classes › the class › Attendance, pick the date and period and mark Present, Absent, Late, Excused or Half-day. Future dates and other teachers’ periods are refused.
2. Open Marks, choose an assessment component and enter marks (0 to the component maximum). The class needs an assessment plan.

#5. Results

1. The exam controller verifies and moderates marks.
2. On Term results choose Compute results, pick the term (and optionally a batch): BSuit computes course results, term results (SGPA/CGPA) and batch ranks. It can be run again.
3. Choose Publish results. Students and parents see only published results.

#6. Fees

1. Set up fee categories, structures, components and instalments.
2. Raise fee invoices (CMP-FEE-INV) — students and parents see non-draft invoices; parents only if they receive invoices for that child.
3. Record fee receipts (CMP-FEE-RCPT), concessions and refunds.

#Seeded roles

Principal, Registrar, Bursar, Exam Controller, Academic Coordinator, Faculty, Counsellor, Special Educator, Warden, Librarian, Clinical Coordinator and Preceptor. See Roles and permissions for what each can do.

#1. Register the patient

Receptionists, nurses, doctors and administrators create patients in Healthcare › Patients (the 360° overview shows everything about the patient). Record allergies in Allergy notes — the prescribing safety check reads this field.

#2. Book the appointment

1. Front desk: create the appointment (statuses Scheduled, Checked-in, In consultation, Completed, Cancelled, No-show).
2. Patient app: choose specialty, doctor and a free slot and book; cancel or reschedule later.

#3. Consultation (doctor, BSuit Smart)

1. The doctor signs in to the Doctor workspace and sees the day’s schedule; allergy and alert flags show on each appointment.
2. Open the patient summary — available only for patients seen by that doctor in the last 12 months; every view is audited.
3. Start consultation, then Mark completed or No-show. Scheduling and cancelling stay with the front desk.

#4. Prescribe safely

1. Choose Prescribe (voice or typed). Dictation or text is turned into a draft by AI when speech-to-text is configured; otherwise add medicines by hand.
2. Check the lines (1–20 medicines) and choose Issue prescription.
3. If the safety check finds a critical issue (for example a recorded allergy), issuing is blocked. Fix the lines, or confirm with a reason of at least 5 characters — the override is audited.

#5. Lab and radiology orders

Use Advance and Cancel on the order row. Completed orders cannot be cancelled.

#6. Billing and insurance

1. Request pre-authorization; BSuit evaluates coverage (Approved, Partial, Rejected or Pending) with the reason.
2. Capture charges and assemble the claim or bill.
3. Post the insurance claim to the ledger (JV-HMS-BILL); it becomes Submitted.
4. Collect the patient co-pay (cash, bank or cheque, including post-dated cheques).
5. Settle with the insurer when paid; an optional write-off posts JV-HMS-CLAIM-WO.
6. Self-pay bills: collect payment against Issued bills.

#7. Caregiver access

In the patient app, a patient can let another patient-app account (for example a family member) view chosen parts of their record — appointments, prescriptions, bills, results, visits — for up to a year (180 days by default). Caregivers can only look; every view is audited, and the patient can withdraw access at any time.

#1. Assets and preventive plans

1. Register assets in Assets (active, maintenance, retired, disposed).
2. Create a PM schedule with a time interval and/or a meter interval — whichever comes first — and a checklist and parts template. Choose fixed or completion-based recurrence.
3. A daily job generates a preventive work order (status Open) when a plan is due, copying the checklist and parts. Missed occurrences are listed.

#2. Work order lifecycle

#3. Technician terminal

1. An administrator issues an enrollment code (workshop, kiosk or field; shared or personal) and the device registers once.
2. The technician signs in with their PIN (locked after repeated failures; a personal terminal accepts only its bound technician).
3. Start a work session on the order (it moves to In progress). Pause with a reason (awaiting parts, permit issue, safety stop, shift end, break, other) — if only paused sessions remain the order goes On hold. Resume and End.
4. Ending a session records labour hours. Ending never completes the order.

#4. Parts

1. Request parts on the order; approvals move them to approved-awaiting-stock.
2. Issue from a warehouse (quantity and warehouse required).
3. Handle failures in Parts exceptions: retry issue, return stock, or void.

#5. Complete and close

1. Complete the order when all checklist items are done and no part lines are waiting.
2. If a JV-PM-COST approval workflow is configured, the order goes to Pending approval; approval posts the cost and completes it, rejection returns it to In progress.
3. Without a workflow, completing posts the cost at once — which needs the close permission.

#Roles

#Breakdowns and compliance

Report breakdowns in Breakdown reports (reported → acknowledged → in progress → resolved); a work order can be raised from a report (emergency if critical, otherwise corrective) — check one does not already exist. Compliance alerts warn 45 days before asset insurance, permits, warranty, vehicle registration or insurance, emissions and driver licences or medicals expire (critical at 14 days); review them in the compliance alerts inbox.

#Purpose and scope

This chapter covers the IoT module: the device registry, the gateway ingest feed, telemetry, alert rules and alerts, commands to devices and firmware tracking. Telemetry is what devices report; alerts are raised when a rule is breached.

#Before you start

1. The IoT module installed for your tenant and the gateway-ingest feature enabled.
2. Permission to create devices (the IOT-ADMIN role is seeded for provisioning and device credentials). Issuing and cancelling commands, acknowledging, resolving and reopening alerts, and provisioning devices each have their own permission (iot.command.issue, iot.command.cancel, iot.alert.acknowledge, iot.alert.resolve, iot.alert.reopen, iot.device.provision).
3. A superuser account for the Gateway Ingest page, which is restricted to superusers.

#1. Device types and groups

1. Open Device types and create a type with a code, name and category (GPS, Environment, Meter, Energy, Access, Machine or Other).
2. Set the Expected interval (seconds) if devices of this type should be considered offline when silent. Leave it blank and they are never considered offline.
3. Optionally create Device groups so a single rule can cover a named set of devices.

#2. Onboard devices

1. Open Onboarding. The wizard has four steps: Identity, Binding, Credential, First reading.
2. Enter a code and name, pick a device type, and the external device id (the id the gateway sends; it defaults to the code). Optionally add the provider and the entity the device is bound to (asset, vehicle, warehouse, room and so on).
3. Choose Create device & generate credential. The credential is generated by the server and shown once; only its hash is stored. Copy it, tick I have saved the credential and continue.
4. The last step polls every 5 seconds and shows a tick when the first reading arrives.
5. For many devices, use the bulk import: Download template, fill the CSV, Validate (dry run), then Import & generate credentials. Download the credentials CSV straight away; credentials are shown once.

#3. Connect the gateway (Gateway Ingest)

1. Open Gateway ingest as a superuser. Other users see a notice that the page is restricted.
2. Check that Accepting telemetry is on. Turning it off stops ingestion without changing the token; readings are refused until it is turned on again.
3. Configure the gateway to POST to the ingest URL shown, with the tenant token in the X-IoT-Key header. If the device has a credential, also send it in X-IoT-Device-Key. The sample payload is on the page.
4. To revoke the token, choose Rotate token and confirm. Every gateway using the old token stops being able to post at once and must be updated with the new one.

#4. Watch what needs attention

1. Open Overview. It refreshes every 30 seconds and shows counts for active, offline and never-reported devices, devices without a credential, and command counts (pending, delivered awaiting acknowledgement, failed and unconfirmed in 7 days, expired in 24 hours), plus open alerts by severity.
2. Use the lists under it: Open alerts, Offline devices, Failed and unconfirmed commands, and the onboarding checklist of devices that have never reported.
3. Open a device to chart a metric over 6 hours to 90 days. Short windows show raw readings; long windows show hourly minimum, maximum and average. See also Telemetry for raw readings (read-only) and Device map for devices with a GPS fix.

#5. Alert rules

1. Open Rules and choose the rule type: Threshold (Min or Max value on a metric), Rate of change (delta threshold within a window in seconds) or Offline (applies to the device as a whole, so leave Metric blank).
2. Choose the scope: a specific device, a device type or a device group. A more specific scope narrows the rule.
3. Set the severity (Info, Warning, Critical) and the cooldown in minutes (default 30), which suppresses repeat alerts for the same device and rule.
4. Optionally list the users to notify (comma-separated user ids) and an Approval Record Type code. A breach then starts that record type’s approval workflow.

#6. Work alerts

1. Open Alerts. Each row shows its severity and status (open, acknowledged, resolved).
2. Choose Acknowledge to take ownership, then Resolve when fixed.
3. A resolved alert shows Reopen; you must give a reason.

#7. Commands to devices

1. Open Commands and choose Issue command. The device must be active, otherwise BSuit refuses with “Device is … and cannot accept commands”.
2. The command starts Pending with an expiry (default 15 minutes, between 1 minute and 24 hours). If the device is offline the screen warns that it expires undelivered if it does not reconnect in time.
3. When the device collects it the command becomes Sent; the device then reports success (Acked) or failure (Failed).
4. Use the status filter and the timeline on a row to follow it; retry or cancel from there.

#8. Firmware drift

Firmware records known versions per device type and one target version per type, with an optional vendor checksum kept for verification only. It reports drift (devices not on the target) but does not deliver updates; there is no over-the-air delivery.

#Housekeeping done for you

A background worker flags devices silent for longer than their type’s expected interval (raising an alert where an offline rule exists), evaluates rate-of-change rules, builds hourly rollups, expires stale commands, marks unacknowledged ones Unconfirmed, and trims raw telemetry past the retention window once its rollup exists. A retention of 0 days keeps everything.

#Purpose and scope

This chapter covers the Transport module: tariffs, consignments (bookings such as LR, AWB or B/L), multi-leg movement, load planning and dispatch, trip sheets, delivery performance and exceptions, and customer and carrier billing.

#Where Transport is in the menu

Transport has no sidebar group of its own. In the source its menu items are declared under Sales Management → Transport & Freight, and the address /transport opens the Transport overview. If you cannot see those items in your sidebar, open the pages by address (for example /transport/overview) and ask an administrator to check that the Transport module is installed and your role has access. Rate cards, zones, surcharge rules, vehicle cost profiles, carriers, freight tax profiles and driver pay rules are marked admin-only in the menu.

#Before you start

1. The Transport module installed (Sales Management lists it as a dependency).
2. Ledgers: a freight income ledger on the rate card or charge lines, a tax ledger where tax is charged, a creditor ledger on each hired carrier, and driver, advance and expense ledgers for trip settlement.
3. Customers and consignors or consignees linked to ledgers, so a bill-to account can be resolved.
4. The named permissions you need, such as transport.consignment.invoice, transport.consignment.cancel, transport.trip_sheet.close, transport.trip_sheet.settle, transport.freight_bill.* and transport.carrier_bill.*. They are granted to the TRANSPORT-ADMIN role.

#1. Tariffs and charges

1. Create Freight zones (cities and pincode prefixes) to use in lanes.
2. Create a Rate card with a validity window, the mode, optional customer, vehicle type and currency, then add Rate lines: origin and destination (city or zone), weight slab, basis and minimum charge.
3. Add Surcharge rules for fuel, waiting, detention, ODA, COD, peak and handling surcharges.
4. Set Freight tax profiles (which GST or VAT masters freight is billed under, rounding and reverse charge).

#2. Book and rate a consignment

1. Open Consignments and create a booking with origin, destination, parties, freight terms (paid, to-pay or TBB) and weight.
2. Rate it from the tariff. The freight line and any rule-based surcharges are saved as charge lines on the consignment; add hand-written accessorial charges in Consignment charges.
3. Only billable charge lines count toward the header total, so the total equals what will be billed.

#3. Plan loads and dispatch

1. Open the Planning workbench. Build a load from open consignments (BSuit can also suggest and consolidate), and set planned departure and arrival; arrival must be after departure.
2. BSuit checks capacity and vehicle-type compatibility, expired insurance, permits, registration and licence, licence class, and the driver’s hours of service.
3. Confirm the load (it needs at least one consignment), then Dispatch and later Complete. A load is Planned, Confirmed, Dispatched, Completed or Cancelled, and only a Planned load can be edited or deleted; cancel others instead.
4. Alternatively use the Dispatch board to assign an own-fleet vehicle or a hired vehicle number to a consignment, and Trips to see legs, fleet trips and sales deliveries together.

#4. Legs, containers, tracking and proof of delivery

1. For multi-leg movement use Route legs: depart and arrive each leg. Once legs exist the consignment status is derived from them, so it cannot read Delivered while a leg is still at a hub.
2. Track movement in Track & trace, which records scans (Booked, Picked up, In transit, Reached destination, Out for delivery, Undelivered). Track containers, seals and custody in Containers; a seal that differs on arrival is flagged, not overwritten.
3. Record proof of delivery with the receiver name (required) and delivered packages. This is the only way a consignment becomes Delivered.
4. To cancel, use the cancel action (needs transport.consignment.cancel).

#5. Trip sheets and settlement

1. Open Trip sheets. A new sheet is a Draft; Open it when the driver departs.
2. Record the driver’s advance and book route costs as Trip sheet expenses. Distance and the driver’s balance are derived from the odometer and lines, never typed in.
3. Optionally plan the cost from a vehicle cost profile and the planned distance, and compute the driver’s pay from a driver pay rule.
4. Close the sheet at the final odometer (not below the opening reading, and needs transport.trip_sheet.close). After closing, expenses can no longer be added.
5. Settle (needs transport.trip_sheet.settle). BSuit posts a settlement journal and freezes the sheet.

#6. Bill customers

1. Open Freight bills and create a bill from eligible consignments (single, consolidated or by customer and period).
2. Approve the draft (maker-checker: the creator needs the self-approve permission to approve their own bill), then Post. Posting debits the customer and credits freight revenue and tax payable.
3. Cancel an unposted bill; reverse a posted one (books a full credit note); raise credit or debit notes against a posted bill; file a GST e-invoice where used.
4. For a single consignment you can instead post a consignment invoice (needs transport.consignment.invoice); a consignment already on a freight bill must be billed from the bill.

#7. Pay hired carriers

1. Create Carriers (hired transporters) linked to a creditor ledger.
2. Open Carrier bills and build a bill from delivered consignments (or legs) that have a hire cost for that carrier. An inactive carrier or a consignment with no hire cost is refused.
3. Approve (transport.carrier_bill.approve), then Post to payables (transport.carrier_bill.post). Posting needs a hire-cost expense ledger and, when tax is present, a tax ledger.

#8. Monitor: overview, delivery performance, exceptions and profitability

Overview shows in transit, delayed, awaiting POD, uninvoiced and open trip sheets. Delivery performance shows on-time, in-full, OTIF, delays and dwell and the late list. Profitability shows margin by lane, customer, carrier and consignment, and planned versus actual trip cost.

1. Work Exceptions (delays, breakdowns, failed delivery, receiver rejection, damage scans, expired compliance and long stops): acknowledge, start, assign, resolve or dismiss, and reopen if needed. Users with transport.exception.manage work them and are the dispatchers notified of new ones.
2. Holders of transport.exception.reassign can move the affected legs to another vehicle or driver in one step.

#Purpose and scope

This chapter covers the Agriculture module: field, crop type, livestock profile and animal group master data, the crop-cycle lifecycle with costing and harvest revenue, livestock feeding and cost entries, irrigation and feeding automation, and season comparison.

#Before you start

1. Expense, payable (or cash), receivable and revenue ledgers in the chart of accounts. They are only needed when you post a cost or a harvest.
2. Permissions: agriculture.cost.post (post a crop-cycle cost), agriculture.harvest.record (record a harvest), agriculture.livestock_cost.post (post a livestock cost) and agriculture.cycle.transition (start or close a cycle). The seeded FARM-MANAGER role is described as owning field and crop planning, irrigation scheduling, sensor-driven decisions and cost and harvest postings.
3. For automation, IoT devices bound to the field or animal group (see the IoT guide).

#1. Master data

1. Create Fields with a code, name and area in hectares. Purpose is Crop, Pasture or Barn. Soil type, location (free text) and company scope are optional.
2. Create Crop types with the soil moisture, temperature and humidity ranges the crop prefers, an optional growing-degree-day base temperature and the typical days to harvest.
3. Create Livestock profiles with the body temperature range and the feed ration per head with its unit.
4. Create Animal groups (herd or pen) with species and head count, optionally linked to a field and a livestock profile.

#2. Plan and start a crop cycle

1. Open Crop cycles and create a cycle with a code, field, crop type, planting date, expected harvest date, expected yield and unit, and budgeted cost. The expected harvest date cannot be before the planting date, and the field must exist.
2. Optionally break the budget down by seed, labour, irrigation and other categories. The Budgeted Cost total stays independent of the breakdown.
3. Open the cycle and choose Start cycle. Only a Planned cycle can be started; it becomes Growing.

#3. Record and post costs

1. On the cycle’s Cost Entries tab add a cost with a description and a positive amount. Choose the expense ledger (debit) and the payable or cash ledger (credit); they are only required to post.
2. Post the entry to the ledger (needs agriculture.cost.post). Posting debits the expense ledger and credits the payable ledger, and tags the journal to the cycle so actuals roll up per cycle. Posting twice has no further effect.

#4. Harvest and revenue

1. On the Harvest & Revenue tab enter the actual harvest date, the actual yield quantity and the sale rate per unit (all positive), and choose a receivable ledger and a revenue ledger.
2. Record the harvest (needs agriculture.harvest.record). BSuit posts a journal for yield × rate: debit receivable, credit revenue. The cycle becomes Harvested.

#5. Close the cycle

1. Post or delete every unposted cost entry.
2. Choose Close cycle on a Harvested cycle (needs agriculture.cycle.transition).

#6. Livestock feeding and costs

1. Record each feed dispense in Feeding events: animal group, time, source, quantity and unit.
2. On a feeding event choose Create cost entry. Pick the basis: unit cost × quantity dispensed, or a total amount, and optionally the expense and payable ledgers.
3. Open the animal group and, on its Cost Entries tab, post the entry (needs agriculture.livestock_cost.post). Posting debits the expense ledger and credits the payable ledger, tagged to the animal group.

#7. Irrigation and feeding automation

Every field and animal group starts with automation Off. In Fields and Animal groups choose Dry run or Live per record. Off only alerts and never actuates; Dry run logs what it would do without sending a command; Live issues a real IoT command. Irrigation events and Feeding events show the log, with the source (manual, rule or dry run).

#8. Compare seasons

Season comparison groups every crop cycle by crop type and planting year and shows expected and actual yield, budgeted and actual cost, yield and cost variance and net margin. Actuals are sourced from the ledger.

#Purpose and scope

This chapter covers Restaurant & KDS: the floor and kitchen master data, reservations, the order ticket lifecycle from open to settle, kitchen tickets (KOT) and kitchen display, and the public Food marketplace presence. The screens in the ERP are registers and master data. Orders are taken and settled on a POS terminal (the same terminal connection used for POS), which calls the same order service as the ERP.

#Before you start

1. The Restaurant feature switched on for your tenant (the menu group is marked admin-only).
2. Products to sell, with an outward tax set on the product or its category. Tax on each line is resolved from the product’s outward tax first, then its category’s, otherwise zero.
3. The POS record type configured. Settling an order uses it and fails with “POS RecordType not configured” if it is missing.
4. Payment ledgers (cash, card, bank) for settlement, and a customer ledger if you allow credit.

#1. Floor and kitchen set-up

1. Create Floor sections such as Hall, Garden and Bar.
2. Create Kitchen stations such as Grill, Fry and Bar. They route kitchen tickets and drive the kitchen display boards.
3. Create Tables with a code, capacity and section.
4. Create Modifier groups (for example Spice level or Add-ons) with minimum and maximum selections, add the choices with price deltas in Modifier options, then attach groups to products in Menu modifiers. Attached groups make the picker appear on the terminal for that product.

#2. Reservations

1. Open Reservations and book a table: customer name (required), phone, party size, date and time, duration in minutes and an optional table.
2. Filter by status or show only upcoming bookings. On a Booked row use No-show or Cancel.
3. When the party arrives, seat it from the terminal. Seating opens a dine-in order on the booking’s table (or the table you choose), marks the reservation Seated and links the order.

#3. Orders and kitchen tickets

1. On the terminal open an order. A dine-in order needs a table, and a table can have only one open order; opening it marks the table Seated.
2. Add items. Each line takes the unit price and a tax amount snapshotted at the time it is added. Items can be updated, or voided with a reason (voiding an already voided line does nothing).
3. Fire to the kitchen. Every item in Ordered status becomes Fired and gets a new KOT batch number; with nothing to fire, BSuit says “no Ordered items to fire”. A KOT can be reprinted.
4. The kitchen display shows every fired ticket not yet bumped, oldest first, optionally per station. Bumping a ticket sets its Fired items to Served and removes it from the board; single items can be bumped too, and a recently bumped ticket can be recalled.
5. To change tables use Move (the target must be active and have no open order); to combine bills use Merge (both orders must be Open, and an order cannot merge into itself). Merged KOT batches continue the primary order’s numbering.

#4. Settle or cancel

1. Open the order bill. Only an Open order can be settled, and it must have at least one non-voided item.
2. Enter any order-level discount and service charge. The bill total is item lines less discounts, less the order discount, plus service charge, plus item tax.
3. Choose the tender: a single payment ledger, credit to a customer ledger, or split tender. Split legs each need a payment ledger and must add up to the bill total within one cent. Split tender cannot be combined with credit.
4. Settle. BSuit posts the sale through the POS posting (one party ledger, sales income and tax counter-entries) using the POS record type, so restaurant sales report together with counter sales. The order becomes Billed.
5. To cancel, use Cancel with a reason. The table is freed.

#5. Review the order register

Orders lists tickets with status (open, billed, cancelled), table, customer, items, totals and KOT history; open one to see its lines and KOT batches. Use Reservations for the booking register.

#6. Publish to the Food marketplace

1. Create a Marketplace restaurant: code, name, public slug (used in public links), cuisine types, description, logo and status Draft or Published.
2. Add Branches with address, city, country, coordinates, delivery time in minutes, delivery fee, minimum order amount and status Draft or Published.
3. Curate Menu items per branch: choose the product and a menu section, dietary tags, sort order, and flag items as Available for ordering or Featured.

#Purpose and scope

This chapter covers the Oil & Gas JV module. The address /oil-gas-jv redirects to Oil & Gas; the module key and API use oil-gas-jv while the pages live under /oil-gas. The Operator runs day-to-day operations, pays costs up front and bills partners back through a Joint Interest Billing (JIB); a Non-Operator owes its working-interest share.

#Before you start

1. A cost recovery ledger for each well. A JIB credits it.
2. A partner ledger (AR for the Operator, AP for a Non-Operator) for every partner. It must exist in the company.
3. Costs on the well. Other modules count toward a JIB when their cost journal is reference-stamped to the well (reference type “well”); only posted, non-cancelled, non-reversed journals dated within the period are counted.
4. Permissions (granted to the JV-ACCOUNTANT role): oil_gas_jv.afe.submit, .afe.approve, .afe.close, .jib.generate, .statement.issue, .cash_call.create, .cash_call.fund and view permissions.

#1. Wells and partners

1. Create a well in Wells with a code, name, location and the Cost Recovery Ledger. Tick “This tenant is the Operator” if you run the well.
2. Add the co-owners in Partners: partner name, working interest %, partner ledger and active flag.

#2. Authorization for expenditure (AFE)

1. Create an AFE in AFEs with a unique AFE number, the well, the estimated amount (greater than zero) and optionally Block billing over this AFE.
2. Submit it (needs oil_gas_jv.afe.submit). If an active OILGAS-AFE approval workflow exists it starts; otherwise decide it manually with Approve or Reject (needs oil_gas_jv.afe.approve).
3. Close an Approved AFE when spending is finished (needs oil_gas_jv.afe.close).
4. The decision history shows every submit and decision; the variance view compares the estimate to billed JIB cost.

#3. Cash calls

1. Open Cash calls and raise a call against an Approved AFE: total amount to call (greater than zero) and a due date that is not in the past.
2. BSuit splits the amount across active partners by working interest so the rows add up exactly to the call.
3. When a partner pays, choose Record funding: amount received, received date, instrument (cash, bank transfer or cheque), reference, the bank or cash ledger received into, and an idempotency key. BSuit posts a Finance receipt (debit bank or cash, credit the partner’s ledger).

#4. Joint interest billing (JIB)

1. Open JIB, choose the well, the period start and end, and optionally the AFE and a narration.
2. Preview the split. Nothing is written. Warnings and blocks (overlapping period, AFE limit, mixed currencies) are shown here.
3. Generate. BSuit sums the well’s posted costs for the period, splits them by working interest and posts one journal per partner (debit partner AR, credit the well’s cost recovery ledger), all in one database transaction. A failure rolls everything back.

#5. Partner statements

On Partners open a partner’s statement to see its JIB lines (optionally for a period) with a running billed total and the AFE reference. Billed, not billed minus collected. Issue the statement (needs oil_gas_jv.statement.issue) to lock a permanent point-in-time copy of what was sent, which later JIB corrections do not change.

#Purpose and scope

This chapter covers the Hospitality module: rooms, rate plans, reservations and their lifecycle, the guest folio and its postings to the ledger, and the hotel calendar. The Hospitality home page shows today at the hotel (arrivals, departures and in-house guests) for the front desk.

#Before you start

1. Install the Hotel industry pack (Finance → Industry Packs). Folio postings use its ledgers (guest receivable GUEST-AR and guest advances GUEST-ADV, plus revenue ledgers). Without them posting fails with “Hotel ledgers not found — install the Hotel industry pack … first.”
2. Set the hotel time zone (see step 1).
3. Permissions: reservation create and edit for bookings, and named permissions hospitality.folio.charge, hospitality.folio.payment, hospitality.folio.refund, hospitality.folio.override, hospitality.reservation.override and hospitality.settings.manage. FRONT-DESK holds the day-to-day ones, without refunds, overrides or settings; HOSPITALITY-ADMIN holds all.

#1. Hotel settings

1. Open Settings and choose the hotel’s time zone as an IANA id such as Asia/Dubai or America/New_York (needs hospitality.settings.manage).

#2. Rooms

1. Create rooms in Rooms with a room number, type, floor, base rate per night and housekeeping status.
2. A new room must start as Vacant — Clean, Vacant — Dirty or Out of Order.
3. Use the housekeeping status to move a room between Vacant — Clean, Vacant — Dirty and Out of Order.

#3. Rate plans

1. Create plans in Rate plans: name, room type, nightly rate, optional season start and end (blank start means evergreen), the days of the week it applies to (none selected means every day) and a priority.
2. For each night, the active plan whose season and days cover the night wins, and a higher priority wins an overlap. If none matches, the room’s base rate is used.

#4. Book a stay

1. Open Reservations and choose New booking.
2. Enter the guest name (required), contact details, check-in and a later check-out date. The picker lists the rooms free for those dates, optionally filtered by room type.
3. Leave the rate blank to quote from the rate plans, or enter a negotiated rate per night. The quote total is shown.
4. Save. The reservation is Confirmed and holds the room for the nights.

#5. Check in

1. On the reservation choose Check in.
2. BSuit checks the room is active, not out of order and not occupied, and that the stay has not already ended.

#6. Change, cancel and reinstate

1. Use Move room to put an in-house or booked guest in another room, with a reason and an optional new rate. The target must be active, free for the nights and able to receive a guest.
2. Cancel needs a reason. The room is released immediately and, if a deposit is held, it is flagged for refund. A checked-in guest cannot be cancelled; check them out instead.
3. Reinstate brings a cancelled or no-show reservation back to Confirmed if the room is still free and the stay has not ended.

#7. The guest folio

1. Open the reservation’s folio. Charges can only be added to booked or in-house stays.
2. Add a charge (description, amount, type) or choose Generate room charges to post every night not yet charged, at that night’s rate. Re-running resumes from the first missing night, and a night already charged is not charged twice. Posting a charge debits guest receivable and credits revenue.
3. Take an Advance deposit (cash, bank or cheque) into the folio; it is held as a guest advance. Settle the folio to receive payment against the balance, and use Apply held deposit to balance to move a held deposit to the receivable.
4. Void a charge with a reason (a reversing entry is posted), or Refund deposit (needs hospitality.folio.refund and the cash or bank ledger it is paid from).

#8. Check out

1. Choose Check out. The dialog can post unposted room nights first and apply a held deposit to the balance.
2. BSuit re-reads the folio. If a balance is due, check-out is refused (“A balance of … is due … Settle the folio, or check out with the override permission”).
3. To leave with a balance, use Check out with balance due (override) with a reason; it needs hospitality.folio.override and is noted on the reservation.

#9. Calendar and availability

Calendar shows room occupancy across dates and the availability picker shows free rooms for a date range. Both follow the hotel’s own business date.

#Purpose and scope

This chapter covers the Insurance module (the C# module installed per tenant). It is not the “insurance” Industry Pack, which is a separate JSON-only configuration bundle; the two are unrelated systems that happen to share a key. The module does however post to ledgers that the Insurance industry pack creates, so both are needed (see below).

#Before you start

1. Install the Insurance industry pack (Finance → Industry Packs). Postings use its ledgers (policyholder receivable, unearned premium, claims expense and reserve, and the reinsurance ledgers RI-CEDED-PREM, RI-PAYABLE and RI-RECOVERABLE). Without it BSuit says “Insurance ledgers not found — install the Insurance industry pack … first.”
2. Permissions (granted to INSURANCE-MANAGER): insurance.premium.bill, insurance.premium.collect, insurance.policy.cancel, insurance.policy.lapse, insurance.claim.review, insurance.claim.reserve, insurance.claim.pay, insurance.claim.reject, insurance.claim.close, insurance.reinsurance.cede and insurance.reinsurance.recover. A tenant can delegate a single finance action without handing out the role.
3. A cash or bank ledger for collections and claim payments.

#1. Products, rating factors and quotes

1. Create Products with a code, name, category, base rate per sum insured, and optional minimum and maximum sum insured.
2. Create Rating factors for a product: a factor key (for example risk_zone:high) and a multiplier. The risk-zone, age-band and similar adjustments compound.
3. Use Quote on a product with a sum insured and a list of factor keys. Annual premium is the sum insured times the base rate, multiplied by every matching factor, rounded to 2 decimals at the end. Keys that match no active factor are reported back instead of ignored.

#2. Policyholders and policies

1. Create Policyholders as Individual or Organization, with an optional national ID or registration number used to recognise the same party across policies.
2. Create a Policy for the policyholder: product, coverage start and end (end after start), sum insured, premium (positive) and premium frequency: single, monthly, quarterly, semi_annual or annual. It starts as a Draft with a POL- number.
3. Issue the policy. This activates it and builds the installment schedule: the premium is split evenly across the periods and the last installment absorbs the rounding remainder.

#3. Bill and collect premium

1. On the policy open its installments and Bill each one when due (needs insurance.premium.bill). Billing debits policyholder receivable and credits unearned premium. At this point the premium is a liability, not revenue.
2. Collect a premium receipt (needs insurance.premium.collect) from the policyholder into a cash or bank ledger. It is allocated oldest installment first and capped at the outstanding billed balance; an installment becomes Paid once fully covered.
3. A daily sweep recognises unearned premium as revenue pro-rata over the coverage period. Only billed premium is earned, and re-running never double-earns.

#4. Renew

1. Choose Renew on a policy whose term is running or finished. BSuit creates a new Draft policy for the next term with the same length, starting the day after the old term ends, keeping the policyholder and optionally re-rating from the product.
2. Issue the new policy as in step 2.

#5. Claims

1. Record a claim in Claims against a policy. The policy must be active (or expired), the incident date must fall inside the coverage window and not be in the future, the reported date cannot be before the incident, and the claimed amount must be positive and within the sum insured. A heuristic fraud-risk score is calculated automatically on creation to help triage; it does not decide anything.
2. Start the review (needs insurance.claim.review). Status moves from Reported to Under review.
3. Reserve (needs insurance.claim.reserve): enter a positive reserve not above the claimed amount or the sum insured. BSuit posts debit claims expense, credit claims reserve, and the claim becomes Approved.
4. Pay (needs insurance.claim.pay) from a cash or bank ledger. Each payment debits the reserve and credits the ledger you choose, is recorded as its own payment, and cannot exceed the remaining reserve. When the paid amount reaches the reserve the claim becomes Paid; until then it stays Approved, so part payments are possible.
5. Reject (needs insurance.claim.reject) a claim that has no reserve yet, or Close (needs insurance.claim.close) an approved, paid or rejected claim. Closing releases any unpaid reserve (debit claims reserve, credit claims expense).

#6. Reinsurance (quota share)

1. Open Reinsurance treaties and create a treaty for an active policy: reinsurer name (required) and cession ratio above 0 and at most 1 (for example 0.3 for 30%). The total ceded share on one policy cannot exceed 100%.
2. Cede premium (needs insurance.reinsurance.cede): debit reinsurance ceded premium, credit reinsurer payable, for the cession ratio times the policy premium. For a cancelled or lapsed policy only the retained (earned) premium counts, so a cancellation shrinks the cession.
3. Recover claims (needs insurance.reinsurance.recover): debit reinsurance recoverable, credit claims paid, for the cession ratio times the total claims paid on the policy.

#Purpose and scope

This chapter covers the Legal Practice module: matters and their parties, conflict-of-interest screening, deadlines and tasks, time and expenses, fee arrangements, billing, receivables, and client trust accounting with its monthly three-way reconciliation.

#Before you start

1. The module installs its own billing ledgers and record types. If they are missing BSuit says “Legal billing ledgers not found — reinstall the Legal Practice module.”
2. A trust bank ledger for the firm, which you choose on each matter. Each matter gets its own client trust liability ledger (TRUST-<matter code>), created automatically in the Client Trust group when the matter is created.
3. The LEGAL-ADMIN role (or a superuser) for trust deposits, disbursements and reversals, conflict overrides, reports and trust reconciliation. Named permissions apply on top for money actions: legal_practice.payment.receive, invoice.write_off, invoice.credit_note, invoice.void, retainer.draw, trust.reverse and trust.reconcile.

#1. Open a matter and screen conflicts

1. Open Matters and create a matter with a unique code and a name. Status is Open, OnHold or Closed.
2. Add the client, opposing side and others in Matter parties (or on the matter’s Parties tab). The role is Client, Opposing, Related, Witness or Other.
3. BSuit screens every name on the matter (its own name and all its parties) against every party on other matters. A match is exact when the normalised names are equal and partial when one contains the other (names of at least 4 characters). The result is stored on the matter and refreshed after any matter or party change, so adding a clean party never erases an earlier hit.
4. You can also run a conflict check for any list of names before taking a matter on.

#2. Fee arrangement

1. On the matter set the fee arrangement type and terms. Payment terms must be 0 to 365 days and the default hourly rate cannot be negative. A rate card may give each attorney a rate (one row per attorney); the rate card wins over the arrangement default.
2. Hourly: bills recorded hours. Fixed fee: needs a fixed fee amount above zero and bills milestones (their total cannot exceed the fixed fee). Retainer: needs a retainer amount and a mode, Trust drawdown or Apply to invoice. Contingency: needs a percent above 0 and up to 100, and a recovery amount.

#3. Time, expenses and tasks

1. Record time in Time entries: matter, employee, hours (above 0 and at most 24) and rate. Or start a timer on a matter and stop it later. Time and expenses can be recorded only against an Open matter.
2. Record Expenses against an Open matter with a positive amount.
3. Track deadlines in Deadlines & tasks: status open, in progress, done or cancelled, due date and an optional reminder some days before. Overdue active tasks are flagged, and reminders can be sent. An open task cannot be added to a closed matter.

#4. Bill the matter

1. On the matter choose Bill. Select unbilled billable time, unbilled billable expenses, pending fixed-fee milestones, or a contingency fee, according to the arrangement.
2. BSuit posts one journal and creates one invoice snapshot atomically for the selection. Invoices are numbered INV-<matter code>-0001, sequential per matter.
3. For a contingency fee, BSuit bills the percentage of the recovery not yet billed.

#5. Collect, adjust and void

1. Open Receivables for open invoices and aging by days past due. Record a payment on a matter (needs legal_practice.payment.receive): amount, instrument (cash, bank or cheque), the cash or bank ledger it went into, and an idempotency key. If you give no allocation, it is applied oldest due first; allocations must add up to the amount and cannot exceed an invoice’s balance.
2. Write off or credit note an invoice (needs legal_practice.invoice.write_off or credit_note) with a positive amount up to the balance and a reason of up to 1,000 characters.
3. Void an invoice (needs legal_practice.invoice.void) to post a reversing journal and un-bill every line.
4. For a retainer matter in Apply to invoice mode, apply the retainer to an invoice (needs legal_practice.retainer.draw).

#6. Client trust

1. Open Trust controls for client funds held, exceptions (negative client balances, stale funds with no recent activity) and the reconciliation.
2. Deposit a client retainer into trust on the matter: debit the firm’s trust bank ledger, credit the matter’s trust ledger. Disburse to the firm as an earned fee or to a third party.
3. Reverse a trust transaction with a reason (needs legal_practice.trust.reverse). The original is flagged and never deleted, and a reversal cannot itself be reversed.

#7. Monthly three-way trust reconciliation

1. On Trust controls choose the trust bank ledger and a period end that is the last day of a month and not in the future. Enter the bank statement balance.
2. BSuit compares three figures: the bank statement, the general ledger balance and the total of the client ledgers. Save the draft (needs legal_practice.trust.reconcile).
3. Sign off. If the three agree within half a cent and no client balance is negative, signing records who and when. If not, you must resolve the difference or sign with a variance explanation of at least 10 characters.

#Purpose and scope

This chapter follows a manufactured product from its bill of materials to finished goods: master data, material requirements planning (MRP), production orders and work orders, capacity scheduling, quality inspection and costing. The Manufacturing home page lists production orders, work orders, BOMs and overdue jobs.

#Before you start

1. Products (finished, semi-finished and raw) exist in the product master, and warehouses are set up (see “Inventory operations”).
2. Work centers exist in Work centers; standard steps exist in Operations.
3. Sales orders, forecasts and existing production orders are the demand MRP reads, so keep them current.

#1. Bills of materials and routings

1. Open BOMs, create the BOM header for the product and add the component lines.
2. Build the routing in Routings with its steps in Routing operations; each step names a work center and a sequence.
3. Submit the BOM for approval, then approve it.

#2. Planning parameters and the master schedule

1. In Planning parameters set, per product, the planning group (Raw Material, Finished Goods, Semi-Finished, Packaging), ABC class, preferred vendor, lead time in days, safety stock, reorder point and reorder quantity.
2. Choose a lot sizing method: LFL (lot for lot), FOQ (fixed order quantity) or EOQ (economic order quantity), with fixed, minimum and maximum order quantities where relevant.
3. Optionally capture demand in Demand forecasts and plan the master production schedule in MPS plans; the MPS workbench shows a product by period matrix with available-to-promise and can recalculate it.

#3. Run MRP

1. Open the MRP dashboard.
2. Set Plan From and Plan To and tick what to include: Production Orders, Forecasts, Safety Stock.
3. Choose the Plan Mode: Regenerative re-plans everything; Net Change re-plans only items whose demand or supply changed since the last run.
4. Choose Run MRP. The run header shows the number, status and the totals for purchase, produce and transfer recommendations.
5. Review each result: planned quantity, net and gross requirement, stock, safety stock, lot method, required date, suggested order date and what it is pegged to. Use the Peg trace to see the demand behind a line.
6. When the run is Completed, choose Confirm to lock it from re-execution.

#4. Convert recommendations

1. Use the All, Purchase, Produce and Transfer tabs (a tab appears only if it has results) and search by product.
2. Select the unconverted lines, then convert to Purchase Requisitions (for bought items) or Production Orders (for made items).
3. Converted lines are dimmed and marked “Converted to …”; they cannot be converted twice.

#5. Production orders and work orders

A production order is created by conversion, from a sales order, or by hand in Production orders (product, BOM, routing, planned quantity, dates, warehouse, department, project, cost centre, priority Low/Normal/High/Critical). The Materials tab lists required materials and can be populated from the BOM.

#6. Capacity and the shop floor

1. In the Capacity schedule drag a work order to another work center or day, or tap it to change the work center and start/end dates. Each cell shows planned versus available hours and the load percentage.
2. The Work center board shows live Andon status and Availability, Performance, Quality and OEE for the last 24 hours.

#7. Quality inspection

1. Define what is measured in Quality parameters.
2. Record an inspection in Quality inspections against a work order or production order: date, inspector, quantity inspected, passed and rejected.
3. Enter a measurement per parameter in Inspection results.

#8. Production costs

Production costs tracks cost lines per production order. Each line has a type — Material, Labor, Overhead or Subcontracting — with quantity, unit cost, total, cost centre and optional work order.

#Purpose and scope

This chapter covers the Real Estate module: listings for sale, rent and lease, buyer and renter inquiries, viewings, offers, the deal record, local market comparables and stale-listing tracking. Buyers and renters reach published listings through the public site and customer portal, and their inquiries, viewing requests and offers land in the same pipeline.

#Before you start

1. The roles PROPERTY-MANAGER and LEASING-AGENT are seeded. A leasing agent sees and changes only the records assigned to them; managers, administrators and superusers see everything.
2. Two actions have their own named permissions: realestate.propertylisting.publish (publish, unpublish and archive a listing) and realestate.propertyoffer.accept (accept an offer).
3. An agent assigned to each listing, so viewings can be scheduled and the public can reach the right person.

#1. Create and publish a listing

1. Open Property listings and create a listing: title, listing type (sale, rent or lease), property type, price, currency, rent period for rentals, address, city, country, bedrooms, bathrooms, area, amenities, images (one URL per line), expiry date and assigned agent.
2. Use the row actions to change status. The status cannot be edited as a field.
3. Publish. The listing needs a price greater than zero, a city and at least one image, and its expiry date cannot be in the past.

#2. Check the price with comparables

1. Enter local Market comparables with an as-of date. Comparables older than about 18 months are excluded.
2. The listing’s Price check compares your price with the average of comparables for the same segment (listing type, property type, city and bedrooms), falling back to your own published listings when there are too few. With fewer than 3 data points there is no suggestion.
3. A price at least 25% away from the suggestion is flagged as an outlier.

#3. Inquiries

1. Open Property inquiries. Inquiries arrive from the public site or are entered by an agent (company and agent are copied from the listing).
2. Move an inquiry along with Mark contacted, Close or Spam. Statuses are New, Contacted, Viewing scheduled, Closed and Spam. A closed inquiry can be reopened to Contacted, and Spam back to New.

#4. Viewings

1. Open Property viewings and schedule a viewing on a published listing: start and end time, optionally linked to an inquiry.
2. A viewing must be in the future, end after it starts, and last between 15 minutes and 4 hours.
3. Buyers can also request a viewing from the public site with up to 3 preferred times within 90 days. That creates a Requested viewing, which holds no slot. Confirm it with the buyer’s time or another, and the buyer is emailed.
4. Complete, cancel, reschedule or mark a viewing as no-show.

#5. Offers

1. Open Property offers and make an offer on a published listing: amount above zero, an expiry in the future, and a contact name or a linked inquiry.
2. Use the row actions: accept, counter, reject or withdraw. A counter marks the original Countered and creates a new open offer with the new terms.
3. Accept (needs realestate.propertyoffer.accept). This reserves the listing and supersedes every other live offer on it in one step.

#6. Close the deal

1. Mark the reserved listing Sold or Rented. BSuit creates one deal record from the accepted offer (idempotent) and closes the linked inquiry.
2. Open Property deals. Deals are created only this way and cannot be created by hand or deleted; cancel a deal instead of deleting it.
3. Record the downstream record type and its id or number on the deal to mark it Handed off. Until then it is Pending hand-off.

#7. Stale listings and public alerts

Stale listings lists Published listings that were published more than N days ago (60 by default), oldest first, so you can reprice or re-list. Customers can save property searches on the public site; an hourly background job emails matching alerts for the listings of their own company only.

#Purpose and scope

This chapter covers the Developer menu (the AI Studio module's low-code surface): custom and built-in entity definitions, the form builder, governed change requests, custom applications, business rules, notification rules, form actions and audit configuration. The Developer home page lists these tools.

#Before you start

1. The Developer menu group is admin-only. The change-request surface runs and generates database DDL, so it is restricted to a superuser or the Admin role, and a portal token can never authorise it.
2. The module declares three separately activatable capabilities because they can change tenant behaviour and data models: Runtime Forms & Custom Entities (entities, form builder, applications), Governed Schema Change Workflow (change requests) and Developer Automation Rules (business rules, notifications, audit configuration). Ask your administrator which are active for your tenant.
3. Work in a development environment first and promote with an exported package.

#1. Entities and fields

1. Open Entities to see custom and built-in entity definitions. Create a custom entity, or extend an existing standard module table by choosing the target module key, entity key and table name.
2. Add fields with a snake_case name (lowercase letters, numbers and underscores, starting with a letter) and a data type: string, integer, decimal, boolean, date, datetime or text.
3. Add relationships: One-to-Many (a foreign key column) or Many-to-Many (a junction table).
4. To make an entity usable by outside users, set Portal Exposure to customer, vendor or careers, name the owner field (required), and optionally allow portal users to create rows (the owner is stamped by the server).
5. For approval, set the status field, the approval record type (default CUST-<entity key>) and mark the entity Submittable. For finance, switch on posting: choose the posting record type (default JV), the amount field and the debit and credit ledgers (or per-row ledger fields); a journal voucher is posted when an approved row is finalised.

#2. Forms

1. Open Form builder. A form has tabs, fields and grid columns that you can reorder. Regenerate rebuilds a form from its entity.
2. Save a version to keep a commit-style history with diffs, and restore an earlier version when needed.
3. For shipped (standard) forms you save a customization layout instead of editing the original.

#3. Change requests

1. Open Change requests. A change request collects entity and field changes (statuses: draft, released, applied, rolled back, failed).
2. Preview SQL first. Release a draft change request: BSuit generates the forward and rollback SQL from the entity definitions and gives it the next sequence number.
3. Apply (shown as Activate) a draft, released or rolled-back change request. BSuit runs the DDL, deploys the entities, registers permission codes, registers menu items, publishes form layouts, unlocks the objects and records the change in the applied ledger.
4. Roll back an applied change request to run its rollback SQL, set entities back to draft and deactivate the menu items. A rolled-back change request can be reset to draft.
5. Export a change request as a package and import it into another environment; the import creates a draft change request.

#4. Custom applications

1. Open Custom applications and create an application with a key (permanent, it cannot be changed), a name, icon, colour and order. A key owned by a compiled BSuit module is refused.
2. Optionally use Design with AI. It produces a review-only blueprint; accepting it creates inactive metadata and a draft change request, and does not release, apply or publish anything.
3. Activate the application. It must pass the readiness check: at least one entity, every entity deployed, a form for every entity, and every linked change request applied. The blockers are listed.
4. Export the application package to move it.

#5. Business rules

1. Open Business rules and create a rule for an entity with a trigger (before save, after save, on load, on field change or on delete), conditions in JSON and a priority (lower runs first).
2. Choose actions: set a field (supports {current_user}), throw an error (blocks the save on before save), set required, set read-only, set visible, or run a sandboxed script.
3. Use trace to test a rule against sample data without applying it.

#6. Notifications and form actions

1. Open Notifications and create a rule for any entity (built-in or custom) with a trigger event (create, update or delete), optional conditions, channels (in-app, email, SMS, push), title, body and link templates with {field} placeholders, and recipients: followers, specific users (comma-separated ids), a role, or a field holding a user id.
2. Open Form actions to add buttons to an entity’s form: start the record’s approval workflow, run a read-only sandboxed script, or call a pre-registered integration endpoint (never a free-text address).

#7. Audit configuration

1. Open Audit config and create a policy for an entity key: enabled flag, which operations to audit (creates, updates, deletes, views), fields to exclude, and retention days (365 by default).

#Purpose and scope

This chapter follows a project from demand intake to billing. The Project Management home page shows budget versus actual, status, completions and overdue attention items, and the Dashboard gives the project view.

#1. Intake: from idea to project

1. In Intake create an intake with a code, title, description, business case, requester, estimated cost, estimated benefit and score.
2. Move the Stage through Idea, Review, Approved or Rejected.
3. Choose Convert on a row that is not rejected or already converted.

#2. Create a project

1. Either start from a template: Templates lists reusable blueprints; choose Instantiate and give a project name. BSuit creates the project with its WBS, activities and milestones and reports how many of each.
2. Or create it directly in Projects: group, manager, location, status, priority, planned and actual dates, currency, budget, estimated cost and revenue method.

#3. Plan the work, budget and people

1. Break the scope down in WBS and Activities; group work under Epics for agile projects.
2. Set the working calendar in Calendars and holidays in Calendar exceptions.
3. Enter the cost budget by category in Budget lines.
4. Allocate people in Resources, with cost and billing rates in Resource rate cards. The Workload heatmap shows allocation by week and flags over-allocation in red.

#4. Track delivery

1. Follow the plan on the Gantt and the Kanban board; Sprint analytics shows burndown and velocity for agile projects.
2. Log risks in the Risk register and problems in Issues.

#5. Change orders

1. Record a change request in Change orders with its cost impact and schedule impact in days. Status starts as Draft and can be Submitted.
2. Use the Approve or Reject row action to decide it.

#6. Forecast cost and profitability

Cost forecast and P&L shows BAC (budget), Committed, Actual, EAC (forecast), ETC (to complete) and VAC (variance) by cost category, plus margin.

#7. Billing and revenue recognition

1. Record billing items in Billing: billing type (Milestone, Time & Material, Fixed Fee, Percent Complete), amount, status Draft, Invoiced or Paid, invoice date and whether it is billable.
2. For percent-complete revenue, pick the unbilled receivable and revenue ledgers and choose Recognize.

#Purpose and scope

This chapter covers a contract from template to payment. The Contract Management home page shows status, value, payments, top contractors and expiries; the Contract dashboard gives an overview of contracts, payments and compliance.

#1. Templates and clauses

1. Keep reusable wording in Contract clauses.
2. In Contract templates set the contract type (Fixed Price, Time & Material, Unit Rate, Lump Sum or Cost Plus), default payment terms, default retention %, default warranty months and a boilerplate body.

#2. Draft the contract

1. Open Contracts. Create a contract directly, or pick a template to create a draft from it (the draft is created and its code is shown).
2. Fill in the contract code, name and scope of work; type; the contractor or consultant company; optional project, WBS element and parent contract (for a sub-contract); start, end and signed dates; warranty; and the commercial terms (retention, advance, performance guarantee percentages, payment terms).
3. On the Cost Code Lines tab enter the scope lines, each budgeted to a project cost code. Cost codes are maintained in Cost codes.

#3. Submit for sign-off

1. In the contract list choose Submit for sign-off on a Draft contract and confirm.
2. BSuit starts the approval workflow configured for the contract record type and moves the contract to Submitted. It stays in the workflow until every approver signs off, then becomes Active with the signer and date stamped.

#4. Clause extraction and electronic signature

1. Open a contract. The AI clauses tab extracts payment terms, deliverables, penalties, termination clause and expiry date from pasted contract text or an uploaded PDF, with a confidence score. The result is for review only; contract fields are never changed automatically. You can then create trackable obligation rows from the extracted obligations.
2. On the signature tab create a signature envelope, add each signer with an email, role and signing order, and choose Send for signature. Signers get their links; you can copy a signing link or void the envelope.
3. Track envelopes and signer status in Signature envelopes.

#5. Obligations, compliance, alerts and evaluations

#6. Variations (change orders)

Variations runs a three-stage pipeline: DCOR (draft change order request), COR (change order request, submitted) and CO (approved change order), each with its own page (DCOR, COR, CO). Variation types are Addition, Omission, Substitution and Time Extension; statuses are Proposed, Under Review, Approved, Rejected and Implemented.

#7. Milestones

1. In Milestones record payment milestones with a due date and amount.
2. When the work is accepted choose Achieve and confirm. The achieved date is stamped and a journal is posted to finance (or submitted for approval if a workflow is configured).

#8. Payments and RA bills

1. Record payments in Payments (all kinds), Progress payments (RA bills and final bills) or Miscellaneous payments (advance, mobilisation, retention release, other).
2. Save with a positive net payable, then choose Post to Finance.
3. The payment moves through Draft, Submitted, Verified, Pending Approval, Approved, Paid or Rejected. Once posted, the record is read-only and shows the journal number.

#Purpose and scope

This chapter covers the Client Licensing module: licenses that a vendor issues to its clients, and the licence installed on a host. It is not the ERP’s own subscription (see Account → Subscription). The module is admin-only: a superuser or the Admin role.

#Before you start

1. An administrator account. Generating a key is further restricted to a superuser on the platform owner’s host, which is the only place the private signing key is installed. Customer or on-premises hosts carry only the public key, which is enough to verify and activate.
2. The Client licensing home lists License Status, License Request, License Plans, Client Licenses and License Generator.

#1. License plans

1. Open License plans and create a plan with a code, name, edition (Starter, Standard, Professional or Enterprise), duration in months, the modules allowed (JSON array), seat limits and prices.
2. Seats come in four kinds: named, named concurrent, guest and guest concurrent, each with its own price. “Max users (legacy total)” is kept for older licenses.
3. Mark a plan inactive to stop new licenses being issued against it.

#2. Create a license request

1. On the host that needs the license, open License request and generate the request file. It carries a machine fingerprint (machine id), the host name, the operating system and the BSuit version.
2. Send the file to the vendor.

#3. Generate the signed key (platform owner)

1. Open License generator as a superuser. Load the request file, or enter the customer name and the machine id.
2. Pick an optional plan to auto-fill, then confirm the edition, maximum concurrent users (at least 1), the modules, and the validity in months (1 to 120). Seat limits cannot be negative.
3. Generate. BSuit signs the license JSON with RSA-SHA256, creates a client license record and writes an “issued” history row in the same transaction. Send the key to the customer.

#4. Activate the license on the host

1. Submit the signed license JSON to the activation endpoint (POST /api/license-management/activate). BSuit verifies the RSA signature, requires a license code and a machine id that matches this host, and then stores it as the host’s active license with an activation history row.
2. A license that is already active is answered with “License already active”.

#5. Check status and expiry

License status shows the active license: code, customer, edition, maximum concurrent users, modules allowed, valid from and until, days remaining, machine id and activation time. A license is valid through its valid-until date and expires the day after; it becomes valid on its valid-from date. An expired license reports as unlicensed (“License has expired”) so the host falls back to the unlicensed behaviour, and with no license it reports unlicensed with the machine id. An hourly background worker also marks the stored client licenses expired.

#6. Renew, suspend and revoke

1. Open Client licenses for the issued license records and their history. Statuses are Active, Expired, Suspended and Revoked.
2. Renew: enter the number of months (1 to 120). The new expiry is counted from the later of the current expiry and today. An expired or suspended license becomes Active again, and the host’s local keys are revalidated.
3. Suspend: invalidates the host’s local key, so the host reports as unlicensed on its next status check.
4. Revoke: invalidates the host’s local key immediately and permanently.

#Purpose and scope

This chapter follows a sales opportunity from first contact to a won deal. The CRM home page shows the pipeline, weighted forecast, opportunities and attention items. After the win, the order continues in the order-to-cash chapter.

#Before you start

1. Pipeline stages exist in Pipeline stages: each has a code, name, probability, sort order, colour, and Won and Lost flags.
2. Lead sources are set up in Lead sources.
3. Sales teams, members, territories and quotas are in Sales teams, Team members, Territories and Quotas (monthly, quarterly or yearly target and achieved amounts).

#1. Capture and qualify leads

1. Create leads in Leads: name, email, phone, mobile, company, designation, industry, website, source, address and notes. Website contact forms can also create leads.
2. Move the Status through New, Contacted, Qualified, Converted or Lost.
3. Before converting, use the duplicate search (by email, phone or company) to find matching leads and accounts. At least one of the three is required.
4. To combine duplicates, merge the duplicate lead into the surviving one: its activities move to the survivor, blank fields on the survivor are back-filled, and the duplicate is marked merged.

#2. Score and segment

1. In Lead scoring rules define rules as field + operator + value + points. Fields: name, email, phone, mobile, company, designation, industry, website, country, status. Operators: Equals, Not equals, Contains, Is not empty, Is empty.
2. Active rules are evaluated against a lead to set its Score. A lead can be scored individually, or all leads that are not converted can be re-scored in bulk.
3. Group leads with Lead segments, which use the same field and operator conditions; choose Members to see who matches.

#3. Nurture with sequences

1. Build a cadence in Sales sequences and its timed steps in Sequence steps.
2. Enrol a lead or contact; Sequence enrollments lists the sequence, status (Active, Paused, Completed), current step and next action time.
3. Mass outreach uses Campaigns and Campaign members; wording is kept in Comm templates.

#4. Convert a lead

Converting a lead that is not already converted creates an account from the lead’s company, industry, website, contact and address details, and an opportunity named “Opportunity - <company>” linked to that account. The lead is marked converted and keeps links to the new account and opportunity, and a system entry is added to the timeline. A lead already converted is refused (“Lead is already converted”).

#5. Work the pipeline

1. Complete the opportunity in Opportunities: name, account, amount, expected close date, probability and next step.
2. Add product lines on the Line Items tab (Opportunity products); they roll up to the opportunity amount.
3. Open the Pipeline board and drag each opportunity between stage columns to update its stage. An Unassigned column holds deals with no stage.

#6. Issue a quote

1. On the opportunity open the quote tab and choose Issue Quote. The current line items are locked into a numbered, printable Quote / Proposal.
2. If you edit the lines and issue again, a new version (v2, v3 …) is created; a version already sent is not changed.
3. Use Print on an issued version to open the document.

#7. Win the deal

1. On the opportunity open the Win tab and choose Win.
2. If an approval workflow is configured for the win record type, the opportunity shows Win Pending Approval and the win is applied when approved. Otherwise it is applied immediately.
3. The result is a draft sales order built from the opportunity’s product lines, with its order number shown on the opportunity. Continue in the order-to-cash chapter.

#8. Forecast

Sales forecast shows Weighted Forecast (amount × probability of open deals), Commit (won), Best Case (commit plus open pipeline) and Pipeline, by period, stage and owner. Compare against Quotas.

#Purpose and scope

This chapter covers the Master Data Management module: duplicate detection and review for products, suppliers and employees, golden-record aliasing, data-quality scoring and the enterprise relationship graph.

#Where Master Data Management is in the menu

Master Data Management has no sidebar entry of its own. The module declares no sidebar group and is deliberately not a standalone application tile; /master-data-management simply redirects to its Duplicates workspace. In the source, the same three pages are declared as admin-only items of the Administration menu (Duplicate Review, Data Quality and Relationships under /administration/master-data/…), and those addresses show the same pages. If you cannot see them in the sidebar, open Duplicates, Quality or Relationships by address, and ask an administrator to check your access.

#Before you start

1. The module is admin-only. Reading candidates, quality scores and resolving an alias is open to any authenticated user of this admin module; every change needs a named permission (granted to MASTER-DATA-ADMIN): master_data_management.duplicate.scan, .duplicate.review, .duplicate.merge, .duplicate.unmerge and .relationship.manage.
2. Two separately activatable capabilities: Master Data Quality (scans, candidate queues, quality scores, history) and Master Data Governance (reviewing and merging candidates and maintaining relationships). Governance is meant for tenants that have a data-steward process.
3. The module depends on Product Management and Procurement.

#1. Scan for duplicates

1. Open Duplicates and choose Refresh assessment for the entity type: products, suppliers or employees (needs master_data_management.duplicate.scan). Other types are refused.
2. BSuit groups records by shared keys (exact identifiers such as barcode, SKU, licence, VAT, e-mail or phone, plus name-based keys) and compares only records that share a group. Pairs scoring at least 0.65 become candidates. Scores weigh exact identifiers and name similarity; employees weigh e-mail, phone and date of birth.
3. The scan also calculates a quality score and issues for each record.

#2. Review a candidate

1. Open a candidate to see the side-by-side comparison of the fields the matcher compared and the reasons it matched, such as same email or a very similar legal name.
2. Review (needs master_data_management.duplicate.review): choose Not duplicate, Confirm (confirmed duplicate) or Keep A / Keep B (merge planned, with the golden record). The golden record must be one of the two records. A suggested golden record is shown only when one side is clearly more complete; on a near tie you must choose.
3. Add notes. The history shows who decided what.

#3. Record an alias (merge) and undo it

1. On a candidate reviewed as merge planned or confirmed duplicate choose Record alias (needs master_data_management.duplicate.merge). BSuit records a reversible alias from the source record to the golden record.
2. To undo, choose Unmerge (needs master_data_management.duplicate.unmerge). The alias is deactivated, kept as an audit record, and the candidate returns to confirmed duplicate. Unmerging an already unmerged candidate does nothing.
3. Other modules can resolve a record to its golden record through the resolve lookup; it follows active aliases and is cycle-safe.

#4. Data quality

Quality lists completeness and validation issues ranked by lowest score first, for each entity type. Run an assessment to calculate scores; a record’s history shows how its score changed.

#5. Enterprise relationships

1. Open Relationships, enter a root entity type and ID, and load its graph (1 to 3 levels). Click any node to re-root the graph on it.
2. Choose Add Relationship (needs master_data_management.relationship.manage): source entity type and ID, the relationship type, and the target entity type and ID. All fields are required.

#Purpose and scope

This chapter covers the document life cycle in Document Management: organising files, versioning and check-out, the review and publishing states, transmittals, sharing, retention rules and recovery. Other modules also attach files to their own records; those files are stored in the same document store and appear under automatically created attachment folders.

#Before you start

1. Define document categories in Categories (code, name, colour, icon, sort order).
2. Decide who may approve documents. Approvals and publishing use the workflow engine (see “Workflow automation”); the publishing workflow is linked to the record type DMS-DOC and transmittals use DMS-TRANS.
3. Check the denied upload extensions with your administrator. The upload guard rejects files on the extension denylist and files whose content is an executable, whatever their extension.

#1. Organise and upload files

1. Open Browse. Create folders in the tree, then upload files into a folder.
2. Open a file to see its properties, versions, comments and tags. Details and grid views are available, and you can filter by lifecycle status.
3. Folders can be renamed, copied, moved, pasted and downloaded as a ZIP. Deleting a file or folder sends it to Trash.
4. Folder permissions are set per role (view, upload, download, delete, folder upload, folder download, edit metadata, check out, approve, share, print, comment).

#2. Versions and check-out

1. Upload a new version from the file. The previous version stays in the history and the new one becomes the latest version, keeping the folder, lifecycle status, category and custom metadata.
2. Check a file out before editing it offline. Only one user can hold a check-out at a time.
3. Check it in when finished. Uploading a new version as the person who holds the check-out also clears the check-out.

#3. Complete the document register

1. Open Document register. Search by name, document number, code or author, and filter by status, type or confidentiality.
2. Double-click a row to edit: name, document number, revision, status, type, confidentiality, author, category, department, source, language, physical location, effective, expiry and review dates, description.
3. The footer shows the number of documents, the total size and counts per status and type.

#4. Lifecycle, review and publishing

1. A new file starts as Draft. In Browse choose Submit for publishing on a draft file and confirm. This starts the workflow linked to DMS-DOC and sets the file to Review.
2. When the workflow is approved the file becomes Published. When it is rejected the file returns to Draft and the reason is appended to its description.
3. Other status changes follow the allowed moves in the table below; a move that is not allowed is refused and the allowed list is shown.

#5. Per-reviewer approvals

1. Open Approvals. Each row shows the file, who requested it, the approver, status, comments and dates.
2. The designated approver chooses Approve or Reject and may add a comment. Only pending approvals assigned to you can be decided, and a decided approval cannot be decided again.
3. Deciding also sets the file’s lifecycle status to Approved or Rejected.

#6. Transmittals

1. Open Transmittals and create one with a subject, from and to company, attention, sent by (required), sent and due dates, purpose, priority and remarks.
2. The Items column shows how many documents are on the transmittal.
3. Track the status through draft, review, approved, sent, acknowledged and closed.

#7. Follow-ups

1. Open Follow-ups and add one for an official document, a document transmittal, a shipment or a shipping container.
2. Set the owner, next action, due date, priority (low, normal, high, urgent) and, if needed, who to escalate to.
3. Move the status through open, in progress, blocked, completed or cancelled.

#8. Share links, retention and recovery

1. Share links lists links with their token, file or folder, creator, downloads (against any maximum), expiry and status. Revoke a link after confirming.
2. Retention policies defines a number of retention days, an action (Archive, Destroy or Review) and optional notify-before days.
3. Trash has separate tabs for deleted files and folders; choose Restore to bring an item back.
4. Access logs records time, user, action, file, folder, details and IP address. Storage statistics shows totals for files, folders, storage, uploads in the last 7 days and checked-out files.

#Other tools in this module

#Purpose and scope

This chapter covers the Employee Engagement module: peer kudos, HR-issued awards, pulse surveys and the suggestion box. Employees use their own pages (Kudos wall, Pulse surveys and Suggestions); HR and leadership use the Engagement menu. The module is switched on by the engagement feature flag.

#Before you start

1. The Employee Engagement module installed and its feature on.
2. Employee records for the people involved, and each employee’s user linked to their employee record so that “Give kudos” and “Suggest” know who is acting.
3. The Engagement home page lists Kudos wall, Awards, Pulse surveys and Suggestions.

#1. Kudos

1. Employees open Kudos wall and choose Give kudos: pick a colleague, write a message and choose a tag (for example teamwork). Kudos are sent as public.
2. HR reads the full feed in Engagement › Kudos wall, a read-only list of all peer recognition with the sender, recipient, tag, public or private flag, date and message.

#2. Awards

1. Open Awards and issue an award: an award type code (free text, for example STAR_OF_QUARTER), the recipient, an optional monetary value and currency, and a citation.
2. BSuit stamps who issued it and when. You can edit an award (type, recipient, citation, value) or delete it.

#3. Pulse surveys

1. Open Pulse surveys and create a survey: title, launch and close dates, whether responses are anonymous (on by default) and the questions as a JSON array. Each question has a q (the text), an optional type and, for multiple choice, an options list. Title and questions are required.
2. Employees see active surveys in My pulse surveys (the mobile ESS app also lists them). They answer each question and submit.
3. Open a survey to see the aggregated results: per-question distributions (option counts for multiple choice, a response count for free text) and a daily timeline of responses.
4. For a survey that is not anonymous, HR can export the raw responses as CSV with the employee id and one column per question.

#4. Suggestion box

1. Employees open Suggestions, choose Suggest, write a title and body (both required) and decide whether it is public on the wall. The author is always recorded for accountability, but is hidden when the suggestion is public.
2. Other employees can upvote public suggestions on the Wall tab; Mine shows your own.
3. Leadership opens Engagement › Suggestions, filters by status and chooses Update to set the status and write a response, which the employee sees.