Australia Financial Year preference option?

Hi Jim,

I’ve been playing around with the Crosstab option in Panorama X - which is really terrific, unless you live in a country with financial year July to June instead of Jan to Dec. In my database, I’ve just adjusted the quarters by adding or subtracting 2, and storing it as a field, and similarly having a subroutine to ‘correct’ the financial year. However, the Crosstab automatically annotates quarters, but summarises to the ‘wrong’ year, to be useful to me. Would it be difficult to have a preference option to choose the appropriate financial system, to make the rest work properly for us???

Some businesses in the US have fiscal years that differ from January to December as well.

I like this idea.

Database setting would be better, in case someone has to deal with different fiscal (or whatever) years. Set it in .Initialize and leave it, unless it needs to be changed.

That was my initial thought as well, but I left the option open to see what people might think. Maybe both - a database option, and a preference to set the default for new databases. So if someone always wanted June to be the start of the fiscal year, they could set it once and never worry about it again.

I was thinking it would be a permanent database property, with a pop-up menu in the Database Options dialog and accessible in code using dbinfo( and setdatabaseoptions.

I am not certain whether anyone might have to use more than one fiscal year in the same database. As I work on my financial database, the one that sent me looking into APIs and Json, I see different equities that might have different fiscal years. Most of what I have pay dividends March, June, September, and December, which probably corresponds to their fiscal year, although maybe not. But several have different payment schedules. So if I wanted one file to deal with several different equities, there might be a need to change the fiscal year according to needs.

The idea of using a permanent database option had never occurred to me, as I could not see much use for it in my applications. However, the idea of using it to hold a value immediately struck me. In particular, that might be useful for storing API tokens. My exploration of these has led me to some other services, like one for postal codes and address verification. Besides the USPS interface, there is at least one other, and it claims to work with other country’s codes. If there were a good way to store tokens, anyone could use the code as long as they signed up for the proper service. Many of them offer free introductory tokens which are limited in things like the number of calls that can be made within a certain time period, but those would be sufficient for most people’s situations, and if they needed more, they could subscribe for more.

That’s the sort of thing permanent variables are for.

However, actually an API token would probably be for Panorama as a whole, rather than for a specific database. So really the best way to store an API token would be to use a preference value. This feature is perfect for that use.

Good to know. There are so many things to learn, so little time to learn them!

As I work with API tokens, I realize that preference values are the way to go, and I am not about to forget them. But it has slipped my memory in the past, and so for the sake of newcomers to the subject, I think that they should be linked in Help to Variables, or at least Permanent Variables.

The other advantage to preference values for tokens is that each user can be assigned a token, which is what some services require. Also, as the cost of the service, if there is one, depends on how much it is used, having different tokens for different users allows each user to pay for the amount that they use individually.

I am hoping to come up with some neat stuff that others can use.