Diseño - Integración

DISEÑO FUNCIONAL

Detalles del Requerimiento

Descripción Modificación de Orden de Consultor Ileana D’ Lima
breve Compra
Modulo MM

ID INT. PTP-M-370 Fecha 04/02/2020

BPD Pedidos de compras con MPP

Como trabajara la integración.

Anexo Perú 04/02/2020

1. Descripción
Tanto Legado como el negocio indican que PMM Perú tendrá la misma estructura y funcionalidad que PMM Chile,
este anexo de ERI es para extender la Funcionalidad de ERI PTP-M-370 a las siguientes Sociedades de Perú:

2. Tablas de Homologación
Se deberá trabajar en las siguientes homologaciones, para considerar los valores propios Perú:

Tabla: ZCENTROCORREO

NOMBRE_LEGADO PAIS CORREO NOMBRE

PMM PE correo@Falabella.cl Nombre

Se amplía para tenga en cuenta el país, este dato lo debe tomar del tag de Header del mensaje. <Pais>PE</Pais>

3. Detalle

El Propósito de la ERI es registrar las “Cancelaciones Posiciones de Pedidos de Compra PMM”. Esta integración
contempla obtener las Cancelaciones sobre las OC (Perú) generadas y aprobadas en el legado que se encuentren es
estado cancelada.
 Diseño - Integración

Dado que las reglas de negocio y estructura de paquete serán idénticas a las de Tottus Chile, se podrá énfasis en las
homologaciones que deben realizarse para que esta Integración funcione para Perú.

4. Alcance

la presente integración se extiende a las Sociedades:

SOC FI RUT DESCRIPCION SAP PAIS

P009 20508565934 HIPERMERCADOS TOTTUS S.A PE
P010 20393864886 HIPERMERCADOS TOTTUS ORIENTE S.A.C PE

5. Validación
Se continúan usando todas las validaciones actuales que existen en PRD, para la integración.

6. TAG – Proxy
Grabación para pruebas en 120: PTP-M-370 PERÚ 04.02.2020 12:51:31

Request:

<n0:ModificarPedidosCompraRequest xmlns:n0="urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra">
<Header>
<Id_Mensaje>String 1</Id_Mensaje>
<Fecha>1999-01-24</Fecha>
<Pais>String 2</Pais>
<Sociedad>String 3</Sociedad>
<Legado>String 4</Legado>
 Diseño - Integración

<codigoInterfaz>String 5</codigoInterfaz>
</Header>
<Item>
<GUID>String 6</GUID>
<NumeroPO>String 7</NumeroPO>
<NumeroOC>String 8</NumeroOC>
<Posicion>
<idposicion>String 9</idposicion>
</Posicion>
<Posicion>
<idposicion>String 10</idposicion>
</Posicion>
</Item>
<Item>
<GUID>String 11</GUID>
<NumeroPO>String 12</NumeroPO>
<NumeroOC>String 13</NumeroOC>
<Posicion>
<idposicion>String 14</idposicion>
</Posicion>
<Posicion>
<idposicion>String 15</idposicion>
</Posicion>
</Item>
</n0:ModificarPedidosCompraRequest>

Confirmation:
 Diseño - Integración

Notification:

7. Notificación – Correo
Se continua con el usa de la lista de distribución de correos que será actualizable en el futuro. Esta lista de distribución
debe ser utilizada por la integración para notificar a los usuarios responsables del proceso por cada sociedad FI respecto
del resultado de la integración, este control debe ser supervisado por quien genere el envío de la Orden de Compra con
la finalidad de resguardar que todas hayan sido traspasadas a SAP. SE USARÁ EL FORMATO ACTUAL DE CORREO QUE
EXISTE PARA CHILE.

Usuario Mail
Ronald Mayute RMAYAUTE@falabella.com.pe

Carmen Segura CLSEGURA@falabella.com.pe

María Pellón MPELLONY@falabella.com.pe

 Diseño - Integración

Actualmente el mensaje de error es el siguiente:

En la solicitud de la ERI de ajustar el mensaje de correo podemos evidenciar que actual solo cumple con el NRO. OC, Se
Solicita la modificación del asunto del Correo donde se agreguen unos campos: Nro Integración(<codigoInterfaz>)
Sociedad(<Sociedad>) y el Nro.OC(<NumeroPO>), este último campo se colocará a nivel de detalle debido a que
pueden venir varias OC en un mismo envió.

Asunto: Error en integración NRO INTEGRACIÓN – LEGADO – SOCIEDAD – FECHA

Ejemplo:

Asunto: Error en integración PTP-M-370-PMM-P009-20200204

Detalle Correo:

Id N.
Guid Texto Mensaje
Mensaje Mensaje
911B496744BC0118E0530A170EA180E1 / NRO
ZMM 048 El pedido T000000860 no está registrado en SAP
OC

8. Resultado del Proceso

 Dado que es una extensión a ERI PTP-M-370 se debe informar tal como lo hace actualmente.

Se debe almacenar el estado de envío (exitoso o con errores) a SAP

