Pedido 
Objetivo
Traslados de stock dentro del sistema y entre sistemas
En el futuro, el usuario no necesitará distinguir entre las clases de documento UB y NB. Puede crear varios pedidos de traslado como pedidos estándar. En estos pedidos, la condición previa para las órdenes de traslado entre sistemas es que, en el Sistema R/3 de gestión de pedidos, se hayan creado como proveedores todos los centros suministradores posibles. Dentro de un pedido puede crear varias posiciones con centros receptores diferentes. Estas posiciones pueden pertenecer a la misma sociedad que el centro suministrador o a otra sociedad. Los traslados dentro de una sociedad o multisociedades se pueden procesar utilizando el mismo pedido.
Flujo de procesos
Comunicación entre el pedido y la entrega
· Crear el pedido
Cuando crea un pedido con una entrega de salida en otro sistema, se crea también una posición de entrega no verificada a partir de un reparto de pedido. En ese momento se desactivan las comprobaciones de disponibilidad. La fecha y la clase de entrega son criterios de partición.
Pedidos creados manualmente:
|
Posición 1 |
Material 4711 1. Fecha de entrega de reparto 6.1 2. Fecha de entrega de reparto 15.6 |
|
Posición 2 |
Material 4712 1. Fecha de entrega de reparto 6.1 |
La transición a una entrega no verificada se realiza tal y como se indica a continuación:
|
1. Entrega no verificada:
|
Posición 1 Posición 2 |
Material 4711 1.6. Material 4712 1.6 |
|
2. Entrega no verificada: |
Posición 1 |
Material 4711 15.6. |
· Modificar el pedido
Si, en una posición de pedido, modifica cualquier dato relevante para la expedición, la posición se entrega de nuevo. Se reemplaza cualquier posición de entrega existente no verificada.
· Borrar el pedido
Cuando borra una posición de pedido, se borran también todas las posiciones de entrega correspondientes. Si ya existe una posición de entrega verificada, la posición de pedido no se borra.
La interfase BAPI Pedido con el método Pedido.GetDetail está a su disposición para visualizar el pedido. Esta BAPI posee funciones válidas para todos los sistemas.
Lanzamiento de la entrega
El sistema verifica si el sistema suministrador es gestionado en forma residente en otro sistema. En tal caso:
· El sistema se salta la determinación de los datos de expedición en el pedido cuando el centro suministrador es gestionado en forma residente en otro sistema.
· La clase de entrega se graba en el documento de compras y se transmite al LES (Sistema de Ejecución de Logística).
· Se anulan las actualizaciones del índice de vencimiento de envío.
· Se crea una entrega no verificada en el LES.
· Se transmite al LES un registro de cada reparto abierto del pedido (abierto significa que la cantidad pedida > la cantidad entregada de una entrega verificada). Esto ocurre también cuando se hacen modificaciones en el pedido. La interfase es tan amplia [incluye textos, mercancías peligrosa (procesamiento en reja)] que el sistema ya no necesita leer datos del pedido.
· Se ha mejorado el control para la determinación de la clase de entrega utilizando la asignación de clase de documento “ centro suministrador, de modo que, en la tabla relevante, podrá incluir una clase de entrega diferente para posiciones de traslado dentro de la sociedad y multisociedades.
· En el sistema de pedido no se podrá efectuar ninguna programación de expedición para traslados de stock válidos para todos los sistemas. Si el sistema de pedido está conectado con SAP APO, APO se encarga de realizar la programación de expedición. Por eso deben introducirse los datos en la interfase ATP y los resultados deben transferirse al LES. Si el sistema de pedido no está conectado con un sistema SAP APO, sólo se transmite al LES la fecha preferente de entrega.