WO2015059713A2 - User oriented driver-driven enterprise resource planning system - Google Patents

Description

TITLE

USER ORIENTED DRIVER-DRIVEN ENTERPRISE RESOURCE PLANNING SYSTEM

FIELD OF THE INVENTION

The present invention relates generally to a computer programme for Enterprise Resource Planning and more particularly a user oriented Enterprise Resource Planning with a robust structure to cater to building and managing any conceivable Business Structure vis-a visa an entity with no vertical or horizontal limits.

BACKGROUND OF THE INVENTION

With growing needs for Information Technology used in any business activity, the present Enterprise Resource Planning systems available provide solutions which are functionality oriented with less focus on the user at any level. The user is having no choice but to adopt systems from available business solutions of Enterprise Resource Planning Systems at whatever performance level they are available.

However the present invention is an attempt to provide an Enterprise Resource Planning System which is user oriented with an object to utilize the Operational Research techniques with the help of which any kind of user will be able to maximize profits.

Also it provides a system which will enable analysis, decision making and evolution of the problems faced with an alternative solution.

Also it is an attempt to provide a system in which maximum operations can be achieved in minimum time with the least key presses. OBJECT OF THE INVENTION

The main object of the Invention is to provide a user oriented Enterprise Resource Planning solution.

The other object of the invention is to provide an Enterprise Resource Planning System which can be built, adopted and managed in any permutation and combination for any business entity.

Another object of the invention to provide an Enterprise Resource Planning System with minimum human skilled Resources with Complete control over environmental set-up.

All the system features collectively, ultimately help the user to improveperformance, accuracy and reduce workload.

DESCRIPTION OF THE INVENTION

(A) The following features briefly explain the implementation of the subject Matter Enterprise Resource Planning System and solution.

[1] THE DRIVER-DRIVEN ARCHITECHTURE TO MANAGE YOUR

EMPIRE!

The Driver-Driven Architecture is the foundation that gives this user oriented ERP system the potential to provide unmatched unique features on one single platform.

The Driver-Driven Concept

"Whatever is Driven has a Driver!" is the basis of the architecture used in this system to manage your empire with no horizontal or vertical limits. What is Driven has a Driven-Code and a Driver-Code. The Driver-Code is basically the Driven-Code of the Driver.

The basic building blocks of the Driver-Driven Architecture: The 7 basic building blocks of the Driver-Driven Architecture are as follows:

[1] Conceptual Group

[2] Working Group

[3] ERP Member

[4] Physical Department

[5] Functional Unit

[6] Menu

[7] Button

Let's understand each one of these in detail.

[1] Conceptual Group

Conceptual Group is basically a Group which is a concept and no working takes place in it. In India, any business structure fits into the following five Standard Conceptual Groups:

[a] Trust

[b] Company

[c] FIRM, Association Of Persons (AOP) And Body Of Individuals (BOI)

[d] Sole Proprietor

[e] Individual

[f] HUF

Rishi ERP allows one to design and manage one's empire under these Standard Conceptual Groups. These alternatives can be modified to include the complete gamut of Business according to the country where Rishi ERP is being used.

Properties of a Conceptual Group:

[1] A Conceptual Group can only drive other Conceptual or Working Groups or a combination of both.

[2] A Conceptual Group can only be driven by another Conceptual Group.

[3] Any Standard Conceptual Group does not have a driver.

Concerned Tables:

[1] Gross_GlobalFile

[2] Group_Details [2] Working Group

A Working Group is a Group under which the actual working takes place.

Properties of a Working Group:

[1] A Working Group can only drive other Working Groups or ERP Members or both in any combination.

[2] A working Group can only be driven by either a Conceptual

Group or a Working Group.

[3] A working Group will always have a driver.

Concerned Tables:

[1] Gross_GlobalFile

[2] Group_Details

[3] ERP Member

An ERP Member is where the actual working happens in an organization. It is analogous to a working Branch of any Organization. Properties of an ERP Member:

[1] An ERP Member can only be driven by a Working Group.

[2] An ERP Member only drives the Physical Departments under it, that carry out the day to day operations with the support of the

Functionalities added to each Physical Department.

[2] It cannot drive another ERP Member or Group.

[4] An ERP Member can start its operations only when it drives at least one Physical Department with at least one Functional units driven by it.

[3] An ERP Member can uniquely be the Head of other ERP Members driven by its driver.

[4] At any stage, if an ERP Member wants to Drive new ERP Members, then that ERP Member gets converted into a Working Group which drives the new ERP Members along with that original ERP Member. Thus at any time one's Business Structure can be expanded vertically or horizontally without any limits.

Concerned Tables: [1] Grossj3lobalFile

[2] Details

[4] Physical Department

The logical distribution of responsibility for the working of any Branch of an Organization is achieved by having Physical Departments under every ERP Member.

Properties of a Physical Department:

[1] A Physical Department can only be driven by an ERP Member.

[2] A Physical Department drives only the Functional Units it has. Concerned Tables:

[1] Details

[2] Dept

[5] Functional Unit:

The Functional Unit helps run the day to day operations. Rishi ERP provides the following Functional Units that any Physical Department can have in any combination:

[a] Finance

[b] Trading

[c] Manufacturing

[d] HR

[e] Periodicals

[f] Service

[g] Entrance Security

[h] System Administration

[i] Hotel Management

[j] Dispatch Management

[k] Transport Management

[I] IT

[m] Press

Any new Functional Unit that is developed becomes available throughout the empire to any Physical Department due to this architecture. Properties of a Functional Unit:

[1] A Functional Unit only drives menus.

[2] A Functional Unit is driven by a Physical Department.

Concerned Tables:

[1] Details

[2] Dept

[6] Menu:

A Menu is a menu option or what is displayed to the user on the screen where the user inputs are accepted and results displayed.

Properties of a Menu:

[1] A Menu drives another menu or a form that is displayed on the screen along with buttons that are to be displayed on that form.

[2] A Menu can be driven by a Functional Unit or another menu.

[3] Only a Menu that drives a form may optionally drive a button. Concerned Tables:

[1] Dept

[2] MenuFile

[7] Button:

A Button is the smallest unit in the Driver-Driven Architecture.

Properties of a Button:

[1] A Button drives a form that is displayed or a menu that drives a form.

[2] A Button can be driven by a menu only.

Concerned Tables:

[1] MenuFile

[2] ButtonFile

The Database Tables and their structures:

The Database Tables and their structures which are the key to the functioning of the Driver-Driven Architecture are as follows:

[1] Gross_GlobalFile Table:

The Gross_GlobalFile Table is the most important table where the main structure of your Empire resides. It stores the driver-driven details of all Groups and ERP Members. The critical fields for this architecture are as follows:

[1] Driven = The name of the Group or ERP Member the record represents.

