A subscription that will be billed in arrears based on actual consumption
Optional setup fee that would be a one time charge, billed in advance
Ability to capture a customer deposit upfront that would then be drawn down based on monthly usage
AND/OR customer commits to a certain “spend” and longer term (one or more years) in exchange for higher discounts
I DO NOT expect Moqui to support all of this out of the box. My questions are generally around the best way to leverage existing functionality along with custom development to satisfy the full requirements. Here is how I am thinking about it:
I would like to use sales orders for a “quote, contract, order” process
The setup fee should be pretty straight forward using standard order processing, invoice, and payment
I will create an Agreement and use AgreementItem and ProductPrice to capture the customer specific price for the usage product
I am planning to use FinancialAccount to track customer balances
I am looking at the deprecated multi tenant functionality, specifically Subscription and SubscriptionResource entities, along with the DEMO_TNT product and the related OrderServices and SubscriptionServices
I am NOT planning to use recurring orders. The usage will come in (this will be custom), and I will generate invoices from the usage data based on information from the Agreement and Subscription (e.g., customer negotiated price from the ProductPrice record, contract start/end dates, etc.)
The first couple of hurdles I need to get over:
Best way to setup a product for usage - I need to put it on an order line and capture the price the customer will pay per unit when usage comes in. But there will be nothing to charge in advance so I don’t want it to end up on an invoice. It is basically a negotiated price per unit for future charges. Should I be thinking about this differently, for example how rates are setup in HiveMind?
How to capture a customer deposit - I have no idea how to “fund” customer accounts. Can this be processed using a sales order and charging a CC or sending customer an invoice?
Once I can figure out the above two questions I am planning to use the existing order processing code and the demo multi tenant data for Product, SubscriptionResource, and ProductSubscriptionResource to setup the subscription. I will add custom code to create and link to an Agreement.
How variable is the negotiated price per unit going to be? If it’s going to be highly variable you are going to want to be absolutely sure that it can’t be more simple for you and your customer to manage a price for the resources used. For example it may cost you 100 dollars per day per customer for the material resources used, however the cost may change over time as you adjust architecture and as your providers increase their prices. You may also have other expenses to factor in for a limit in a “material” cost price. What I’m trying to say is that setting a hard limit for in the price for the future with changing costs might need to be factored in, and instead of having a “negotiated” price per unit having a set of options for a price may be simpler to handle.
I may be understanding you wrong, but the idea of funding customer accounts may be legally tricky if they have a balance directly in dollars because that’s basically a bank or an exchange. Although I’m certainly no legal expert. Regardless it seems like it may be over-complicating it aws has only recently added “Advance Pay” to it’s services and is still in beta. Just charging the customer on a predefined period for the resources being used or paying up front with your costs well thought out would work well. You could also have them buy a “gift card” like product ahead of time and have an internal FinancialAccount associated with the party that can be used as a PaymentMethod with a backup PaymentMethod when it runs out. If you’re positive about having customer funds held in your system and are willing to take upon yourself the liability for that, then using a FinancialAccount would probably be a good way to track it similar to how a “gift card” product would work, but where you would store the funds used would be a whole nother can of worms that may not be worth getting into.
Thanks @michael, here are some clarifications to my questions:
Assume that the cost side is controlled and there will always be a margin. In other words no discount would be approved that would drive it negative.
I am specifically asking for suggestions on ways to setup a product in Moqui that will be billed in arrears. There is nothing upfront to be billed, I just need to put it on an order. When the order is approved the underlying subscription is created (this part is working by using digital products and the existing subscription services).
Financial accounts. Thanks for the suggestion to use this as a payment method along with a backup. This works well with my use case to have a backup CC on file. What I still need clarification on is specifically HOW do I get a balance into the financial account. I mean literally how do I perform the transaction in Moqui. For example you mentioned gift card.
Looks like this happens with ProductSubscriptionResource and SubscriptionResourceentities in the mantle-usl/SubscriptionServices.xml at master · moqui/mantle-usl · GitHub services file and possible the TenantSubscriptionServices. I couldn’t find a good screen for adding a subscription to a product, but if you end up creating one or tacking some functionality onto products / orders a PR would be welcome!
Hopefully this helps a bit with stuff like this. By the way, the primary way I find this stuff out is searching the code base and the web app with useful tools like service and entiy search in the web app, but sometimes stuff just is just only in the code base. See Searching Everywhere | IntelliJ IDEA Documentation for a reference on how to do it in Intellij (which is how I primarily do it).
Anyways, the primary idea is to search for stuff you know like subscription and FinancialAccount, and you’ll be able to find what you’re looking for. A good practice is to look at what services have the search term and what entities those services use. This kind of thing certainly could be improved, but knowing how to find the information already in Moqui is an important skill to have when dealing with it.