Las estrategias de planificación representan un procedimiento comercial para planificar cantidades y fechas de producción. Existen diferentes estrategias de planificación que cubren escenarios de fabricación contra stock -MTS y fabricación contra pedido – MTO.

La mayoría de ellos están asignados a productos terminados que explotan la planificación y adquisición de la estructura completa de una lista de materiales (BOM).

Pero en este blog, queremos hablar de la estrategia de planificación 70 (Preplanificación a nivel de conjuntos), que se mantiene en el nivel de ensamblaje (semiterminados – materias primas) y no en el nivel de producto terminado.

Esta estrategia está diseñada para la planificación de componentes. (existen otros tipos de estrategias de componentes: 59 y 74)

Estrategia – 70 Preplanificación a nivel de conjuntos

Esta estrategia de planificación es muy útil cuando se tienen múltiples variantes de productos terminados pero que se fabrican utilizando materiales comunes. Por ello se pueden pronosticar estos materiales comunes con mucha anticipación.

• El producto terminado puede tener cualquier estrategia de planificación MTO o MTS.
• Se debe crear las necesidades primarias planificadas sobre el componente que se quiere planificar.

Requisitos

• Material planificado (componente)

Grupo de estrategia: 70 – Preplanificación a nivel de conjuntos.

Modo de compensación – Controla en qué dirección se efectúa la compensación de necesidades sobre el eje de tiempos.

Planificación necesidades mixta – 1 Preplanificación de conjuntos con montaje final.

• Necesidades primarias planificadas (MD61)

Clase de necesidad: VSFB – Preplanificación de conjuntos.

Cantidades de planificación

Escenario – Inicial

Una vez realizado los requisitos iniciales podemos ver cómo están las necesidades y stocks de los materiales involucrados en nuestra estrategia de producción.

Producto terminado:

No hay existencias del producto terminado y tampoco ha llegado una necesidad de cliente para la fabricación de este material.

Producto semiterminado

Al lanzar el MRP vemos que la planificación de las previsiones creadas anteriormente (MD61 – Transacción) generan las previsiones por las cantidades totales de la previsión.

Escenario – Pedido de ventas

Llega un pedido de ventas contra nuestro producto terminado y veremos cómo debe generar las previsiones de fabricación contra nuestro producto terminado y cómo compensa la fabricación de nuestro material semiterminado contra las previsiones creadas inicialmente.

Producto terminado:

Lanzando el MRP, observamos que ha llegado la necesidad de reaprovisionarse a causa del pedido de ventas en nuestro material de producto terminado.

Producto semiterminado:

La ejecución del MRP ha compensado las necesidades primarias creadas inicialmente contra este material a través del pedido de ventas.

Esto ha reducido la cantidad de necesidad creada inicialmente de 500 unidades a 300 unidades. Mientras que las otras 200 unidades que se debían generar en esa fecha quedan reflejadas en una nueva necesidad del pedido introducido contra su material padre.

*en el caso de NO haber utilizado una estrategia de compensación en el material semiterminado. La ejecución del MRP hubiese sumado la nueva cantidad introducida por el pedido sin tener ninguna compensación entre el pedido y la previsión

Esperamos que este artículo te haya sido de ayuda. Recuerda que puedes dejarnos tus dudas en comentarios o ponerte en contacto con nuestro área de SAP Logística.

Área SAP Logística

La entrada Estrategia de planificación – Componentes se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En este artículo vamos a hablar sobre otra de las novedades de SAP dentro de la estrategia SAP Fiori UX: SAP Screen Personas. SAP Screen Personas es una herramienta de IU que nos permite mejorar la productividad de los usuarios mediante la personalización y simplificación de las pantallas, sin necesidad de modificar el funcionamiento back-end.

Gracias a esa personalización, podremos diseñar pantallas dirigidas a cubrir las necesidades de un usuario o grupo de usuarios, evitando grandes costes de programación y reduciendo tiempos de desarrollo.

Además, con SAP Screen Personas podremos adaptar las pantallas de una forma sencilla a dispositivos móviles, sin necesidad de crear aplicaciones IU5 desde cero.

SAP Screen Personas se fundamenta en estas tres herramientas para mejorar la productividad:

• Editor de pantallas, con él podremos ocultar campos que los usuarios no utilicen, combinar la información dividida en diferentes pestañas en una única vista. Realizar cambios en las pantallas para hacerlas más atractivas para el usuario.
• Mediante los scripts, podremos automatizar las tareas que los usuarios realicen repetidamente.
• Los temas, nos permiten cambiar la apariencia de todas las pantallas al mismo tiempo, dándoles un estilo coherente entre ellas.

Los beneficios que SAP Screen Personas puede tener sobre una empresa son los siguientes:

• Los procesos de negocio se simplifican al condesar la información de estos en pantallas más simples.
• La toma de decisiones se acelera al facilitar la introducción de los datos en los sistemas permitiendo tener la información en tiempo real más rápidamente.

Próximamente, tendréis disponible un videotutorial explicando cómo crear una variante para personalizar vuestras pantallas.

Esperamos que este artículo te haya servido de ayuda. Recuerda que puedes dejarnos tus dudas en comentarios o ponerte en contacto con nuestro departamento de UX/I.

Área UX/I

La entrada SAP Screen Personas se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Estaba claro que, cuando SAP adquirió Successfactors hace ya casi una década, el tema de la comunicación entre los sistemas cloud y on-premise iba a ser clave a la hora de trabajar con las nuevas soluciones de talento que, a día de hoy, SAP Successfactors nos ofrece (Performance, Goals, Compensation, Time Management, Payroll…etc).

El problema que preocupaba a mucho usuarios y consultores era el de la replicación de datos de empleados en la nube ya que, volver a introducir dichos datos de forma manual en el sistema resultaría ser una tarea ardua para muchos usuarios de la aplicación. Este proceso tendría que automatizarse y ante dicho problema, SAP nos propuso varias soluciones.

En este artículo abordaremos una de las soluciones disponibles: el envío de datos de empleados de SAP R/3 HCM a SuccessFactors a través del uso de un middleware de integración (SAP PI). Concretamente nos centraremos en la exportación de los datos desde el sistema on-premise.

Antes de comenzar con la exportación de datos, deberemos haber instalado el correspondiente add on para la integración de SAP ERP Human Capital Management y SAP SUCCESSFACTORS Business Execution (SuccessFactors BIZX). Gracias a este add on, se consigue la integración de datos para los siguientes escenarios:

• Datos de Recruiting o Contratación: Se puede transferir información de posiciones de SAP ERP (datos de infotipo vacante-1007) a SAP SSFF BizX para que se modifiquen directamente las pertinentes solicitudes de contratación en el sistema cloud.
• Datos de Compensation o Compensación: Se pueden transferir datos de compensación de SAP ERP a SAP SSFF para llevar a cabo la planificación de compensación desde el sistema cloud. Por otro lado, la comunicación es bidereccional lo que nos permite exportar datos de Successfactors a SAP R/3 e influir automáticamente en la nómina de los empleados.
• Datos de Desempeño o Performance: Se pueden transmitir datos de R/3 a Successfactors para el desarrollo de herramientas de informes, por otro lado, también se pueden transmitir datos de evaluaciones (notas de los informes de desempeño, por ejemplo) al sistema on-premise.
• Datos de empleados: Se transmiten datos clave de empleados de SAP ERP HCM a través de la ejecución de programas estandar disponibles después de la instalación del add on correspondiente. Estos programas generan un fichero CSV con doble cabecera y con los correspondientes campos clave necesarios (Status, UserID, Username…) así como hasta un total de 15 campos customizables para la generación de usuarios en Successfactors:

Como ya hemos mencionado al principio del artículo, nos centramos en éste último escenario de integración de datos de empleados. Una vez instalado el correspondiente Add on de integración tendremos disponible desde customizing los siguientes accesos:

Este escenario de integración funciona como pértiga para los demás escenarios por lo que siempre se recomienda comenzar por este escenario.

Una vez configurado el middleware de integración (SAP PI, en este caso), procedemos a definir el formato de nombre para los campos de FIRSTNAME Y LASTNAME:

Si no se especifica nombre alguno para los campos nombre y apellido, el sistema propone por defecto los nombres de PA0002-VORNA y PA0002-NACHN.

Una vez definidos los campos Vorna y Nachn procedemos a definir la variante para nuestro report de extracción de datos de personal.

La variante de extracción es importante y debe crearse antes de la ejecución del programa RH_SFI_SYNCHRONIZE_EMPL_DAT. Este report nos arroja los cambios en los datos maestros de empleados registrados desde la última ejecución de ese mismo report.

1. Para comenzar con la ejecución del programa debemos establecer el período para el cual queremos extraer los datos de empleados. La fecha por defecto siempre es la de hoy.
2. Para extracciones iniciales de datos de empleados siempre se debe establecer el status 3 (Activo).
3. Establecemos un email por defecto que rellenará el campo del email en nuestro csv generado en caso de que no se encuentre mapeo alguno con el campo del email en nuestros infotipos.
4. Establecemos un idioma de extracción que deberá coincidir con el idioma de nuestra instance de Successfactors para evitar inconsistencias entre ambos sistemas durante el mapeo. También activamos el checkbox para el log de errores.
5. Por último seleccionamos que campos de infotipos queremos que se mapeen. Por defecto SAP nos proporciona una dropdown selection con algunos campos de infotipos por defecto, en caso de querer una implementación propia de campos deberemos establecer una BAdI enhancement determinada. Si la opción de exclusión de campos está seleccionada para un determinado campo, ese campo (siempre que no sea clave) no se incluirá en la transferencia de datos:

Una vez ejecutado el programa se generará nuestro fichero csv que se guardará en nuestras vías de acceso lógicas y físicas que previamente habremos definido.

Para comprobar que nuestro fichero csv se ha generado correctamente podremos ir a la transacción del directorio SAP (AL11) y analizar su correcta generación y estructura:

Según tengamos configurado nuestro middleware de integración, el fichero se cargará automáticamente en SAP PI y la importación de datos en SuccessFactors se conseguirá de forma consecutiva.

Como ya hemos mencionado anteriormente, el programa RH_SFI_SYNCHRONIZE_EMPL_DAT nos arroja las variaciones en los datos de empleados registradas desde la última ejecución del programa por lo que si quisiéramos que dicho programa se ejecutase de manera periódica de forma automática podríamos acudir a la transacción SM36 para programar mediante un job la extracción periódica de datos de empleados y la generación de ficheros csv.

Después de la importación automática de empleados en SSFF recibimos un email con la confirmación de que ha habido una nueva importación de empleados y que se han creado de forma automática 6 nuevos empleados en nuestra instancia.

Quedaría comentar la parte de envío de datos de la solución cloud a nuestros sistemas en la tierra, como por ejemplo, comentar el escenario de desempeño pero eso es un tema que prefiero dejar para próximos artículos.

Esperamos que este artículo te haya resultado de utilidad a la hora de importar datos a SAP SuccessFactors.. Recuerda que puedes dejarnos tus dudas en comentarios, o puedes ponerte en contacto con nuestro departamento de RRHH de SAP.

Área SAP RRHH

La entrada COMUNICACIÓN EN SUCCESSFACTORS: ENVÍO DE DATOS DE EMPLEADOS DE SAP R/3 A SUCCESSFACTORS se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

¿Qué es un material fantasma en SAP PP?

Los materiales fantasmas en SAP PP son agrupaciones lógicas de componentes, y son conjuntos ficticios que nunca se producen ni se crean stock de dichos materiales. Sus componentes están integrados con el producto de mayor nivel.

Las decisiones para usar este concepto en el sistema SAP son los siguientes:

• Agrupar un proceso lógico y estructurar las listas de materiales con un mismo patrón.
• Realizar listas de materiales sencillas para productos muy complejos, con muchos niveles en las listas de materiales.

Requisitos

La configuración del tipo especial de aprovisionamiento “Conjunto ficticio” sobre el material que no queremos aprovisionar en sistema.

Deberemos tener creada las listas de materiales de los materiales involucrados, En la explosión de la lista de materiales del producto padre, se puede todos los niveles de la estructura de la BOM. En dicha explosión; el material fantasma queda marcado como posición Dummy.

En cuanto a la diferencia de datos maestros de un conjunto fantasma y un conjunto real es que un material fantasma no necesita una ruta, ya que no se va a producir ni comprar.:

• No se realizan pedidos planificados / órdenes de producción para los componentes fantasmas.
• No hay existencias de los ensamblajes fantasmas.

Escenarios

En el momento de la creación de la orden de fabricación del material padre, se puede ver como desglosa los componentes de la lista de materiales dentro de dicha orden.

El material fantasma lo muestra en los componentes a modo informativo y a su vez la explosión del material fantasma con los componentes de su lista de materiales.

• La lista de necesidades/stock del material fantasma no controla ni stocks, ni fabricación ni compras.

• La lista de necesidades/stock del material inferior muestra la necesidad secundaria del material fantasma.

Esperamos que este artículo te haya servido de ayuda a la hora de gestionar materiales fantasma en SAP PP. Recuerda que puedes dejarnos tus preguntas en comentarios o ponerte en contacto con el área de SAP logística de Oreka IT.

Área SAp Logística

La entrada Qué es un material fantasma o ficticio – PP se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Aquí tienes el vídeo completo del webinar que celebramos el pasado 28 de marzo de 2019 sobre nuestra app para fichar en el trabajo desde cualquier dispositivo móvil. Muy útil para empresas que busquen registrar los fichajes y ausencias de los empleados desde cualquier punto y dispositivo móvil.

Puedes consultar la ficha completa de esta herramienta aquí

Si estás interesad@ en esta aplicación, puedes ponerte en contacto con nuestro departamento de SAP Recursos Humanos.

Área SAP Recursos Humanos