[2] Full Name = Full Name of Driven

[3] ShortName = A short name for Driven.

[4] DnCode = Driven-Code which auto-increments when a new record is added.

[5] Driver = The name of the Driver (Conceptual or Working Group).

For Standard Conceptual Groups, Driver = "HOS"

[6] DrCode = Driver-Code. DrCode = 0 for Standard

Conceptual Groups. [7] Path_Type = "NEW" or "DEFAULT" or "EXISTING"

Path_Type options are only given to Conceptual or Working Groups. For ERP Members, Path_Type is "EXISTING".

[8] If Path_Type = "DEFAULT" then BrPath = "DATA\DB0"

If Path_Type = "NEW" then BrPath = "DATA\DB" + STRING(DnCOde)

If Path_Type = "EXISTING" then BrPath = BrPath of Driver. The root path with the BrPath is basically where the Database is maintained.

[9] BType= "GROUP" or "ERP Member". BType defines if the driven is a Group or a Member. If Group then the details whether it is a Conceptual or Working Group is updated in the Group_Details Table.

[10] if BType = "GROUP" then HO = 0

If BType = "ERP Member" then HO = DnCode of the Driver whose driver is a Conceptual Working Group Working Group in the hierarchy above that ERP Member.

[1 1] ALevel = 1 for the Driven whose DrCOde = 0.

ALevel = (ALevel of its Driver) + 1.

This basically tells the level at which the Driven is in the Business Structure.

[12] YearlD = Current Year

[2] Group_Details Table:

The Group_Details Table holds the complete details about the Group along with its type (Conceptual or Working). The critical fields for this architecture are as follows:

[1] DnCode = DnCode assigned in the Gross_GlobalFile Table.

[2] If Concept = "C" then the Group is a Conceptual one.

If Concept = "W" then The Group is a Working one.

[3] Details Table:

The Details Table holds the complete details of all ERP Members.

The critical fields for this architecture are as follows:

[1] DnCode = DnCode assigned in the Gross_GlobalFile Table.

[2] If HO_Branch = "HO" the ERP Member is the HO of other ERP

Member on the same level.

[3] LeveINo = ALevel of the ERP Member in the Gross_GlobalFile table.

[4] Dept Table:

Department Table holds the driver-driven details about the Physical Departments with its Functional Units under any ERP Member. The critical fields for this architecture are as follows:

[1] DnCode = DnCode of the ERP Member from the Gross_GlobalFile Table to which the Physical Department with its Functional Units belong.

[2] Driven = Name of the Driven Physical Department or Functional Unit.

[3] DnCd Driven-Code of any Physical Department or Functional Unit.

[4] Driver Name of the Driver ERP Member or Physical Department.

[5] DrCd Driver-Code of any Physical Department or Functional Unit.

[6] ALevel represents the level. [7] Type = "PHYSICAL" or "FUNCTIONAL" or ""

[8] YearlD = Current Year.

When a new ERP Member is created and a new Physical Department with its Functional Units are added to it then the following procedure is followed:

[a] Add record with Driven = "MAIN ERP MENU", DnCd = 1 , DrCd = 0, ALevel = 1 , Type = "", DnCode = DnCode of the ERP Member from the Gross_GlobalFile Table.

[b] Add record with Driven = Name of ERP Member in contention , DnCd = 2, DrCd = 1 , ALevel = 2, Type = "", DnCode = DnCode of this ERP Member from the Gross_GlobalFile Table.

[c] Add records of the Physical Departments with Driven = Name of Physical Department, DrCd = 2, DnCd = Incremental from 3 onwards. ALevel = 3, Type = "PHYSICAL", DnCode = DnCode of its Driver.

[d] Add records of the Functional Units with Driven = Name Of Functional Unit, DrCd = DnCd of Driver Physical Department, DnCd = The DnCd of the Functional Unit from the table, ALevel = 4, Type = "FUNCTIONAL", DnCode = DnCode of its Driver.

"MAIN ERP MENU" is an entry point menu from software prospective.

MenuFile Table:

The MenuFile table holds the driver-driven details of Menus. This table along with the ButtonFile table contains details of what will be displayed on the screen. The critical fields for this architecture are as follows:

[1] All records of a Functional Unit have the same MenuGroup value. The records of the first Functional Unit has MenuGroup = 1 and then on it increments by 1 for the next set of records representing a Functional Unit.

[2] FPrompt is the Menu Option that the record represents.

[3] DPrompt is the display name of FPrompt

[4] MenuDrCOde is the Driver-code of that Menu which can be either the driven code of the Driven in the Dept table or the MenuDnCode of an Menu Option represented by FPrompt.

[5] MenuDnCode is the Driven-Code of the Menu option or Menu.

Where FPrompt = Name of a Functional Unit, MenuDnCode = DnCd of that Functional Unit in the Dept table. [6] RunProc is the name of the procedure to generate the Menu on the screen depending upon rights. For a Menu option, RunProc="".

[7] BCriteria = "BRANCH" or "TOTAL". Records with BCriteria = "BRANCH" are for Menu or Menu options that are for normal end users. Records with Criteria = "TOTAL" are for Menu or Menu options that aid basic consolidations at Group, ERP Member or Physical Department level.

When a new Functional Unit needs to be added:

[1] A record is added with MenuGroup = last MenuGroup value + 1 , MenuDrCode = 0, MenuDnCode = 100, FPrompt = "Mainerpmenu", DPrompt = FPrompt, BCriteria = "BRANCH" or "TOTAL", ALevel = 0 and RunProc = "". This is the default first record added for any Functional Unit.

[2] New record is added with MenuGroup = value as in [1], MenuDrCode = 1 , MenuDnCode = DnCd of that Functional Unit in the Dept table, FPrompt = Driven in the Dept Table where DnCd = MenuDnCode, , DPrompt = Display Name of the Functional Unit in the menu, BCriteria = "BRANCH" or TOTAL", ALevel = 1 and RunProc = "" if this drives another menu option else it is assigned the procedure that the program will call to generate the form.

[3] MenuGroup = same as [2], MenuDrCode = MenuDnCode of the Driver, MenuDnCode = incrementing by 1 after the MenuDnCode of the Functional Unit as we add menu options under it, FPrompt and DPrompt are the menu option name and display name, BCriteria = BCritertia of Driver, ALevel = (ALevel of Driver) + 1 and RunProc = "" if this drives another menu option else it is assigned the procedure that the program will call to generate the form. ButtonFile Table:

The Button File stores the details of Buttons that are driven by the Menus in the MenuFile Table. Whatever Buttons are driven by a particular Menu are displayed depending upon rights on the form generated by the procedure mentioned in RunProc of that Menu in the MenuFile table. The critical fields for this architecture are as follows:

