Greetings Team,

I would like to highlight an ongoing issue related to manifest closure in Flex.

We are facing scenarios where a manifest contains shipments that get cancelled after being scanned or picked up by the courier. When attempting to close such manifests, the system throws an error stating that the respective tracking IDs are already cancelled, despite the fact that the shipments have already been handed over to the courier.

To mitigate this, we implemented an SOP instructing the warehouse team to close the manifest immediately after the shipment is scanned on the courier’s device. This has significantly reduced the occurrence of such cases. However, edge cases still exist where shipments get cancelled post-scan, resulting in the same blockage.

This issue was also raised yesterday via ticket #51991. As per the response from the support team, @Mayur Karwa advised us to stop performing this activity from the backend. However, no alternative approach or explanation was shared.

It is important to highlight that delays in manifest closure can lead to unnecessary brand escalations, particularly for sensitive brands such as ABFRL (TCNS), where timely dispatch and status accuracy are critical.

@Mayur Karwa, we request your guidance on an alternative solution or workaround that can be implemented without operational disruption. We cannot afford to wait for a future feature deployment by @Swapnil Pangare, as this may result in further confusion and avoidable escalations from the brand side.