E-Patterns Technical Strengths

Contents

1. Generic Models underlying key areas of enterprise solutions
2. Item Framework: 
3. Multi-Setups: 
4. Party Framework: 
5. A general entry transaction framework:
6. Meta-description of all entry transactions: 
7. Requirements specification and Design Documentation: 
8. Workflow Flexibility:
9. Vertical Industry Definitions: 
10. General Model for Transfer to GL Accounts: 
11. Segments: 
12. Migration Tool:  

• Best practices and concepts adapted from Oracle, JD Edwards and other ERPs
• Modified and customized for Pakistani requirements. Highly configurable and adaptable business rules, user interfaces, and workflows.
• Based on a reliable conceptual framework of meta-descriptions of entry transactions. The conceptual framework based on experience of over 50+ organization, their processes and evolution of three generations of the products.
• Party Framework based on Know One-Know All concept. If you know one party type you know all.
• Know One-Know All Item Framework. Know one class of item, you know all kinds of items (WIP, service, labor, materials, finished goods, spare parts, assets etc.)
• Standardized Transaction Framework. All data entry transactions are specialization of a fundamental configurable and run-time adaptable transaction.

Generic Models underlying key areas of enterprise solutions

Item Framework:

• A general item model that provides uniform treatment to all kinds of items
  • Raw materials, finished goods, WIP, Assets, Services etc.
  • The general framework allows issue, receipts, and transfers to be handled similarly for assets as for any other item.
  • Charging of expenses, services and labor to cost centers/departments, then, becomes just a special case of issue of items to the departments.

Multi-Setups:

• Multiple companies, multiple business units, multiple groups of companies. Multiple currencies etc. Multiple units of measures: Different units of measure for transaction quantity and for the primary quantity. Support for auto-conversion among the units of measures.

Party Framework: 

• A general party model providing uniform treatment for internal and external parties, individuals and organizations, and internal organizational hierarchy.
  • External: Customer, Suppliers, Bank, Transporter, Agents
  • Individuals: Employees, Directors etc.
  • Internal: Company, Business Unit, Stores, Departments etc.
  • Multiple roles for the same party
  • Inspired from Data Resource Model by Len Silverston

A general entry transaction framework:

•  The model makes all sales, purchase, inventory, production, imports and exports transactions to be special cases of the same generic entry transaction. Any enhancement to functionality, GUI or a feature made in one entry transaction then becomes available everywhere.
  • This is a very brief statement of a capability that is to the heart of the business patterns technology.
  • The framework is the distillation of the experience gathered over the last five years.
  • The general entry transaction framework is driven by the meta-description of entry transactions.

Meta-description of all entry transactions: 

• A meta-description provides an abstract definition of attributes of all the entry transaction. The meta-description is stored in the database and enables the following capabilities:
  • Flexibility to selectively make visible attributes of transactions according to needs of customers.
  • Flexibility to define customer specific default values
  • Flexibility to customize formulae for derived values in the forms.
  • Flexibility to re-label form controls
  • Flexibility to define any number of specialized transaction types without recompiling
  • Flexibility to insert and change business rules in the database
    • To manage inventory at any party role e.g. warehouse, store, department, asset, supplier, customer, employee, etc.
    • To transfer and receive items from any party role.
    • To create serial/lot items or use them in any transaction
    • To track a transaction through any other transaction
  • Flexibility to provide solutions for specific vertical industries
  • Flexibility to map the transaction to a different table in the database or to map a field to another field in the database
  • To control and override properties such as mandatory, visible, editable, display label, default values, derived formulae etc.
  • Dynamic changing and redefinition of formulae for derived fields

Requirements specification and Design Documentation: 

• The meta-description serves a most important function as the design and documentation of the functionality provided by each entry transaction.
  • Analysis document given to development is now simply a list of attributes in the meta-description.
  • A new transaction is a specification of the attributes to be reused from one or more existing transactions and definition of new ones if required.
  • The meta-descriptions drive the transaction framework. They force the synchronization of the coding to the meta-description (and hence to the documentation).
  • Meta-description can also serve as a source of user-documentation

Workflow Flexibility:

• Flexible definition of workflow where a transaction can be made to occur against any other transaction.
• Generic rules that help in populating the fields of the subsequent transaction with values from the previous transaction. This can be done without any coding. Dynamic changing of the mapping of a field of a transaction to a field of the pervious transaction.
• Definition of subsequent and previous transaction can be done at run-time without requiring coding or recompiling.

Vertical Industry Definitions: 

• Ability to maintain industry specific meta descriptions of transactions
  • Ability to switch among the various industry meta descriptions
  • Currently, the ERP supports the following industries; Textile, pharmaceutical, chemicals,

General Model for Transfer to GL Accounts: 

•  Many transactions in purchases, sales, payroll, imports and exports require a corresponding entry in GL.  The general model enables any transaction of any module to be mapped to a defined accounting transaction. The mapping is stored in the database and can be changed dynamically. Following transfers are currently supported.
  • Transfer of Purchase Invoice, LC, purchase returns etc
  • Transfer of Sales Invoice, sales returns)
  • Transfer of payroll transactions for loans, advances, pay-slip components

Segments:

• Multiple segments for accounting transactions

Migration Tool: 

• A utility that compares the databases of the clients with the development database and generates scripts to bring up the client-database to the current version.
  • Provides scripts for database upgrades
  • Provides scripts for managing meta-descriptions