Si durante el proceso de conversión y validación de datos el proceso resulta Ok, SAP deberá responder a PMM el
OK del bloqueo sobre las posiciones informadas.

Si durante el proceso de conversión y validación de datos se identifican errores, el proceso debe ser suspendido
solamente para los Pedidos de Compras que presenten problemas y los errores reportados a los usuarios de la lista
de distribución de correos creada para tal fin.
 Diseño - Integración

9. Alcance Técnico

R.01 Si la Posición informada por PMM tiene “Recepción” en SAP: quedará con “Flag de Entrega Final”.
Funcionalidad SAP: Si tiene EM recibida parcial a esta posición se le marcara el indicador de entrega
final, si la EM es recibida total este indicador se marca de forma automática, para indicar que la posición
está concluida y el sistema no permita recibir más mercancía.

R.02 Si la Posición informada por PMM no tiene “Recepción” en SAP: se colocará el “Indicador de
Bloqueo”.
Funcionalidad SAP: Si la OC No tiene EM recibida, a esta posición se le colocará el candado de bloqueo,
es decir, EKPO-LOEKZ = S

R.03 En el asunto del correo de errores se debe informar: Sociedad – País – Nro Integración. En cuerpo
del correo el Nro. Además de incluir los mensajes de error. (Este nuevo requerimiento se informó en el
punto anterior).

1.- Comunicación de mensajes empaquetados.

2.- Se debe enviar SYS_GUID hexadecimal por mensaje (Empaquetado)
3.- Cada registro debe tener un identificador estándar del tipo GUID/UUID no superior a 32 caracteres
4.- Si se reenvía el mismo SYS_GUID hexadecimal de anulación de posiciones de una orden de compra (SKU) no se
contabilizará nuevamente y se responderá que ya está contabilizado en SAP.

En caso de errores en algún registro del paquete, se contabilizarán todas las cancelaciones de OC que estén sin
errores y se entregara el detalle del error de aquel N° de documento que no se pudo bloquear, el que puede ser
reenviado desde el legado en otro paquete.

Funcionalidad SAP: Responderá un mensaje indicando que la orden de compra ya está modificada.

El mensaje de confirmación es a través de un SP publicado en la base del legado.

10. Información del sistema legado

Jesús Cordova (X) Entrada ( ) Salida
Responsable del Tipo Interfaz
sistema legado
( ) Síncrona (Ej.: Una consulta) HT:
Espera Respuesta (X) Asíncrona Promedio diario: 2,700
(X) Con respuesta Valor máximo: 33,000
Cantidad de
( ) Sin respuesta
Registros
HTO:
aproximados
Promedio diario: 330
Valor máximo: 2,200
 Diseño - Integración

Modo de Reproceso de () Total (x ) Delta

() Batch (x ) Online
ejecución errores

Sistema ( ) File Frecuencia ( ) Anual ( ) Mensual

(X) JDBC (Respuesta) ( ) Semanal ( ) Diario
(X) SOAP (Request) (X) A Pedido
( ) Otros ________________ ( ) Otro
(¿cuál?) Cada 5 minutos

Cantidad de C10 ( ) SI
Campos (X) NO
Campos a
Homologar

Acción en SAP (X) Nueva ( ) A Convertir

( ) NO Tipo
(X) SI
Datos Adicionales

El sistema deberá devolver el resultado de la ejecución, en caso que haya sido exitoso, devolver un OK y el número
del Pedido en SAP, si fue un error, devolver el error para que Legado proceda a ejecutar nuevamente.
El reproceso de la orden es responsabilidad de Legado y en caso de error, deberá corregir los datos y enviar
nuevamente.
En caso de tener error funcional en la ejecución de la BAPI, guardar Log en SLG1.
Se requiere que si existe una anomalía en la comunicación de Legado con PO se debe enviar un email al
responsable del proceso, con ello se pueden realizar acciones de mitigación.
Para el caso de los reintentos que son por fallas que no sean funcionales se definirá el siguiente lineamiento
(Guaranteed Delivery)
 Se debe garantizar el la Cancelación de la Orden de Compra a SAP. Esto permitirá automatizar el proceso
de Orden de Compra, asegurando el flujo del proceso. Para lograr esto, se almacena un SYS_GUID de
mensaje y campo de Status para determinar que se debe volver a enviar la Orden de Compra en caso de
no obtener el mensaje de confirmación.
 El Estatus de los mensajes es “CONFIRMADO” y “ENVIADO”. El estatus cambia a CONFIRMADO cuando se
recibe el mensaje de confirmación desde SAP y debe ser eliminado de la tabla de control de estatus. Para
el caso de ENVIADO debe programarse un job que reenvíe los mensajes que no tienen confirmación. La
cantidad debe ser de 5 reintentos con un intervalo de 30 minutos entre cada intento. Si por algún motivo
este patrón no logra la confirmación en el 5to intento se debe enviar una alerta por parte de PMM que no
fue posible realizar el envío de la Orden de Compra y se debe revisar los datos con los cuales fue
solicitado.
 Diseño - Integración

