Power Appsでの通貨表示
あけましておめでとうございます（もう遅い…）。
2020年の年末にPower Platformに出会い、約1年間 Power Appsを中心に勉強を続けてきました。
ある程度基本的なところは触ってきたかなという気がしますが、Output が全然できてないせいで、一度通過したことを調べ直すシチュエーションも多く、効率悪いなーと感じることの多いこの頃です。
2022年はもう一度初心に還って、基本的なことから備忘的にOutput をしていきたいなと思います。 僕自身、ノンプロの市民開発者ですし、技術的BGもほとんどないので、大半が調べたことを自分の備忘用に記載する内容が中心になると思いますが、なるべく週に1本程度の更新を目標に再開していきたいと思います。 基本的なところはできるだけ深堀して理解度を上げるというのも一つの目標です。
今年の第一弾はPower Apps での通貨型のデータの扱い(表示)について書いていきます。
通貨型のデータ
SharePointリストやDataverseなどでは通貨型のデータを設定し、扱うことができますが、Power Apps（ここではキャンバス。モデル駆動とかポータルについては調べてません）では、以下のような位置づけのようです。
浮動小数点数に格納される通貨値。 Currency 値は、通貨フォーマット オプションを使用した数値と同じです。
Power Apps のデータ型 - Power Apps | Microsoft Docs より。
浮動小数点数はさておき、結局のところ、直接的に通貨型のデータを扱えるわけではなく、数値型と同様に扱い、見た目をフォーマットすることで通貨表示にするという運用になっています。
フォーマットの書き方
Text関数を用いて記述します。
Power Apps での Text 関数 - Power Apps | Microsoft Docs 参照。
通貨の表示の際に使用するText関数の構文は、
Text( Number, CustomFormat, [ResultLanguageTag ] )
となっており、
第1引数：数値、第2引数：フォーマットの形式(プレースホルダー)、第3引数：言語タグ の形です。
第1引数（Number）
通貨の場合は数値型のデータを入れます。見た目が数値でもテキスト型のデータの場合もあるので、そういう場合はValue関数を使って数値型に直してやる必要があります。
第2引数（Custom Format）
ここにプレースホルダーを設定して、表示の形式を設定します。 使用するプレースホルダーは通貨の場合、以下のものを使います。
数値：＃、0
言語：[$-Language Tag] ←言語のプレースホルダー
通貨記号：$
区切り：ピリオドとコンマ(言語によってはスペースなども桁区切りとして使用可）
数値
例として通貨っぽく数値を色々なパターンで記述してみると以下のようになります。小数点以下が存在する通貨の場合は、#と0の使い分けに注意ですね。例では小数点以下第2位まで記述していますが、第3位以降がある少数を入力した場合は第3位が四捨五入されて第2位までの表示となります。 ↓↓↓見にくくてすみません、クリックして拡大してやってください…。
言語のプレースホルダー
米ドルを例にとると、 [$-en-US] という記述になります。$-以降が Language Tag で、言語－リージョン の形式です。 en-US なら 英語-アメリカ、en-GB なら 英語-イギリス といった感じです。 Custom formatの言語を特定する役割があり、 言語のプレースホルダーを設定していないと、自動的に自身の環境の言語プレースホルダーが設定されるようです。 そして、アプリの実行時にプレースホルダーが存在しない場合、[$-en-US]とみなされてしまうとのこと。
通貨記号
プレースホルダーとして第2引数に$を置くと、設定した言語により、通貨記号の表示を調整してくれ、日本語環境なら¥マークを表示してくれます。
『設定した言語』とは第3引数で指定した言語です。
この言語は第3引数で言語タグを使用することで設定できますが、省略した場合はユーザーの環境の言語が適用されます。
ですので、日本語の環境で日本円を表示する場合などは、これによって第3引数を省略することができます。
ただし、ブラウザやOSの設定を英語に変更しているなど、言語環境が異なると違う通貨記号になってしまうことがあるため、ユーザーの言語環境が不明な場合は第3引数をきっちり設定し、言語を固定しておいた方が無難だと思います。
区切り
基本的にはコンマがグルーピング（桁区切り）、ピリオドが小数点ですが、言語によってはスペースで区切ったり、小数点がコンマだったりします。これは第3引数で設定した言語のルールが適用されるようです。
第3引数（Result Language Tag）
その名称通り、Text関数の結果を調整するようで、通貨のフォーマットを書いている場合は桁区切りや、小数点、通貨のプレースホルダーを設定した言語のものにしてくれます。
デフォルトはユーザーのアプリを動かしている環境の言語で、これを上書きして固定したい場合に設定します。
表記は en-US のように、言語‐リージョン の形です。
通貨表示はカオス
ここまで読んで頂いた方は気づいたかと思いますが、第2引数と第3引数両方にLanguage Tag が出てきます。
第2引数では Language Placeholder の中に、第3引数ではそのままの形で。
二重に言語指定が出てくるうえに、自動設定があるし、プレースホルダーに至っては空だと勝手に en-US に設定されてしまう。
自身の環境も併せると、あいまいな表記の場合、どの言語がどう設定されているのかがわかりづらく、混乱のもとになっています。
しかも、通貨のプレースホルダーとして使用した＄は第2第3引数を同じ言語に設定した時にはそのまま＄表記のままで、第3引数のみにLanguage Tagを設定した際にのみ正常に働いてくれる謎の挙動を示します。
桁区切りにしても、第3引数が強いようで、Language Placeholder不要なんじゃないの？と思ってしまいます。
恐らく作る機会はそうそうないかもですが、グローバルなアプリを作る際にはLanguage Placeholderなしで、Text関数の外に通貨記号を直書きするのが良いのでは？と思います。
以下は見にくいですが、桁区切りがスペースで、通貨記号も特殊なノルウェーのクローナと、英ポンドを例に色々やってみた結果です。
↓↓またもやクリック拡大お願いします。
それぞれの通貨で検証する必要はあると思いますが、
日本円だと、通貨のプレースホルダー＄が利用できるので、
Text(10000000,"$#,###","ja-JP") ➡ ¥10,000,000
のような書き方できれいに表示でき、
ノルウェーのクローナの場合は桁区切りをスペースにしようとした場合第2第3引数双方にLanguage Tagを入れねばならず、その際＄が機能しないので、以下のようにText関数の外側に通貨記号をStringとしてつけてやるような形で表記する必要があります。
Text(10000000,"[$-nb-NO]# ###","nb-NO")&"kr" ➡ 10 000 000kr
ややこしいですね！
おまけ
Text関数のDocsのグローバルアプリの項目で出てくる、フランス語の場合の構文のセミコロンの意味が分からなかったけど、色々調べているうちに発見。 いくつかの言語では小数点の表記がコンマなので、その場合、数式のセパレータがセミコロンになるらしい…。
以下参照。こちらもややこしい！
