Openbravo ERP

A few days ago, we published Openbravo ERP 2.40 alpha. While we are still very focused on stabilizing that release and making it available for production as soon as possible, it is also time to start planning for the next release, 2.50 and we would appreciate any feedback from our Community.

For that purpose, we just published [1] the list of possible release candidates sorted them by priority. Please examine it and give us your opinion:
1) Is the list complete?
2) Are the priorities in the right order?

Here is how to read the list. Each row contains:
1) The priority (rows are sorted by this attribute)
2) Name
3) Description
4) A rough estimation of complexity (from 1 very simple to 5 very complex)
5) The affected area (User experience, global support, etc.)
6) The source (the source is made of entries that came from feature requests, competitive analysis, internal discussions on product strategy, specific requests from community members, etc.)
7) An initial estimation of effort in terms of months (the tolerance here is very high - perhaps +/- 100% - but it gives a starting point for planning)
8) An initial estimation of effort for our engineering team (in some cases, we have community volunteers absorbing some or all the work)
9) A cumulative effort if that project and all the previous ones were to be implemented

Notice that this list includes in excess of 110 projects of various complexity for a total of 264 man months of effort (22 man years!). This is clearly too much work for a single release and our development capacity is probably a fraction of that by one order of magnitude, so we need to choose wisely.

This is an opportunity to influence that choice by commenting on this list and voice your needs by replying to this post.

I would also remind you that you can guarantee that a particular feature is developed sooner rather than later by volunteering and doing the work yourself. We had several such contributions in 2.40 and we hope to have more in 2.50.

Finally, be aware that the priority is not a straight reflection of the importance of the project but it also mediates other consideration such as dependencies (project A is required before project B) and some development best practices (for example: try to tackle the small refactoring and clean up projects as early as possible in order).

Please review this list and reply to this post with your comments. I look forward to your feedback.

Thanks,

Paolo

[1]http://spreadsheets.google.com/pub?key=pPWZAST9Jg5FQBzfEy0kTQw

Hello Paolo,

I vote for prioritizing these items with brief reasons attached:

#60 Data Access Layer: Very core infrastructural feature that needs to be implemented eventually anyways. Better to implement it sooner than later. Not implementing this feature cost the Compiere project big time.

#173 DB2 Support: Second largest database product after Oracle. IBM is a very good partner since they do not have their own ERP product unlike Oracle. They will be a good partner of Openbravo and provide big leads.

#190 Full multi-tenant Support: Currently customizations like field additions propagate to all tenants. This problem has to be overcome so there can be truly tenant-specific customizations that don't affect other tenants. Crucial for SaaS.

#140 Portal Integration: With JSR-286 available, portals and portlets are very powerful tools. Needs to be taken advantage of in order to facilitate user interface-level integration with other applications and enterprise tools.

#1 Modularity: Very core infrastructural feature that needs to be implemented eventually.

#94 Industry Templates: Crucial functionality that is needed to compete with Great Plains and Navision.

Thank you,
Mete Kural
Touchtone Corporation

Hi,

I would prioritize projects in the area of User Experience, for example nº 130, that have a powerful influence in the client usability satisfaction. Users working lots of hours with OB feel much more tired than with other software with a much more simple UI[1]. We can customize some parts of OB but others aren't yet affordable for us.

Then, and using as an argument the last post of Manel Sarasa[2] I would empower the freedom of OB. One of the most important pieces of each ERP is the DBMS, so the projects nº 173 I think are keys to the success of OB, and with the DBSource Manager tool you have a good chance. From this three DataBases I will begin with MySQL not only because it's Opensource but also because behind MySql there is since 26 Feb. Sun Microsystems[3] a big company compromised in Opensource technology building the stack of Internet (hardware, opensolaris, jvm, glassfish, mysql, netbeans...) on Opensource. I think this stack would be useful thinking in a near future about SaaS.

Then, I will prioritize projects related with the integration between OB and other software and one key for this are the webservices, so the nº 61 I think is really important. Furthermore taking into account the OSA.


