Skip to main content

​
Purpose

The Business Rules Layer (BRL) serves as the intermediary tier between the Presentation Layer and the Data Access Layer (DAL) in SMAF’s three-tier architecture. This layer encapsulates all business logic, validation rules, and domain-specific operations for expense and travel allowance management.

​
Key Responsibilities

Business Logic Enforcement

Implements Mexican Federal Public Administration expense policies and validation rules

Data Orchestration

Coordinates complex operations across multiple DAL components

Authorization Workflows

Manages approval chains and status transitions for commissions and expenses

Calculation Engine

Computes travel allowances, reimbursements, and budget allocations

​
Architecture Pattern

The BRL implements a Manager-based pattern where each domain entity has a dedicated manager class: 
namespace InapescaWeb.BRL
{
    public class MngNegocio[Entity]
    {
        // Static methods that delegate to DAL
        public static Entity Method(parameters)
        {
            return MngDatos[Entity].Method(parameters);
        }
    }
}

​
Core Manager Classes

Manager ClassDomain Responsibility
MngNegocioComisionCommission lifecycle management and CRUD operations
MngNegocioComprobacionExpense verification and fiscal compliance validation
MngNegocioPagoPayment processing and disbursement logic
MngNegocioMinistracionBudget allocation and fund release management
MngNegocioViaticosTravel allowance rate calculations
MngNegocioXmlCFDI invoice XML processing and validation
MngNegocioGenerarRefBank reference generation for payments

​
Design Principles

​
1. Stateless Operations

All BRL methods are static and stateless, enabling simplified invocation from the presentation layer: 
// Example: Retrieve commission details
Comision commission = MngNegocioComision.Detalle_Comision(
    psFolio: "2024-001",
    psDep: "CRIP-SC",
    psComisionado: "JALP001",
    psEstatus: "AUTORIZADA"
);

​
2. Separation of Concerns

The BRL never accesses the database directly. All data persistence operations are delegated to the DAL: 
public static List<Comision> Regresa_ListComision(
    string psUsuario, 
    string psPeriodo, 
    string psEstatus = "")
{
    // Delegates to DAL - no database logic here
    return MngDatosComision.Regresa_ListComision(psUsuario, psPeriodo, psEstatus);
}

​
3. Validation Before Persistence

Business rules are enforced in the BRL before data reaches the DAL:
The BRL validates that commission dates do not overlap for the same employee:
public static bool Comision_Extraordinaria(
    string psUsuario, 
    string psFechaInicio, 
    string psFechaFinal, 
    string psOpcion)
{
    return MngDatosComision.Comision_Extraordinaria(
        psUsuario, psFechaInicio, psFechaFinal, psOpcion
    );
}
Enforces SAT regulations on continuous travel day limits:
public static string Obtiene_Dias_Continuos(
    string psFechas, 
    string psComisionado, 
    string psTerritorio)
{
    return MngDatosComision.Obtiene_Dias_Continuos(
        psFechas, psComisionado, psTerritorio
    );
}
Prevents duplicate invoice submission:
public static string Exist_UUUID(string psUUID)
{
    return MngDatosComprobacion.Exist_UUUID(psUUID);
}

​
Parameter Naming Convention

The BRL uses Hungarian notation with prefixes indicating data types:
​
ps[Name]
string
String parameters (e.g., psUsuario, psFolio, psEstatus)
​
pi[Name]
int
Integer parameters (e.g., piOpcion, piSecuencia)
​
pb[Name]
bool
Boolean parameters (e.g., pbBandera, pbUsuarioPagador)
​
po[Name]
object
Object parameters (e.g., poComision, poEntidad)

​
Status Transition Management

The BRL orchestrates complex state machines for commission workflows:

​
Status Update Method

public static bool Update_estatus_Comision(
    string psEstatus, 
    string psUsuario = "", 
    string psFolio = "", 
    string psDep = "", 
    string psArchivo = "", 
    string psObservaciones = "", 
    bool x = false)
{
    return MngDatosComision.Update_estatus_Comision(
        psEstatus, psUsuario, psFolio, psDep, psArchivo, psObservaciones, x
    );
}

​
Transaction Coordination

While individual BRL methods are stateless, complex operations require coordinated calls: 
// Example: Commission authorization workflow
// Step 1: Update commission status
MngNegocioComision.Update_estatus_Comision(
    psEstatus: "AUTORIZADA",
    psUsuario: currentUser,
    psFolio: folioNumber,
    psDep: department,
    psArchivo: archiveId
);

// Step 2: Generate official document
MngNegocioComision.Inserta_Oficio_Comision(
    poComision: commissionObject,
    psOficio: officialDocumentNumber
);

// Step 3: Update file paths
MngNegocioComision.Update_ruta_Comision(
    psRuta: documentPath,
    psArchivo: archiveId,
    psDep: department,
    psComisionado: employeeId,
    psOficio: officialDocumentNumber,
    poComision: commissionObject
);
The presentation layer is responsible for transaction management when coordinating multiple BRL calls. Each BRL method executes independently.

​
Error Handling Philosophy

BRL methods typically return:
  • Boolean for success/failure operations
  • String for calculated values or validation messages
  • Entity objects for data retrieval
  • Lists for collection queries
// Boolean return example
public static Boolean Inserta_Comision(
    string psClv_Oficio,
    string psTipoComision,
    // ... many parameters ...
    string psPais, 
    string psEstado)
{
    return MngDatosComision.Insert_Comision(
        psClv_Oficio, psTipoComision, /* ... */ psPais, psEstado
    );
}
Exceptions are not caught in the BRL - they bubble up to the presentation layer for user-facing error messages.

​
Integration with Entities

The BRL heavily uses entity classes from InapescaWeb.Entidades namespace: 
using InapescaWeb.Entidades;

// Entity usage example
public static Comision Detalle_Comision(
    string psFolio, 
    string psDep, 
    string psComisionado = "",
    string psEstatus = "")
{
    return MngDatosComision.Detalle_Comision(
        psFolio, psDep, psComisionado, psEstatus
    );
}

​
Common Entity Types

  • Comision: Full commission details with nested properties
  • Entidad: Generic key-value entity for dropdowns and catalogs
  • GridView: Specialized entity for data table binding
  • comprobacion: Expense verification details
  • Ministracion: Budget allocation records

​
Performance Considerations

Thin Layer Pattern

Most methods are simple pass-through calls, minimizing overhead

Dataset Returns

Some methods return DataSet for complex multi-table results

Optional Parameters

Extensive use of optional parameters reduces method proliferation

String-based Logic

Calculations return strings to avoid decimal precision issues

​
Best Practices for BRL Development

  1. Always validate inputs before passing to DAL
  2. Use descriptive parameter names following Hungarian notation
  3. Return meaningful values - empty strings, nulls, or zero for invalid states
  4. Keep methods stateless - no class-level variables
  5. Delegate all database operations to the DAL layer
  6. Document business rules in code comments

Commission Management

Deep dive into MngNegocioComision methods

Verification Management

Expense validation and reimbursement logic

Payment Management

Payment processing and bank reference generation

Data Access Layer

Understanding the DAL that BRL depends on

Build docs developers (and LLMs) love

Get started for freeTalk to us