A menudo debo hacer frente a preguntas difíciles sobre los entornos actuales de impresión y una que suele aparecer con frecuencia es: «¿Por qué a veces desaparece el output de mi SAP cuando uso SAPSprint?».
En primer lugar, mi opinión es que SAPSprint NO es la causa del problema. No obstante, dado que SAPSprint usa el spooler de Windows para crear y entregar el output, esta solución puede que no sea suficientemente fiable en algunas circunstancias determinadas si el output de SAP implica impresiones automáticas, en una estación de trabajo o sin supervisión.
SAPSprint es una solución ideal para SAP, ya que le proporciona toda la libertad de las fuentes y los dispositivos de la impresión Windows (un tipo de dispositivo, auténtica impresión Unicode). Además, es un servicio sencillo de instalar.
Desde el punto de vista del sistema, el usuario imprime desde SAP usando el tipo de acceso («Access Type») «S» en un servidor de impresión Windows que ejecuta SAPSprint. Con esta configuración, algunas personas indican que en ocasiones pierden un output vital cuando llevan a cabo una impresión automática.
Cuando imprime desde un sistema Windows, si un trabajo desaparece no suele ser un gran problema. Si el usuario va a la impresora y no encuentra su trabajo, vuelve a su escritorio y lo reimprime: problema resuelto. Sin embargo, en el caso de la impresión automática de SAP, el output generado (por ejemplo, una lista de envíos, una etiqueta de un pedido o una etiqueta de producto) resulta crítico para la empresa y para el proceso logístico.
Si uno de estos documentos no se imprime, en el mejor de los casos se producirá un retraso en un proceso logístico urgente (como la salida de un camión) y, en el peor, podría perderse por completo el pedido o el envío. Debido a que el proceso logístico o de pedido se inicia en otro lugar, el trabajador del almacén no «se espera» ese output... el desencadenante de la siguiente fase del proceso de negocio es el propio output impreso. Así que, en este caso, un output extraviado equivale a la ruptura de un proceso de negocio.
Hace unos años, el equipo de desarrollo de SAP y yo trabajamos juntos en una solución global para imprimir de forma fiable el output producido por SAPSprint. Me enorgullece decir que funciona muy bien y resuelve este problema.
Examinemos la opción «omsprint» para SAPSprint de SAP y veamos cómo resuelve el problema. La nota SAP 1545557 http://service.sap.com/sap/support/notes/1545557 afirma lo siguiente:
Es preferible SAPSprint con un sistema externo de gestión de output (OMS, por sus siglas en inglés). Esta posibilidad es especialmente interesante para aplicaciones que dependen de tipos de dispositivos genéricos SAPWIN. La nueva interfaz OMSPRINT combina las ventajas de SAPWIN (como la impresión independiente del tipo de dispositivo mediante los controladores de impresora Windows y usando cualquier fuente) con las ventajas de un OMS (como supervisión de la impresión de trabajos y confirmación de estado mediante una llamada de función remota; RFC, por sus siglas en inglés).
Para activar esta interfaz, basta con enlazar su OMS (por ejemplo, nuestro producto Enterprise Output Server) con la interfaz de la línea de comando OMSPRINT e interrumpir (y poner en manual) el servicio SAPSprint Windows. A continuación, hay que redefinir las impresoras que usan la instancia SAPSprint para usar el tipo de acceso «E» en el OMS.
El enlace entre el sistema OMS y el ejecutable OMSPRINT suele hacerse en un proceso FILTER. Los sistemas externos de gestión de output permiten que el proceso comience cuando un trabajo de impresión está listo para ser impreso en una cola (puede ser cualquier proceso, por cierto). La clara ventaja es que cualquier problema para crear, enviar o imprimir el output será detectado por el OMS y notificado directamente a la aplicación de llamada (en este caso, SAP).
De este modo, se prescinde completamente de la entrega del spool de Windows, y el OMS usa una entrega controlada PJL o ZPL para garantizar que el trabajo se imprime. Cualquier error se notifica al sistema de la aplicación SAP mediante RFC BC-XOM (o a otros controladores de la infraestructura o sistemas de incidencias, si se desea).
Por supuesto, implementar un OMS requiere una determinada inversión de tiempo y dinero. Pero tras perder otro pedido este mes y tener que lidiar con otro «cliente insatisfecho» o tener de nuevo otro retraso en sus camiones de reparto, puede que considere que merece la pena explorar esta opción.
Los sistemas EOM proporcionan muchas otras ventajas, más allá de la mera impresión ERP. Pueden reducir considerablemente los costes de su infraestructura de impresión y permitirle recuperar la inversión en cuestión de meses.
Para acabar, admito que no soy imparcial, porque trabajo para Levi, Ray & Shoup y he visto de primera mano cómo el software Enterprise Output Management puede resolver problemas como estos. Si desea más información sobre estas soluciones, haga clic aquí o póngase en contacto con LRS para estudiar el ROI y las mejoras globales esperadas en su propio entorno SAP.