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

Day wise Inventory which we can access by selecting the date

In Discount column we found total amount difference in MRP-Invoice total of flipkart. But we want to know what is the flipkart discount and what is farmley discount in different 2 columns in sales report. So we can study the discount at brand level and sales channel level. A reference ticket we have raised already. #74510 In this ticket we raised sales report and flipkart invoice where 2 different discount present in both and not able to understand the same. That's why we request you to please create the same.

Brand Western Lifescience Requirement :- Bubble wrapping is required for 5 SKUs only. Total SKUs created & having inventory are more. Check & confirm how can tis be implemented. This is critical

BOX IN , BOX OUT FEATURE Currently, the warehouse is unable to perform box-to-box dispatch because the system allows picklist creation only by entering the total quantity, then the same qty picklist is created. Due to this, warehouse staff have to open boxes to complete the process. To enable box-to-box handover without opening the boxes, a new feature is required that allows picklist creation at the SKU level. This enhancement will allow the warehouse team to execute the process smoothly and efficiently.

Hi Team, Please check the below issue observed in Flipkart orders which are showing as Cancelled in Flex, although all shipments were cancelled before pickup. During investigation, we identified two different scenarios: Case 1: Cancellation After “PACKED” Status The order gets cancelled immediately after reaching PACKED status. Order status moves to CANCELLED. Putback status shows “Created”, however: No entry is visible in the Putaway Items tab. This makes it difficult to track and close such cases operationally. Requirement: All putback-created cases should be clearly visible in the Flex Orders tab, similar to how Sidelined cases are displayed. Operationally, these cases should follow the In-house RTO process to ensure better tracking and control over putback pendency. Case 2: Cancellation During Manifest Creation The order gets cancelled while adding shipments to the manifest. A tote is created, and all cancelled tracking IDs are placed into the tote. Putaway is created and successfully closed following the RTO process. However, even after putaway closure, the putback status continues to show “Putback Pending to Create”. This creates a system mismatch, as the physical and operational process is completed, but the system status does not reflect the same. Request We request you to: Investigate why putback-created cases are not visible in the Orders tab. Fix the issue where putback status does not update even after successful putaway closure. Streamline both flows to ensure system visibility aligns with actual warehouse operations. Looking forward to your support in resolving this at the earliest.

Greetings All, I would like to highlight a critical issue we are currently facing during brand audits. We encountered this problem most recently during the ongoing Raymond brand audit across multiple locations. The issue arises when a location is marked as “OFF” via the app and zero inventory is pushed to the sales channels. While this should ideally prevent any further order flow, we are facing order and shipment creation inconsistencies across marketplaces. Although this may not impact every channel, I would like to cite Flipkart as a representative example. For Flipkart, zero inventory was pushed on 26th July. However, orders that were created prior to 26th July are still visible in the “Upcoming” tab and are not immediately assigned to us due to factors such as customer verification checks aimed at fraud prevention. These orders only get assigned post verification, and their fulfillment TAT varies accordingly. In our previous discussion with @Mayur Karwa, the backend order creation check was disabled, which earlier prevented such orders from appearing in the workspace. While this change allowed the orders to reflect in the workspace, it surfaced another blocker — shipment creation is still restricted. Currently, shipment creation is blocked if the location is marked inactive, due to a validation linked to the location toggle. As a result, even though orders are now visible in the workspace, we are unable to create shipments in Flex. This defeats the objective of disabling the backend order creation restriction. From an operational and logical standpoint, order creation should be driven solely by inventory availability. If zero inventory is pushed to a channel, no new orders should be created. Orders should resume only once positive inventory is pushed back to that channel. As discussed with @Ajay Sharma, there is a concern that removing the shipment creation dependency on inactive locations could impact other inactive channels on UC. However, in our view, this risk is mitigated as long as zero inventory is consistently maintained for those channels. Given the audit sensitivity and potential brand escalations, we request urgent alignment on this behavior and guidance on the correct approach to avoid operational and audit discrepancies.

Hi Team, We faced a critical issue yesterday related to our Flipkart API integration, which is used to update order statuses on the Flipkart panel. As part of the current flow: Once an order is picked, the invoice is generated from the Flipkart panel, which moves the order from “Pending Label” to “Pending RTD”. This event is entirely dependent on Flipkart. The second event is triggered when the order is marked “PACKED” in our Flex system. At this stage, we push the RTD (Ready to Dispatch) confirmation via API, which allows the order to move from “Pending RTD” to “Pending Handover”. However, yesterday, for certain orders, the second event was missed, due to which those orders did not move to the “Pending Handover” tab. As a result, the orders did not appear on the Ekart courier device, and hence pickup did not happen. This issue is critical because: Invoice generation alone is sufficient for order processing in Flex. However, pushing the RTD event is mandatory for the order to move to the “Pending Handover” tab and appear in the courier pickup task. If the RTD event is not pushed, the order gets blocked at Pending RTD, even though it is fully ready for dispatch. We therefore request you to please explore and implement a mechanism to re-push the second (RTD) event automatically in case of failure. This will ensure: Orders are not stuck due to transient API or server issues Pickups can happen smoothly without manual intervention Operational dependency risks are minimized Request your urgent attention on this matter, given the direct impact on pickups and SLA.

Hi Team, The brand Boone Fashion wants their amount of 10,000 to 20,000 should automatically get transferred to the wallet for smooth order processing any fail. This should get fixed.

The brand TIPL ships coffee machines and coffee sachets. For orders where a machine and other items are ordered together, multiple boxes are required—the coffee machine is packed separately, while the remaining items are packed in different boxes. To support this packaging flow, the MPS (Multi-Packet Shipment) feature is required. Additionally, it would be beneficial if the box count is also visible in the export reports, as this was a specific requirement raised by the brand.