Openbravo Localization Quality Assurance CheckList
Introduction
This document lists the mandatory and non-mandatory checks to verify for validating the quality of an Openbravo Localization Pack.
Mandatory and non-mandatory checks are split into two, therefore both the "Community" and the "Professional" edition of an Openbravo Localization can be validated.
It is important to remark that Localization projects ready to be published can be published in "QA Approved" status only if all the mandatory checks included on the validation list are successfully passed.
The Professional Localizer is required to ensure the quality of a localization pack, therefore before asking Openbravo to validate the quality of a localization pack needs to be sure that the mandatory checks
have been successfully validated.
Mandatory checks
All the checks included in this section must be mandatory passed.
In case just one is not passed, the localization pack must be rejected. The "localization" owner should fix the issue7s before another Openbravo's validation.
Community Edition
Check 1 - Community Pack Content
The "Community" pack must contain at least:
- a translation pack (in case the language is different from English). Take into account that the pack must include a translation module per module available in the Openbravo 3 distribution.
- a chart of accounts module. In some countries there are no official charts of accounts, but even for these countries there should be a sample chart of accounts module.
- and a taxes configuration module with the list of commonly used tax rates for the country.
all of them under an "Openbravo Public License" (OPL)
Other modules can be included into the "Community" pack referring to basic localization areas such as:
- commonly used payment terms or payment methods
- country regions or states
- etc
Finally, a Community Localization pack is not intended to include "Templates" that modify the core application.
For additional information on this regard please review this article.
Check 2 - Community Pack Documentation
Openbravo can validate and monitor localization documentation depending on the local language used, otherwise Openbravo could request a report or any documentation written in English.
The "Community" pack of an Openbravo Localization must be properly documented.
Above means that there should be an "Openbravo" wiki page, tagged as Category:India for instance, linked to the corresponding "Community Pack" project published in the Forge that includes:
- a "Table" that lists and briefly describes all the Modules/Packs contained in the "Community" pack.
- a link to another wiki page per each module/pack, that includes a more detailed explanation of the each "commercial" module or even a User Manual if the "commercial" module deserves it.
- and an "Installation Manual" that describes how to instal the pack, mainly describing how to properly apply the datasets contained in the corresponding pack.
See an example below:
Community Localization India in English.
Community Localization Mexico in Spanish.
![]() |
Disclaimer Please note that above ones are "real" Community Localization examples, therefore do not change those wiki pages but create new ones for your localization. For instance, if you want to document the Community Localization of France, create the wiki page: http://wiki.openbravo.com/wiki/Community_Localization_France |
Above described documentation can be written on the "local" language.
Check 3 - Community Modules Documentation
Each module/feature contained in a "Community" pack needs to be properly documented.
Above means that there should be an "Openbravo" wiki page tagged same way as described above and linked to the corresponding project published in the forge, which includes:
- a brief "Introduction" which describes the content of the module and therefore the feature or functionality that implements.
- optionally, a "Documentation" section which includes:
- a "User Manual" that clearly explains:
- the feature as well as the business scenario that can be accomplished by using the feature
- the new user interface elements such as windows, tabs or fields that are created once installed
- how to properly configure the feature
- and how to properly use it
- Other documents such as a "Functional Specification" or a "Technical Design" are not mandatory but nice to have.
- a "User Manual" that clearly explains:
- and an "Available Versions" section which list the relevant versions of the module/feature. This section has an special interest in those cases where changes in the law implies changes to be implemented in the module/feature.
See an example below:
![]() |
Disclaimer Please note that above ones are "real" Community features documentation examples, therefore do not change those wiki pages but create new ones for your localization. For instance, if you want to document the Chart of Accounts module for France, create the wiki page http://wiki.openbravo.com/wiki/Chart_of_Accounts_France |
Above described documentation can be written on the "local" language.
Check 4 - Installation in PostgreSQL
- Can we install the community pack in PostgreSQL?
- Did we get any warning during the installation process?
Check 5 - Installation in Oracle
- Can we install the professional pack in Oracle?
- Did we get any warning during the installation process?
Check 6 - Community Dataset application
There can be datasets included in the "Community" pack. Dataset checks are related to:
- Have all the system level dataset (if any) been applied successfully?
- Have all the dataset available into the community pack been applied successfully (taking into account its dependencies and the level at which should be applied) as described in the corresponding installation guide?
Check 7 - Community Pack/Modules definition
All the modules/packs included in the community version of an Openbravo localization are properly defined.
Above means that all the modules/pack contained in a "Community" Pack must have:
- a java package name such as:
- For example if your company is named Foods & Beverages and you have an Internet domain called fandb.com, all your java packages should start by com.fandb.
Then you should add: "localization.XXXXX.YYYYY" where "XXXXXX" is the shortname of the country and "YYYYYY" is the shortname of the module/pack.
Therefore, a complete java package name can look like: "com.fandb.spain.spanishtaxesconf".
- For example if your company is named Foods & Beverages and you have an Internet domain called fandb.com, all your java packages should start by com.fandb.
- a descriptive name in English
- a description and Help/Comment in English
- a license and a license text in English
- an author name that corresponds to the "Localizer" name
- and an URL that can be the url of the localizer
It is also important to check that they have followed the Naming guidelines for modules. Specially verify that "Module Names" are written in English (even for non-English modules).
Above can be verified as "System Administrator" role, in the "Module" window.
Check 8 - Community Pack/Modules publication in the Forge
It is really important to check that the community pack and all the modules/packs included in it are published in the Openbravo Forge (or Openbravo Central Repository) as described below:
- each module/pack needs to have a Project in the Forge
- each module/pack needs to be registered in the Forge
- finally, each module/pack and the corresponding project in the Forge must be related.
It is also important to check that all the projects related to the commercial modules/pack have:
- a descriptive "Name" in English
- a "Short Name" such as "paymenttermspain" in English
- a "Description" in English
- a "License" that is an "Openbravo Public License" (OPL)
- a "Project Type" that is either "Regular" or "Translation"
- a "Category" that is "Openbravo ERP"
- a "Subcategory" that is either "Localization Modules" or "Localization Packs"
- a "Visibility" that is Public
- and finally, regarding the section "Project Tools":
- a Wiki Link that points to an Openbravo wiki page that includes all the documentation/information of the module/pack, as described in Check 2 and Check 3 above.
That wiki page needs to be tagged at the very end of the document as Category:Mexico, for instance.
Please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com), before creating your country "Category". - a Bugtracking Link that points to the Openbravo Issues system - Project: Openbravo Localizations - Category: Localization Mexico, for instance.
It is important to take into account that either you want to submit a new feature request or report a defect you need to create an account or "username" here: login Openbravo.- If you are the owner of the "Professional" localization for your country, and you do not find the specific Localization "Category" for your country please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com).
- if you are the owner of the "Professional" localization for your country, please contact the Openbravo Localization Lead to inform her about the username who will monitor the issues of any kind reported for your localization project.
- and a Code Link that points to the corresponding (to be defined).
- a Wiki Link that points to an Openbravo wiki page that includes all the documentation/information of the module/pack, as described in Check 2 and Check 3 above.
- If you have any question related to any "localization" project tools link please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com).
Chart of Accounts checks
Chart of Accounts related checks are:
- Run the Initial Client Setup process for creating a new client with accounting and select the chart of accounts. Ensure that the client is successfully created.
- Run the Initial Organization Setup process for creating a new Legal with Accounting organization and select the chart of accounts. Ensure that the organization is successfully created.
In case the pack includes more than one chart of accounts module, repeat the previous checks for all of them. - Review the "Account Tree" to check that it follows a "Balance Sheet" and "Income Statement" structure.
- Review the "Account Tree" to check that there are not "Suspense" accounts located out of a specific node that is not the Balance Sheet or Income Statement node.
- Review the "General Ledger Configuration" so it is linked to the "Account Tree".
- Review the "General Ledger Configuration" so it properly has all the the mandatory "General Accounts" and mandatory "Defaults" accounts configured.
Translation Pack checks
Translation checks are related to:
- All the translation modules should be included into a translation pack. This translation pack should be included in the "Community" pack.
- Ensure that there is a translation module per each module inside the Openbravo 3 distribution. Currently there should be 13 translation modules for the modules: Query/List Widget, JSON Datasource, User Interface Application, Widget Collection, User Interface Client Kernel, Advanced Payables and Receivables, HTML Widget, Orders Awaiting Delivery, Smartclient, User Interface Selector, Workspace & Widgets, Payment Report and Core.
- Once installed, login into Openbravo and go to the change role popup. Ensure that the new language can be selected
- Change the User Interface to the new language and browse several windows, specially the most important ones, like Purchase/Sales Order, Goods Shipment, Good Receipt, Sales/Purchase Invoice, Business Partner and Product. Ensure that the application looks like it is properly translated.
- Take some percentages about the translation status. Ensure that the translated percentage is always greater than 75%.
You can use the following SQL queries to get an approximate percentage, replacing es_ES by the correspondent language:
AD_Message
select round((select count(*)
from ad_message m
join ad_message_trl mt using (ad_message_id)
where m.msgtext <> mt.msgtext
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_message), 2) ||'%' as Translated
from dual;
AD_TextInterfaces
select round((select count(*) from ad_textinterfaces m
join ad_textinterfaces_trl mt using (ad_textinterfaces_id)
where m.text <> mt.text
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_textinterfaces), 2) ||'%' as Translated
from dual;
AD_Element
select round((select count(*) from ad_element m
join ad_element_trl mt using (ad_element_id)
where m.name <> mt.name
or m.printname <> mt.printname
or m.description <> mt.description
or m.help <> mt.help
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_element), 2) ||'%' as Translated
from dual;
AD_Tab
select round((select count(*) from ad_tab m
join ad_tab_trl mt using (ad_tab_id)
where m.name <> mt.name
or m.description <> mt.description
or m.help <> mt.help
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_tab), 2)||'%' as Translated
from dual;
AD_Window
select round((select count(*) from ad_window m
join ad_window_trl mt using (ad_window_id)
where m.name <> mt.name
or m.description <> mt.description
or m.help <> mt.help
and mt.ad_language = 'es_ES') * 100.00 / (select count(*) from ad_window), 2) ||'%' as Translated
from dual;
Taxes configuration checks
Taxes module related checks are:
- Go to the Tax Rate window and get the number of tax rates included into the module. Ensure that the number is great enough.
- Take a look at some tax rates and ensure that they are properly defined.
- Ensure that there are no summary level tax rates without any child. You can use the following SQL query.
select t1.*
from c_tax t1
where t1.issummary='Y'
and not exists (select 1
from c_tax t2
where t1.c_tax_id=t2.parent_tax_id)
- Verify the Tax Zone tab has several records. In case no records (or a few) are there, it may indicate a problem in the tax rate definition. You can use the following SQL query:
select count(*)
from C_Tax_Zone
where ad_client_id=<clientID>
- Go to the Tax Category window and ensure that several records are created. In case just one record is there, it may indicate a low quality taxes module.
- Go to the Business Partner Tax Category window and ensure that several records are created. In case no records are there, it may indicate a low quality taxes module.
Professional Edition
Check 1 - Professional Pack Content
The "Professional" pack must contain at least:
- a Community Pack, and not the community modules separately
- and other extensions modules all of them under an "Openbravo Commercial License" (OCL)
Other modules can be included into the "Professional" pack referring to not that basic but more complex localization areas such as:
Finally, a Professional Localization pack is not intended to include "Templates" that modify the core application.
For additional information on this regard please review this article.
Check 2 - Professional Pack Documentation
Openbravo can validate and monitor localization documentation depending on the local language used, otherwise Openbravo could request a report or any documentation written in English.
The "Professional" pack of an Openbravo Localization must be properly documented.
Above means that there should be an "Openbravo" wiki page, tagged as Category:Mexico for instance, linked to the corresponding "Professional Pack" project published in the Forge that includes:
- a "Table" that lists and briefly describes all the Modules/Packs contained in the "Professional" pack.
- a link to another wiki page per each module/pack, that includes a more detailed explanation of the each "professional" module or even a User Manual if the "professional" module deserves it.
- and an "Installation Manual" that describes how to instal the pack, mainly describing how to properly apply the datasets contained in the pack and in the "Community" pack which will be also installed.
See an example below:
Professional Localization India in English.
Professional Localization Mexico in Spanish.
![]() |
Disclaimer Please note that above ones are "real" Professional Localization examples, therefore do not change those wiki pages but create new ones for your localization. For instance, if you want to document the professional localization for France, please create the wiki page: http://wiki.openbravo.com/wiki/Professional_Localization_France |
Above described documentation can be written on the "local" language.
Check 3 - Professional Modules Documentation
Each module/feature contained in a "Professional" pack needs to be properly documented.
Above means that there should be an "Openbravo" wiki page tagged same way as described above and linked to the corresponding project published in the forge, which includes:
- a brief "Introduction" which describes the content of the module and therefore the feature or functionality that implements.
- a "Documentation" section which includes:
- a "User Manual" that clearly explains:
- the feature as well as the business scenario that can be accomplished by using the feature
- the new user interface elements such as windows, tabs or fields that are created once installed
- how to properly configure the feature
- and how to properly use it
- Other documents such as a "Functional Specification" or a "Technical Design" are not mandatory but nice to have.
- a "User Manual" that clearly explains:
- and an "Available Versions" section which list the relevant versions of the module/feature. This section has an special interest in those cases where changes in the law implies changes to be implemented in the module/feature.
See an example below:
![]() |
Disclaimer Please note that above one is a "real" Community feature documentation example, therefore do not change that wiki page but create new ones for your localization. For instance, if you want to document the most common methods of payment used in France, create the wiki page: http://wiki.openbravo.com/wiki/Methods_Of_Payment_France |
Above described documentation can be written on the "local" language.
Check 4 - Installation in PostgreSQL
- Can we install the professional pack in PostgreSQL?
- Did we get any warning during the installation process?
Check 5 - Installation in Oracle
- Can we install the community pack in Oracle?
- Did we get any warning during the installation process?
Check 6 - Professional Dataset
There can be datasets included in the "Professional" pack. Dataset checks are related to:
- Have all the system level dataset (if any) been applied successfully?
- Have all the dataset available into the professional pack been applied successfully (taking into account its dependencies and the level at which should be applied) as described in the corresponding installation guide?
Check 7 - Professional Pack/Modules definition
All the modules/packs included in the professional version of an Openbravo localization must be properly defined.
Above means that all the modules/pack contained in a "Professional" Pack must have:
- a java package name such as:
- For example if your company is named Foods & Beverages and you have an Internet domain called fandb.com, all your java packages should start by com.fandb.
Then you should add: "localization.XXXXX.YYYYY" where "XXXXXX" is the shortname of the country and "YYYYYY" is the shortname of the module/pack.
Therefore, a complete java package name can look like: "com.fandb.spain.spanishtaxesconf".
- For example if your company is named Foods & Beverages and you have an Internet domain called fandb.com, all your java packages should start by com.fandb.
- a descriptive name in English
- a description and Help/Comment in English
- a license and a license text in English
- an author name that corresponds to the "Localizer" name
- and an URL that can be the url of the localizer
It is also important to check that they have followed the Naming guidelines for modules. Specially verify that "Module Names" are written in English (even for non-English modules).
Above can be verified as "System Administrator" role, in the "Module" window.
Check 8 - Professional Pack/Modules publication in the Forge
It is really important to check that the profesional pack and all the modules/packs included in it are published in the Openbravo Forge (or Openbravo Central Repository) as described below:
- each module/pack needs to have a Project in the Forge
- each module/pack needs to be registered in the Forge
- finally, each module/pack and the corresponding project in the Forge must be related.
It is also important to check that all the projects related to the commercial modules/pack have:
- a descriptive "Name" in English
- a "Short Name" such as "VATreportIndia" in English
- a "Description" in English
- a "License" that is an "Openbravo Commercial License" (OCL)
- a "Project Type" that is either "Regular"
- a "Category" that is "Openbravo ERP"
- a "Subcategory" that is either "Localization Modules" or "Localization Packs"
- a "Visibility" that is Public
- and finally, regarding the section "Project Tools":
- a Wiki Link that points to an Openbravo wiki page that includes all the documentation/information of the module/pack, as described in Check 2 and Check 3 above.
That wiki page needs to be tagged at the very end of the document as Category:Mexico, for instance.
Please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com), before creating your country "Category". - a Bugtracking Link that points to the Openbravo Issues system - Project: Openbravo Localizations - Category: Localization Mexico, for instance.
It is important to take into account that either you want to submit a new feature request or report a defect you need to create an account or "username" here: login Openbravo.- If you are the owner of the "Professional" localization for your country, and you do not find the specific Localization "Category" for your country please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com).
- if you are the owner of the "Professional" localization for your country, please contact the Openbravo Localization Lead to inform her about the username who will monitor the issues of any kind reported for your localization project.
- and a Code Link that points to the corresponding (to be defined).
- a Wiki Link that points to an Openbravo wiki page that includes all the documentation/information of the module/pack, as described in Check 2 and Check 3 above.
- If you have any question related to any "localization" project tools link please contact the Openbravo Localization Lead at (patricia.sanjuan@openbravo.com).
Non Mandatory checks
Validating the quality of a localization pack is a difficult task, specially when we are checking modules with code that implements a concrete business logic.
However we can run a set of verifications that, at least, will give us a clue about the quality of the code.
In general this kind of tests should not reject the localization pack, but just give us a rough idea about its quality.
Community Edition
Functional Review
The documentation provided for the "Community" modules/packs as described in Check 3 above, needs to be clear enough to allow the end-users to easily understand, configure and use those modules/features.
Openbravo can do a functional review as the language of the documentation provided by the localizer is either in English or Spanish language.
Module structure
Take one by one all the modules contained in the community pack/s and examine the file contents.
- Ensure that there is a legal folder with the license text inside it in case it is necessary
- Ensure that the files inside the pack fulfill the Openbravo standards
- In case of including templates, ensure that they have sense.
Code review
Database structure
- Open some XML files that define new database tables and ensure that the mandatory columns have been declared (ad_client_id, ad_org_id, created...)
- Open all the XML files that define new external columns and ensure that the "oncreatedefault" is set for the not null columns
PL/SQL code
- Pay special attention to triggers. Do a quick code review, paying special attention to mutant table issues
- Review INSERT and DELETE clauses. Ensure they don't break end-user important data (business partners, products, invoices, orders, etc.)
Java code
- Ensure that no XSQL files are present. All the queries to the database must be done using DAL
- Do a quick review of some Java classes. Study the code structure, the cleanliness, the control over errors and exceptions, the use of log4j, etc.
Javascript code
- Try to run JSLint for the Javascript code and check for errors
Professional Edition
Functional Review
The documentation provided for the "Professional" modules/packs, mainly the user manuals provided as described in Check 3 above, needs to be clear enough to allow the end-users to easily understand, configure and use those modules/features.
Openbravo can do a functional review as the language of the user manuals provided by the localizer is either in English or Spanish language.
Module structure
Take one by one all the modules contained in the pack/s and examine the file contents.
- Ensure that there is a legal folder with the license text inside it in case it is necessary
- Ensure that the files inside the pack fulfill the Openbravo standards
- In case of including templates, ensure that they have sense.
Code review
Database structure
- Open some XML files that define new database tables and ensure that the mandatory columns have been declared (ad_client_id, ad_org_id, created...)
- Open all the XML files that define new external columns and ensure that the "oncreatedefault" is set for the not null columns
PL/SQL code
- Pay special attention to triggers. Do a quick code review, paying special attention to mutant table issues
- Review INSERT and DELETE clauses. Ensure they don't break end-user important data (business partners, products, invoices, orders, etc.)
Java code
- Ensure that no XSQL files are present. All the queries to the database must be done using DAL
- Do a quick review of some Java classes. Study the code structure, the cleanliness, the control over errors and exceptions, the use of log4j, etc.
Javascript code
- Try to run JSLint for the Javascript code and check for errors