判断
承認は会場が行う
会場が「販売可能」と登録した枠にだけ申請が届きます。承認・条件提案・お断りは会場が選び、自動では確定しません。カレンダーの空白は販売可能として扱いません。
全組が会場・日程・実費・取消条件に合意した申請だけが届きます。会場は空きを再確認し、承認・条件提案・お断りを選びます。支払いの記録も同じ画面で整理します。
判断
会場が「販売可能」と登録した枠にだけ申請が届きます。承認・条件提案・お断りは会場が選び、自動では確定しません。カレンダーの空白は販売可能として扱いません。
準備
日程は1枠ずつ手で登録し、前の週から複製できます。外部カレンダーとの連携は任意の候補で、接続しても販売の許可は会場が確認します。
記録
バンドからの支払申告、会場の受領確認、銀行への着金確認を別の状態として扱います。申告だけで入金済みにはしません。
申請を受け取る前に、会場側で登録しておく内容です。手入力と複製で始められます。
予約を提供する権限のある担当者を登録します。確認の方法は検討中です。
販売できる日と時間を手入力し、必要なら前週から複製します。
外部カレンダー連携は任意総額、追加費、支払・取消条件を登録します。条件が不明な枠は「予算内」と扱いません。
最低保証、還元の開始、率か定額、対象売上と控除、受領者を分けて登録します。
振込先などの受取情報と受領確認の担当を登録します。初期は外部で受け取る想定です。
届くのは、全組が会場・日程・実費・取消条件に合意した申請です。会場は次の順で確認し、回答します。
承認の効力は、この申請の会場・日程・条件に限ります。承認がそのまま契約になるかどうかは、会場の契約条件によります。
価格や時間、追加費などの変更を提案します。相手側の全組が再合意するまで確定しません。
この申請に対してお断りを返答します。その日程の空き状況は、会場が必要に応じて更新します。
会場実費の支払いは、初期はアプリの外で行う想定です。アプリは3つの状態を分けて記録し、開催後の精算に使います。
01 支払申告
バンド側の入力です。この時点では入金の確認はできていません。
02 受領確認
会場の担当者が、受け取った内容を確認して記録します。
03 着金確認
振込の場合、口座への着金を確認した状態です。受領確認とは別に扱います。
集金をアプリが仲介する方式、カード決済、決済費の負担者は検討中で、初期には含めていません。外部で受け取る運用でも利用できる設計です。
初期に提供を予定している会場向けの画面です。項目や見た目は開発の中で変わります。
初期にアプリで扱う範囲と、これまでどおり会場が行う範囲を分けて示します。
初期のあとに検討する構想です。提供するかどうか、いつ提供するかは未定です。
出演者の出演情報・音響資料の提出状況と、当日の進行時間、担当の分担を公演ごとに見る構想です。既存のメールや資料との二重管理にならないかを確認する必要があります。