Overview
This document provides describes an forward order life cycle flow for current the Ajio Dropship Integration and new Ajio VMS Integration.
Forward Flow
Model 1 : E-invoicing through client’s ERP
Flow Diagram
...
Forward Order Flow
Assure Omni will fetch B2C order details through Increff's VMS Integration Layer using date filters from Ajio Channel.
Assure Omni will soft reserve the inventory. Assure Omni will send Acknowledgement Increff's VMS Integration Layer for that order. Increff’s VMS Integration layer will hold acknowledgement for definite time (4 hours) and then will send it to Ajio. At this step Ajio will stop customer cancellation. Here 4 hours of window will enable customers to cancel the order.
Increff's VMS Integration Layer will fetch B2B order details for which acknowledgement is sent.
Increff's VMS Integration Layer will send B2B orders to client’s ERP via Increff’s ERP integration(Assure Omni Magic/Standard ERP Integration/ Custom Integration). Here orders will have the final quantity only for which invoice is to be created.
Client’s ERP will make an invoice for the final quantity submitted for B2B PO and give it to Increff's VMS Integration Layer.
Order will be released for picking.
During packing, for invoiced quantities Increff’s VMS Integration layer will generate B2B invoice at Ajio and other quantities will be cancelled for that order. B2B invoice will be updated with QR code and IRN number and the same will be uploaded to Ajio channel. If some items are not found in the warehouse or damaged, the whole order needs to be cancelled as the E invoice is already generated in ERPs and Increff can not cancel it partially on Ajio side.
B2C Invoice and Shipping labels will be fetched for each B2C order while packing in the warehouse.
At the time of handover, Increff will make a Create Manifest call to Ajio to create a manifest for shipments at Ajio channel’s end.
This will end the forward order life cycle.
Interfaces to be Implemented
For any client to go live on Ajio VMS model with Increff the following interfaces need to be implemented:
...
Article master creation - This api will be needed to automate tasks of uploading article master and listings against Assure Magic 2 channel. This step can be optional if in order posting Client sku id/EAN is allowed in place of some other variant id. If some other variant id is required in order posting then please refer to below document :https://increff.atlassian.net/wiki/spaces/IOSA
...
Interfaces coloured in blue are Mandatory Interfaces.
Flow Name | Details | Remarks |
|---|---|---|
B2B Order Posting | Omni will push B2B order details fetched from Ajio to ERP against which the ERP will generate an e-invoice. Here the Event Type in the postings is set as OUTWARD_ORDER_CREATE. | We support two ways for this -
|
Post B2B Invoice | Once the client’s ERP generates the e-invoice it needs to pushed to Omni. | We have an API to Push B2B Invoice. |
...
B2B Order Cancellation Posting - from Increff’s ERP integration layer to client’s ERP. If the client’s ERP is integrated via Assure magic then they can refer to the Order Posting from Assure section in the document below. Here only Complete cancellation (OUTWARD_ORDER_CANCEL) will be sent and not the partial cancellationhttps://increff.atlassian.net/wiki/spaces/IOSA
...
B2B Invoice details posting to Increff
Model 2 : E-invoicing through Increff (RMS)
Flow Diagram
...
Forward Order Flow
Assure will fetch B2C order details through Increff's VMS Integration Layer using date filters from Ajio Channel.
Assure will soft reserve the inventory. Assure will send Acknowledgement Increff's VMS Integration Layer for that order. Increff’s VMS Integration layer will hold acknowledgement for definite time (4 hours) and then will send it to Ajio. At this step Ajio will stop customer cancellation. Here 4 hours of window will enable customers to cancel the order.
Increff's VMS Integration Layer will fetch B2B order details for which acknowledgement is sent.
After fetching B2B information, Increff’s VMS Integration layer will release the order for picking.
Here if items are not found or damaged, order can be partially canceled.
During packing, B2B invoice will be created by Increff’s RMS. The same will be generated, updated and uploaded to Ajio.
B2C Invoice and Shipping labels will be fetched for each B2C order while packing in the warehouse.
At the time of handover ,Increff will make a Create Manifest call to create a manifest for shipments at Ajio channel’s end.
This will end the forward order life cycle.
Manual Tasks to be done by Client
Clients can download reports for E-invoices generated by RMS in a defined date range on the RMS UI. They can use this for reference or manually upload it to their ERPs.
Return Flow
There are two return models supported via Ajio VMS Integration.
Credit Note Model
RSI Model
Model 1 : Credit Note
Return Order Flow - Credit note via ERP
Increff’s VMS Integration layer will receive a return expectation from Ajio against a Forward order number. This can be a customer return or RTO. In case a warehouse has not received return expectation from Ajio for an RTO, Increff’s VMS Integration layer can generate an RTO request to Ajio through Ajio VMS RTO Generation after which Increff’s VMS Integration layer will receive return expectation as RTO in some time.
This return will be processed in the warehouse and qc updates will be shared with Ajio through Increff’s VMS Integration layer.
Return order postings - from Increff’s ERP Integration layer to client’s ERP. If a client's ERP is integrated via Assure magic 2 they can refer to the Return Order Posting section in the document below. Here Shipment Array will come empty: [].https://increff.atlassian.net/wiki/spaces/IOSA
Credit note posting to Increff - After this client’s ERP has to generate credit note and share with Increff’s VMS integration layer via Ajio VMS Credit Note API Interface. This will send credit note information to Ajio.
Any Qc bad or missing items have to be handled offline with Ajio. Qc updates will be shared through integration but settlements should be done manually.
Return Order Flow - Credit note via RMS
...
/OID/pages/510853817/Ajio+VMS+Integration+Flow#Post-B2B-Invoice-API-- | ||
Cancelled Order Postings | If the customer cancels the order after the e-invoice has been generated by the client, Omni will send another posting to the client’s ERP which will cancel the order(e-invoice) in their ERP. Here the Event Type in the postings is set as OUTWARD_ORDER_CANCEL. | We support two ways for this -
|
Complete order Postings | Once the order is completed in the warehouse, this posting is sent to Client’s ERP. The main purpose for this posting to create a return order against a partially cancelled orders. If the order gets partially cancelled by the customer after the e-invoicing is done by the ERP, the ERP can consume this posting to create a return order for the items which were cancelled by the customer. Here the Event Type in the postings is set as OUTWARD_ORDER_COMPLETE. | We support two ways for this -
|
Post B2B Invoice API -
| Include Page | ||||
|---|---|---|---|---|
|
Model 2 : E-invoicing through Increff (RMS)
Flow Diagram
...
Forward Order Flow
Omni will fetch B2C order details through Increff's VMS Integration Layer using date filters from Ajio Channel.
Omni will soft reserve the inventory. Omni will send Acknowledgement Increff's VMS Integration Layer for that order. Increff’s VMS Integration layer will hold acknowledgement for definite time (4 hours) and then will send it to Ajio. At this step Ajio will stop customer cancellation. Here 4 hours of window will enable customers to cancel the order.
Increff's VMS Integration Layer will fetch B2B order details for which acknowledgement is sent.
After fetching B2B information, Increff’s VMS Integration layer will release the order for picking.
Here if items are not found or damaged, order can be partially canceled.
During packing, B2B invoice will be created by Increff’s RMS. The same will be generated, updated and uploaded to Ajio.
B2C Invoice and Shipping labels will be fetched for each B2C order while packing in the warehouse.
At the time of handover ,Increff will make a Create Manifest call to create a manifest for shipments at Ajio channel’s end.
This will end the forward order life cycle.
Manual Tasks to be done by Client
Clients can download reports for E-invoices generated by RMS in a defined date range on the RMS UI. They can use this for reference or manually upload it to their ERPs.
Return Flow
There are two return models supported via Ajio VMS Integration.
Credit Note Model
RSI Model
Model 1 : Credit Note
Return Order Flow - Credit note via ERP
Increff’s VMS Integration layer will receive a return expectation from Ajio against a Forward order number. This can be a customer return or RTO. In case a warehouse has not received return expectation from Ajio for an RTO, Increff’s VMS Integration layer can generate an RTO request to Ajio through Ajio VMS RTO Generation after which Increff’s VMS Integration layer will receive return expectation as RTO in some time.
This return will be processed in the warehouse and qc updates will be shared with Ajio through Increff’s VMS Integration layer.After Return Processing, Credit note will be generated by RMS and will be shared to Ajio
Return order postings - from Increff’s ERP Integration layer to client’s ERP.
Credit note posting to Increff - After this client’s ERP has to generate credit note and share with Increff’s VMS integration layer via below API.
Any Qc bad or missing items have to be handled offline with Ajio. Qc updates will be shared through integration but settlements should be done manually.
Interfaces to be Implemented
All Interfaces are mandatory.
...
Flow Name | Details | Remarks |
|---|---|---|
Return Order |
...
Increff’s VMS Integration layer will receive a return expectation from Ajio against a Forward order number. This can be a customer return or RTO. In case a warehouse has not received return expectation from Ajio for an RTO, Increff’s VMS Integration layer can generate an RTO request to Ajio through Ajio VMS RTO Generation after which Increff’s VMS Integration layer will receive return expectation as RTO in some time.
This return will be processed in the warehouse and qc updates will be shared with Ajio through Increff’s VMS Integration layer.
Ajio will generate RSI documents and Increff’s VMS Integration layer will pull those documents. Increff’s VMS Integration layer will mark this RSI document as ‘ACCEPTED’ to Ajio. Here one RSI document can contain some partial return items and return items from different returns. It can be possible that return items which were not received yet. We have to mark that also as ACCEPTED because of throttling restrictions at Ajio. Here one possibility is Return order is not processed yet. Still RSI will be marked ACCEPTED.
Clients can get RSI reports from Ajio VMS Reports UI. Here they can get a return item level report using which they have to manually upload in their ERP to create Inward PO and do GRN against it.
Any Qc bad or missing items have to be handled offline with Ajio. Qc updates will be shared through integration but settlements should be done manually.
API Details
B2B Invoice Details Posting
Clients need to implement this functionality in their ERP side
Production Endpoint:
https://assure-proxy.increff.com/ajio-vms/b2bInvoice/posting
Staging Endpoint:
https://staging-oltp.increff.com/ajio-vms/b2bInvoice/posting
Headers
authUsername:
authPassword:
Method
POST
Payload
| Code Block | ||
|---|---|---|
| ||
{
"invoiceNumber": "9200006652",
"invoiceDate": "2020-10-16T20:22:28.000+05:30",
"forwardPurchaseOrder": "4042640641",
"isPartialInvoice": true,
"invoiceLineEntries": [
{
"channelSkuCode": "460491724004",
"quantity": 1
},
{
"channelSkuCode": "460491724006",
"quantity": 2
},
{
"channelSkuCode": "460491724008",
"quantity": 1
}
],
"qrCode": "String",
"irnNumber": "String",
"invoicePdf": "Base 64 encoded byte stream",
"invoiceURL": "Invoice PDF public URL"
} |
Response
Http Status Code: 200 [Success]
Payload Details
...
Parameter Name
...
Data Type
...
Description
...
Mandatory
...
invoiceNumber
...
String
...
Invoice number on Invoice Document
...
yes
...
invoiceDate
...
ZonedDateTime
...
Invoice date and time with zone information
...
yes
...
forwardPurchaseOrder
...
String
...
Purchase Order Number
...
yes
...
qrCode
...
String
...
QR Code
...
yes
...
irnNumber
...
String
...
IRN number
...
yes
...
isPartialInvoice
...
Boolean
...
If ERP has created partial invoice for complete order then it will be true
...
yes
...
invoiceLineEntries
...
List
...
This is required only in case there can be multiple invoices against one PO.
...
no
...
channelSkuCode
...
String
...
This will be the SKU code sent during Ajio order posting.
...
no
...
quantity
...
Integer
...
Sku quantity that is invoiced
...
no
...
invoicePdf
...
String
...
Base 64 encoded byte stream
...
Any one of these is mandatory.
...
invoiceURL
...
String
...
Invoice PDF public URL
Credit Note Details Posting
Clients need to implement this functionality in their ERP side
Production Endpoint:
https://assure-proxy.increff.com/ajio-vms/creditNote/posting
Staging Endpoint:
https://staging-oltp.increff.com/ajio-vms/creditNote/posting
Headers
authUsername:
authPassword:
Method
POST
Payload
| Code Block | ||
|---|---|---|
| ||
{
"creditNoteNumber": "11000",
"returnOrderId": "11000",
"ackNumber": "11000",
"ackDate": "2020-10-16T20:22:28.000+05:30",
"irnNumber": "1",
"signedQrCode": "string",
"signedCreditNotePdf": "Base 64 encoded String",
"creditNotePdfUrl": "string"
} |
Response
Http Status Code: 200 [Success]
If Status Code is other than 200 then Client has to retry that particular call
Payload Details
...
Parameter Name
...
Data Type
...
Description
...
Mandatory
...
creditNoteNumber
...
String
...
Credit note number
...
yes
...
returnOrderId
...
String
...
Return Order Id
...
yes
...
ackNumber
...
String
...
Ack Number
...
no
...
ackDate
...
ZonedDateTime
...
Ack date and time with zone information
...
no
...
signedQrCode
...
String
...
QR Code
...
yes
...
irnNumber
...
String
...
IRN number
...
yes
...
signedCreditNote
...
String
...
Base 64 encoded byte stream
...
Any one of these is mandatory
...
creditNoteUrl
...
String
...
Credit Note Pdf public URL
RSI Fetching
Clients need to implement this functionality in their ERP side
Production Endpoint:
https://assure-proxy.increff.com/ajio-vms/rsi
Staging Endpoint:
https://staging-oltp.increff.com/ajio-vms/rsi
Headers
authUsername:
authPassword:
Method
GET
Request
Query Parameters
...
Parameter Name
...
Data Type
...
Description
...
Mandatory
...
rsiDateFrom
...
ZonedDateTime
...
Date to fetch RSI from.
...
yes
...
rsiDateTo
...
ZonedDateTime
...
Date to fetch RSI to.
...
yes
Note:-rsiDateFrom and rsiDateTo should not be more than 2 days apart.
Produces
application/json
Sample Response:
| Code Block | ||
|---|---|---|
| ||
{
"returnSalesInvoices": [
{
"rsiNumber": "3100000374",
"createdAt": "2020-10-16T20:22:28.000+00:00",
"rsiPdfUrl": "https://storage.googleapis.com/dev-oltp-nextscm-com/ARVIND/RSI/257e46e4-8ad3-4f77-98ff-d09b2b9bb904.pdf",
"billingNo": "33111150000047",
"irnNumber": "c46a3047f428c7ee8e29954a5bbaa82a2170879db",
"qrCode": "eyJhbGciOiJSUzI1NiIsImtpZCI6IkVEQzU3REUxMzU4",
"rsiLines": [
{
"returnOrderCode": "RT11381010",
"clientSkuCode": "8903537740123",
"hsn": "61091000",
"quantity": 2,
"rsiLineAmount": 2077.2,
"totalLineTax": 0,
"taxSummary": {
"cessAmount": 0,
"cessPercentage": 0,
"cgstAmount": 0,
"cgstPercentage": 0,
"igstAmount": 0,
"igstPercentage": 0,
"sgstAmount": 0,
"sgstPercentage": 0,
"tcsAmount": 0,
"tcsPercentage": 0,
"gstAmount": 0
}
}
]
}
]
} |
RSI Flow
...
Key Points
Along with the RSI, customer code and plant/store code will also be provided.
Line items can be identified by EAN in Return Sales Posting as well in RSI. Also return order id will be sent with return order posting as well as in RSI.
RSI Payload
| Code Block | ||
|---|---|---|
| ||
{
"returnSalesInvoices": [
{
"rsiNumber": "3100000374",
"locationCode": "MI50",
"channelName": "120997",
"createdAt": "2020-10-16T20:22:28.000+00:00",
"rsiPdfUrl": "https://storage.googleapis.com/dev-oltp-nextscm-com/ARVIND/RSI/257e46e4-8ad3-4f77-98ff-d09b2b9bb904.pdf",
"billingNo": "33111150000047",
"irnNumber": "c46a3047f428c7ee8e29954a5bbaa82a2170879db",
"qrCode": "eyJhbGciOiJSUzI1NiIsImtpZCI6IkVEQzU3REUxMzU4",
"rsiLines": [
{
"returnOrderCode": "RT11381010",
"clientSkuCode": "8903537740123",
"hsn": "61091001",
"quantity": 2,
"rsiLineAmount": 2078.2,
"totalLineTax": 0,
"taxSummary": {
"cessAmount": 0,
"cessPercentage": 0,
"cgstAmount": 0,
"cgstPercentage": 0,
"igstAmount": 0,
"igstPercentage": 0,
"sgstAmount": 0,
"sgstPercentage": 0,
"tcsAmount": 0,
"tcsPercentage": 0,
"gstAmount": 0
}
},
{
"returnOrderCode": "RT11381010",
"clientSkuCode": "8903537740124",
"hsn": "61091000",
"quantity": 1,
"rsiLineAmount": 2077.2,
"totalLineTax": 0,
"taxSummary": {
"cessAmount": 0,
"cessPercentage": 0,
"cgstAmount": 0,
"cgstPercentage": 0,
"igstAmount": 0,
"igstPercentage": 0,
"sgstAmount": 0,
"sgstPercentage": 0,
"tcsAmount": 0,
"tcsPercentage": 0,
"gstAmount": 0
}
}
]
}
]
} |
Return Order Posting Payload
...
| language | json |
|---|
...
Postings | After the return is processed in the warehouse, a return order posting is sent to client’s ERP. | We support two ways for this -
|
Post Credit Note | After the return is processed in the ERP, the ERP will need to generate a credit note. This credit note will be uploaded to Ajio. Any Qc bad or missing items have to be handled offline with Ajio. Qc updates will be shared through integration but settlements should be done manually. | We have an API to push credit note - |
API to Post Credit to Omni
| Include Page | ||||
|---|---|---|---|---|
|
Return Order Flow - Credit note via RMS
Increff’s VMS Integration layer will receive a return expectation from Ajio against a Forward order number. This can be a customer return or RTO. In case a warehouse has not received return expectation from Ajio for an RTO, Increff’s VMS Integration layer can generate an RTO request to Ajio through Ajio VMS RTO Generation after which Increff’s VMS Integration layer will receive return expectation as RTO in some time.
This return will be processed in the warehouse and qc updates will be shared with Ajio through Increff’s VMS Integration layer.
After Return Processing, Credit note will be generated by RMS and will be shared to Ajio.
Any Qc bad or missing items have to be handled offline with Ajio. Qc updates will be shared through integration but settlements should be done manually.
Model 2 : RSI Flow
Return Order Flow
Increff’s VMS Integration layer will receive a return expectation from Ajio against a Forward order number. This can be a customer return or RTO. In case a warehouse has not received return expectation from Ajio for an RTO, Increff’s VMS Integration layer can generate an RTO request to Ajio through Ajio VMS RTO Generation after which Increff’s VMS Integration layer will receive return expectation as RTO in some time.
This return will be processed in the warehouse and qc updates will be shared with Ajio through Increff’s VMS Integration layer.
Ajio will generate RSI documents and Increff’s VMS Integration layer will pull those documents. Increff’s VMS Integration layer will mark this RSI document as ‘ACCEPTED’ to Ajio. Here one RSI document can contain some partial return items and return items from different returns. It can be possible that return items which were not received yet. We have to mark that also as ACCEPTED because of throttling restrictions at Ajio. Here one possibility is Return order is not processed yet. Still RSI will be marked ACCEPTED.
Clients can get RSI reports from Ajio VMS Reports UI. Here they can get a return item level report using which they have to manually upload in their ERP to create Inward PO and do GRN against it.
Any Qc bad or missing items have to be handled offline with Ajio. Qc updates will be shared through integration but settlements should be done manually.