A continuación, durante este articulo se analizaran las tablas y columnas de OpenERP, como por ejemplo: reporting, data mining, etc.
En este post vamos a ver como podemos saber en que tabla y que campo de la base de datos se guardan los datos de cada documento de OpenERP desde el cliente web.
En OpenERP cualquier dato con el que podemos trabajar es descrito por los “Objetos”, si eres programador sabrás de que hablo.
Para saber los campos que tiene cada documento lo que necesitamos es ver el objeto correspondiente. En OpenERP por lo general los nombres de los objetos se corresponden con los nombres de las tablas, y los campos del objeto con los campos de la tabla.
Vamos a ver como podemos ver en que tabla se guardan los datos de los pedidos de ventas, para ello entramos en el cliente web de OpenERP y nos dirigimos a un pedido de ventas cualquiera.
Si situamos en ratón en la zona inferior a la izquierda sobre [PERSONALIZAR] nos aparecen varias opciones, clickamos sobre PERSONALIZAR OBJETOS para ver el Objeto que representa el pedido de ventas.
Si te fijas en el nombre del objeto es “sale.order”, el nombre de la tabla será el mismo pero cambiando el punto “.” por un guión bajo “_”, sale_order.
En la ventana del objeto te viene la lista de todos los campos, y el tipo del que son, si te fijas en el campo order_line, es del tipo one2many, esto quiere decir que este campo no esta en es la tabla sale_order, si no que indica que hay otra tabla que referencia a sale_order, sale_order sería el maestro y la otra tabla el detalle. Para saber la tabla en la que estan las lineas clickamos sobre order_line y vemos lo siquiente:
Vemos que pone “Relación objeto: sale.order.line” esto quiere decir que la tabla es sale_order_line, también pone “Campo relación: order_id” este es el campo de la tabla sale_order_line que apunta a sale_order.
Con esto podemos hacernos una idea de la estructura que tiene la base de datos de OpenERP, para hacer informes, migraciones, cubos olap, minería de datos….
Tras un largo tiempo de desarrollo, finalmente se ha publicado la versión Release Candidate 1 de OpenERP 6. Ya podemos probar la que será la siguiente versión de OpenERP en la sección de descargas (All in One para Windows) o en www.openerp.com/downloads para el resto de versiones. Ahora es tarea de la comunidad española realizar las adaptaciones necesarias para la correcta migración de la localización. Los compañeros de Pexego han estado revisando la versión 6.0 RC1 (y nos ha gustado bastante), y han elaborado un pequeño resumen para resolver las siguientes preguntas: ¿qué cambios en la versión 6.0 afectan a la localización española?, ¿qué partes de la localización funcionan ya en la 6.0?, ¿qué trabajo está pendiente?
Contabilidad general:
Hecho: –
Falta:
Secuencias diferenciadas en facturas: En la 6.0, por defecto, la numeración de facturas se basa en la de los asientos. Es decir: el campo “número” de la factura, muestra el campo “número” del asiento. Si creamos una factura (asiento y factura 1), y la pagamos (asiento 2), la siguiente factura tendrá número 3 (asiento 3). Al menos en España el comportamiento de la 5.0 (con secuencias separadas de facturas y asientos, siendo además configurables por diario) es más correcto. En la 6.0 será necesario implementar ese comportamiento en un módulo aparte.
Plan de cuentas:
Hecho:
Migrado el plan a la 6.0.
Ahora se usa el nuevo campo “report_type” de los tipos de cuenta, y el tipo de cuenta “liquidity” en las cuentas de bancos/caja.
Desaparecen los grupos de impuestos (tax_group).
Corregida cuenta padre para las cuentas bancarias (572 en lugar de 572…0).
Falta:
Las plantillas de planes de cuentas sólo permiten una cuenta raíz para todas las cuentas bancarias (572), pero en España para las cuentas de caja usamos otra (570). Sería bueno que OpenERP introdujese la opción de definir cuentas raíz diferentes para cajas y bancos.
Informes legales:
Hecho:
Los informes de Balance y PyG (basados en account_balance_reporting) funcionan correctamente en la 6.0 RC1.
Funcionan los nuevos reportes de Balance y PyG de OpenERP 6.0 (no usan el formato oficial español, pero son interesantes: el PyG por ejemplo muestra a izquierda las pérdidas y a derecha las ganancias).
Falta:
Los informes adicionales, basados en account_financial_report (listado de facturas, impresión del diario, balance completo), no funcionan dado que la instalación del módulo falla (esto no sería mucho trabajo). Por otro lado el módulo debería refactorizarse para aplicar las mejoras en reportes de la versión 6.0.
Operaciones de fin de año:
Hecho:
Renumerar los asientos funciona, pero no actualiza el número de factura relacionado (pero, en cualquier caso, ese comportamiento [mismo número para factura y asiento] no es válido para España)
Falta:
El asistente de cierre de ejercicio español necesita adaptaciones, actualmente falla la instalación.
La creación de ejercicios y periodos fiscales debería ser sobreescrita (http://bit.ly/a6rbgv), para generar automáticamente los periodos especiales usados en España (apertura, pyg, cierre).
Gestión de bancos y caja:
Hecho: –
Falta:
La exportación de remesas no funciona: la instalación del módulo account_payment_extension falla, además han desaparecido las formas de pago en la 6.0.
La importación y reconciliación de extractos bancarios no funciona: ahora las líneas de extracto se basan en “vouchers” (~ recibos), con lo cual la implementación de la 5.0 debe ser reescrita.
Localización general:
Hecho:
El módulo de topónimos funciona correctamente en la 6.0 RC1 (con un par de retoques en la interfaz).
Falta:
El resto de módulos de personalización de empresas, los de importación de datos por defecto y los de instalación y preconfiguración aun están pendientes de revisión.
Ventajas de utilizar formatos adecuados a los estándares
“Los Estándares Abiertos son el corazón de Internet y mucho de lo que ha surgido para funcionar en esta creciente plataforma global. La esencia de los estándares abiertos es la interoperabilidad. La adopción de estándares abiertos conduce interfuncionamiento de productos que compiten entre si. Por cada indicador, los estándares abiertos reducen las barreras a la entrada en los mercados existentes y aumentan las opciones del consumidor.”
Vint Cerf, Chief Internet Evangelist, Google
Una de las garantías de usar software libre es su apuesta por estándares abiertos.
Los desarrollos suelen utilizan motores o bases de datos para funcionar, y el software libre siempre busca la estandarización de la conectividad entre los datos. Así, como la ejecución multiplataforma de los programas.
Estas son las razones por las que debería adoptar formatos abiertos:
01Garantizar accesibilidad y perpetuidad de los datos: la información estará siempre accesible para todos los usuarios y desde cualquier plataforma.
02Garantizar una completa transparencia al contenido de los archivos.
03Limitar la propagación de virus: adoptar formatos abiertos aumenta la seguridad y reduce drásticamente el riesgo de contaminación.
04Promover diversidad en la interoperabilidad de la comunicación electrónica.
Si bien no se puede forzar a que todo el mundo use Software Libre, si se debería intentar que todos los intercambios de datos utilicen un formatos estándar.
Debido a los múltiples problemas de ya han habido en el pasado, este dato está siendo tomado en cuenta por muchos gobiernos, que ya han adoptado estándares libres para la intercomunicación de documentos.
Los formatos estándar permiten que cualquiera pueda crear un programa que lea y/o escriba en dicho formato.
Y lo más importante es, que asegura que cualquier persona tendrá siempre un software disponible para la lectura de dicho formato, sin necesidad de imponer programas concretos, para poder acceder y modificar la información contenida en dichos archivos.
La proliferación de los estándares libres de intercambio de información terminaría con las dictaduras de las empresas que mantienen cautivos a sus usuarios, y que crean formatos que solo pueden ser leídos y/o escritos correctamente con su propio software, o con el software que ellos autorizan.
La situación anteriormente descrita, es un abuso por parte de los creadores de esos formatos. Ya que, se adueñan del derecho a conocer como acceder a la información contenida en esos archivos, y conspira contra la perdurabilidad y compatibilidad de los datos.
Además, no aseguran de modo alguno su continuidad de lectura y escritura en el futuro y/o por diferentes plataformas de acceso.
Conclusiones
Últimamente, grandes empresas se han sumado a la corriente que intenta popularizar los formatos estándares libres. Entre ellas IBM, Mozilla, Google, Intel, Sun Microsystems, Adobe o Novell.
Aunque algunas de estas empresas desarrollan software privativo, también se preocupan por promover los estándares abiertos, en favor de la universalización del acceso a la información, sin la obligación de recurrir a software privativo para ello.
Actualmente los estándares libres están viviendo un gran impulso debido a que redunda en beneficios para todos, y sin duda la universalización de formatos abiertos es el presente y, obligatoriamente el futuro de los intercambios de información.
Artículo modificado CC. Original extraído de gnulinuxlibre.net
Además, le adjuntamos el enlace a nuestra web donde podrá encontrar más información de su interés, haciendo clic aquí.
Un consultor de OpenERP participa proceso comercial, pero sobretodo sus especialidades son el desarrollo, consultoría y formación de soluciones de gestión.
La gran mayoría de las empresas grandes; que se dedican a dar soluciones cerradas se han visto obligadas a fusionarse o incluso a cerrar como consecuencia de la situación económica actual. De hecho las empresas locales que ofrecen servicios de software libre suelen ser de un tamaño inferior.
Cualquier proyecto de implantación de un ERP debe ser realizado por un grupo de personas con diferentes roles y habilidades técnicas y funcionales, y trabajando con Software Libre; puede ser bastante común que algunas de ellas estén involucradas desde el primer momento.
Suelen ser consultores profesionales cualificados, que a pesar de colaborar en la fase de preventa, pero sobretodo sus especialidades son el desarrollo, consultoría y formación de soluciones de gestión.
Por este motivo puede encontrar una brecha entre las presentaciones comerciales de las grandes empresas con la exclusividad de un producto.
Cuya única finalidad será cerrar la venta, y posiblemente el comercial ya quede desvinculado de su cuenta llegados a ese punto y las empresas locales de menor tamaño; que pueden decidir o no emplear su tiempo ‘gratuitamente’ para sus clientes potenciales, dependiendo de la seguridad que tengan de conseguir su implantación.
Dado que OpenERP está a disposición de quien lo quiera descargar y probar, y nadie tiene la exclusiva sobre su distribución, el enfoque de presentaciones suele ser completamente diferente.
Dependiendo de la magnitud de su proyecto, quizás pueda encontrar; diferencias significativas como comerciales dedicados, proyecciones de vídeos muy preparados y emotivos en grandes pantallas o un seguimiento casi agobiante de su cuenta.
Con soluciones más avanzadas técnicamente y funcionalmente y mucho más competitivas, no es necesario repetir el mismo discurso que las alternativas privativas.
En este artículo, hablaremos sobre la financiación colectiva y las ventajas comunes del software libre.
En junio de 2005, Adobe, la compañía creadora del conocido programa de retoque de imágenes Photoshop, anunció su decisión de poner a disposición de sus usuarios y gratuitamente, un repositorio de imágenes (1).
Esta acción, contraria a los intereses de los fotógrafos profesionales, supuso que una agrupación francesa de más de 1.500 de ellos, denominada Unión de Fotógrafos Creadores (UPC).
De hecho, anunciarán un boicot a los productos de Adobe y amenazaran con migrar a una herramienta libre de similares características, aunque todavía inferior tecnológicamente, llamada The Gimp.
Lamentablemente, al final Adobe cedió a las presiones y decidió no publicar su repertorio de imágenes, con lo que la amenaza de UPC no se cumplió. Sin embargo, supongamos que finalmente se hubiera hecho, y analicemos las ventajas que hubieran tenido:
Dato 1. El coste medio de una licencia de Photoshop es de 1.000 euros, quizá algo menor adquirida masivamente a través de organizaciones de profesionales.
Dato 2. Cada vez que Adobe actualiza su software, e introduce mejoras, es casi obligatorio para un profesional actualizar, por lo que vuelve a desembolsar la cantidad de dinero de la licencia si quiere mantenerse actualizado.
Dato 3. El total de las licencias de uso sirve para engrosar los beneficios de Adobe, sin repercutir mejoras o beneficios a sus usuarios, y sin importar que sean uno o un millón.
Supuesto Photoshop vs. Gimp.
Supongamos que a través de alguna agrupación, del tipo UPC, se reúnen fondos para mejorar e impulsar el desarrollo de The Gimp.
Se utiliza el mismo dinero que para las licencias de Photoshop o incluso menos para contratar un grupo de desarrollo (2) o se paga a los desarrolladores originales para que realicen las mejoras solicitadas.
Se obtienen las mejoras solicitadas, y el programa, que sigue a disposición de todo el que quiera utilizarlo, ya cumple con los requisitos necesarios de los usuarios profesionales.
Si en lugar de simplemente una agrupación de fotógrafos, fueran organizaciones de profesionales de varios países; el potencial de crecimiento sería enorme, así como su capacidad para desbancar a su “rival” propietario en poco tiempo.
Este caso, que puede utilizarse para otros tantos desarrollos libres. 25 palabras, que es más del máximo recomendado de 25%. Trata de acortar las frases.Este caso, que puede utilizarse para otros tantos desarrollos libres.
Puede ilustrar cómo sin realizar más inversión de la actual (simplemente reorientándola) se podría desbancar algunos “programas estrella” de software propietario.
Se llevaría a cabo, mediante la unión de los profesionales, y las mejoras serían puestas a disposición de todos de manera libre y gratuita.
En software libre, cuanto mayor sea el número de usuarios y comunidad, mayor es su sostenibilidad y continuidad.
(2) Se habla de grupos de desarrollo para realizar los cambios solicitados.
Aun cuando para un desarrollo de estas dimensiones sería un grupo de profesionales cualificados mucho más amplio; incluyendo, los propios profesionales del sector que serían los que generaran las especificaciones del programa y realizaran las pruebas pertinentes.
Además, le adjuntamos el enlace a nuestra web donde podrá encontrar más información de su interés sobre; financiación colectiva y ventajas comunes del software libre, haciendo clic aquí.
Para empezar, si el SL tiene tantas ventajas, como se han mencionado anteriormente, ¿Cómo es posible que aún se utilicen soluciones propietarias en algunos casos, en lugar del software libre?
La cantidad de dinero que se genera con el pago de licencias privativas, muchas veces lleva asociado que las grandes empresas de software privativo creen departamentos o ‘lobbies’ que trabajen casi en exclusiva para desprestigiar el SL y conseguir contratas públicas (y privadas).
Dado que el modelo de negocio del SL es descentralizado y tradicionalmente se ha gestionado desde las empresas locales, no es fácil llevar ese conocimiento a las clases políticas, en su mayoría ignorantes informáticamente hablando, y es fácil dejarse influenciar por empresas de renombre para la toma final de decisiones.
De hecho, afortunadamente la situación mejora día a día, pues muchos gobiernos ya han sufrido las consecuencias de no apostar por estándares (formatos no estándar, actualización forzosa de versiones, dependencia tecnológica, sistemas inseguros…). Y están cambiando sus infraestructuras y adaptándolas a estándares abiertos y libres.
Algunos ejemplos de resoluciones institucionales y acciones legislativas
National Advisory Council on Innovation, South Africa
Por último, el software libre y los formatos abiertos, en constante expansión se utiliza y expande en la medida en que se conocen sus ventajas, y no hay ningún interés contrario a él haciendo presión
Además le adjuntamos el enlace a nuestra web, donde podrá encontrar más información sobre el software libre haciendo clic aquí.
A continuación, a lo largo de este artículo se estudiara si un software libre puede convertirse en uno de uso propietario.
La licencia de uso es otorgada por el propietario del software, o mejor dicho, de su copyright. En el supuesto de que un desarrollo utilice un 100% de código propio, y su propietario decida cambiar la licencia de uso.
La conversión es perfectamente legal (no se podría realizar cuando se ha utilizado código de otros con licencia libre).
Teóricamente, el software licenciado como libre se quedaría ‘estancado’ tras el cambio de licencia; mientras que sus desarrolladores trabajarían en continuar el código con una licencia privativa.
Este hecho que realmente no se ha dado en muchas ocasiones, suele derivar, si la calidad del programa lo merece, en que otra entidad se haga cargo de mantener la continuidad, y se cree un segundo desarrollo paralelo y abierto, tal y como se ha comentado en el ejemplo de Borland.
¿Podría OpenERP cerrar el código y cobrar por licencias?
Podría ocurrir, aunque no es probable. Precisamente el éxito del producto reside en su filosofía abierta, y en la multitud de apoyos y riqueza que recibe de la comunidad de empresas que lo distribuyen y utilizan.
OpenERP está programado en un lenguaje interpretado, y sería imposible, sin rehacerlo desde cero, no entregar el código al distribuir el programa.
Además existe una organización sin ánimo de lucro mantenida por la comunidad de desarrolladores a lo largo del mundo, llamada Oca (Odoo Community Association). La cual, se encarga de organizar el trabajo colaborativo y defender los intereses y la sostenibilidad de los desarrollos comunitarios; trabajando activamente en colaborar en la definición de hojas de ruta (roadmaps) de nuevas versiones con la empresa desarrolladora y su implementación.
OpenERP (Odoo) es uno de los claros ejemplos de software libre, hecho y pensado como libre desde su concepción.
Es fundamental que podamos consensuar los términos a utilizar en las traducciones. Que cada cual utilize una traducción personalizada porque se encuentra más cómodo con los términos que se manejan en esta nos trerá problemas a la larga y dificultará el desarrollo de documentación localizada en el futuro. Por estos mótivos esta página pretende ser un lugar donde comentar y proponer alternativas en relación a los términos utilizados en la traducción de OpenERP.
Se ha utilizado acentos, tanto en mayúsculas como en minúsculas. Esto no acarrea ningún tipo de problema codificando en UTF-8 el fichero de la traducción. Además de ser normativa ortográfica, permite automatizar la traducción a otros idiomas latinos como catalán y gallego.
Sólo se utilizan mayúsculas al incio de la frase/texto o cuando es nombre propio. El uso de mayúsculas en la primera letra de cada palabra está acceptado en inglés pero no en castellano. Además los textos quedan ligeramente más cortos y se facilita la lectura. Se hace una excepción con la abreviaciones (p.e. LdM).
Las acciones son verbos en infinitivo (p.e. Cancelar). Los estados son verbos en participio (p.e. Cancelado).
En las ayudas o sugerencias se usa la forma verbal de usted, sin poner nunca la palabra usted. Por ejemplo: Marque esta opción para poder cancelar asientos en este diario. Seleccione Bajo pedido para …
Se ha intentado mantener la longitud de los textos originales, aunque es imposible pues en la mayoría de casos las traducciones al castellano son más largas. Se ha testeado la mayoría de menús, vistas, formularios e informes para comprobar que no aparezcan textos demasiado largos.
A veces algunos textos no aparecen traducidos porqué en el código fuente de OpenERP no se han indicado que son traducibles (normalmente mensajes de aviso dentro del código Python, podrían catalogarse de bugs del programa).
Lista alfabéticamente ordenada de las traducciones utilizadas. Se ha intentado utilizar un registro de castellano de España estándar con vocablos de gestión empresarial. Cuando una expresión se ha traducido de dos o más formas diferentes se han separado con comas. Las listas de acciones (verbos infinitivos) y vocabulario método scrum se han separado al final.
INGLÉS -> ESPAÑOL
account -> cuenta, contabilidad
account chart -> plan de cuentas
account move -> asiento (o apunte)
account move line -> movimiento, mov. (o partida)
account owner -> titular de la cuenta
amount -> importe
assignation -> asignación
attendances -> servicios
balance -> balance o saldo
balance -> saldo pendiente (en formas de pago)
balance sheet -> balance
bank account -> cuenta bancaria
bank statement -> extractos bancarios
BOM -> LdM (Bill of Material -> Lista de Materiales, hay que mantenerlo abreviado)
case -> caso
chart -> gráfico (de pastel, de barras, de líneas), resumen (chart muestra muchas veces tablas de resumen)
chart of accounts -> plan contable
company -> compañía (es la propia empresa)
credit -> haber
credit balance -> saldo acreedor
custom -> personalizado
dashboard -> tablero
deadline -> fecha límite
debit -> debe
debit balance -> saldo deudor
default -> por defecto
deferral -> cierre
done -> realizado
email -> email, correo electrónico
event -> evento
file -> archivo
fiscal year -> ejercicio fiscal
follow-up -> seguimiento
general ledger -> libro mayor
goods -> material
grid -> tabla
helpdesk -> helpdesk (¿Mejor traducirlo como centro de soporte?)
history -> historial
HR -> RRHH
in progress -> en proceso
item -> detalle, elemento
location -> ubicación
lot -> lote
meeting -> reunión
Ok -> Aceptar
opened -> abierto
order -> orden o pedido. Una orden o pedido puede estar, por ejemplo, en estado borrador (presupuesto), confirmada (comanda), enviada (albaran), facturada (factura))
Order description está traducido como Descripción de la order. La traducción me parece apropiada pero no la etiqueta original. Order description no se utiliza para introducir una descripción de la orden de venta sino que tiene asignada una secuencia. Propongo utilizar Nº orden venta o Ref orden venta
Untaxed Amount está traducido como Importe sin impuestos. Propongo utilizar Base imponible
El estado In progress está traducido como En progreso. Propongo utilizar En proceso
Packing name está traducido como Nombre del paquete. Propongo utilizar Nº albarán o Ref albarán
En el módulo stock (Control inventario), el término Reordering Policy está traducido como Política de volver a ordenar. Propongo utilizar Política de reabastecimiento.
Actualmente Partners está traducido como Empresas. Partners es un término más amplio y ambiguo que incluye además de empresas a particulares, instituciones, organismos oficiales, asociaciones, etc. Propongo mantener la palabra en inglés Partners o utilizar la palabra Entidades
No es fácil traducir Partners. Varias posibilidades son: Empresas, Entidades, Clientes y proveedores, etc. Depende de donde se implemente OpenERP son más adecuadas unas o otras. Actualmente Partner está traducido como Empresa y Company (la propia empresa) como CompañíaTraduccion_es_ES
Comentarios y debate sobre la traducción de OpenERP al castellano (España)
INTRODUCCIÓN
Es fundamental que podamos consensuar los términos a utilizar en las traducciones.Y, que cada cual utilice una traducción personalizada porque se encuentra más cómodo con los términos que se manejan en esta nos trerá problemas a la larga y dificultará el desarrollo de documentación localizada en el futuro.
Por estos mótivos, esta página pretende ser un lugar donde comentar y proponer alternativas en relación a los términos utilizados en la traducción de OpenERP.
GUÍA DE ESTILO
Se ha utilizado acentos, tanto en mayúsculas como en minúsculas. Esto no acarrea ningún tipo de problema codificando en UTF-8 el fichero de la traducción. Además de ser normativa ortográfica, permite automatizar la traducción a otros idiomas latinos como catalán y gallego.
Sólo se utilizan mayúsculas al incio de la frase/texto o cuando es nombre propio. El uso de mayúsculas en la primera letra de cada palabra está acceptado en inglés pero no en castellano. Además los textos quedan ligeramente más cortos y se facilita la lectura. Se hace una excepción con la abreviaciones (p.e. LdM).
Las acciones son verbos en infinitivo (p.e. Cancelar). Los estados son verbos en participio (p.e. Cancelado).
En las ayudas o sugerencias se usa la forma verbal de usted, sin poner nunca la palabra usted. Por ejemplo: Marque esta opción para poder cancelar asientos en este diario. Seleccione Bajo pedido para …
Se ha intentado mantener la longitud de los textos originales, aunque es imposible pues en la mayoría de casos las traducciones al castellano son más largas. Se ha testeado la mayoría de menús, vistas, formularios e informes para comprobar que no aparezcan textos demasiado largos.
A veces algunos textos no aparecen traducidos porqué en el código fuente de OpenERP no se han indicado que son traducibles (normalmente mensajes de aviso dentro del código Python, podrían catalogarse de bugs del programa).
Lista alfabéticamente ordenada de las traducciones utilizadas. Se ha intentado utilizar un registro de castellano de España estándar con vocablos de gestión empresarial. Cuando una expresión se ha traducido de dos o más formas diferentes se han separado con comas. Las listas de acciones (verbos infinitivos) y vocabulario método scrum se han separado al final.
INGLÉS -> ESPAÑOL
account -> cuenta, contabilidad
o account chart -> plan de cuentas
o account move -> asiento (o apunte)
o account move line -> movimiento, mov. (o partida)
o account owner -> titular de la cuenta
* amount -> importe
assignation -> asignación
attendances -> servicios
balance -> balance o saldo
balance -> saldo pendiente (en formas de pago)
balance sheet -> balance
bank account -> cuenta bancaria
bank statement -> extractos bancarios
BOM -> LdM (Bill of Material -> Lista de Materiales, hay que mantenerlo abreviado)
case -> caso
chart -> gráfico (de pastel, de barras, de líneas), resumen (chart muestra muchas veces tablas de resumen)
chart of accounts -> plan contable
company -> compañía (es la propia empresa)
credit -> haber
credit balance -> saldo acreedor
custom -> personalizado
dashboard -> tablero
deadline -> fecha límite
debit -> debe
debit balance -> saldo deudor
default -> por defecto
deferral -> cierre
done -> realizado
email -> email, correo electrónico
event -> evento
file -> archivo
fiscal year -> ejercicio fiscal
follow-up -> seguimiento
general ledger -> libro mayor
goods -> material
grid -> tabla
helpdesk -> helpdesk (¿Mejor traducirlo como centro de soporte?)
history -> historial
HR -> RRHH
in progress -> en proceso
item -> detalle, elemento
location -> ubicación
lot -> lote
meeting -> reunión
Ok -> Aceptar
opened -> abierto
order -> orden o pedido. Es decir, una orden o pedido puede estar, por ejemplo, en estado borrador (presupuesto), confirmada (comanda), enviada (albaran), facturada (factura))
timesheet -> hoja de servicios, hoja de asistencia
total -> total
tracking -> tracking (¿Es mejor rastreo o seguimiento?)
track -> track (¿Es mejor rastreo?)
tree -> árbol
UOM -> UdM (Unit of Manufacturing -> Unidad de Manufactura, hay que mantenerlo abreviado)
UOS -> UdV (Unit of Sell -> Unidad de Venta, hay que mantenerlo abreviado)
untaxed amount -> base imponible
VAT -> IVA
wage -> salario
wizard -> asistente
workcenter -> centro de producción
workflow -> flujo de trabajo (a veces sólo flujo para abreviarlo)
write-off -> desajuste
zip -> C.P. (Código Postal abreviado)
ACCIONES (verbos en infinitivo)
asigne -> asignar
cancel -> cancelar
close -> cerrar
compute -> calcular
confirm -> confirmar
create -> crear
open -> abrir
pack -> empaquetar
pay -> pagar
print -> imprimir
run -> ejecutar
select -> seleccionar
send -> enviar
sign in -> registrar entrada
sign out -> registrar salida
Traducciones referentes al método Scrum (1)
Términos consensuados y incorporados el 3-4-2008
MENÚ PARTNERS
Para empezar, credit Limit está traducido como Límite Haber. Propongo utilizar Crédito o Crédito concedido
En segundo lugar, state of Mind está traducido como Estados de satisfacción. Propongo utilizar Grado de satisfacción
Account owner está traducido como Dueño de la cuenta. Propongo utilizar Titular de la cuenta
MENÚ SALES MANAGEMENT
Por una parte, order description está traducido como Descripción de la order. La traducción me parece apropiada pero no la etiqueta original.
Por otra parte order description; no se utiliza para introducir una descripción de la orden de venta sino que tiene asignada una secuencia. Propongo utilizar Nº orden venta o Ref orden venta
Untaxed Amount está traducido como Importe sin impuestos. Propongo utilizar Base imponible
El estado In progress está traducido como En progreso. Propongo utilizar En proceso
Packing name está traducido como Nombre del paquete. Propongo utilizar Nº albarán o Ref albarán
Términos propuestos
Asímismo, en el módulo stock (Control inventario); el término Reordering Policy está traducido como Política de volver a ordenar. Propongo utilizar Política de reabastecimiento.
Además, actualmente Partners está traducido como Empresas. Partners es un término más amplio y ambiguo que incluye además de empresas a particulares, instituciones, organismos oficiales, asociaciones, etc. Propongo mantener la palabra en inglés Partners o utilizar la palabra Entidades
No es fácil traducir Partners. Varias posibilidades son: Empresas, Entidades, Clientes y proveedores, etc. Depende de donde se implemente OpenERP son más adecuadas unas o otras. Actualmente Partner está traducido como Empresa y Company (la propia empresa) como Compañía
A lo largo de este artículo responderemos a la típica pregunta que surge, cuando hablamos de sistemas de gestión empresarial ¿Qué es un ERP?
Los sistemas de planificación de recursos empresariales (Enterprise Resource Planning, en inglés) sistemas informáticos destinados a la administración de recursos en una organización asociados con las operaciones de producción y de los aspectos de distribución de una compañía comprometida en la producción de bienes o servicios (1).
O de otra manera, un ERP es un sistema de gestión para todos los procesos de la empresa de forma integrada en una única plataforma.
Tradicionalmente, ha estado asociado a empresas de gran tamaño, pues su mayor ventaja es que centraliza la información, sin importar el número de departamentos, personal o delegaciones.
Sin embargo, cada vez es más popular su uso en pequeñas y medianas empresas que desean controlar toda su información, y mejorar las comunicaciones con sus clientes y proveedores.
Su único inconveniente es que son sistemas complejos de configurar y también de utilizar.
Por lo que puede haber usuarios habituados a herramientas más sencillas que sean reacios al cambio. Por lo que, se suele requerir solicitar los servicios de implantación y formación a terceras empresas especializadas.
No obstante, si se desea un incremento de la productividad, y un control sobre los datos y los procesos de trabajo de su empresa, la instalación de un ERP es sin duda un paso obligatorio.
