Can anyone suggest a way to file documents automatically into tax years (fiscal years), preferably as part of a smart rule?
Basically what I would like to do is copy the functionality of the existing File > Document Date step in a smart rule, but using a year that’s calculated like this (in the case of the UK):
If
DayOfYear ( DocumentDate ) ≥ 96 then
TaxYear ( DocumentDate )
else
TaxYear ( DocumentDate ) - 1
End if
I do this all the time in FileMaker Pro, but replicating it in AppleScript would baffle me, not to mention how to get the document date into the script step within a smart rule, and then file the document based on the calculated tax year.
Tha background to this is that here in the UK taxes are calculated for the 12 months starting on 6 April, and a number of other countries have similar odd rules. As a result I spend more time than I’d like moving documents into DT folders that are named for tax years rather than calendar years.
It would be great to have a “fiscal year” function as one of the date-related placeholders in DT’s smart rules. But there would have to be a setting for when your fiscal year starts. That sounds complicated, and perhaps not of interest to enough people to make it a feature request.
Then there’s the question of how tax years are named. Wikipedia says the US uses the year in which the tax year ends, while in India it’s the year in which the tax year begins. In the UK the convention, at least among non-accountants, is to make it clear by writing 2021-22 or 2021-2022.
So, any ideas for a homebrew version would be very welcome. I can hear @BLUEFROG muttering “why bother?”, but it’s an entertaining project that I don’t think has been discussed here before.
The creation date of all my documents is set to the document date on import. I have a database for tax. That database contains a group called data, which in turn contains 8 subgroups (think “insurance”, “income”…). The database also contains one group for each year (so think “2020”…). Each of these contains 8 smart groups with the same names as the subgroups in the data group (so again, think “insurance”, “income”…).
The smart groups are set to display those records contained in the equivalent subgroup in the data group. They use conditions such as creation date is after 01.01.2020 00:00:00 and creation date is before 31.12.2020 23:59:59. Some records are relevant to a different tax year than their creation date would suggest, or to more than one tax year, so the smart groups include a condition “tag is: tax2020” for example.
The advantage of this setup is AI; I started with 8 subgroups for every year. However, AI never knew which year I wanted my income sheet to go into, for example. Now it always gets it right: it goes in data/income regardless of date. And the smart groups do the rest.
And me thinking that measuring weight in stones is the summit of British peculiarities…
Sorry, back to your question: first, you have to determine _which _ date is relevant for tax purposes. Is it the billing date, the date you received the bill or the date you paid it? For tax deductible donations, you might get the confirmation some time after the tax year ended. So that requires special consideration.
Once you know the relevant date of the document, you can sort it into the relevant subgroup depending on if it’s before April 6 or not. That should be feasible with a smart rule or minimal scripting.
You missed Brexit then? Thanks for pointing out the necessity of determining which date is relevant for tax purposes. That date could be included as custom metadata on importing the record, or on imprinting it “paid” or whatever, which should leave my suggestion feasible at least.
The smart folders route is clearly much better, or at least will be once I have suitable tags in place (at the moment I tend to organise stuff through groups and replicants). It’s great that DT offers more than one way to approach this.
And yes, @chrillek, you’re right that it might need some flexibility in which dates to use. Actually in the case of my micro-business I think the tax rules are pretty clear, it’s just that I sometimes don’t remember them…
I used to be a staunch remainer, but I now see the error of my ways. Clearly, this 6 April business is meant to keep us connected to Canada, India and the rest of the Empire. The European project was doomed from the start, and the rest of you can keep your own peculiar foreign habits.
As for stones, I despair. Britons who are approaching 50 now did their schooling in metric units. Thank goodness I’m an engineer – although of course in Britain an engineer is someone who comes to fix the drains.
I have great respect for plumbers (especially the Polish ones), and all the other skilled tradespeople who keep things running. But unlike in most of the rest of the world, anyone here can call themselves an engineer. These days that includes a lot of people who were previously, and honourably, known as fitters and technicians. To put it another way, we don’t name many streets after engineers and inventors.
From what little I’ve seen of steam trains I’d say there the two jobs are quite closely linked…
Thanks for pointing out the necessity of determining which date is relevant for tax purposes. That date could be included as custom metadata on importing the record, or on imprinting it “paid” or whatever, which should leave my suggestion feasible at least.
