"Subscribe & Save" (and maybe other) discounts not showing up

[kodek]

I have an item that I order monthly. Since I have multiple subscriptions, I get a discount. The item got shipped/charged alone. Here's a (cropped) screenshot:

The item shows up in YNAB as $10.02 which is the item's value + tax. The "subscribe and save" discount of $1.42 does not show up.

I checked the Items report, and it shows up as follows (redacted, but I attempted to keep CSV structure):

12/17/20,XXX,"XXX",XXX,"XXX","XXX",Amazon.com,,new,Amazon.com,,$9.99,$9.44,1,"XXX",,,[email protected],12/21/20,XXX,XXX,,XXX,XXX,1234-1234,Shipped,AMZN_US(XXX),$9.44,$0.58,$10.02,false,,false,XXX,USD,

The Orders and Shipments row is as follows:

12/17/20,XXX,"XXX",Amazon.com,,[email protected],12/21/20,XXX,XXX,,XXX,XXX,1234-1234,Shipped,AMZN_US(XXX),$9.44,$0.00,$0.58,$1.42,$0.58,$8.60,XXX,

Note that the discount of $1.42 shows up there (under the "Total Promotions" column).

[starsprung]

Thanks for the report, I'll get on it!

[starsprung]

I think the tricky part here is when there are multiple items in the order, since the Orders and Shipments only gives a "Total Promotions" value for the entire order. In that case I think the best I can do is proportionally distribute the discount to each item in the order. In the case of a Subscribe and Save discount that might be fairly accurate, but might not be accurate if the promotion is a coupon on a specific item in the order.

The other option would be to record discounts on multi-item orders as a separate transaction which would have to manually split and attributed to the correct categories. That's more or less how I currently handle shipping charges. It's not the best user experience though and would could be more bothersome with discounts than shipping.

[starsprung]

I also need to make sure tax is handled correctly. I live in a jurisdiction with no sales tax, so I haven't had data available to test this, are promotions always applied before tax?

[kodek]

think the tricky part here is when there are multiple items in the order, since the Orders and Shipments only gives a "Total Promotions" value for the entire order. In that case I think the best I can do is proportionally distribute the discount to each item in the order.

Isn't this analogous to shipping costs? I believe those show up as their own entries, correct? Perhaps discounts could show up independently as well. Subscribe & Save is a constant percentage across the order, but other discounts may only apply to specific items in the order.

The other option would be to record discounts on multi-item orders as a separate transaction which would have to manually split and attributed to the correct categories. That's more or less how I currently handle shipping charges.

Whoops. I should have kept reading 😃 . I think this is a reasonable workaround, personally. It would be more consistent than trying to reverse-engineer discounts.

are promotions always applied before tax?

It seems like it's after-tax, given that the numbers add up. Perhaps it's a rounding error. I can look for other data samples and confirm.

[starsprung]

Isn't this analogous to shipping costs? I believe those show up as their own entries, correct? Perhaps discounts could show up independently as well. Subscribe & Save is a constant percentage across the order, but other discounts may only apply to specific items in the order.

Yeah, that's an issue. It's unfortunate though that if someone has 20 subscribe and save items, YNAB won't correctly reflect the true cost of those without potentially having to split the promotional transaction into 20 transactions manually in YNAB. That's also an issue for shipping, but at least for me shipping charges are relatively rare. I think I'll go the simple route of just adding this separate transaction (which also has the benefit of being backwards compatible) and investigate the feasibility of adding an option to auto-distribute discounts/shipping. At the very least it can be done pretty simply for single-item orders.

are promotions always applied before tax?

It seems like it's after-tax, given that the numbers add up. Perhaps it's a rounding error. I can look for other data samples and confirm.

I guess it doesn't make a difference if I'm simply adding a separate transaction with the promotional discount. I think it would only be relevant if I was trying to proportionally spread the discount over multiple items.

[github-actions]

🎉 This issue has been resolved in version 1.4.4 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[kodek]

Thank you!