11. Casos de Prueba

Caso Descripción Resultados esperados

Cancelar Pedido de Cancelar Pedido desde PMM Pedido en SAP cerrado correctamente
PMM hacia SAP sin errores

Cancelar pedido con Se realiza el cambio de estado en PMM Pedido en SAP modificado correctamente
Recepción parcial de en y debe llegar a SAP el nuevo estado
PMM
Cancelar pedido total Se realiza el cambio de estado en PMM Pedido en SAP modificado correctamente
en PMM y debe llegar a SAP el nuevo estado

Cancelar OC con En SAP ya queda con indicador de entrega final

recepción Total

Cancelar OC en dólares En SAP ya queda con indicador de entrega final

con recepción total

Cancelar OC en dólares En SAP queda con indicador de entrega final

con recepción parcial

Volver a enviar PO debe enviar al Legado la respuesta informada

cancelación de pedido previamente
 Diseño - Integración

Descripción Chile 29/08/2018

El objetivo de esta integración es el bloqueo de todas o algunas posiciones de pedidos de compras (PO)
nacionales originado en el sistema de PMM PERU siempre y cuando no exista entrada de mercancías o el
ingreso sea igual a cero.

Para la implementación se propone el uso de una la bapi “BAPI_PO_CHANGE” enmascarada a través de un

proxy y con una respuesta asíncrona con los resultados de bapi.

Tratamiento de Errores
Los mensajes de sistema propios de la creación del pedido deben ser trasmitidos al sistema de origen para su
tratamiento.

Alertas No aplica.

Requerimientos de Monitoreo
Descripción: Necesidad de la transacción de dejar logs de las tareas realizadas
Se usará el registro estándar en el log de aplicaciones.

Otras Consideraciones
No aplica

Lógica de Procesamiento

Siglas y convenciones usadas en este documento:

BP: Business Partners.

Tag o Etiqueta: Se refiere indistintamente un elemento XML.
Nodo: Etiqueta XML para agrupar un conjunto de elementos XML que corresponden a una misma entidad.

Antecedentes y supuestos:

Esta interfaz de entrada parte del supuesto que el documento enviado por el sistema legado, sistema de
origen de la interfaz, trae los siguientes datos:

Datos a nivel general del documento:

 Diseño - Integración

Lógica de Procesamiento
1. Número de orden de compra SAP.

Datos a nivel de ítem para cada ítem del documento:

2. Número de la posición del pedido PMM, equivalente al correlativo único.

El mensaje XML tiene definidos los siguientes nodos y cardinalidad:

Nodo Padre Nodo Cardinalidad Comentario

(nodo raíz) <PO> 1..1 Documento raíz.
PO <Cabecera> 1..1 Datos de cabecera.
PO <Item> 1..N Items.

Los elementos que conforman estos nodos son:

Dato de Origen Nodo padre Tag XML Tipo de Cardi- Restricción de valores
dato nalidad
Número OC <Cabecera> <NumeroOC> Char(10) 1..1

Identificador de <PMG_DTL_TECH_ 1..1

posición <Item> KEY>

Importante: El contenido de todos los tags enviados debe respetar la longitud máxima, así como las
restricciones específicas de valores, si es el caso.

Log de aplicaciones:

Todos los mensajes de sistema (informativos, advertencia y error) deben ser registrados en el log de
aplicaciones estándar (transacción SLG1), con su consiguiente código numérico. En caso de que el mensaje
no sea estándar (Z), debe ser generado dentro de una clase de mensaje Z y con un código de error
independiente para cada mensaje. No se debe usar mensajes de sistema genéricos (mensaje 000).

El “Nivel de clasificación Log de App.” debe ser asignado en función del tipo de mensaje de sistema a
registrar. Los mensajes de error se clasifican como nivel 2, “Importante”; los de advertencia como nivel 3
“Medio”; e informativos como nivel 4, “Información adicional”.
 Diseño - Integración

Lógica de Procesamiento
Todas entradas al log de aplicaciones de este desarrollo deben quedar registradas en la siguiente jerarquía:
Objeto: Según los lineamientos del área de integraciones & desarrollos.
Sub-objeto: Según los lineamientos del área de integraciones & desarrollos.
ID Externo: valor de POHEADER-PO_NUMBER
Clase de mensaje, para mensaje Z: Según la definición de mensajes Z definidos para PTP

La fecha de expiración de todas las entradas en log de aplicaciones debe corresponder a los lineamientos
del proyecto.

Considerar el uso de SLG1 para manejo de logs.

Objeto: Z+Negocio+País = Z+Negocio+PE

SubObjeto: PedidosCompra

Negocio = Se obtiene con la función de BRF+ ZSOCIEDADESPORNEGOCIO entrando con SOCIEDAD

País = Tabla T001 - LAND1

Lógica para el mapeo de campos de la interfaz propiamente dicha

