Category Archives: Oracle Retail

Como instalar IGS (Integration Gateway Services) | RIB

IGS

Primero que nada, debo aclararles que IGS por sus siglas en ingles Integration Gateway Services es un sub-sistema opcional de RIB y por lo tanto debe ser instalado después de que los componentes base de RIB han sido instalados y verificados. El componente IGS provee una infraestructura de integración para sistemas externos (third party) a Oracle Retail a través de un grupo de Web Services para conectarse a RIB 13.1. Por lo tanto el mismo solo suele ser instalado en caso de necesitarlo, un ejemplo de su uso sería proveer un punto de integración entre la funcionalidad de “Currency Rates” de ORFI (Oracle Retail Financials Integrator) que permite que dado un cambio en la Tasa de Moneda realizado en el módulo de GL de EBS, el mismo llegue a RMS en su tabla CURRENCY_RATES.

Como pre-requisito para su instalación se necesita una instancia de WebLogic en una versión mayor o igual a 10.3, adicionalmente el mismo no puede ser desplegado en conjunto con el componente “rms-service“.

Para realizar la instalación solo se deben seguir los siguientes pasos:

Continue reading

Como configurar el RPMTaskMDB en multihilos en RPM | Retail Price Management 13.2

RPMTaskMDB es un bean controlado por mensajes utilizado para facilitar la capacidad de procesamiento asíncrono de RPM. El RPMTaskMDB actúa como oyente de las colas de mensajes, tan pronto como llega un mensaje en la cola, el contenedor desencadena la ejecución de este bean. Cuando una tarea de fondo es creado por RPM, se publica un mensaje a la cola como un disparador para iniciar el procesamiento de las tareas.

EJB usado por RPMTaskMDB

com.retek.rpm.app.task.service.RPMTaskAppServiceBmtEjb

Tablas usadas por RPMTaskMDB

  • Tareas actuales, historicas y pendientes por ser ejecutadas: RPM_TASK, RPM_CONFLICT_CHECK_TASK, RPM_LOCATION_MOVE_TASK
  • Tablas usadas para enviar alertas a usuarios acerca del status: ALERTS, ALERT_RECEIVER, ALERT_STATUS, ALERT_STATUS_DSC

Donde encuentras el archivo weblogic-ejb-jar.xml correcto para habilitar el multihilos en Retail Price Management (RPM)?

Para configurar la cantidad de hilos del RPMTaskMDB se debe modificar el archivo Weblogic-ejb-jar.xml 

  • Si ya tienes instalado RPM puedes encontrar este archivo en la siguiente ruta:
[WEBLOGIC_HOME]\user_projects\domains\base_domain\servers\rpm-server\tmp\_WL_user\rpm13\[SYS_GENERATED_FOLDER]\rpm13.jar\META-INF\ 
  • En caso de que vayas a instalarlo

Debes dirigirte a la carpeta donde descomprimiste el instalador de RPM (por ejemplo):

cd /u00/webadmin/media/rpm-test/rpm/application/rpm13/template/

Cambiar el archivo Weblogic-ejb-jar.xml y correr el instalador que usas para RPM como usualmente lo harías y de esta manera se desplegara con la configuración indicada.

  • Y finalmente cambiar la propiedad max-beans-in-free-pool dentro del archivo Weblogic-ejb-jar.xml:
   <weblogic-enterprise-bean>
      <ejb-name>RPMTaskMDB</ejb-name>
        <message-driven-descriptor>
           <pool>
           <max-beans-in-free-pool>5</max-beans-in-free-pool>
           </pool>     
         <destination-jndi-name>@task.queue@</destination-jndi-name>
      </message-driven-descriptor>
      <reference-descriptor>
      </reference-descriptor>
  </weblogic-enterprise-bean>
  <weblogic-enterprise-bean>
      <ejb-name>RPMChunkMDB</ejb-name>
        <message-driven-descriptor>
           <pool>
           <max-beans-in-free-pool>5</max-beans-in-free-pool>
           </pool>     
         <destination-jndi-name>jms/chunkQueue</destination-jndi-name>
      </message-driven-descriptor>
      <reference-descriptor>
  </weblogic-enterprise-bean>

¿Cómo podemos determinar el valor que se utilizará en el campo max-beans-in-free-pool?

Este valor depende de la configuración de hardware. Puede modificar el valor en función de su número de CPU.

Nota: la información de este articulo aplica para la versión de RPM 13.2, para más detalle se puede consultar la documentación de oracle.

Venta de pre-empacados en RMS (Retail Merchandising System)

pre-empacados en RMS

