PPPark

PPPark料金自動計算の導入と管理画面設定ガイド

ⓘ本ページはプロモーションが含まれています

Contents

スポンサードリンク

クイックスタート（管理者向け一枚サマリ）

このセクションは時間のない管理者向けの要約です。導入初日に行う最低限の操作と検証を短く列挙します。

  • 管理者権限の確認：料金設定・公開ができるアカウントを用意します。
  • 設定の下書きとバックアップ：既存設定をエクスポート／記録し、ステージング環境で下書きを作成します。
  • 基本設定（新規料金プラン作成）：
  • メニュー例：設定 > 料金 > 新規料金プラン
  • 必須項目：プラン名、適用駐車場（ロット）、適用期間、タイムゾーン、ステータス（下書き/公開）
  • 主要パラメータ設定：単位時間、端数処理、初期ブロック、段階料金、日別/24時間上限、割引ルールを設定します。
  • 検算：Excel/Sheetsで代表ケース（境界含む）を作成し、管理画面の「プレビュー」や「シミュレーション」機能で突合します。
  • 決済テスト：必ずサンドボックスで決済（成功・失敗・返金）を検証し、Webhook 署名検証を行います。
  • 公開：下書き→公開（公開日時設定がある場合は指定）。公開後はログと売上突合を行います。

公式ドキュメントの参照先は1回だけ確認して運用に従ってください（リンク集は下部参照）。

概要と導入前チェックリスト

導入の全体像と、事前にそろえておくべき項目を一覧化します。設定漏れが誤請求や連携不具合の原因になりますので、必ずチェックしてください。

機能の範囲と想定用途

ここではPPParkで一般的に自動化される処理範囲を示します。導入可否判断の材料にしてください。

  • 入出庫データを元にした経過時間の自動算出と料金計算
  • 単位課金（例：15分/30分）、初期ブロック、段階式（区間ごとの課金）
  • 最大料金（カレンダー日単位／スライディング24時間）、夜間固定料金、時間帯適用
  • 割引・クーポン・会員（月極）パスの併用ルール
  • 精算端末・決済APIとの連携、領収書・明細表示の反映

上記は代表例です。画面項目や挙動はバージョンで変わるため、導入前に必ず公式ドキュメントを照合してください。

導入前の必須確認事項

導入前に必ず確認・準備しておく項目です。抜けがあると誤請求や連携不具合の原因になります。

  • アカウント権限：料金設定・公開が可能な管理者アカウントの有無。操作ログのアクセス権も確認。
  • タイムゾーン／サーバ時刻：システム時刻（UTC推奨）と現地タイムゾーンの紐付けを確認。夏時間（DST）対応も確認。
  • 税設定：税込／税抜表示、税率、端数処理（四捨五入/切上げ/切捨て）の規則を会計と一致させる。
  • ハード連携：入出庫センサー、ゲート、精算機の接続・ログ出力形式・タイムスタンプ精度を事前確認。
  • 決済連携：決済プロバイダのテスト環境、Webhook 受信、署名検証手順の確認。
  • 既存料金のマッピング：現行の料金体系をテンプレート化して移行手順を定義する。
  • ログ／バックアップ：設定変更の履歴保管とロールバック手順を整備。変更時は差分エクスポートを保存。
  • 法務・会計チェック：領収書フォーマット、税表示、地方条例（表示義務など）への適合性を確認。

公式ドキュメント・参照先（必ず1つは確認）

実務では公式ドキュメントの該当ページを必ず参照してください。以下は確認すべきドキュメント名と想定URL例です。実際のURLは製品のポータルで確認してください。

管理画面関連（料金設定・時間帯）

管理画面のヘルプ内「料金設定」「時間帯（Time Bands）」「プラン管理」ページを確認します。例：

  • 管理画面マニュアル - 料金設定: https://docs.pppark.example/admin/rates

API・決済・Webhook

決済連携やWebhookの署名検証は必須確認項目です。例：

  • API リファレンス - Webhook: https://docs.pppark.example/api/webhooks
  • 決済連携（サンドボックス）: https://docs.pppark.example/integrations/payments

リリースノート・互換性

バージョン差分で挙動が変わるため、リリースノート（変更履歴）を必ず確認します。

  • リリースノート: https://docs.pppark.example/release-notes