I hope my poor opinion helps.
In any case, you are doing a great work! Thanks.



[1]This is a common complain of a company where we are implementing OB
[2]http://openingerpsfuture.blogspot.com/2008/06/freedom-is-much-powerful-change-agent.html
[3]http://blogs.sun.com/jonathan/

Hi Openbravo team!

Hey that's not an easy task but at least your are taking it courageously! I hope you'll forgive me to be a bit rude here but I should say I'm not 100% confident in your success yet so I prefer being clear by what I mean when I mean changing things. I'm going to make some comparisons with OpenERP to illustrate were I think the current OB platform is lagging behind. That's not at all to bash OB but rather to make contrasts more obvious; indeed I wish OB success too: having several oss ERP players is better than a monopoly and the proprietary software model should be defeated so every bits helps. Also having the buzzword "Java" in you product might give you a small competitive advantage in some companies for an other couple of years, so that's why I think there is a little chance your last ventures get their money back one day :-)

Overall I'm going to agree with Mete Kural: the current overall OB platform is a bit tough so you would better invest in rebuilding the platform first rather than:
* investing on features prematurely,
* then rebuilding the platform (since you really have too, there is competition here already)
* and then again refactoring the features to use the platform which would cost you nearly has much as starting them from scratch.
So yes, build a more effective platform while you can. Be aware that OpenERP has already half of those listed features you are missing here (Saddly, I'm not joking, want to check?) and from my experience in both projects I would say they are running 5 times faster thanks to a much more productive platform (true business objects with OOP all the way, integrated BPM, amazing modularity, easiness of customization).

Also, if you think you can't afford rebuilding the platform, my best advice is
* option 1) you consider investing in specializing OB to be at least clearly the best in some markets. Let's say retail (thanks to Openbravo Pos?)
* option 2) Bad for open source, but might save you: dismiss from an open source business model and build a Saas model where you could eventually fund your required investments without caring too much about the platform being expensive to develop on or not.
* option 3) take a charter flight far from you business angels ;-)

My open source experience since 2003 might be short, but so far I should say I saw no successful open source project built on raw PL/SQL. Compiere took a niche before Navision, Divalto, Sage X3, Cegid or Business One were ready and Compiere current half and short-lived success is clearly not due to community efforts but rather to a standard proprietary ERP business model. I believe only a very good Object Oriented Programming can abstract the mere implementation of each feature to third party developers so that you can indeed reach a community catalysis point.

So, while there are clearly important missing features, I would just advice like Mete Kural:

1) First of all: #60 Data Access Layer
Hibernate would be good. But would an ActiveRecord JRuby on Rails powered ORM layer just kickass enough? Remember ActiveRecord don't prevent you from calling stored procedures or retriving data by raw SELECT's. On edge cases it's slower than Hibernate but I thing getting a Rails-like productivity is way more important than raw speed (OpenERP has such a Rails-like productivity if you are happy with one of the two presentation layers). And moreover I'm sure you could tweak your datamodel to get much more extra speed than the raw ORM speed.
ActiveRecord is just simpler than Hibernate and co and has the advantage of being scriptable so you would have more agility when hot swapping OB code. Keep in mind that only loading an extension module should ideally be able to hot patch the running datamodel, OpenERP uses it very efficiently already. Groovy + hibernate would make it too but I consider it's slower and make you miss the community of Rails and the power of JRuby. But yeah, anything else than SQLC might be better. PL/SQL might be migrated to take advantage of the ORM progressively. Things that might be customized should come first. Also having the ORM infrastructure would help a lot even if thousand of PL/SQL code remain. Using an ORM would help you targeting other databases.