Para bloquear la o las posiciones del pedido de compras SAP, se deberá primero igualar con el número de
orden de compra de PMM.
Se debe extraer también la posición del pedido PMM que se necesita bloquear.

Se deben considerar las siguientes validaciones previo bloqueo de la(s) posición(es):

- Debe existir
- No debe estar borrada
- No debe estar bloqueada
- No debe tener entrada de mercancía ni total ni parcial.

Se sugiere utilizar la BAPI: BAPI_PO_CHANGE, agregar el número de orden de compra SAP al

PURCHASEORDER.

La posición del pedido PMM que se debe bloquear se encuentra en el campo EKET-LICHA de la orden de
compra SAP (detallado en documento PTP-M-352 Pedidos de Compras desde PMM).
 Diseño - Integración

Lógica de Procesamiento

Los parámetros en la BAPI serán:

DELETE_IND = S (con S la posición queda bloqueada)

Verificar que EKPO-MENGE = 0

Finalmente, EKPO-LOEKZ = S

Luego, la BAPI también deberá considerar marcar el flag “Concluida” agregar el “motivo”: Z003
Estructura: VERSIONS
Completed: X
Reason: Z003

El mapeo de esta interfaz consta de tanto de datos generales del documento como datos a nivel de
posición.

Se debe construir una tabla paramétrica donde se almacene usuario y dirección de correo electrónico cuyo
objetivo será notificar a los usuarios responsables del proceso por cada sociedad FI respecto del resultado
de la integración, este control debe ser supervisado por quien genere el envío de la Orden de Compra con la
finalidad de resguardar que todas estas anulaciones hayan sido traspasadas a SAP.

Usuario Mail
 Diseño - Integración

Lógica de Procesamiento

Queda a criterio del área PO si crea una nueva o utiliza una que ya exista y se utilice para otra interfaz.

Datos de cabecera

Corresponden a los datos generales del documento, y son completados mediante el llenado de los campos
en las estructuras: POHEADER, POHEADERX, de la bapi sugerida.
La lógica para llenar las estructuras antes mencionadas y sus campos es:

01.- Numero de pedido

Campo: PURCHASEORDER: 6900000057
Lógica: Se trata del número de orden de compra SAP.

Datos de posición

Corresponden a los datos de los ítems del documento, y son completados mediante el llenado de los
campos en las estructuras: POITEM y POITEMX.
La lógica para llenar las estructuras antes mencionadas y sus campos es:
Corresponden a los datos de los ítems del documento y son completados mediante el llenado de los campos
en las estructuras: POITEM de la BAPI sugerida

101.- Numero posición de ítem

Campo: POITEM-VENDRBATCH
Lógica: corresponde al código único que representa la posición del pedido PMM.

Envío de mensajes de respuesta a PMM.

El objetivo de este mensaje de respuesta es comunicarle al sistema legado el resultado del intento de
modificar el pedido de compras en SAP.
 Diseño - Integración

Lógica de Procesamiento

El mensaje de respuesta debe consistir en el envío de la tabla de respuesta que retorno SAP al ejecutar la
BAPI, tabla RETURN.

Si hubiera algún incidente en la comunicación con el legado, este debe ser registrado en el log de
aplicaciones.

Adicionalmente se debe registrar en el log de aplicaciones un mensaje de sistema informativa con el texto
“&1|&2|&3| Orden de compra de legado finalizando proceso.”, donde &1 corresponde a la sociedad SAP
según la tabla de homologación de sociedades, &2 corresponde al identificador del legado, y &3
corresponde al número de orden de compra según el legado.

Control de procesamiento:
El sistema legado enviara un identificador único por cada documento a crear en SAP (OC, Pedido, Comprobante
contable) que debe ser de tipo UUID largo de 32 caracteres. Con este dato el mensaje viajará a SAP con un UUID de
mensaje que se utilizará con propósitos de monitoreo y un UUID por cada documento que requiera generar para
evitar duplicidad en la creación de documentos.
 Diseño - Integración

Lógica de Procesamiento
Flujo de GUID

Legado PO S4H

Enviar interfaz

GUID
Entregar a S4H GUID

Validar existencia de
GUID
GUID en tabla Z

NO

¿Existe?
SI

GUID/
N°SAP Enviar N° de
documento SAP al
legado
Enviar N° de
documento a legado

Ejecutar BAPI
GUID/
N°SAP
NO

¿Ejecución OK?
SI

Asociar GUID a
GUID/Cod documento
Error

GUID/Cod
Error
Actualizar Estado y Grabar GUID, N°
número SAP para el documento y fecha
GUID SYS en tabla Z

Enviar respuesta a
legado

Estructura Tabla Z:

Campo Nombre Técnico Tipo

Mandante Mandt mandt
GUID GUID Char32
Documento SAP docSAP Char10
Fecha Datum Sy-datum
Sociedad Bukrs bukrs
 Diseño - Integración

Lógica de Procesamiento

