Hace unos pocos días anunciábamos la inmediata disponibilidad de una nueva versión del módulo de impuestos para España (1.2.45) que incluía todas las novedades que entrarán en vigor a partir del 1 de septiembre del 2012.
En nuestro afán por publicar la nueva configuración de impuestos lo antes posible para facilitar el trabajo de nuestros usuarios y, debido principalmente a la confusa comunicación de la información relativa a los nuevos impuestos, existía un error en el porcentaje de la retención e ingreso a cuenta de las actividades profesionales que fue rápidamente detectado por nuestra red de partners.
Según el BOE el porcentaje de retención e ingreso a cuenta para actividades profesionales sube del 15% al 21% desde el 1 de septiembre. Sin embargo esta medida es excepcional hasta el 31 de diciembre de 2013, momento en el cual el porcentaje pasa al 19%.
En la versión 1.2.45 del módulo de impuestos el porcentaje de los impuestos afectados era del 19% en lugar del 21%. Esa versión ha sido cancelada y se ha publicado una nueva versión (1.2.46) que lo soluciona. Por este motivo es fundamental que actualice su instancia con esta versión del módulo de impuestos o una superior.
Para guiar a nuestros usuarios en el proceso de actualización del módulo de impuestos, se ha creado un documento con los pasos detallados que se deben seguir para actualizar correctamente la configuración de impuestos en instancias de Openbravo. El documento se encuentra disponible en el siguiente enlace.
Esperamos que el documento les aclare completamente cualquier tipo de duda que puedan tener sobre el proceso.
viernes, 10 de agosto de 2012
viernes, 15 de junio de 2012
New Localization Guide - request for feedback
As you probably know in the past we have had a lack in documentation related to the localization process. A great number of localizers (Community and Partners) have often been complaining about it, and obviously they were right...
But that was in the past :-)
During the last weeks we have been working on a new Localization Guide that will definitely improve the localizer experience. It provides all the information required for developers interested in the localization for Openbravo.
The most important value of this guide is the set of very detailed how-tos about the common modules usually involved in any localization project. These how-tos are written so that anyone can find in just one document all the required steps to complete a concrete localization task.
The guide is now available in our Wiki, although it is not fully completed. It is still pending just a few articles and, specially, a deep review from readers.
And here is where we need you!
It would be great if you could spend a few minutes to read some articles (the most interesting for you) and provide your feedback (structure, content, English...). All the opinions will be welcome, specially the good ones :-)
You can post your feedback into the Forum topic created for it.
I hope you find it interesting.
Thanks in advance for your collaboration!
But that was in the past :-)
During the last weeks we have been working on a new Localization Guide that will definitely improve the localizer experience. It provides all the information required for developers interested in the localization for Openbravo.
The most important value of this guide is the set of very detailed how-tos about the common modules usually involved in any localization project. These how-tos are written so that anyone can find in just one document all the required steps to complete a concrete localization task.
The guide is now available in our Wiki, although it is not fully completed. It is still pending just a few articles and, specially, a deep review from readers.
And here is where we need you!
It would be great if you could spend a few minutes to read some articles (the most interesting for you) and provide your feedback (structure, content, English...). All the opinions will be welcome, specially the good ones :-)
You can post your feedback into the Forum topic created for it.
I hope you find it interesting.
Thanks in advance for your collaboration!
viernes, 20 de enero de 2012
Spanish Withholding Report: Modelo 190
We are proud to announce the availability of the Spanish withholding report Modelo 190 for the fiscal year 2011, which lists all the monetary withholdings related to professional activities and must be submitted to the Spanish tax authorities by January 31st, 2012 the latest.
This report takes into account the amounts effectively paid, therefore Modelo 190 is released as explained below:
The last two are also ready to work in instances that have been migrated from the old financial flow. The generated report automatically merges the information from both financial flows, allowing Modelo 190 to be launched in any possible scenario.
All these modules are distributed under a commercial license that requires acquiring an activation key before the installation. However, they are available at zero cost to Professional Edition subscribers.
And good news doesn't end here: the Spanish tax report Modelo 390 will come very soon, so stay tuned!
This report takes into account the amounts effectively paid, therefore Modelo 190 is released as explained below:
- Withholding Report: Modelo 190 (Spain) - NOT APRM compatible v1.0.3, to be installed in Openbravo 2.50 instances without Advanced Payables and Receivables Management functionality.
- Withholding Report: Modelo 190 (Spain) v1.3.2, to be installed in Openbravo 2.50 instances working with the new financial flows (Advanced Payables and Receivables).
- Withholding Report: Modelo 190 (Spain) v3.3.2, to be installed in Openbravo 3 instances.
The last two are also ready to work in instances that have been migrated from the old financial flow. The generated report automatically merges the information from both financial flows, allowing Modelo 190 to be launched in any possible scenario.
All these modules are distributed under a commercial license that requires acquiring an activation key before the installation. However, they are available at zero cost to Professional Edition subscribers.
And good news doesn't end here: the Spanish tax report Modelo 390 will come very soon, so stay tuned!
Modelo 190: Resumen anual de retenciones e ingresos a cuenta
El modelo tributario oficial 190 de la AEAT para el año fiscal 2011 ya está disponible en Openbravo ERP. Este modelo resume las retenciones practicadas en actividades económicas incluidas dentro de las facturas de compra contabilizadas en Openbravo.
El informe tiene en cuenta las cantidades efectivamente pagadas en cada factura, por lo que se distribuye en tres modalidades diferentes:
Todos estos módulos se distribuyen bajo la Licencia Comercial de Openbravo, pero están disponibles sin coste adicional para los suscriptores de la Edición Profesional.
Y las buenas noticias no terminan aquí: el modelo tributario 390 también estará disponible muy pronto, ¡estén atentos!
El informe tiene en cuenta las cantidades efectivamente pagadas en cada factura, por lo que se distribuye en tres modalidades diferentes:
- Withholding Report: Modelo 190 (Spain) - NOT APRM compatible v1.0.3, para ser ejecutado en instancias de Openbravo 2.50 con el flujo financiero antiguo.
- Withholding Report: Modelo 190 (Spain) v1.3.2, para ser instalado en instancias de Openbravo 2.50 con el nuevo flujo financiero (Advanced Payables and Receivables).
- Withholding Report: Modelo 190 (Spain) v3.3.2, compatible con Openbravo 3.
Todos estos módulos se distribuyen bajo la Licencia Comercial de Openbravo, pero están disponibles sin coste adicional para los suscriptores de la Edición Profesional.
Y las buenas noticias no terminan aquí: el modelo tributario 390 también estará disponible muy pronto, ¡estén atentos!
lunes, 3 de octubre de 2011
Module Packager
Module Packager is the name of a new extension module available for Openbravo 3 and 2.50 versions. It is released under the Openbravo Public License and it can be installed through the Module Management window of your Openbravo instance.
This module is mainly intended for developers who want to reduce the time it costs to package a module, and for the users who are not comfortable running commands into the shell terminal.
When installing this module, it adds a button inside the Module window that allows the developer to run all the common tasks that are needed for packaging a module in just one click. The button is available for modules set as in development.
The Module Packager currently supports:
- Exporting the datasets configured for the module (if any).
- Exporting the database.
- Exporting the translation XML files, saving them into the appropriate folder (only in case of translation modules). To perform this task it delegates to the Translations Management Extension developed by Marcos Bernal.
- Packaging the module into an obx file ready to be published into the Central Repository
The developer can manually selects the tasks he wants to be run each time, thus simplifying and speeding up the process of packaging a module.
This module is mainly intended for developers who want to reduce the time it costs to package a module, and for the users who are not comfortable running commands into the shell terminal.
When installing this module, it adds a button inside the Module window that allows the developer to run all the common tasks that are needed for packaging a module in just one click. The button is available for modules set as in development.
The Module Packager currently supports:
- Exporting the datasets configured for the module (if any).
- Exporting the database.
- Exporting the translation XML files, saving them into the appropriate folder (only in case of translation modules). To perform this task it delegates to the Translations Management Extension developed by Marcos Bernal.
- Packaging the module into an obx file ready to be published into the Central Repository
The developer can manually selects the tasks he wants to be run each time, thus simplifying and speeding up the process of packaging a module.
martes, 1 de marzo de 2011
Using messages with parameters in Java
Messages are one of the most important parts of a software. They enable the application to inform the user about errors, warnings or other important information. That's why we should give them special consideration.
Users: Sometimes developers find it difficult to write a simple and clear message. We are used to writing sentences in a cryptic computer language, so it's natural for us to also write cryptic messages (that are almost impossible for an average user to understand).
Developers: We must appreciate that a user expects messages in his natural language, not in machine language... Yes, I know it sounds strange and difficult but we need to make an effort... It is also important to consider translators; the simpler and clearer the message, the more likely it is to be correctly translated.
Example: there is a process which executes some kind of business logic. Imagine the process fails in the middle of the execution with the following error:
RUNTIME EXCEPTION
...and now try to imagine the average-user's face!
Yeah, I know all the developers are saying: "no problem, we can dive into the application logs, we can debug the code, etc."; but the user isn't able to do that. This message is a "show stopper" for them... and we don't want this situation to happen.
As I said before, a message must be written in a "natural" language and must try to be as helpful as possible, specially when dealing with errors. In the previous example, a good message could be:
The invoice IV-1000004 has not been posted yet. Remember that invoices must be posted before running this process
For developing that we could think about creating two different messages, one for "The ", and the other one for " has not been posted yet. Remember that invoices must be posted before running this process". After that, in the Java code, we could easily concatenate the invoice number between these two messages... Wrong!!
Again, the developer must consider the localizer who is faced with translating two meaningless strings of text.
Translating is a very difficult (and time consuming) task. A localizer must be provided with meaningful phrases (where the context is clear) for translating, otherwise the translation will almost certainly be inaccurate.
So, the best way to keep both our users and localizers happy would be to create the message with the invoice number as a parameter.
In Java we have all the flexibility to implement our own parametrized messages framework. In my developments I use the String.format(java.lang.String, java.lang.Object...) method, which is very similar to the C's printf().
Let's see how it works:
* The error message included into the Application Dictionary is: "The invoice %s has not been posted yet. Remember that invoices must be posted before running this process". Observe the %s, that represents our parameter.
* The Java code for passing the invoice document number to the message is as easy as:
As usual, we recover the "BLOG_INVOICE_NOTPOSTED" message from the Application Dictionary using the Utility.messageBD() method.
Then, the recovered message is used as the first parameter of the String.format() static method. The second parameter is the invoiceDocNo string (IV-1000004 in the example), that will replace the %s of our message.
With this very basic considerations, users and localizers will be very happy and the product will be even better.
Users: Sometimes developers find it difficult to write a simple and clear message. We are used to writing sentences in a cryptic computer language, so it's natural for us to also write cryptic messages (that are almost impossible for an average user to understand).
Developers: We must appreciate that a user expects messages in his natural language, not in machine language... Yes, I know it sounds strange and difficult but we need to make an effort... It is also important to consider translators; the simpler and clearer the message, the more likely it is to be correctly translated.
Example: there is a process which executes some kind of business logic. Imagine the process fails in the middle of the execution with the following error:
RUNTIME EXCEPTION
...and now try to imagine the average-user's face!
Yeah, I know all the developers are saying: "no problem, we can dive into the application logs, we can debug the code, etc."; but the user isn't able to do that. This message is a "show stopper" for them... and we don't want this situation to happen.
As I said before, a message must be written in a "natural" language and must try to be as helpful as possible, specially when dealing with errors. In the previous example, a good message could be:
The invoice IV-1000004 has not been posted yet. Remember that invoices must be posted before running this process
For developing that we could think about creating two different messages, one for "The ", and the other one for " has not been posted yet. Remember that invoices must be posted before running this process". After that, in the Java code, we could easily concatenate the invoice number between these two messages... Wrong!!
Again, the developer must consider the localizer who is faced with translating two meaningless strings of text.
Translating is a very difficult (and time consuming) task. A localizer must be provided with meaningful phrases (where the context is clear) for translating, otherwise the translation will almost certainly be inaccurate.
So, the best way to keep both our users and localizers happy would be to create the message with the invoice number as a parameter.
In Java we have all the flexibility to implement our own parametrized messages framework. In my developments I use the String.format(java.lang.String, java.lang.Object...) method, which is very similar to the C's printf().
Let's see how it works:
* The error message included into the Application Dictionary is: "The invoice %s has not been posted yet. Remember that invoices must be posted before running this process". Observe the %s, that represents our parameter.
* The Java code for passing the invoice document number to the message is as easy as:
String message = String.format(Utility.messageBD(new DalConnectionProvider(),
"BLOG_INVOICE_NOTPOSTED", getLang()), invoiceDocNo);
As usual, we recover the "BLOG_INVOICE_NOTPOSTED" message from the Application Dictionary using the Utility.messageBD() method.
Then, the recovered message is used as the first parameter of the String.format() static method. The second parameter is the invoiceDocNo string (IV-1000004 in the example), that will replace the %s of our message.
With this very basic considerations, users and localizers will be very happy and the product will be even better.
viernes, 2 de julio de 2010
Intrastat for Openbravo ERP
Intrastat is the system used to collect statistics on the trade of goods between European Union countries. All the VAT-registered companies in the European Union are required to provide information about arrivals (purchases, imports...) and dispatches (sales, exports...) of goods within the European Union.
Companies must submit to the authorities a valid file containing all the information related to these movements.
Openbravo ERP supports Intrastat since 2.50MP12 through the installation of several modules. In this post I give you a summary about how to get the Intrastat file ready to be submitted to the authorities using Openbravo ERP.
Modules definition
Currently, the Instrastat feature for Openbravo ERP is mainly divided into the following modules:
How to install it
All these modules are stored into the Central Repository, so you can install them as usual, i.e. using the Module Management in your Openbravo ERP environment.
Take into account that these modules are distributed under a commercial license that requires acquiring an activation key before the installation. However, these modules are available at zero cost to Professional Edition subscribers. Please contact your Openbravo Partner in case of doubts.
Configuring your data
The Intrastat report stores a great amount of data that is almost impossible to manage manually. If you want Openbravo ERP to generate the report for you, you first need to invest some time in properly configuring your data. For example, you need to add the Intrastat information for your Products and Business Partners:
The more detailed configuration you enter into the ERP, the faster it will generate the Intrastat file. So it's up to you ;-)
How it works
Each time you enter an Intracommunity transaction into the system, the Intrastat framework will automatically catch it. Several tabs have been added to the ERP in order to manage Intrastat transactions, like for example at invoice line level:
The system will retrieve the information you have previously entered in your Master Data and it will populate this tab.
How to get the Intrastat file
Whenever you want to get the Intrastat file, you can use the Intrastat Launcher window available at Intrastat || Analysis Tools || Intrastat Launcher || Intrastat Launcher:
This process creates/updates an Intrastat declaration in draft status based on the transactions available in the system for the selected period. The declaration can be reviewed by the user at Intrastat || Analysis Tools || Intrastat Declaration window.
Inside the lines tab, the user has the opportunity to manually modify the fields in case he needs to change something in a particular transaction, or even to create new lines or exclude some of them from the report.
Once the Intrastat declaration is processed, the user can easily get the file pressing the Generate File button.
Remember, this post is a brief summary about the Intrastat capabilities in Openbravo ERP. If you want to learn more about them, visit the project's home page, and specially the project's wiki where you will find the Functional and Technical documentation of the project (English) and also the complete User Manual (Spanish only).
Companies must submit to the authorities a valid file containing all the information related to these movements.
Openbravo ERP supports Intrastat since 2.50MP12 through the installation of several modules. In this post I give you a summary about how to get the Intrastat file ready to be submitted to the authorities using Openbravo ERP.
Modules definition
Currently, the Instrastat feature for Openbravo ERP is mainly divided into the following modules:
- Intrastat, which is the core of the functionality. It provides a generic and country agnostic framework for managing Intrastat-related transactions.
- Intrastat for Spain, which runs on top of the Intrastat framework and implements the concrete business logic for Spain. It is also in charge of creating the Intrastat file compatible with the Spanish requirements.
- Intrastat - Spanish translation, which adds the Spanish (Spain) translation for the Intrastat module.
How to install it
All these modules are stored into the Central Repository, so you can install them as usual, i.e. using the Module Management in your Openbravo ERP environment.
Take into account that these modules are distributed under a commercial license that requires acquiring an activation key before the installation. However, these modules are available at zero cost to Professional Edition subscribers. Please contact your Openbravo Partner in case of doubts.
Configuring your data
The Intrastat report stores a great amount of data that is almost impossible to manage manually. If you want Openbravo ERP to generate the report for you, you first need to invest some time in properly configuring your data. For example, you need to add the Intrastat information for your Products and Business Partners:
The more detailed configuration you enter into the ERP, the faster it will generate the Intrastat file. So it's up to you ;-)
How it works
Each time you enter an Intracommunity transaction into the system, the Intrastat framework will automatically catch it. Several tabs have been added to the ERP in order to manage Intrastat transactions, like for example at invoice line level:
The system will retrieve the information you have previously entered in your Master Data and it will populate this tab.
How to get the Intrastat file
Whenever you want to get the Intrastat file, you can use the Intrastat Launcher window available at Intrastat || Analysis Tools || Intrastat Launcher || Intrastat Launcher:
This process creates/updates an Intrastat declaration in draft status based on the transactions available in the system for the selected period. The declaration can be reviewed by the user at Intrastat || Analysis Tools || Intrastat Declaration window.
Inside the lines tab, the user has the opportunity to manually modify the fields in case he needs to change something in a particular transaction, or even to create new lines or exclude some of them from the report.
Once the Intrastat declaration is processed, the user can easily get the file pressing the Generate File button.
Remember, this post is a brief summary about the Intrastat capabilities in Openbravo ERP. If you want to learn more about them, visit the project's home page, and specially the project's wiki where you will find the Functional and Technical documentation of the project (English) and also the complete User Manual (Spanish only).
Suscribirse a:
Entradas (Atom)