A petición de algunas personas hemos preparado un último curso de formación técnica para este año. No tenemos previstos más de momento. El curso se celebrará la primera semana de Junio y quedan 2-3 plazas libre en el caso de que alguien esté interesado que se ponga en contacto con nosotros en info@acysos.com o en el número 948 238905
Un saludo
lunes 25 de mayo de 2009
lunes 22 de diciembre de 2008
Hijack
Hi,
This afternoon I was reviewing some docs in order to quote an OpenERP implementation. Usually, on every quote, we carefully explain what is free software, what are the licences involved and its rights involved, etc. Not everybody knows what free software is and they need to be educated.
Today I found a sentence on the document sent by our (soon to be) client that I thought was funny: "Source code It will be very positive if the source code of the candidate aplication is available through a GPL or similar licence, to avoid the hijacking of our data". I loved it. I won't need to include my rant in favor of free software, but I think the sentence holds very true on a very common situation.
How many firms have their data hijacked? How many have been black mailed by their IT providers? I had the chance to know a situation where all the POS terminals from a nation wide commercial firm stopped working on a 2nd of January. They didn't renew their maintenance contract, and finally they ended up paying a big deal of money....
We can also talk about impossible migrations, and we have to crack access databases or even capture data from the printing port to be able to retrieve data from a Pervasive database.... just crazy!!
Anyway... like in any good hijack, there's people with Stockholm syndrome: they've been hijacked and are still happy.
Regards,
Pedro
This afternoon I was reviewing some docs in order to quote an OpenERP implementation. Usually, on every quote, we carefully explain what is free software, what are the licences involved and its rights involved, etc. Not everybody knows what free software is and they need to be educated.
Today I found a sentence on the document sent by our (soon to be) client that I thought was funny: "Source code It will be very positive if the source code of the candidate aplication is available through a GPL or similar licence, to avoid the hijacking of our data". I loved it. I won't need to include my rant in favor of free software, but I think the sentence holds very true on a very common situation.
How many firms have their data hijacked? How many have been black mailed by their IT providers? I had the chance to know a situation where all the POS terminals from a nation wide commercial firm stopped working on a 2nd of January. They didn't renew their maintenance contract, and finally they ended up paying a big deal of money....
We can also talk about impossible migrations, and we have to crack access databases or even capture data from the printing port to be able to retrieve data from a Pervasive database.... just crazy!!
Anyway... like in any good hijack, there's people with Stockholm syndrome: they've been hijacked and are still happy.
Regards,
Pedro
Secuestro
Hola,
Estaba esta tarde repasando algo de documentación para la elaboración de un presupuesto a un posible cliente. Normalmente en la elaboración de presupuestos dedicamos un espacio a una explicación sobre el software libre, la/las licencias implicadas y los derechos asociados a ellas. El desconocimiento del software libre es una resistencia que tenemos que vencer muchas veces.
Por ello, me ha hecho bastante gracia la siguiente frase en el documento enviado por nuestro (espero que futuro) cliente: " Código fuente Se valorará muy positivamente que el código fuente se encuentre disponible bajo una licencia libre de tipo GNU o similar, para impedir el secuestro de los datos de nuestras empresas". Me ha encantado. No sólamente porque me voy a ahorrar toda la perorata habitual sobre la idoneidad de utilizar software libre, sino porque expresa muy claramente una situación que desgraciadamente es muy habitual.
¿Cuántas empresas padecen el secuestro de sus datos? ¿A cuántas empresas se ha chantajeado y se chantajea por parte de sus proveedores de servicios informáticos?. Yo he tenido la desgracia de conocer algún caso donde dejaron de funcionar todas las TPVs de una cadena nacional de establecimientos un 2 de enero porque habían decidido rescindir el contrato de mantenimiento con su empresa habitual. La "broma" se saldó con un cuantioso rescate económico....
Podemos hablar también de cuando nos encontramos con migraciones "imposibles" y hay que tratar de rescatar datos crackeando bases de datos Access, o capturando la salida de datos de bases de datos Pervasive interceptando el puerto de la impresora.... pesadillas para no dormir.
En cualquier caso... como en todo buen secuestro, también hay gente con el síndrome de Estocolmo: cogidos por los testículos y todavía están agradecidos...
Un saludo,
Pedro
P.S- Todavía quedan plazas para nuestra formación técnica sobre OpenERP en Enero, del 19 al 23 en Pamplona. Si alguien tiene interés: info@acysos.com
Estaba esta tarde repasando algo de documentación para la elaboración de un presupuesto a un posible cliente. Normalmente en la elaboración de presupuestos dedicamos un espacio a una explicación sobre el software libre, la/las licencias implicadas y los derechos asociados a ellas. El desconocimiento del software libre es una resistencia que tenemos que vencer muchas veces.
Por ello, me ha hecho bastante gracia la siguiente frase en el documento enviado por nuestro (espero que futuro) cliente: " Código fuente Se valorará muy positivamente que el código fuente se encuentre disponible bajo una licencia libre de tipo GNU o similar, para impedir el secuestro de los datos de nuestras empresas". Me ha encantado. No sólamente porque me voy a ahorrar toda la perorata habitual sobre la idoneidad de utilizar software libre, sino porque expresa muy claramente una situación que desgraciadamente es muy habitual.
¿Cuántas empresas padecen el secuestro de sus datos? ¿A cuántas empresas se ha chantajeado y se chantajea por parte de sus proveedores de servicios informáticos?. Yo he tenido la desgracia de conocer algún caso donde dejaron de funcionar todas las TPVs de una cadena nacional de establecimientos un 2 de enero porque habían decidido rescindir el contrato de mantenimiento con su empresa habitual. La "broma" se saldó con un cuantioso rescate económico....
Podemos hablar también de cuando nos encontramos con migraciones "imposibles" y hay que tratar de rescatar datos crackeando bases de datos Access, o capturando la salida de datos de bases de datos Pervasive interceptando el puerto de la impresora.... pesadillas para no dormir.
En cualquier caso... como en todo buen secuestro, también hay gente con el síndrome de Estocolmo: cogidos por los testículos y todavía están agradecidos...
Un saludo,
Pedro
P.S- Todavía quedan plazas para nuestra formación técnica sobre OpenERP en Enero, del 19 al 23 en Pamplona. Si alguien tiene interés: info@acysos.com
jueves 18 de diciembre de 2008
Security / Seguridad
Hello again...
First a quick note on the next Technical Training in spanish. I hope it will soon appear here: we will be holding our second Technical Training week in Pamplona, Spain, the week starting on January the 19th. There are a few seats available so if you are interested, please contact us on info@acysos.com.
And now let's get to the main topic of this post: security.
Installing and running a production server with OpenERP is rather easy for anyone with a little knowledge about computers. However, make it a safe environment for your data is not something necessarily easy to achieve. Fortunately, from version 5.0 the developer of a new module has to think a little bit about security and define groups and access controls to the objects belonging to that module.
However, there are some security issues that have to be thought, for example, the user and permissions of the user launching the server process. Let's use an example to illustrate my point. Let's create a module with this code:
The code is an image and not complete, but anyone with a knowledge of OpenERP programming can quickly build a module that would allow to execute code on the server. We can see that the OpenERP administrator, someone with the ability to install modules, can do anything that the server launcher user can. For example, a user with those priviledges could perform operations on databases (create, drop, etc.), read/write files on the host operating system, etc.
This is something that should be thought about on any production environment: the user launching OpenERP has to have enough rights, but no more (never use 'root' for this). Also, we must be very, very careful on who belongs to the 'admin' group. A good security policy is something that takes some time to think, and some knowledge to implement. A full undestanding on how the application works is needed to be able to set a proper environment.
*******************************************************************
Hola de nuevo...
Lo primero una pequeña nota sobre la próxima formación técnica en castellano. Espero que pronto aparezca aquí, la semana entre el 19 y el 23 de Enero celebraremos una semana de Formación Técnica sobre OpenERP en Pamplona. Todavía queda alguna plaza por lo que si hay alguien interesado puede remitirse a info@acysos.com para más información.
Y ahora vamos al tema del post de hoy: la seguridad.
Cualquiera con un mínimo conocimiento de informática puede instalar y ejecutar un servidor de OpenERP y ponerlo en producción: no es difícil. Sin embargo, hacer que éste sea un entorno seguro para sus datos corporativos es harina de otro costal y no es necesariamente algo sencillo. Afortunadamente, desde la versión 5.0, OpenERP obliga a los desarrolladores a pensar un poco en la seguridad de sus módulos y a definir grupos y reglas de acceso para los objetos pertenecientes al módulo.
Pero hay otros elementos relativos a la seguridad que deben ser diseñados y ejecutados. Por ejemplo, los permisos del usuario de sistema que lanza el proceso servidor de OpenERP. Vamos a usar un pequeño ejemplo para ilustrar mi punto de vista. Creemos un módulo usando el código que se puede consultar en la imagen superior.
El código no está completo, pero cualquierea con un mínimo de conocimiento de cómo hacer un módulo de OpenERP puede crear un módulo que ejecute instrucciones en el servidor con el usuario que ha lanzado el proceso servidor de OpenERP. Un administrador de OpenERP, esto es, una persona con capacidad para instalar módulos, puede hacer cualquier cosa que el usuario propietario del proceso principal pueda hacer. Por ejemplo, un usuario administrador puede ejecutar operaciones en bases de datos (crear, borrar, etc.), leer y escribir archivos en el sistema operativo, etc.
En cualquier entorno de producción todo esto debe ser correctamente estudiado. El usuario que lanza OpenERP debe tener suficientes permisos, pero no más (nunca utilizar el usuario 'root'). De la misma manera, debemos tener muy claro quién pertenece al grupo de administradores de la aplicación: tienen un poder muy grande. Una buena política de seguridad no se improvisa y requiere ciertos conocimientos para su implementación. Un buen conocimiento en profundidad del funcionamiento de la aplicación será necesario para tener un entorno seguro y confiable para nuestros datos.
First a quick note on the next Technical Training in spanish. I hope it will soon appear here: we will be holding our second Technical Training week in Pamplona, Spain, the week starting on January the 19th. There are a few seats available so if you are interested, please contact us on info@acysos.com.
And now let's get to the main topic of this post: security.
Installing and running a production server with OpenERP is rather easy for anyone with a little knowledge about computers. However, make it a safe environment for your data is not something necessarily easy to achieve. Fortunately, from version 5.0 the developer of a new module has to think a little bit about security and define groups and access controls to the objects belonging to that module.
However, there are some security issues that have to be thought, for example, the user and permissions of the user launching the server process. Let's use an example to illustrate my point. Let's create a module with this code:
The code is an image and not complete, but anyone with a knowledge of OpenERP programming can quickly build a module that would allow to execute code on the server. We can see that the OpenERP administrator, someone with the ability to install modules, can do anything that the server launcher user can. For example, a user with those priviledges could perform operations on databases (create, drop, etc.), read/write files on the host operating system, etc.
This is something that should be thought about on any production environment: the user launching OpenERP has to have enough rights, but no more (never use 'root' for this). Also, we must be very, very careful on who belongs to the 'admin' group. A good security policy is something that takes some time to think, and some knowledge to implement. A full undestanding on how the application works is needed to be able to set a proper environment.
*******************************************************************
Hola de nuevo...
Lo primero una pequeña nota sobre la próxima formación técnica en castellano. Espero que pronto aparezca aquí, la semana entre el 19 y el 23 de Enero celebraremos una semana de Formación Técnica sobre OpenERP en Pamplona. Todavía queda alguna plaza por lo que si hay alguien interesado puede remitirse a info@acysos.com para más información.
Y ahora vamos al tema del post de hoy: la seguridad.
Cualquiera con un mínimo conocimiento de informática puede instalar y ejecutar un servidor de OpenERP y ponerlo en producción: no es difícil. Sin embargo, hacer que éste sea un entorno seguro para sus datos corporativos es harina de otro costal y no es necesariamente algo sencillo. Afortunadamente, desde la versión 5.0, OpenERP obliga a los desarrolladores a pensar un poco en la seguridad de sus módulos y a definir grupos y reglas de acceso para los objetos pertenecientes al módulo.
Pero hay otros elementos relativos a la seguridad que deben ser diseñados y ejecutados. Por ejemplo, los permisos del usuario de sistema que lanza el proceso servidor de OpenERP. Vamos a usar un pequeño ejemplo para ilustrar mi punto de vista. Creemos un módulo usando el código que se puede consultar en la imagen superior.
El código no está completo, pero cualquierea con un mínimo de conocimiento de cómo hacer un módulo de OpenERP puede crear un módulo que ejecute instrucciones en el servidor con el usuario que ha lanzado el proceso servidor de OpenERP. Un administrador de OpenERP, esto es, una persona con capacidad para instalar módulos, puede hacer cualquier cosa que el usuario propietario del proceso principal pueda hacer. Por ejemplo, un usuario administrador puede ejecutar operaciones en bases de datos (crear, borrar, etc.), leer y escribir archivos en el sistema operativo, etc.
En cualquier entorno de producción todo esto debe ser correctamente estudiado. El usuario que lanza OpenERP debe tener suficientes permisos, pero no más (nunca utilizar el usuario 'root'). De la misma manera, debemos tener muy claro quién pertenece al grupo de administradores de la aplicación: tienen un poder muy grande. Una buena política de seguridad no se improvisa y requiere ciertos conocimientos para su implementación. Un buen conocimiento en profundidad del funcionamiento de la aplicación será necesario para tener un entorno seguro y confiable para nuestros datos.
jueves 11 de diciembre de 2008
account_reverse
Hello,
I just commited a new module in launchpad. It's name is account_reverse and what it does is very simple: it allows to automatically reverse an account move.
Rationale:
Sometimes it's wise not to allow cancelling entries on journals. If there's a mistake, a reverse move has to be created (by hand), and the accounts be reconciled. This should not be done with moves that have some reconciled entries. We plan to use this feature for the spanish localization where there's a legal requirement to create a closing move (at the end of the year) and an opening move (at the begining). Using this technique to create the opening move as a reverse closing move and reconcile each other allows us to treat the reconcile accounts as normal balance accounts allowing us to perform the closing of the year on any future date. The standard year close has a problem with reconcile accounts if the closing is delayed.
Some implementation details...
As you probably know by now, the accounting module in OpenERP does NOT have a date on the account.move object, but rather let's the dates be on the move lines. I think this is not a very wise decision (it allows for inconsistent states of accounting on dates which are not end of period) but it is very straight forward to force that every move line inside a move have the same date... although this would cause some problems if you used centralized journals except... if the centralized journals only exist for daily periods.... but that's a whole new rant... about which we can talk some other day.... This makes sense because I introduced a related field "date" on the moves. It just picks the date of the first move line, which almost always (if you do your accounting right) should be the same for all of them.
The new module creates a new wizard on the account move that let's you, on a chosen a set of moves, choose journal, period, date (yes date) for the move and will create a set of cancelling moves for the first ones. You have 2 check boxes: reconcile if you want the moves to be reconciled and another one that will just copy the journal, period and date from every original move to its reverse move.
The wizard should not allow to perform a reversal of any move if any line is reconciled (you must unreconcile first), but will let you reverse posted moves.
Please test it and report the bugs ;)
UPDATE:
Fabien posted a comment saying that the date field has been moved to the account.move object. I think this is a very wise move. To avoid breaking things, the account.move.line object still has a date field, which is related to the former. The account_reverse module has been changed accordingly.
***************************************************************
Hola,
Acabo de hacer el commit de un nuevo módulo en launchpad. Se llama account_reverse y hace una cosa muy sencilla: permite invertir un asiento contable de forma automática.
Justificación:
A veces es sensato no permitir cancelar o borrar asientos en los diarios (pregunten a un auditor....). Si hay algún error contable, se debe corregir realizando el correspondiente contra-asiento a mano y conciliar ambos. Este proceso no debería realizarse sobre asientos que ya tengan líneas conciliadas. Pensamos utilizar este módulo para el proceso de localización española donde debemos realizar un asiento de cierre y otro de apertura. Usando ésta técnica para crear el asiento de apertura como un contra-asiento del de cierre y conciliando ambos, podemos tratar las cuentas a conciliar como cuentas normales de balance (cerrando por saldo contable a fin de año) y de esta manera realizar el cierre de forma precisa en cualquier momento del año. El proceso de cierre estándar de OpenERP tiene algunos problemas con las cuentas a conciliar si se realiza en fechas muy posteriores al fin real del ejercicio.
Algunos detalles de la implementación
Como probablemente sepan ya, el módulo de contabilidad de OpenERP no tiene una fecha en el asiento contable (por defecto, se entiende) sino que las fechas pertenecen a los apuntes. Creo que no es una decisión demasiado acertada (permite inconsistencias contable en fechas distintas a los fines de período), pero es bastante fácil forzar que todos los apuntes de un asiento tengan la misma... aunque esto causaría problemas si se usan diarios centralizados.... excepto si estos diarios sólo existen para períodos diarios.... pero ésto es otra historia de la que hablaremos otro día ;) Todo ésto viene a cuento porque en el módulo se añade un campo de tipo "related" que permite trabajar con fechas en los asientos. El campo no se muestra en pantalla (por defecto) pero el módulo lo utiliza.
El nuevo módulo crea un wizard sobre los asientos contables que permite sobre un conjunto de asientos, elegir diario, periodo y fecha (sí... fecha) para el asiento y crear el contra-asiento correspondiente con esos parámetros. Hay dos opciones adicionales: conciliar si se desea que los asientos se concilien a pares y otro casilla que copiará para cada asiento original el diario, periodo y fecha haciendo el contra-asiento en el mismo modo.
El wizard no permite realizar el contraasiento de ningún asiento si alguno de sus apuntes está conciliado (hay que desconciliar primero), pero permite invertir asientos validados.
Por favor... pruebenlo y reporten los bugs ;)
ACTUALIZACIÓN:
En un comentario a esta entrada, Fabien nos informa de que el campo date (fecha) ha sido agregado al objeto account.move (asiento contable). Para evitar romper las cosas, los apuntes contables (account.move.line) disponen de un campo fecha que no es sino una referencia al anterior. El módulo account_reverse ha sido actualizado para tener en cuenta estos cambios.
Un saludo,
Pedro
I just commited a new module in launchpad. It's name is account_reverse and what it does is very simple: it allows to automatically reverse an account move.
Rationale:
Sometimes it's wise not to allow cancelling entries on journals. If there's a mistake, a reverse move has to be created (by hand), and the accounts be reconciled. This should not be done with moves that have some reconciled entries. We plan to use this feature for the spanish localization where there's a legal requirement to create a closing move (at the end of the year) and an opening move (at the begining). Using this technique to create the opening move as a reverse closing move and reconcile each other allows us to treat the reconcile accounts as normal balance accounts allowing us to perform the closing of the year on any future date. The standard year close has a problem with reconcile accounts if the closing is delayed.
Some implementation details...
As you probably know by now, the accounting module in OpenERP does NOT have a date on the account.move object, but rather let's the dates be on the move lines. I think this is not a very wise decision (it allows for inconsistent states of accounting on dates which are not end of period) but it is very straight forward to force that every move line inside a move have the same date... although this would cause some problems if you used centralized journals except... if the centralized journals only exist for daily periods.... but that's a whole new rant... about which we can talk some other day.... This makes sense because I introduced a related field "date" on the moves. It just picks the date of the first move line, which almost always (if you do your accounting right) should be the same for all of them.
The new module creates a new wizard on the account move that let's you, on a chosen a set of moves, choose journal, period, date (yes date) for the move and will create a set of cancelling moves for the first ones. You have 2 check boxes: reconcile if you want the moves to be reconciled and another one that will just copy the journal, period and date from every original move to its reverse move.
The wizard should not allow to perform a reversal of any move if any line is reconciled (you must unreconcile first), but will let you reverse posted moves.
Please test it and report the bugs ;)
UPDATE:
Fabien posted a comment saying that the date field has been moved to the account.move object. I think this is a very wise move. To avoid breaking things, the account.move.line object still has a date field, which is related to the former. The account_reverse module has been changed accordingly.
***************************************************************
Hola,
Acabo de hacer el commit de un nuevo módulo en launchpad. Se llama account_reverse y hace una cosa muy sencilla: permite invertir un asiento contable de forma automática.
Justificación:
A veces es sensato no permitir cancelar o borrar asientos en los diarios (pregunten a un auditor....). Si hay algún error contable, se debe corregir realizando el correspondiente contra-asiento a mano y conciliar ambos. Este proceso no debería realizarse sobre asientos que ya tengan líneas conciliadas. Pensamos utilizar este módulo para el proceso de localización española donde debemos realizar un asiento de cierre y otro de apertura. Usando ésta técnica para crear el asiento de apertura como un contra-asiento del de cierre y conciliando ambos, podemos tratar las cuentas a conciliar como cuentas normales de balance (cerrando por saldo contable a fin de año) y de esta manera realizar el cierre de forma precisa en cualquier momento del año. El proceso de cierre estándar de OpenERP tiene algunos problemas con las cuentas a conciliar si se realiza en fechas muy posteriores al fin real del ejercicio.
Algunos detalles de la implementación
Como probablemente sepan ya, el módulo de contabilidad de OpenERP no tiene una fecha en el asiento contable (por defecto, se entiende) sino que las fechas pertenecen a los apuntes. Creo que no es una decisión demasiado acertada (permite inconsistencias contable en fechas distintas a los fines de período), pero es bastante fácil forzar que todos los apuntes de un asiento tengan la misma... aunque esto causaría problemas si se usan diarios centralizados.... excepto si estos diarios sólo existen para períodos diarios.... pero ésto es otra historia de la que hablaremos otro día ;) Todo ésto viene a cuento porque en el módulo se añade un campo de tipo "related" que permite trabajar con fechas en los asientos. El campo no se muestra en pantalla (por defecto) pero el módulo lo utiliza.
El nuevo módulo crea un wizard sobre los asientos contables que permite sobre un conjunto de asientos, elegir diario, periodo y fecha (sí... fecha) para el asiento y crear el contra-asiento correspondiente con esos parámetros. Hay dos opciones adicionales: conciliar si se desea que los asientos se concilien a pares y otro casilla que copiará para cada asiento original el diario, periodo y fecha haciendo el contra-asiento en el mismo modo.
El wizard no permite realizar el contraasiento de ningún asiento si alguno de sus apuntes está conciliado (hay que desconciliar primero), pero permite invertir asientos validados.
Por favor... pruebenlo y reporten los bugs ;)
ACTUALIZACIÓN:
En un comentario a esta entrada, Fabien nos informa de que el campo date (fecha) ha sido agregado al objeto account.move (asiento contable). Para evitar romper las cosas, los apuntes contables (account.move.line) disponen de un campo fecha que no es sino una referencia al anterior. El módulo account_reverse ha sido actualizado para tener en cuenta estos cambios.
Un saludo,
Pedro
viernes 5 de diciembre de 2008
account_regularization
Hi all,
Last week we finished our first Technical Training Week in Pamplona Spain, and I dare to say that it was a success. We even found 2 new bugs on OpenObject 5 !! We will be holding similar events in the future, so... stay tuned!
On the other hand we are working also on the localization effort (altogether with Jordi and Santiago). Today we created a new module in extra-addons named account_regularization. This module has existed for a while in the 4.2 extra-addons repository, but now it has been migrated to support the forthcoming OpenERP 5. This is a very interesting module for us. Let me briefly explain what it does:
It creates a new object on the system called account_regularization. This object will let the user add a set of view accounts to a list. When a wizard is called it will look for all the child accounts, and create a balance cancelling entry for each one of them. The remaining amount will be sent to a selected debit or credit account.
What's the use for this module?. For example tax declarations. You can add to the list the parent view account for all the tax collected and tax paid accounts, and it will create a move sending the difference to a Tax due account. It can also be used to create a 'Profit and Loss' move as it is mandatory in some countries.
It can work on a period base calculation or in between dates calculations.
Please, test the module and send us any suggestion/bug/whatever.
*********************************************************
Hola a todos,
La semana pasada completamos nuestra primera semana de Formación Técnica en Pamplona y me atrevería a decir que fue todo un éxito. ¡¡ Incluso localizamos un par de bugs en OpenERP 5!! Dentro de poco volveremos a convocar otro curso ya que lamentablemente no pudimos atender todas las peticiones. ¡Permanezcan atentos!
Por otro lado, seguimos con el trabajo de localización (junto con Jordi y Santiago). Hoy hemos subido un módulo nuevo al repositorio de extra-addons llamado account_regularization. Este módulo lleva ya un tiempo en el repositorio de módulos extra de la versión 4.2, pero ahora ha sido actualizado para funcionar también con la versión de OpenERP 5. Para nosotros éste es un módulo bastante interesante. Explico aquí brevemente en qué consiste.
Crea un nuevo objeto en el sistema llamado account.regularization. Este objeto permite al usuario añadir una serie de cuentas tipo vista a una lista. Después, cuando se invoca un wizard, se rastrean todas las cuentas hijas de las anteriores y se crea un asiento que salda todas esas cuentas, llevando la diferencia a la cuenta debe/haber indicada. En resumen... hace una regularización contable ;)
¿Para qué queremos este módulo?. Por ejemplo para las declaraciones de IVA. Bastaría con añadir las cuentas vista con códigos 477 y 472 e indicar en las cuentas debe y haber las correspondientes a Hacienda Pública Deudora o Acreedora. También vamos a utilizar el módulo para la generación del asiento de regurlarización de pérdidas y ganancias.
Una característica interesante del módulo es que permite saldar las cuentas a nivel de períodos o de fechas.
Por favor, no duden en enviarnos cualquier tipo de sugerencia, bug o mejora.
Un saludo,
Pedro
Last week we finished our first Technical Training Week in Pamplona Spain, and I dare to say that it was a success. We even found 2 new bugs on OpenObject 5 !! We will be holding similar events in the future, so... stay tuned!
On the other hand we are working also on the localization effort (altogether with Jordi and Santiago). Today we created a new module in extra-addons named account_regularization. This module has existed for a while in the 4.2 extra-addons repository, but now it has been migrated to support the forthcoming OpenERP 5. This is a very interesting module for us. Let me briefly explain what it does:
It creates a new object on the system called account_regularization. This object will let the user add a set of view accounts to a list. When a wizard is called it will look for all the child accounts, and create a balance cancelling entry for each one of them. The remaining amount will be sent to a selected debit or credit account.
What's the use for this module?. For example tax declarations. You can add to the list the parent view account for all the tax collected and tax paid accounts, and it will create a move sending the difference to a Tax due account. It can also be used to create a 'Profit and Loss' move as it is mandatory in some countries.
It can work on a period base calculation or in between dates calculations.
Please, test the module and send us any suggestion/bug/whatever.
*********************************************************
Hola a todos,
La semana pasada completamos nuestra primera semana de Formación Técnica en Pamplona y me atrevería a decir que fue todo un éxito. ¡¡ Incluso localizamos un par de bugs en OpenERP 5!! Dentro de poco volveremos a convocar otro curso ya que lamentablemente no pudimos atender todas las peticiones. ¡Permanezcan atentos!
Por otro lado, seguimos con el trabajo de localización (junto con Jordi y Santiago). Hoy hemos subido un módulo nuevo al repositorio de extra-addons llamado account_regularization. Este módulo lleva ya un tiempo en el repositorio de módulos extra de la versión 4.2, pero ahora ha sido actualizado para funcionar también con la versión de OpenERP 5. Para nosotros éste es un módulo bastante interesante. Explico aquí brevemente en qué consiste.
Crea un nuevo objeto en el sistema llamado account.regularization. Este objeto permite al usuario añadir una serie de cuentas tipo vista a una lista. Después, cuando se invoca un wizard, se rastrean todas las cuentas hijas de las anteriores y se crea un asiento que salda todas esas cuentas, llevando la diferencia a la cuenta debe/haber indicada. En resumen... hace una regularización contable ;)
¿Para qué queremos este módulo?. Por ejemplo para las declaraciones de IVA. Bastaría con añadir las cuentas vista con códigos 477 y 472 e indicar en las cuentas debe y haber las correspondientes a Hacienda Pública Deudora o Acreedora. También vamos a utilizar el módulo para la generación del asiento de regurlarización de pérdidas y ganancias.
Una característica interesante del módulo es que permite saldar las cuentas a nivel de períodos o de fechas.
Por favor, no duden en enviarnos cualquier tipo de sugerencia, bug o mejora.
Un saludo,
Pedro
lunes 10 de noviembre de 2008
Technical training / Formación técnica
It's been a long time since my last entry. This is in part because of the commitment to write in two languages and also because this end of year is very, very active.
We have been working on the spanish localization for version 5.0 and I'm glad to say that on my system almost everything is working alright. Some of the functionalities provided by the former localization project (creation of the chart of accounts, with any number of digits based on a template) is now provided by default, so some of the work just means keeping on track with the new developments.
I'm also writing a review of the account_asset module to be published here, but I got stuck in the middle. I hope to finish it soon and also a new account_renumber module that will be very helpful on some countries for the end of the year treatments.
If this doesn't sound enough, I'm also glad to announce our first Technical Training to be held on our offices in Pamplona (northern Spain). You can contact me here for more info if you are interested. There are a few places available.
***********************************************************
Han pasado unos cuantos días desde mi última entrada. La exigencia de escribir en dos idiomas es algo que da cierta pereza, además de la cantidad de trabajo que se nos está acumulando a final de año.
Hemos estado trabajando en la localización española para la versión 5.0 y estoy muy satisfecho porque en mi sistema funciona prácticamente todo sin problemas. Todavía hay que validar algunas cuestiones pero esperamos liberar todo en breve. Algunas funcionalidades aportadas por la anterior localización (como la creación del plan de cuentas con un número de dígitos determinado) están ahora presentes por defecto, de modo que parte del trabajo sencillamente consiste en mantener el código al día.
Estoy escribiendo también un artículo sobre el módulo de gestión de activos 'account_asset', pero lo tengo a medias. También hemos estado trabajando en un módulo de renumeración de asientos contables que será de utilidad para muchas empresas de cara al cierre de ejercicio.
Si todo lo anterior no parece mucho, me congratulo en anunciar nuestro primer curso de Formación Técnica sobre OpenERP, que tendrá lugar en Pamplona entre los días 24 y 28 de Noviembre. Si alguien está interesado todavía quedan algunas plazas. Me podeis contactar aquí mismo.
Un saludo,
Pedro
We have been working on the spanish localization for version 5.0 and I'm glad to say that on my system almost everything is working alright. Some of the functionalities provided by the former localization project (creation of the chart of accounts, with any number of digits based on a template) is now provided by default, so some of the work just means keeping on track with the new developments.
I'm also writing a review of the account_asset module to be published here, but I got stuck in the middle. I hope to finish it soon and also a new account_renumber module that will be very helpful on some countries for the end of the year treatments.
If this doesn't sound enough, I'm also glad to announce our first Technical Training to be held on our offices in Pamplona (northern Spain). You can contact me here for more info if you are interested. There are a few places available.
***********************************************************
Han pasado unos cuantos días desde mi última entrada. La exigencia de escribir en dos idiomas es algo que da cierta pereza, además de la cantidad de trabajo que se nos está acumulando a final de año.
Hemos estado trabajando en la localización española para la versión 5.0 y estoy muy satisfecho porque en mi sistema funciona prácticamente todo sin problemas. Todavía hay que validar algunas cuestiones pero esperamos liberar todo en breve. Algunas funcionalidades aportadas por la anterior localización (como la creación del plan de cuentas con un número de dígitos determinado) están ahora presentes por defecto, de modo que parte del trabajo sencillamente consiste en mantener el código al día.
Estoy escribiendo también un artículo sobre el módulo de gestión de activos 'account_asset', pero lo tengo a medias. También hemos estado trabajando en un módulo de renumeración de asientos contables que será de utilidad para muchas empresas de cara al cierre de ejercicio.
Si todo lo anterior no parece mucho, me congratulo en anunciar nuestro primer curso de Formación Técnica sobre OpenERP, que tendrá lugar en Pamplona entre los días 24 y 28 de Noviembre. Si alguien está interesado todavía quedan algunas plazas. Me podeis contactar aquí mismo.
Un saludo,
Pedro
Suscribirse a:
Entradas (Atom)
Entradas