[1] Ail records that are driven by a Menu have the same

MenuGroup value. The records of the first Menu and the Buttons it drives, have MenuGroup = 1 and then on it increments by 1 for the next Menu and its driven Buttons.

[2] MenuDrCode holds the MenuDnCode of the driver.

[3] MenuDnCode is the Driven-Code of the Driven which is auto-incremental. [4] BCaption = Display name of the Button.

[5] RunProc = the procedure to be executed when the Button is clicked.

When a Menu wants Buttons on its form the following steps are required:

[1] Add record with MenuGroup = Current maximum MenuGroup value + 1 , MenuDnCode = auto-incrementally generated, MenuDrCode = MenuDnCode of Driver Menu from MenuFile table, RunProc = "" and other details.

[2] Add record for every Button with MenuDrCode = MenuDnCode in [1], MenuGroup = MenuGroup of driver, RunProc = Procedure to be run when Button clicked.

INPUT-PROCESS-OUTPUT CHARTS

Module name: Manage My Empire (1.0)

Module name: Authentication (3.0)

INPUT PROCESS OUTPUT

[1] IF ERP User Authenticated User Authenticated THEN details with selection transfer control to module settings are transferred Generate Screen (3.1) to module 3.1 with

User Name & with vDrCode=0, vDrCode=0,

Password from User vDnCode=0, vDrCd=0, vDnCode=0, vDrCd=0, Entry on the Screen vDnCd=0, vDnCd=0,

vMenuDnCode = 0 and vMenuDnCode = 0 and vMenuDrCode = 0 ELSE vMenuDrCode = 0 or to module Authentication unauthenticated details Failure (3.2). are transferred to

Module name: Screen Generation (3.1)

INPUT PROCESS OUTPUT

[1] IF (vDnCode = 0) OR

(there is atleast one

Transfer Control to

Authenticated User Driven in the

3.1.1 with details .vDrCode, GrossGlobalFile table

Authenticated User vDnCode, vDrCd, with DrCode = vDnCode)

details, vDrCode, vDnCd, then transfer control to

vDnCode, vDrCd, vMenuDrCode and module Group or ERP

vDnCd, vMenuDrCode vMenuDnCode Member Selection

and vMenuDnCode. (3.1.1).

[2]IF a Group is selected

(BType = "GROUP" for

DnCode = vDnCOde in

Gross_GlobalFile table)

THEN Do Nothing ELSE

IF the selected ERP

Member does not have

any Physical

Departments (No record

present with DnCode =

vDnCode in Dept Table)

THEN Do Nothing ELSE

IF the selected Physical

Department has not been

assigned any Functional

Units (No record in Dept

table with DrCd = (DnCd

of Driven when Alevel =

2 AND DnCOde = vDnCode in Dept table))

THEN Do Nothing ELSE

IF No procedure is

assigned to a menu ((No

record with MenuDrCode

= vMenuDnCode in

MenuFlle table) AND

(For MenuDnCode =

vMenuDnCode, RunProc

= "")) THEN DO Nothing.

[3] If vMenuDnCode = 0 Transfer Control to then transfer control to 3.1.2 with the module Physical Authenticated User Department or Functional details, vDrCode, Unit or Menu Selection vDnCode, vDrCd, (3.1.2) vDnCd, vMenuDrCode and vMenuDnCode.

[4] if RunProc = "" for

MenuDnCode =

vMenuDnCode in Transfer Control to MenuFile table then 3.1.2 or 3.1.3 with transfer control to the Authenticated User module Physical details, vDrCode, Department or Functional vDnCode, vDrCd, Unit or Menu Selection vDnCd, vMenuDrCode (3.1.2) else to module and vMenuDnCode. Generate Menu with

Buttons (3.1.3)

Module name: Group or ERP Member Selection (3.1.1).

INPUT PROCESS OUTPUT

Authenticated User [1] Depending upon the Show the generated details ,vDrCode, authenticated ERP form on screen and vDnCode, vDrCd, User's rights in Rishi wait for User Input. vDnCd, ERP , a menu showing

vMenuDrCode and the list of Driven from

vMenuDnCode Gross_GlobalFile Table

with DrCode = vDrCode

is generated and the user

is asked for his selection

and what he wants to do

on that selection("+" or

"ENTER" KeyPress) By

default the selection is on

the Top of the Driven list.

[2] vDnCode = DnCode

Key Press "+" or and vDrCode = DrCode

"ENTER" made on of the selected Group or

the Selection ERP Member from the

Gross_GlobalFile table

[3] IF Key Press =

"ENTER" THEN IF the

selected is a ERP

Member without atleast

If condition satisfied, one Functional Unit (No

transfer control to the record in Dept table with

module 3.1 or 3.1.1.2 DrCd = (DnCd of Driven

with Authenticated User when Alevel = 2 AND

details .vDrCode, DnCOde = vDnCode in

vDnCode, vDrCd, Dept table)) then transfer

vDnCd, vMenuDrCode control to the module

and vMenuDnCode. Add Physical Dept./

Functional Units (3.1.1.2)

else transfer control to

the module, Screen Generation (3.1) Process

[1]

Transfer control to

[4] IF Key Press = "+"

module Screen THEN transfer control to

Generation (3.1) with the module Add

Authenticated User Conceptual Group /

details .vDrCode, Working Group / ERP

vDnCode, vDrCd, Member(3.1.1.1)

vDnCd, vMenuDrCode and vMenuDnCode.

Control is transferred to

RETURN Control to 3.1

3.1.

Module name: Add Conceptual Group / Working Group / ERP Member(3.1.1.1)

INPUT PROCESS OUTPUT

WHEN

CASE1 (The selected

option is a Conceptual

Group (BTvpe=

"GROUP" for DnCOde

Authenticated User = vDnCode in Show the Generated details ,vDrCode, Gross GlobalFlle table Form to Screen and vDnCode, vDrCd, AND Concept = "C" for wait for user to enter vDnCd, vMenuDrCode DnCode = vDnCode in the required details and vMenuDnCode Group Details table)): and press CTRL+W.

Generate form to take

details from user

where he can only add

another Conceptual

Group or Working

Group. CASE2 (BTvpe= "GROUP" for DnCode

= vDnCode in Gross GlobalFile table AND Concept = "W" for DnCode = vDnCode in

Group Details table)): Generate form to take details from user where he can only add another Working Group or ERP Member.

CASE3 (The selected option is an ERP Member (BTvpe= "ERP MEMBER" for DnCode = vDnCode in Gross GlobalFile table)):

Add Working Group record with new DnCode but same ERP Member details in Gross_GlobalFile and Group_Details tables with, DrCode = vDrCode, Driven = Same details as ERP Member, ALevel = ALevel of this ERP