La entrada Webinar Control Horario · App para fichar en el trabajo desde cualquier dispositivo móvil se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

La gestión de tiempos libres o “time off” en materia de tiempos se ha ido convirtiendo en una práctica habitual en las empresas de hoy en día. Cada vez, son más las empresas que tienen implementadas diversas políticas de gestión de tiempos como sistemas de beneficios para empleados. Es por ello, que las empresas precisan de un sistema eficaz para establecer la forma en la que éstos beneficios se distribuyen.

Existe un gran número de transacciones y tareas a realizar una vez establecido el EC Time Management.

Con esta aplicación derivada del Employee Central, los administradores de recursos humanos son capaces de relacionar a los nuevos empleados con las cuentas de tiempos apropiados cuando se les contratan. De esta forma, se permite que los administradores de SuccessFactors tengan siempre una imagen representativa de los horarios y contingentes de los empleados.

Por otro lado, los empleados necesitan saber qué contingentes les corresponden para poder solicitar vacaciones u otros absentismos a través de la aplicación cloud. A partir de ahí, los responsables de cada empleado pueden aprobar y rechazar las correspondientes solicitudes.

Employee Central ofrece un sinfín de herramientas para la gestión de tiempos. La gestión de asistencias se lleva a cabo mediante el empleo de hojas de tiempos o “time sheets” mientras que los absentismo, como ya hemos mencionado, se gestionan mediante los “Time offs”, existiendo una gran correlación entre ambas herramientas.

En Successfactors, la gestión de tiempos (PT) va de la mano con la gestión de permisos o “time offs” con el fín de establecer un proceso completo y eficiente de la gestión de tiempos. Para implementar la gestión de tiempos en Successfactors se deben emplear los denominados objetos de gestión de tiempos:

• Tipo de Tiempos: Es una categoría especifica de tiempos sobre el que se guardan las horas. Es decir, sirve para clasificar el número de horas según su naturaleza (horas de trabajo, absentismos…etc).
• Cuentas de Tiempos: Las cuentas de tiempos almacenan la cantidad de tiempo actualmente disponible a usar por sus respectivos tipos de tiempos. Funcionan como bolsas de horas de las que los empleados pueden deducir horas de un determinado contingente. Es una herramienta de gran utilidad ya que permite a los empleados comprobar cuantas horas de contingente les corresponden, tienen aun disponibles o han disfrutado.
• Tipos de cuentas de tiempos: Cualquier tipo de tiempo que necesite cuentas de tiempos, debe tener tipos de cuentas de tiempos asignados. Dicho indicador permite al sistema saber que cuentas de tiempos deberán ser creadas. Se pueden crear reglas de negocios que se asignen a dichos tipos de cuentas de tiempos para devengar de forma automática las horas que le corresponden a cada trabajador en base a su tiempo trabajado.

• Calendarios de Festivos: Se crean días festivos que se recogen en calendarios festivos en base a la configuración regional y que a posteriori, se asignarán al plan de horario de trabajo.

• Los horarios de Trabajo: Definen el patrón de trabajo de un empleado. Se asignas a la información del puesto de trabajo del empleado y muestran información relativa al número de días y horas por semana que el empleado trabaja. Estos horarios de trabajo normalmente se aplican a grupos de empleados. Sin embargo, si existe un trabajador con un horario particular exclusivo, se puede crear un horario de trabajo a parte y asignárselo a dicho empleado.
• Calendarios de Festivos: Se crean días festivos que se recogen en calendarios festivos en base a la configuración regional y que a posteri, se asignarán al plan de horario de trabajo.

Existen diferente modelos para establecer un horario de trabajo: simple, por periodos y programado. A la hora de crearlos se establece un fecha de inicio que se toma como punto de partida para el horario de trabajo.

El desarrollo de Employee Central por parte de SAP SuccessFactors es evidente. Cada vez son más las mejoras que se trasladan a la solución cloud ya sea en materia de gestión de personal, gestión organizativa o, como en este caso, gestión de tiempos y, es que ya es una realidad que, en éste ultimo campo SuccessFactors ofrece prácticamente todas las herramientas que se venían ofreciendo en los sistemas on-premise en un formato más agradable e intuitivo mejorando la experiencia de usuario.

Paulatinamente, SuccessFactors está pasando de ser un software dedicado únicamente a la gestión de talento a ser un software que sustituya al resto de módulos ya consolidados en ERP y, la gestión de tiempos en EC es un claro ejemplo de ello. Al fin y al cabo, es cuestión de “tiempos” que nos vayamos a la nube.

Si tienes cualquier duda o cuestión, puedes dejarnos tu pregunta en comentarios o puedes ponerte en contacto con nuestro departamento de SAP Recursos Humanos.

SAP Recursos Humanos

La entrada SUCCESSFACTORS: es cuestión de tiempos se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Si no pudiste acudir a nuestro webinar sobre el proceso de recruiting en SAP SuccessFactors, aquí tienes el vídeo completo. En este vídeo encontrarás la presentación de la herramienta, así como una demostración en vivo del proceso de recruiting realizado con esta herramienta.

Esperamos que te haya resultado interesante, y recuerda que puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro departamento de SAP RRHH. Si quieres saber más sobre SAP SuccessFactors, consulta los artículos relacionados.

Área SAP RRHH

La entrada Webinar · Recruiting process en SAP SuccessFactors se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

El pasado 16 de abril celebramos un webinar sobre KANBAN en SAP S/4 HANA, en el que abordamos un flujo completo de producción y realizamos un revisión general de los beneficios que aporta implementarlo.

La agenda del webinar fue la siguiente.

1. ¿QUIEN ES OREKA IT?
2. ¿QUE ES KANBAN?
3. KANBAN EN SAP
4. DATOS MAESTROS
5. TRATAMIENTO ID KANBAN
6. MOVIMIENTOS DE MATERIAL
7. DEMO

Si no pudiste asistir, te dejamos aquí el vídeo completo del webinar.

Puedes dejarnos tus preguntas en comentarios, donde trataremos de darte respuesta lo antes posible. Si estás interesad@ en el sistema KANBAN en SAP S/4 HANA, ponte en contacto con nuestro departamento de SAP Logística.

Área SAP Logística

La entrada Webinar · KANBAN en SAP S/4 HANA se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Hace unos meses publicamos un artículo avisando de la necesidad de actualizar Solution Manager mínimo al stack 8 de la versión 7.2 para poder mantener la conexión con el centro de soporte de SAP tras la actualización que van a realizar en la infraestructura. La fecha límite para realizar esta actualización y seguir conectándose sin problema es el 1 de enero de 2020.

En relación con la actualización, SAP ha decidido securizar las notas. Para ello, ha implementado la obligatoriedad de que las notas estén firmadas digitalmente. Esto implica que cualquier sistema que no actualice la forma de descargar y subir notas, no podrá implementar notas. Va a ser necesario habilitar en los sistemas ABAP el poder utilizar notas SAP digitalmente firmadas.

