Make Initial Install Work Out of the Box By Filling In Defaults

[bcinteractive]

I'm loitering around fresh install and I notice that after installation, there's a lot of initial setting that need to be done before actual use of the application. I would like to suggest that defaults are included so upon first install the app can be use (like entering transactions)

1. Default tax groups, tax authorities... usually blank and some aspect of the application won't work.
2. Default users for A/R and A/P and Accountant -- at least, I think there's a lot of prerequisite before one can add a user
3. Different default inventory items

I have to stop at 2 as that's where I get the idea of 'out of the box' . I just encountered a crash when adding a user but without complete info - like location...

[timschofield]

This is something I have thought about a lot over the years, but it is very hard to define any defaults. For instance, the tax setup varies hugely by location. It looks completely different in Europe to the USA for example. Same with inventory categories and items. It would look entirely different in a hospital to the inventory system in a wholesale distributor, or in a manufacturing company.

The best idea I had was to have a list of scripts which have to be completed on first logging in after install, and you wouldn't be able to move on until all those scripts had been visited.

Might be an idea to use this thread to try and define such a list.

Thanks
Tim

[timschofield]

I like the idea of a checklist script, though we need to be careful what goes in there. In my opinion, only those things that are on it should be those things that are neede by all organisations, to get a working system.

There is a user already created by the install. This is called 'admin' by default, but the name can be changed in the installer. This user should then be used to create any other users the organisation requires.

Thanks
Tim

[bcinteractive]

Agree on all points. :)

While going through list, I hit a snag for creating users. I'll send the error message later after I recreate the issue.

I like the idea of creating general user templates

• super accountant -> can do all the responsibilities below
• accountant -> can do GL responsibilities
• sales -> can do A/R responsibilities
• purchaser -> can do A/P responsibilities
• inventory in charge -> can do inventory responsibilities

Thanks
Ben

[dalers]

For me, I also need an engineering role - able to create or edit an Item (INCLUDING providing purchasing information) and also create or edit a BOM, but NOT able to perform operational tasks such as creating a purchase order, receiving or issuing stock, etc.. I do not believe this is possible with the curent set of Security Roles and current Security Token Assignment.

[timschofield]

Hi Ben and Dale,

Personally I would only include the System Administrator role by default. In my experience no two organisations have exactly the same roles. It is up to the organisation to tell webERP what roles they want, rather than webERP trying to enforce preset roles on the organisation.
I think we have an excellent security system that is incredibly flexible. Every organisation can create a fine tuned setup that accurately reflects the way their organisation works.
In the end we write the software, we don't do the implementation. I would always recommend having an implementation expert help with the setup.

Just my opinion,
Tim

[bcinteractive]

Hi Tim,

The default user(s) is/are meant to be a template/guide. webERP already has a comprehensive system in place when it comes to access control. From this generally accepted defaults, the system admin can clone and or modify as required by the users. the default user(s) may be considered as demo data, but at the same time, they are a great way to speed up setting up webERP for use. They can always be deleted or set to inactive.

Not got say this is a top priority but it does help. I will return to this feature when it really does have some traction with the community.

@dalers You have something specific going, good for you. Hope you can get around the access control you need.

As always, thanks for the consideration,

Ben

[dalers]

@timschofield with all respect, I would strongly suggest NOT to create "a list of scripts which have to be completed on first logging in after install, and you wouldn't be able to move on..." and I would argue this would violate WebERP's stated principles of (Imho) of "simplicity over all except when required for performance".

Imho the initial config workflow should include a set of reasonable defaults and a simple "just click next" to result in a working system when you don't know the answer to all the questions yet. Tryton.org seem to have managed a "basic universal chart of accounts" and have kept manual configuration to a minimum (although can be just as cryptic as WebERP so far as non-obvious data dependencies... ;-)

I would also suggest the new database update system in which updates cannot be run individually from a command line for debugging or other special purposes falls into the same category.

rant off ;-)

[bcinteractive]

Hi @dalers, I had this idea because I just did a fresh install with no demo option and I have to look all over the app just because I was not able make it work.

I gathered from Tim's point of view that he needed to interview the users first in order to set up webERP before it can be used. Having the script will take the place of Tim's interview of a sort. Initial decisions and settings created and decided - some can be amended later or informed users that such option is final if there is any.

I think having the script will help using webERP quicker.

[timschofield]

Hi Dale, there are some things for which "reasonable defaults" don't exist. The most obvious being tax. I could set up defaults for the UK, but in Canada you would have to delete out all the defaults in order to create different ones. In the US they would have to delete and put in more different ones.