Un pre-empacado es un elemento que consta de varios artículos que se venden como uno solo. Estos artículos se venden generalmente como una unidad como un beneficio para el consumidor, ya sea por conveniencia o ahorro de precio. La estrategia es, por lo tanto, para animar al cliente a comprar más.

El paquete puede contener diferentes elementos y / o múltiplos del mismo artículo, estos artículos pueden venir de diferentes departamentos y/o de múltiples proveedores / países de origen.

Por defecto el precio de venta será la suma del costo de los componentes más el margen del departamento del paquete, pero puede ser cambiado.

Así mismo, el pre-empacado no se puede ordenar o transferir a menos que el paquete está configurado como vendible y pueda ser “pedido”. Por consiguiente el inventario es mantenido y se puede visualizarse a nivel del componente del artículo. El “inventario” del pre-empacado se puede ver cuando se le solicite de forma manual, pero no se mantiene en Retail Merchandising System (RMS). RMS permite a los usuarios ver el inventario de los artículos del pre-empacado a través de la pantalla “Sellablle Pack Build (packbld.fmb)”  en el menú de inventario.

Finalmente si la venta al por menor del paquete ofrece un descuento, el descuento se prorratea a través de los elementos componentes en el momento de la venta y se mostrará como una rebaja en el registro de acciones. Por el contrario si la venta al por menor del paquete es mayor que la suma de la venta al por menor de los componentes, el excedente será prorrateado a través de los elementos componentes en el momento de la venta.

Qué es EDI y como funciona dentro de Retail Merchandising System (RMS)?

Que es EDI

La intención de este articulo es proporcionar algunos consejos sobre la funcionalidad de EDI dentro de RMS y cómo desactivar el almacenamiento de ventas diarias en la tabla EDI_DAILY_SALES.

¿Qué es EDI?

EDI (Intercambio Electrónico de Datos) proporciona un método para minoristas y proveedores para transmitir documentos de la empresa. El programa traductor de EDI convierte archivos de entrada o salida a archivos planos o formato EDI según corresponda.

Los batchs EDI de RMS crean un archivo de salida si los datos se están transmitiendo al proveedor o aceptan un archivo de entrada iniciado por el proveedor. En todos los casos, el archivo es traducido por la aplicación de software de traducción de EDI del cliente.

Cómo utilizar el EDI?

Se debe indicar qué transacciones EDI están soportadas por el proveedor. Si el proveedor solicita la actividad del producto, se puede indicar si los datos deben ser transmitidos sobre una base diaria o semanal.

También se debe indicar la variación permitida para cambios en los costos por importe monetario y en función del porcentaje. cambios en los costos recibidos del proveedor que se encuentran dentro del rango tolerado se aprueban automáticamente por el sistema después de aceptar los cambios.

Algunas generalidades sobre EDI

La tabla EDI_DAILY_SALES contiene información de ventas diarias de SKUs de proveedores que transmiten informes diarios de actividad a través de EDI. Se llevará a cabo los volúmenes de ventas de SKU en la ubicación y el nivel de fecha de la transacción.

La tabla sólo tendrá información sobre las ventas regulares. Ésta será definida durante el procesamiento de archivos POSUPLD.

Los registros serán purgados de acuerdo con el indicador de EDI_DAILY_RPT_LAG en la tabla SYSTEM_OPTIONS.

En caso de que no se utilice la funcionalidad de intercambio electrónico de datos (EDI), se puede detener el llanado de datos en la tabla EDI_DAILY_SALES ajustando del campo EDI_SALES_RPT_FREQ a el valor ‘W‘ en la tabla SUPS, generando que las ventas e información de inventario sean descargados semanalmente y por lo tanto la tabla EDI_DAILY_SALES no se actualice.

¿Cómo se elimina la información de la tabla EDI_DAILY_SALES?

Para eliminar la información de la tabla EDI_DAILY_SALES solo se debe ejecutar el job “post processing” para el batch EDIDLPRD.

En caso de necesitar mas información, pueden consultar la documentación de RMS en Oracle.

Promociones basadas en tiempo en Retail Price Management (RPM)

Promociones Basadas en tiempo

A partir de la versión 13.2.4 de Retail Price Management (RPM) se incorporó la funcionalidad de Promociones Basadas en tiempo como “Happy Hour” o “door-buster”.

Las versiones anteriores de RPM permitían a los usuarios introducir el tiempo (en horas: minutos) en el marco de las fechas de inicio y final respecto a la creación y mantenimiento de las promociones; sin embargo, esta información no se almacenaba en las tabla RPM_FUTURE_RETAIL y por lo tanto no viajaba al punto de venta (POS).