（注）上記URLは例示です。管理画面の「ヘルプ」「ドキュメント」リンクやサポート窓口で最新版を確認してください。

管理画面でのステップバイステップ設定手順

ここでは代表的な管理画面操作の流れと、ボタン名や画面遷移の例を示します。製品のバージョンにより表記は異なるので、操作時は画面上のヘルプを参照してください。

料金プランの作成と時間帯設定

新規プラン作成から時間帯を定義する流れを示します。必須項目や操作ボタン名の例も含めています。

  1. 管理画面で「設定」→「料金」→「新規料金プラン」を選択する。
  2. 必須入力：プラン名、適用駐車場（ロット選択）、適用開始/終了日、タイムゾーン、ステータス（下書き/公開）
  3. 「時間帯を追加」ボタンで帯を作成する。
  4. 帯の入力項目：開始時刻、終了時刻、適用曜日、祝日扱い（適用/除外）
  5. 日跨ぎ帯（例 22:00–08:00）は「開始時刻 > 終了時刻」を明示的に選ぶか、日付範囲のロジックを指定する。
  6. 重複帯の優先順位を設定する（例：明示的な優先度順／高額優先）。
  7. ボタン例：「優先度設定」「編集」「削除」
  8. 「プレビュー」または「シミュレーション」機能で代表入出庫時刻を入力して結果を確認する。

単位時間・端数処理・上限設定→保存・公開

課金ロジックの要所と公開時の注意点を示します。

  1. 単位時間と単価を設定する。
  2. フィールド例：課金単位（分）、単価（円）
  3. 初期ブロック（最初のX分を定額）を必要に応じて設定する。
  4. 端数処理を選択する（切上げ/切捨て/四捨五入）。フィールド例：「端数処理」ドロップダウン。
  5. 最低料金・最大料金を設定する。
  6. スコープ指定：日別（カレンダー日）／スライディング24時間／滞在ごと（entry-based）を明示する。
  7. 割引・クーポン・月極フラグの設定を行う。
  8. クーポン例：％割引、金額割引、利用回数制限、併用可否フラグ。
  9. プレビューで複数代表ケースを検算する。
  10. 「下書き保存」→承認フロー→「公開（公開日時設定）」で本番反映する。公開後は「変更履歴」「監査ログ」を確認する。

注意：公開前に代表的な境界時刻（時間帯開始直前/直後、日跨ぎ、DST切替日）で必ず検証してください。

計算ロジックの明示と検算例

料金計算の基本フロー、日跨ぎの扱い、スライディング24時間とカレンダー日単位の定義を明確にします。実際のシステム挙動は公式仕様に従いますが、ここで比較と検算方法を示します。

端数処理・優先順位・日跨ぎの扱い

ここでは「単位化」「段階式」「最大料金スコープ」の取り扱い方を整理します。

  • 経過分（分） = 出庫時刻 − 入庫時刻（分、UTCベースで計算し表示のみローカル化するのが安全）
  • 単位数の算出（unit_minutes は課金単位）
  • 切上げ（例）: 単位数 = CEILING(経過分 / unit_minutes)
  • 切捨て: 単位数 = FLOOR(経過分 / unit_minutes)
  • 四捨五入: 単位数 = ROUND(経過分 / unit_minutes)
  • 初期ブロックがある場合は先に初期ブロックを満たすか否かで分岐する。
  • 段階式は各区間ごとに超過分を算出して合算する（最初のX分は定額、次はY分ごとにZ円など）。
  • 最大料金のスコープは「カレンダー日単位」か「スライディング24時間」かで結果が変わる（下節で定義）。

実装上の注意点：端数処理を「どの単位で切上げするか（全滞在に対してか、日単位に分割して行うか）」は運用ルールとして明確に定義し、検算テンプレートと揃えることが重要です。

「カレンダー日単位」と「スライディング24時間」の定義とアルゴリズム

