¿Columnas vs. Filas?

Tener los datos en memoria no es lo único que hace rápido y eficiente a SAP HANA, hay un conjunto de aspectos adicionales que contribuyen a lograr tiempos tan reducidos de acceso a la información (aquí un post al respecto) como la tecnología de procesamiento o almacenamiento basado en columnas, esta tecnología es una alternativa a la clásica y popular almacenamiento basado en filas, utilizada por la gran mayoría de bases de datos relacionales, mayoritariamente en uso en la actualidad.


Tener los datos en memoria no es lo único que hace rápido y eficiente a SAP HANA, hay un conjunto de aspectos adicionales que contribuyen a lograr tiempos tan reducidos de acceso a la información (aquí un post al respecto) como la tecnología de procesamiento o almacenamiento basado en columnas, esta tecnología es una alternativa a la clásica y popular almacenamiento basado en filas, utilizada por la gran mayoría de bases de datos relacionales, mayoritariamente en uso en la actualidad.

Al referirnos al almacenamiento basado en columnas o filas no pretendemos señalar a una como buena y a la otra como obsoleta, ambas tecnologías son buenas y eficientes pero dependiendo qué uso se le da.  La base de datos de SAP HANA utiliza ambas tecnologías, pero para tareas diferentes para así obtener su mejor rendimiento.

Resumiendo lo bueno y malo de cada tecnología, lo siguiente sería lo más destacable:

  • Almacenamiento basado en filas (Row – based Storage)
    • Ventajas: Todos los datos se almacenan juntos, facilitando la inserción y actualización
    • Desventajas: Durante la selección o recuperación de datos, todos los datos son leídos.
  • Almacenamiento basado en filas (Column –  Based Storage)
    • Ventajas: Sólo se accede a la información requerida durante el proceso de selección o lectura.  Cualquier columna de datos puede actuar como un índice o clave para la recuperación de datos.
    • Desventajas: La actualización de datos en columnas no es eficiente como lo puede ser la tecnología basada en rilas.

Referencia: (aquí)

Consolidación financiera: Métodos

Las empresas, con el fin de crecer o sobrevivir, entre ellas se pueden producir las siguientes operaciones:


Las empresas, con el fin de crecer o sobrevivir, entre ellas se pueden producir las siguientes operaciones:

  • Fusiones entre empresas
  • Compra de una parte del negocio de una empresa por parte de otra
  • Compra de acciones de una empresa por parte de otra.

De estas probables operaciones comerciales, sólo en el caso de compra de acciones, tanto la adquiriente como la adquirida, mantienen su independencia jurídica, es decir, siguen existiendo como empresas individuales, pero quizás queden bajo una dirección única, obligadas, por consiguiente, a consolidar su información financiera.

Según el porcentaje de propiedad y/o control que tiene la sociedad dominante sobre las dependientes se aplicarán uno de los siguientes métodos para consolidar la información del grupo:

  • Método de integración global. Consiste en la incorporación al balance de la sociedad dominante el total patrimonio de las sociedades dependientes y en la cuenta de pérdidas y ganancias de la sociedad dominante se incorporarán todos los ingresos y gastos de las sociedades dependientes.  Aplicable a las sociedades dependientes o filiales en las que se tiene un control del 100%.
  • Método de integración proporcional. Similar al método de integración global, salvo que se agrega en la proporción que se posea de la sociedad multigrupo dado que se gestiona conjuntamente con alguien más.
  • Procedimiento de puesta en equivalencia (método de participación).  Se aplica a las sociedades asociadas.  Es un método carece de la fase de agregación. Para una sociedad multigrupo se puede aplicar este método.

El conjunto de sociedades que se integran por los métodos de integración global e integración proporcional se denomina “conjunto consolidable”.

El conjunto de sociedades que se integran por los métodos de integración global, integración proporcional y puesta en equivalencia se denomina “perímetro de consolidación”.

«Ley de signos» en SAP BPC

En ocasiones se olvida o se ignora que los principios sobre los que está diseñado SAP Business Planning and Consolidation (SAP BPC) provienen de su fabricante original, OutlookSoft, usuarios y consultores de otros productos, que comienzan a conocer el producto, al descubrir alguna característica apuntan expresiones como “… pero esto no es SAP”.


En ocasiones se olvida o se ignora que los principios sobre los que está diseñado SAP Business Planning and Consolidation (SAP BPC) provienen de su fabricante original, OutlookSoft, usuarios y consultores de otros productos, que comienzan a conocer el producto, al descubrir alguna característica apuntan  expresiones como  “… pero esto no es SAP”.