Reglas de procesamiento.
Ejemplo de procesamiento.
Caso 1: Envío nuevo GUID (32000000000000000000000000000001) Legado  S4H

 Se valida campo en tabla Z.

 Como no existe, Ejecuta BAPI creando exitosamente el documento SAP
 Se crea registro en tabla Z asociando GUID, Documento SAP, fecha y sociedad
 Se retorna relación al sistema legado
Caso 2: Envío GUID 32000000000000000000000000000001

 Se valida campo en tabla Z

 Como el GUID ya existe, no aplica ejecución de BAPI
 Se obtiene documento SAP asociado al GUID
 Se retorna relación al sistema legado
Caso 3: Envío nuevo GUID 32000000000000000000000000000002

 Se valida campo en tabla Z

 Como no existe, ejecuta BAPI teniendo errores que impiden la creación del documento
 Se retorna registro GUID junto a los errores indicados por la BAPI
Caso 4: Reenvío GUID corregido 32000000000000000000000000000002

 Se valida campo en tabla Z

 Como no existe, ejecuta BAPI creando exitosamente el documento SAP
 Se crea registro en tabla Z asociando GUID, Documento SAP, fecha y sociedad
 Se retorna relación al sistema legado

Pruebas
 Diseño - Integración

Caso Descripción Resultados Datos de prueba

esperados

001 Bloquear posición de Pedido en SAP Documento en legado con escenario

Pedido desde PMM bloqueado descrito.
hacia SAP sin errores. correctamente.

002 Bloquear posición de Mensaje de Documento en legado con escenario

Pedido que tenga error. descrito.
ingresos de mercancía.

003 Bloquear posición de Mensaje de Documento en legado con escenario

Pedido que se error. descrito.
encuentre borrada.

004 Bloquear posición de Mensaje de Documento en legado con escenario

Pedido que se error. descrito.
encuentre bloqueada.
 Diseño - Integración

Documentación Técnica – PO
Descripción de interfaz
COD PTP-M-370 NOMBRE Modificación Pedidos de Compra desde PMM
Vertical:
Sistema Origen Sistema Destino Tamaño Máximo de Mensaje (KB)
Destino PMM SAP 1 KB
Descripción El objetivo de esta integración es el bloqueo de todas o algunas posiciones de pedidos de
compras (PO) nacionales originado en el sistema de PMM Perú siempre y cuando no exista
entrada de mercancías o el ingreso sea igual a cero.

Para la implementación se propone el uso de una la bapi “BAPI_PO_CHANGE” enmascarada

a través de un proxy y con una respuesta asíncrona con los resultados de bapi.
Modo Operación Asíncrono Síncrono
Respuesta Sí No
Activación Bloque de posición de Órdenes de Compra
Objeto de Negocio PedidosCompra
Tipo de Integración IDOC Proxy Otra
con SAP
Dirección (con Inbound Outbound
respecto a SAP)
Nivel de Complejidad Alta Media Baja Muy Baja
Modo de ejecución Tiempo Real Batch
Periodicidad de Diaria Semanal Mensual Anual
ejecución Trimestral Por Demanda Otra:_____
Persistencia Estándar
Módulos Impactados FI CO SD MM BW Otros PM
Analista Técnico Gabriel Rivera

Características de la etapa de envío

Etapa de Envío: Al realizar la liberación de Orden De Compra, se debe gatillar la interfaz hacia S4H.

2700 bloqueos de
órdenes de Compra 2700 bloqueos de órdenes de
diarias Compra diarias
Peak Estimado de
Nº Estimado de Mensajes/Día
Mensajes/Min
 Diseño - Integración

Hora de Fin (si

Hora de Inicio (si procede)
procede)
Formato Envío (XML, IDOC, XML Formato Recepción XML
etc.) (XML, IDOC, etc.)
Nº Campos de Mapeo N/A Timeout (si procede) 10 Seg.

Características de la etapa de respuesta (si procede)

Etapa de Respuesta: Una vez creada o no la Orden de Compra en SAP, este devuelve un status de creación hacia
PMM

1700 bloqueos de
1700 bloqueos de órdenes de
órdenes de Compra
diarias Peak Estimado de Compra diarias
Nº Estimado de Mensajes/Día
Mensajes/Min

Formato Envío (XML, IDOC, XML Formato Recepción XML

etc.) (XML, IDOC, etc.)
5 10 Seg.
Nº Campos de Mapeo Timeout (si procede)

Definición estructura SAP

Creación de Tipo Base IDOC (si la interfaz se define con IDOC)
Elemento
COD Segmento Tabla Campo Obl. Rep. Descripción
de datos
SEG1
SEG2

Tratamiento de errores de integración (reproceso técnico)

Introducir aquí el contenido si aplica o no

Asignación del módulo de funciones de entrada / salida al tipo mensaje

Introducir aquí el contenido si aplica o no

Acuerdos de interlocutor
Introducir aquí el contenido

Tratamiento de errores de IDOC

Introducir aquí el contenido
 Diseño - Integración

Definición PROXY
Estructura: BAPI_PO_CREATE1

