Introduction

This document describes the flows that are integrated between WMSs Magic 2 and RMS and RMS and the possible flows between WMS Magic 2, RMS and the client’s systems.

Forward Flow

Invoice and Shipping Label Generation

• If the client is integrating with WMS Magic 2Increff Omni standard API, for the invoice and shipping label generation then there are 2 multiple options :

  The standard WMS Magic 2 flows are followed, where the invoice

  available.

  • Invoice and shipping label generation is both are handled by the client itself. There is no RMS involvement here. Please refer to the WMS Magic 2 documentation on how the invoice

  • RMS handles the invoice generation and shipping label documents will flow to WMS Magic 2. //TODO: insert link heregeneration.

  • RMS handles only the invoice and/or generation, shipping label is handled by client system

  • RMS handles only the shipping label generation. 

• The below sections describe the flows where RMS is used for Invoice and/or shipping label generation

...

• • , invoice generation is handled by client system

RMS handles the invoice generation and shipping label generation.

...

1. When the warehouse operator clicks on the Complete Packing button, this complete packing call is made to WMS Magic.

2. Pack Order API call is made to the Client’s system. This is to inform the client’s system that for that particular order, packing is being done in WMS.

3. The client’s system returns the response of the Pack order call (including shipment code etc.)

4. WMS Magic makes the Compute Tax and Generate Invoice API calls to RMS

5. RMS returns the tax and invoice details in the responses.

6. WMS Magic makes the Generate ShippingLabel API call to RMS.

7. RMS makes the api calls to Clickpost/Shiprocket/shipway based on the configuration and returns the AWB and courier details to WMS Magic.

8. WMS Magic returns the shipment details in response to omni wms.

9. When the warehouse operator clicks on the Print Invoice and Shipping Label button, this call is made to WMS Magic to fetch the invoice and shipping label details.

10. WMS Magic makes the Get Invoice API call to RMS to get the invoice details of the order that was packed.

11. RMS returns the invoice details to WMS Magic.

12. WMS Magic makes the Get Shipping Label API call to RMS to get the shipping label details of the order that was packed.

13. RMS returns the shipping label details to WMS Magic.

14. The invoice and shipping label details are sent to Omni WMS from WMS Magic 2.

...

RMS handles only the invoice generation, shipping label is handled by client system

...

1. When the warehouse operator clicks on the Complete Packing button, this complete packing call is made to WMS Magic.

2. Pack Order API call is made to the Client’s system. This is to inform the client’s system that for that particular order, packing is being done in WMS.

3. The client’s system returns the response of the Pack order call (including shipment code etc.)

4. WMS Magic makes the Compute Tax and Generate Invoice API calls to RMS

5. RMS returns the tax and invoice details in the responses.

6. WMS Magic returns the shipment details in response.

7. When the warehouse operator clicks on the Print Invoice and Shipping Label button, this call is made to WMS Magic to fetch the invoice and shipping label details.

8. WMS Magic makes the Get Invoice API call to RMS to get the invoice details of the order that was packed.

9. RMS returns the invoice details to WMS Magic.

10. WMS Magic makes the Get Shipping Label API call to Client’s System to get the shipping label details of the order that was packed.

11. Client’s System returns the shipping label details to WMS Magic.

12. The invoice and shipping label details are sent to Omni WMS from WMS Magic 2.

...

RMS handles only the shipping label generation, invoice generation is handled by client system

...

1. When the warehouse operator clicks on the Complete Packing button, this complete packing call is made to WMS Magic.

2. Pack Order API call is made to the Client’s system. This is to inform the client’s system that for that particular order, packing is being done in WMS.

3. The client’s system returns the response of the Pack order call (including shipment code etc.)

4. WMS Magic makes the Generate Shipping Label API call to RMS

5. RMS returns the shipping label details in the response.

6. WMS Magic returns the shipment details in response.

7. When the warehouse operator clicks on the Print Invoice and Shipping Label button, this call is made to WMS Magic to fetch the invoice and shipping label details.

8. WMS Magic makes the Get Shipping Label API call to RMS to get the shipping label details of the order that was packed.

9. RMS returns the shipping label details to WMS Magic.

10. WMS Magic makes the Get Invoice API call to Client’s System to get the invoice details of the order that was packed.

11. Client’s System returns the invoice details to WMS Magic.

12. The invoice and shipping label details are sent to Omni WMS from WMS Magic 2.

Notification Flow

• The client can opt for the RMS notifications to be pushed to their system. 

• What happens is the logistic aggregator pushes various tracking updates to RMS related to the shipment that was packed in the forward flow as well as return orders created via RMS or logistic aggregator plugins (Eg- Clickpost provides a return order plugin which can be used on the client’s website where a customer can place a return order)

