The community around Openbravo POS is very active and with clever members that take advantage of the product to create great things. One of the best examples of I found recently through a post in the Spanish forums [1] is the use of an iPad with Openbravo POS.

This solution has been implemented by a Trattoria in Peru called Don Angelo [2]. The iPad is offered to the customers of the restaurant instead of the menu, and they use the iPad to view the menu, and make orders. This way orders are faster and with less mistakes. Customers find it very easy and everybody is very happy with this innovation.

This solution has also attracted the attention of the media [3] and they have also a very nice promotional video where you can see Openbravo POS in action [4].

The technical details are very simple: Openbravo POS runs inside a virtual machine in a host computer, and the iPad has installed the application WYSE pocketcloud [5] for iPad that cost only $14.99 and that allows to access to the virtual machine where Openbravo POS runs.

My congratulations to the developers of this innovative solution.

[1] http://forge.openbravo.com/plugins/espforum/view.php?group_id=101&forumid=446545&topicid=7017054&topid=7018879 (in Spanish)
[2] http://www.donangelo.pe/Trattoria_Don_Angelo/Promociones/Entradas/2010/7/21_Carta_Ipad_en_nuestro_Restaurante.html (in Spanish)
[3] http://www.peru.com/noticias/portada20100812/112347/Restaurante-peruano-entre-los-pioneros-en-el-mundo-en-uso-de-iPad-en-servicio (in Spanish)
[4] http://www.youtube.com/watch?v=xEh1WD9qeeg (in Spanish)
[5] http://www.wyse.com/products/software/pocketcloud/index.asp

Release 3.0 of Openbravo will be an exciting release with major improvements in the user experience. A few weeks ago we released 3.0-RC2 that contains only a small part of the total user experience redesign we planned for 3.0-Production (due for Q1 next year).

Stability is a keyword inherently attached to ERP systems. System integrators and end users want a system that simply offers them the capabilities they need in a pleasant manner and at any moment. In this case stability means that it always works in the way they expect it to work. Openbravo takes this challenge very seriously, as you can see in our current 2.50 MPs (Maintenance Packs) release process:

• We run a set of automated tests on every commit, which in practice means a 24/7 job: build tests, sanity tests, upgrade tests, functional tests, etc.
• As a general rule every commit is related to a resolved issue. The QA team, together with the development team, leads the effort of individually verifying the correct resolution of these issues.
• The QA team performs complete set of manual tests before releasing a maintenance pack to guarantee the quality of the release.

This is the global picture of our current 2.50 MP release process, delivered at the beginning of every month. Now we would like to go beyond this by offering an additional service level in our MPs. And precisely the Life Cycle Management feature introduced in version 2.50MP20 makes this possible: whenever a released MP stays live without known issues for 40 days we’ll tag that release in a special manner. So that system integrators can choose to either use the current stable versions or the ones that have matured for 40 days.

This Life Cycle Management feature introduces the concept of Maturity level for modules, which allows Openbravo to make use of its statuses as follows:

• Test: primarily used by the Openbravo QA team. This is the pre-release status.
• QA Approved (old name: Controlled release): this is the current maturity level of the MPs once they are released. It means they have passed the automated tests, the issues have been individually verified and the QA team has run a comprehensive set of manual tests.
• Confirmed Stable (old name: General availability): the module has passed 40 days in the QA Approved maturity level without any known issues.

So in practice, what does this mean for a system integrator? Simple: those looking for exactly the same maturity level of the current MPs should use the QA Approved status. And those who would like to go beyond this level should consider using the Confirmed Stable status.

Configuring this is as simple as selecting the desired setting in the Module Management Console:

Note that Confirmed Stable is the default option for all the modules. We’ll apply this policy for Core starting from 2.50MP23.

 

EDIT, 2011/07/04: the maturity levels have been renamed as follows:

• Controlled Release → QA Approved.
• General Availability → Confirmed Stable.

Tagged: QA, Release process, Releases

One of my favorite podcasts is Steve Bragg's Accounting Best Practices. Steve is the author of over 40 accounting books and a former CFO of both public and private companies. His podcast covers many topics relevant for an ERP professional, ranging from process best practices, to reviews of accounting technologies, to commentary on IFRS and GAAP.

The podcast has been active for a few years but I discovered it only this past January. Since then I have been both listening to new episodes and catching up on old issues.
Besides being informative, Steve brings a very practical point of view to the accounting technology, providing a good insight in what a CFO expects from an accounting software and often commenting on what worked for him as a user.