Hay dos formas de poder habilitar la funcionalidad para poder usar notas digitalmente firmadas:

• Mediante la implementación de notas manuales usando la transacción SNOTE.
• Mediante la implementación de un paquete usando el TCI, que si no está instalado es necesario instalarlo, que incluye todas las notas del anterior punto. Este segundo método es el recomendado por SAP.

Para poder habilitar la funcionalidad, ya sea bien por notas o por TCI, es necesario que los sistemas estén en un Stack mínimo dentro de cada Release:

Para ambos casos, después de la implementación, es necesario habilitar conexiones seguras mediante HTTPS con el SAP Support Backbone. Además, es necesario crear una conexión HTTPS contra el servicio de descargar de notas.

En conclusión, la necesidad de actualizar Solution Manager al stack 8 de la versión 7.2 se suma la necesidad de adaptar los sistemas SAP para que se puedan implementar las notas firmadas antes del 1 de enero de 2020. En caso de no hacerlo, Solution Manager no tendrá conexión con SAP (EWA, Maintenance Planner…) y además, no será posible descargar notas de los servidores de SAP para implementarlos.

Si tienes cualquier duda o pregunta, puedes dejarnos un comentario o ponerte en contacto con nuestro departamento de Administración de Sistemas SAP.

Área de administración de sistemas SAP

La entrada Implementando digitally signed SAP Notes se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

El pasado 8 de mayo impartimos este webinar sobre SAP BCM para la automatización de la comunicación bancaria. Si no pudiste asistir, te dejamos el vídeo completo del webinar donde podrás ver tanto la presentación teórica como la demostración real de la herramienta.

Si quieres ampliar información acerca de SAP BCM, puedes ponerte en contacto con nuestro departamento de SAP Finanzas & Controlling.

La entrada Webinar · SAP BCM para la automatización de la comunicación bancaria se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

El sector de utilities (agua, luz, gas) está en continua evolución y exige respuestas adaptadas a sus necesidades cambiantes. Esto obliga a las empresas de este sector a tener una mayor interconectividad para afrontar retos comunes como son la globalización, la reducción de costes, la eficiencia energética, la sostenibilidad o la innovación.

¿A qué nos lleva esa interconectividad? A la optimización. La integración de IS-U como componentes de SAP tiene definidos una serie de objetos relevantes y sus roles en la industria utilities, muy relacionados con otro módulo de SAP como Project Managment (PM). Estos son los principales objetos:

• Business Partner (BP) o Interlocutor comercial (IC)
• Contract Account o Cuenta de Contrato agrupa todos los contratos de un BP.
• Connection Object u Objeto de conexión; normalmente es un edificio, pero puede ser otro tipo de estructuras como una fuente o una zona de edificio. El objeto de conexión corresponde la ubicación técnica en Mantenimiento (PM).
• Premise o Punto de Suministro; un punto de suministro está asignado a un objeto de conexión, y está asociado a un Equipo en mantenimiento.
• Contract o Contrato; es el objeto por el que el cliente recibe el tipo de facturación. Un contrato está relacionado por tanto con Ventas (SD) y facturación.
• Installation o instalación; agrupa diferentes dispositivos o registros, y si es necesario, indica valores que estarán asignados a un punto de suministro, que son por ejemplos los contadores.
• Device Location o ubicación del aparato; es el lugar dentro de un objeto de acometida donde montan los aparatos. En relación a PM, se puede definir también como una ubicación técnica.

La introducción en el mercado de aparatos multifuncionales, como teléfonos inteligentes y las mejoras en la velocidad de conexión de datos hace necesario replantearse estrategias orientadas a perfeccionar la interconectividad de este tipo de sector.

La unión de IS-U con PM en la industria utilities es capaz de adaptar rápidamente los procesos que ya se exigen como la flexibilidad y agilidad para innovar en las empresas.

Si tienes cualquier duda sobre este tema, puedes ponerte en contacto con nuestro departamento de SAP Logística.

Área SAP Logística

La entrada Responde a la interconectividad en el sector de utilities: SAP IS-U + Project Managment se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Siguiendo con los webinars que hemos impartido en las últimas semanas, el pasado 16 de mayo realizamos uno más en el que abordamos las principales diferencias entre el MRP Live y el MRP clásico en SAP.

Las empresas en el proceso de planificación de necesidades de materiales se enfrentan a una estructura cada vez más compleja, necesitando una toma de decisiones con mayor información actualizada sobre la oferta y la demanda. Para ello S4HANA, nos dota de un nuevo MRP, más optimo, con mayor rendimiento, mayor eficiencia.

Los puntos que se abordaron fueron los siguientes.

Agenda
• De donde venimos a donde vamos
• Planificación: Beneficios e Incompatibilidades
• MRP Live o MRP Clásico
• Ejecución: Configuración y Parámetros de control
• Evaluación

A continuación, te dejamos el vídeo completo del webinar. Al final del mismo están las preguntas de los asistentes junto con las respuestas proporcionadas.

Si quieres ampliar la información sobre esta herramienta, ponte en contacto con nuestro departamento de SAP Logística.

Área SAP Logística

La entrada Webinar · Planificación de necesidades: principales diferencias entre MRP Live y MRP clásico de SAP se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

La manera más correcta de leer un infotipo desde código es mediante la función HR_READ_INFOTYPE. En este artículo encontraréis el por qué y cómo utilizarla.

Los datos de los distintos infotipos, al igual que la mayoría de información de SAP, se guardan en tablas. Existe una tabla por cada infotipo y las de los infotipos de personal (PA), las podemos encontrar bajo la denominación de PAnnnn, siendo nnnn el número correspondiente al infotipo con el que queremos trabajar.

A la hora de leer un infotipo, por ejemplo, para obtener los datos de éste en la ejecución de un programa, podríamos hacerlo mediante una sentencia SELECT, igual que para cualquier otra tabla. Pero a la hora de trabajar con este tipo de tablas, es recomendable sustituir esta sentencia por la función HR_READ_INFOTYPE para así evitar vulnerabilidades y tener los datos personales del empleado más protegidos.

La llamada a la función y la declaración de sus variables es la siguiente:

Los parámetros obligatorios para llamar a esta función son:

• PERNR
• INFTY
• INFTY_TAB

Parámetros de entrada

En TCLAS indicaremos la clase de transacción con la que queremos que se ejecute la función. Por defecto, la función utilizará a ‘A’. Sus posibles valores son los siguientes:

•  A: datos maestros y datos de tiempo
• B: datos del solicitante
• T: horario de turnos

El PERNR es el número que identifica al empleado del cual queremos obtener información.

Como esta función podemos conseguir información de muchos infotipos y será en el parámetro INFTY en el que le indicaremos el número del infotipo.

A pesar de no ser obligatorios, es recomendable utilizar los parámetros BEGDA y ENDDA para filtrar el resultado por fechas. De esta manera, aunque el empleado en el infotipo tenga muchos cortes, en la tabla interna solamente nos llegarán aquellos que se encuentren entre las fechas pasadas por parámetro. Por defecto, la función recogerá todos los cortes, ya que no filtra porque utiliza el inicio y el fin de los tiempos como fechas.

