Está en la página 1de 6

Especificación para ampliación del proceso de entrada para el IDOC

WPUKSR
Justificación
Actualmente, la contabilización en SAP ECC de transacciones generadas en el punto de
ventas se lleva a cabo de forma consolidada mediante la generación de IDOCs en SAP
POSDM para ventas (agrupadas por Tienda/Fecha/Artículo) y medios de pago (agrupados
por Tienda/Fecha/Medio de Pago). El flujo de información para este proceso es el siguiente:

POS
POS PI ECC
DM

XML Ventas Detalladas IDOCs acumulados Ventas


(WPUUMS) y Medios de Pago
(WPUTAB)

Dado que le información desde POSDM hacia ECC se integra de forma consolidada, no existe
el nivel de detalle requerido para generar el informe fiscal “Libro de Ventas”
correspondiente a las tiendas en ECC.

Descripción de la solución
Para cubrir el requerimiento se debe enviar la información estadística de cajero
correspondiente a cada tienda desde POSDM hacia ECC y almacenarla en una tabla para la
construcción del reporte “Libro de Ventas”. Como parte de la solución se realizaron las
siguientes actividades en los diferentes componentes del landscape.
• PI: Mapeo de campos fiscales del XML hacia POSDM.
• POSDM: Generación de IDOC WPUKSR con datos estadísticos de cajero. Algunos
campos fueron reutilizados para alojar datos fiscales que son requeridos para el
reporte en ECC.
• ECC: Activación de tabla S122 como parte de las estructuras del SIR (Sistema de
Información de Retail) para alojar datos enviados por POSDM en el nuevo IDOC
implementado WPUKSR. Adicionalmente se realizo la construcción del reporte
“Libro de Ventas”.
El nuevo proceso de integración quedaría de la siguiente manera:

POS
POS PI ECC
DM

XML Ventas Detalladas con datos fiscales IDOCs acumulados Ventas


(WPUUMS) y Medios de Pago
(WPUTAB).
IDOC de estadísticas de cajero
(WPUKSR)

Requerimiento de desarrollo
La contabilización del IDOC WPUKSR resulta en la actualización de la tabla S122 en base a
su respectiva clave primaria que se presenta en la imagen siguiente:

De manera estándar, si no existe un registro que coincida con la clave primaria de la tabla
se procede a la creación con los valores contenidos en el IDOC, de lo contrario se actualizan
los valores del registro mediante la sumatoria de todos los campos numéricos que no
forman parte de dicha clave.

En condiciones normales el envío del IDOC WPUKSR que se realiza al final del día (una vez
cerradas las tiendas) debería llevar a cabo la creación de registros nuevos en la tabla S122
pero dado que la transmisión de datos desde el POS hacia POSDM es muy susceptible a
interrupciones por motivos de diversa índole, es muy probable que se presenta la situación
de ventas rezagadas, lo cuál desencadenaría envíos posteriores de IDOCs WPUKSR de fechas
previamente enviadas y se llevaría a cabo la actualización de registros en la tabla S122
sumando los nuevos valores de campos numéricos enviados en éste IDOC “delta”.

Este comportamiento estándar de sumarización es adecuado para todos los campos


involucrados en el proceso a excepción de 2 de ellos que fueron reutilizados y requieren
una lógica particular que es la que se va a implementar en el UserExit:
• Primera factura del día: Almacenado en AZBRT.
• Última factura del día: Almacenado en AZBON.

Los campos del IDOC WPUKSR que son preparados por la tarea de POSDM son los
siguientes:
Lo que se requiere es activar un UserExit en SAP ECC durante el procesamiento del IDOC
WPUKSR de tal forma que se gestionen los valores de los campos AZBRT y AZBON en caso
de que la operación a ejecutar sea una actualización del registro.

Detalle de la ampliación
Se debe activar un UserExit para el procesamiento del IDOC WPUKSR para aplicar la lógica
necesaria a fin de que los campos S122-AZBRT y S122-AZBON conserven los valores
requeridos para el proceso.

Para el procesamiento de éste IDOC existen 4 UserExits posibles según se muestra en la


tabla siguiente:

Se estima que el componente que se debe implementar es EXIT_SAPLWPUE_123 con la


lógica siguiente.

El parámetro principal para el desarrollo de la lógica es I_INTERFACE, en el cual se leerán


los datos actuales del IDOC en la tabla I_INTERFACE- input_idoc_segments y únicamente los
segmentos a modificar deben agregarse en la tabla
I_INTERFACE- output_changed_idoc_segments.
Seguidamente la estructura del parámetro I_INTERFACE.

Nota: en la lógica que se define a continuación todos los campos de E1WPK01 y E1WPK02
pertenecen a I_INTERFACE- input_idoc_segments

• Iterar sobre cada registro de la tabla I_INTERFACE- input_idoc_segments.


• De cada segmento E1WPK01 tomar la fecha del campo VORGDATUM para los
segmentos E1WPK02 hijos.
• Buscar en la tabla S122 si existe un registro creado usando la clave siguiente:
o S122-SPTAG = E1WPK01-VORGDATUM
o S122-WERKS = I_INTERFACE-INPUT_IDOC_CONTROL-RCVPRN
o S122-KBDNR = E1WPK02-KASSIERER
o S122-KASNR = E1WPK02-KASSID
• Si NO se encuentra registro en la tabla S122, se finaliza el procesamiento para el
registro actual.
• De lo contrario.
o Se procede a efectuar la comparación del campo AZBRT de la siguiente
manera:
§ Si S122-AZBRT <= E2WPK02-AZBRT
• Crear registro en
I_INTERFACE-output_changed_idoc_segments como copia
de E2WPK02 con el campo E2WPK02-AZBRT = 0.
§ De lo contrario
• Crear registro en
I_INTERFACE-output_changed_idoc_segments como copia
de E2WPK02 con el campo E2WPK02-AZBRT = E2WPK02-
AZBRT – S122-AZBRT.
o Se procede a efectuar la comparación del campo AZBON de la siguiente
manera:
§ Si S122-AZBON >= E2WPK02-AZBON
• Crear o actualiza el registro en
I_INTERFACE-output_changed_idoc_segments como copia
de E2WPK02 con el campo E2WPK02-AZBON = 0.
§ De lo contrario
• Crear o actualiza el registro en
I_INTERFACE-output_changed_idoc_segments como copia
de E2WPK02 con el campo E2WPK02-AZBON = E2WPK02-
AZBON – S122-AZBON.

Actualmente existe un proyecto creado en la transacción CMOD para la activación de el exit


EXIT_SAPLWPUE_123.

También podría gustarte