#kaizen_best-practices
buoyant adderBOT
👋 Welcome to your new thread!
⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.
⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.
🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1293228357357404172
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
onyx osprey
We run a printing business with pretty complex pricing structures.
I am looking to hear any input on suggested best practices/features I may not be aware of.
Our sales process works like this:
- Customer places manual order/quote request
- We generate a quote
- We send quote for approval
- If approved, we send an invoice or payment link for payment
- Customer pays invoice
- Order starts and so on
Our pricing formula works like this:
-
Orders may contain multiple line items
-
Line items consist of:
- Garment/garment color
- Sizings + Quantities per size
- Imprints (print locations/artwork)
Each garment has a base price, potentially adjusted by size surcharges.
Larger sizes like 2XL or 3XL have additional costs ($2 for 2XL, $3 for 3XL).
Print pricing is based on a primary location (base price) and then additional locations.
The primary price may sometimes be a variant such as a Primary "Jumbo" or Primary "Small"
The primary location pricing is not size dependant where as the additionals are.
The print location pricing is based on the overall garment count of the order made up from all line items and is scaled on breaks.
1-12 garment - $30/per piece
13-31 garments - $19/per piece
32-63 garments - $15/per peice
64+ garments - $12/per piece
Additional location pricing is based on the size of the print area and how many are selected:
up to 3x3 inches - $3/per location
up to 4x10 inches - $5/per location
up to 10x12 inches - $7/per location
up to 14x16 inches - $12/per location
up to 16x20 inches (Jumbo) - $15/per location
So to summarize an example order:
A Gildan 64000 Black T shirt (our cost + 75% markup)
- 5 small, 5 medium, 5 large, 5 2xl (garment cost * 20) + (2 * 5) for the 2xl size upcharge
- a primary print location of front center (this hits the $19/per piece breakdown)
- an additional location of 3x3 ($3 per shirt)
- a second additional location of 3x3 ($3 per shirt)
All this being said, as you can imagine - it can get very messy and complex.
How much off this pricing formula can be offloaded to Stripe realistically? And how much should be done on our side automation wise? Should I be seperating these line items further? E.g. print and garments are seperated? Should each garment size/color variation be an entirely new line item? Etc etc
Currently we have some pretty in depth workflows via Make for creating the quotes/invoices right now but I believe I am doing a few parts incorrectly regarding product/line item creation as well. The whole concept of products vs prices vs line items and their ability to have temp products (and allowing it to add pending line items) was a bit much at first for my brain haha.
Very curious on best practices regarding how I should approach solving our needs/requirements.
waxen merlin
Hello
Reading
Yeah I don't think I'm going to be able to give you too much specific guidance here. I agree this is a complex scenario but the premise is that you create separate Products/Prices for each different product you offer and the different prices for each. If there is dynamic charging based on the order then you can either add Invoice Items as line items using price_data inline or if that dynamic pricing is going to be the same based on certain scenarios then you can create Prices for each of those as well and add them as needed.
onyx osprey
Yeah I don't think I'm going to be able to give you too much specific guidance h...
Is it okay to have tons of products that are realistically never to be used again in terms of like data purity sake? The concept of "product" is a bit flawed for us as we're truly billing for a mix of service and product so like if we're just doing a concatonated string of the line item information then that product will likely never be applicable to another person and will be created for that invoice only.
waxen merlin
Yes that is totally fine
We don't have any limits on number of Products/Prices
So you should create this inventory in whatever way works best for you
waxen merlin
😂
onyx osprey
I couldn't find any simple solution for generating the line item body data as it requires form encoded data?
There's no JSON option?
waxen merlin
To be fair we are working on v2 APIs that accept JSON (https://docs.stripe.com/api-v2-overview). But only the Meters API is supported on v2 so far.
But yeah, sorry, no way around this right now.
onyx osprey
this took some time to figure out too (the iterator)
onyx osprey
based on this picture though, I am using the pricing/products correctly yeah?
waxen merlin
Yes
onyx osprey
Once a quote is approved via our Airtable forms (we send the quote PDF via sendgrid) this fires off our next process here
The concept of charging auto vs sending manually and auto advance was a bit confusing too
but I think I have this correct?
This was so we could bypass the 1 hour wait time
waxen merlin
If you are sending an Invoice for payment collection via the Hosted Invoice Page then you want to use send_invoice.
onyx osprey
Yep
waxen merlin
And yeah calling the send endpoint can let you bypass the 1hr wait time
waxen merlin
That would determine whether the Invoice was finalized/sent automatically after the 1 hour finalization period
If you turn auto_advance to off then the Invoice stays in draft
onyx osprey
Ah alright, so in our case it's somewhat irrelevant here
waxen merlin
That also determines whether things like automatic retries take place
onyx osprey
Got it
One more odd question - we have a seperate workflow for bypassing quote approval and generating an invoice directly, for some reason in the Make-based Stripe action "Create an invoice item" - there appears to be no name field, only description? Is this a limitation to how line items are created? When I was browsing the workbench I believe it creates it's own price/product on the fly to handle it or something?
Where as when I generated the quote API body manually, I could specify the product name/description of course.
Could also just be a Make limitation here
waxen merlin
When creating an Invoice Item you can create the Price in-line using price_data: https://docs.stripe.com/api/invoiceitems/create#create_invoiceitem-price_data
However you can't create a Product in-line here. You would have to already have created the Product and when you do that you can set its name: https://docs.stripe.com/api/products/create#create_product-name
onyx osprey
When creating an Invoice Item you can create the Price in-line using `price_data...
Got it, so I assume Make is using the first endpoint here
waxen merlin
Correct
You can't set name on Prices
That doesn't exist
(you can set nickname but that's not the same thing)
onyx osprey
Alright, that clears that up. Maybe someone else here will have any ideas for the initial question but thanks for your input regarding the other things.