Mediante BYPASS_BUFFER y LEGACY_MODE indicamos si se va a leer con búfer y si se va a usar la implementación de éste o no. Por defecto, al primero de ellos no se le pasa ningún dato. Si por el contrario, queremos leerlo sin búfer, habría que pasarle una X. En el último de los campos, podemos jugar también con la X, y por defecto tenemos un espacio en blanco.

Parámetros de salida

El único parámetro de salida que tiene esta función es SUBRC, el cual ya lo podemos consultar de por sí mediante la variable de sistema SY-SUBRC.

Tablas

El resultado que estamos buscando se recoge en una tabla interna que nos devuelve el parámetro INFTY_TAB, la cual tenemos que declarar del mismo tipo que la tabla del infotipo que queramos obtener. Esto es así para que la tabla tenga los mismos campos que el infotipo y no perdernos ningún dato.

Excepciones

La única excepción que tiene declarada es INFTY_NOT_FOUND con el valor 1. Nos saltará cuando el infotipo que le hemos pasado en número no exista.

Con estos conocimientos, podemos utilizar y aprovechar al máximo la función HR_READ_INFOTYPE, evitando que alguien sin permisos acceda a los datos de alguno de los empleados.

Si tienes cualquier duda al respecto, puedes dejarnos tu pregunta en comentarios. También puedes ponerte en contacto con nuestra área de SAP Recursos Humano.

Área SAP Recursos Humanos

La entrada Función HR_READ_INFOTYPE en SAP se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Antes de todo, hay que recordar que el método kanban permite controlar la fabricación y el flujo de materiales. Estos materiales que se necesitan regularmente, se aprovisionan continuamente en pequeñas cantidades a fabricación. Si quieres saber más sobre este método, te recomendamos ver el webinar que impartimos hace unas semanas sobre este tema.

La reposición o la fabricación de un material sólo se desencadena cuando un nivel de fabricación superior necesita realmente dicho material. Esta reposición se desencadena directamente en la fabricación utilizando los datos maestros actualizados. La gran ventaja de la fabricación KANBAN es reducir la contabilización manual lo máximo posible.

Ciclo de control

El registro de ciclo de control está compuesto por el centro, el área de suministro de producción y el material.

Dicho registro determina la ubicación en almacén de producción y la clase de puesta a disposición de material que se utiliza en la interfase WM-PP. La clave completa define la ubicación en almacén de producción: número de almacén, tipo de almacén y ubicación.

Logística –> Producción –> Kanban –> Ciclo de control PKMC.

Ciclo de vida

En el ciclo de vida se determina la fase en el que se encuentra un ciclo de control (Creación – Liberado – Bloqueado)

Estrategia de reposición

En el ciclo de control se define cómo debe organizarse la reposición entre la fuente de aprovisionamiento y el consumidor.

• Fabricación propia – efectúa el reaprovisionamiento en la fabricación dentro de la compañía. Se debe indicar el responsable y la versión de fabricación
• Aprovisionamiento externo – es una estrategia de compra de materiales en el proveedor. Se debe identificar la organización de compras, proveedor o centro suministrador y pedido abierto si lo hubiera.
• Traslado – efectúa el reaprovisionamiento del área de suministro desde otro punto de la planta (IM o WM)

Kanban

Para la circulación de Kanbans, debe definir lo siguientes conceptos:

• Cantidad de Kanbans que circulan entre la fuente de aprovisionamiento y el consumidor
• Cantidad de material por Kanban (Contenedor)
• Máximo de contenedores vacíos

Cálculo automático de Kanban

Existe la posibilidad del cálculo automático de Kanban para determinar el número de Kanbans o la cantidad por Kanban:

• Clase de cálculo. Ésta controla si debe calcularse el número de Kanbans o la cantidad por Kanban.
• Se utiliza para grabar en la memoria intermedia las fluctuaciones de necesidad. Se multiplica por el resultado de la fórmula del cálculo de Kanbans.
• Con la constante se puede controlar la señal para notificar que un Kanban está vacío. (se suele usar de stock de seguridad)
• Perfil de cálculo. Este perfil simplifica la actualización del perfil de cálculo.
• Plazo de reposición. Puede indicar este plazo en días o bien en horas y minutos.

Impresión de Kanban

Se define si deben imprimirse los Kanbans o no y qué evento debe desencadenar la impresión. También se especifica el dispositivo de salida.

Esperemos que este post te haya ayudado a configurar tus Kanbans. Recuerda que si tienes cualquier duda, puedes dejarnos tus preguntas en la zona de comentarios o ponerte en contacto con nuestro departamento de SAP Logística.

Área SAP Logística

La entrada Ciclo de control en SAP- KANBAN se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

En este artículo vamos a hablar de la arquitectura para SAP FIORI con S/4 HANA. Vamos a explicar los componentes que lo forman y las conexiones necesarias para cada tipo de aplicación. Durante el artículo no se muestra la arquitectura completa, solamente los componentes relevantes desde el punto de vista de las autorizaciones. Éste será el primero de una serie de artículos que hablarán sobre autorizaciones para S/4 HANA.

En la imagen superior se puede observar cuáles son los elementos principales que componen SAP Fiori en S/4 HANA. El cliente es el SAP Fiori Launchpad desde donde los usuarios lanzan todas las aplicaciones Fiori. El Front-End Server (FES) es un sistema SAP NetWeaver ABAP Stack como cualquier ERP SAP. La diferencia es que no tienen ningún add-on de negocio instalado. La arquitectura recomendada para SAP Fiori separa la parte UI de la parte de lógica de negocio que está en el SAP Back-End Server (BES). Se pueden conectar varios BES a un sólo FES. Esta arquitectura tiene, entre otras, algunas de las siguientes ventajas:

• Separar el ciclo de vida de las aplicaciones UI del backend.
• Permitir iteraciones más rápidas con las aplicaciones UI.
• Permiter realizar cambios en las aplicaciones UI sin necesidad de tener autorizaciones en el backend.
• El administrador del metadata UI no necesita permisos de administrador en el backend donde se alojan los datos sensibles del negocio

La imagen representa la arquitectura completa en cuanto a autorizaciones para S/4 HANA donde se pueden ver los tipos de aplicaciones Fiori, los componentes que interactúan en cada servidor y los tipos de conexión que utilizan para conectarse entre ellos. A continuación, se explica brevemente en que consiste cada tipo de aplicación y como interactúa con el resto de componentes.

