Playing around, I’ve found a way to at least approximate the look of the missing “Money” data type. The main complaint from its lack is that using floating point, instead of integer, math induces rounding hassles. First, instead of storing money as separate ($, €, etc.) plus decimal cents, store the full value in cents. Panorama’s 64 bit integers provides a range of ± 90 Quadrillion to the nearest cent, which should be vast enough any stable currency, albeit not for worst case hyperinflated ones. You’d have to carefully keep straight the implied units of your numbers, potentially integer dollars, integer cents, or floating point dollars & cents to avoid 100x conversion errors, a doable task I leave to you. You’d also have to watch the rules for combining numeric types (Panorama Help > Numbers) if you want to keep your results as integers and avoid rounding.
The real problem then becomes we humans would want to see “integer” cents displayed with a decimal point before the last two digits. Panorama’s output patterns don’t precisely allow such. An Output Pattern of #.## would display a floating point dollar plus cents like 1.23, but same pattern would display the integer cents as 123.00. But Panorama X offers additional Numeric Pattern options, specifically those for Multiple Component Numbers. The Help Wizard offers Pattern “###-##-####” as an example for use with social security numbers. Other characters can be displayed as text at specific positions within floating point or integer numbers." Alas, the “.” character (Unicode 002E), aka “period,” aka “decimal point” is privileged within the Numeric Patterns and can’t be used that way.
However, Panorama X now supports Unicode and its vast array of characters offers options that look like a “decimal point”, but aren’t, and can be used just like the “-” characters in the social security code pattern. The best alternative in many fonts seems to be “․” (Unicode 2024), “One Dot Leader.” It looks identical to my eye in both appearance and spacing within the Formula Wizard to a “decimal point.” Giving integer 123 cents an Output Pattern of #․## displays that integer as 1․23, when I use Character viewer to search for 2024 then enter it there instead of a decimal point. So far so good! But if I change the integer to 1234 and use that Output Pattern it still displays 1․23, not the desired 12․34. Not so good. Changing the Output Pattern to ##․## displays 1234 as 12․34, but displays 123 as 01․23. You have to add enough leading “#” characters to your pattern to allow for the possible length of your integer and you have to put up with leading zeros for shorter integers. If you want to display commas every three digits you can provide them, but may have to put up with leading commas if your integers vary enough. I don’t see how to avoid the leading extras showing in the data sheet. But if your integer cents are to be displayed via the pattern( function, as on a TDO or some other formulaic output, you can build a variable reflecting that integer’s length [eg. ?(length(integer)<4, "#․##",rep("#",length(integer)-2)+"․##")] to use for the functions pattern and avoid the leading extras.
In principle the above method could also be used to mimic other “fixed point” data points while allowing for integer rather than floating point math. For non-US systems that use different separators for decimal numbers you’d need to find a Unicode look alike for your comma, etc. Such are probably available although may not be available in all fonts. Whether the hassles involved herein are a good trade for the rounding hassles involved with using floating point math for money values I leave up to you.
I suspect the inelegant data sheet display issues could be resolved by Jim adding additional characters to the Numeric Function toolkit, versions of “#” and “,” that would only display in Multiple Component Numbers when there were sufficient digits available. I also suspect Jim would prioritize that addition to the bottom of his very long list.