ここでは両者の定義を明確化し、実装アルゴリズム例と境界ケースを示します。

  • カレンダー日単位（midnight-to-midnight）
  • 定義：各カレンダー日（現地のローカル日付）ごとに滞在を分割し、各日の合計に日別上限を適用する方法です。
  • アルゴリズム（擬似）：
    1. entry_local = 入庫時刻 をローカルタイムで求める。exit_local = 出庫時刻 をローカルで求める。
    2. 各ローカル日 D に対して、その日内の滞在分（minutes_D）を算出する。
    3. day_charge_D = calc_charge(minutes_D, 時間帯分割等)
    4. day_charge_D = min(day_charge_D, daily_cap) // 日別上限適用
    5. 合計 = sum(day_charge_D)
  • 境界例：入庫 23:30、出庫 翌02:30 の場合、23:30–24:00（30分）と00:00–02:30（150分）に分割して日別計算を行います。
  • スライディング24時間（entry-based rolling 24h）
  • 定義（通常実装パターン）：入庫時刻を基準に24時間単位で完全なブロック数分上限を適用し、残り時間は通常計算する方法。
  • アルゴリズム（推奨シンプル実装）：
    1. total_minutes = exit_utc - entry_utc（分）
    2. full_blocks = INT(total_minutes / 1440)
    3. remainder = total_minutes - full_blocks * 1440
    4. total = full_blocks * cap + min(cap, calc_charge_for_period(entry + full_blocks24h, entry + full_blocks24h + remainder))
  • 注意点：一部システムでは任意の24時間のスライドウィンドウでキャップの最適適用（最も有利なウィンドウを探す）を行う場合があるため、実装前に仕様を確認してください。上記は最も一般的で計算コストが低いブロック分割方式です。
  • 境界例：入庫 09:00 day1、出庫 11:00 day2（26時間）の場合、full_blocks=1、remainder=120分 → 合計 = 1×cap + remainder分の通常計算。

選択基準：顧客の利便性と表示義務、地方条例に基づき、どちらを採用するか決めます。どちらを採る場合でも代表ケースで検算して挙動をドキュメント化してください。

割引と最大料金の適用順序（適用パターン比較）

割引（％/金額）と上限の適用順により請求金額が変わります。以下で代表的な2パターンを示します。

  • パターンA（割引→上限）
  • 流れ：基本料金を計算 → 割引を適用（上限がある場合は割引上限を考慮）→ 上限（カレンダー/24h）を適用（合計が上限を超える場合に上限を最終料金とする）
  • 数値例：基本 3,000円、割引20%上限500円、上限1,200円
    • 割引 = min(3,000 × 0.2, 500) = 500 → 割引後 = 2,500 → 上限適用後 = min(2,500, 1,200) = 1,200円
  • パターンB（上限→割引）
  • 流れ：基本料金を計算 → 上限を適用 → その後で割引を適用（割引上限は上限後の金額に対して適用するか明示する）
  • 同例：基本 3,000 → 上限1,200適用 → 割引 = min(1,200 × 0.2, 500) = 240 → 最終 = 960円

運用上の注意：上記でわかるように適用順により顧客負担が大きく変わります。業務方針（顧客還元優先／収益優先）に基づいて順序を決め、設定画面での「割引適用前/後」フラグを確認してください。仕様が曖昧な場合、必ず代表ケースで結果を確認し、顧客向け表示（領収書）で適用順序を説明できるようにします。

Excel/Google Sheetsでの検算テンプレートと実装式（具体例）

検算テンプレートは管理画面の計算と突合するための必須ツールです。ここでは具体セル参照例と、日跨ぎ・複数帯・段階式・スライディング24hの実装方針を示します。シート上部に設定セルを置く設計を推奨します。

基本列と設定セルの例

下段のA列〜J列を1行分の計算と仮定した例です。シート上部に設定セル（$X$1 形式）を置きます。

カラム 説明
A 入庫日時 datetime（例: 2026/05/01 09:00）
B 出庫日時 datetime
C 経過分（分） =(B2-A2)2460
D 単位数 =CEILING(C2/$F$1,1) （$F$1 に unit_minutes）
E 単価 単価（セル参照）
F 基本料金 =D2*E2
G 初期/最小適用 =IF(C2<=$G$1, $G$2, F2) （$G$1=初期ブロック分、$G$2=初期料金）
H 割引額 =MIN(G2*$H$1, $H$2) （$H$1=割引率、$H$2=割引上限）
I 上限適用 =MIN(G2-H2, $I$1) （$I$1=最大料金）
J 最終料金 =I2 または =G2-H2（ロジックに応じて）