NB1: if using ActiveRecord, you could consider using this plugin to automatically build your OOP data model after your existing physical table model: http://www.redhillonrails.org/foreign_key_associations.html
NB2: the multithreading issue with ActiveRecord is not an issue if borrowing a different JRuby runtime from a pool (see warbler or the glasfish gem) when entering a threaded servlet. Also consider there is a Google Summer of code sponsored by Sun to overcome that limitation and at the very last you can even consider the DataMapper framework which combine the power of Hibernate with the easiness of AR (still less popular however).


2) Sorry, I couldn't find it in the list: a dynamic templating system for the UI layer
Be it what you want: JSP, JSF, ERB+JRuby but I think you need something dynamic the server will just JIT from one request to an other so you can dramatically speed up developments cycles. Yes you can turn your efforts towards your end customers, but keep in mind that without a developer community you won't make it either. Look at what the investment of SAP, Oracle or M$ are on their ERP products, nothing little like 15M$, so an oss player like OB can only make it if a community starts building and marketing the ERP at its maximum stride. Believe me or not, currently, when you explain an new comer he will have to recompile a part of OB just to put on an other server or port, he is likely to seek for a job elsewhere. And again raw speed is not a valid argument here. The server JVM will optimize the bytecode nearly as if it were static HTML.

3) #1 Modularity
Not everybody needs everything but nearly everybody needs more that what you currently get in the OB monolithic stack. Also consider a modular software is simpler to understand (because of a better encapsulation) so third party developers might contribute more effectively once modularity is there. Ideally you would handle dependencies to allow a multi-layer plugin system but that's only worth it if you get third party contribution for real. Again others have done it already.

3) My third is an easy one but that would lead to a dramatic UI improvement but I can't find it listed: paginated table views.
Currently it seems that if a table has many records it's displayed on a single page. I know it's 'ajaxified' by bits but still navigating is hard I think. We could indeed try to say OB is better on scalability (dream on) because of Oracle, but with such bloated tables, customers will be quick to feel worried.

4) #121 Projects enhancements (only if really improved for services companies, else you might better focus on something easier to achieve)
Currently I could advice Openbravo for the logistic, distribution or manufacturing sectors but certainly not to service oriented companies (again OpenERP is just far ahead here).
Basically the bare minimum would be the ability to assign tasks to employees and employees having obvious dashboard to enter their their tasks status (double input: time and %) So then you can monitor the effectiveness of the project.

5) #34 Integration with Google Calendar (especially if you do 4) )
Strange? Well let me explained. Again OpenERP did an amazing job here with their shared calendar (see on eTiny). But it took them a bit of work. And this was consider they have a way better platform already. So I think OB shouldn't try to compete here. Instead Google Calendar is there already, free of use, with a public API and really user friendly. You would get the most advanced calender feature for almost free by doing this move. Again a big step forward for project management. With GCalendar integrated, you could also drop some 'event management' listed here. Also that one is cool and good for your marketing as it seems so important to you.

6) #143 Tags (if easy)
Easy and efficient. if you had restful URL's you would have them for free using say Del.ico.us. Again, Having a good platform first makes things easy then.

7) #153 Bookmarks
Again: easy and efficient. And again being restful would have helped you doing it in no time.

8) #61 Web Services - Phase I
Yes, you should expose your datamodel, at least in a CRUD way to the world. Also notice that OpenERP (sorry that's the only better ERP I found), they expose controller actions with web services so you can just remote any GUI process like a piece of cake. having it would be a must.

9) Once you get 8), you can finally drive you logic using a BPM engine (#64)
I would finally advice a BPEL engine, possibly Intalio if it's open source enough (I'm still not sure). That would solve all your sale process requirements by the way. Again, I consider OpenERP clearly take advantage of having such an integrated BPM with now a DHTML BPM editor (eTiny trunk). Still, deploying a BPM editor on the client side is tough, but one can consider a webstart heavy client (or an applet, they just fixed the plugin in Java 6U10!) is acceptable considering the added value (DHTML is a must but is hard to achieve).

10) #170 Email Integration
Again, others have it already and it make them nice to use (for CRM, reporting...)

