Consejos para la actualización de datos 

Orden cronológico de los datos

El Sistema SAP proporciona una amplia de opciones para la actualización de datos. Por ejemplo, puede realizar modificaciones válidas en el futuro y realizar modificaciones en objetos que tienen su propio historial y cuyos datos de activación no están en orden cronológico. Esto puede crear problemas cuando los datos se transfieren a sistemas de TPV, porque los grupos de segmentos individuales en la interfase con TPV siempre se transfieren por completo.

Podría trasladar, por ejemplo, un lunes una modificación de precios que fuera válida para el lunes siguiente. A continuación hace una modificación en la bonificación en especie y se traslada el martes (y se introduce únicamente en el sistema el martes). Esta modificación es válida para el próximo viernes.  El sistema de TPV puede reaccionar de tres maneras:

·        El sistema de TPV reemplaza la modificación de lunes trasladada por la modificación de viernes (esta es la norma). Por consiguiente, la modificación del lunes tiene que transferirse de nuevo y debe incluir también la modificación del viernes.

·        El sistema de TPV gestiona precios diferentes para fechas diferentes, de manera que la modificación del lunes no se sobrescribe. Por consiguiente, el lunes, el precio del artículo es correcto pero la bonificación en especie no lo es. En este caso, la modificación del lunes tiene que transferirse de nuevo y debe incluir también la modificación del viernes.

·        El sistema de TPV mezcla las dos modificaciones correctamente. En este caso, la modificación del lunes no tiene que transferirse de nuevo. La mayor parte de sistemas de TPV no pueden coordinar en la actualidad este proceso.

Para evitar los problemas descritos anteriormente, la salida a TPV envía datos coherentemente de manera que se mantiene el orden cronológico. Los registros de borrado se preparan en el IDOC para cada artículo que va seguido por las modificaciones de artículo en orden cronológico.

Objetos dependientes del tiempo

Evite transferencias múltiples:

·        Los datos deberían actualizarse de tal forma que se activen en orden cronológico. Sin embargo, esto sólo es válido para los próximos n-1 días, siendo n el plazo de comercialización de la tienda (opción en el perfil de salida a TPV). Fuera de este periodo, la actualización de datos no es crítica. Modifique sus precios de venta, por ejemplo, en el tiempo – en otras palabras, no durante el plazo de comercialización de la tienda.

·        Los períodos de validez de un objeto (por ejemplo, precios de venta) no deberían definirse indefinidamente, si es posible. Si es así, y se divide el período en una fecha posterior, se inicializa el objeto de nuevo a partir de la fecha de comienzo (sin embargo, la fecha más temprana posible para esto es la fecha actual). Deberían definirse períodos para que sean consecutivos, pero sin superponerse. Además, el nuevo período de validez debería comenzar al cabo den días o más.

·        Si es posible, debería evitar borrar intervalos de condición físicamente (períodos de validez para precios). Esto sucede si reemplaza completamente un precio a nivel de tienda por un nuevo precio que haya creado (al mismo nivel). La salida a TPV tiene una lógica que reconoce borrados como este, pero hay casos especiales (borrados de intervalo parciales de condiciones de partición) que el sistema no puede reconocer. Sin embargo, se reconocen los borrados estándar de los precios de promoción y de los precios estándar. Si tiene que borrar intervalos de condición, debería archivar registros de condición regularmente.

·        No borre nunca registros de condición definiendo el indicador de borrado del registro de condición. La salida a TPV no puede responder a esto debido a razones técnicas y de rendimiento. Si no se atiene a esto, se producirán incoherencias en el sistema de TPV.

·        No utilice condiciones en las secuencias de acceso, ya que la salida a TPV no las puede incluir en el análisis regresivo de las modificaciones de condiciones.

Asignaciones m:n en las listas

Puede asignar varios surtidos a una tienda. Una nueva tienda también puede hacer referencia a un surtido en una tienda existente.

Si crea o borra una referencia como esta, esto significaría que todos los artículos tendrían que ser inicializados o borrados en la nueva tienda para salida a TPV. Puesto que este procedimiento llevaría mucho tiempo, el mensaje de modificación (programa RWDPOSUP) en la salida a TPV no responde a esta clase de modificación.

Si crea una referencia como esta, inicie una nueva inicialización de TPV (RWDPOSIN). La aplicación relevante se refiere claramente también a esto cuando graba una referencia.

Sin embargo, si quiere borrar una referencia, debería borrar todos los datos de artículo en el servidor TPV en la tienda. Alternativamente, puede utilizar la solicitud directa (RWDPOSAN), aunque tiene que activar el identificador Borrar datos seleccionados así como el identificador Datos de material de traslado. El sistema prepara a continuación registros de borrado para todos los artículos en esta tienda.

Asignaciones de set

Cuando se transfieren asignaciones de set, se tiene en cuenta el período para gestionar el artículo de set superior en la tienda, pero no el período para gestionar los componentes individuales. Debería tener esto en cuenta al crear el set y asegurarse de que el período para gestionar los componentes de set es el mismo que el período para gestionar el artículo de set (cuando crea el período para gestionar el artículo de set, esto se incluye automáticamente). En caso contrario, es posible que una tienda pueda recibir sets cuyos componentes no estén todos asignados a la tienda. Estas asignaciones de set no pueden utilizarse y permanecerían sin usar en el sistema de TPV.

Si se debe modificar un período de gestión para un componente, lo puede extender, pero no lo debería acortar nunca.

Materiales de acompañamiento

Igual que en el caso de sets, puede ampliar el período para gestionar un material de acompañamiento, pero no debería reducirlo.

Si se añade una posición a una lista de lista de materiales existente para un material de acompañamiento y el mismo material de acompañamiento se incluye también en listas de materiales para otras unidades de medida, las listas de materiales para estas unidades de medida de venta también volverán a transferirse.

El artículo B-bebida se vende en varias unidades de medida. Existen listas de materiales de material de acompañamiento para las unidades de medida botella, paquete de 6 y caja. La posición botella con depósito existe en las dos primeras listas de materiales. La lista de materiales para cajas sólo contiene la posición caja con depósito. Si luego se añadiera botella con depósito, las listas de materiales para las otras dos unidades de medida se transferirían de nuevo, porque también contienen la posición botella con depósito.

Para evitar este problema, debería asegurarse siempre de que las listas de materiales se crean completamente desde el principio, para que no tenga que añadir posiciones posteriormente.

Modificaciones de precio de materiales de acompañamiento

La salida a TPV reacciona automáticamente ante modificaciones de precio, lo que significa que los objetos afectados se preparan de nuevo y se transfieren a los sistemas de TPV.

La única excepción se refiere a las modificaciones de precio para artículos de envases. El sistema no responde a esto, ya que el análisis de los punteros de modificación afectados causaría un tiempo de ejecución mucho mayor para la preparación del mensaje de modificación.

De todas formas, los precios de envases se modifican con muy poca frecuencia. Cuando esto sucede, debe reinicializar los datos maestros de artículo por medio de una solicitud directa.

Datos personales

El texto para el campo Observaciones se lee únicamente mediante el identificador de texto 0001. Si un texto debe transferirse al cliente, el texto debe actualizarse con el identificador 0001 para la superficie de venta. En el sistema estándar, esto corresponde a Referencia de ventas externa.