System Overview

Introduction

Damsy ERP is a multi-company enterprise resource planning system built on ASP.NET MVC 5 (.NET Framework 4.5.2). The application delivers server-rendered Razor views with jQuery and DataTables, persists data in SQL Server through stored procedures, and renders printable documents with Crystal Reports and Excel exports with ClosedXML.

Understanding the system at this level helps you locate code quickly, trace a user action to its database call, and avoid breaking cross-cutting concerns such as session gates and connection string resolution.

Purpose

This page describes the macro architecture: which projects exist, how they depend on each other, and the standard path a page request follows from the browser to SQL Server and back to a rendered view.

When to Use

Refer to this overview when you:

• Onboard to the Damsy ERP codebase for the first time
• Need to explain the system to stakeholders or new developers
• Are deciding where a new feature belongs (UI, DAL, BO, or SQL)
• Are debugging a request that spans multiple layers

For layer-specific detail, follow the related pages listed at the bottom of this document.

How It Works

Solution projects

Project	Responsibility
DamsyERP.UI	Web application: root controllers, MVC Areas, Razor views, app-assets, Crystal report viewer pages (.aspx)
DAL	Data access layer: ADO.NET, BaseHelper, stored procedure calls
BO	Business objects / DTOs organized by module namespace (BO.Payroll, BO.Bills, …)
UTILITIES	Shared helpers: HashCryptography, constants, cross-cutting utilities

Dependency direction

The UI never references SQL directly. All database access flows through DAL classes that call stored procedures via BaseHelper and the MyConnectionString connection string.

End-to-end request flow

Every typical page load follows the same stack:

1. Browser sends an HTTP request to a root controller or an MVC Area.
2. The controller checks session (typically CompID) and builds or receives a BO object.
3. A DAL class prepares SqlParameter[] and invokes BaseHelper methods.
4. BaseHelper opens a connection using MyConnectionString and executes a stored procedure.
5. Results return as DataTable, bool, or mapped BO properties.
6. The controller passes data to a Razor view rendered inside a module layout (_LayoutPayroll, _BillsLayout, etc.) with shared app-assets.

Technology stack summary

Layer	Technology
Web framework	ASP.NET MVC 5, .NET Framework 4.5.2
UI	Razor, jQuery, DataTables, module-specific CSS
Data	ADO.NET, SQL Server stored procedures
Reports	Crystal Reports runtime 13.0.2000.0
Excel	ClosedXML
Auth	Session-based; password encryption via HashCryptography

Developer Notes

• Startup project: DamsyERP.UI (see DamsyERP.sln).
• Default route: {controller}/{action}/{id} defaults to Login/Index.
• Primary connection string name: MyConnectionString — resolved in DAL/BaseHelper.ResolveConnectionString().
• Legacy connection strings (ZDBERP_ZPILOTConnectionString, ZDBERP_PANZERConnectionString) exist in Web.config for Crystal and legacy scenarios; routine DAL code uses MyConnectionString.
• Schema is not fully in Git. Stored procedure definitions and table DDL live primarily in SQL Server. DAL files reference procedure names as string literals.

Naming quirks

Two Area route names are intentionally misspelled in the codebase and must not be "fixed" without updating routes and links:

• Adminisration (missing "t")
• ManagmentDashBoard (missing "e")

Examples

Tracing a Payroll dashboard load

GET /Payroll/PayrollDashboard/Index
  → PayrollDashboardController.Index()
  → checks Session["CompID"]
  → PayRollDashBoard_DAL with CompID from session
  → BaseHelper.GetDataTable("[dbo].[GetPayRollDashboardKPIs]", parameters)
  → View with _LayoutPayroll.cshtml

Tracing login (root, no Area)

GET /Login/Index
  → LoginController.Index()
  → Common.GetCompany() for company dropdown
  → View UserLogin.cshtml

POST /Login/Index
  → Login_DAL.GetLoginUser()
  → [dbo].[GetLoginUser]
  → Session populated → Redirect ~/Dashboard/Index

Related Pages

• MVC Architecture — Areas, controllers, views, layouts
• Request Pipeline — Global.asax, routing, HTTPS
• Authentication Flow — login sequence
• Data Access Layer — DAL and BaseHelper patterns
• Login — user-facing login flow

Important Notes

Session is the primary authorization gate

There is no centralized middleware authorization filter. Most controllers manually check Session["CompID"] and redirect to login when empty.

Multi-company by design

Every authenticated request is scoped to the company selected at login (CompID). Pass CompID (from session) into DAL calls and stored procedures.

Common Mistakes

Mistake	Why it fails	Correct approach
Adding EF or direct SQL in controllers	Breaks established DAL/SP pattern; bypasses timeout and connection handling	Add a DAL method calling the appropriate SP
Using wrong connection string name	Runtime ConfigurationErrorsException or wrong database	Use MyConnectionString via BaseHelper
Fixing Area typos (Adminisration)	Breaks existing URLs, bookmarks, and redirects	Keep route names as registered
Assuming Git contains full schema	SP may exist only in deployed SQL Server	Coordinate DB changes with DBA / deployment scripts

Next Steps

1. Read MVC Architecture to understand how Areas and layouts organize the UI.
2. Follow Authentication Flow to see how session state is established.
3. Review Data Access Layer before writing any new database interaction.