13) #140 Portal integration (optional)
Yeah, OB won't rule the world alone so it better play nice with other third party softwares. Why don't you put OB in a Liferay portal (it's MIT licensed, quite competitive and recently supported by Sun). It features JSR168 and JSR286.
But more importantly, I think you should integrate with javascript portals such as iGoogle (or Liferay again thanks to its Google Gadget portlet). Indeed, daddy's portlet market was a notorious failure because the best tools of the market simply aren't portlets or aren't always coded in Java (find a competitive Java forum or wiki and call me). On the contrary Google Gadget's like portals open a true competitive cross technology and cross server market were the user (not the system administrator) takes the control.
Just in case you were not aware, let me better illustrate: http://fr.youtube.com/watch?v=8EsFJu6p3P4
Such portals are already free of use (like iGoogle) or even open source such as Liferay or Apache Shindig.
NB: by doing this move, you would also get a DHTML chat client for free using the Mibbit gadget or even GTalk.

11) #82 Rules Engine (optional)
Well, beware of bloatware. A simple rule engine is nice (for instance to build a price engine, a product configurator, a CRM front dispatcher...) but it would also be quite easy to build something to heavy to be actually used by an open source community. The price list system would better take advantage of the rule engine if any.

12) #73 Master details UI pattern (optional)
would give more freedom to the presentation layer

14) Then think to refactoring/developing new features among the listed ones.

So yes, I've been rude and it's not easy work. But I should say I see no other way. Also beware of doing too many real deployments before doing the hard job because you could then waste too much money to get a correct fame from those early deployments and then get trapped with the that last decade technology forever (or probably not even forever). Without OpenERP, there would be only Ofbiz, JFire and other immature or poorly supported projects so things would have been very different. But like it or not, in the Darwinian open source world, there is hardly room for a second place.

15) Port OpenERP over Jython on the Java platform and apply OB css theme. Sun just hired the two Jython dev lead to do what they did with JRuby over the last 2 years (Nutter, Enebo, Bini, Norbye and co). The code is GPL'ed so you are technically allowed to do it. Well OK, 15) is a joke ;-)

Good luck, your are indeed targeting at a great achievement for a better business world, I hope you success. You can count on me when I'll think the dev effort I put on the platform won't be wasted, that's what I usually like in open source projects.

Raphaël Valyi.

OK, so by the way here is my own comparison between Openbravo and OpenERP among your planned features.
It might not be 100% accurate but illustrate better and more concretely the points were OB is currently lagging behind:
http://docs.google.com/View?docID=ajb639cjf9fb_133hsb6vbtn&revision=_latest

BTW, just like you mentioned, green colored items are indeed often overlapping items you already identified as being better implemented in OpenERP. I found a few other ones too, may be because I tend to know their product better by now.

Still, on the other hand, OB has also a few advantages, namely:
* better current reports (but beware of the coming OpenObjects BI intergrated solution coming in the pipe from OpenERP)
* probably better multi-companies support while it's hard to be 100% sure given the complexity of OB pl/SQL code
* much better POS support through OpenbravoPOS once synchronization is fixed
* funding
* possibly better scalability thanks to Oracle but again, hard to be 100% sure and OpenERP improved a lot in raw speed too recently, they handle up to 1000 concurrent sessions on their cheap demo servers without any noticeable leak, so that might just be fast enough.
* "Java" buzzword (while PL/SQL) might be more correct
* much better marketing team
* support looks more professional

So again, good luck for the courageous piece of work you are undertaking, it's certainly not easy to start the run behind but at least you convinced your angels you will make it, that's a very great tactical move from you, may you achieve the added value that risky move deserves.

Raphaël Valyi.

Paolo,

Having read through the list, the current order looks sensible to me, but I would be interested to know how far down the current list 2.50 will get using current engineering resources. Then we could concentrate on the first part of the list to bring some items forward to ensure they get into 2.50 .

Some comments:

* There seems to be a disproportionate interest in SaaS. While SaaS is certainly of interest to a company who wish to provide such a service and should be prepared to develop that functionality for themselves, I do not think that the general open source user is particularly bothered, since they will only be interested in providing a service for their own company. What is of more interest is the ability for a group of companies (organisations) to share a single database server and each company (organisation) having their own application server with access to the database. Thus Openbravo would then be useful for multi-national companies. There is also a finite limit as to how many clients a single server can support. It would make far more sense to give each customer a virtual image on the server and let Openbravo concentrate on a single "Client"/company design. The use of multiple "Clients" being more useful for testing and production. Therefore I would support #14 Multi-organisation support.

*#55-Operate Openbravo from UI is another item of interest only to service providers, who should be prepared to develop that functionality since they are going to make money from it. So that would be a NO, from me anyway. Openbravo is aimed at the SME market rather than suppliers to the SME market, is it not?

* Data access layer is important to provide database independence and provided it is well documented the implementers can develop the interface to their favourite database. Thus item 173 is achieved by the community with Oracle and Postgres implementations as examples.

* I, and I hope others, would like to see an improvement in documentation. And with this in mind I would like to suggest than as a general policy, documentation is written ahead of the engineering work. This has several effects:
1. Ordinary users get a much better understanding of what engineering are trying to achieve.
2. Ordinary users get to suggest better ways of doing the functionality because it is at a level they can understand.
3. Engineering get a much clearer picture of what is actually required.
4. New functionality does not appear without documentation.

* There is also a risk of developing too much new functionality before the current functionality is completed. We have an expression "Don't run before you can walk" which I find myself using more frequently. That is not to say that Openbravo is poor, quite the opposite. However there are quite a few basic items that are missing that I would have assumed would be present by default, if the developer had had his business hat on when coding the project.
To give an example, The standard prints for Sales Order, Purchase Order, Invoice etc. do not, out-of-the-box, get the organisation details (address,telephone,fax,VAT number,company number) and put them at the head of the printed page. This means that every single implementer of Openbravo has to do this work (after they have managed to find out how to do it).

*(which reminds me) Openbravo should enable a logo for each organisation, which would be selected automatically at print time relative to the current user's organisation, and displayed as the logo on the UI, which helps the user note which organisation they are currently working under. So if the user switches organisation to do some different work the logo on the UI will change. Granted this doesn't apply to all users, but I would think that the accountant might move around between organisations.

*Warehouse Picking #58 is very important because without it the warehouse functionality is incomplete. How on earth is the warehouse staff supposed to know what to get out of the warehouse to get it delivered to the customer or manufacturing? If an organisation does not need warehouse picking, they probably do not need Openbravo because a standard accounts package would probably do what they need. Therefore this item is very important.

* EDI support you may find has been done already.

* Integration to Google Calendar, email etc. are nice-to-haves, but hardly essential to the main framework. If implemented, it would be sensible to provide a generalised calendar, email interface so that implementers could use their chosen calender/email rather than be forced to use Google (wonderful though it is). This really is an add-on to modularity in that you make it easier for the community to provide add-ons.

*#120 Automatic Bank account transaction download and reconciliation would be very useful though I would imagine you will only get as far as providing a generalised interface with one example, since each bank will have differing formats and procedures. It is more important to get bank reconciliation from the paper statement working first.

Finally I would be very interested in contributing to the User Interface Redesign #180 to which my comments on documentation ahead of development are very pertinent.

Hope this helps. I will try to join in the chat meeting tomorrow.

Kind regards,

Andrew.

SaaS support should not be later patched on by companies who want to provide Openbravo as a service. Such examples often end up in technical failure. Support for SaaS needs to be built into Openbravo from the grounds up to make SaaS truly feasible.

Hi,

My point about SaaS was not a technical one, but a user demand issue. If a company is interested in providing an Openbravo SaaS they could always fund the development by Openbravo.

As I understood the original request we are discussing what the Openbravo team will develop for the next version (2.50) for the community, which I deem to be the end users.