• Legacy: no son aplicaciones UI5. Son WebDynpro y transacciones GUI para aplicaciones HTML. No son aplicaciones portables, a pesar de contar un aspecto Fiori. Estas aplicaciones se conectan mediante HTTPS directamente contra el backend.
• Transactional, Analytical, Object Page: las tres funcionan de la misma manera, se les da un nombre diferente dependiendo del uso para el que hayan sido desarrollados. Son aplicaciones SAPUI5 Fiori. Tienen el despliegue de su interfaz en el FES. No son parte del Central UI pero necesitan add-ons específicos de prodecuto del Product UI. Por otro lado, estas aplicaciones necesitan recoger datos de negocio del servidor S/4 HANA del backend. Estos datos se transfieren mediante el protocolo OData. Para ello, se crea un RFC-TRUSTED entre el FES y el BES. Los usuarios de SAP Fiori necesitan tener un usuario en cada servidor con diferentes autorizaciones.
• Search: la aplicaciones Search del Fiori Launchpad tienen otra forma de funcionar. La interfaz del usuario se consigue mediante HTTPS desde el Central UI del FES. En cambio, los datos van por el protocolo InA directamente contra el motor Enterprise Search del servidor S/4 HANA.

Por último, comentar que es posible tener un sistema SAP Fiori con S/4 Hana sin necesidad de usar la arquitectura anterior. Se puede incluir el Front-End dentro del Back-End pero no es lo que recomienda SAP. Este tipo de arquitectura se puede observar en servidores Solution Manager 7.2.

En conclusión, la arquitectura presentada en el artículo es la que deberían de adoptar las empresas que estén pensando en hacer una conversión. Se puede observar cómo interactúa cada aplicación con los diferentes componentes de los dos servidores. Esta arquitectura separa las interfaces de los datos sensibles del negocio permitiendo tener dos usuarios con diferentes autorizaciones en cada sistema. El traspaso de datos y autorizaciones mediante los dos sistemas se hace mediante una RFC-TRUSTED. Los artículos futuros se centrarán más en la parte de la creación de autorizaciones en el FES y en el BES.

Esperamos que este artículo sobre la arquitectura de SAP Fiori con S/4 HANA te haya resultado útil. Recuerda que muy pronto estarán disponibles los siguientes artículos sobre autorizaciones para S/4 HANA.

Si tienes cualquier duda, puedes dejarnos un comentario o ponerte en contacto con nuestro departamento de SAP BASIS.

Área Administración de sistemas SAP

La entrada Arquitectura para SAP FIORI con S/4 HANA se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

A la hora de realizar Inversiones en Inmovilizado material dentro de la organización, SAP ofrece diferentes alternativas, pudiendo implicar módulos cómo FI, IM, MM, CO, PS…

Una práctica muy extendida en el mundo empresarial es la Gestión de Inversiones en Inmovilizado mediante Proyectos, con una fuerte integración entre los módulos:

• PS: Project System
• FI-AA: Finance-Asset Accounting
• IM: Investment Management

Así, siendo el Proyecto el eje central de este flujo, se generan automáticamente los Activos Fijos en Curso (AFeC) necesarios, para una vez finalizado el Proyecto, capitalizar el montante total de la inversión en el Activo Fijo Terminado.

Para la Gestión de Proyectos de Inversión en SAP PS, varios pasos a seguir son requeridos:

• Creación y Liberación de Proyecto tipo Inversión
• Imputación de gastos incurridos a Elemento PEP
• Liquidación Periódica de Elemento PEP a AFeC
• Creación y capitalización de Activo Fijo Terminado

Creación de Proyecto tipo Inversión

El proceso de creación de Proyectos de Inversión no dista del de otro tipo de Proyectos, por lo que se usará la transacción CJ20N (Project Builder).

Como hecho relevante, es que, en la Definición del Proyecto, se deberá asignar un Perfil de Inversión:

De esta manera, se crea la estructura de Proyecto, siendo únicamente necesaria la utilización de Elementos PEP:

Realizada la Fase de Planificación de Costes y Fechas necesaria, se llevará a cabo la Liberación del Proyecto o de los -Elementos PEP correspondientes.

Así, el Status del sistema del Elementos PEP cambiará a:

• Liberado, Existe Activo Fijo en Curso:

De esta manera, el Activo Fijo en Curso ya habrá sido creado de manera Automática con la Liberación del Elemento PEP. Mediante la siguiente transacción, se podrá visualizar el AFeC creado:

• AS03 – Visualizar Registro Maestro de Activo Fijo

Imputación de gastos a Elemento PEP

El Elemento PEP correspondiente será el Objeto de Imputación de todo los Gastos y Costes incurridos.

Como ejemplo, se contabiliza una Factura de Acreedor en SAP FI:

• FB60 – Contabilización factura acreedor

Siendo el Objeto de Imputación el Elemento PEP correspondiente:

Liquidación Periódica de Elemento PEP a AFeC

En el Proceso de Cierre de Periodo, se liquidará el Elemento PEP:

• Emisor Liquidación: Elemento PEP
• Receptor Liquidación: AFeC

La Liquidación se podrá realizar mediante la siguiente transacción:

• CJ88 – Liquidación proceso individual

De esta manera, el AFeC recibirá los gastos desde el Elemento PEP:

Una vez ejecutada la Liquidación mensual, se podrán ver los Valores de AFeC:

• AW01N – Asset Explorer

Creación y capitalización de Activo Fijo Terminado

Una vez liquidados todos los gastos al AFeC mediante liquidaciones periódicas desde el Elemento PEP, corresponde la creación y capitalización del Activo Fijo Terminado.

Para crear el Activo Fijo:

• AS01 – Crear Activo Fijo

En la pantalla de selección de parámetros, se elegirá una Clase de Activo Fijo Terminado:

…

Como último paso, los Valores del AFeC deberán liquidarse en el Activo Fijo Terminado. Esta Liquidación Final se realiza a través del Elemento PEP cómo Emisor de la Liquidación.

De esta manera, en el Project Builder (CJ20N), se creará la Norma de Liquidación correspondiente en el Elemento PEP mediante el Menú  :

Esta Norma de Reparto tendrá ciertas especialidades:

• Tipo de Imputación: AF – Activo Fijo
• Receptor de Liquidación: Activo Fijo Terminado creado en el paso anterior
• Clase de Liquidación: TOT – Liquidación Total

Finalmente, se procederá a la Liquidación final del Elemento PEP:

• CJ88 – Liquidación proceso individual

De esta manera, el Activo Fijo Terminado habrá recibido el Valor correspondiente:

Financieramente, el asiento contable reflejará una disminución del valor del AFeC (-) y un aumento del valor del Activo Fijo Terminado (+):

Finalmente, se puede consultar el Valor del Activo Fijo Terminado mediante la transacción AW01N, comprobando que ha recibido el Valor de capitalización:

Esta es la manera en la que SAP PS soporta la Gestión de Inversiones de Inmovilizado, cubriendo mediante el Proyecto todos los pasos necesarios para la final capitalización de los Costes incurridos en la construcción del Inmovilizado Material.

Listado de transacciones empleadas:

Esperamos que este artículo te haya sido de ayuda a la hora de gestionar proyectos de inversión de inmovilizado material con SAP PS Project System. Si tienes cualquier duda puedes dejarnos un comentario o ponerte en contacto con nuestra área de SAP Finanzas.