SAP en la versión 10.0 ha realizado más avances para que SAP BPC sea más similar al estándar, pero hay cosas que no podrán variar, como la forma en que se almacenan los importes.  En BPC los importes de los datos transaccionales se almacenan según la parametrización que se realice en la dimensión (equivalente a una tabla de datos maestros) de tipo ACCOUNT dedicada para definir los conceptos o cuentas que se utilizarán en la automatización de un proceso de presupuesto, planificación o consolidación.  Dentro de esta dimensión hay un atributo (equivalente a un campo o atributo) denominado ACCTYPE (Account Type) que puede tener los siguientes valores:

  • INC: Ingresos (Income – PyG)
  • EXP: Gastos o Costes (Expense – PyG)
  • AST: Activo (Asset – Balance)
  • LEQ: Pasivo (Liabilities & Equity – Balance)

Según el valor de la propiedad ACCTYPE los datos que se ingresen vía formularios de entrada o proceso de carga de datos, los importes son tratados del siguiente modo:

Intentar “forzar” un tratamiento diferente a los parámetros BPC que rigen esta “ley de signos” puede ocasionar un resultado impredecible.

Referencia: (aquí)

Otro Rebranding: ¿SAP BusinessObjects BI por SAP Analytics Solutions?

Son varios los cambios de nombre que SAP ha hecho a sus productos, especialmente en los portfolios (carteras o grupos de productos) de Business Intelligence (BI) y Enterprise Performance Management (EPM), pero este sería el más relevante, no porque aporte algo, sino por la confusión que generaría.


Son varios los cambios de nombre que SAP ha hecho a sus productos, especialmente en los portfolios (carteras o grupos de productos) de Business Intelligence (BI) y Enterprise Performance Management (EPM), pero este sería el más relevante, no porque aporte algo, sino por la confusión que generaría.

Entrando al Marketplace, hemos visto que la sección para descargar actualizaciones de BI ya no se denomina SAP BusinessObjects BI, sino Analytics Solutions, por el momento no hemos visto comunicado oficial alguno, pero para qué, no hace falta, los usuarios además de la amplia variedad de componentes que tenemos en BI, versiones y ediciones, también deben tener presente los varios nombres que tienen todos los productos y portfolios SAP. 

Otros cambios de nombre de SAP: aquí, aquí o aquí

El futuro de SAP se escribe sobre HANA

Leyendo un artículo del portal especializado en tecnologías de la información, ZDNet, encontramos una serie de ideas y conclusiones interesantes del último evento relevante de SAP, SAP TechEd, antes de celebrarse SAPPHIRE Now 2012 de Madrid. Del artículo de Dennis Howlett , extraemos las siguiente ideas:


Leyendo un artículo del portal especializado en tecnologías de la información, ZDNet, encontramos una serie de ideas y conclusiones interesantes del último evento relevante de SAP, SAP TechEd,  antes de celebrarse SAPPHIRE Now 2012 de Madrid. Del artículo de Dennis Howlett , extraemos las siguiente ideas:

  • La apuesta de futuro de SAP, además de SAP HANA, es Mobile y Cloud Computing.
  • Nuevas empresa y otras con experiencia en el mercado están desarrollando nuevas aplicaciones mobile basadas en SAP HANA que antes eran inimaginables diseñar. Se menciona el caso de la empresa Basis Technologies que ha desarrollado una herramienta predictiva sobre el consumo de energía que tiene como clientes referentes a EDF y ayuda a identificar a los clientes con riesgo de cambio o con necesidades de servicio.
  • La tienda de aplicaciones móviles de SAP no tiene la demanda que se esperaba, en parte, porque los clientes si requieren aplicaciones mobile, pero con posibilidades de personalización que no se ofrecen.
  • Mensaje para los desarrolladores ABAP: En los países desarrollados están en riesgo de ser relegados a tareas de mantenimiento y corrección, es aconsejable abandonar la “mentalidad de 1990” y prepararse para el mundo SAP HANA.
  • Se percibe un gran desconocimiento sobre SAP HANA en el entorno SAP, para algunos, la verdadera gran innovación en los últimos 20 años de SAP.
  • Para el especialista se espera en el próximo SAPPHIRE NOW de Madrid se espera grandes anuncios sobre SAP HANA y que se aborde más sobre las propuestas Cloud Computing, casi no mencionado en este evento.