Feature Requests

DELHIVERY requires a QR code generated in the invoice to be scanned before accepting the package for shipping. When creating a Manual self fulfillment order, the INVOICE generated by ESHOPBOX doesn't generate the QR code, so when ESHOPBOX automatically assigns DELHIVERY for shipping, the pick up is not happening. However, that is not the case with BLUEDART, the other shipping partner ESHOPBOX assigns pick up to. So, if the choice is given to the customer to choose the shipper, then there will no longer be delays and complaints and multitude of ticket numbers

Hi Team, we have received a requirement from the brand- VI-john to have LR details reflected and downloadable from the Workspace for all B2B orders. Currently, there is no tracking information available to the brand on Workspace for B2B shipments. The LR details are visible on Flex, however the same is not reflecting on Workspace. Request you to please check and enable the same on Workspace as well.

Hi Team, Many brands have requested additional enhancements in the ticketing system: Ability to search tickets not only through Ticket ID, but also using: Order ID Tracking ID Requirement for a bulk export option to download tickets along with key ticket information/details, without exporting the complete chat conversations. Please check the feasibility of these enhancements and share the possible approach and timelines.

Hi Team, We have received a requirement from the brand regarding B2B order exports. The brand needs batching and expiry details to be included in the B2B export Excel file at SKU level. Use case / scenario: We are handling B2B shipments at a large scale for this brand. In cases where a B2B order gets cancelled or a PO expires, the inventory is expected to be re-inwarded. However, while creating a new consignment for the same inventory, the brand is required to provide batch and expiry details. Currently, since these details are not available in the B2B export, the brand faces challenges in recreating the consignment accurately. Request: Please enable/introduce batching and expiry details in the B2B export file to support this operational requirement. Requesting you to review and prioritize this.

Hi Team, This is regarding an ongoing issue that is causing significant discrepancies across multiple processes. We are observing that shipments are being created even after an order has already been dispatched from the warehouse and subsequently cancelled in-transit. A new shipment gets generated for the same order, which then gets stuck in Flex due to a duplicate tracking ID error. In such cases: The original shipment reflects “Return on the way” in the workspace The newly created shipment shows “Processing” or “Ready to Ship” Since the order has already been dispatched against the original tracking ID, the system rightfully flags the new shipment as duplicate. Additionally, in cases where a shipment contains multiple items and one item is cancelled during in-transit, the system is following an RTS cancellation flow, which is not operationally feasible. As both items are packed in a single shipment, partial delivery is not possible, leading to further discrepancies. Key Issues: Operational Blockage in Picklist Processing If one shipment in the picklist faces an issue, the entire process gets blocked. Even after applying temporary fixes via support tickets, discrepancies persist. In some cases, this has resulted in duplicate deliveries, as orders already dispatched are processed again under a new shipment ID. Incorrect Status Handling Orders marked via temporary fixes as RTO are getting restocked under a different shipment ID. Meanwhile, the original dispatched shipment reflects “customer cancellation” with a putaway option, creating further confusion. Suggestion / Recommendation: A new shipment should not be created if the order is already: Dispatched in Flex Marked as “handover done” in the workspace Instead, the system should follow the RTO flow for such cases. Additionally, we suggest evaluating whether it is feasible to fetch pickup/handover status from Flipkart API, to ensure: Once the shipment is handed over to the courier, no new shipment is created The shipment is correctly processed through the Return (RTO) lifecycle This will help eliminate duplicate shipments, prevent operational delays, and ensure process accuracy. Please review this and let us know if the proposed solution is feasible or if any alternative approach can be implemented to address these issues.

Hi Team, We would like to request an enhancement for the Snapdeal manifestation process. Currently, once orders are packed and manifested through Flex, they continue to reflect under the “Pack” tab on the Snapdeal portal. Due to this, we have to manually select all orders and close the manifestation on the Snapdeal panel. Requirement: Once an order is packed and manifested in our OMS/Flex system, it should automatically move to the “Handover” tab on the Snapdeal portal. This automation will eliminate the need for manual intervention and help ensure timely pickup alignment. At present, despite completing packing and manifestation, orders remain stuck in the “Pack” tab, causing operational delays. For your reference, we have attached relevant screenshots. Kindly review the issue and implement the required solution at the earliest. Looking forward to your support on this.

Hi Tech Team, We have a new requirement for brand-level order processing charges, Requirement Details: First item in an order INR 10 Additional items in an order (upto 10 Items) INR 7 Additional items in an order (more than 10 Items) INR 6 Order processing charge: INR 4 per item for up to 3 items For add. orders with more than 3 items: INR 2 per item Currently, this functionality is not available in the system. We request you to please implement this logic for the respective brands. Brand Name - Kumbhkaran, Benetton, Inlabs-Lifesciences Kindly prioritize this and let us know once the changes are completed or if any additional details are required from our end.

Hi Team, As per brand Currently, customers receive a notification from Eshopbox to convert COD orders to prepaid when the order is in transit. The brand has requested to include a discount coupon within this notification to encourage prepaid conversions. Please confirm whether it can get added or not.

Context: A single FC has: Online instance Offline instance Currently, users can receive any return in either instance. Problem: Returns are being received in the wrong instance (Online vs Offline), leading to tracking and reconciliation issues. Expected Behavior If the return is of Online FC:It must be received only in the Online instance of the FC. If the return type is of Offline fc:It must be received only in the Offline instance of the FC. Popup Message (Examples) If mismatch (Online return in Offline instance): “This is an Online return. Please receive it in the Online instance.” If mismatch (Offline return in Online instance): “This is an Offline return. Please receive it in the Offline instance.”