More fundamentally, what needs to change in Openbravo that could not be achieved using virtual servers?

And in such an environment, would you really want business users tweaking the database. I would have thought that it would make more sense,in providing a SaaS, to only give the users access to the Openbravo interface and offer a service of customisation on top of that. So I do not see a need to provide SaaS specific functionality within Openbravo as a priority when there are so many other things that need doing.

Hope this help clarify my position.

Kind regards,

Andrew.

This is my priority list (starting with the most important) partially based on experience of giving functional and technical trainings of Openbravo

73 Master details UI pattern
1 Modularity
130 Selector auto-complete
70 Selector UI pattern in Applications Dictionary
64 Business Process Manager (Workflow Engine)
82 Rules Engine
83 Rule-driven accounting engine
15 Sales Dashboard
18 Complete Localization Pack for US
93 Advanced Localization Pack for US
20 Accounting for manufacturing transactions
40 E-Commerce Integration
145 Improved cost management
61 Web Services - Phase I
125 Search engine integration
165 Button Auto-save
152 Favorites menu

Rok

Raphael,
can you please elaborate further on your third priority (paginated table views)?
If by that you mean fetching only the record currently displayed in the list (plus a few more) and fetch others as you navigate, we have implemented that in 2.40. Can you please check 2.40 alpha r3?
Thanks,
Paolo

Andrew,

what do you mean by: "* EDI support you may find has been done already".

Are you aware of a community contribution that we could add to the core?

Thanks,

Paolo

Hi pjuvara,

about the "paginated table views", I mean:

Yes, I'm aware of the partial data retrieval (by bits) system you implemented on 2.40 I find it a great step forward for sure (not having it would have been tough). I was indeed tracking the SVN daily commits untill recently.

Still I could be wrong but I don't think this is enough ergonomic either (and our accountant tends to agree). Indeed: even if the database load is OK and the response time is correct thanks to the partial data loading, one would expect that the table lines would be paginated much like a Google search result for instance so one can easily navigate from page to page with an obvious visual feedback about the current, previous and next result page. Having say 30 000 invoices in the same page and scrolling among them seems tough indeed, unless we missed something.

also by the way, off topic but important for Openbravo: it seems that Openbravo has been making enough noise recently, so Compiere decided to release their documentation for free, and it's actually quite good, see their new wiki: http://wiki.compiere.com/display/docs/Material+Management
I think in some ways they are recognizing a serious Openbravo threat, so they are starting to react. We think that Openbravo is still offering much more for less than Compiere but it's always better to keep an eye on the competition. In any case, I think this proves Openbravo is starting to change the rules.

Good luck with the development.

Raphaël Valyi.

I would like to thank everybody for their responses either in this forum or in the IRC chat. This has been very helpful.

Based on the input received, I revised and re-prioritized the list of candidate features and a new version of the spreadsheet is available at the same URL[1].

You will see that I have added some color coding to the first column to separate the features in batches:
1) The first shade of green indicates features that we consider "release must-have's". Their completion define the success or failure of the release.
2) The second shade of green groups clean up projects in the Openbravo platform. Because of their nature, these projects should not require any functional design.
3) The third shade groups clean up projects in the Openbravo functionality. These projects should not require a lot of functional design.
4) The bright green group indicates fairly large projects that require a fair amount of functional description
5) The yellow group indicates "stretch goals" for the release: features that we will attempt to deliver but that we believe are at high risk.

All the other entries in the list are out of scope for 2.50.

You will notice that all entries scheduled for 2.50 now have a feature request that points to Mantis. With that, we are been able to leverage the Roadmap feature of the issue tracker and you will see the same list there[2].

We are now entering the execution phase of the release and you will be able to track our progress in a status page on the wiki[3], similar to the one we used for 2.40[4].

Thanks again.

