What is Damsy ERP?

Damsy ERP is an enterprise resource planning platform for organizations that operate across multiple companies and branches from a single web application. It covers payroll processing, client billing, inventory management, employee self-service, field operations, and management reporting — all gated by company context and per-user module permissions.

The application follows a classic server-rendered MVC model: Razor views, jQuery-enhanced forms, DataTables for grid UIs, Crystal Reports for printable documents, and ClosedXML for Excel exports.

Purpose

Damsy ERP centralizes day-to-day business operations that would otherwise live in disconnected spreadsheets and legacy tools:

• HR & payroll — employee masters, attendance, salary runs, statutory compliance, full-and-final settlement
• Commercial — billing with GST/IRN support, payment receipt, credit and debit notes
• Supply chain — stock masters, requisitions, purchase orders, receipts, issues, and returns
• Workforce — employee self-service for payslips, leave, loans, and Form 16
• Operations & governance — grievances, incidents, verification workflows, and management MIS

Every screen is scoped to a selected company (CompID in session). Users pick a company at login; nearly every controller action validates that session key before proceeding.

When to use Damsy ERP

Damsy ERP is a strong fit when your organization needs:

Scenario	How Damsy ERP helps
Multi-company payroll with site-wise processing	Payroll module with branch/unit hierarchy and statutory reports
Contract staffing with client billing	Bills module linked to contracted rates and payroll outputs
Inventory tied to sites and supervisors	Stock module with requisition → PO → receipt → issue flows
Employee-facing HR documents	ESS module for payslips, leave requests, and CTC views
Cross-module management reporting	Management dashboard with Crystal-based MIS

info

Damsy ERP is not a greenfield SPA or microservices platform. It is a mature, database-centric ERP where SQL Server stored procedures carry most business logic. Plan integrations and extensions accordingly.

Architecture at a glance

Request lifecycle

1. User navigates to a URL (default landing: Login/Index).
2. MVC routes the request to a root controller or an Area controller.
3. The controller checks session keys — especially CompID — and builds a business object (BO).
4. A DAL class calls BaseHelper, which opens MyConnectionString and executes a stored procedure.
5. Results return as DataTable, JSON, or view model data and render in a module-specific layout.

Multi-company model

At login, the user selects a company from a dropdown populated by the GetCompany stored procedure. Successful authentication stores company identity and module flags in session:

Session key	Role
CompID / CompName	Active company — primary gate on actions
UserID / UserName	Authenticated account
Role / RoleId	Role name and identifier
dtVerifyUser	Full user record including module boolean flags

Module access is not a single permission string. Each user carries flags such as Payroll, Billing, ZSTOCK, and Ess on the BO.User object stored in dtVerifyUser. The home dashboard exposes only the modules the user is allowed to open.

Developer notes

• Solution file: DamsyERP.sln at the repository root.
• Startup project: DamsyERP.UI.
• Intentional route typos: Areas are registered as Adminisration and ManagmentDashBoard — URLs must match these spellings exactly.
• Session key casing: Role identifier is stored as RoleId, not RoleID.

warning

Do not rename Area folders to "fix" spelling. Routes, links, and bookmarks across the codebase depend on the existing names.

Common mistakes

Mistake	Why it fails
Expecting REST APIs for every screen	Most modules are form-post MVC with server-rendered views
Assuming Entity Framework drives queries	Data access is ADO.NET + stored procedures via BaseHelper
Using RoleID in custom session code	The established key is RoleId
Navigating to /Administration/...	Correct path uses Adminisration

Related pages

• Feature overview
• Technology stack
• Solution structure
• Running locally

Next steps

Review the feature overview to see which modules map to your use case, then read Solution structure before opening the codebase in Visual Studio.