Esta funcionalidad puede ser usada para los siguientes tipos de promociones:

  • Promociones simples
  • Promociones con umbrales
  • Promociones Multi-compra

Adicionalmente para las promociones simples se pueden cargar a través del batch de inyección de precios en la tabla RPM_STAGE_PROMO_COMP_SIMPLE.

Para más información pueden visitar la documentación oficial de RPM.

Como atender un soporte de segundo nivel de un flujo de batchs de Oracle Retail

oracle_res10_rev052610

A continuación les comparto un checklist que realice hace mucho tiempo como base para tomar acciones al momento de ser notificados de una falla en un job de UC4 durante la ejecución del batch nocturno de Oracle Retail.

  • Si un job aborta y no es un error conocido, se debe exigir al área que esta reportando que cree un caso referente al problema donde adjunten los logs del error.
  • Si un job aborta y al revisar el log se observan mensajes referentes a conexión (por ejemplo: timeout, no conectado a oracle, no more data t oread from socket, etc) los mismos deben ser re-ejecutados.
  • Si un job aborta y no es por error de conexión, se debe evaluar si al ser re-ejecutado aún tendrá disponible la información que utiliza como entrada para su procesamiento. (Por ejemplo el job batch_saimptlogi)
  • Si un job aborta debido a que dejó registros rechazados, se deben respaldar los archivos rechazados (.rej) comprimidos en un archivo zip al ticket de soporte que fue creado para reportar el error.
  • Si un job aborta y no es un error conocido, se deben evaluar las siguientes premisas:
    1. ¿Qué hace el job y cuál es el impacto de dejarlo para el día siguiente? (apoyarse en el operation guide de Oracle Retail)
    2. Validar el código fuente hasta identificar en qué punto está fallando; en caso de que sea por unos datos inválidos, los mismos deben ser respaldados en una tabla temporal y el job re-ejecutado solo con la información correcta para dar continuidad a los batch nocturnos. La información respalda en una tabla temporal(dentro del esquema de base de datos de la persona de guardia, ejemplo: juanrodriguez.tabla_numerocaso, abarreto.tran_data_numerocaso) debe ser documentada en su respectivo ticket de soporte e incluir el ultimo archivo de log de ejecución del job
    3. Revisión dentro de oracle support con el mensaje de error que aparece en el log de UC4.
    4. En caso de no conseguir el error y después de haber agotado las opciones anteriores, se debe llamar al backup de guardia y pedir apoyo para solucionar el mismo, si aun así no se consigue solución se debe llamar al líder de Equipo para definir las acciones a seguir.
  • Antes de las 6 de la mañana se debe enviar un correo con el status del Oracle Retail Batch indicando los acontecimientos del mismo y los números de tickets que fueron abiertos.
  • Una vez finalizado el batch de Ventas se debe responder al correo anterior y anexar el status del mismo

Documentación de UC4 (AppWorx)

Documentación de UC4

UC4 es una aplicación utilizada para la automatización de procesos en background, normalmente utilizada para grandes sistemas como los utilizados en bancos, retailers, empresas de seguros, telecomunicaciones; esto con la finalidad de establecer grandes flujos de procesos donde existen muchos pequeños programas que se deben ejecutar con dependencias, de manera paralela, con condiciones, y un sin fin de posibilidades para atender las necesidades del negocio.

Esta herramienta funciona instalando un agente en el servidor donde se encuentran los correspondientes programas operativos y que será el encargado de ejecutarlos según la configuración que se realice para el mismo.

Entre las tecnologías que pueden ser ejecutadas por UC4 se encuentran: pro*c, c, c++, pl/sql, shell script, RETL, JAVA y cualquier tipo de binario que resida en el servidor donde es instalado el agente.

Para mas información pueden entrar en la pagina de http://www.appworx.com/ o consultar el “user guide” con la documentación de la versión 8 de esta aplicación: Documentación UC4

Un ejemplo de un flujo puede ser el siguiente:

flujo uc4

Como monitorear las tablas MFQUEUE en Oracle Retail?

Debes realizar un monitoreo constante de las tablas MFQUEUE con el fin de poder detectar cuando un mensaje se quedado atrapado en alguna de estas colas, en caso de que el mensaje no sea consumido se debe revisar el adaptador correspondiente.

Para esto ejecuta el siguiente query:

Y validar que para cada tabla existen 0 registros, en caso contrario monitorear el comportamiento tomando en cuenta que los valores deberían reducirse a cero paulatinamente…