Dec 27, 2007

Supporting the localization of Openbravo

by Nicolas Serrano
Openbravo is spreading over many countries. You can see the localization project list, the map of partners and the success stories.
This has been done thanks to our community, partners and the Openbravo team.

In the Get Together event we saw the interest of our community in the localization projects of Openbravo. We have a localization team focused on this task and, as a result, you can use Openbravo in many countries, in some cases thanks to a localization pack developed by Openbravo itself and in many others thanks to projects lead by the larger community.

We see this as a sign of success as our goal is to support a localization process lead by the community, as we believe that to be the most scalable way to achieve global coverage.

In this spirit, besides answering questions in the forums, we have made an effort in providing more documentation about the localization process itself and the task related to it, e.g. accounting tasks. In particular, we have released new documents that can help you developing a localization for your own region. You can see them in our wiki page, in the Localization section. Here you can find the documents that explain how to create new chart of accounts and test them, create customized reports about accounting and taxes or the behaviour of taxes in Openbravo.

Our experience with the localization process is that the creation of the chart of accounts is the more difficult for people, usually because it is hard to have the required dual competence in accounting and software development together.

We think there are two ways of approaching this, depending on whether your country has official laws about this or not. For example, in Spain the chart of accounts is defined by the government and you must use the accounts and reports defined there, without a lot of choices.

The opposite happens in countries like the USA where there are no firm guidelines and therefore you must define how to organize this information. In the cases of the U.S., we have made the choice of implementing the simplest chart of accounts following the guides of a well know U.S. financial institutions, i.e. the U.S. Securities and Exchange Commission. If your country does not have compulsory laws, you could take a similar approach and start by reviewing this document and even use a translation of the US chart of accounts as a starting point.

We are aware that there is a lot more to localization than just translation and chart of accounts. Openbravo is a very flexible platform and many deeper localization functionality can be easily developed in addition to accounting.

We keep improving the tools and documentation to make easier the localization process and we’re forward looking to hearing from you in the localization forums, even we delay some answers or we have difficulties answering some of your questions.




Dec 20, 2007

Call for Participation in Openbravo 2.35 Maintenance Pack 1 Acceptance Testing

by Paolo Juvara
I do not blog as much as I should but so far it looks like a pattern: once on release naming convention and a few days later on acceptance testing.

Openbravo is just about to launch its first maintenance pack, 2.35 MP1, and we are asking the community to help us validate its quality before release.

If you are willing and able - or if you wanted to participate for 2.35 and couldn't - this opportunity is for you! Notify us of your interest by sending an email to collaborate@openbravo.com.

The process is going to be very similar to what we did for R2.35, but with a few improvements based on the lessons we learned in that exercise. Specifically, here is what we are asking:
  1. We will give you early access to the installer through a private FTP server. You will essentially receive the release at the same time as our QA team.
  2. We will give you access to our QA portal, where you can see our test cases for the acceptance test. Following the experience with the previous round of acceptance testing, we have significantly improved the quality of test cases.
  3. We will assign you a set of test cases and we expect that you will install the application on your server, run the test cases and report the outcome in the QA portal
  4. Contrary to what we did in 2.35, we will not assign you any bug to verify as we will execute that task internally (we think it is more productive this way). Obviously you are free to verify specific bugs that you care about.
  5. If you have any questions or doubts during the process, we will be available on the IRC channel to answer.
Acceptance testing should start today and ideally should last 4 or 5 days. However, as most countries are in the Holiday Season, we plan to extend acceptance testing till January 4th.

Please remember that this is going to be Acceptance Testing, not a full blown QA cycle. The purpose of Acceptance Testing is to validate that an already QA'ed release is good to go and that the last build didn't introduce any major regression (essentially: test the product as it is going to be shipped before your users do to avoid to be embarrassed later).
Because of that, we will stop the release of the maintenance pack only if one of the test cases fails with a significant bug or one of the critical bugs that we thought had been fixed still reproduces. Nonetheless, we do expect you to log all issues you find, including small bugs, as we will fix those in future releases.

So what is 2.35 MP1? It is a stabilization pack that solves approximately 41 of the most severe issues that have been reported by the community and represents a major milestone in Openbravo's commitment to deliver a stable Community Edition that can be acquired and operated in a truly free manner.

We look forward to your participation in this very important milestone!



Dec 14, 2007

We listen!

by Paolo Juvara
This past October, I had published a blogpost in which we discussed a revision of the naming standards for the Openbravo releases.

Release names had been a hot topic at Openbravo for a while as our community complained several times that it was difficult to understand them and with that change we had hoped to resolve the problem.
In fact that announcement created further discussions, both as comments to post itself, as well as in other forums and blogs. In those discussions, a lot of very good ideas came up, so we thought of giving it a second try.

Yesterday we published a revised definition of our release strategy and in particular, we adopted a new naming standard. Check it out and let us know what you think!