SUMARIAS - NEREO ENVÍA MODIFICACIONES CUANDO DEBEN SER ALTAS

El problema.

En ocasiones, se produce en Nereo un mal funcionamiento en la lógica que reconstruye la actividad de mensajería -con el fin de determinar qué cambios deben enviarse-, de manera que propone enviar modificaciones cuando deberían ser altas. Por tanto, esas modificaciones son rechazadas al no existir el alta correspondiente. 

Este problema es un viejo conocido. Ya me había puesto sobre la pista el usuario SLLEDO, en que me advertía de que cuando se envían juntas distintas operaciones, a veces la mensajería del expediente queda inservible. En todo caso, aprovecho para recordar que el feedback de usuario es fundamental, y que no no dudéis en aportar o explicar ideas, mecanismos o problemas del día a día....es el primer paso para arreglar o mejorar.

Volviendo al problrma concreto, solo recientemente he podido averiguar la causa de ello. Vamos a explicarlo brevemente, con la ayuda de un ejemplo real de incidencia. Veamos esta secuencia e mensajes.

El origen del problema está en los 3 mensajes de abajo. Hay una modificación de cabecera, una alta de partidas (la 7), y una modificación de partidas ( 1 a 6), los tres mensajes enviados en el mismo paso operativo, pero enviados secuencialmente. Esto es consecuencia de que Nereo trata de optimizar los trámites, de forma que sea lo más eficiente para el usuario, agrupándolos en la misma operación.

¿Por qué eso es un problema? 

Tal vez también por la búsqueda de eficiencia -u otro motivo, por analizar en detalle-, en base de datos se crea una única cabecera para los tres mensajes. Esto se ve así (arriba los mensajes, abajo las cabeceras de sumarias)

Como se ve, la 'cabecera múltiple' solo admite un estado, que va a ir cambiando a cada mensaje que se cursa. En este ejemplo, has sido Aceptada, Rechazada, y Aceptada a partir de las 3 respuestas recibidas. Y aquí viene el problema. Se ha quedado en 'Aceptado' tras el último mensaje, pero el anterior a ese -adición de partida 7- ha sido rechazado. 

Al tratar de reconstruir la rama del mensaje, se entra en contradicción. Quede la cabecera como quede, habrá un movimiento incoherente respecto a su cabecera. Y este es el lío que luego provoca el siguiente mensaje, en el que se cursa una modificación de la partida 7, que realmente no tiene un alta en los sistemas externos (AP, Aduana, etc..).    

Como **bonus**, es este mismo motivo el que causa un efecto que seguro habéis notado: un mensaje "Aceptado" que sin embargo acarrea el mensaje de error del anterior, tal como puede verse también en la imagen. 

En todo caso, esto lleva así mucho, mucho tiempo ¿por qué no ha dado más problemas? Solo cabe especular, pero seguramente por varios motivos:

1. Las operaciones 'múltiples' no deben de ser demasiadas sobre el total y, de éstas, solo son problemáticas aquellas que no han obtenido el mismo resultados en todo sus mensajes.
2. Es probable que algunos usuarios (como el citado al principio) hayan entendido y aprendido a mitigar el problema por su cuenta, cosa que consiste básicamente en enviar una a una las operaciones (detalles más abajo). En todo caso, un inciso:  el compartir y centralizar el conocimiento a nivel de grupo es algo a mejorar, cosa que intenta esta serie de artículos de Nereo. 
3. Después. una vez se produce el fallo, sólo una F13 lo ha podido resolver -hasta ahora, ver más abajo-. El problema es que no siempre es posible usar esa función que, recordemos, hace un 'reset' de la sumaria en todos los sistemas. El 'por qué', cuando no es posible, tiene causas diversas: fuera de plazo, partida 'bloqueadas' o ya 'datadas', no se acepta F13.. 
4. Si nada de lo anterior funciona, pues solo quedan los trámites directos en las distintas ventanillas, físicas o virtuales, de los distintos actores (AP, Aduana, etc...).

Es casi obvio, por tanto, que la solución pasa por desdoblar las cabeceras en tantas como mensajes se envíen, y controlar adecuadamente la secuencia en que lo hacen. Pero esto, que se dice fácil, es más complicado de lo que parece, y puede tardar unos meses.

Evitemos el problema, a la larga es más eficiente.

Mientras llega o no la solución ¿qué hacemos para mitigar, minimizar o evitar el problema? Ya está apuntado antes. además de que resulta obvio a partir de lo explicado: enviemos una a una las operaciones de mensajería si Nereo nos propone más de una a la vez. De esta manera se cursarán cabeceras únicas por mensaje ¿Cómo se hace esto?  

1.- Para enviar la sumaria, usaremos la función 'Avanzada'.

2.- Usaremos 'Modificar Datos' (contraseña 12345) para poder deseleccionar funciones de manera que quede solamente una a enviar.

 No hay regla fija para el orden de envío de las sucesivas funciones. Como criterio general, se enviarán por orden 'jerárquico': Cabecera->Conocimiento->Partida, y por orden de 'acción': primero las modificaciones y luego las altas. Si tenéis información para mejorar o matizar esta indicación, compartidla. 

3.- Repetir el proceso hasta que se hayan tramitado todas las funciones pendientes.

Ya tengo un expediente en esta situación ¿qué hago?

Lo ideal es no llegar aquí, pero si es el caso, aún se puede intentar algo. Se trata de 'engañar' a Nereo para evitar de alguna manera ese bucle en el que se nos sugiere una modificación de un alta que no existe, y que por lo mismo no permite reenviar ese alta.  En nuestro ejemplo, los conocimientos 7 y 8 estaban en esta situación. Veamos con actuar.

1.- Enviar una eliminación del los conocimientos comprometidos. En este caso, 7 y 8. Para ello y como ya sabéis, desclicar los mismos. 

 

 
2.- Dicha eliminación va a a ser rechazada por los mismo motivos que no se acepta su modificación, es decir, porque no hay un alta real fuera de Nereo. Lo que vamos a hacer una vez recibido el rechazo es ACEPTAR MANUALMENTE EL MENSAJE DE ELIMINACIÓN (CTRL+ ALT + F6). Este es el paso clave. 

3.- Una vez hecho esto, volvemos a enviar la sumaria. En Nereo veremos esto. 

Es decir, Nereo 've' dos conocimientos sin actividad. Los seleccionamos para envío y vemos esto.

 
Es decir, puesto que los 'antiguos' 7 y 8 están eliminados, sencillamente ha asignado 9 y 10 a los 'nuevos', que obviamente son los mismos, renumerados. 

Esto es lo que se ve una vez acabado el proceso.