It seems you could put everything, either directly or indirectly, in some journal-without-dit.beancount file, and then have another file journal-with-dit.beancount that contains your plugin directive and includes "journal-without-dit.beancount".
You might also be interested in https://github.com/jbms/beancount-import since it can handle merging matching entries sourced from different accounts, even with different dates. The dates are currently recorded as a date metadata field on each posting, to allow for the postings to have different dates, although I don't do anything with them yet; once there would is a "standard" way to deal with or represent these dates it would be easy to migrate, though. On Mon, May 2, 2016 at 7:58 AM, Filippo Tampieri <[email protected] > wrote: > My use case is due to the interaction of the deposit_in_transit plugin and > the transaction completer I use during import. > > The transaction completer relies on the past entries to figure out which > account to assign to the second posting of imported entries. > The deposit_in_transit plugin helps me deal with transactions such as > credit card payments that appear in both the bank statement and the credit > card statement. > For example, when I import my bank account statement, the transaction > completer would complete an entry like this: > > 2016-03-23 * "Payment to AMEX" > Assets:MyBankAccount -1261.98 CAD > Assets:DIT:Amex > > When I import my credit card statement, the transaction completer would > complete the corresponding entry like this: > > 2016-03-24 * "PAYMENT RECEIVED - THANK YOU" > Liabilities:Amex 1261.98 CAD > Assets:DIT:MyBankAccount > > As you see, the first entry uses Assets:DIT:Amex to indicate that it is > depositing funds in the Amex account rather than using the Assets:Amex > account directly. > Similarly, the second entry receives the funds from > Assets:DIT:MyBankAccount rather than directly from Assets:MyBankAccount. > > This allows the importers to import all entries and I do not have to worry > about detecting a transaction that is common to the two statements and > commenting it out on one side and possibly dealing with the different dates > of the two entries (which could cause a problem with balance assertions in > certain cases). > > Instead, I run the deposit_in_transit plugin that automatically creates a > new entry that ties to first two: > > 2016-03-24 * "Payment to AMEX / PAYMENT RECEIVED - THANK YOU" > Assets:DIT:MyBankAccount 1261.98 CAD > Assets:DIT:Amex > > It also tags pending deposits and tags and links cleared transactions, but > that is beyond the point of this discussion. > > The problem I have is caused by an extension I made to the > deposit_in_transit plugin. When the two entries happen on the same date, > accountants will usually remove the transaction from the deposit-in-transit > account (I use a pair of deposit-in-transit accounts, but just because I > want those account names to give you info about the source and destination > of the funds in the original entries) and use the original source and > destination accounts directly. So, my plugin will do this as well and when > faced with two entries such as: > > 2016-03-23 * "Payment to AMEX" > Assets:MyBankAccount -1261.98 CAD > Assets:DIT:Amex > > 2016-03-23 * "PAYMENT RECEIVED - THANK YOU" > Liabilities:Amex 1261.98 CAD > Assets:DIT:MyBankAccount > > (note that the only thing changed is that the two entries now share the > same date), instead of adding a new entry to link them, it will replace > them with a single entry: > > 2016-03-23 * "Payment to AMEX / PAYMENT RECEIVED - THANK YOU" > Assets:MyBankAccount -1261.98 CAD > Liabilities:Amex 1261.98 CAD > > Nice and tidy. > But now, here is the problem with the import stage; when importing an > entry such as: > > 2016-03-23 * "Payment to AMEX" > Assets:MyBankAccount -1261.98 CAD > > The transaction completer will look at past entries to come up with a > reasonable second posting; if it used the results of the deposit_in_transit > plugin, it would use: > > Liabilities:Amex > > as the second leg, while I want it to use the same account that I use in > my beancount file, i.e.: > > Assets:DIT:Amex > > Otherwise, I will end up with two entries (one from the bank statement and > one from the credit card statement) describing the same transaction! > > So, my solution would be to disable the deposit_in_transit plugin when > using bean-extract. > > > On Mon, May 2, 2016 at 10:28 AM, Martin Blais <[email protected]> wrote: > >> You could always look at the name of the top-level module >> (__main__.__file__) or sys.argv. >> That's a bit of an odd need. >> What's the use case? >> >> >> On Mon, May 2, 2016 at 9:22 AM, Filippo Tampieri < >> [email protected]> wrote: >> >>> I need one of my plugins to know whether it is running from within >>> bean-extract or otherwise. >>> Is there a clean way to achieve that? >>> Thank you, >>> fxt >>> >>> -- >>> 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 post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/beancount/66ae4e5b-6706-4b0d-ae78-f9dbd12eae82%40googlegroups.com >>> <https://groups.google.com/d/msgid/beancount/66ae4e5b-6706-4b0d-ae78-f9dbd12eae82%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to a topic in the >> Google Groups "Beancount" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beancount/IUlEVn3v3oE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> To post to this group, send email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/beancount/CAK21%2BhNSjn72JBD4vxuELQDqR_67AtomH%3DKbCffjDgeA-bXw4Q%40mail.gmail.com >> <https://groups.google.com/d/msgid/beancount/CAK21%2BhNSjn72JBD4vxuELQDqR_67AtomH%3DKbCffjDgeA-bXw4Q%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > 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 post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/beancount/CAKgGm2iQR3u8ttQw0hxugwa%3DGazqZH5v-cyGUSpQeu44qE5J-Q%40mail.gmail.com > <https://groups.google.com/d/msgid/beancount/CAKgGm2iQR3u8ttQw0hxugwa%3DGazqZH5v-cyGUSpQeu44qE5J-Q%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAKJfoCHq2wCK7OgKMa-EP82s6XC0atE0qSENCKq%2BHPsLRaC%2B8A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
