Shipping & Invoicing in 3.0

The Openbravo flows are coming your way!

In the Enhanced Sales Order project, that we aim to ship in 3.0 Core, it is all about redesigning the existing flows for ordering, invoicing and shipping. In an earlier post I have shared the adventures of Jim, the Computer Seller & Liz, the Order Taker with you and in the meanwhile I have also published scenarios for a sales director (Dan) and a customer carer (Amy). If you haven´t read their adventures and given your feedback yet, then please still do so. You will have to work with it in the end so you better speak up now or forever hold your peace :-)

The latest scenarios look at invoicing and shipping. Using the new 3.0 GUI framework, I have tried to model flows that are as flexible as possible. So you can first take a a sales order and then create an invoice against it, or maybe just for a few lines which means partial invoicing. Or you take a whole lot of orders and generate invoices for all of those at once, perhaps merging invoices for the same customer. Sometimes you want to invoice products, rather than entire sales orders because maybe you were only able to ship one product at a certain point in time. You then would want to create partial invoices for a whole lot of sales orders that contain that specific product. The same goes for shipments. Sometimes you first want to create a shipment document and then pick sales order lines to ship but this could also be done the other way round: first select a sales order (line) and then decide to ship it.

All this is of course dependent on the invoice and delivery terms for the customer. Our current processes and configurations are not always transparent and we need a redesign here as well.

Having said all this, let me ask you for now to look at the Shipping and Invoicing scenarios. There is a lot of complexity once you start looking at all the possible configurations and flows but I want to get the basics right first. Please help me in doing so.

Quick Line Picking & Price Lists

As part of the 3.0 release which includes a redesigned Sales Order Flow, we are looking at the Copy Lines and Copy From Order functionality. From now on the two together will be called Quick Line Picking. During brainstorms the following ideas/issues surfaced:

• Price list must be added as a filter as sometimes you want to pick products that never have been ordered before
• Consumption days concept does not make much sense and is tucked away too deeply. Extend date range filter to more human ranges such as “last week” or “last quarter”
• Most frequently ordered makes sense as it is likely that popular orders will be repeated
• Most recently ordered makes sense as it is likely that recent orders will be repeated
• Product category makes sense as a filter ("I only want to order hardware")
• Show for each product the sales/purchase order they belong to. Clicking the order will open it on a new tab so you can peek into it and see the rest of the order
• Use extra dedicated filters for the most important attributes. Use column filters for the less relevant filters
• Set default filters to avoid massive volumes
• Save filter settings for reuse per window type and user

We also thought of combining orders and lines in one grid, perhaps grouping them in expandable sections (Family Grid style) but the drawback is that the amount of rows in an expanded state can become excessive as it is a Cartesian product where every product is shown multiple times, as it belongs to multiple sales orders. In this stage I am not convinced about the real advantage of doing so, as selecting an entire order and then removing one or two products in the sales order lines grid afterwards is hardly an effort. However, a simplified version that used a column Last Order Used (page 18 in the PDF in the Forge link below) helps the user grouping products that belong to the last order.

I plan to keep Copy Lines and Copy From Order in separate windows (in fact, they are layers in 3.0 style) but the user can easily switch between them. I believe that a user either wants to select products from price lists or recent orders OR wants to reuse and merge all order lines from entire orders OR wants to duplicate a past order, including all its header and lines data. This last option can also be done in a grid by duplicating the row. So we´ll have three flavors to reuse order lines. The proposed solution tries to satisfy all three methods.

The Price List is the most important attribute in order line picking. The Price List is now set in the header. The lines to pick should have it as a default filter, although it should also still be possible to choose products from other price lists. The Price List Version is currently not used in the header. The new proposal does have it in the header although I am not certain if this is a good idea or not, so help me out here.

Then there is a whole set of business logic we need to rethink when adding products from a non-default price list or even more than one, which can get quite complicated when products exist in more than one price list.

I have attempted to model all of the above thoughts in an extended sales order scenario, see the first PDF document via the link below. The second PDF shows some background on Price Lists. I also noticed that the price list setup is very tedious. We must tackle this as well at some point but let´s first focus on the sales order flow.

Please have a good look and let us know if this all makes sense to you. Find the proposed solution and the discussion thread on this Forge forum.

Openbravo ERP 3.0 - Release Candidate 1 is available for download

Release Candidate 1 is our first step towards Openbravo ERP 3.0. It is an early release that is comparable to a pre-alpha release. It gives a sneak peek into what is coming in 3.0 but be aware that this release candidate is largely incomplete. In fact it contains only 39% of the functionality we plan for the 3.0 core delivery.

