Entrega válida para todos los sistemas
(dentro de la sociedad y multisociedades) 
Objetivo
Este escenario está disponible para cuando quiera realizar una comprobación de disponibilidad global o regional (verificación ATP). A menudo, en el Sistema SAP R/3 en el que se creó el pedido de cliente no se muestran todos los stocks/centros que hay que verificar. En el sistema SAP APO puede realizar una verificación ATP a través de sistemas SAP R/3. También puede utilizar las funciones adicionales de la verificación ATP que hay en el sistema SAP APO (por ejemplo, Verificación ATP basada en reglas). Hay, en particular, una determinación de la ubicación en la que el sistema puede determinar centros no visualizados en el sistema de pedidos de cliente. Este escenario es pues adecuado para situaciones en las que las ventas y la expedición se representan en sistemas SAP R/3 distintos.
Comparado con el escenario 
Gestión de pedidos
para terceros ALE (2 SAP R/3, 1 SAP APO), este escenario es más eficaz y
flexible cuando las modificaciones se hacen en el flujo de procesos. Esto se
debe a que los documentos de compras (solicitud de pedido y pedido) no se
crean en el sistema solicitante y no se crea ningún pedido de cliente en el
sistema suministrador.
Unaentrega multisociedades existe, básicamente, cuando la sociedad vendedora de un pedido de cliente es diferente de la sociedad suministradora y la entrega al cliente tiene lugar directamente de la sociedad vendedora sin entrada de mercancías provisional. Se crea un documento de facturación interno entre las sociedades. La sociedad vendedora factura a los clientes externos. Este proceso también se soporta dentro de flujos de mercancías válidos para todos los sistemas a través de los límites del sistema (véase también: Traslado de stock válido para todos los sistemas (dentro de la sociedad)).
Una entrega dentro de la sociedad sólo puede llevarse a cabo cuando la organización vendedora al nivel de cabecera de un documento de ventas se asigna a un nodo de centro de beneficio diferente de la organización proveedora a nivel de posición y la sociedad no varía. En este caso, debería realizarse una liquidación de centro de beneficio entre los dos centros de beneficio. El precio de traslado dentro de la sociedad debería visualizarse en el pedido de cliente.
En este escenario, las entregas dentro de la sociedad se pueden convertir en entregas válidas para todos los sistemas si el centro suministrador se gestiona, a nivel de posición, en un sistema diferente al de ventas.
Condiciones previas
· A continuación se indican condiciones previas del sistema para implementar entregas válidas para todos los sistemas:
¡ SAP R/3 Enterprise Core
¡ Plug-in 2001.2
¡ SAP APO Rel. 3.0A
· Debe haber realizado las parametrizaciones para los precios de traslado en el Customizing (véase también: Parametrizaciones Customizing para entregas válidas para todos los sistemas)
Para más información sobre la integración técnica entre SAP APO y un sistema SAP R/3, véase la documentación SAP APO – Advanced Planner and Optimizer ® Escenarios empresariales de gestión de cadena logística (GCL) ® Integración SAP APO y SAP R/3.
· En el Customizing de ALE para la clase de interlocutor (LS - sistema lógico), fije el IDOC Deliveryprocessing_execute. Para hacerlo, seleccione Base ® Application Link Enabling (ALE) ® Modelación e implementación de procesos empresariales ® Acuerdos entre interlocutores EDI y tiempo de procesamiento ® Actualizar el acuerdo entre interlocutores EDI manualmente. En el sistema de pedidos de cliente, actualice la clase de mensaje Deliveryprocessing_execute como parámetro de salida para el sistema lógico de gestión de expedición. Actualice esta clase de mensaje como parámetro de entrada para el sistema lógico de la entrada de pedidos de cliente.
Flujo de procesos
El diagrama siguiente muestra una entrega válida para todos los sistemas (dentro de la sociedad) entre dos sistemas SAP R/3 con un SAP APO conjunto.
...
1. Usted crea un pedido de cliente en el sistema de pedidos de cliente. En la pantalla inicial, seleccione la clase de orden y los datos organizativos.
2. En la pantalla de entrada de pedidos, introduzca los datos de cabecera seguidos de los datos de posición. Tiene dos opciones:
...
a. Introduzca su propio centro (centro en el sistema de pedidos de cliente)
b. Introduzca un centro externo (de otro Sistema SAP R/3 dentro del grupo empresarial de sistemas).
La Ayuda para entradas le muestra los posibles centros, incluidos los externos (cuando introduce el Sistema SAP R/3 lógico relevante). El sistema también puede proponer automáticamente el centro basándose en los datos del registro maestro de deudor, el registro maestro de materiales o el registro de información para cliente y material.
Se aplican las restricciones siguientes:
¡ Para procesar posiciones con centros externos necesita un modelo de integración activo. Al actualizar el modelo CIF, hay una opción de entrada adicional para centros externos.
¡ No puede utilizar ninguna bonificación en especie.
¡ La configuración con centros externos no es posible.
¡ No puede utilizar stock para pedido de cliente ni valorado ni no valorado.
¡ No se ofrece soporte para la fabricación contra pedido.
¡ No puede hacer imputaciones de los costes ni del rendimiento del pedido de cliente.
¡ Los planes de entregas para la industria abastecedora (véase también en el menú SAP: Logística ® Comercial ® Ventas ® Plan de entregas ® Crear; con la clase LZ) y las necesidades primarias de cliente (véase también en el menú SAP: Logística ® Producción ® Planificación de la producción ® Gestión de demanda ® Necesidad de cliente ® Crear) no se soportan para centros externos.
¡ El flujo indirecto de documentos no está disponible para ninguna evaluación auto-programada. Esto no afecta al sistema SAP estándar.
¡ Las órdenes inmediatas no son posibles para posiciones con centros externos.
¡ La necesidad de gestión de lotes debe definirse para todos los centros.
¡ La determinación de división de centro-división (regla 001 en el Customizing para la imputación de división) no es posible para centros externos.
¡ Para las verificaciones ATP basadas en reglas no se utilizan ni la región, ni el municipio, ni la ciudad.
¡ No se pueden definir puestos de expedición ni almacenes para centros externos y, por lo tanto, no se pueden convertir en valores propuestos en el pedido de cliente.
¡ En el sistema de pedidos de cliente, no se reconoce el calendario de fábrica para centros externos. En el transporte y la programación de transporte (que se puede realizar también en SAP APO), el sistema tiene en cuenta el calendario SAP APO para el almacén suministrador (centro). Tampoco se reconocen los horarios de trabajo/turnos del puesto de expedición. Se pueden asignar utilizando el calendario parcial SAP APO actualizable.
¡ El número de cliente de centros externos no se conoce, de modo que no se puede utilizar para grupos de artículos ni para determinaciones de precio relacionadas.
¡ No se conoce la característica de planificación de necesidades para materiales en centros externos, de modo que no se puede utilizar para asignar y verificar tipos de reparto en el pedido de cliente.
¡ La posición en el pedido también debe tener una clase de necesidad para centros externos (determinación mediante el tipo de posición y la característica de planificación de necesidades inicial).
¡ Las necesidades de centros externos no son visibles en el sistema de pedidos de cliente (vista stock/necesidades).
3. En SAP APO, se realiza una verificación ATP de acuerdo con las opciones de las Instrucciones de verificación. Para sustituciones de ubicación, se puede encontrar una ubicación desconocida en el sistema de llamada (centro externo). El centro que se encuentra es trasladado al sistema de pedidos de cliente.
4. Cuando se graba el pedido en el sistema de pedidos de cliente, se transfiere al sistema SAP APO utilizando la interfase SAP APO Core Interface. En el grafo de pedidos SAP APO, se crean también las necesidades para las posiciones del pedido que tienen centros externos (no se crea ninguna necesidad para estas posiciones en el sistema de pedidos de cliente).
5. A continuación, se borra definitivamente cualquier Asignación temporal de cantidad creada durante la verificación ATP en SAP APO.
6. Grabe el pedido en el sistema de pedidos de cliente.
Restricciones:
¡ La verificación del límite de crédito en el pedido sólo es posible si existen los datos relevantes del sistema suministrador, es decir, los datos de salida de mercancías, estadísticas, etcétera. Las estadísticas válidas para todos los sistemas sólo se pueden obtener utilizando los exits de cliente.
¡ El transporte y la programación de transporte deben estar activados. De lo contrario, deberá actualizar estos datos posteriormente de forma manual en el pedido de cliente.
7. El sistema de venta envía el IDOC Deliveryprocessing_execute, con los datos del pedido de cliente, al sistema de expedición.
8. El IDOC se procesa en el sistema de expedición según las opciones establecidas en el Customizing ALE.
9. Se crea una Entrega no verificada en el sistema de expedición según la parametrización de fecha de entrega en el pedido de cliente. Como en el escenario integrado, donde puede crear varias entregas para un pedido de cliente, en este escenario puede crear también varias entregas no verificadas para un pedido de cliente (criterio de partición). Para cantidades restantes sin confirmar no se crea ninguna entrega no verificada.
10. La entrega no verificada se transmite al sistema SAP APO utilizando el Core Interface Model de SAP APO. El sistema SAP APO recibe como referencia el número del pedido de cliente correspondiente a cada posición de entrega. El sistema crea entonces necesidades para la entrega no verificada en el grafo de pedidos del sistema SAP APO. Además, se borran las necesidades de la posición de pedido de cliente referenciada.
11. El sistema crea también una necesidad para la entrega no verificada en el sistema de expedición. La necesidad en la entrega no verificada tiene un indicador de planificación de necesidades diferente al de la entrega (o categoría en SAP APO). Por lo tanto, la entrega no verificada aparece por separado en el resumen de necesidades del sistema de expedición y de comprobación de disponibilidad del sistema SAP APO. Cuando se crea la entrega no verificada, el sistema no realiza ninguna comprobación de disponibilidad. La verificación ATP también puede diferenciar entregas no verificadas y entregas. La entrega no verificada se incluye en la regla de verificación ATP SAP R/3 como una necesidad de ventas. En el sistema SAP APO, la entrega no verificada se compensa con la necesidad de pedido de cliente.
12. La necesidad en la entrega no verificada permite una planificación de necesidades local en el sistema de expedición.
13. Usted convierte la entrega no verificada en una entrega en el sistema de expedición. Se ejecutan las mismas verificaciones que para la creación de la entrega convencional.
En este escenario, el sistema de expedición posee las limitaciones siguientes en comparación con el escenario integrado:
¡ No hay bonificaciones en especie.
¡ No hay verificación del límite de crédito en la entrega.
¡ No se realizan actualizaciones de las estadísticas de datos de pedido utilizando la entrega.
¡ No se efectúa una entrega completa en función del indicador de entrega completa. Una entrega completa debe procesarse utilizando grupos de entrega y el acuerdo de entrega parcial C (no se permiten entregas parciales).
¡ En el sistema de expedición, no puede replanificar ni retrasar las posiciones de proceso de terceros ni las entregas no verificadas.
14. Se realiza una comprobación de disponibilidad en SAP APO para la entrega. Se graba cualquier modificación relevante en el sistema SAP APO. Según la cantidad disponible comunicada al sistema de expedición por SAP APO, los procesos siguientes pueden dar lugar a la entrega:
¡ Todo disponible
¡ Cantidad reducida
La entrega escribe una necesidad de entrega tanto en el sistema de expedición como en el sistema SAP APO. Se borran las necesidades de la entrega no verificada tanto del sistema de expedición como del sistema SAP APO.
15. La entrega confirma las cantidades de entrega al pedido de cliente. El sistema actualiza entonces el status y los flujos de documentos para el pedido de cliente.
16. Puede realizar todas las funciones subsiguientes, como picking, embalaje y salida de mercancías, del mismo modo que en el escenario integrado. Todas las modificaciones de la entrega se comunican automáticamente al sistema de pedidos de cliente.
17. Se crea el documento de facturación en relación con el pedido. El índice de documento de facturación se escribe a partir de la confirmación de la entrega al pedido, cuando se contabiliza la entrega para la salida de mercancías. Si se requiere información sobre la entrega para crear el documento de facturación y no se puede determinar esa información a partir del flujo de documentos del pedido relevante, en el sistema de expedición se llama un BAPI sincrónicamente para el documento de facturación. Este BAPI determina los datos relevantes para el documento de facturación. El sistema fija los datos de entrega o los valores de contabilización o bien define condiciones.
Gestión multisociedades
Si configura su sistema de manera que los centros diferentes estén también en sociedades diferentes, la entrega es relevante para la facturación interna.
El proceso descrito anteriormente varía, como mínimo, cuando contabiliza la salida de mercancías en el sistema de expedición y se produce el lanzamiento de la facturación interna y se envía al sistema de pedidos de cliente para la comparación.
Otros escenarios
Se seguirán soportando los escenarios siguientes:
· Verificación ATP basada en reglas (SAP R/3 y SAP APO)
·
Gestión de pedidos
para terceros ALE (2 SAP R/3, 1 SAP APO)
Estructura del concepto completo en los subprocesos
· Transporte y programación del transporte
· Creación y modificación de pedidos de cliente
· Entregas utilizando entregas no verificadas
· Proceso desde la perspectiva de Contabilidad