A concept that combines parents & children, column filtering, aggregation and table joining, allowing the user to freely manipulate and analyze data
Data is stored in Openbravo in a header-line relationship, also known as a parent-child relationship. For example a business partner who has two bank accounts and two locations. This data model consistently separates parent and child records which makes it suitable for 1:n relationships where there are few parent records and many child records. It will be less suitable for 1:1 or 1:n relationships where n is small. The user can only work in one view at a time and needs to switch back and forth between parent and children frequently.
The next generation of Openbravo ERP aims to offer a more flexible master-detail GUI where parent & child grids or forms can be shown in the same view. This allows for much faster record creation, editing, comparing and searching. Besides that, different views can be opened on separate tabs, offering multi-tasking.
Reports in Openbravo - and most other ERPs - are produced as one-off documents. They have a pre-defined set of dimensions, layout and data grouping. This works fine in most of the cases but in some cases more flexibility is desired.
Pre-defined views make it easy for the user to create out-of-the-box reports and to work on standard tasks but they do not allow the user to freely experiment with the data. Now imagine a grid view where:
Parent and child information is combined
Both attribute values and records can be shown
Column values can be aggregated (e.g. sum, count, average)
Complex nested boolean searches across parent and multiple children can be performed on user level by just using column filters
Grids can be joined
The user can experiment with data in a flexible way. Questions such as "Give me the sum of all unpaid invoices of over 1000 Euros of customers in the Czech Republic that have a HSBC bank account" can easily be answered by manipulation of a grid
Most reports can be replaced by this new grid view
The concept that is presented below aims to simplify data by summarizing it, comparable to pivot tables and on the other hand aims to simplify multi-dimensional analytical queries, comparable to on-line analytical processing (OLAP). In the hands of a savvy user, this concept can be a powerful yet easy tool for do-it-yourself business intelligence. For implementation in Openbravo I can imagine that this is an additional view. Not all record types will need it.
I have to admit that I have no idea about potential performance issues. For now I think it is good first to look at whether this idea can make our users more productive, effective and better informed and then assess how to realize it.
We would like to congratulate you for such innovative approach for the grids.
We are very sure that it would prove to be more productive and would help to enhance the performance.
When Openbravo would be integrating this feature in the ERP?
We are extending Openbravo for our client and have the requirements that could be fulfilled by this feature.
So we would be anxiously waiting for this feature to be added soon.
Thanks guys, happy to hear that you like it. At the moment the Family Grid is just an idea, so we don't know yet if and when it will be implemented. We are busy working on a complete GUI overhaul though so please tune in on this UX Lab Forum, blog, or web album to get an idea what´s going on. You can vote for the Family Grid on User Voice.
I am a big fan of combining parent and child data in one screen. Common data entry tasks should be located on one screen where possible. Sales header data (business partner, sales rep, etc) and item data (material, qty, price, etc). The same goes for any document in the system (purchase orders, work requirements, etc) Less is clicks means better user experience.
Your ideas towards presenting reporting data are great. The Family Grid would be a really powerfull tool. Looking at a closer horizon for quick-wins I would go for:
having parent and child together for data entry
develop at least basic reports that appeal to business managers. Standard operational reports could be more focused towards management control of the processes. This leaves for additional explanation, which I am now obliged to give (but for lack of time will not do right now)
I think the quality of Openbravo ERP is mainly judged by ease of use and the functional completeness (is it SCOR compatible? SCOR is used as a supply chain reference model by major industries andsome software vendors). Standard reporting is also part of that. Advanced OLAP features are cool. Just how far should that go since there is also the integration with Pentaho, which offers also great reporting and dashboard opportunties? I am curious how you see Pentaho's role for the future.
Thanks for your comments, they are helpful. Let me react on your suggestions:
Having parent and child together for data entry: Yes, this will have great benefits for grids in some cases, such as goods receipt. It can also be great for form entry but we need to be careful not to break our pure master-detail GUI paradigm where the top part of the page is always the parent of the bottom part of the screen. A simple way of faking a single-entry-form for header and child is having both views defaulted in form view, example here and more detailed version here and here.
Develop at least basic reports that appeal to business managers: Yes, that makes sense. I am awaiting your additional explanation :-)
SCOR compatibility: I have visited the site and asked a couple of my colleagues about their (customers´) experiences with SCOR. Let me quote their answers:
"I have some small experience with SCOR on the business analytics side. Some fairly sophisticated customers used it as a guide in developing their own supply chain metrics, which they then implemented themselves (with services help). I asked customers for several years at our annual conference if they wanted us to develop out-of-the-box SCOR-compliant metrics for various ERPs, but there was spotty interest (and we never invested). I see this as something that would be perceived positively at the upper end of the market, but not our focus."
"I am aware of SCOR, but have never seen any real demand for it within the mid-market (I think I have been asked about it twice in the last 10 years).
I see it as outside Openbravo's target market."
+ I agree that you shouldn't mix parent and child in the same frame. I'm looking at your purchase order design and that's exactly what I'm talking about. So I think we're on the same page.
+ If I re-read my statement on the reports it sounds almost like there aren't any useful reports at all. That's off course not what I mean. Especially on the production side it would be beneficial if there was a report where I can quickly review my MRP status. It would look like an additional layer on the production plan window where I can quickly review the inventory status of materials (columns with days of inventory left, planning warnings, current stock). A planner should be able to drill to one material and review the MRP status of that material only. Currently you would need to run production plan per material te be able to review one material at the time. I should draw this out in some form.
+ You shouldn't look for customer's interest in SCOR. I'm trying'to say that if Openbravo is ever going to invest in functionality again (which I understand is currently not priority) it is good to be inspired by a reference model, to base your application on, that is already there instead of making one up. A customer may not ask for SCOR, but it will ask for functionality that SCOR describes. These are two different things. We are currently working with two prospects and both literally asked to be educated. They will certainly not ask for SCOR, but they implicitely demand SCOR(-like) knowledge and application support.
Is it possible to split and give a priority to filter bar explained in this concept? A filter bar (or row) on top of grids is a nice and handy feature in many 3rd party grids. This can help a lot in filtering list views.
284 projects - 9236 developers