Pac Pr
Service Interface Namespace SWCV kag efi
e x
ModificarPedidosCompraR urn:Falabella.cl:S4H:GestionAbastecim F_I_S4H_GESTIONABA ZPTP ZPO
equest_Inb iento:PedidosCompra STECIMIENTO
ModificarPedidosCompraC urn:Falabella.cl:S4H:GestionAbastecim F_I_S4H_GESTIONABA ZPTP ZPO
onfirmation_Out iento:PedidosCompra STECIMIENTO
ModificarPedidosCompraN urn:Falabella.cl:S4H:GestionAbastecim F_I_S4H_GESTIONABA ZPTP ZPO
otification_Out iento:PedidosCompra STECIMIENTO

Estructura de Datos y Requerimiento de Transformación de Datos.

Numero de Flujo Sistemas Entrada, Salida y Mapeo PROXY
001 PMM - S4H
002 S4H - EMAIL

Requisitos Especiales.
<identificación validaciones, formatos y reglas especiales de validación de datos>

N° Descripción.
N/A N/A

DATOS PROPIOS DE LA INTEGRACION (sección dedicada a consultor PO)

System Landscape Directora.
Product Software Component Technical Business System
System
F_PMM F_I_PMM_GESTIONABASTECIMIENTO PMM_D PMM_PE_D
F_S4H F_I_S4H_GESTIONABASTECIMIENTO F4D S4H120_D
F_PI F_B_PI_GESTIONABASTECIMIENTO N/A N/A
F_PI F_A_PI_GESTIONABASTECIMIENTO N/A N/A
F_PI F_C_PI_COMMON N/A N/A
F_EMAIL F_I_EMAIL_GESTIONABASTECIMIENTO EMAIL_D EMAIL_D
 Diseño - Integración

Integration Builder Design – REQUEST

Resumen Diagrama de Flujo – REQUEST

Data Type
Nombre ModificarPedidosCompra
Namespace urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
Software Component F_B_PI_ GESTIONABASTECIMIENTO
Versión
Estructura

Estructuras
PTP-M-370.xlsx

Message Type
Nombre ModificarPedidosCompraRequest
Namespace urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
Software Component F_I_PMM_GESTIONABASTECIMIENTO
Version
Data Type Relacionado ModificarPedidosCompra
Namespace data type urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
 Diseño - Integración

relacionado
Target namespace urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra

Service Interface
Nombre ModificarPedidosCompraRequest_Out
Namespace urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
Software Component F_I_PMM_GESTIONABASTECIMIENTO
Version
Estructura relacionada ModificarPedidosCompraRequest
Namespace relacionado urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
Categoría Inbound Outbound
Modo Asincrónico Sincrónico

Service Interface
Nombre ModificarPedidosCompraRequest_Inb
Namespace urn:Falabella.cl:S4H:GestionAbastecimiento:PedidosCompra
Software Component F_I_S4H_GESTIONABASTECIMIENTO
Version
Estructura relacionada ModificarPedidosCompraRequest
Namespace relacionado urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
Categoría Inbound Outbound

Modo Asincrónico Sincrónico

Integration Builder Configuration Scenario – REQUEST.

Configuration Scenario
Nombre ModificarPedidosCompra

Integrated Configuration

ICO: Configuración de la integración que contiene los servicios para chile.

Communic
ation Party

Communic PMM_PE_D
ation
Componen
t

Interface ModificarPedidosCompraRequest_Out
 Diseño - Integración

Interface urn:Falabella.cl:PMM:GestionAbastecimiento:PedidosCompra
Namespac
e

Inbound Communication Channel

Processing
SOAPSenderModificarPedidosCompra

Receiver Condition Communication Communication Component Receiver

Party

S4H120_D

Receiver Condit Operati Interface Namespace

Interfaces ion on
Mappin
g

ModificarPedidosCompraR urn:Falabella.cl:S4H:GestionAbastecimient
equest_Inb o:PedidosCompra

Outbound Communication Channel

Processing
SOAPXIReceiverModificarPedidosCompra_PMM_PE

Communication Channel

Party
Communication Component PMM_PE_D
Nombre SOAPSenderModificarPedidosCompra
Adaptador BC CIDX File HTTP_AAE IDoc_AAE JDBC
JMS
Mail RFC AS2 HTTP IDoc SOAP
WS
REST Otro:_________
Configuración Adaptar Type: SOAP
Transport Protocol: HTTP
Message Protocol: SOAP 1.1
XMBWS.Timeout 10000
 Diseño - Integración

Communication Channel

Party
Communication Component S4H120_D
Nombre SOAPXIReceiverModificarPedidosCompra_PMM_PE
Adaptador BC CIDX File HTTP_AAE IDoc_AAE JDBC
JMS Mail RFC AS2 SOAP WS
REST Otro:
Configuración SOAP / HTTP / XI
HTTP Destination: S4DCLNT120
XMBWS.Timeout 10000

Integration Builder Configuration Scenario – CONFIRMATION.

Resumen Diagrama de Flujo - CONFIRMATION.
 Diseño - Integración