Member, PathType =

"EXISTING". BType =

"GROUP", Concept =

"W".

Update ERP Member

record in

Gross_GlobalFile table

with DrCode = DnCode

of the new Working

Group, ALevel = Alevel

+ 1.

vDnCode = New

Working Group

DnCode, vDrCode =

DrCode of new

Working Group.

Generate form to take

details from user

where he can only add

another Working

Group or ERP

Member.

[5] From screen inputs, As per condition, WHEN Casel (Branch transfer control to TvDe = "ERP module 3.1.1.1.1 ,

MEMBER"): 3.1.1.1.2 or 3.1.1.1.3.

CTRL+W Key Press Transfer control to the with user inputs, module Add ERP Authenticated User Member (3.1.1.1.3) details .vDrCode, with screen inputs. vDnCode, vDrCd, vDnCd, Case2(BranchTvpe = vMenuDrCode and

"GROUP" and Conceot vMenuDnCode

= "CONCEPTUAL" :

Transfer control to the

module Add

Conceptual Group

(3.1.1.1.1) with screen

inputs.

Case2{BranchType =

"GROUP" and Concept

= "WORKING"):

Transfer control to the

module Add Working

Group (3.1.1.1.2) with

screen inputs.

Control is transferred to 3.1.1 with

Authenticated User

[6] RETURN control to details .vDrCode,

Module 3.1.1 vDnCode, vDrCd, vDnCd,

vMenuDrCode and vMenuDnCode

Module name: Add Conceptual Group (3.1.1.1.1)

INPUT PROCESS OUTPUT

[1] Create a record in

Gross_GlobalFile Table

with new DnCode,

Ho=0, Drcode =

vDncode value of

parent Group, BType =

"GROUP", and the

Group name and

details. WHEN

New record is added to

CaseKPath Tvpe =

the Gross_GlobalFile

"NEW"):

User inputs, Table and a database

BrPath = "DATA\DB" +

authenticated User is created by name = string value of new

details .vDrCode, "GDATA" + String value

DnCode. A database is

vDnCode, vDrCd, of new DnCode + "_" + created by name =

vDnCd, current year + ".dbc". in

"GDATA" + String value

vMenuDrCode and the path = BrPath + of new DnCode + "-" +

vMenuDnCode "\GDATA" + String current year + ".dbc". in

value of new DnCode + the path = BrPath +

"_" + current year. "\GDATA" + String

value of new DnCode +

"-" + current year.

Case2iPath TvDe =

"DEFAULT"):

BrPath = "DATA\DB0"

Case2(Path TvDe =

"EXISTING"): BrPath = BrPath for

DnCode = vDnCode.

[2] Create record in

Group_Details Table

with DnCode = New

New record is added to DnCode given to the

Group_Details Table. new Group, Concept =

"C" and miscellaneous

details.

RETURN control to the Control transferred to module 3.1.1.1 module 3.1.1.1

Module name: Add Working Group (3.1.1.1.2)

INPUT PROCESS OUTPUT

[1] Create a record in

Gross_GlobalFile

Table with new

DnCode, Ho=0, Drcode

= vDncode value of

parent Group, BType =

User inputs,

"GROUP", and the

authenticated User

Group name and New record is added to details .vDrCode,

details. When the Gross_GlobalFile vDnCode, vDrCd,

Table

vDnCd, vMenuDrCode

CaseKPath TvDe =

and vMenuDnCode

"NEW" :

BrPath = "DATA\DB" +

string value of new

DnCode. A database is

created by name =

"GDATA" + String value of new DnCode +

"-" + current year +

".dbc". in the path =

BrPath + "\GDATA" +

String value of new

DnCode + "-" + current

year.

Case2fPath TvDe =

"DEFAULT"):

BrPath = "DATA\DB0"

Case2(Path TvDe =

"EXISTING"):

BrPath = BrPath for

DnCode = vDnCode.

[2] Create record in

Group_Details Table

with DnCode = New

New record is added to DnCode given to the

Group_Details Table. new Group, Concept =

"W" and miscellaneous

details.

RETURN control to the Control transferred to module 3.1.1.1 module 3.1.1.1

Module name: Add ERP Member (3.1.1.1.3)

INPUT PROCESS OUTPUT

User inputs, [1] Create a record in

New record is added to authenticated User Gross_GlobalFile Table

the Gross_GlobalFile details ,vDrCode, with new DnCode, Ho=

Table.

vDnCode, vDrCd, DnCode of the 1^sl vDnCd, vMenuDrCode Parent Working Group

and vMenuDnCode in the Hirarchy above

this ERP Member,

Drcode = vDnCode

value of parent Group

of this ERP Member,

BType = "ERP

MEMBER", and the

Group name and

details. BrPath =

BrPath of the Parent

Working Group.

[7] Create record in

Details Table with

DnCode = New New record is added to DnCode given to the the Details Table.

new ERP Member and

miscellaneous details.

RETURN control to the Control transferred to module 3.1.1.1 module 3.1.1.1

Module name: Add Physical Department / Functional Unit(3.1.1.2):

INPUT PROCESS OUTPUT

Authenticated User [2] Generate Menu to

details .vDrCode, add Physical Show the generated vDnCode, vDrCd, Departments to the menu to the screen to vDnCd, vMenuDrCode ERP Member with get user inputs.

and vMenuDnCode DnCode = vDnCode.

User Input from the [3] Generate menu to Show the menu with screen of the new select and add the Functional Units physical department to Functional units to the that can be added to be added to the ERP physical department the Physical Member. created. Department. User selected

Functional Units to be

added to the Physical

[4] Save details of the

Department and wait

new physical

for user to either add

department with its

new Physical

functional units

Department or press

temporarily.

CTRL+W and save

newly created Physical

department.

User Input to add new [5] Transfer control to Control transferred to Physical department Process [3] Process [3]

[8] Create Records in

the Dept Table with

CTRL+W Pressed by details of the Physical New records are User to save the Departments along added to the Dept Physical departments. with the functional Table.

departments created

by the User.

RETURN control to the Control transferred to module 3.1.1 module 3.1.1

Module name: Physical Department or Functional Unit or Menu Selection (3.1.2):

INPUT PROCESS OUTPUT

[1] As per user rights,

for ERP Member with

Authenticated User DnCode = vDnCode,

Menu with Physical details .vDrCode, display a menu with all

departments options vDnCode, vDrCd, the Physical

for user to to choose vDnCd, vMenuDrCode Departments driven by

from

and vMenuDnCode. it which is got from the

Dept table. Ask for

user selection. [2] vDnCd = DnCd and

vDrCd = DrCd of

selected Physical

Department from Dept

Menu Options of

Physical department table, display a menu

Functional Units for selected with all the Functional

user to choose from Units driven by it which

