LS
I have been working as business analyst implementing ERP solution for many years (e.g. BPCS or SAP/R3). Since recently I have got in some freelance work and some of my clients are some (very)Small companies. Before open source an ERP at such level was the unthinkable step. I have studied some ERP on SourceForge but webERP appeald to me for its simplicity (making it a perfect, out of the box soutions).
I'll keep this page to share with you all my experience and contribute (as much as possible to the knoweldge of the group).

Getting the business model right

First task on any ERP implementation is understanding the business model. The way a company leads its business is uniques. Even small companies in the same area of activity opperate in a certain way (depending on the imagination and inspiration of its owners). So the business model is someting it has to be understood and it will be implementation goal.

WebErp flexible menu's and options


LS
I have implemented WebErp for some of my clients. The functionality (as provided by the standard package) was good enough to get them started without any modification or custom build functionality.

It has been requested by all of my clients to implement a flexible organisation of the workspace. Namely to be able to define the menu groups and their options. Also it has been requested to give every users a more or less customised view all the system: to group the function they need and hide the ones they don't need. This can be partially achieved by setting the authorisation correctly. However not enough. Optionally I can customize the script for every customer but not for every user (which means one webErp for each = impossible to manage cost effectively).

Change overview:

Instead of hardcoding the menu groups and options in the index.php make them database dependent as following:
A Database chagnes
1. New table for menu codes and descriptions (menu): menu_code, menu_description
2. New table for all menu option used at the moment (function): function_code, function_description, function_section (e.g. AP, AR, system etc)
3. New table for menu options (moptions): moption_menu (from menu file), mopion_section (see point 6), moption_function (from functions), moption_index (the order in the section) moption_description (from function_description, but it can be overriden)
4. Extend www_users by adding a flag (use custom menu's Y/N)
5. New table for user authorised menu's (usermenu): usermeu_user (from www_user) usermenu_code (from menus)
6. New table for section (section): section_code, section_description (e.g. Transactions, Inquiries, Maintenance. (eventually section_icon)

B. Functionality changes

Under the System menu group, Maintenance section add 2 new functions:
1) Function registration (to update function)
2) Menu maintenance (to update menu)
3) In the user maintenance add new flag "Custom menus flag "Y/N". If set to Y display additionally a button for "User authorisation to menus'


Index.php (WebErp main entry).
During the user log on retrieve the Custom_menus flag. If it is set to value N the script will continue as it is now. If not then:
a) Retrieve all menus user is authorised to from usermenu.
b) for every record found:
b.1) create a menu group with the description from menu
b.1) Retrieve all transaction from moptions for given menu code in the order of the moption_section, moption_order. For every distinct moption_section found build the required section with the given option.

I need to do this anyway. Whem I'm done I'll submit the code to you all. However until then maybe is somebody in different stages of implementing something similar maybe we can combine the efforts?


<Phil>
Just a thought.....

Maybe we could leverage off the role defintions data and present only the menu options applicable to the user's role. There is already facility to change user roles - define new roles and have different each user with different access to scripts. Its miserable to show a user an option then present them with a rude message saying how unimportant they are if their role does not allow them in. Would be way better not to present the option at all.

We would need a function with the parameter being the script file name - if the script has a $PageSecurity in the role array of allowed $PageSecurity tokens then show the link otherwise not....

It would be particularly beautiful to get the PageSecurity from each script by parsing the first few lines of the script. The other alternative is to maintain a separate table of scripts and PageSecurity values. This would need to be maintained separately and agree to the hard coded script $PageSecurity value which is tested at user access time.

Me thinks this would be relatively simple and easy to implement - compared to the solution proposed above.

(Aside: Having a separate table of script and security settings could have additional benefit since it would then allow more fine grained user interface setting of security with an additional script to allow defining each scripts $PageSecurity - there would also need modification to every script to use a function to get the PageSecurity first - too much work!! Also I am a bit unsure that having the page secuirty set in the script maybe required before the database connections are made - I just can't recall.)

Another thought ....

You could define some different languages - make up a directory under locale with a language code en_JO and set the user to this other language. The menu string for each entry can be changed at will for the messages.po of en_JO and this user will display different text for these menu options - a hack !

</Phil>
Thanks for your thoughts and direction.

First of all I don't intend to change the current security scheme. The role definitions and related functionality is done in the assumption that WebERP will display always its standard menus (or part of them, based on user definition). In order to make a selection within those standard menus of accessible function to a certain user, the Page security is used is relation with the role.

My approach is to define a strategy not based on roles, but based on what functions the user needs (related with his/her user current job). For example the users entering orders need order functions, but occasionally they need to enter new customers (which is part of the A/R module), or maintain some items (which is part of the System) etc. By defining a customised user menu, I dont need to check the security anymore as the users have been given permision to access some specific functions. What they cannot see they cannot access (unless they type the name of the script in browser bar - this can be solved by calling the browser with some parameters).

To conclude, standard menus will require security check which the current scheme provides excellently. User defined menus, requires no security as the access to a certain function has been requested, explicitely or implicitely by the nature of their role with in the company.

Point taken, about the usage of the "locale" functions. Definitively a must.
Valid XHTML :: Valid CSS: :: Powered by WikkaWiki