Beruflich Dokumente
Kultur Dokumente
Entrega Saliente
Project End Date GD Regional Delivery GD Project Manager
Head
Table of contents
1. Program Summary..............................................................................................................................3
1.1. Definition..................................................................................................................................................4
1.2. Defined Fields...........................................................................................................................................4
1.3. Procedure..................................................................................................................................................4
2. Appendix......................................................................................................................................................9
1. Program Summary
OBJECT OVERVIEW
Business
Object ID
Process
Object Title Interfaz Entrega Saliente
PROGRAM ATTRIBUTES
SELECTION SCREEN
Selection Screen Block Name / Description -
AUTHORIZATION REQUIREMENTS
< Please fill this section if there are special Authorization Requirements; else mention N/A. Every
authorization object needs to be documented to provide the security administrator information on
the purpose and use of the object. The following sections are the minimal documentation
requirements.>
1.1. Definition
<The definition establishes the purpose and or use for the object. Is there a standard object
available to be used or custom authorization object to be created.>
1.3. Procedure
<The procedure section helps to explain how this object is to be used. Examples with field values
and explanations should be provided.>
Sample:
Entrega Saliente:
PROCESSING LOGIC
Entrega Saliente:
1. Se debe crear una clase que tenga los mtodos para extraccin de datos y el mtodo de
conexin con el proxi.
El mtodo de conexin con el proxi debe tener la lgica definida por PO.
Se debe tener en cuenta las siguientes condiciones en la clase de mensajes ZWES la cual debe
estar previamente parametrizada para las entregas salientes, para empezar a procesar la
informacin, se debe copiar el programa asociado a la clase de mensaje.
NAST-KAPPL=V2. Aplicacin
NAST-OBJKY= N entrega.Clave de objeto
NAST-VSTAT<>0. Status de proceso
Estas condiciones se validan en la clase de mensajes ZWES, para la cual se realiz la copia al
programa de control: /SPE/STO_ID_PROCESSING.
Nombre de la copia: ZWMS_STO_ID_PROCESSING,
Rutina Modificada: PERFORM check_subsequent_exist en las lneas 392 a 455
2. Extraccin de datos.
Nota: Las estructuras para la extraccin de datos deben estar definidas por PO.
Para mapear los campos contra la estructura que provee la clase de mensaje.
Se requiere un escenario de datos para identificar los campos que corresponden a los
solicitados.
El proceso de extraccin de datos del objeto de negocio se utilizando los mtodos definidos en la
clase, es necesario que los mtodos permitan obtener lo bloques de datos de manera individual.
Mtodos de extraccin:
* GET_DATA -> Mtodo que Obtiene la data llamando a mtodos de extraccin
Cadena:
- GET_CABECERA_ENTREGA: Obtiene los datos a nivel de cabecera para las entregas
ingresadas
+ GET_DIR_CLIENTE: Obtiene datos de cliente
- GET_DETALLE_ENTREGA: Obtiene los datos a nivel de detalle para las entregas
- GET_STATUS: Obtiene los estatus nivel de cabecera y nivel de detalle
Datos direccin:
Con KNA1-ADRNR ir a la tabla ADRC donde ADRC- ADDRNUMBER = KNA1-ADRNR, obtener de
esta tabla los datos:
ADRC-NAME1
ADRC-NAME2
ADRC-STREET
ADRC-HOUSE_NUM1
ADRC-POST_CODE1
ADRC-CITY1
ADRC-COUNTRY
ADRC-REGION
ADRC-TIME_ZONE
ADRC-TRANSPZONE
ADRC-PO_BOX
ADRC-POST_CODE2
ADRC-POST_CODE3
ADRC-TEL_NUMBER
ADRC-TEL_EXTENS
Nota: con ADRC- ADDRNUMBER ir a la tabla ADR2, donde ADR2- ADDRNUMBER = ADRC-
ADDRNUMBER, obtener ADR2-TEL_NUMBER
ADRC-FAX_NUMBER
ADRC-FAX_EXTENS
Nota: con ADRC- ADDRNUMBER ir a la tabla ADR6, donde ADR6- ADDRNUMBER = ADRC-
ADDRNUMBER, obtener ADR6- SMTP_ADDR
ADRC- DEFLT_COMM
ADRC-EXTENSION1
ADRC-EXTENSION2
ADRC- REMARK
LIKP-LGTOR
LIKP-CONT_DG
LIKP-ABLAD
LIKP-VSTEL
LIKP-ROUTE
LIKP-TRSPG
LIKP-AULWE
LIKP-INCO1
LIKP-INCO2
LIKP-BOLNR
LIKP-XABLN
LIKP-TRATY
LIKP-TRAID
LIKP-VSBED
LIKP-VSART
LIKP-SDABW
VTTK-TKNUM
VTTK-STREG
VTTK-DPLEN
Datos, interlocutor
De VBPA, donde VBPA-VBELN = LIKP-VBELN, obtener:
VBPA-PARVW
VBPA-KUNNR
VBPA-KUNNR
Cabecera embalar:
VEKP-EXIDV
VEKP-EXIDA
VEKP-VHILM
VEKP-BRGEW
VEKP-NTGEW
VEKP-MAGEW
VEKP-TARAG
VEKP-GEWEI
VEKP-BTVOL
VEKP-NTVOL
VEKP-MAVOL
VEKP-TAVOL
VEKP-VOLEH
VEKP-WERKS
VEKP-ERNAM
VEKP-ERLKZ
VEKP-ERDAT
VEKP-WMSTA
VEKP-VOLEH_MAX
VEKP-GEWEI_MAX
VEKP-VHART
VEKP-VHILM_KU
VEKP-PACKVORSCHR
VEKP-KZGVH
VEKP-LABELTYP
VEKP-ZUL_AUFL
Nota: para cada material LIPS-MATNR ir a la tabla MAKT, donde MAKT-MATNR = LIPS-MATNR y
MAKT-SPRAS = SY-LANGU, obtener:
MAKT-MAKTX
LIPS-BRGEW
LIPS-GEWEI
LIPS-VOLUM
LIPS-VOLEH
LIPS-CHARG
LIPS-BESTQ
LIPS-LGTYP
LIPS-LGPLA
LIPS-MAGRV
para cada posicin de la entrega, obtener de la tabla VBUP, donde VBUP-VBELN = LIKP-VBELN,
obtener:
VBUP-KOSTA
VBUP-LVSTA
LIPS-CHARG
LIPS-BWTAR
LIPS-LFIMG
LIPS-MBDAT
LIPS-MBUHR
LIPSD-PIKMG
LIPSD-VRKMP
LIPS-BRGEW
LIPS-GEWEI
LIPS-VOLUM
LIPS-VOLEH
LIPS-UNTTO
LIPS-UEBTO
LIPS-UEBTK
LIPS-KZTLF
LIPS-UEPOS
LIPS-GRKOR
LIPS-WERKS
LIPS-LGORT
LIPS-KDMAT
LIPS-EMPST
LIPS-CHSPL
LIPS-CHARG
LIPS-UMBAR
LIPS-KCMENGVME
LIPS-KCMENGVMEF
LIPS-UECHA
Resumen de status:
para cada posicin de la entrega, obtener de la tabla VBUP, donde VBUP-VBELN = LIKP-VBELN
VBUP-PKSTA
VBUP-LVSTA
VBUP-KOQUA
VBUP-WBSTA
VBUP-FKSTA
VBUP-FKIVP
VBUP-PDSTA
Nota: Con LIKP-VBELN ir a la tabla, VBPA, donde VBPA-VBELN = LIKP-VBELN, obtener VBPA-
ABLAD, este dato se refiere al puesto de descarga.
Las estructuras de outbound y de inbound son definidas por PO, para la entrada y salida de
datos del proxi.
Es requeridos que los mtodos de extraccin estn definidos de tal manera que se puedan
obtener de forma individual todos los bloques de datos necesarios.
Por ejemplo:
Se debe tener mtodos para obtener, datos de cabecera entrega, cabecera embalaje, detalle
entrega, detalle embalaje, estados, datos interlocutor, datos direccin, datos de transporte etc.
Con este procesamiento de datos es posible realizar las validaciones en WMS para la entrega y
para el documento de transporte.
Con la informacin obtenida en la consulta sobre la tabla VBUK, se deben realizar las siguientes
validaciones:
Determinar si la entrega de salida tiene relevancia a transporte:
* VBUK-TRSTA <> ''. Tiene relevancia a transporte
Condiciones:
- Si la entrega esta como pendiente por planear transporte, estatus de planificacin de
transporte = A, (VBUK-TRSTA=A), se debe mostrar por pantalla el mensaje:
La entrega est pendiente por transporte, no es posible enviarla a WMS y no debe permitir
modificar el status de envo de la clase de mensaje.
3. Documento de transporte.
Para realizar las validaciones sobre el documento de transporte se debe tener previamente
parametrizada la clase de mensajes ZWES, que se active en las transacciones VT01N, VT02N y
VT16.
Con la extraccin de datos definido con la clase, se deben validar las siguientes condiciones:
Se debe validar cuando haya una modificacin en la entrega de salida, transaccin vt02n, se debe
validar que le entrega tengan centro - almacn gestionado por WMS (Respuesta del proxi de PO).
Si las entregas cumplen las condiciones se debe permitir el cambio de status y se debe actualizar en
WMS el campo AccionCabWms con valor 'D', para todas las entregas relacionadas con el
documento de transporte que cumplan con las condiciones.
Nota: No se les debe permitir cambio de status a las entregas que no cumplan
Enviar a WMS a nivel de cabecera y detalle la informacin del cambio de status de cada una de las
entregas relacionadas con el documento de transporte.
Nota: Si al menos una entrega no cumple con las condiciones, no se debe permitir el cambio de
status del documento de transporte a no concluido y se debe mostrar el siguiente mensaje por
pantalla:
Si todas las entregas cumplen con las validaciones se debe permitir la eliminacin del documento
de transporte
Se actualiza el campo AccionCabWms con valor 'D', para todas las entregas relacionadas en el
documento de transporte.
Enviar a WMS la eliminacin de cada una de las entregas asociadas al documento de transporte, a
nivel de cabecera y transporte, mapeo definido en el proxi establecido por PO.
Nota: Si por lo menos una entrega no cumple con las validaciones definidas, no se debe permitir a
eliminacin la eliminacin del documento de transporte y se debe mostrar por pantalla el mensaje:
No es posible eliminar el documento de transporte *documento de transporte*, por que tiene
entregas en WMS en estado diferente a HOLD y/o cantidades en picking
Por medio del proxi se consulta el detalle de la orden de salida, de existir la entrega en WMS, se
realizan las siguientes validaciones.
- Que el estado de todas las posiciones de la orden en WMS permitan eliminarse definido
por el parmetros ob_lno_stt=HOLD.
- Que las posiciones de la entrega no tengan cantidades en picking en WMS definido por el
parmetro, cmp_qty=0.
En caso de no cumplir con las validaciones no se debe permitir la eliminacin de la entrega del
documento de transporte y debe mostrar por pantalla el mensaje: No es posible eliminar del
documento de transporte la entrega *entrega*, WMS no permite modificar la entrega por estado y/o
cantidades en picking.
Si la entrega no existe en WMS, (no se obtiene registros de WMS), se debe eliminar la entrega del
documento de transporte y no hacer notificacin a WMS.
Mapeo a PO.
El envo a PO se hace por medio del mtodo EJECUTAR_PROXI.
Este recibe como parmetro de entrada el N de la entrega IP_VBELN y las acciones con indicador
de actualizacin o borrado y devuelve un indicador de error que llaga en X si hay fallos en envo a
PO.
El mapeo para el proxi se hace utilizando la estructura: lwa_output la cual se llena por medio del
mtodo: set_data_proxi
Al mapeo se envan datos a nivel de cabecera, datos de direccin, gestin, transporte, datos
movimiento de mercancas, textos y datos a nivel de detalle.
En cabecera se envan:
- Entrega -> LIKP-VBELN
- Accin cabecera WMS -> Si es update o delete, A para update y D para delete
- Destinatario mercanca -> LIKP-KUNNR
- Nombre destinatario -> KNA1-NAME1
- Denominador regin -> T005U-BEZEI
Datos de direccin:
- Nmero direccin 1 -> ADRC-NAME1
- Nmero direccin 2 -> ADRC-NAME2
- Calle -> ADRC-STREET
- Poblacin -> CITY1
- Cdigo postal -> ADRC-POST_CODE1
- Primer N de telfono: ADRC-TEL_NUMBER
Datos gestin:
- Tipo orden WMS -> ZWMS_TIPOORDEN-ORDENWMS
- Fecha ent cliente -> LIKP-LFDAT
- Prioridad ent -> LIKP-LPRIO
- Fecha carga -> LKP-LDDAT
- Fecha picking -> LIKP-KODAT
- Stat conf picking -> VBUK-KOQUK
- Stat tot picking alma -> VBUK-KOSTK
- Stat plan transporte -> VBUK-TRSTA
- Secuencia carga -> 1 valor segn orden en transporte
Datos de transporte
- Cond exped -> LIKP-VSBED
- Ind gestin esp -> LIKP-SDABW
- Est registrar transporte -> VTTK-STREG
- Fecha fin carga > VTTK-DPLEN
- Doc transporte -> VTTK-TKNUM
Textos
- Textos con ID: Z009, NAME: Entrega y Objeto: VBBK
- Textos con ID: Z008, NAME: Entrega y Objeto: VBBK
Tratamiento de errores.
Hola, en la entrega de salida al llenar en el objeto de negocio los campos de estatus de cabecera y detalle de la
entrega, est colocando el estatus anterior al del ltimo cambio realizando por la transaccin VL02N, debido a
esto los valores de los estatus deben tomarse de memoria si el exit es sobre la transaccin VL02N.
Adicional a lo anterior, en la EF dice que por la VL02N solo se debe activar el proceso de integracin si ocurre
alguno de los siguientes cambios en la entrega:
Eliminacin de la entrega
Estamos encontrando que al modificar la cantidad de picking activa la integracin y no debe ser ya que no es
ninguno de los eventos anteriores.
Lo anterior est generando que al momento de hacer el picking en SAP, est enviando nuevamente a WMS la
entrega, esto no se debe hacer porque el proceso en WMS ya fue realizado.
Segn la solicitud anterior se realizan las siguiente modificaciones en los siguientes objetos:
Include: ZSD_VALIDA_ENTREGA_SALIENTE
Clase: ZCL_WMS_ENTREGA_SALIENTE
Se almacenan en estas tablas los datos en memoria de la tabla VBUP y VBUK, que estn en las tablas XVUK[] y
XVUP[] se almacenan respectivamente en las tablas LTD_ST_LIKP[] y LTD_ST_LIPS[], para obtener los status de
cabecera y detalle de la entrega.
Despus de que estas tablas internas se llenan, se crea una instancia de la clase
ZCL_WMS_ENTREGA_SALIENTE, y al llamar al constructor se pasan las tablas internas LTD_ST_LIKP[] y la
LTD_ST_LIPS[].
Se agrega la validacin de las tablas internas globales GTD_ST_LIKP[] y GTD_ST_LIPS[] si estn vacas,
si estas no estn llenas, se realiza las respectivas consultas a las tablas VBUK y VBUP.
REUSABLE CODE
FILE ATTRIBUTES
INTERNAL TABLES
Name Description
MESSAGES
SELECTION TEXT
Description
Name
S_PARTNR Business Partner
TEXT ELEMENTS
Text Description
Name
000 List Contains no text
SUBROUTINES
Description
Name
LAYOUT_BUILD Logic for building the output
At the end of the interface run, please describe the details for the output list.
Output Method
[Please indicate the expected output method(s) for the report]
Example:
Saved to File / Sent to print / Send to email account / Download to excel
Main Heading
[Provide the main heading field for the report]
Example:
The main report heading will be: Contracts Nearing Expiry
LAYOUT
Please list the sequence of the fields in which the output must be displayed?
Or embed Excel sheet layout.
TOTALING
SORTING
[List any sorting requirements for the report]
Example:
Users will be able to sort on contract type and vendor. Default sort sequence will be by contract
type.
PAGE BREAK
[Provide details of any page breaking requirements that should be used in addition to field
breaks]
Example:
Page breaks will be used where necessary to prevent overflow of retrieved data
ERROR HANDLING
[Include potential errors, notification procedures, and contingency procedures.]
Report Footer
[Please copy the Business test Conditions and Control scenarios from the FS]
[Add relevant Technical scenarios associated with this development. Examples would include 1)
testing an error-free run; 2) testing the exception processes; 3) testing the error handling.]
2. Appendix