Thanks for the quick response @bruno29a. I was afraid that was going to be the answer… Unfortunately, these are the same workarounds that I have been using and they cause a waste of time, unnecessary workflow clutter and an unfriendly presentation / user experience. I suppose if a user were just doing a few simple calculations, all parties had 100% faith in the calculation engine and user workflow design, the approach and processes used required no explanation, and only the final output would ever be presented or viewed, then the “.toFixed(2) / convert to string” approach at the end might be adequate. Unfortunately those conditions are extremely rare in my world for custom projects. The node by node presentation within the workflow is often more important than the output.
I need to be able to do live walkthroughs and be able to review each individual node configuration / output tables on the fly with Accountants, CPAs, Comptrollers, CFOs, Auditors, Managers, Owners, etc. This requires a clean consistent currency presentation thought the workflow.
I have presented 2 separate forensic accounting projects in the last 2 days via interactive video conference. Both projects included several requests for a more friendly right aligned fixed decimal accounting presentation, and both projects became nervous and requested “excel calculation proofs” the second they viewed the higher precision output of a GroupBy Node prior to rounding. These were not issues when doing walkthroughs using a fixed decimal / currency friendly data type on Alteryx projects. It added hours of work to the project for me to create several multi sheet excel calculation proofs / manual excel formatting.
Forensic accounting projects like these often generate a single adjustment Journal Entry with a few support data sheets as the output which receive little scrutiny. The importance of a user friendly presentation is actually more important when presenting the calculation process within the workflow itself, then in the simple cleaned up output.
I really hope that a currency friendly fixed decimal data type is added in the future. I posted a new feature suggestion. Please add your support if you find yourself in need of a fixed decimal number or more currency friendly data type.