Feature Requests

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.

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.

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.

Problem Statement: Shopify has recently introduced its own packaging material option, which can be tagged directly to an order. In Eshopbox, we also maintain packaging materials and have logic in place to recommend the most suitable packaging material for each order. This creates a conflict at the packing desk: if an order is already tagged with a packaging material from Shopify, it is unclear whether the Shopify packaging material or Eshopbox’s recommended packaging should be followed. This ambiguity needs to be resolved to avoid operational confusion and ensure smooth packing workflows. Requirement: To address this, sellers should have control over which packaging material source to follow. During the Shopify integration setup, sellers must be able to specify whether they want to use Shopify’s recommended packaging material (tagged at the order level) or Eshopbox’s recommended packaging. Based on their selection, the logic in the system will be adjusted accordingly.

Enable efficient management of inventory, orders, returns and catalog syncing through a direct integration with BigCommerce.

Objective: Enable efficient management of inventory, orders, and catalog syncing through a direct integration with Magento. Key Benefits: Seamless Inventory Sync: Real-time inventory updates to reduce stock-outs and manage dynamic stock levels across Magento stores. Centralized Order Management: Automatic order import and status syncing for streamlined order processing. Catalog Sync: Synchronize product creation, updates, and linking between Magento and the platform. Unified Insights: Detailed analytics and reporting for better business insights and data-driven strategies. Impact: Direct Magento integration will eliminate the complexities of managing products and orders manually, offering users a robust, automated workflow while supporting Magento's extensive marketplace ecosystem.

Brand: Raymond Request Type: Feature Enhancement Channel - FBA Background: Similar to the process of creating sales orders, the Raymond brand requires the ability to create return orders. Currently, Raymond has provided the necessary return data, but due to system restrictions, the return creation process cannot be completed. Requirement: Immediate: Enable manual creation of FBA returns in the system using the data provided by Raymond. Long-term: Develop an automated solution to process FBA returns for Raymond similar to the sales order automation flow. Objective: To streamline the return handling process for Raymond by removing current system restrictions and automating return order creation, ensuring operational efficiency and data accuracy. Impact: Reduces manual intervention for the Raymond operations team Enhances consistency in FBA return handling Aligns returns workflow with sales order processes

Enable seamless integration between Eshopbox Fulfillment Services and EasyEcom to facilitate clients using EasyEcom as their primary commerce and transaction management system while leveraging Eshopbox for fulfillment in other regions. ome clients actively use EasyEcom at their own locations for order and inventory management. To expand their business operations, they want to onboard Eshopbox for fulfillment services in other regions. However, it is crucial for these clients to maintain EasyEcom as the centralized system of record for all transactions, even when Eshopbox handles the fulfillment process. This integration would allow EasyEcom to record and reflect all operations performed via Eshopbox, ensuring transparency, consistency, and efficiency.

Currently, our system does not support GST invoice generation for freebie products that are bundled with actual purchases. This creates compliance and documentation gaps, especially for brands that require complete invoice traceability — even for zero-value items. As per the expected functionality, the system should be enhanced to: -> Automatically create a separate line item in the invoice for the freebie product. -> The line item should reflect the product details with a zero amount (₹0). -> GST should be handled appropriately based on tax applicability and reporting norms. -> This should be implemented in the same invoice as the primary (paid) product, not as a separate document. Implementing this feature will align the invoicing process with standard accounting practices and brand expectations.

We have received a requirement from the brand regarding the "Shipping Service:" field on Amazon. Currently, this field contains a free text box that should not be left empty, as Amazon mandates it to be filled. Since the orders are being dispatched from the Eshopbox warehouse, this field must be updated with "Eshopbox Standard" to ensure compliance and smooth order processing.