（表の前後に空行を入れています。）

日跨ぎ・時間帯分割・段階式の具体式（サンプル）

ここでは日跨ぎ帯の分割や段階式を扱うための実用的アプローチを示します。複雑な場合はヘルパー行を作り、日ごとに分割して合算する方式が現実的です。

  • 総分（分）: C2 = (B2 - A2) * 24 * 60
  • 初期ブロック + その後の加算（例）:
  • 設定セル：初期分 $G$1（分）、初期料金 $G$2、追加単位 $G$3（分）、追加単価 $G$4（円）
  • 式（行内一式）:
    =IF(C2<=$G$1, $G$2, $G$2 + CEILING( (C2-$G$1) / $G$3, 1 ) * $G$4 )
  • スライディング24時間方式（ブロック分割モデル）:
  • total_min = C2
  • full_blocks = INT(total_min / 1440) （$K$1 = 1440）
  • remainder = MOD(total_min, 1440)
  • fee_full = full_blocks * $I$1 （$I$1 = cap）
  • remainder_fee = 上の初期/段階計算ロジックで「remainder」分を算出（補助列で算出推奨）
  • 合計 = fee_full + MIN(remainder_fee, $I$1)
  • 時間帯ごとに分割（複数日の場合は日数分ループする前提）:
  • dayCount = INT(B2) - INT(A2) + 1
  • 各日 d（0〜dayCount-1）について:
    • dayStart = INT(A2) + d
    • bandStart = dayStart + TIMEVALUE("08:00")
    • bandEnd = dayStart + TIMEVALUE("22:00") // 日跨ぎ帯は +1
    • overlap_min_d = MAX(0, (MIN(B2, bandEnd) - MAX(A2, bandStart)) * 24 * 60)
  • 各日分を合算して帯ごとに単価を適用

Excel の1セルで完全自動化するのは可読性が低くなるため、日ごと・帯ごとのヘルパー列を作って合算する方式を推奨します。

割引→上限、上限→割引の具体式（セル参照例）

  • 割引→上限（G2が基本料金、割引率$H$1、割引上限$H$2、最大料金$I$1）:
  • 割引額: =MIN(G2*$H$1, $H$2)
  • 割引後: =G2 - (上記)
  • 最終: =MIN(割引後, $I$1)
  • 上限→割引:
  • 上限適用: =MIN(G2, $I$1)
  • 割引額: =MIN(上限適用*$H$1, $H$2)
  • 最終: =上限適用 - 割引額

シート上で「適用順序」を切り替えるフラグを設け、どちらの式を使うか選べるようにしておくと検証が容易です。

DST（夏時間）とタイムゾーン変更時の具体処理例と検証手順

タイムゾーン関連のバグは誤請求に直結します。基本方針は「タイムスタンプはUTCで保存」「ローカル表示とカレンダー分割はタイムゾーンIDで行う」です。ここでは代表的なケースと検証手順を示します。

基本方針（UTC保存・ローカル表示）

  • 入力・保存：入退場イベントは必ず UTC タイムスタンプ（ISO 8601）で保存する。
  • 表示・カレンダー分割：画面表示や「日別上限」計算などローカル日付が必要な箇所では、保存した UTC を該当駐車場の IANA タイムゾーン（例: America/Los_Angeles, Europe/Berlin, Asia/Tokyo）でローカル変換して処理する。
  • ライブラリ：サーバ/クライアントともにタイムゾーン対応のライブラリを使用する（例：Java java.time.ZoneId、Python zoneinfo/dateutil、JS なら Luxon / Intl API）。

代表的ケース別の処理例

  • 日本（JST、DSTなし）
  • 実装は比較的単純。ローカル日付は UTC→Asia/Tokyo 変換で一意に定義されます。検証は通常の境界時刻で実行。
  • 米国太平洋時間（PST/PDT、DST がある場合） — 春の前倒し（spring forward）例:
  • DST開始日（例：03月の第2日曜）に 02:00→03:00 に飛ぶため、「存在しない」ローカル時刻が発生します。イベントはUTCで記録されているため経過時間は正しく算出できるが、ローカル日付での分割処理では非存在時刻の扱い（エラーにするか近接時刻で処理するか）を仕様に明示する。
  • DST 終了（fall back）で時間が重複する例:
  • 01:30 が 2 回発生するため、ローカル時刻だけだとどちらの 01:30 か不明。解決策は保存時に UTC とオフセット（例：-07:00 か -08:00）を一緒に記録すること。ライブラリの「fold」フラグや offset 情報を利用する。