is got from the Dept

table. Ask for user

selection.

[3] vDnCd = DnCd and

vDrCd = DrCd of

selected Functional

Unit from Dept table. If

the Functional Unit has

atleast one Menu

Option under it then

display a menu with all

the Menu Options

Functional Unit driven by the Menu Options for user selected Functional Unit which to choose from

is got from the Menu

Table and ask for user

selection, else

vMenuDnCode =

vDnCd and transfer

control to module

Screen Generation

(3.1)

[4] vMenuDnCode = Menu with menu

Menu Option Selected MenuDnCode of options for user to selected Menu option choose from from MenuFile table. If

the Menu Option has

atleast one Menu

Option under it then

display a menu with all

the Menu Options

driven by this Menu

which is got from the

Menu Table and ask

for user selection, else

transfer control to

module Screen

Generation (3.1)

[5] Transfer control to

Menu Option Selected

process [4].

Module name: Generate Menu with Buttons (3.1.3)

INPUT PROCESS OUTPUT

[1] The form is generated

by the procedure

mentioned in RunProc for

Authenticated User details MenuDnCode =

.vDrCode, vDnCode, vMenuDnCode in Based on User rights, vDrCd, vDnCd, MenuFile. Buttons, if any, form is generated with vMenuDrCode and that are driven by this Buttons.

vMenuDnCode MenuDnCode are present

in the ButtonFile table

which are also displayed

on the form. [2] LOGICAL COLOR SCHEME FOR ACCOUNTING & INVENTORY:

Colors play a vital role in our daily lives and it has been proven that our activities and responses are influenced by them. This User Oriented Driver- Driven ERP System has a logical color scheme to represent Accounting & Inventory that has a potential to become a Universal Standard.

Understanding the concept of "Credit & Debit" has remained a challenge from laymen to high level managers. This color concept indicates to the user, what he has (Assets) and what he owes to others (Liabilities) by very obvious green & red colors. Similar is the case with Income & Expenses, where Incomes are obviously denoted in green & Expenses in red color. The accounting ledgers will have color as per their nature & accordingly their respective ledgers will also have logical colors. Just by having a look at the report one can understand the financial position.

The same concept has been extended to inventory also where purchase quantity would be indicated in green & sales quantity would be indicated in red. However purchase amount would be indicated in red & sales amount would be indicated in green.

Across this ERP system, anything in BLUE color denotes that drill down is available.

[1] Logical Color Scheme in Accounting:

In Accounting, any Account Head will fall under one of the following four main groups: Assets, Liabilities, Income or Expenditure. Any Account Head will have either a Credit or Debit nature. Account Heads under Assets & Expenses are of Debit nature, and those under Liabilities & Income are of Credit nature.

Logical Color Scheme in the Leqer of an Account Head :

In the leger of any Account Head

[1] The Account Head name, Balance column back color and Balance column figures will be displayed in GREEN if it belongs to Assets or Income Group, or RED if it belongs to Expenses or Liabilities Group.

[2] The back color of the Credit and Debit columns will represent the nature of the leger, ie. For Balance sheet legers, back color of the Credit Column is RED and the back color of Debit column will be GREEN. In case of Profit and Loss legers, Back color of Credit column will be GREEN and that of the Debit column will be RED.

[3] The contra legers and its value will have its color as per their nature.

Logical Color Scheme in the Balance Sheet. Trial Balance & Profit and Loss : In the Balance Sheet, Trial Balance and Profit & Loss Account, the names and figures belonging to Asset or Income are displayed in GREEN and those belonging to Liabilities or Expenditure are displayed in RED.

Logical Color Scheme in Voucher Entry and Day Book:

In Accounting, voucher entry is of the following types: [1] Receipt [2] Payment [3] Purchase [4] Sale [5] Journal [6] Contra. Receipt, Payment, Purchase and Sale voucher entries belong tothe Profit and Loss account. Journal and Contra voucher entriesbelong tothe Balance Sheet.

[1] Voucher type of Receipt, Sale and Contra are displayed in GREEN.

Voucher typeof Payment and Purchase are displayed in RED.

[2] During entries of vouchers of Receipt, Payment, Purchase & Sale, the back color of Debit column is RED and back color of Credit column is

GREEN. During entries of vouchers of Journal & Contra, the back color of

Debit column is GREEN and back color of Credit column is RED.

[3] The color of the figures will be according of the nature of the Account Head

Group.

The Daybook will display multiple voucher entries with each club having color scheme as per the above guideline.

Now lets see a scenario where we do not know which main Group an Account Head belongs to. Here the sheer power of the logical color scheme can be seen. By just observing the color of the figures shown and the background color of the Credit and Debit columns we can immediately determine the Main group to which the Account Head belongs to. While a new ledger is created in an ERP Software the Group Type again can have a logical color scheme depending upon the nature of group. Figures 6, figure 7 and figure 8 are screen shots of an ERP software which shows this scenario. Once a ledger is created, its name wherever shown will have a logical color scheme depending upon the nature of its Group.

[2] Logical Color Scheme in Inventory:

Purchase quantity & Sales value in Inventory are represented in GREEN. Sales quantity and Purchase value in Inventory are shown in RED.

The advantage of this color scheme is useful in scenarios where by mistake a ledger is added to the wrong group. For example when an expense ledger is by mistake added to an Income group, looking at the GREEN color of the figures and knowing that figures in any ledger whose nature is expense is RED, we can immediately identify the mistake. Also a person not from an accounting background can easily start to interpret accounting data.

The world without colors would be very monotonous and this color scheme helps in eradicating this deficiency in Accounts and Inventory in a logical way. Use Of such logical color scheme would be extremely useful to the public at large & specially the senior managers to understand the working of their organization.

[3] ENTRY OBJECT:

In the current erp systems , an entry operator must have knowledge of accounting principles as which ledger would be credited or debited or to which accounting group an account head belongs to or knowledge of voucher types . This poses a limitation of requiring technical personnel . Also for group entries, periodic entries or frequenly used entries user has to do these entries again and again just with few changes in parameters ( like bill no. , instrument no.).