It sports tabs, quick launch menus, a new application menu and a first stab at the My Openbravo portal page. In addition to the new GUI, we also introduce:

• A narrowed down scope based on the key flows
• New standard roles (discuss)
• Redesigned financial flows, including advanced payables and receivables management (discuss)

View some screenshots, read the release notes, download the virtual appliance, run it in our demo instance online (Openbravo/openbravo) and discuss it all on the early release forum.

Enjoy!

The Family Grid - part II

Simple, real-time business intelligence by manipulating grids

Reporting is an essential part of everyday business and therefore an essential part of an ERP. Today´s businesses need relevant, up-to-date, accurate and consumable metrics that help them make the right decisions. Traditionally, reports are generated once in a while (month, quarter) and are exported to PDF for printing & annotating or Excel for further manipulation. Reports are used in presentations and meetings to look at past performance, understand the status quo and project future performance. The danger lies in the choice of dimensions and the interpretation of the data. Reports are static and generated as a one-off document with a set of dimensions, normally defined by a ready-made SQL query or via a visual query builder. Openbravo´s Sales Dimensional Reports allow the user to choose a number of filters and dimensions and even the sorting order can be set. This works well if the user knows in advance what metrics she is looking for and what data set she wants to look at. The drawback is that it does not allow analyzing the data in realtime by changing the filters and dimensions and looking at the impact on the results while doing so.

A while ago, in the Family Grid, I have presented a fairly abstract idea for basic business intelligence functionality by combining parent and child data in one grid, joining grids and filtering and aggregating columns. Now, I´d like to show you a more simplified version of this idea.

The Family Grid II scenario (download it here) lets the user view sales orders in one grid and a set of order lines for all of these in the other. Both the sales order grid and the order lines grid can be filtered on any attribute using column filters. Columns containing numerical values can be aggregated (sum, count, average, median). The grids can be joined (inner or outer join) with the click of a button which, for example, lets the user find all sales order that contain a certain product (or all sales that do not contain that certain product). Final result sets can be exported to Excel or PDF and the view (which is in fact a query rather than a report) can be saved for reuse.

It should be noted that this approach does not intend to replace traditional reporting because many SQL queries just cannot be build using the Family Grid. However, I believe that this way of manipulating grids is very powerful and can lead to insights that can be hard to discover using traditional one-way reporting. Playing with a data set in real time using parent and child grids, filters, aggregations and joins with an easy-to-use GUI lets non-expert users unlock the power of data in an ERP without having to invest in hi-end business intelligent software.

Are you as convinced as I am about the business value of this feature? Discuss it here.

By the way, we´re not happy with the name of this functionality. Family Grid does not cover it really. What about RapidGrid, GridSift, PowerGrid, Data Distiller, Metrix, EasyAnswer, RapidAnswer, IntelliGrid, "Openbravo RapidEdge Edition – the fastest way to start a competitive edge", "PerfectGrid - the fast & simple way to your information"?

New Multiple Selection Widget Proposal

Check out this concept for a selector that allows for multiple object selection. It´s a hybrid between toggled selection (using checkboxes to select multiple and discontinuous objects) and collected selection. See how it works.

To Stretch or Not to Stretch

In this stage we´re almost done with the HTML for the forms and grids for the 3.0 GUI. We´ve built two versions for the forms:

1. Fixed width fields. Example here

2. Relative width fields: depending on screen resolution, the fields will be stretched. Example here

Both have pros and cons. Fixed width fields are easier to scan (especially on wide screen monitors) and I suspect them to be faster in use (although the difference may be insignificant). Relative width fields allow for long value input, without the value (string of characters) being cut off. Nothing more annoying than not being able to distinguish a value because the most distinguishing characters are at the end, just outside the field.

There is even a third option: variable length input fields are pretty cool as well but I´m afraid of a creating messy forms when fields stretch individually so in case you wanted to suggest this: Don´t :-)

Also, the tab order in these demo sites follow the html by default, which is up to down. The current OB form tab order goes from the left to the right. What works best for you?

I would like to hear you opinion & experiences on both topics. Drop you reactions here.

Openbravo San Fermin: Let the Bull run through your Company

Pamplona is the birthplace of our flagship product Openbravo ERP but it is probably better known for its yearly San Fermin festival where millions of people gather to watch the famous encierro, the running of the bulls. This year we wanted to share a bit of local pride with you by letting the bull run through your company as well. We´ve created a San Fermin skin that can be downloaded as a module and applied to your instance. Find the instructions here.

We´ve also painted our demo site red (http://demo.openbravo.com) , go have a look!

A special thanks to Miguel Rodriguez Font who created the bull logo, beautifully crafted using graphic characters only.