Área SAP Finanzas

La entrada SAP PS Project System – Proyecto de Inversión se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

SAP S/4HANA es la siguiente generación del software empresarial de SAP Business Suite. Una de las razones de esta adaptación es satisfacer las necesidades de las empresas en la optimización de los procesos, además de afrontar los retos de la nueva economía digital.

La migración a SAP S/4HANA no es sólo un proyecto de una sola vez en la que se actualicen o exista una migración de base de datos. Es algo más, ya que se trata de crear una nueva infraestructura de sistemas TI, haciendo más fácil la vida al usuario de SAP.

Una de las características más importantes de S/4HANA es la simplificación del modelo de datos. SAP proporciona vistas de compatibilidad para las tablas, que ya no son necesarios en la migración.

En el ámbito de logística, por ejemplo, para el caso de maestro de materiales se resume a una tabla denominada MATDOC, siendo el resto vistas (como MKPF, MSEG,..):

Se puede visualizar a través de la transacción SE16N, la diferenciación si es una tabla o una vista en SAP S/4HANA como se indica a continuación:

Las ventajas de una implantación en SAP S/4HANA permiten homogeneizar la información de la base de datos en tiempo real, buscando los datos en una tabla única, una mejor trazabilidad de la producción a través del MRP live y una gestión del cambio en función de la evolución de la empresa mirando al futuro con nuevas interfaces más simplificadas, como SAP FIORI.

Simplificación, eficiencia e inteligencia son las tres características que definen SAP S/4HANA y preparan a las empresas para el futuro. Si están interesados en mayor información sobre este tema, no duden en ponerse en contacto con nosotros en la el email orekait@orekait.com.

La entrada De SAP ERP 6.0 a SAP S/4HANA en Logística se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Hasta la fecha nos hemos preocupado en gestionar todo el contenido de nuestras instancias a través del uso de ficheros XML como el Corporate Data Model que, recogía datos organizativos de la empresa o el Succession Data Model que, atendía a la forma en la que se estructuraba la información pertinente a empleados.

No obstante, desde 2015, SuccessFactors ha estado trasladando dicho método de tratamiento de datos hacia lo que se conoce como MDF FO o MetaData Framework Foundation Objects. Hasta la fecha de hoy, los siguientes objetos se han trasladado en el nuevo formato a nuestra instancia:

• Entidad Legal.
• Unidad de Negocios.
• División.
• Centro de Coste.
• Clasificación de Puestos.
• Clasificación de Trabajos.
• Grupo de pagos.
• Calendario de pagos.

Es normal que durante los próximos años todos los objetos de nuestras instancias que, hasta la fecha se están o se han manejado a través de XML, se convertirán en MDF eliminando finalmente el uso de dichos ficheros.

Si tenemos instalado Employee Central en nuestra instancia, seremos capaces de grabar información detallada de nuestra empresa a través del Admin Center: “Gestión de datos”. En esta transacción tendremos acceso a aquellos FO que han sido convertidos a MDF FO por lo que no precisaremos del uso de ficheros XML para su configuración.

Este gran avance introducido por SuccessFactors permite a los administradores/clientes de SuccessFactors gestionar de manera independiente sus objetos de instancia. La herramienta es bastante sencilla e intuitiva lo que permite acelerar la forma en la que se transmiten los objetos a SuccessFactors y, digo transmitir, porque SuccessFactors permite importar objetos de otros sistemas como SAP ERP HCM para que estos datos no se tengan que “picar” uno a uno otra vez. Por lo que la integración también es importante en este aspecto.

Los FO (Foundation Objects) recogen información organizativa, de pago y de trabajo. Estos objetos se pueden customizar para recoger la información específica de la empresa, se pueden crear tablas de datos en SSFF a través del agrupación lógica de dichos FOs y también, se pueden crear listas desplegables que recojan información relativa a algunos de estos campos.

Podemos agrupar los Foundation Objects en tres categorías:

• Organizativa: Entidad Legal, Departamento, Divisiones, Centros de Costes, Localizaciones…,etc.
• Pagos: Calendario de Pagos, Frecuencia de Pagos, Componente de pagos…,etc.
• Trabajo: Códigos de trabajo y Funciones de Puesto de trabajo.

A continuación, mostraré la configuración de algunos objetos, siendo el más importante la entidad legal que, vendría a equipararse con la Unidad Organizativa que conocemos de SAP ERP.

No obstante, Successfactors no sólo nos permite registrar e importar datos de nuestro ERP a nuestra instancia, si no que nos permite además, customizar los Foundation Objects que deseemos para que estos se asemejen a nuestro modelo organizativo. Por ejemplo, podemos incluir asociaciones de objetos e incluso campos que completen nuestros registros de FO y satisfagan los requisitos de nuestra empresa.La entidad es la estructura organizativa más importante dentro de Successfactors. De ella cuelgan todas las demás unidades como la división o el departamento y, se asignan a los empleados que están dados de alta dentro del sistema SSFF tal y como podemos observar en la siguiente imagen:

Dicha configuración de objetos se asemeja a la ya conocida transacción del diccionario de datos en SAP ERP. Ya que, a través de la transacción “Configurar definiciones de objetos” de SuccessFactors podemos construir “tablas” con “elementos de datos” de todo tipo (string, date…) así como crear nuevos FO para posteriormente añadirles registros.

Por ejemplo, imaginemos que a nuestro registro de Entidad Legal queramos añadirle un campo obligatorio denominado “Año fundación de la Organización”. Bastaría con modificar la tabla de datos desde el diccionario de datos de SuccessFactors y añadirle nuestro elemento de datos de Fecha como se muestra en la siguiente imagen:

Una vez registrado dicho campo, podemos regresar a nuestra transacción “gestionar datos” para introducir/crear una nueva entidad legal y observar como, en efecto, nuestro nuevo campo “Año de fundación” aparece. Esto significa una gran revolución en el tema de tratamiento de datos, ya que a la hora de poder customizar los FO directamente desde el Admin Center, se puede replicar la totalidad de datos extraíbles de SAP ERP y replicar las estructuras organizativas y de personal que tengamos en nuestro sistema on-premise.

Es decir, podríamos,por ejemplo, modificar la entidad legal en successfactors añadiéndole un nuevo campo string para que ésta recogiese el OBJID de la unidad organizativa correspondiente.

Otra característica importante es el tema de las asociaciones en SuccessFactors, es decir, las relaciones entre objetos.

Hemos demostrado cómo crear entidades legales, pero dichas unidades organizativas se encuentran en una localización geográfica específica por lo que convendría crear una relación entre ambos objetos.

Desde la transacción “Configuración de objetos” podemos establecer relaciones entre los diferentes objetos y sus respectivos campos:

Gracias a dichas relaciones entre objetos podemos establecer auténticas vías de evaluación entre departamentos, divisiones y entidades legales e incluso entre posiciones de trabajo. Una vez establecidas dichas relaciones, el organigrama empresarial en SuccessFactors recordaría bastante a la PPOME de OM en SAP ERP HCM.