Paolo
[1]http://spreadsheets.google.com/pub?key=pPWZAST9Jg5FQBzfEy0kTQw
[2]https://issues.openbravo.com/roadmap_page.php
[3]http://wiki.openbravo.com/wiki/2.50_Release_Status
[4]http://wiki.openbravo.com/wiki/2.40_Release_Status

Hello Paolo,

Thank you for the updated spreadsheet. The new priority seems to be sensible. One thing that I would like to re-emphasize is that although #70 Data Access Layer is one of the yellow items and you said that you will attempt to deliver the yellow items in release 2.50, I would recommend you to really make a good attempt at it for release 2.50. I think the sooner that database independence can be delivered, the better.

Also, I notice that a lot of what was supposed to be done for Openbravo Green is now in the list of items in this spreadsheet. I get the impression that Openbravo is changing the strategy for Openbravo Green. Rather than a revolution - a big bang 3.0 Openbravo Green release - an evolution seems to be the new approach. Am I correct?

Thank you,
Mete Kural
Touchtone Corporation

Some remarks:

That new roadmap sounds reasonable to me, I wouldn't do different if working on Openbravo. Community consultation is a smart move. Compiere is thinking again about more transparency, but not that much, no question here.

Mete,
About the database independance and the 'Green' revolution or revolution:
this is my own opinion, but I don't consider "database independence" is doable for real in the short run. I mean it would be too expensive, they would have to recode their 500 000 pl/SQL lines or spend a lot of time ensuring an other database can run it too. Look at how expensive (how many bugs in the past) it has been to allow PostgreSQL. I think PostgreSQL is enough to support as the free option.

The current added value of Openbravo is those half a million pl/SQL lines of code (mostly from Compiere, but not only) and the concept itself of a free and well supported ERP marketed as a Java technology that attracted investors. If you question those Oracle lines of code that lurk behind the XML files, you question Openbravo itself I think. Mete, also look at OpenERP: they only allow PostgreSQL but they already abstracted the persistence layer and the result is that they are growing very fast now. So I think if Openbravo can achieve such a valuable platform by 2.50, then it's OK and they'll start receiving lots of third party contributions. That's not a big deal if DB2 or MySQL can't run Openbravo yet. Other investors (or thirs party coders) could fund this later on when the project is successful.

As I said, I'm not sure this will work considering the OpenERP competition, but at least I think that is any case the best option is indeed to fix the existing SQL codebase, make it good enough so one can use it blindly, just like say a Linux box, and also provide that new database access layer one can then build on as the new foundation for the future features. I think the Linux kernel is a good example to follow: it's not always well written, it's barely understandable, but as soon as they made it work really well lots of people started using it without needing to understand what happens under the cover. Kernel contributions are only a very tiny fraction of the users mass, still bug reports are more common and they help the core developers for sure. I think if Openbravo can achieve that with the existing codebase, they will succeed.

Granted those 500 000 pl/SQL lines of code won't start using that new platform miraculously, but at least the community might then benefit of an open source viable platform to start build something cleaner and more complete, once you have both the modularity and a persistence layer abstraction people can start focusing on functional code and functional modules can be contributed from all over the world, just like it's now happening with OpenERP modules for instance.

Overall, I think we will seriously look at Openbravo again around October for 2.50. I didn't realize how much work Openbravo would throw in that soon. By the way, I've been happy to see that in developing countries like Brazil were no mid market proprietary ERP fits, Openbravo is already clearly competitive and lots of integrators like Vipware are preferring it over Compiere. I just wish the same happens in France and other western countries too but it looks like it's harder considering the mature and reasonably cheap mid market proprietary offer here. So I think we should wait a bit that new 2.50 platform and clean up make the integration costs drop so it's more doable here. May be it's the same situation in the US and US localization should then not be considered a top priority over platform refactoring, but I'm not sure about that. Some US firms might also be more gutsy when investing, so you know that better than me.

Kind regards,

Raphaël Valyi.

Hi Community,

Grids are the fastest way to work with registers. Some ideas to improve grids:

