https://solidus.io logo
Join Slack
Powered by
good evening. i'm looking for some advice. my team...
# support
f
good evening. i'm looking for some advice. my team is looking to implement a feature where customers can pre-pay for mulitple orders (kinda like a subscription where they'd pay once and get products now, in 1 month, 2 months, etc). it's not really a subscription since they're paying once up front. like they have 1 of product A and 2 of product B, and they want to pay for 3 months/deliverys/ one approach we were thinking was using 
cartons
where all the products would be in a single order (3xA and 6xB) and then break it up into 3 cartons (1xA and 2xB, 1xA and 2xB, ...). at least in that case, the payment data model stays the same (1 payment for 1 order). but the order's "state" gets a little more complicated w.r.t shipment status. another approach would be to generate 3 distinct orders, but it seems trickier to get them all under a single payment. does anybody have any suggestions or prior art on doing something like this?
j
Any reason you're reaching for cartons, rather than just shipments? Is it just because there's a single shipping cost associated with the whole thing?
f
there would be 1 cost, but multiple shipments
i was thinking cartons because it seemed that would be the simplest way to implement the splitting logic in a calculator
j
Yeah, then I think you're on the right track with using cartons. Sure the shipment status will be a bit weird until the whole thing ships, but I wouldn't consider that a huge issue (unless you've got ERP integrations or something depending on that, and even that would be solvable.)
Yeah, I would imagine the trickiness would be mostly on the fulfilment side here: making sure these orders get fulfilled correctly and on the right interval. If you can sort out the complexity on that side, I think cartons is a very sensible way to go for this.
f
heh, sigh, so i was just informed that our custom warehouse management system (we pack/ship our own products) depends on/enforces uniqueness at the order level
so now it's just the lesser of 2 evils. figure out how to group together orders on the solidus side (mostly concerned about having a single payment) or overhaul our fulfillment side
j
Yeah, my worry would be the complexity is all on that side, making sure these order get fulfilled/accounted for correctly.
Cartons do have numbers that you could use to distinguish them, but I'd also have questions as to how the payments are supposed to show up for these orders.
f
we have a totally custom FE, so my thought was that we'd detect if there were mutliple orders with the same payment and that would distinguish them as this type of "batch order". then we'd show each carton/shipment with it's shipping status/contents
j
I meant as far as being transmitted to your ERP/accounting system/etc.
Another option (which definitely has some complexity) would be to use store credit. Have a custom store credit type that the custom is essentially purchasing and the subsequent orders are created and paid for using that store credit type. That's a solution that raises accounting questions though.
f
yea
hmmm. unless we created an order as the cart products + 2 coupons/credits towards the next orders. then after payment processing, we'd generate 2 duplicate orders and apply those credits
j
It's definitely another option. I'm no accountant, but it does reflect the liability of presale a bit better. Depends on how you want to track that stuff.
f
yea, it's kinda like a gift card from a rev-rec perspective
sg thumbs up 1
@Jared Norman thanks for taking the time to talk through that with me. i've got some thinking/investigating to do on our end
j
Any time! Don't hesitate to reach out if you want to work through any more of it.
k
Is this for something like a magazine?
Back in the days before Solidus was forked from Spree, I implemented something very similar and released as an extension: https://github.com/nebulab/spree-subscriptions It is for spree, but I think that it’s not super hard to make it work with the current Solidus with some tweaks.
It basically gives you an admin interface to mark a variant as subscribable. When the order is placed a new subscription for that user and that variant is created. When you release a new “edition” of the magazine (or whatever you need), it creates a free order for each user still subscribed and reduce by 1 the remaining issues they will get. It will send a couple of emails when the subscription is about to end or ended, so people can come back to the website and subscribe again.
s
I’ve implemented something very similar to this in the past and found store credits to be a nice (but not perfect) solution.
3 Views
Open in Slack
PreviousNext
Powered by