De todo esto podemos obtener una conclusión bastante evidente: el gran desarrollo y las amplias mejoras que últimamente se están construyendo en la solución cloud y que recuerdan en gran parte a aquellas transacciones que encontramos en SAP ERP. Está claro que en el futuro todos los objetos se definirán en MDF FO y que las mejoras de la solución cloud irán a más, por lo que creo que no podemos negar que SuccessFactors está predestinado a ser el futuro de los softwares de gestión empresarial en materia de HCM. ¿O acaso pensábamos que este día no iba a llegar?

Esperamos que este artículo te haya servido de ayuda. Si quieres, puedes ponerte en contacto con nuestro departamento de SAP RRHH

Área SAP RRHH

La entrada Un nuevo diccionario de datos en SuccessFactors se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Como visteis en artículo anterior de navegación y enrutamiento en SAPUI5, cuando se realiza la configuración de las rutas es necesario definir un patrón. En este articulo explicaré los diferentes patrones que podremos utilizar.

Cuando el hash se añade a la url, el Router realizará la comparación con los patrones configurados y navegará a la primera coincidencia. Por ese motivo, es conveniente que los patrones sean diferentes entre sí, para un correcto funcionamiento de la navegación en nuestras aplicaciones.

A continuación, veremos los dos tipos de patrones que podremos definir:

• Patrón Hard-code

El hash deberá coincidir exactamente con el patrón. Por ejemplo, si el definimos el siguiente patrón, “producto/configuración”. Únicamente, coincidirán si el hash es exactamente igual al patrón. Con este tipo de patrón, no es posible pasar datos entre vistas.

• Patrón con parámetros

Si queremos pasar datos entre vista, deberemos utilizar los patrones con parámetros. Podremos utilizar cuatro tipos de parámetros a la hora de definir los patrones.

1. Parámetros obligatorios

Puede definir parámetros obligatorios para el patrón colocando el parámetro entre llaves “{ID del parámetro}”.

Por ejemplo, si definimos un patrón “producto/{id}”, los hash-es “producto/5” y “producto/3”, coincidirán con el patrón. En cambio, el hash “producto/” no coincidirá con el patrón porque falta el parámetro obligatorio.

2. Parámetros opcionales

Puede definir parámetros opcionales para el patrón colocando el parámetro entre dos puntos “:ID del parámetro:”.

Por ejemplo, si definimos un patrón “/producto/{id}/detalle/:idDetalle:”, “idDetalle” será el parámetro opcional y “id” será el parámetro obligatorio. Si comparamos los hash-es “producto/5/detalle” y “producto/3/detalle/2”, ambos hash-es coincidirán con el patrón.

3. Parámetros de consulta

El parámetro de consulta permite pasar consultas con cualquier parámetro dentro de él. Un parámetro de consulta comienza con ?, y puede ser definido como obligatorio “producto{?query}” u opcional “producto:?query:”.

Podremos utilizar este tipo de parámetro para enviar un número de grande de parámetros, por ejemplo, “producto?id=5&detalle=7&fecha=20181221”. En la vista destino, en manejador del evento de navegación el parámetro de consulta se convertirá en un objeto, con el resto de parámetros como atributos.

4. Parámetro “rest as string”

Un parámetro que finaliza con un asterisco * se denomina parámetro “rest as string”. Es posible definir el parámetro como obligatorio “{detalle*}” u opcional “:detalle*:”.

Por ejemplo, si definimos un patrón “producto/{id}/:detalle*:”, el parámetro “id” será obligatorio y el parámetro “detalle” será opcional del tipo “rest as string”.  Si comparamos los siguientes hash-es “producto/5/3” y “producto/5/detalle/3/foo”, ambos coincidirán con el patrón. Al obtener el valor del parámetro detalle, en el primer caso recibiremos el valor “3” y el segundo “detalle/3/foo”.

Gracias a los diferentes tipos, podemos crear el patrón que mejor se adecue a nuestras necesidades, de una manera sencilla y clara.

Esperamos que este artículo te haya resultado de interés para realizar la configuración de las rutas con patrones.  Puedes dejarnos tu pregunta en comentarios o ponerte en contacto con nuestro departamento de User Experience e Integración.

Área User Experience e Integración

SAP UI5: Navegación y Enrutamiento

La entrada SAP UI5 · Navegación y Enrutamiento: patrones se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....

Para que sea posible reportar a la AEAT en los términos que especifica, es necesaria la implementación de las siguientes BADI´s proporcionadas por SAP:

• Los datos maestros de los terceros, tal que la razón social.
• La descripción que corresponda a cada operación.
• Las referencias catastrales de los locales de negocio que se encuentren alquilados.

Datos maestros clientes y proveedores

Para la implementación se accede a la SE19 e implementamos la BADI_FIESSII_MASTER_DATA, clase ZCL_FIESSII_MATER_DATA.

Activamos el método CHANGE_PARTNER_DETAILS, en el cual añadiremos la lógica que se necesite.

Descripción de la operación

La agencia tributaria requiere que se cumplimente la descripción de la operación con un texto libre que puede ocupar 500 posiciones. En principio no va a validar este campo, pero se supone que se utilizara para posibles inspecciones o cuando haya duda sobre las facturas que se están enviando.

Para la implementación se accede a la SE19 e iplementamos la BADI_FIESSII_INVOICE_DETAILS, clase ZCL_FIESSII_INVOICE_DETAILS.

Activamos los dos métodos:

• CHANGE_OUTGOING_INVOICE.
• CHANGE_INCOMING_INVOICE.

Referencias catastrales

Las empresas con arrendamientos de locales de negocios sin retención, deben informar de la referencia catastral al SII. Por ello, hay que implementar la BADI de las referencias catastrales para aquellos arrendamientos no sujetos a retención.

Al SII, sólo se debe enviar la clave de localización y la referencia catastral. A día de hoy, según los datos de la AEAT están definidas las siguientes claves :

• Clave 1. Inmueble con referencia catastral situado en cualquier punto del territorio español, excepto País Vasco y Navarra.
• Clave 2. Inmueble situado en la Comunidad Autónoma del País Vasco o en la Comunidad Foral de Navarra.
• Clave 3. Inmueble en cualquiera de las situaciones anteriores pero sin referencia catastral.
• Clave 4. Inmueble situado en el extranjero.

La BADI, que tiene el nombre BADI_FIESSII_REAL_ESTATE, se puede implementar con el nombre de la clase ZCL_FIESSII_REAL_ESTATE para el método FILL_REAL_ESTATE_DETAIL.

Esperamos que este artículo te haya servido para conocer qué BADI’s existen en SAP para la Implementación del SII en España. Puedes dejarnos tus preguntas en comentarios o ponerte en contacto con nuestro área de SAP Finanzas.

Área SAP Finanzas

La entrada ¿Qué BADI’s existen en SAP para la implementación del SII en España? se publicó primero en Blog de SAP: Actualidad SAP, Business Intelligence, SAP HCM, Abap....