Why Business Logic Customization Matters in ERP Operations
Manual data entry errors and inconsistent validation create downstream reporting problems that finance and operations teams spend hours correcting. When users can save orders with incorrect totals, exceed credit limits, or modify locked records, the system becomes a source of risk rather than control.
ERP business logic customization addresses this by enforcing rules at the database layer, ensuring validation runs regardless of whether users enter data through the web interface, mobile app, or API integration. Traditional ERP systems require expensive development cycles to implement these controls, but Onfinity ERP offers a structured approach using X-classes and M-classes that finance leaders and ERP administrators can manage with minimal coding expertise.
System-enforced rules that trigger automatically during save, update, or delete actions eliminate the need for manual checks and reduce the compliance burden on your team. This approach ensures that business policies are applied consistently across all user interfaces and data entry points.
How X-Classes Enable Property Management for ERP Tables
X-classes are auto-generated property classes that map directly to database table columns in Onfinity ERP. They inherit from persistent object (PO) classes, which handle save and delete operations consistently across the system.
The X-class generator tool creates these classes automatically from any table, providing type-safe access to data fields without manual coding. When you add a new column to a sales order table or change a field length, you regenerate the X-class to reflect those changes.
This approach reduces manual coding errors and ensures that your custom modules interact with database tables using the same methods as core system functionality. X-classes provide the foundation for persistent object class programming, allowing developers to work with structured data objects rather than writing raw SQL queries.
For finance teams managing custom order tables or operations groups tracking production data, X-classes mean that table structure changes don’t break existing logic. Regenerating the X-class updates all property mappings automatically, maintaining consistency as your data model evolves.
Using M-Classes to Enforce Validation Rules and Business Logic
M-classes provide trigger functionality that executes before save, after save, before delete, and after delete operations. These triggers allow finance and operations teams to enforce business rules at the moment data is committed to the database.
Validation rules can prevent users from saving records that violate business constraints. For example, if your policy prohibits sales orders exceeding a certain amount without approval, the M-class before-save trigger checks the order total and blocks the save operation if the limit is exceeded, displaying a clear error message to the user.
Field-level change detection allows logic to run only when specific columns are modified. If you want to prevent users from changing the grand total field after an order is approved, the M-class checks whether that field has been modified and rejects the update while still allowing changes to other fields like customer notes or delivery instructions.
New record versus update logic enables different rules for data entry and edits. You might allow updates to existing records without restrictions but enforce strict validation on new entries. The M-class distinguishes between these scenarios using a simple parameter, giving you precise control over when validation applies.
Proper naming conventions and module management entries are required for M-classes to execute correctly. The system loads the appropriate assembly based on the table prefix, so following the naming rules ensures your logic runs every time a user saves or deletes data.
Automating Calculations Across Parent-Child Tables
After-save logic in M-classes can calculate line totals by multiplying quantity and price automatically when users enter order line data. Instead of relying on users to enter correct totals or building complex UI logic, the system computes values at save time and writes them back to the database.
Parent table totals, such as the grand total on a sales order header, can be computed by summing all related child records. The M-class retrieves all line items associated with the order, loops through the results, sums the line totals, and updates the header record with the calculated amount.
This eliminates manual calculation errors and ensures data consistency across linked records. When a user adds, updates, or deletes an order line, the header totals recalculate automatically without requiring additional user actions or separate batch processes.
M-class logic retrieves related records using table queries that filter by parent ID, ensuring only relevant child records are included in calculations. Values are set programmatically and saved back to the database, maintaining referential integrity and providing an audit trail of all changes.
Setting Up Module Management and Namespace Configuration
Module management entries must be created with the correct module prefix, assembly name, and namespace for X-classes and M-classes to function properly. The system uses this configuration to locate and load your custom logic at runtime.
Naming conventions depend on table prefix length. Tables with two characters or fewer before the first underscore follow one naming pattern, while tables with longer prefixes follow another. For example, a table named AD_Table results in an M-class named MTable, while a table named VA001_SalesOrder results in MVA001SalesOrder.
X-classes and M-classes must reside in the model folder within the module structure. This folder organization tells the system where to find your custom classes and ensures proper compilation and deployment.
Cache reset is required after configuration changes to activate new logic. When you add or modify an M-class, the system needs to reload assemblies to recognize the changes. Performing a cache reset ensures your updated logic executes on the next save operation.
Proper namespace alignment ensures the system loads and executes custom logic during data operations. Mismatched namespaces or incorrect assembly references prevent M-classes from running, so verifying these settings during initial setup prevents troubleshooting later.
When to Use X-Classes and M-Classes vs. Other Customization Methods
Use M-classes for server-side validation that must apply regardless of user interface or API access. When business rules need to be enforced during batch imports, integrations, or any data entry method, M-classes provide consistent control at the database layer.
X-classes are necessary when extending or modifying table structures in custom modules. They provide the data access layer that M-classes and other custom code rely on, ensuring type-safe interactions with database tables.
For real-time field calculations during data entry that need to update other fields before users click save, consider callouts, which will be covered in separate sessions. M-class logic executes when records are saved, making them ideal for validation and post-save calculations rather than interactive field updates.
This method is appropriate for finance and operations teams who need reliable, auditable business rule enforcement. Database trigger implementation through M-classes ensures that rules are applied consistently and logged for compliance purposes, giving teams confidence that policies are being followed across all data entry channels.
See X-Class and M-Class Customization in Your Environment
If your team needs to enforce custom business rules and automate calculations across complex order or transaction workflows, Onfinity ERP’s X-class and M-class framework can reduce manual errors and development overhead.
Request a demo to see these capabilities in your own business context, or follow us on LinkedIn for more technical insights into ERP customization best practices.