テスト・検証手順と受入基準（実務的基準）

検証は網羅的かつ再現性を持たせて行います。以下は案件で使える代表的テスト項目と現実的な合格基準の例です。

テストケース選定基準と必須ケース

代表ケースはカテゴリ毎に抽出し、境界・組合せを優先して検証します。

  • 境界系：単位未満（例：10分）、単位ちょうど（15分）、時間帯の開始直前/直後（例：07:59/08:00）
  • 中時間・長時間：数時間、24時間を超える滞在（例：26時間）
  • 日跨ぎ：23:00→07:00 等の夜間跨ぎ
  • DST／タイムゾーン切替：前節参照のケース
  • 割引・上限・併用：割引単独、割引＋上限（各適用順）、月極併用、クーポン上限超過
  • 外部連携：精算機ログ、決済（成功/失敗/返金）、Webhook 受信/署名エラー
  • 障害シナリオ：センサーイベント欠落、重複イベント、ネットワーク断での手動精算

検証合格基準（実務例）

合格基準は重要度により段階化します。例：

  • 重大（誤請求に直結するケース：端数・日別上限・DST）
  • 合格ライン：100%一致（検証ケース中の全件）
  • 高（顧客クレームに直結しやすい：割引併用、時間帯分割）
  • 合格ライン：99%（重大な差異はゼロ）
  • 標準（稼働後のマイナー差異許容範囲）
  • 合格ライン：95% 以上

サンプルサイズと抽出法：各カテゴリから代表ケースを抽出し、合計で50〜200件のうち「重大」カテゴリは全数網羅、他は層化抽出でカバーします。合格判定は自動テストスクリプトで期待値と実結果を突合し、差分ログを保存してください。

注意：上記は運用目安です。最終基準は事業リスク許容度と会計要件に合わせて決定してください。

外部連携・決済・セキュリティ／プライバシー

外部連携（Webhook、決済、精算機）とログ管理は、運用と法令順守の要です。ここでは必須の技術要件と運用上の注意点を示します。

Webhook と API のセキュリティ

  • TLS 必須：Webhook/ API は TLS 1.2+ を使用する。
  • 署名検証：HMAC-SHA256 等で署名を行い、ヘッダ（例：X-PPPark-Signature）で送る。受信側で共有シークレットにより検証する。
  • 推奨ヘッダ例（仕様に合わせて）: X-PPPark-Timestamp, X-PPPark-Signature
  • リプレイ対策：タイムスタンプ付与と一定時間（例：5分）より古い通知は拒否する。
  • 冪等性：同一イベントに idempotency_key を付与し重複処理を避ける。

簡易的な署名検証（疑似コード）：

  • 署名受領: sig = request.header['X-PPPark-Signature']
  • 生成: expected = HMAC_SHA256(secret, timestamp + '.' + body)
  • 比較: secure_compare(expected, sig)

決済・カードデータの扱い

  • PAN（カード番号）はシステム側で保持しない（トークン化を利用）。
  • PCI-DSS 準拠を確認し、必要に応じて決済事業者と契約する。
  • Webhook に含まれる顧客情報は最小限にし、個人情報は暗号化保存（AES-256）する。
  • 返金フローや調整は決済ログと管理画面ログで 1 トランザクション単位で辿れるようにする。

ログ管理と暗号化

  • 監査ログ（料金変更、公開操作、管理者アカウントの操作）は少なくとも 1 年保管を推奨（法令・会計要件に合わせる）。
  • 保存時は暗号化（KMS ベース）を利用し、アクセス制御を厳格化する。
  • ログは改ざん検知（ハッシュチェーンや署名）を導入すると監査に有利です。

法務・会計面の実務例（領収書・税表示・地方条例）

請求表示・領収書は会計監査や顧客クレーム対応で重要です。ここでは表示例と注意点を示します。

