On Wednesday, October 5, 2022 at 5:32:54 PM UTC-7 [email protected] wrote: > Creative solution, using an intermediate account. > > I wonder if just an importer that requires both the credit card account > and the Amazon orders file in order to produce output isn't simpler. It's > just a join between these two datasets, and and CC importer could just fail > when the other file's not given to it. >
I did just that at some point, and the annoyances I ran into include: - having to have both sets of data together to do the import. Amazon GDPR requests for orders data take 24-48 hrs after submission (is there a better way?). So I'm stuck on importing my credit card data until the GDPR request goes through - Dates don't match: if I don't download both at exactly the same time, one is ahead or behind the other, meaning I have to point the scripts at historical downloads - I tend to use a bunch of different credit cards for purchases, compounding this problem - I tend to make full and partial payments using Amazon gift cards, which means I need to import all my payment sources along with my Amazon order history together, and it gets a bit more complicated than a simple join Of course, YMMV. Some/all of these may not apply to you, so a join-at-import might work well for you. Here's yet another idea that may be the best of all worlds: the thread posted by Archimedes just now was very timely: a nice solution would be to do each side of the import (payment / orders) independently, have the importer rewrite an existing matching entry if found; and if not found, book it to the intermediate account (for later rewriting when the other side is imported). -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/222cac43-1437-4b27-ac0d-9c3350592f36n%40googlegroups.com.
