ポイントが何に使われたかを調べる

残高がおかしい、と言われたときに決着をつける場所がポイント使用履歴です。ポイントが動いたすべての要請と払い戻しが、いつ動いたのか、どの予約が原因なのか、誰の残高から出たのかとともに記録されています。

これは元帳であって残高照会ではありません。何がなぜ動いたかは分かりますが、誰にいくら残っているかは分かりません。

1. ポイント使用履歴を開く

予約モジュールのログの下、予約ログの隣にありますが、ピン留めされた項目ではないため、まずもっと見せるを選びます。

開くと、日付の絞り込みなしで全社分が最新順に並びます。この最初の画面は記録されたすべての要請と払い戻しです。眺める場所ではなく、一件を調べる場所だと考えてください。

2. 聞かれた質問に合わせて絞り込む

検索ボックスはありません。絞り込みは列見出しの中にあります。絞り込める4つの見出しにはじょうごが表示され、見出しそのものが操作部になっています。

絞り込みは組み合わせられます。何も見つからない絞り込みは、壊れたように見せるのではなく絞り込みを解除するよう促します。

3. 1行を読む

数量はその行の正味の増減です。 要請はそのまま 10 Room hours と表示され、払い戻しには先頭にプラスが付いて +10 Room hours となります。2つの異なるユニットを使う予約はそれぞれ1行ずつ持ちます。2つは互いに支払いのできない別々の予算だからです。

並べ替えられるのは時間と実行ユーザーだけです。他の3つは行の中身から組み立てられるため、並べ替えの対象がありません。

4. 明細を開いて実際に動いたものを見る

行をクリックすると、右の画面がそれを取引に分解します。1行が常に1つの動きとは限らないからです。

各取引にはリソース、残高が引かれた人、そして金額が並び、ポイント要請または払い戻しと示されます。ここでしか見えないことが2つあります。

• 予約の変更は1つではなく2つの動きです。 元の費用が払い戻され、新しい費用が要請されます。1時間から2時間に延長した会議は10の払い戻しと20の要請として現れ、数量の列はその正味の10を報告します。自分の残高を見ている人には差額しか見えないため、明細を開くまで計算が合わないように見えます。
• 要請された人は、実行ユーザーの列の人とは限りません。 管理者が同僚の代理で予約した場合、誰のポイントが支払ったのかを述べるのはこの明細だけです。

画面上部の予約は予約そのものを開きます。「この要請はおかしい」からその原因となった会議へ至る最短の経路です。

5. ダウンロードする

見出しのダウンロードは日付の範囲を尋ねます。今月、または時間の絞り込みが既に設定されていればその範囲で開き、その範囲をスプレッドシートとして渡します。

数行だけを取り出すには、それらを選んで選択項目をエクスポートを使います。こちらは予約単位で動くため、選んだ明細はその予約の履歴の残りも連れてきます。要請と払い戻しが片方だけでなく揃って届きます。

6. 正しい答えが得られたか確かめる

受けた申し立てを最初から最後まで再現します。その人で絞り込み、時間をその人が尋ねている期間に設定し、数量の列を合計します。要請から払い戻しを引いたものが、その期間にその人の残高から出た量です。

その合計が失われたと言われている量と一致すれば、元帳と申し立ては一致しており答えは行の中にあります。一致しない場合、その差はほぼ必ず次の4つのいずれかです。いずれもここには記録されません。

ポイント使用履歴に出ないもの

• 誰かの残りの残高。 管理コンソールのどこにも、その人にいくら残っているかを報告する画面はありません。現れるのは、実際にその人の代理で予約している最中の予約フォームの料金パネルだけです。
• 期間のリセット。 期間が切り替わって変わった残高は行を残しません。記録されるのは予約・変更・キャンセルだけなので、残高がひとりでに動いた最も多い理由であるにもかかわらず、ここには見えません。
• 拒否された予約。 ポイント不足で止められた人は要請されていないため、何も書かれません。試みた記録は残りません。
• 料金の設定されていないリソース。 ポイントポリシーのないリソースは費用がかからず、どれだけ予約されても現れません。

何も戻らなかったキャンセルについてもう一言。それはリソース自身のポリシーが払い戻しを許可していないか、払い戻し期限を過ぎてキャンセルされたかのどちらかです。どちらもリソースポイントポリシーの設定であって記録の不具合ではありません。設定リファレンスが扱っています。