Objects could be assumed as pre - defined templates of the entries which are oftenlyused having some common nature(cash receipt, cash payments, rent, salaries) or accounting heads ( travelling expenses etc.) or be a periodic transactions (like student's school fee etc. , light bills ) . These objects greatly boosts the efficiency of an entry operator as well as require least knowledge of accounting principles. Concept of entry object applies to both accounting as well as inventory . In case of accounting entry object once the object is ready , user did not have the knowledge of credit & debit ledgers and information of ledger . The preparation of the object involves predefining credit & debit ledger & related information such as bank, instrument no. which may be kept as fixed or of variable nature or combination of fix and variable.

In continuation to the basic object , of honoring User is God & to minimizes ease the operations , periodic transaction is such a concept that it can pass 'N' no. of entries of rent , salary , fee etc. , which are of periodic nature ,at the predefined date & with the given sequencing .

While predefining periodic transactions, a ledger of periodic nature , date , amount, frequency , are stored as input and triggred at the right time at the predefined frequency, manually as well as automatic.

Further to above accounting object , there is concept of advance comprehensive accounting object which can pass the set of entries to explain complete nature of transaction .

In addition to this generalize object , there is specific accounting object of interest received , DD preparation , investment , transportation , cash payment , cash receipt which pass the full set of entries along with system generated narration explaining the transaction . Just imagine the work load saved & the ease with which such objects have been the boon for user .

In case of inventory object.user just has to enter name of the supplier & he gets list of all the items supplied by him & user just has to enter the qty. against respected item name . This also serves work of detecting item name from the master file . While entering purchase bills , system automatically senses for any new item buyed from a particular supplier and adds them in the list of supplier items of that supplier which are later offered by the system when bill comes from that supplier.

[4] THE FRONTIER ALGORITHM:

This is a very prudent concept of not running after the water after the fire is set. Leger is a very useful and most frequently used accounting report. Presently in general legers are generated by processing the data on command. Obviously this takes its own time depending upon the size of the data. However in the present case a table, having columns just like leger is used to display the leger . This table is always updated live so that at any point of time it is in the ready to use status. The table also has other important columns which can also display the leger immediately with other conditions like Bank, Instrument no, Party Name , Bill no.

It is like keeping the things ready before they are actually needed. This algorithm keeps the legers ready in required format. It updates the leger live on any change in the basic data.

[5] CASH CONTROL WITH CLUBBING AND DE-CLUBBING OF CURRENCY DENOMINATIONS:

As a part of strict cash control using denominations this feature helps the user to keep the cash record by clubbing small denominations. However to enable the management to have the flexibility in the decision as to what extent lowest denominations are to be recorded the feature of declubbing is also provided. Using both these tools ie. Clubbing and declubbing management can consolidate or expand the denominations as per the suitability over the period of time.

In clubbing operation user is offered to select the denominations which he wants to club meaning the denominations of which he doesn't want to keep the separate track. Notes and coins are seperately clubbed. On clubbing the total value of the selected denominations is stored in the clubbed denominations viz notes and coins with their denominations value as 1. For example, if we selelct not to keep the separate track of notes having denominations rs 1 - 5 and 10, then the total of these four denominations will be reflected against denominations as notes in cash details. In the event of change of decision in maintaining, the denominations can be catered by further clubbing or declubbing existing club of denominations. If one wants to go further selective in not keeping the record of one additional denomination, that denominations would be added in the group of existing club and its value would be changed accordingly. However if the management needs to keep the record of denominations which has already been clubbed, this can be done by removing that particular denomination along with its quantity from the existing club by declubbing operation. Here now the system will start displaying the newly removed denominations along with its quantity separately. Value of this newly removed denomination is reduced from the existing club value.

[6] ENCRYPTED REPORTS:

Secrecy and confidentiality is the heart of accounts. The marital relations , however legal and bonafide would never like to be a public affair. Similarly anybody having funds, however legal, bonafide , hard earned that may be, would not like to make it public. The concept of encrypted reports exactly hits on this subject. The original source data is encrypted usng different conventions, formula at the run time and passed on to the concerned party via soft or hard copy. The encryption logic is conveyed to the concerned party separately so that even if this encrypted report goes in the wrong hands one does not have to worry. The concept basically involves simple conversion formula of credit, debit and date of transaction and name of the leger is also changed. In case of encrypted leger the balances and totals are updated after encryption to avoid any discrepancies. Different encryption formula can be used at different points of time to avoid any clue.

[7] HIBERNATE:

Hibernate is the one more step ahead in serving the user by saving his time in carrying out monotonus operations of pressing the same keys for doing the same operations. The concept keeps the track of last branch and the activity executed by the given user. Next time when the same user logs in, the system leaves him exactly at the same point where he had left during his last log off. User has the freedom to either use or not this feature. [8] RIGHTS ASSIGNMENT TO THE EXTENT OF MINUTES AND BUTTON LEVEL RIGHTS:

Many times it is not advisable to give the rights of some important options to the user for more than few minutes. More particularly when the chief wants to leave for some important work urgently and he wants to delegate some important option rights to his subordinate, he can give the rights for 5 to 10 min and leave the place. The rights would be automatically removed after the predefined period. The system extends tight control on operations even to the lowest level like button. The hierarchy of rights is Conceptual Group, Working Group, ERP Member(Branch), Physical Department, Functional Department, Menu & Buttons.

System never looses the control even for the minutes. System has the ability to assign and remove the rights even for 5 mins. The rights are automatically removed at the predefined time. The system maintains the rights given to the particular user in the table and makes only those options available at runtime. Options for which he has not been given the rights practically do not exist for him at all.

The general philosophy of assigning rights is to include the same in the rights table so that whenever that option is called for the system first of all checks in rights table for the given user. If it is found the work goes ahead else the control is given back.

[9] SMART ENTRY & MULTIPLICATION FACTOR:

Presently the cashiers of even the best banks have to over cautious in entering huge amounts. We have actually seen the cashiers entering the value from keyboard and then counting the zeros in screen just to make sure that nothing goes wrong. This concept can be used extensively across the world in any entry operations involving multiple zeros. In stock market softwares also where buy and sell of huge amount of shares are involved , this feature would be a boon for the user. Where entering huge amounts involving multiple zeros is part of the business it is better to use this concept which will not necessitate entering the last character

In continuation to the achievement of the goal to serve the user as a God by minimizing workload and ease of operation, the system provides the tool to save the user from committing grievous mistakes in entering huge figures involving multiple zeros. Pressing of certain characters only serve the purpose of entering multiple zeros. The following norms indicates corresponding values:

"C" - Crore , "L" - Lakh, "T" - Thousand, "H" - Hundred. These characters entered after any figure would be treated as those many Crores, Lakhs, Thousands or Hundreds as the case may be.

The same concept can be extended for Million, Billion and Trillions also.

Multiplication factor is the concept which helps the user to enter the huge amounts in lakhs and crores by just entering the main figure with which the factor is multiplied by the system to get the required figure. For example if one wants to enter the value in lakhs, the multiplication factor would be set to 1 lakh and the remainder number is only entered . So if we enter 2 it will be displayed as 2 x 1 lakh = 2,00,000. But this is useful on!ywhen all the enteries are in round figure of thousands and lakhs and crores. Obviously here the operator saves the keypresses of entering zeros.

[10] USER DEFINED BALANCE SHEET:

In spite of rigid standardization of accounting codes and procedures every user including the auditor would like to view the data in their own way.Obviously for this purpose , they prepare balance sheet in their own way using various 3rd party softwares like excel etc. But ultimately they are prepared manually and don't have automatic generation of balance sheet by the software.

Overview : Present system gives full freedom to the user , auditor to design the balance sheet as per their own requirement , once in a lifetime & then use it repeatedly .automatically "N" no. of times. User can have its own conventions also to maintain secrecy of presentation. Design : The designing is so simple and its amendment also ,that normal user with little accounting background can do. Here just 1 wants to write things in the way he wants along with certain accounting information to whether a particular information pertains to Balance Sheet or Profit & Loss A/C or Trading Account or Mfg. Account and its accounting grouping. What has to do is just to map the data with required balance sheet design.

Detailed Design :

User Defined Balance Sheet : In order to prepare B/S which is fully user defined , Firstly a B/S layout or B/S template is to be prepared. In this layout , b/s items are created and are arranged in hierarichal levels . Main columns involved in this layout or format which are customised according to the user needs are described as below

Column Name Description

1. B/S Item Any name which Auditor wants to give to B/S item

2. Msfield It indicates the source of the value to be displayed

against the b/s name.

• Closing - A/C head's closing value is displayed

• Split - A/C head's closing value is splitted into 2 - opening and current. Opening and current values are shown in next 2 rows

• Opening - A/C head's opening value is displayed

• Current - A/C head's current value is displayed

• Title - Values are calculated acc. to its level or may be used to just show title

• Formula - it is used when values are to calculated based on some formula

3. Level Level are Assigned to show hierarchy in b/s items . Root b/s items are assigned level 1 & corresponding total record for alevel = 1 is given alevel = 0 . For a particular A/C pillar , all other levels lie between this above mentioned levels (i.e between 1 and 0) .

Accounting pillars The basic building blocks of accounts i.e Liabilities , Assets .Income , Expenditure , Trading Income , Trading Expenses , Mfg. Income , Mfg. Expenses

Accounting Groups In order to facilitate mapping of account heads with b/s items and to avoid mistakes while doing mapping, Accounting Groups are offered and each b/s item is assigned accounting group, so a/c heads belonging to that a group could only be mapped with that b/s name.

Once a Balance Sheet Format is prepared, it is now ready to be mapped with A/C heads . In mapping left hand side shows list of accounting heads and right hand side shows b/s items based on a/c head's Accounting pillars and Accounting Groups . Once all the a/c heads are mapped , user defined b/s is prepared based on the above mapping.

[11] USER DEFINED REPORTS:

The normal user has to depend upon the basic reports provided by the software. However he is held back of any analytical report that comes up to his mind The present system provides him with the basic structure which will help him to design his w analytical report. For this he just has to give the sequence of information in whch he would like to view the report and the conditions / constaints subject to which he would like to have such report. The generalized logic crosses all the bariers of different functionalities, reports and analysis pertaining to amy data whether of accounts or invertory or HR or anything else.

It can generate all sorts of analytical reports involving combination of various conditions related to date (period range ), amount (min, max range), geographical location(Based on address of suppliers, customers). The generated report can be saved with specific name. In future, it can be called, modified and can be saved with different name for future use. [12] AUTOMATED AUDITING OF ACCOUNTS WITH OPTION TO TAKE CORRECTIVE ACTION :

Audit is the heart of accounting which ensures accuracy of the data subject to accounting standards and laws in existence. We know that auditor report itself says in general that the report is subject to the information given by the client and their sample checking. Because it is humanly impossible to check 100 % data.

However the present system itself sits in the chair of auditor and checks 100% data for certain norms like negative cash at any point of time, improper account grouping, difference in bank and out leger balance, payment of expenses in cash more than 20000, previous years closing balance not equal to current years opening balance, leger balances against the nature of the leger, difference of balances between the branches, etc.

In the interest of the user and to ease out auditor's workload the concept of internal audit is provided. Every entry can be marked as "Audit Ok" to ensure the accuracy and sanctity of the data. This "Audit Ok" marked entry cannot be changed without removing the tag. The concept of leger "Audit Ok" helps a lot in declaring the correctness of the leger during leger scrutiny. There is also provision to note audit problems of particular entries for further clarification by auditor.

[13] CASH PLANNING ACROSS THE EMPIRE:

In a large organization every unit has its own cash balance. However an efficient management would like to analyze surplus cash lying with any other center while its other counterpart unit may be in need of cash. This comprehensive cash leger would show whether the system as a whole is really short of cash or not and accordingly it can make the arrangement for the cash either by internal cash transfer or outside source.

[14] COMPREHENSIVE LEGERS ACROSS THE EMPIRE:

One can get comprehensive details of any ledger at any level which is very useful for analysis the management. [15] HELP THAT IS EXACTLY SIMILAR TO THE SOFTWARE:

The Help file provided to the user operates just like the software and aids the user in case of any difficulty to understand this system.

[16] SAFE DEPOSIT VAULT:

It is the feature which keeps the track of transfer of hands so that management is never dependent on the individual for the possession / location of important assets like important documents , jewelry , treasury box keys etc. The greater advantage with this tracking of assets is absence of dependence on persons.

It can also track the system across the world , sitting anywhere . Management accountability apart from just tracking the assets for its current holder. It also gives the movement of that assets through different hands which helps in safety of the assets .

Design : Safe Deposit Vault concept involves maintenance of 2 master tables . One having details of assets to be tracked and secondly the holder / possessor of the assets . Now whenever there is change of hands of the assets , transferor would enter in the system , name of the assets of the person to whom it would be handed over . Once transferor does this entry , the corresponding recipient , who is also the user of the system , gets the same entry at the same time for confirmation . The beauty of the way in which the recipient confirms the receipt of the assets is by way of entering its system password so that it can never deny the receipt of the assets .

[17] REPLICATE ENTRY

This is one more feature that help the user in passing n number of entries automatically either same entry or other entries with some rule.

[18] CONSOLIDATED BALANCE SHEET:

While doing consolidation of B/S or P/L , two branches or groups may have their different balance sheet formats . Say, for ex. we have 2 groups Groupl 101 and group2 102 , whose consolidation is to be done . These 2 groups would be consolidated in their parent group 103 . Let group's b/s format be 104 , 105 and 106 (may or may not be different from each other) respectively . Now to consolidate them , we map format 106 with 104 and 105 respectively i.e. each b/s items of 104 and 105 are assigned some b/s item from 106 . Having mapped all the b/s names , calculations are done based on above mapping to generate b/s for 103 . In this way , consolidation is possible for any complex system containing any no. of ERP Members and Groups present at any level of Driver Driven Architecture . This is what the beauty of driver driven architecture that any complex organisation could be managed with this architecture having consolidation at each & every level with full user controls.

[19] INTER BRANCH RECONCILIATION:

It is The tool which help auditors to ensure no missing link along the branches. For the software to understand the various branches , it is necessary to map corresponding accounting heads with branch name. Once its various branches are established & mapped with each other, the system ensure for the presence of corresponding entries in the respected branches. For Ex. each branch A has spent for or given to branch B certain amt. , then system will ensure that branch B puts on its record that it has received that particular amt. or that particular amt. has been spent on its own behalf by branch A.

Problems in Existing System :

As the size of organization increases, it becomes virtually impossible for the auditor to reconcile all the branches manually while present system uses the detailed differences between branches and also make path clear to correct them.

Design : Suppose we have 2 branches A 101 and B 102 .In order to reconcile between 2 branches , System must understand which account head 103 in branch A 101 represents branch B 102 & which account head 104 in branch B 102 represents branch A 101. For this understanding , while in branch A 101 , we map entity 103 ( from list of ledgers in 101 ) with branch B 102 ( from list of erp members which are part of system) . Similarly in branch B 102 , we map entity 104 ( from list of ledgers in 102 ) with branch A 101. After mapping is done , System now understands relation in the 2 branches . Now when Auditor runs for the option of inter branch reconciliation , System matches the balances in all such branches whose relation has been established earlier (as stated above) Differences are notified wherever found and Auditor is offered ledgers of the 2 branches (where mismatch is found) to take corrective action .

[20] INTER MEMBER RECONCILIATION:

Apart from reconciliation between the branches of the same working group, the system also provides for reconciliation amongst all the members of the ERP Empire.

[21] HUMAN RESOURCES:

In the present system, HR department itself is a department as well as a function. So we have a HR department which will manage the human resources of the organization as a whole across the empire apart from its own department. This involves analyzing the requirement, its recruitment and allocation. While recruiting, the database specially keeps the note of the expertise of the individual in various areas along with grading. The typical feature of this department is that the selection of right person at the right place within the organization is done by the system itself. During this process, the system considers the existing manpower having required expertise, their present placement in different departments and the possibility of their being transferred to other departments considering the grade, level of expertise. System also maintains the structured organization chart of the departments as well as human beings. The system provides for the management of the human resources not only at one location but across the whole empire. It takes the input of manpower required at different branches across the empire ad fulfills it either by fresh recruitment or by exploring the possibility of internal adjustment considering the potential of the existing staff.

[22] PERIODICALS:

The present system does not ignore the importance of communication with the customers and world at a large through circulants and periodicals which may be a printed magazine or videos. The system comprehensively includes both the ways of dispatch like one involving Government post offices structure and secoundly couriers. Dispach of magazines almost necessarily involves printing of address labels. The system has developed its own logic of printing the address labels which saves upon the paper by taking advantage of differential number of lines in the addresses. The saving of paper can run upto 10 to 20 percent. Label Printing Algorithm: The logic arranges the address information in a way to economise the paper requirent maintaining the clairity and readability. It keeps the track of the number of lines per label and for the given condition arranges the labels while printing in such a way that minimum paper is wasted while cutting the labels due to differential lines per label.

In short, the paper consumption is savedfirstly by economizing the number of lines per label by properly arranging the address informationand secondly printing the labels in such a way that while cutting the labels almost no paper is wasted due to differential lines of addresses. The logic is strictly against the use of fixed size stickers.

The system also provides the logic of printing the labels for post offices which require them to be sorted according to post office zone, state, district and pincode. Ths tremendously saves the workload of post offices in sorting the periodicals manually as per their requirement.

[23] MANUFACTURING:

Apart from routine inventory features, the system also has Manufacturing feature. The system has such a generalized logic that it can cater to many industries with minor changes specific to that industry.

[24] LOGIN SECURITY:

User id and password both are hidden and their input does not give the idea of the number of characers in User id and password. In general for the know user id, cyber criminal tries to break the password. But in the present system he does not get to know even the user id and thus he does not get the starting point to break the login. Things become the worst when he cannot know even the length of both the inputs.

Claims

Claim:

(1) A Driver Driven Architecture for Enterprise Resource Planning System and the solution which comprises:-

Logical Colour Scheme

The Frontier Algorithm

Hibernate

Rights assignment to the extent of minutes and button level rights

Multiplication factor SSmart Entry

User Defined Reports

Help that looks exactly like the software

Comprehensive ledgers across the empire

Safe Deposit Vault

(2) A Driver Driven system as claimed in claim 1 above wherein a Logical Colour scheme is applied throughout system for better understanding of different Finance, and Accounting documents.

(3) A Driver Driven system as claimed in claim 1 & 2 above which further includes a Frontier Algorithm, displays the leger immediately even in case of ledger data.

(4) A Driver Driven system as claimed in claim 1 to 3 above which further includes a function of Hibernate, automatically takes the user to the last Screen Function, when the user had last logged out, on every login.

(5) A Driver Driven system as claimed in claim 1 to 4 above which includes a system of assigning the Rights to the user.at every level of building block, to the extent of accounting legers even for a few minutes.

(6) A Driver Driven system as claimed in claim 1 to 5 above which includes a concept of multiplication factor which multiplies the entire value with that figure. Another concept of smart entry serves the purpose of avoiding entering multiple zeros by a single meaningful character.

(7) A Driver Driven system as claimed in claim 1 to 6 above which includes a powerful generalized logic to generate various customized and analytical reports, with all kinds of matrix.

(8) A Driver Driven system as claimed in claim 1 to 7 above which includes a Help menu which is operable exactly similar to the end user software.

(9) A Driver Driven system as claimed in claim 1 to 8 above which includes a system to generate any kind of comprehensive Ledger documents at any level in an enterprise.

(10) A Driver Driven system as claimed in claim 1 to 9 above which further includes the user ID and Password are hidden during system Login and are not traceable even through Hacking

(11) A Driver Driven system as claimed in claim 1 to 10 above which includes a system of tracking the transfer of hands of the important precious assets amongst the users for the Position / Location, and the access to the subject matter of the complete ERP System.

(12) A Driver Driven Architecture for ERP system and solution which have Functional Unit comprising of the following :

Object entry

Cash Control with Clubbing and de-clubbing of currency denominations

Encrypted Reports

User defined Balance Sheet

Cash Planning across the empire

Replicate Entry

Comprehensive HR

Consolidation of Balance sheet at any level

Inter branch & members reconciliation

(13) An ERP System and Solution along with the architecture as claimed in the respect to the description in the accompanying specification.

(14) A Driver Driven system as claimed in claim 1 to 13 above which further includes computerize sorting of periodicals, to facilitate the Logistics movement of periodical from resource to destination thereby helping is economics of use of stationary.