In episode 42, Steve discusses how printing invoices in PDF format can improve the chances of collection. PDF invoices have the advantage of being easy to generate and email to customers who receive them in a timely manner in a format that is easy to read, understand and print. In his experience, this simple practice is one of the most effective tools to not only reduce overdue receivables but also to simplify the collection of overdue items. Using PDF invoices, Steve has been able to handle over 50% of overdue receivables with one single email.

As a software professional, I am always surprised by how the simplest things are often the most effective.


Steve concludes that episodes recommending listeners to buy some PDF conversion software and returns to the topic in a later episode pointing to additional tools, some of which are offered as freeware. However, regardless of the license type and cost, using an external PDF generation tool is time consuming. You need to install the PDF virtual printer, generate the PDF output, archive it and then email it to your customers.

Openbravo offers the ability to generate PDF invoices natively. This feature has been available since the beginning of the project and recently went through some significant improvements. Starting from 2.50 MP20, all the printed document formats (customer and supplier invoices but also sales orders, shipment notices, etc.) have been revised to have clearer and more complete formats. They also support additional parameters allowing you to fine tune the graphical layout of your invoices. What previously required a developer with Jasper Reports skills is now within reach of end users:

• If you print your invoices on plain paper or you email them, you can configure whether your company logo appears on the invoice.
• Similarly, you can control whether your company address appears on the invoice.
• You can print a different logo and address depending on the organization that issues the document.
• If you print your invoices on company letterhead, you can control the size of the header margin to ensure the best fit with your existing brand graphic design.

The entire process Steve describes is fully automated in Openbravo. The combination of PDF output features and email capabilities allows you to send PDF invoices to your customers directly from the application either en masse or on a document by document basis. The email message can be based on an email template for a completely touchless process, or can be manually edited to add explanation of complex invoices, further reducing the risk of billing disputes. You can also automatically archive the invoices you emailed and keep an auditable trace of the documents you sent.

If you are looking for a solution to manage customer invoicing and collections, you should give Openbravo a try.

I am pleased to announce that today Openbravo released Openbravo 3.0 RC2, the second release candidate in the 3.0 series.

This is a very exciting milestone for us because, unlike its predecessor RC1, Openbravo 3.0 RC2 supports onwards updates to both future release candidates and generally available releases.

This means that Openbravo 3.0 RC2 is not limited to evaluation or development purposes only and can be considered for production usage by early adopters in new implementations. As such Openbravo 3.0 RC2 is a fully supported release and it is available both as a Community Edition and Professional Edition.

Release candidates are incremental deliveries towards the full 3.0 road map and do not contain the full set of functionality intended for 3.0. Also, while new functionality has been thoroughly tested, they should be considered not yet proven.

If you are a new user interested in learning about Openbravo and evaluating the product, you should consider using Openbravo 3.0 RC2 as it gives you a closer representation of what is coming in the next months. If you are an existing community member interested in staying up to speed with the latest evolutions of Openbravo, you should download and install Openbravo 3.0 RC2.

If you are interested in deploying Openbravo for production usage, you should consider either Openbravo 2.50 or Openbravo 3.0 RC2 depending on the time frame of your implementation and your attitude towards both risk and change.

Early adopters interested in deploying Openbravo 3.0 RC2 for new implementation projects:

• are recommended to thoroughly test planned business processes before deploying release into a production environment;
• should be prepared for both UI and functional changes in subsequent releases; future 3.0 release candidates will provide improvements in usability and system operation but will require users of 3.0 RC2 upgrading to those releases to be able to absorb significant changes.
  

Users looking for a production deployment in the short term as well as users valuing stability should continue considering our generally available product, Openbravo 2.50.
Upgrades from earlier version of Openbravo (2.40, 2.50 or 3.0 RC1) are not yet supported so existing Openbravo users should wait for subsequent release candidates before considering an upgrade.

On the surface, Openbravo 3.0 RC2 looks similar to 3.0 RC1. However, it introduces very significant changes:

• The Requisition to Receipt and Budget to Analysis flows are now supported, completing the 3.0 functional footprint.
• The financial flows are based on the latest version of Advanced Payables and Receivables, which include the following new features:

• Manual and automatic payment execution
• Refunds to customers

The keyboard shortcuts capabilities have been enhanced to support all the new layout components such as tabs, Quick Create and Quick Launch.

Openbravo 3.0 is architected to support modules originally developed for 2.50 and to make it is easy for module authors to support both versions from a single code line. Thanks to that, Openbravo 3.0 RC2 already benefits from a rich catalog of 42 modules, among which:

• Initial Data Load
• Spanish Community Localization Pack
• Spanish Professional Localization Pack
• Electronic Invoicing
  