• These tracking updates are consumed by RMS and corresponding to these updates, notifications are pushed to the client’s system.

• The client’s system’s url and credentials are configured on the Push Config section on RMS UI. 

• So when the tracking updates are pushed to RMS, the notification API call is made to the url configured, with the credentials configured in RMS UI passed as http headers.

• For tracking updates to be consumed by RMS, the RMS url has to be configured on the logistic aggregator panel

  • Clickpost: 

    • Go to the Clickpost settings page

    • Select the Notification tab.

    • Go to the Webhooks: Selected status section

    • There the client can select which all statuses to be pushed to RMS. The same statuses will be pushed by RMS to the client’s system.

    • In the same page, the client has to configure RMS’s url in the webhook url. RMS Clickpost Notification URL: https://saas.increff.com/rms/in/api/clickpost/notify

    • The generated key displayed on this page here has to be set as the webhook key on RMS UI.

  • Shiprocket;

    • Go to the Shiprocket settings page

    • In the API section go to Webhooks

    • Type in the RMS’s url in the URL field. RMS Shiprocket Notification URL:https://saas.increff.com/rms/in/api/st/notify

    • Whatever has been set as webhook key on the RMS UI for Shiprocket will have to be set in the token field.

  • Shipway

    • The RMS’s url would have to be sent to Shipway team. It will be configured at their end. RMS Shipway Notification URL: https://saas.nextscm.com/rms/in/api/shipway/notify

    • Once Shipway team configures the RMS notification url at their end, the notifications will start getting pushed to RMS.

Forward Notifications

...

• For the orders for which shipping label was generated via the logistic aggregator, logistic aggregators have the provision to push tracking updates to systems.

1. Logistic aggregators push tracking update notifications to RMS. 

   1. For example-when the courier picks up the shipment from the warehouse, the tracking update of “Shipment Picked Up” will be sent to RMS by logistic aggregator

   2.  When the courier delivers the shipment to the customer, the tracking update of “Delivered” will be sent to RMS by logistic aggregator.

2. RMS then pushes the notification to the Client’s system.

• Refer to RMS API Documentation for the different notifications that can be sent to the Client’s system. ( link)

RTO Notifications

• For logistic aggregators, RTO is just considered as a forward order status.

• So, for the flow of RTO Notifications, it would be the same as other forward order notifications (Picked Up, Delivered etc.)

• But since an RTO is considered as a return order in our system, the client’s system would have to push the RTO as a return order to WMS Magic.

...

1. The Logistic Aggregator pushes the RTO notification to RMS.

2. RMS forwards the RTO Notification to Client’s System.

3. The Client’s System pushes the return order of type RTO to WMS Magic. 

Return Notifications

• Just like how different notifications are sent by RMS for forward orders, in a similar manner notifications for return orders.

• But for return AWB generation, there are multiple flows possible.

Return Order Creation Flow 1 (Applicable just for Clickpost)

• Clickpost provides a plugin that can be used by clients on their customer facing websites. ( plugin name and link)

• So, when a customer places an return order on the website, using this plugin the return order will be created on Clickpost

1. Customer places a return order on the customer facing website.

2. The Clickpost plugin creates a return order on the Clickpost panel.

3. Clickpost sends an update to RMS that the return order has been placed on the Clickpost panel.

4. RMS makes a notification API call to Client’s system for the return order creation.

5. Client’s system now makes the Create Return Order API call of WMS Magic 2 to push the return order to Increff WMS

6. Clickpost sends the tracking updates for the return orders to RMS (when the return order is picked up, when the return order is in transit etc.)

7. RMS makes the notification API calls to the Client's system for these updates.

Return Order Creation Flow 2

• In this scenario, when the Customer places the return order on the brand website, the client’s system makes the create return order API call to RMS

...

1. The Customer places a return order on the brand website.

2. The Client’s system makes the create return order API call to RMS

3. RMS makes the return awb generation API call to logistic aggregator.

4. The logistic aggregator generates the return awb at its end, and returns the details in the response.

5. RMS returns the return awb details in the response to Client’s system

6. Client’s system now makes the Create Return Order API call of WMS Magic 2 to push the return order to Increff WMS

7. Clickpost ( logistic agregator) sends the tracking updates for the return orders to RMS (when the return order is picked up, when the return order is in transit etc.)

8. RMS makes the notification API calls to the Client's system for these updates.

Return Order Creation Flow 3 (No involvement of RMS)

...

1. The Customer creates a return on the customer facing Website.

2. The client’s system makes the API call to Logistic Aggregator to generate the return AWB.

3. The logistic aggregator returns the return awb details in the response.

4. The client’s system then uses these details and pushes the Customer return order to WMS Magic.