1.- Ability to launch process from grid.
It would be useful a little and beautiful icon, similar to an arrow in a combo box, on the left side of each row. When you push on it, a list with process appear. This will be the same process we can launch from the edit window.
When we design an automatic window, the option "appear in the grid" for a process really mean 'appear in the combo box of each row in the grid'.
I'm not talking about an ugly combo box. It would be more like the little arrow that appear when we push on the header row to order the grid.

2.-Filters on the grid.
It would be useful too, to put a text box at the end of each column. This box will be an automatic filter: while you write, filtered registers appear on the grid.
In fields validated by a list, would be better a combo box with the options list, instead a text box.

3.-Quick insert on a grid window.
Furthermore editable grid, 'it would be useful' a little edit window at the bottom of the grid window to quick add a register.
In this edit window only principal fields appear, not all fields like in the edit window.


I hope this ideas 'will be useful' ;)

Hi community!

"Field sequence" tab improvements:
--------------------------

In Windows, Tabs, and Fields->Tab->Field Sequence it would be useful that mandatory fields appear in different colour. For example, red colour for mandatory fields and yellow colour for mandatory fields with a default value.

It will avoid the classical error "Field xx not found" when we have designed an automatic edit window without all the mandatory fields.


Thanks.

Improving grids (continuation):

4.-Now, the position of a record in a grid is controlled by "line number" field. I think it would be better 2 vertical arrows, similar to the arrows in the 'Windows,Tabs, and Fields'->Tab->'Field Sequence' tab.
With this arrows we could control the position of the selected register.

Automatic windows design improvements:
------------------------------------

It would be useful to have the possibility of add fields from different tables to an automatic window.
When we add a field, we can choose the table too.
All the fields from the tables choosed appear in the 'Windows,Tabs, and Fields'->Tab->'Field Sequence' tab with a different colour for mandatory fields (see post "By: azuledu (azuledu) - 2008-06-29 12:29").


Thanks!

Hi!

I think that a system like UserVoice (http://uservoice.com) or Digg (http://digg.com) would be better to add and vote for new functionalities.

Its just an idea..

Thanks!

Hello Raphael,

I mostly agree, however we should also remember from history that not delivering database independence cost Compiere greatly - we were a Compiere partner during those times and are very familiar with the events and the outcomes - and I would like Openbravo to avoid that mistake. This is a serious judgment I make to a greater extent from past experience rather than intuition. So despite your points, I still root for database independence as soon as possible.

Thanks,
Mete
p.s. Compiere eventually rewrote all the PL/SQL into Java procedures that are supposedly portable among different databases - but never quiet delivered on the database independence fully - so if Compiere could re-write all the PL/SQL, I think Openbravo can, too.

What about using the mature, well documented and well battle-proved iBatis for the gradual mapping and modularisation of the DB access?

http://ibatis.apache.org/

I forgot to mention that iBatis allows a gradual modularisation while reusing the existing PL/SQL.

Hi Paolo,
Although I am too late for 2.50, I would first like to congratulate Openbravo for inviting the community to participate in release prioritization.
Since 2.50 is closed, I would like to point out just one feature request that was not discussed earlier - web-services. I believe that exposing Openbravo's objects (business partners,products,orders etc.) through a soap interface is very important. Openbravo will always have to be integrated with other information systems and web-services are the way to go.
I think initially 'READ only' web-services should be developed. This should be fairly easy to implement and can provide a great value for Openbravo-EverythingElse integration.
Reagrds,
Yossi BH,
Open source ERP Guru
http://opensourceerpguru.com/

Another comment: Reading the list of priorities I´ve seen the request of adding a rules engine for custom business behavior. In my experience it is more efficient and far more easy way of implementing this requisite via using an embedded language for custom business behavior. Possible embedded languages could be Groovy or javascript.

Groovy is my recommended option and easier for Openbravo since it is Java-frienly ;).

Adding a rules engine is a complex task and, in the end, the result is not as versatile and powerful as adding an embedded scripting language.