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):
DayOfYear ( DocumentDate ) ≥ 96 then
TaxYear ( DocumentDate )
TaxYear ( DocumentDate ) - 1
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
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.
This is actually one of the few things I do without any scripting at all
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.
Thank you both
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.
Interesting… that’s the plumber in the US.
Also in the US, an engineer can be the person who drives a train…
(Engineer & Baldwin Steam Locomotive in Silverton | This was … | Flickr)
So is that a photo of a plumber or a train driver?
We have plumbers too! So that was a bad example.
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…
train driver? TRAIN DRIVER?!?
That, my friend is a locomotive engineer!
This is obviously working with old steam train tech but even modern trains have engineers.
I have great respect for plumbers (especially the Polish ones), and all the other skilled tradespeople who keep things running.
Trains still have Firemen too
So does this forum at times (and I don’t mean you)!
Of course. The others would not go places to ask for help but take back control. Of DT or whatever.