• Multi-dimensional Tax Report

Module authors in our Community interested in making their modules available for 3.0 should stay tuned for instructions to be published in the coming days.

If you want to learn more about Openbravo 3.0 RC2, please review the release notes for a full description of the release, download instructions or Amazon EC2 AMI codes. If you are pressed for time and have only a few minutes to learn about the product, you can take it for a spin in our demo environment.

We are confident that you will be as excited about 3.0 RC2 as we are. As always, you are encouraged to tell us what you think, by posting a comment on this post, raising an issue in issues.openbravo.com or discussing it in the Early Releases Discussion forum.

Since we first published the roadmap for Openbravo 3.0 last January, a few people have been asking why are we focusing on a simplified functional footprint and have decided to eliminate some functionality from the Community Edition.

At Openbravo we believe that every company should have an ERP and that open source offers a great opportunity to disseminate our product and to put great ERP solutions within reach of companies of every size and with every budget.

Our experience however taught us that complexity is our enemy: our open source license allows many people to download and install Openbravo but too many of them still struggle adopting it because of the difficulties they face during the implementation.

For 3.0 we have embarked in a big effort to eliminate complexity. The new interface makes the user experience not only more productive but also more intuitive: with the My Openbravo dashboard users will always have the most important information at their fingertips; with the new navigation they will never get lost in the product; with multi-tabs they will be able work on multiple documents at the same time; with the master-detail layout, they will be able to see full documents in a single window and to reduce the number of clicks needed to perform an action; with editable grid, they will be as productive in their ERP as they are with a spreadsheet; with the new searches, they will be able to easily find and extract valuable business information out of the system.
From a functional perspective, the new financial flows - already available to Professional Edition subscribers in 2.50 through the Advanced Payables & Receivables module and embedded in the Community Edition in 3.0 - blend the simplicity of a consumer oriented accounting package with the robustness of an enterprise grade finance application.

We expect that these changes will increase the successful adoption of Openbravo among open source users.

However, for some areas of the product - and specifically for manufacturing, MRP and project billing and accounting - we had to conclude that a certain level of complexity is inherent in the functionality and that the only way to guarantee their successful deployment is to make sure that the implementation is assisted by a trained professional, such as an Openbravo partner.

Following this logic, we decided that the best course of action is excluding them from the Community Edition and releasing them as zero cost commercial modules exclusively available through Openbravo partners working with the Professional Edition.

Eliminating functionality is always a tough decision and we realize that this can be disappointing to those Community Edition users who are currently leveraging the features we have decided to discontinue in their edition of choice. These users should stay tuned as we will provide upgrade recommendations for them in the coming months and before 3.0 reaches production status.

We are confident that this change will increase the appeal of the product and will allow a much bigger number of organizations to be successful with Openbravo. More companies will be benefiting from our community editions, and clients with more complex needs will be better served by our professional partner channel.

As you probably know, beginning version 2.50, Openbravo features a powerful Data Access Layer based on Hibernate which can be used to build powerful Business Logic code in a platform independent and secure way. If you use the DAL to access and manipulate the Openbravo database, your code gains several very convenient features for free. An easy example of this is that all DAL queries and operations have security and validation checks automatically implemented. The Openbravo standard security model is applied whenever any query or operation is done through DAL. Client and organization filtering is applied, and entity access is also checked.

The DAL has a special mode of operation called Administration mode. In this mode, the security checks (including client/organization and entity access) are not applied, and therefore the code which is executed under this mode is allowed to access all entries in all entities, for every client and organization. This is handy for developing code which doesn’t need these checks.

During the last months we’ve found out that in fact, the entity access check is not needed for most business logic code (because the entity access is usually done by the application itself; if for example the code corresponds to a callout, the callout itself will only be called if the user enters the window, and therefore only if the user has access to that particular entity). However, the client/organization filter is really very important in most business logic pieces of code, because it allows the developer not to have to worry about it (DAL automatically only provides the objects which the user has access to).

Because of this, starting MP22 we are providing a new, stricter admin mode. This special admin mode doesn’t do entity access checks (and therefore your code can freely access entities, even if the user of the context does not have access to their window), but still filters by client and organization when doing queries and operations into the database. This new mode is the advised one for every business logic code developed for MP22 and onwards. It can be used in your code by using the following calls:

try {
OBContext.setAdminMode(true);

// queries and other DAL calls

} finally {
OBContext.restorePreviousMode();
}

You can find out more information about the DAL Admin mode here. This new mode will be available in MP22, if you need to use admin mode in earlier versions of Openbravo, you can find out how in the link.

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.