
Tal vez en algún momento se enfrentó al problema de que su orden de flete o confirmación de reserva de flete por parte del proveedor de servicios de transporte fue rechazada con el mensaje “No se puede confirmar el documento; los datos enviados ya han sido modificados”.
Esto se debe a los cambios que se produjeron en el documento después de que se envió al transportista la solicitud de transporte anterior. De esta manera, el sistema lo protege de tener una discrepancia entre lo que está confirmado en su sistema y lo que el proveedor del servicio de transporte pensó que acordó al enviar su confirmación, ya que esto conduciría en un caso menor a una disputa financiera en el peor de los casos a su cliente que aparece en el lado equivocado tratando de recoger algo que ya no estaba planeado para ser enviado después de todo.
Estado: cambiado después del envío
Este blog brinda información general y diferentes estrategias para manejar estos cambios tardíos como el remitente, según los requisitos comerciales de su cliente.
Tal vez lo primero sea comprender qué cambios desencadenan realmente el restablecimiento del estado:
Supongamos que no solo realiza un único cambio después de la subcontratación inicial, sino que realmente adapta su pedido paso a paso debido a los cambios en la demanda. O tal vez los cambios ocurren constantemente debido a cambios en la orden de venta subyacente. Enviar una actualización después de cada guardado con un cambio generaría constantemente mensajes a su proveedor de servicios de transporte, que podría no ser capaz de manejar actualizaciones frecuentes o poner al menos una gran carga en el proceso completo de subcontratación.
¿Tu usuario sabe mejor? Así que simplemente déle una lista de trabajo dedicada que filtre los documentos cuyo estado cambió después del envío.
Criterios de filtro: modificados después del envío
Esto permite al usuario monitorear de manera efectiva y volver a comunicar manualmente los documentos modificados en masa.
Lista de trabajo: cambiada después del envío
Entonces, incluso después de mi advertencia anterior, desea reenviar su pedido de inmediato… está bien, hagámoslo de todos modos.
Lo haremos configurando una estrategia y condición de chaco, que reenvía la reserva una vez que hubo un cambio relevante de subcontratación.
Primero, creamos una estrategia de método de controlador de procesos que incluye el método de controlador de cambios estándar SEND_TOR.
Método Chaco para Enviar Orden de Flete
Estrategia Chaco – Asignación de Métodos
En segundo lugar, creamos una Condición de cambio de controlador para activar el envío solo una vez que se produjo un cambio relevante de subcontratación que también establecería el estado en consecuencia.
Chaco Condición para Enviar Orden de Flete
La definición de acceso a datos en la captura de pantalla anterior no se entrega como parte de la personalización estándar, por lo tanto, debe mantener un DAD según la captura de pantalla a continuación.
Definición de acceso a datos: cambios de subcontratación
Asigne la Condición de controlador de oportunidad a su orden de flete/tipo de reserva y cada vez que se realice un cambio relevante de subcontratación, el sistema activará de forma asincrónica una nueva solicitud de subcontratación.
Está muy seguro de que en su escenario, por lo general, solo ocurren cambios menores y que la definición estándar de un cambio relevante de subcontratación es demasiado crítica y ni siquiera se lo comunicaría al transportista. Digamos que ocurre un cambio de cantidad menor que podría no afectar los cargos o el tipo de camión requerido de su transportista y ni siquiera necesita la autorización para comunicárselo a su transportista.
En este caso tienes la opción de implementar BADI /SCMTMS/TOR_CHACO_CHANGES_DET Método DET_CUSTOM_CHANGES
BADI para modificar Cambios identificados
En este método, puede validar los cambios durante el guardado y adaptar la criticidad de los cambios determinada por la lógica estándar.
Descargo de responsabilidad: este método es muy fácil de implementar en caso de que desee identificar cambios adicionales y aumentar la criticidad de un cambio. Sin embargo, si desea ignorar potencialmente los cambios identificados en el estándar, debe asegurarse de ignorar solo los cambios menores que considere no relevantes para su escenario y no sobrescribir los cambios críticos que también son críticos para su escenario.
Por lo tanto, no desea inundar su TSP con actualizaciones y no desea que esto se convierta en una tarea manual para su usuario.
En este caso, tiene la opción de enviar actualizaciones programando un informe /SCMTMS/TOR_FO_PROC_BATCH para órdenes de flete, respectivamente /SCMTMS/TOR_BO_PROC_BATCH para Reservas de Carga, en un intervalo adecuado.
Informe de lotes de órdenes de flete
Simplemente puede asignar un perfil de selección que filtre los documentos cuyo estado haya cambiado después de enviarlos y enviarlos colectivamente de nuevo a su proveedor de servicios.
Perfil de selección: las órdenes de flete cambiaron después del envío
Espero que este blog explique por qué el sistema está diseñado de la manera que es. Sé que, a menudo, el primer instinto de los clientes es esperar actualizaciones inmediatas y automáticas, pero esto debería brindarle una guía para explicar por qué esta podría no ser la mejor solución después de todo y herramientas para adaptar el sistema a las necesidades reales del cliente.
Calle Eloy Gonzalo, 27
Madrid, Madrid.
Código Postal 28010
Paseo de la Reforma 26
Colonia Juárez, Cuauhtémoc
Ciudad de México 06600
Real Cariari
Autopista General Cañas,
San José, SJ 40104
Av. Jorge Basadre 349
San Isidro
Lima, LIM 15073