CoA is another one. For instance, in the Francophone world the governments (most anyway) proscribe a CoA that all businesses must use. In the Anglo Saxon world, however we have free form charts where companies can do their own thing. The govt doesn't even proscribe whether you use numbers or letters, or a mixture. So again there are no "reasonable defaults".

The database upgrade system isn't available via the menus, all you can do is force a rerun by changing the value of DBUpdateNumber in the config table.

Rants (polite ones anyway) are always welcome :)

Tim

[dalers]

Hi @tim, glad to hear from you .

The most obvious being tax. I could set up defaults for the UK, but

Imho, the goal should not be an accounting system that can only be used after complex and time consuming configuration fopr a specific jurisdiction (complex and time consuming that is for a lay person unfamilar with WebERP). Instead, for the greatest applicability and use, the goal should be the simplest system that results in correct operation, regardless of the jurisdiction.

My typical role is engineering design documentation and design change management, and typically work with a founder who is already using QuickBooks and has no plans to change. I however need to manage off-the-shelf and custom parts, bills of material (essentially a custom parent part), supply chain documentation (Vendor and Vendor PNs) and building protoptypes. The solution is essentially a hybrid system, using WebERP for operations and continuing to use QuickBooks for financials. For me personally, the work to setup accounts and taxes is unecessary for what is primarily engineering design work. I do accept though that some minimum financial configuration is required so that I can buy and manage stock, issue parts on hand to a prototype build, report on the quantity and value of stock on hand, etc.

A side benefit of a simpler core system is simpler testing and simpler troubleshooting.....

all you can do is force a rerun by changing the value of DBUpdateNumber in the config table.

I know, but this (imho) makes the system more complicated....

Cheers,
Dale

[bcinteractive]

Thank you for putting some time to consider this. I just notice that some feature are considered a 'hard fact' but for me is not really that obvious.

• Consider creating a user, from scratch --> you cannot move on until you specify a location. But there is no default location - and so cannot move on.
• Also, authority to use accounts, cash accounts. While I have a vague idea that this is a control feature, it doesn't feel 'general'. That said even the initial admin account is 'powerless' to create a first transaction.
• I was thinking the defaults should just be called <Default + description> with initial value of 0 if a value is required. When reporting, everything can be traced to defaults that can be modified as needed.

Put another way, what are the steps needed to create a first counter sale, invoice, purchase or any kind of transaction.

[timschofield]

This is a big subject. Successfully implementing an ERP system is not a trivial exercise. I have spent much of my career doing this. The first thing I do at the start of any implementation is to sit the relevant staff down, and go through all the parameters that are needed in the setup, deciding what the optimum values are for that organisation. This can often take several days of discussion, and even then changes happen further down the line of the implementation.

If we put default values in, these values would have to be changed during the implementation anyway. Failure to change could cause major issues for the organisation. For instance no default tax setup will be correct, and using the wrong tax setup would be damaging.

That is why I was suggesting webERP held the hand of the user through setting up the system with my list of scripts, which I don't feel I described very well.

@dalers the ethos behind webERP that you are referring to has always been that the code used in the scripts should be easily understood, and easily altered. This is not the same as webERP being simple to use. The more functionality that we have added over the years, then the more complex the system has become. WebERP is not just a bookkeeping application like Quick Books, it is way more complex than that, and all the pieces affect each other, so careful thought needs to go into the implementing of it.

Thanks
Tim

[pakricard]

I think “easy setup” and “ERP” do not match.

ERP are difficult to set up by definition, as ERP is designed to manage all bits and pieces of an organization. There are thousands of different types of organizations, needing different things, with different jurisdictions, different skilled work force, etc. Hundreds of settings must be synchronized to declare “success”. My perfect setup will be different from yours, and each one of the ERP installations will be different.

Trying to simplify all these variables into a universal “easy N screens setup” I think is not achievable without a massive effort.

I have been using webERP for 16 years now, and there are still parts of it that need reconfiguration occasionally, or I discover the side effects of modifying a random setting. webERP is becoming more complete, with more functionalities, so more complex.

Moreover, we should keep in mind we are a tiny team, so we must focus our effort towards the best outcome. We can't do everything, everywhere like SAP, Odoo, Tryton, etc due to our size.

I think, the main goals we should focus on now are consistency and documentation. Consistency in coding, in results, in appearance, etc. Probably, devoting a fraction of the effort needed to create this universal easy setup, into proper and detailed documentation on how to set up webERP will be of better use.

My 2 cents ;-)
R