The Family Grid

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 an 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.

This movie presents the idea.

Let me hear your thoughts on the UX Lab forum.

Bank Statement Reconciliation Redesign

Bank statement to bank reconciliation is the process for entering and reconciling bank statements with cash transactions from accounts payable and accounts receivable and cash balances in the general ledger. This sounds like a terrible thing to do on a daily basis but it doesn't have to be. We had a look at how to improve this functionality in Openbravo and came up with the following ideas:

• Introducing an additional layer on top of grid and form views that shows an overview of the bank account, its items that need to be reconciled, some balances and shortcuts


• Possibility to import a bank statement


• Automatic matching of bank statement lines with Openbravo transactions. We need to figure out the exact logic here still but value, reference or keywords in the description could be used for automatic match finding. The user then only needs to verify whether the proposed match makes sense, and tick the box.


• Searching for matches among transactions and invoices. Making a match with an invoice and reconciling means that this invoice will change to status paid.


• Creating new transactions on the fly when they don't exist yet


• In case of partial payments we want to be able to match a bank statement line with a part of an invoice. This results in the invoice being paid partially. I call this splitting of the invoice but perhaps this term is not ideal as the invoice remains as a whole but there are just payments made against it.

Have a look at the mockup images and do give your feedback. Thanks!