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 (BOl) [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] Gross_GlobalFile [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 0] 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 -GlobalFiIe 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. 9 [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\DB0D 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. [11] 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 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-GlobalFiIe Table. [2] If Concept = "C" then the Group is a Conceptual one. If Concept = "W" then The Group is a Working one. 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] Level No = ALevel of the ERP Member in the Gross-GIobalFile 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 of 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. [4] Menufile Table: t! MM