Enterprise Service Repository – CONFIRMATION.

Data Type
Nombre ResultadoTransaccion
Namespace urn:Falabella.S4H:Common
Software
F_I_S4H_COMMON
Component Version

Estructura
Estructuras
PTP-M-370.xlsx

Data Type

Nombre EnvioRespuestaSqlStmt
Namespace urn:Falabella.cl:PI:Common:Structures
Software
F_C_PI_COMMON
Component Versión

Estructura
Estructuras
PTP-M-370.xlsx

Message Type
Nombre EnviarResultadoTransaccionConfirmation
Namespace urn:Falabella.cl:S4H:Common
Software
F_I_S4H_COMMON
Component Version
Data Type
ResultadoTransaccion
Relacionado
 Diseño - Integración

Namespace data
urn:Falabella.cl:S4H:Common
type relacionado
Target namespace urn:Falabella.cl:S4H:Common

Message Type
Nombre EnvioRespuestaSqlStmt
Namespace urn:Falabella.cl:PI:Common:Structures
Software
F_C_PI_COMMON
Component Version
Data Type
EnvioRespuestaSqlStmt
Relacionado
Namespace data
urn:Falabella.cl:PI:Common:Structures
type relacionado
Target namespace urn:Falabella.cl:PI:Common:Structures

Service Interface
Nombre ModificarPedidosCompraConfirmation_Out
Namespace urn:Falabella.cl:S4H:GestionAbastecimiento:ModificarPedidosCompra
Software
F_I_S4H_GESTIONABASTECIMIENTO
Component Version
Estructura
EnviarResultadoTransaccionConfirmation
relacionada
Namespace
urn:Falabella.cl:S4H:Common
relacionado
Categoría Outbound
Modo Asincrónico

Service Interface
Nombre ModificarPedidosCompraConfirmationSqlStmt_Inb
Namespace urn:Falabella.cl:PMM:GestionAbastecimiento:ModificarPedidosCompra
Software
F_I_PMM_GESTIONABASTECIMIENTO
Component Version
Estructura
EnvioRespuestaSqlStmt
relacionada
Namespace
urn:Falabella.cl:PI:Common:Structures
relacionado
Categoría Inbound
Modo Asincrónico
 Diseño - Integración

Message Mapping
Nombre EnviarResultadoTransaccionConfirmation_to_EnvioRespuestaSqlStmt
Namespace urn:Falabella.cl:PI:Common:Mappings
Software
F_A_PI_ GESTIONABASTECIMIENTO
Component Version
Estructuras EnviarResultadoTransaccionConfirmation
Relacionadas Origen urn:Falabella.cl:S4H:GestionAbastecimiento:ModificarPedidosCompra
Estructuras EnvioRespuestaSqlStmt
Relacionadas
Destino urn:Falabella.cl:PI:Common:Structures
Definición de Mapeo Se reutiliza completamente

Operation Mapping
ModificarPedidosCompraConfirmation_Out_to_ModificarPedidosCom
Nombre
praConfirmationSqlStmt_Inb
Namespace urn:Falabella.cl:PI:GestionAbastecimiento:ModificarPedidosCompra
Software
F_A_PI_ GESTIONABASTECIMIENTO
Component Version
Mapeos
EnviarResultadoTransaccionConfirmation_to_EnvioRespuestaSqlStmt
Relacionados
Operaciones ModificarPedidosCompraConfirmation_Out
Relacionados Origen urn:Falabella.cl:S4H:GestionAbastecimiento:ModificarPedidosCompra
Operaciones ModificarPedidosCompraConfirmationSqlStmt_Inb
Relacionados
urn:Falabella.cl:PMM:GestionAbastecimiento:ModificarPedidosCompra
Destino

Integration Builder - CONFIRMATION

Configuration Scenario
Nombre ModificarPedidosCompras

Integrated Configuration
Commu
nicatio
n Party
Commu
nicatio
n S4H120_D
Compo
nent
Interfac
ModificarPedidosComprasConfirmation_Out
e
Interfac urn:Falabella.S4H:RegistrosContables:ModificarPedidosCompras
 Diseño - Integración

e
Names
pace
Inboun Communication Channel
d
Process SOAPXISenderModificarPedidosComprasConfirmation
ing
Communication
Condition Communication Component Receiver
Party
Receive
PMM_PE_D
r

Con
ditio Operation Mapping Interface Namespace
n
IF
Receive LEG
r ADO
Interfac = ModificarPedidosCompraConfirmat urn:Falabella.cl:PMM:GestionAbast
ModificarPedidosCom
es PM ion_Out_to_ModificarPedidosCom ecimiento:ModificarPedidosCompr
prasConfirmation_Inb
M praConfirmationSqlStmt_Inb a
&&
PAIS
= PE
Outbou Communication Channel
nd
JDBCReceiverModificarPedidosComprasConfirmation
Process
ing

