MF - Cart functionality

[char-star]

For supporting cart functionality:

Multiple items

One customer, one agent, fulfillments are independent

• Remove/make-optional the provider attribute on order object. That will take away the dependency of having items of same provider. The items array can contain multiple items from same/different providers
• there will be multiple items, each representing a scheme
• there will be multiple fulfilments, each associated with a scheme. Customer and Agent information will be duplicated in each fulfillment object.
• there will be single payment for all the schemes together
• quote object will contain breakup for each item + fulfillment combo
• cancellation is all together for the order - not possible for each fulfillment
• refund visibility in case of partial fulfillments (eg. one of many item fulfillments failed and only that amount needs to be refunded): will take this up as part of #406

Lumpsum + Lumpsum

• two items, two fulfilments of type lumpsum
• one payment for both
• quote will contain line items separately for item+fulfilment combo
• order status is derived basis the combination of two fulfilments
• both lumpsum fulfilments will complete after success

SIP + SIP

• same as lumpsum+lumpsum
• one mandate for both SIPs
• order will be completed only when both the SIPs are fully done
• another way to solve this is let the buyer app make two orders, but let him use the mandate created in the first sip, and attach that to the second sip. Even if the mandate is in pending/inprogress state, it needs to be shown and allowed to attach as a payment option for the second sip

Lumpsum + SIP

• Let the buyer app make two separate orders

Redemption + Redemption

• Don't see a usecase except where atomicity is needed. Let the buyer app make two separate orders

Lumpsum + Redemption

• Don't see a usecase except where atomicity is needed (rebalancing usecases). Let the buyer app make two separate orders

[ShubhangaAcharya]

Things to consider

• If multiple fresh purchases across different AMCs are being attempted, should seller app communicate multiple AOFs? If yes, how?
• Currently, if a purchase order is attempted but no folio number is provided, seller app shares the list of folio numbers to select from. At present (Folio number,Email,Mobile, Holding Pattern, Primary Investor name ) are shared. In case of multiple purchases, if folio number is not shared, should we share folio number list across AMCs. If yes, we have to include AMC code also so that BuyerApps can figure out what folios belong to what AMCs and allow selection of folios accordingly.

[char-star]

Things to consider

* If multiple fresh purchases across different AMCs are being attempted, should seller app communicate multiple AOFs? If yes, how?

If the investor is KYC compliant and folios have to be created in two AMCs - seller app can send one folio opening form which will capture all the details needed and internally open folios in two AMCs. I don't think there is a need to send multiple folio opening forms. In case, there is a variation on data fields that need to be captured (future) for each AMC, a superset of that can be sent in the folio opening form.

* Currently, if a purchase order is attempted but no folio number is provided, seller app shares the list of folio numbers to select from. At present (Folio number,Email,Mobile, Holding Pattern, Primary Investor name ) are shared. In case of multiple purchases, if folio number is not shared, should we share folio number list across AMCs. If yes, we have to include AMC code also so that BuyerApps can figure out what folios belong to what AMCs and allow selection of folios accordingly.

Currently folio numbers are shared as part of the fulfillment object which is tied to a particular item. So amc code is not needed explicitly, it can be derived from the item (that is scheme)

[char-star]

1. As per the current order states, order will move to COMPLETED state when the fulfillment becomes successful. In case of cart, if one item fulfillment is successful and the other is pending or failed - then the order remains in ACCEPTED state. Is it a good idea to introduce a PARTIALLY_COMPLETED state to be explicit.

2. Current cancel api supports cancelling of an order. In case of SIP cart (two schemes, two fulfillments), if the user wants to cancel only one SIP, cancel api can't support it as it doesn't have cancel on fulfillment. Should we move the cancellation to update call to have granularity or not support SIP cart and let the buyer app place multiple orders?