領収書フォーマットと税表示例

  • 表示必須項目例：発行者（事業者名）、駐車場名、利用日時（入庫/出庫）、経過時間、基本料金、割引、税額、合計、取引ID。
  • 税抜表示の例：
  • 利用料金（税抜）: ¥1,000
  • 消費税（10%）: ¥100
  • 合計（請求額）: ¥1,100
  • 税込表示の例（内税明示）：
  • 利用料金（税込）: ¥1,100（税抜 ¥1,000、税 ¥100）
  • 小数・端数処理：税の端数処理（円未満の処理）は会計方針に合わせる。日本では最終金額を円で表示するのが通常。

地方条例への適合方法（運用手順）

  • 地方条例で「料金掲示」「営業時間」「最大料金表示」が義務の場合、料金表に下記を掲示することが多い：単位時間、単価、端数処理、日別上限、適用時間帯、表示例。
  • 手順：条例の該当ページを確認 → 料金表示テンプレを作成 → 管理者と法務で確認 → 現地掲示とWeb告知を実施。
  • 重大な点は顧客に誤認を与えない表示（例：「24時間最大」か「カレンダー日最大」かを明記）を必ず行うこと。

移行・運用・トラブル対応（FAQ風の要点整理）

運用で優先すべき手順と典型トラブルの初動対応をまとめます。ログ取得と早期再現が最優先です。

移行時の実務注意点とベストプラクティス

  • 既存料金の棚卸し：全ルールを一覧化し、テンプレートへマッピング。差分は変更管理表に記録。
  • 段階的導入：まずは1〜2拠点でパイロット運用。問題がなければロールアウト。
  • 顧客告知：看板・Web・会員通知で期日と変更点を明示。誤解を招かない文言を法務と確認。
  • ロールバック：公開前に設定エクスポートを保存し、公開後に即時ロールバックする手順を用意。
  • 監視・アラート：公開後7日間は売上差分や平均単価の急変をアラート化。

トラブルシューティング（優先対応例）

  • 計算結果が期待と異なる
  • 初動：代表ケースで再現 → 管理画面の「計算ログ」取得 → 端数設定／時間帯設定／タイムゾーンを確認 → ステージングで修正確認。
  • 割引が適用されない
  • 初動：クーポン有効期限、利用回数上限、併用設定、適用条件（車種/会員）を確認。
  • 最大料金が効かない
  • 初動：上限の「スコープ」（カレンダー/24h）が意図通りか確認 → 境界ケースで手計算と比較。
  • 精算機イベント欠落／重複
  • 初動：デバイスログ取得 → 再送試行・ID照合 → 手動精算での差分処理フローを適用。
  • 決済/Webhookの不整合
  • 初動：決済ログとWebhookログを照合 → 署名・タイムアウト・再試行設定を確認 → 決済事業者へエスカレーション。

FAQ（短答例）

  • 設定が反映されない場合は？
  • 「下書き保存」のままになっていないか、適用対象駐車場が正しいか、公開日時が設定されていないかを確認してください。
  • 割引と上限の順序はどちらが良い？
  • ビジネス方針に依存します。割引→上限は事業者に有利（顧客負担軽減は少なくなる）で、上限→割引は顧客優遇になるため、代表ケースで影響を試算してください。
  • 検算テンプレはどこで入手？
  • 本文のExcel/Sheets構成を基に作成してください。運用環境に合わせて設定セルを用意します。

まとめ

導入前に抑えるべき要点を短く整理します。実運用では代表ケースの検算と公式ドキュメント照合を優先してください。

  • 設定は「下書き→検算→公開」の流れで実施し、公開前に必ず代表ケースで突合する。
  • 上限のスコープ（カレンダー日／スライディング24h）と割引の適用順序は運用方針で明確にし、ログと領収書で説明できるようにする。
  • DST／タイムゾーンは UTC保存＋ローカル表示で扱い、DST の存在する地域は境界ケースを必ず検証する。
  • Webhook/決済は署名検証・TLS・トークン化を実装し、ログは暗号化して保管する。
  • サンプル値は例示に過ぎません。金額や閾値は必ず自施設の収益モデルと法務会計と照合して調整してください。

（参考）公式ドキュメントの確認場所：管理画面の「ヘルプ／ドキュメント」、API リファレンス（Webhook・決済）、リリースノート。運用前にこれらを1回以上確認し、疑義は公式サポートへ問い合わせてください。

スポンサードリンク

-PPPark