Communication Channel
Party
Communication S4H120_D
Component
Nombre SOAPXISenderModificarPedidosComprasConfirmation
Adaptador SOAP
Configuración SOAP / Sender / HTTP / XI
XMBWS.Timeout 10000

Communication Channel
Party
Communication PMM_PE_D
Component
 Diseño - Integración

Nombre JDBCReceiverModificarPedidosComprasConfirmation
Adaptador JDBC
Configuración JDBC Driver: oracle.jdbc.OracleDriver
Connection: Por Definir
User Name: Por Definir
Password: Por Definir
XMBWS.Timeout 10000
Disconnect from database after processing each message

Enterprise Service Repository - NOTIFICATION

Enterprise Service Repository – NOTIFICATION

External Definition
Nombre Mail
Namespace urn:Falabella.cl:PI:Common:Mail
Software Component F_C_PI_COMMON
Version
Archivo a importar

Service Interface
 Diseño - Integración

Nombre ModificarPedidosCompraNotification_Out
Namespace urn:Falabella.cl:S4H:GestionAbastecimiento:PedidosCompra
Software Component F_I_ S4H_GESTIONABASTECIMIENTO
Version
Estructura relacionada External Definition: Mail – Mail
Namespace relacionado urn:Falabella.cl:PI:Common:Mail
Categoría Inbound Outbound
Modo Asincrónico Sincrónico

Service Interface

Nombre ModificarPedidosCompraNotification_Inb
Namespace urn:Falabella.cl:EMAIL:GestionAbastecimiento:PedidosCompra
Software Component F_I_EMAIL_ GESTIONABASTECIMIENTO
Version
Estructura relacionada External Definition: Mail – Mail
Namespace relacionado urn:Falabella.cl:PI:Common:Mail
Categoría Inbound Outbound
Modo Asincrónico Sincrónico

ntegration Builder - NOTIFICATION

Configuration Senario
Nombre ModificarPedidosCompra

Integrated Configuration

Communicat
ion Party

Communicat S4H120_D
ion
Component

Interface ModificarPedidosCompraNotification_Out

Interface urn:Falabella.cl:S4H:GestionAbastecimiento:PedidosCompra
Namespace

Communication Channel
 Diseño - Integración

Inbound SOAPXISenderModificarPedidosCompraNotification
Processing

Receiver Conditi Communication Party Communication Component Receiver

on

EMAIL_D

Receiver Conditi Operati Interface Namespace

Interfaces on on
Mappin
g

ModificarPedidosCompraNotificati urn:Falabella.cl:EMAIL:
on_Inb GestionAbastecimiento:PedidosC
ompra

Outbound Communication Channel

Processing
MAILReceiverModificarPedidosCompraNotification

Communication Channel

Party
Communication S4H120_D
Component
Nombre SOAPXISenderModificarPedidosCompraNotification
Adaptador BC CIDX File HTTP_AAE IDoc_AAE JDBC
JMS Mail RFC AS2 SOAP WS
REST Otro:
Configuración SOAP / HTTP / XI
XMBWS.Timeout 10000

Communication Channel
 Diseño - Integración

Party
Communication EMAIL_D
Component
Nombre MAILReceiverModificarPedidosCompraNotification
Adaptador BC CIDX File HTTP_AAE IDoc_AAE JDBC
JMS Mail RFC AS2 SOAP WS
REST Otro:
Configuración SMTP / XIPAYLOAD / Receiver
Servidor:
smtp://correoseguro.falabella.cl:25
Usuario: SAP-PO-PREPROD@falabella.cl
Pass:
Use Mail Package
Content Encoding: base64
XMBWS.Timeout 10000
 Diseño - Integración

Documentación Técnica – ABAP

Fecha Actual Fecha Entrega
(dd/mm/aaaa) (dd/mm/aaaa)

Objetos (Solo en utilización de PROXY)

[Incluir en esta sección un inventario de los objetos que componen y serán utilizados en el
desarrollo, indicando tablas, programas, funciones, etc. Listar todos los objetos, ya sean nuevos
o existentes. En caso de requerir la creación de tablas, estructuras, elementos de datos o campos
específicos incluir un detalle de cada uno. Eliminar este comentario en la versión final del
documento.]
Short Description Program ID Object Type Object Name
Administrar GUID ZPOCL_MODIFICAR_PEDIDOS_COMPRA Clase ZXXCL_ADMIN_GUID
Modificar OC ZPOCL_MODIFICAR_PEDIDOS_COMPRA Funcion BAPI_PO_CHANGE

Tiene relación con la llamada a programas y/o funciones necesarias para la ejecución del
proceso en SAP, ejemplo, monitoreo, clases de mensajes, funciones de formatos de campos.

Implementación
[Incluir en esta sección las consideraciones para implementar la solución en el entorno productivo,
incluyendo definiciones sobre órdenes de transporte y cualquier otro requerimiento para que su
correcta puesta en marcha. Eliminar este comentario en la versión final del documento.]
Orden Transporte Descripción Comentario
F4DK906789 WECX-PTP-M-370-Modificacion orden
de compra

Code Inspector
Diseño - Integración