The OSERP knowledge collection
One place to learn. A reference to return to.
For the cashier serving a customer, the accountant explaining a balance, and the administrator setting up a business. Learn the reason behind each step, then keep the reference close as you work.
Built to be trusted
Clear evidence. Visible coverage.
This founding edition combines reviewed guides with a screen inventory extracted from OSERP. Each reference states what has been checked. The coverage register identifies details still awaiting operational verification; it does not equate an inventory with a complete user manual.
View documentation coverage → · Read with an AI assistant →
---
Source: https://learn.oserp.in/manual/accounting
---
description: Use OSERP ledgers, journals, allocation screens, financial reports, and posting-period controls.
---
# Accounting and period close
Accounting work begins with the company, chart of accounts, currency, and period. The ledger structure and posting rules determine how operational activity appears in the books. A balanced report is necessary, but it does not by itself prove that the correct accounts or dates were used.
## Prepare the accounts
Use [Account Groups](/atlas/screens/accounting-groups) to organize accounts and [Ledgers](/atlas/screens/accounting-ledgers) to maintain individual posting accounts. Review the classification and intended use with the person responsible for accounting policy. Link operational posting rules to the appropriate accounts before processing transactions.
**GL Mapping** at `/settings/gl-mapping` controls configured posting behavior. Review the applicable document/stage combination and account determination. A sale that has been operationally completed can still need investigation if its accounting stage failed.
## Enter a journal
Open [Journal Entry](/atlas/screens/finance-journal-entry). Select the voucher type and date, enter a reference and narration where appropriate, and add ledger lines. Use a narration that explains the business event, not only a repetition of the amount.
The reviewed voucher normalizer requires at least **two lines** and a positive total debit. It totals base-currency debits and credits and rejects an imbalance greater than **0.01**. A small difference up to that threshold is adjusted in the normalization logic; review the posted base values when reconciling foreign-currency rounding.
For foreign-currency lines, the exchange rate is required and must be greater than zero. The system resolves the company's base currency rather than assuming every company uses the same currency. A revaluation adjustment has special base-only handling; ordinary journal users should not substitute that for a normal foreign-currency transaction.
Review the transaction and use the permitted save/post workflow. Confirm its final status and trace the posted lines into General Ledger. Saving a form alone does not prove posting succeeded.
## Understand the dates
Voucher date determines the accounting date. Document date can describe the original supporting document. Baseline date, due date, and value date serve different settlement or reporting purposes. Do not change the accounting date solely to make an overdue receivable appear current.
Payment terms determine expected settlement timing. Confirm whether an inherited term or a manually entered due date is responsible for the value on the document.
## Allocate money to open items
Use [Allocate Receipts](/atlas/screens/accounting-allocate-receipts) for incoming settlements, [Allocate Payments](/atlas/screens/accounting-allocate-payments) for outgoing settlements, and [Allocate COD](/atlas/screens/accounting-allocate-cod) for supported courier cash-on-delivery reconciliation.
Select the correct partner, currency, and open documents. Allocate only the amount actually being settled. A payment record and allocation to an invoice are separate facts; an unallocated receipt can exist while an invoice remains open.
For a short courier payout, compare the collections covered, amount received, fees, and residual balance. Do not assume an unexplained difference is automatically a write-off.
## Select the right report
| Report | Question it helps answer |
| --- | --- |
| Trial Balance | What are the account balances at the selected point or period? |
| General Ledger | Which posted lines explain an account balance? |
| Day Book | What voucher activity occurred in the selected period? |
| Profit and Loss | What income and expense activity contributes to the result? |
| Balance Sheet | What asset, liability, and equity balances are represented? |
| Cash Flow | How does the configured report classify cash movement? |
| Customer / Supplier Statement | Which partner transactions and settlements explain the balance? |
| Tax Summary | What tax amounts are represented by the selected activity? |
Use consistent filters when comparing reports. Exported data should be checked for its company, date range, currency, and status selection before sharing.
## Posting periods and close
The reviewed period guard allows a date in an **OPEN** period and refuses dates in **CLOSED** or **LOCKED** periods. When a company has a calendar but no period covers the date, posting is refused. When no calendar exists at all, this guard is permissive. Therefore a business that needs period controls must actually configure and maintain its calendar.
A close routine should reconcile operational documents, stock, receivables, payables, cash/bank balances, tax, and adjustment journals before locking the period through the supported administration process. Keep approval evidence and report copies according to business policy.
## Troubleshooting
For an imbalance, inspect line currencies, rates, and entered debit/credit values. For a period refusal, check the date and defined calendar. For a missing posting, inspect document status and posting messages before entering a replacement journal. For a wrong balance, drill to the contributing records rather than editing a master balance to force agreement.
---
Source: https://learn.oserp.in/manual/administration
---
description: Configure OSERP company settings, user permissions, numbering, print layouts, imports, and operational controls.
---
# Administration and access
Administration establishes the operating environment. Changes can affect future transactions across several teams, so record the reason, verify the result, and communicate operational changes through your organization's normal process.
## Know which screen owns a setting
| Area | Application screen |
| --- | --- |
| Company identity and print profile | `/admin/company-profile` |
| Company feature configuration | `/admin/general-settings` |
| Branches | `/admin/branches` |
| Document/record numbering | `/admin/numbering` |
| Users and roles | `/admin/users`, `/admin/roles` |
| POS configuration and payment types | `/admin/pos-settings`, `/settings/payment-types` |
| Print layouts | `/settings/print-layouts` |
| GL posting mappings | `/settings/gl-mapping` |
| Order stages | `/settings/order-stages` |
| Import work | `/admin/imports` |
| Notifications | `/admin/notifications` |
## Give people the access they need
Create or maintain individual users and assign appropriate roles. Review company scope and intended operations. The menu table determines what is offered; the server separately protects actions. A broad-looking role name is not proof of access to restricted payroll operations.
Test a representative user account for the intended job. Confirm both that permitted work succeeds and that unrelated sensitive screens/actions are unavailable. Do not share one user's credentials among cashiers or use a real employee's account for training.
## Configure numbering
Review the record/document type, series, prefixes, and current sequence before enabling automatic numbering. Existing documents must remain identifiable. A sequence setting is not permission to reuse historical document numbers.
After changing a series, create a demonstration record and verify the assigned number and duplicate handling. Do not manually reserve a production number by creating a fake financial transaction.
## Set up print output
Company Profile supplies business identity data; Print Layouts controls supported presentation. Review both. Preview an authorized sample document, confirm company identity, currency, dates, item quantities, tax breakdown, totals, and page layout, then check the actual printer path used by staff.
## Import records
Use the current template and supported import screen for the intended entity. Match codes, units, currencies, and required references. Start with a small demonstration batch, review errors, and compare saved records with the source file before loading the full set.
Check for duplicate codes and existing records before retrying an import. A partial failure does not necessarily mean no rows were saved. Preserve the import result and determine which records require correction.
## Maintain controls
Review period configuration, posting rules, allowed document stages, branch/register relationships, and user access after a significant setup change. Verify the effect in a demonstration transaction. Some controls are company-level and others are item-, role-, or transaction-specific.
## Change record
For each consequential change, retain the setting, previous value, new value, reason, approving person, effective date, and verification result in the organization's approved change record. The academy explains software behavior; the business remains responsible for deciding its operating policy.
---
Source: https://learn.oserp.in/manual/ai-integrations
---
description: Use OSERP AI assistance responsibly, distinguish documentation retrieval from authorized actions, and understand integration boundaries.
---
# AI assistance and integrations
The academy provides readable explanations for people and AI tools. It does not grant access to a company's records or authorize operations in OSERP.
## Ask a useful question
Include the screen name, business task, current status, and relevant non-sensitive context. For example: “In Item Master, what is the difference between Standard Price and MRP?” or “My journal date falls outside the configured periods; which setting should the administrator inspect?”
Ask the assistant to cite the relevant academy page and state uncertainty when a behavior is not verified. A generated answer should not invent a field limit or claim a workflow is implemented because a configuration flag exists.
## Company and item knowledge
Item Master includes Markdown content and document-indexing choices for AI use. Decide what information is appropriate before indexing it. Product instructions and specifications are different from employee data, customer financial records, credentials, or private implementation notes.
The `/ai` screen is associated with settings management in the menu table. Provider/model configuration and usage settings belong to authorized administration. Do not paste secret keys into the public academy or into a support example.
## Read versus act
Reading a public procedure is different from executing it. An AI or integration performing an operation must use an authenticated, authorized application interface and the correct company context. Documentation retrieval does not bypass role checks, posting validation, approval rules, or period locks.
For consequential actions, inspect the target record, proposed change, and expected outcome. After execution, verify the actual saved result and retain its reference. Never treat an assistant's statement “done” as a replacement for application evidence.
## Integrations
OSERP has backend routes and MCP-related implementation, but this academy edition does not advertise every internal route as a supported public API contract. Use the published integration interface approved for your deployment. Authentication, scopes, versioning, retry behavior, and supported operations must be documented for that interface.
If a request times out, inspect the operation's supported idempotency/retry behavior and check for an existing record. Do not assume repeating an arbitrary POST is safe.
Continue to [AI-readable academy content](/ai/) for the public knowledge exports.
---
Source: https://learn.oserp.in/manual/documents
---
description: Operate OSERP sales and purchasing workspaces, understand document stages, and verify stock and accounting outcomes.
---
# Sales and purchasing
Use `/sales/workspace` and `/purchasing/workspace` for document-based business activity. Menu access is associated with `documents:read`; creation, posting, approvals, and other actions have their own checks.
## Start with the business event
A quotation communicates an offer. An order records an agreed demand or supply commitment. A delivery or goods receipt records physical movement. An invoice records billing. A credit document records a supported correction or return-related financial adjustment. Which types and transitions are available depends on configuration.
Do not use the names as proof of posting effects. Inspect the configured stage and resulting stock/accounting records for your business.
## Create a document
1. Confirm the company, transaction direction, and document type.
2. Choose the customer or supplier, dates, reference, currency, and warehouse where relevant.
3. Add items with their quantity and unit. Review conversion factors when buying or selling in packs.
4. Check the price source, discount, tax, line amount, and totals.
5. Review payment terms, due date, and dimensions where used.
6. Save, inspect status, and follow the required approval or posting transition.
Never interpret a lookup displaying a record as proof that the record is eligible for every operation. An inactive item, missing setup, insufficient stock, closed period, or permission check can block a later action.
## Follow the document flow
When copying or progressing from a source document, inspect the open quantity and references. A partial receipt or shipment should leave the remaining quantity identifiable. Do not create an unrelated full-quantity document as a shortcut around the remaining-quantity controls.
Record the source and target references so a colleague can follow the chain. When the same event appears in order, fulfilment, invoice, and payment views, those are related records rather than permission to enter the event again.
## Purchasing example
The business orders ten cases, each containing twelve base units. A demonstration receipt of four cases should be checked against the configured conversion and expected 48 base units. Inspect the received warehouse, lot information where used, and cost values. The supplier invoice and its settlement may occur separately from the receipt.
The example establishes a verification method. Actual supported partial-flow behavior must be confirmed against your configured document types and release.
## Sales example
Prepare a customer order for five units. Fulfil the quantity actually dispatched. Check the resulting delivery/invoice references and what remains open. Review revenue, tax, stock relief, and customer balance at the stages configured to produce those effects.
## Returns and corrections
Start from the original document when the workflow supports it. Record the quantity and reason actually being returned or corrected. Separate physical receipt of returned goods, the credit document, and payment refund. These actions answer different business questions and may require different permissions.
## Check the outcome
Inspect the original document status, related documents, Stock Movements, General Ledger, and partner statement. If a posting fails, preserve the reason and correct its cause before retrying the supported action. Do not assume every endpoint is safely repeatable after a timeout.
---
Source: https://learn.oserp.in/manual/ecommerce
---
description: Maintain OSERP online catalogue and storefront settings, fulfil orders, handle COD, and review returns.
---
# Ecommerce and online orders
OSERP separates product/catalogue work, storefront presentation, and order fulfilment. A published-looking product card does not by itself prove that checkout, stock, payment, and posting are correctly configured.
## Prepare the shop
Review stores, products, categories, storefront sections, menus, templates, checkout, and payment configuration in their respective screens. Ecommerce and storefront areas have separate permission families. Use the [screen directory](/atlas/screens/) to find the exact page.
Check product identity, public descriptions, images, price/tax basis, stock eligibility, and delivery information. Keep confidential notes and employee/customer data out of public product content. Confirm the result in the actual storefront after publishing.
## Follow an order
The existing order documentation explains an order as the operational record driving a sales document. Accounting comes through that related document and its configured posting stages. An order-status label alone does not prove that its accounting completed.
Review customer, payment method, courier where relevant, line quantities, and fulfilment state. Follow the configured stages through picking, dispatch, and delivery. For partial fulfilment, check which quantities were dispatched and which remain open.
## Stage configuration
Administration's Order Stages configuration associates operational stages with posting behavior. The existing default narrative associates dispatch with goods-out/invoicing and delivered COD activity with collection. Your configured stage mapping is the authority for the actual workflow; do not assume all companies use identical stage names or timing.
A highlighted timeline message can expose a posting failure even when operational movement proceeded. Correct the underlying cause and use the supported retry path. Check for the original posting before repeating a general write operation.
## Cash on delivery
Record whether collection is by the business's own driver or a courier. A courier collection can represent money still held by the carrier, rather than money already received in the company's bank. Retain courier identity and remittance references so reconciliation can connect collections to later payouts.
When a payout covers several orders, compare covered collections, actual cash received, fees, and remaining differences. Escalate unexplained short payments instead of silently treating them as settled.
## Returns and cancellation requests
Use `/ecommerce/returns` to review customer requests. The existing workflow documentation distinguishes approve, decline, and hold. A request is not itself a refund. Inspect the original order, actual returned quantity, reason, and evidence before deciding.
Keep the customer-visible decision note factual. Verify physical stock return, credit-document result, and payment refund independently. Approving a return should not be assumed to prove an external payment provider completed a refund.
## Operational checks
Review orders waiting at each stage, posting exceptions, unpaid/COD balances, unresolved return requests, and checkout/payment failures. Compare the same order references across operational and accounting views before reporting a discrepancy.
---
Source: https://learn.oserp.in/manual/
---
description: Role-oriented OSERP operating guides for finance, inventory, sales, purchasing, retail, administration, and people operations.
---
# The OSERP operating manual
Choose the business task you need to complete. Use the Atlas when you need exact field locations or constraints. These founding-edition guides identify operating sequences and verification points; the [coverage register](/reference/coverage) distinguishes reviewed implementation guidance from runtime-tested procedures.
| Your work | Guide |
| --- | --- |
| Maintain accounts, post journals, reconcile, and close | [Accounting](/manual/accounting) |
| Prepare quotations, orders, deliveries, invoices, and purchases | [Sales and purchasing](/manual/documents) |
| Manage stock, locations, transfers, and adjustments | [Inventory](/manual/inventory) |
| Run the checkout counter and reconcile a shift | [POS](/manual/pos) |
| Maintain customers and suppliers | [Business partners](/manual/partners) |
| Configure the company and access | [Administration](/manual/administration) |
| Maintain employee and payroll information | [People and payroll](/manual/people) |
| Maintain a shop and fulfil online orders | [Ecommerce](/manual/ecommerce) |
| Track project work and review approvals | [Projects and workflows](/manual/projects-workflow) |
| Use AI assistance and connected interfaces | [AI and integrations](/manual/ai-integrations) |
## A reliable transaction routine
Confirm company → check prerequisites → enter or select records → review quantities and amounts → save → obtain required approval → execute the appropriate posting/fulfilment action → inspect the result → reconcile.
The steps can span more than one screen. Keep the original document reference throughout. If an operation fails or times out, investigate whether a record already exists before repeating a write.
---
Source: https://learn.oserp.in/manual/inventory
---
description: Manage OSERP item quantities, warehouses, transfers, adjustments, lots, and stock reconciliation.
---
# Inventory and warehouses
Inventory records answer what is held, where it is held, what is committed, and what value is attached to it. Item descriptions and warehouse masters provide context; stock movements establish quantity history.
## Prepare the masters
Create or review [items](/atlas/item-master), [categories](/atlas/screens/inventory-categories), and [warehouses](/atlas/screens/inventory-warehouses). Confirm the base unit, stock-tracking flag, relevant batch/serial settings, company costing method, and allowed warehouse context.
A default warehouse is a selection preference, not a transfer. Changing a master record does not relocate existing stock.
## Receive stock
Use the appropriate purchasing or receipt workflow. Record the actual warehouse, quantity, transaction unit, and cost. Supply lot, manufacturing, expiry, serial, and MRP information where the workflow requires it. Verify the saved conversion to base quantities before treating the receipt as complete.
## Transfer stock
Open [Stock Transfers](/atlas/screens/inventory-transfers). Identify source and destination, then enter the items and quantities. A transfer changes location; it is not a customer sale or a supplier purchase. Check the workflow's dispatch/receipt states and [In Transit](/atlas/screens/inventory-in-transit) when movement spans more than one step.
Verify both ends of the transfer and retain the reference. Do not correct a delayed receipt by creating a second unrelated movement.
## Adjust stock
Use [Stock Adjustments](/atlas/screens/inventory-stock-adjustments) only for an authorized adjustment with a reason and supporting evidence. Confirm whether the screen expects a counted quantity or an adjustment difference before entering values. These are different inputs.
Inspect the quantity, cost, posting result, and period. A physical count discrepancy needs explanation; it should not be concealed by changing unrelated item-master fields.
## Read stock quantities
**On Hand** is recorded stock. **Reserved/Committed** describes quantities committed to demand. **Available** is on-hand less reserved in the reviewed item stock calculation. **On Order** is expected supply. These values should not be added together and labelled physical stock.
Use [Stock Report](/atlas/screens/inventory-stock-report) for the selected view, [Stock Movements](/atlas/screens/inventory-stock-movements) for the event trail, and [Stock Audit](/atlas/screens/inventory-stock-audit) for reconciliation checks. Confirm the date range, item, warehouse, and company before comparing.
## Lots, expiry, and MRP
A single item can have several lots with different expiry dates and printed prices. Review the actual lot being issued and its available quantity. The batch-price screen at `/inventory/batch-prices` addresses lot-level pricing; changing the current item price does not establish that every lot carries that price.
The reviewed stock response explicitly reports disagreement between a stock entry and its lot quantities. Treat a mismatch as an investigation task. Do not suppress it by excluding the affected lot from a report.
## Bins and locations
The reviewed Item Stock implementation explains bins as picking/putaway instructions, not independently maintained bin balances. A bin reference on a document is not evidence of a complete bin-level quantity ledger.
## Daily checks
Review incomplete receipts/transfers, unexpected negative stock, lot mismatches, missing costs, and stock adjustments. Reconcile selected items back to their movements and accounting effects. Keep the same date cut-off when comparing inventory value with the books.
---
Source: https://learn.oserp.in/manual/partners
---
description: Maintain OSERP customer and supplier records, avoid duplicates, and understand partner identity, terms, pricing, and balances.
---
# Customers and suppliers
**Application address:** `/business-partners/partners` · **Menu permission:** `bp:read`. Business partners hold reusable information about the people and organizations with which the company trades.
## Search before creating
Search by the identifiers available in the screen. A business may appear under a trading name that differs from its registered name. Compare contact and tax identifiers before deciding it is a new partner. Separate duplicate records can split statements, pricing, loyalty history, and settlement allocation.
## Identify the partner and its role
Choose the applicable customer/supplier role and enter the display identity and relevant contact details. A supplier's item code belongs in vendor-item information, not in the partner's own identity field. An employee, user account, and business partner are also different records even when they describe the same person.
Use the [screen reference](/atlas/screens/business-partners-partners) for the exact field labels and declared interface constraints. Dynamic sections and backend validation still require the detailed review listed in the coverage register.
## Addresses, contacts, and registration
Keep billing, delivery, and contact information consistent with the business documents. A contact email does not grant system access. Tax-registration information describes the partner; storing it does not establish that a registration is valid or that a particular tax treatment is appropriate.
## Groups and pricing
Customer groups can connect a customer to price lists, discounts, and loyalty behavior. When a customer receives an unexpected price, inspect the assigned group and the list entry for the item. Compare quantity thresholds and branch context as well.
Item Master can display group pricing and its source. This is more informative than comparing only Standard Price with the receipt total. Read [Item pricing](/atlas/item-master#pricing-why-different-customers-can-pay-different-amounts).
## Credit and payment terms
Payment terms and due dates explain when settlement is expected. A credit limit expresses a business control where supported; do not assume the same enforcement in every document and channel until verified. Preserve the exact refusal when a transaction is blocked and have an authorized person review the control.
## Statements and allocation
Use Customer Statement or Supplier Statement to inspect the partner's transactions and balance. Match company, period, currency, and partner identity. A receipt can exist without being fully allocated to the intended invoice. Use the appropriate allocation screen and verify the remaining open balance.
## Sales people
The Sales People screen at `/business-partners/sales-people` has a separate management context. Associating a salesperson with activity and computing commission are different operations; an assignment alone must not be described as proof that a commission was calculated or paid.
## Corrections
Correct the existing record where supported. Before deactivating or consolidating a duplicate, review open documents, statements, price-group membership, and linked records. Do not delete a historical partner as a shortcut to changing its name.
---
Source: https://learn.oserp.in/manual/people
---
description: Understand OSERP employee records, employment, leave, pay revisions, payroll calculation, approval, and ledger posting.
---
# People and payroll
HR information and payroll information are separately permissioned. The reviewed HR controller uses `hr:read` for reading and `hr:manage` for changes. Payroll uses distinct permissions for reading, running, approving, and posting. HR access alone does not grant access to pay.
## Employee and employment records
Open [Employees](/atlas/screens/hr-employees). Distinguish the person's identity from their employment record. Employment associates the person with a company and the working details relevant to that engagement.
Review identifiers, start/end dates, status, and organizational assignment. Changes to employment dates can affect downstream eligibility, so verify the intended period before saving. Use fictional records for training and keep payroll material restricted to authorized users.
## Leave and attendance
The [Leave & Attendance](/atlas/screens/hr-leave) interface offers request and attendance information, with approval/rejection/cancellation actions where permitted. Review the employee, dates, days, reason, unpaid classification, and decision note. A request submitted is not the same as leave approved.
Before payroll calculation, resolve relevant attendance or leave issues and verify how the selected payroll configuration consumes them. Do not assume every leave label has an automatic salary consequence.
## Configure pay
Use [Payroll Components](/atlas/screens/payroll-components) to define supported pay elements. Use [Employee Pay](/atlas/screens/payroll-pay) for pay revisions and their effective context. A revision should preserve when the new terms begin; overwriting an old amount without considering dates can make later review difficult.
Confirm the earning/deduction classification, amount or formula, effective dates, and posting configuration. Country-specific statutory treatment needs separate subject review; the academy does not establish payroll compliance.
## Calculate a payroll run
Open [Payroll Runs](/atlas/screens/payroll-runs), create the intended run/period, and review which employees are included. **Calculate** starts the calculation. The reviewed controller starts work and exposes progress rather than holding a single request open for the full calculation.
Wait for the reported result and inspect exceptions. Review gross amounts, deductions, and net pay employee by employee where needed. The interface provides explanatory detail and supports a distinct single-employee recalculation path after correction.
## Approve and post
Calculation, approval, and ledger posting are separate actions with separate permissions:
| Action | Permission |
| --- | --- |
| Read payroll | `payroll:read` |
| Configure/run calculations | `payroll:run` |
| Approve payroll amounts | `payroll:approve` |
| Post to the ledger | `payroll:post` |
Review totals before approval. Use **Post to ledger** only when the run is ready and the posting period/mappings are correct. Inspect the resulting journal. An approved or posted payroll run is not proof that employees' bank accounts have received payment.
## Reconcile and correct
Compare run totals, employee details, payslips, the journal, and actual payment evidence. After a calculation timeout, inspect progress and run status before starting another run. After posting, use the authorized correction process rather than editing historical pay data to force agreement.
---
Source: https://learn.oserp.in/manual/pos
---
description: Open an OSERP register, identify customers, sell and take payment, recover interrupted work, and reconcile a shift.
---
# Point of sale
**Application address:** `/pos` · **Menu permission:** `pos:sell`. POS management and reports can require `pos:manage`. This chapter uses the reviewed register interface wording and pricing implementation; the complete checkout sequence remains to be verified against the deployed release.
## Open a register
Confirm the company and store/register context. **Cash already in the drawer** is the opening float: count it before starting, because the close is measured against it. It is not today's sales revenue.
Select **Open register** when ready. If an existing shift is available, inspect its ownership and register context before taking it over. Do not create another shift merely because an earlier cashier stepped away.
## Build the sale
Scan a barcode or search by item name/code; the interface advertises **Enter to add**. Inspect the item, quantity, unit price, tax, and line total. A case barcode may add several base units, so one scan is not necessarily one item unit.
If multiple MRP lots are available, check which printed price applies to the physical pack being sold. Pricing can depend on customer group, branch, quantity, tax basis, and MRP. Use the pricing source and Item Master reference to explain differences.
## Identify the customer
Search existing customers before creating a new one. The interface supports search by name, mobile, or email and warns about identifiers already associated with another customer. This prevents repeat visits from becoming separate customer records.
Some tills require a customer for every sale or above a configured amount. Follow the displayed requirement. The new-customer interface includes name, mobile, WhatsApp, email, customer type, date of birth, gender, state code, and GSTIN. Collect only information your business is authorized to use.
Do not assume **Walk-in Customer** satisfies a named-customer policy. If the Pay action is unavailable, read the actual requirement instead of creating an anonymous placeholder repeatedly.
## Take payment
Review the final basket, offers, customer, and amount due. Choose the configured payment type and enter the actual tender information requested. For cash, verify change. For a non-cash method, follow the business's payment-confirmation procedure; selecting a method alone is not proof that a bank or gateway settled funds.
Complete the sale once, wait for confirmation, and retain the receipt/reference. After a timeout, find the sale in the report or register history before repeating checkout.
## Leave, lock, and close are different
| Action | Interface meaning |
| --- | --- |
| Lock screen | Step away; the shift stays open and requires unlocking |
| Leave the till | Hand over or move elsewhere in OSERP; the shift stays open |
| End shift and close register | Count the drawer and finish the shift; further sales cannot be rung on that closed shift |
Choose the action that matches the business event. Closing the browser or leaving the till is not a cash reconciliation.
## Recover interrupted work
The interface can offer to restore an open sale. Compare the recovered basket with the customer's actual purchase before continuing. If the previous checkout might already have completed, inspect sales history first. Restoring a basket is different from reversing a completed sale.
## Close and reconcile
Count the drawer and use the supported register-close process. Compare expected cash with counted cash, considering opening float, sales, refunds, and any supported cash movements. Record the reason for a variance according to business policy.
Review [Sales](/atlas/screens/pos-reports-sales), [Cashiers](/atlas/screens/pos-reports-cashiers), [Registers](/atlas/screens/pos-reports-registers), and [Slab Offers](/atlas/screens/pos-reports-slab-offers) with matching company, dates, and register filters.
## Common counter problems
**Unknown barcode:** check its exact characters and units-per-scan mapping before registering another code. **Unexpected price:** compare customer group, branch list, quantity break, MRP selection, and tax basis. **Customer required:** use an identifiable existing or properly registered customer. **Payment uncertainty:** verify the sale and payment outcome before retrying. **Stock refusal:** investigate the selected warehouse/lot rather than disabling a control to complete the sale.
---
Source: https://learn.oserp.in/manual/projects-workflow
---
description: Use OSERP project structures and understand approval, rejection, hold, rework, reassignment, questions, and watchers.
---
# Projects and approvals
Projects organize work and its financial attribution. Approval workflows determine who must review a record before a controlled action proceeds. Their configuration and day-to-day use are different responsibilities.
## Project structure
Open [Projects](/atlas/screens/projects). The reviewed project controller uses `projects:read` for inspection and `projects:manage` for changes. Maintain the project identity, type, manager, status, and work breakdown structure as supported by the screen.
A **WBS** breaks work into elements so costs can be assigned more precisely than the project as a whole. The postable-reference operation identifies eligible leaf elements on projects that take cost. Do not assume every heading in the tree can receive postings.
Before restructuring a project, review existing document assignments and the effect on future coding. Adding a project reference to a document is not the same as posting that document.
## Supporting documents
Attach relevant authorized project evidence using the supported attachment flow. The reviewed project upload controller declares a **25 × 1024 × 1024 byte** limit. This differs from other upload areas; use the constraint for the specific screen, not a single assumed system-wide upload size.
## Configure approvals
The Workflow screen at `/workflow` is a configuration surface associated with settings management. Define the intended condition, route, responsible roles/people, and stage restrictions, then test representative allowed and blocked cases with demonstration records.
The Tray at `/tray` brings work requiring attention into an operating view. Inspect the document, amount, history, attachments, and reason for the request before deciding.
## Understand the seven approval actions
| Action | Meaning in the reviewed approval model |
| --- | --- |
| Approve | Record an approval decision |
| Reject | Record a rejection |
| Hold | Pause the request; it remains open and continues to block the document |
| Rework | Return for correction through the supported resubmission path |
| Reassign | Hand responsibility to a specified person or role through a replacement request |
| Ask | Address a question to a person without changing the decision state |
| Watch | Include a person without changing the decision state |
Pending and on-hold requests remain open in the reviewed logic. **Ask** and **Watch** do not approve the document. Reassign, Ask, and Watch require a target; only Reassign can target a role in this model.
## Act on a request
Open the underlying document, read the context, and choose the action matching the situation. Use a clear note that lets the requester understand the decision or missing information. Recheck the resulting state and responsible person.
Batch actions are limited to supported decisions such as Approve, Reject, Hold, and Rework. Inspect every selected request before using a bulk action; the convenience of a batch selection does not establish that all records deserve the same decision.
## Verify completion
An approved request and a posted business document are separate facts. Confirm the next supported stage and resulting transaction. If responsibility changes, verify that the replacement request exists and the new person can see it.
---
Source: https://learn.oserp.in/reference/coverage
# Coverage and verification
OSERP Academy is a living reference. This founding edition describes the repository baseline **0.4.0**. A hosted application may run a different release.
## Coverage measures
| Measure | Count | Meaning |
| --- | --- | --- |
| Application pages discovered | 87 | Includes setup and sign-in pages |
| ERP page files | 82 | Page-level inventory, not distinct business processes |
| Extracted labelled controls | 940 | Screen occurrences; the same business field can appear more than once |
| Controls needing manual identification | 428 | Dynamic or ambiguous bindings; not silently counted as documented |
| Database models inventoried internally | 189 | Includes system models; not all are public business entities |
| API operations inventoried internally | 685 | Controller declarations, not independently exercised operations |
| Authored academy pages | 27 | Guides, reference chapters, and learning material |
| Runtime-verified academy walkthroughs | 0 | No operational walkthrough is claimed as runtime-tested in this edition |
## How to interpret evidence
**Reviewed guide:** written after inspecting named implementation sources. Useful operating guidance, but it can still require a demonstration against the deployed release.
**Extracted reference:** literal screen labels and declared constraints obtained from source. It does not infer missing limits or prove the effects of a setting.
**Runtime verified:** reserved for a documented walkthrough completed against an identified release using demonstration data, including its resulting records. No entry currently carries this status.
**Planned:** educational or product capability that is not available yet. Future certification and international recognition belong here.
## Remaining work before exhaustive coverage
1. Resolve every ambiguous or dynamically generated field.
2. Join each field to its actual request validation, saved default, and storage constraints.
3. Trace consequential settings through every consuming workflow.
4. Execute positive and negative cases for every operation and role.
5. Capture demonstration screenshots and Arabic/RTL walkthroughs.
6. Review accounting and region-specific material with appropriate subject specialists.
7. Recheck differences between this baseline and the published application.
The [screen directory](/atlas/screens/) provides the module-by-module work list. The internal audit retains source hashes so changes can be detected without publishing private implementation files.
---
Source: https://learn.oserp.in/reference/glossary
---
description: Plain-language definitions of common OSERP business, accounting, inventory, and workflow terms.
---
# Glossary
| Term | Meaning in this academy |
| --- | --- |
| Tenant | Top-level data/access boundary for a subscribed organization context |
| Organization | Organizational scope grouping company activity |
| Company | Business entity/context whose records and books are being operated |
| Branch | Operating location or subdivision associated with business activity |
| Master record | Reusable definition such as an item, partner, warehouse, or ledger |
| Business partner | Customer, supplier, or other trading-party record |
| Ledger | Account receiving posted accounting lines |
| Voucher / journal | Accounting transaction with debit and credit lines |
| Posting | Recording an authorized transaction's accounting effect |
| Draft | Saved or prepared record that is not necessarily finalized or posted |
| Approval | Decision permitting the next controlled workflow step |
| Period | Defined accounting date range with an operating status |
| Base currency | Currency in which a company's books are expressed |
| Exchange rate | Conversion relationship used for a foreign-currency amount |
| Allocation | Applying a settlement against selected open items |
| Receivable | Amount due from a customer or other debtor |
| Payable | Amount owed to a supplier or other creditor |
| UOM | Unit of measure |
| Conversion factor | Multiplier relating one unit to another |
| On hand | Quantity recorded as held |
| Reserved / committed | Quantity committed to demand |
| Available | On hand less reserved in the reviewed item-stock calculation |
| On order | Expected supply, not stock already received |
| Lot / batch | Group of stock sharing identifying/receipt attributes |
| Serial number | Identifier for an individual tracked unit |
| MRP | Printed pack-price reference interpreted as inclusive in reviewed pricing |
| Standard price | Item selling-price reference, subject to the configured pricing path |
| Standard cost | Item cost reference, distinct from every actual receipt or warehouse value |
| FIFO | First-in, first-out valuation/issue concept where the selected path implements it |
| FEFO | First-expiring, first-out ordering concept |
| BOM | Bill of materials: component requirements for a defined output |
| Kit | Component-based selling definition in the reviewed item model |
| WBS | Work breakdown structure for organizing project work and attribution |
| COD | Cash on delivery |
| Register session | A POS shift whose activity is reconciled at close |
| Opening float | Cash already in the drawer at the start of a shift |
| Idempotency | A supported operation's ability to recognize a repeated request without duplicating its effect |
| Scope | The permitted data/operation context of a user or integration |
| Audit trail | Recorded evidence of who changed or performed something and its context |
Some terms describe a concept rather than a guarantee that every OSERP path implements every variation. Consult the relevant workflow and verification status.
---
Source: https://learn.oserp.in/reference/troubleshooting
---
description: Investigate common OSERP access, posting, pricing, inventory, payment, and reporting problems with the right evidence.
---
# Troubleshooting
Start with the exact screen, active company, record reference, action, and error message. Check whether the action may already have completed before repeating it.
| Symptom | First checks | Next step |
| --- | --- | --- |
| Screen missing | Role permissions, company feature configuration, intended menu | Administrator reviews the relevant screen/action grants |
| Record missing | Company, filters, status, identifiers, pagination | Search existing records before creating a duplicate |
| Item name refused | Blank or spaces-only name | Enter a meaningful name and save again |
| Duplicate item code | Existing organization-scoped item code | Find the existing item or choose the intended new code |
| Journal unbalanced | Base-currency debit/credit values and exchange rates | Correct the lines; inspect any rounding adjustment |
| Closed/locked period | Voucher date and covering period | Authorized accounting review; do not bypass the lock |
| No period covers date | Mistyped year or missing calendar period | Correct date or properly configure the missing period |
| Base currency change refused | Existing posted entries | Review with the accounting administrator |
| Unexpected selling price | Customer group, list, branch, quantity break, MRP, tax basis | Compare the pricing source and physical pack |
| Stock is zero after item creation | No received/opening movement; wrong warehouse; stock flag | Verify the actual stock-creating workflow |
| Stock entry and lots disagree | Warehouse and lot totals, prior movements | Investigate the mismatch with stock audit evidence |
| Invoice remains open after payment | Receipt allocation, partner, currency, residual amount | Allocate correctly and review the remaining balance |
| POS Pay unavailable | Customer policy, basket state, permissions, required choices | Follow the displayed reason |
| Checkout timeout | Existing sale/receipt and payment status | Verify before retrying |
| Payroll calculation appears stuck | Run progress, exceptions, current status | Inspect progress before creating/restarting work |
| Order advanced but accounting missing | Timeline posting exception and configured stage | Correct the posting cause through the supported retry path |
| Report differs from another report | Company, dates, status filters, currency, accounting vs operational timing | Align the selections and trace the same records |
| Attachment refused | File type, area-specific size limit, hosting limit | Use a supported file; do not assume all upload areas share a ceiling |
## A useful support record
Include application release if available, screen name/path, company, document or item reference, date/time, expected result, actual result, exact message, and reproducible steps. Add a screenshot only after removing unnecessary personal information. Never include a password, secret key, or access token.
## Corrections after posting
Use the supported reversal, credit, return, or adjustment process for the business event. Preserve the original reference and reason. Editing unrelated master data does not retroactively explain a posted transaction, and deleting records can destroy the evidence needed to reconcile it.
---
Source: https://learn.oserp.in/start/company-setup
---
description: Walk through OSERP Company Setup, including identity, location, tax configuration, accounting, features, and review.
---
# Set up your company
**Application address:** `/setup`. This guide is reviewed against the setup interface and company creation service; it has not yet been exercised against a hosted release for academy verification.
Prepare the registered business name, address, country, base currency, financial-year starting month, tax-registration details, intended chart of accounts, and enabled modules before beginning.
## 1. Identity
Enter **Company Name**. It is required and cannot consist only of spaces. **Legal / Registered Name** captures the formal name when it differs from the operating name. **Business Type** and **Industry** classify the business. **License / Registration No.** stores its registration reference.
The business-type choices include Indian and Gulf terminology. Select the form that matches your business records; the selection is classification within OSERP and is not a legal determination.
The **Print Profile** controls company information used in printed documents. Review the logo, print name, print address, tax label/number, registration label/number, and extra line separately from the company identity. An incorrect print profile can make a document misleading even when its transaction values are correct.
## 2. Location
Choose **Country**, then **State / Province / Emirate** where applicable. Complete city, address lines, postal code, phone, email, and website. Country influences suggested configuration, so select it before reviewing currency and tax settings.
Contact fields describe the company. They do not create user accounts or grant anyone application access.
## 3. Tax & Compliance
Review **Tax Regime**, **Tax Registered?**, and **Tax Registration Number**. Use details supplied by the person responsible for your tax setup. The application stores these settings; their presence is not confirmation of statutory compliance.
Choose the financial year. Its underlying starting month is an integer from **1 to 12**. A January start uses a single-year label; a non-January start produces a year-span label based on the current date when the company is created.
## 4. Accounting
Confirm **Base Currency**, the unit in which this company's books are kept. The creation service requires it. The currency normalizer accepts a three-letter code; the accepted code format does not by itself prove that every currency-specific feature is configured.
Select a **Chart of Accounts** preset or choose **Start blank (import later)**. Starting blank leaves account setup work to complete before transaction posting. Review imported ledgers and posting mappings before relying on them.
::: warning Choose the base currency before posting
Company Profile refuses to change the base currency after entries have posted. Confirm this choice during setup rather than trying to reinterpret existing balances later.
:::
## 5. Features & Modules
Enable only the features the business intends to use, then complete their master data and permissions. A feature switch is not a substitute for the associated configuration.
| Setting | Operational decision |
| --- | --- |
| Inventory | Whether the company manages stock quantities |
| Costing Method | The inventory valuation method used by supported posting paths; choices shown include FIFO, weighted average, and standard cost |
| Warehouses | Whether stock is organized across storage locations |
| Bins / Racks | Location instructions inside warehouses; do not assume a separate per-bin stock balance |
| Batch Tracking / Serial Numbers | Whether item-level traceability is needed; configure the relevant items as well |
| Negative Stock | Whether the business intends to permit stock below zero; actual transaction checks must also be considered |
| Multi-Currency | Whether transactions use currencies beyond the company's base |
| Cost Centres / Projects | Whether additional dimensions are required for analysis |
| Budget Management | Configuration flag; verify supported budget workflows before relying on it |
| Amount Decimal Places | Display/configuration value from 0 through 4; it is not the database's storage precision |
| Payroll / POS | Which business modules are enabled |
| Approval Workflows | Whether approvals are part of the company's operating process |
Pricing also has a company tax-basis setting. The creation service uses an explicitly supplied choice or a country-dependent default. Check **General Settings** and the labels beside selling prices before entering a catalogue. MRP and batch selling prices are interpreted as tax-inclusive in the reviewed pricing logic.
## 6. Review and create
Review all six sections. Choose **Create Company** once. The interface also advertises **Enter** for Next and **Ctrl+Enter** for Create. Shortcuts depend on focus and the current step.
Company creation is followed by initialization of starter records. If initialization or chart-of-accounts import reports a problem, check whether the company already exists before retrying creation. The service deliberately keeps the company even if a later bootstrap step fails.
## After creation
Open Company Profile and General Settings to verify saved values. Confirm the active company, expected financial year, base currency, tax basis, chart of accounts, numbering, users, roles, and warehouse setup. Run a demonstration transaction before beginning live operations.
Continue to the [company field guide](/atlas/company) and the [extracted setup controls](/atlas/screens/setup).
---
Source: https://learn.oserp.in/start/first-sale
---
description: Prepare and follow a first demonstration sale in OSERP, then verify the document, payment, and inventory effects.
---
# Your first sale
Use a demonstration company. This guide describes the operating sequence and verification points; document names and available stages depend on your configured workflow. It is not a runtime-verified transaction walkthrough yet.
## Choose the route that matches the work
Use the **Sales Workspace** at `/sales/workspace` for document-based sales. Use **Point of Sale** at `/pos` for a counter sale. Do not enter the same sale through both routes.
## Prepare the records
1. Confirm the company, base currency, tax basis, and transaction date.
2. Create a customer if the sale needs an identified customer or receivable.
3. Create an active, sellable item with a base unit and appropriate pricing.
4. For a stocked item, receive authorized demonstration stock into the intended warehouse. Creating the item alone does not create stock.
5. Have the administrator confirm the sales document type, numbering, payment types, posting rules, and permissions.
Use a simple demonstration quantity, such as two units of a fictional notebook. Start with a pricing example whose expected result you can calculate manually. Apply only the tax configuration approved for that demonstration.
## Document-based sale
Open Sales Workspace. Select the appropriate document type, customer, date, and warehouse. Add the item and quantity, then inspect unit price, discounts, tax, and total. If the workflow starts with a quotation or order, follow the configured document flow toward delivery and invoice; a quotation is not a posted invoice.
Save the record, record its number, and inspect its status. Submit for approval if required. Use the supported posting or stage action only when the document is ready. Do not assume **Save**, **Approve**, and **Post** are equivalent.
## Counter sale
Open POS with the appropriate selling permission. Select or open the correct register session as required. Confirm the store/branch and warehouse context. Scan or select the item, check quantity and any units-per-scan multiplier, identify the customer when required, and review offers and tax.
Choose the payment method and tender amount, review the balance or change, then complete checkout once. Wait for confirmation and keep the receipt or sale reference. A network timeout after submission requires checking for an existing sale before retrying.
## Verify the result
| Question | Where to investigate |
| --- | --- |
| Was the sale saved or completed? | Original document or POS sales report |
| Was stock relieved? | Item stock, Stock Movements, and the selected warehouse |
| Was revenue posted? | General Ledger and the document's posting result |
| Is the customer still owed money? | Customer Statement and receipt allocation |
| Was tender assigned correctly? | POS/register/payment reports or the relevant receipt record |
| Did tax match the configured basis? | Document lines, total, and Tax Summary for the same period |
If a value is unexpected, keep the original record and investigate its flow, pricing source, configuration, and posting status. Do not change a ledger balance manually to conceal an unexplained difference.
## Practice reflection
Explain which step created the business obligation, which step moved stock, which step affected the books, and which step recorded payment. These can be different steps. Continue with [sales and purchasing](/manual/documents) or [POS operations](/manual/pos).
---
Source: https://learn.oserp.in/start/
---
description: Begin using OSERP with the right company, permissions, master records, and first transaction.
---
# Welcome to OSERP
OSERP brings business records, transactions, stock, and accounting into a company workspace. The most useful way to learn it is to follow a record from setup through a transaction and into its report.
This academy has two reading modes. Follow the **User Manual** when you need to accomplish a task. Open **OSERP Atlas** when you need to understand a particular screen, field, or restriction. The [coverage register](/reference/coverage) explains the evidence behind this edition.
## Before your first session
Obtain your organization's OSERP application address and an individual user account from its administrator. The academy is a public reference; signing into it is not required and it does not sign you into your business system. Never enter application passwords into a public documentation page.
Use a demonstration company for exercises. Real posted transactions affect business records. Sample names and amounts in these lessons are fictional and must not be interpreted as recommended tax or accounting policy.
## The first-day sequence
1. Sign in to the application and identify the company you will work in.
2. If creating a business, follow [Company Setup](/start/company-setup). Otherwise have the administrator confirm its setup.
3. Learn the [navigation and company context](/start/navigation).
4. Review the chart of accounts, period, currency, tax configuration, document numbering, and required posting mappings with the person responsible for the books.
5. Create the necessary [customers and suppliers](/manual/partners), [items](/atlas/item-master), and [warehouses](/manual/inventory).
6. Practise [a first sale](/start/first-sale), then locate its document and resulting reports.
7. Follow the [learning path](/courses/) for your job.
## Three kinds of information
**Master records** describe reusable business entities: an item, customer, supplier, warehouse, employee, or ledger. Creating an item does not by itself receive stock into a warehouse.
**Transactions** record business events: receiving goods, invoicing a customer, accepting payment, transferring stock, or posting a journal. A saved draft and a posted transaction do not have the same effect.
**Reports** explain the recorded results. Always inspect the company, date range, status filters, and currency before comparing two reports. An apparently missing transaction can be a filter issue rather than a posting error.
## What to do when a screen is missing
The navigation depends on role permissions. Some features also depend on company configuration. Ask the administrator to check the intended role and module configuration; repeatedly typing a restricted address will not grant access. The server separately checks individual actions.
## What success looks like
You can identify the active company, find an existing record, create an authorized demonstration record, explain whether a transaction is draft or posted, and trace the result into the appropriate report. You do not need to memorize every field before doing useful work.
---
Source: https://learn.oserp.in/start/navigation
---
description: Understand company context, permissions, keyboard interaction, and finding OSERP screens.
---
# Find your way around
OSERP offers a keyboard-oriented workspace. The exact controls available depend on your role, company configuration, and the screen you have opened.
## Confirm your context
Before entering or reconciling information, confirm the active company and period. Similar item names or ledger names across companies do not make the records interchangeable. If a record appears missing, check company and filters before recreating it.
## Find a screen
Use the application's navigation or command search where offered. The [screen directory](/atlas/screens/) gives application paths and the menu permissions declared for each page. Paths such as `/inventory/items` belong to your OSERP application, not the academy domain.
Screen permission lists use **or** semantics: one listed permission can make the screen visible. The backend still decides whether each operation is allowed. Permission to view a master does not automatically include permission to edit or delete it.
## Browse, view, and edit
Lists find existing records. A record window can be in view mode until you choose **Edit**. Disabled controls can also depend on record status or an unsaved parent record. In Item Master, for example, several related-record tabs require the item to be saved first.
Before closing an edited window, save or deliberately discard the changes. Do not assume switching tabs saved a record.
## Keyboard use
Use **Tab** and **Shift+Tab** to move between standard controls, and follow the keyboard hints shown by each screen. Shortcuts are contextual: a key used inside a document editor can mean something different in a global search.
Company Setup advertises **Alt+Left** for Back, **Alt+D** for Dashboard, **Enter** for Next, and **Ctrl+Enter** for Create. Item Master includes a field finder associated with **Ctrl+F**; it can take you to a field on another tab. Verify the hint in your running release.
## Language and reading direction
The application includes English and Arabic interface text. Some identifiers, codes, and amounts deliberately keep left-to-right input even in an Arabic interface. This academy edition is written in English; translated application labels in a screenshot or reference do not imply that the entire academy has an Arabic edition.
## Before reporting a problem
Record the screen name, active company, document or item reference, action attempted, current status, and exact error. Capture no password, access token, or unnecessary personal data. These details let another person reproduce the issue without guessing your context.