単発の販売を会計処理する前に、なぜPOSで商品を作成する必要があるのか？

お使いのPOSが商品カタログを唯一の信頼できる情報源（シングルソース・オブ・トゥルース）として扱っているためであり、単発の販売はそのようなモデルに考慮されていないからです。レシートの各行は商品レコードに紐付ける必要があり、多くのシステムにはオープンアイテム機能（レジ担当者が名称と金額を入力して先に進める明細タイプ）が用意されていません。商品として未登録のものを顧客から渡された場合、レジには対応するボタンが存在しないのです。

そのため、レジ担当者は通常、次の2つの方法のいずれかでその場しのぎの対応をします。列が伸びる中で会計中に使い捨ての商品を作成するか、最も近い実在の商品で会計処理して誰にも見咎められないことを祈るかです。どちらの方法も、帳簿に誤ったデータを残すことになります。

なぜすべての販売をカタログレコードに紐付ける必要があるのか？

カタログ優先のPOSでは、商品レコードがすべての役割を担っているためです。価格、税ルール、在庫の紐付け、レポートカテゴリを保持しているため、チェックアウトはデータ入力ではなく検索処理になります。この設計は小売取引の圧倒的多数に適しており、バーコードスキャンが瞬時に完了するのもこのためです。

問題が発生するのは例外的なケースです。修理費用、特別注文、配送代金、今朝ベンダーから持ち込まれたイレギュラーな委託商品などです。昔の電子レジスタ（ECR）は、これをオープン部門キー（入力された金額を受け取り、特定のカテゴリに分類するボタン）で処理していました。多くの現代的なクラウドPOSシステムは、カタログ優先の設計に移行した際にこの機能をひっそりと削除し、二度と再構築しませんでした。

オープンアイテムボタンがない場合、スタッフは実際にどう対応しているのか？

スタッフは回避策を講じますが、その回避策は機能の不足以上のコストをもたらします。

• 会計中に作成される使い捨て商品。レジ担当者は取引を中断し、カタログエディタを開いて、その日の価格で「その他商品」を作成します。これを1か月続けると、カタログは不要なレコードで溢れ返り、検索、エクスポート、レポートを汚染します。

• ダミー商品のグリッド。一部のシステムでは、「カスタム販売1」「カスタム販売2」といった名前の商品を作成し、価格帯ごとにバリエーション（1.00ドル、2.00ドルなど）を用意するよう加盟店に促します。レジ担当者は実際の金額に最も近いバリエーションを選択します。これはテンキーのふりをしたカタログであり、売上は存在するバリエーションの金額に端数処理されてしまいます。

• 最も近い実在の商品で会計処理する。レジでの処理は最速ですが、帳簿上は最悪です。代用されたSKU（在庫保持単位、商品レコード）は販売していない在庫を失い、架空の需要に基づいて再発注アラートが作動し、売上レポートには誤った商品が計上されます。

• 数量の裏ワザ。1ドルの商品を数量37で会計処理すると、37ドルの明細と何の意味もない販売数量が生成されます。

これらはその場では気づきにくいものの、レポート作成時に大きな代償を払うことになります。これは応急処置だらけのPOSと同じ失敗パターンです。回避策が定着してシステムそのものになり、レポートは店舗の実態を反映しなくなります。

修正するまでの間、どの回避策が耐えられるか？

現在のPOSで対応できず、今すぐ移行できない場合は、被害を最小限に抑えましょう。

1. 税処理ごとに1つの雑商品を本部で一括作成し、レジでの価格上書き（オーバーライド）を有効にします。「雑商品（課税）」「雑商品（非課税）」など明確な名前を付け、少なくとも明細の税金が正しくなるようにします。

2. レジでのカタログ編集をロックします。回避用の商品はマネージャーが一度だけ作成すべきであり、シフトに入っているスタッフが会計途中で作成してはなりません。

3. 雑商品の明細を毎週確認します。雑売上が売上のごく一部を超えている場合、毎晩のCSVエクスポートが月末までズレを隠してしまうのと同様に、何が実際に売れているのか把握できなくなっています。

これは応急処置です。合計金額と税金の整合性は保たれますが、単発の販売はすべて区別のつかない1つの分類にまとめられ、代用されたSKUによる在庫の歪みが解消されるわけではありません。

チェックアウト時の単発販売はあるべき姿とは？

カタログの不自然な裏ワザではなく、正式な明細タイプであるべきです。レジ担当者は名前と金額を入力し、課税対象かどうかおよび税グループを選択して、明細をカートに追加します。支払時には他の商品と同様に機能し、レシートには入力した名前が印字され、レポートには独立した明細として表示され、在庫には一切影響を与えません。従来のレジスタは何十年も前にこれを実現していました。現代のPOSにできない技術的な理由はありません。

Finalはこれをカスタム販売として提供しています。販売画面のカタログの横にあるタブで、テンキーで名前と金額を入力し、必要に応じて税グループを選択し、他の明細と同様にカートに追加できます。これは本日より利用可能であり、詳細な手順はヘルプセンターのカスタム販売の作成方法に掲載されています。免税販売から分割決済まで、柔軟なシステムが吸収すべきその他のチェックアウト時の例外ケースにも同じ原則が適用されます。明細レベルおよび決済レベルの決定は、カタログの修正作業ではなく、レジカウンターで行うべきものです。

1つの注意点として、オープンアイテムは本当の意味での単発販売のための機能です。毎週同じ「単発商品」を会計しているなら、それは商品レコードを作成すべきです。違いは、行列の視線を浴びながら会計途中で慌てて追加するのではなく、意図的なカタログ登録として処理できる点にあります。

では、なぜお使いのPOSは最初に商品を作成させるのか？

それは、カタログが完全であるという前提で設計されているためであり、レジカウンターではその前提が週に何度も崩れるからです。解決策は、スタッフの規律を強化することや、ダミー商品のグリッドを整理することではありません。入力された名称、金額、税金の選択を受け入れるオープンアイテムの明細タイプを用意することです。経験則として、単発の請求にその金額を入力する以上の時間がかかる場合、お使いのPOSに必要なのは回避策ではなく明細タイプです。先月レポートに記録された「その他」の明細数を数えてみてください。その数値に驚いたなら、ついでに他の回避策の監査も行ってみましょう。