販売の記録方法

販売を記録するとき、何を作成しているのか

Skyline Nexusにおける販売とは、transactionsテーブル内のタイプがsellである1行と、一連の販売明細行、そしてゼロ件以上の入金記録で構成されます。この3つは意図的に分けられています。請求書は顧客に対する請求権です。明細行は棚から出ていったものです。入金は届いたお金です。ERPで販売について多くの人が混乱するのは、この3つを一つの出来事として扱うことが原因です。店頭では、たいてい同じ瞬間に起こるからです。

会計上、これらは同じ出来事ではありません。請求書は収益と売掛金を生みます。明細行は在庫を減らし、売上原価を生みます。入金は売掛金を消し込み、現金を動かします。掛けで販売すれば、入金は数週間後に行われ、その間、売掛金は貸借対照表に計上されたままです。前受金を受け取れば、請求書が存在する前にお金が届きます。システムがこれらすべてをモデル化しているのは、どれも実際の事業で起こることだからです。

したがって、販売を記録するときの実務上の問いは、どのボタンを押すかだけではありません。この3つのうち、今どれを作成していて、どれを意図的にまだ作成していないのか、という問いです。その答えは、ほぼすべて、フォーム上の一つの項目、つまり後述する「ステータス」によって決まります。

同じ伝票への3つの入口

左メニューには「販売」というドロップダウンがあります。その下にはいくつかの項目があり、いずれも同じ種類の伝票を作成します。違いは、フォームのどこまでを表示するか、どれだけ素早く入力できるかだけです。

完成した伝票は、どの入口を使ったかにかかわらず「すべての販売」（/sells）に一覧表示されます。下書きと見積書には専用の一覧、「下書き一覧」（/sells/drafts）と「見積書一覧」（/sells/quotations）があります。これらはまだ実際の請求書ではないので、販売一覧を煩雑にすべきではないからです。POSのレシートも「POS一覧」（/pos）に別途表示されます。

一部の動作を説明するうえで知っておく価値のある実装上の詳細があります。「販売を追加」フォームは、POS画面と同じコントローラーに送信されます。一つの保存処理に対する2つのフロントエンドなのです。そのため、どの画面から始めても税金のルール、在庫のルール、元帳への計上は同一であり、POSのレシートと「販売を追加」の請求書が会計上異なる扱いを受けると期待すべきではありません。

• 「POS」（/pos/create）はタッチ操作を前提としたカウンター用画面です。顧客を1人選び、商品グリッドと支払パネルで数秒のうちに完了します。小売、飲食店、あらゆる店頭販売に適した入口です。
• 「販売を追加」（/sells/create）は完全な請求書フォームです。請求書番号体系、通貨、支払条件、配送、カスタム項目、複数の支払行など、すべての項目が表示されます。B2Bの請求書、配送を伴う販売、支払条件のある取引に適した入口です。
• 「直接販売」（/sells/direct/create）は、単純な請求書向けに「販売を追加」を簡略化したものです。
• 「下書きを追加」（/sells/create?status=draft）と「見積書を追加」（/sells/create?status=quotation）も同じフォームで、ステータスがあらかじめ設定された状態で開くため、誤って確定してしまうことがありません。
• 「販売注文を追加」（/sells/create?sale_type=sales_order）は、後で請求する顧客の注文を記録します。POS設定で販売注文が有効になっている場合にのみ表示されます。

「販売を追加」画面の入力

最初のカードは「販売詳細」です。「拠点を選択」は必須で、見た目だけの項目ではありません。販売がどの在庫を引き当てるか、どの請求書番号の採番ルールを使うか、どの支払アカウントが提示されるか、そして電子インボイスを申告している場合は、その販売が申告されるかどうかまで決めます。電子インボイスは拠点ごとに有効化されるからです。「請求書番号体系」は請求書に付与される番号を制御します。「販売日」は伝票の会計上の日付で、既定値は現在日時です。「請求書通貨」と「対SAR為替レート」は、外貨建て販売が設定されている場合にのみ表示されます。

「請求書番号」は意図的に触りにくくなっています。請求書番号を編集する権限を持つユーザーに対して、伝票が下書きである間だけ表示され、「空欄の場合は自動生成されます」というヘルプテキストが添えられます。これは正しい設計です。レジ担当者が上書きできる請求書番号は連番ではなく、途切れた連番は税務調査官が最初に気づくものです。

「顧客」カードでは、取引先と「支払条件」を入力します。支払条件は数値と単位（「月」または「日」）で指定します。この画面には支払期日の項目はありません。期日は支払条件から算出され、空欄のままにすると顧客に設定された既定の支払条件が使われます。請求書ごとではなく顧客レコードに支払条件を設定しておくことが、5分をかける価値があるのはこのためです。

ステータスがほぼすべてを決める

「販売を追加」の「ステータス」には、「確定」「下書き」「見積書」「プロフォーマ」があります。後続のほぼすべての動作がこの値で制御されるため、フォーム上で最も影響の大きい項目です。

下書きのルールには意図的な例外が一つあり、驚かされる前に知っておく価値があります。POS設定にある「下書き請求書の在庫を差し引く」という事業設定を有効にすると、純粋な下書きでも保存時に在庫が減り、完了した現金販売とまったく同じように販売、利益、売上原価、キャッシュフローの各レポートに算入されます。既定では無効で、製品内のヘルプテキストにもはっきりそう書かれています。下書きを本当にピッキング伝票として使っている場合にのみ有効にし、その時点で下書きが財務的に実在するものになることを理解してください。

実務上のルールはこうです。商品が出荷され、顧客に支払義務があるなら、ステータスは「確定」です。それ以外は取引ではなく、意図を記録しているにすぎません。気になるミスを避ける手段として「下書き」を使わないでください。確定されない下書きは、どこにも現れない販売になってしまいます。

• 「確定」は実際の請求書です。在庫を減らし、入金を受け付け、総勘定元帳への計上対象となり、電子インボイスが有効な場合は税務当局に申告されます。
• 「下書き」は作業中の伝票です。元帳には計上されず、入金も受け付けません。保存処理は、ステータスが下書き、見積書、プロフォーマの販売に対して入金記録を書き込むことを拒否します。既定では在庫にも影響しません。
• 「見積書」は申し出です。何も動きません。在庫も、元帳も、入金もありません。
• 「プロフォーマ」は請求前の書類です。見積書と同様、何も動かしません。

販売の税金の計算方法

税金は販売に2つのレベルで入ることがあり、その違いは重要です。明細税は、個々の商品行に付けられる税率です。注文税は伝票全体に適用される単一の税率で、商品グリッドの下にある「注文税」項目で選択します。ほとんどの事業ではどちらか一方を使います。同じ伝票で両方を使うと他のシステムではトラブルになりがちですが、Skyline Nexusはまさにその誤りを防ぐように作られています。

注文税は、すでに独自の明細税を持つ行を除いた課税標準に対して課されます。自身の税率がヘッダーの税率と同じ行は、ヘッダーの課税標準に一切算入されません。平たく言えば、システムは付加価値税に付加価値税を上乗せせず、すでに伝票と同じ税率で課税されている行に二重に課税することもありません。これは請求書合計を計算する処理に組み込まれた計算ルールであり、チェックを忘れないようにしなければならない設定ではありません。

価格が税込か税抜かは、請求書ではなく商品の属性です。商品フォームには「販売価格の税区分」という項目があり、「税込」と「税抜」から選びます。明細行には税抜単価と税込単価の両方が保存されるため、請求書は再計算せずにどちらでも表示できます。販売フォームの行ごとの税選択は、事業でインライン税が有効になっている場合にのみ表示されます。無効の場合、税金は商品と注文税の項目から決まります。

端数処理は請求書ごとの判断ではなく、事業設定です。既定では、明細ごとに丸めてから合計するのではなく、全桁の精度で合計し、最後に請求書全体で一度だけ丸めます。2つの方法の差は、明細の多い請求書で補助通貨単位の数単位にすぎず、顧客にとっては重要ではありませんが、元帳と一致させなければならない付加価値税の申告にとっては非常に重要です。

入金は請求書とは別の記録

フォーム下部の「支払を追加」カードは任意です。各支払行では「金額」「支払日」「支払方法」「支払アカウント」と、任意の「支払メモ」を入力します。「支払行を追加」を使えば、1枚の請求書を複数の支払手段に分けられます。顧客が一部を現金、一部をカードで支払う場合に必要な機能です。行の下には「支払合計」（Total Payable）、「支払合計」（Total Paying）、「お釣り」、「残高」が表示されます。

掛売りの場合は、「掛売 — 全額未払」にチェックを入れます。これにより支払金額がゼロになり、支払行が非表示になり、保存処理は入金記録の作成を完全にスキップします。請求書は発行され、売掛金が計上され、代金は後で回収されます。これが掛売りを記録する正しい方法であり、金額ゼロの支払行を入力するのは正しくありません。

伝票上の支払ステータスは入力するものではなく、導き出されるものです。受領額の合計が請求書合計以上であれば支払済み、一部を受け取っていれば一部、何も受け取っていなければ未払いとなります。この判定は入金が追加、編集、削除されるたびに再実行されます。そのため、後日の入金は請求書を編集するのではなく、販売一覧の「支払を追加」（/payments/add_payment/{id}）から回収を記録してください。数字を合わせるために請求書を編集するのは誤った発想であり、取引の取消と訂正に関するガイドで扱っています。

販売が在庫に与える影響

販売が「確定」で保存されると、各明細行はその事業拠点におけるその商品バリエーションの利用可能数量を減らします。在庫管理対象でない商品はスキップされます。在庫管理を無効にした商品に対しては減算処理が何もしないため、サービスや作業料を同じ画面で販売しても、マイナス在庫は発生しません。

続いて、目にすることは少ないものの知っておくべき第2の処理が実行されます。販売した各数量は、それが由来する特定の仕入明細に割り当てられ、その割り当てが保存されます。この対応付けによって、売上原価は推定ではなく実際のものになります。システムは、どの原価のどの仕入が、どの販売に供給されたかを把握しているのです。ロットと有効期限のルールを適用するのも、過剰販売が許可されていない場合にそれを拒否できるのも、この仕組みによるものです。

この割り当ては販売の時点で構築されるため、数週間遅れて記録された販売は、その間に在庫が動いていれば、当時とは異なる割り当てになります。これはバグではなく計算の結果であり、販売を発生当日に記録すべき最も実践的な理由です。

総勘定元帳に計上される内容

確定した販売は内部イベントを発生させ、会計モジュールがそれを受け取ります。すべてが設定されていれば、そのリスナーが仕訳を作成します。仕訳は、売掛金の統制勘定に請求書合計の全額を借方計上し、収益に税抜金額を、仮受付加価値税に税額を貸方計上します。商品カテゴリーごとに収益勘定が設定されていれば収益はカテゴリー別に分けられるため、商品とサービスの両方を販売する事業では、手作業で分析しなくても損益計算書で両者を区別して確認できます。

3つの条件がすべて満たされなければ何も計上されません。元帳が壊れていると結論づける前に、3つすべてを確認する価値があります。第一に、販売が「確定」であること。下書き、見積書、プロフォーマは設計上スキップされます。第二に、/accounting/settings の会計設定で「売上取引を自動計上」が有効になっていること。第三に、勘定科目がマッピングされていること。売掛金勘定、収益勘定、仮受付加価値税勘定を /accounting/settings/mapping で設定します。マッピングが欠けていても何かが壊れるわけではなく、単に計上が拒否されるだけです。

月末に引っかかりやすい第4の関門があります。販売日を含む会計期間が開いていなければなりません。期間が締められているかロックされている場合、締めた月に黙って遡って計上されるのではなく、計上が拒否されます。これは正しい動作であり、期間を締めることの目的そのものですが、ロックされた月の日付の販売を元帳に反映させるには、期間を再開するか日付を訂正する必要があるということです。

電子インボイス（適用される場合）

サウジアラビアでは、販売が「確定」で保存されると、電子インボイスモジュールが請求書を自動的に生成して申告します。この機能は事業全体ではなく事業拠点ごとに有効化されるため、ある拠点では電子インボイス制度の下で運用し、別の拠点はまだ登録していない、ということが可能です。設定は /zatca/configuration にあります。

申告はべき等です。システムは申告済みのものを記録し、同じ請求書を二度申告することはありません。申告に失敗しても、販売は保存されます。これは意図的な選択です。税務当局のエンドポイントに接続できなかったせいで販売が失われるほうが、数分遅れて申告するよりもはるかに悪いからです。失敗した申告は、販売そのものから再送信できます。

請求書はいったん申告されると、編集できないようロックされます。システムのメッセージは明確で、請求書はすでに申告済みのため編集できず、訂正するにはクレジットノートまたはデビットノートを発行しなければならない、と表示されます。これはソフトウェアが使いにくいからではありません。申告された請求書は税務当局が保有している書類であり、それを変更する唯一の適法な方法は、別の書類を発行することなのです。

保存した後

販売は「すべての販売」に、請求書番号、顧客、合計、支払ステータス、該当する場合は電子インボイスのステータスとともに表示されます。行メニューからは、表示、印刷、入金の追加、入金の表示、返品の開始ができます。/sells/show/{id} の詳細画面では、明細行、税の内訳、入金履歴が一か所にまとめて表示されます。特定の請求書で何が起きたのかを尋ねられたときに開くべき画面です。

顧客の残高は販売後に再計算されるため、売掛金は顧客元帳と売掛金の年齢調べ表にすぐに反映されます。元帳への計上が有効かつ設定済みであれば、同じ数字が会計モジュールを通じて試算表と貸借対照表にも表示されます。両者が一致しない場合、通常の原因は計算誤りではなく、前述の3つの計上の関門のいずれかです。

簡単なチェックリスト

• 拠点は正しいですか？在庫、採番、支払アカウント、電子インボイスが拠点で決まります。
• ステータスは「確定」ですか？それ以外はまだ販売ではありません。
• 販売日は、入力している日ではなく、実際に販売が行われた日ですか？
• 顧客が支払っていない場合、金額ゼロの支払行ではなく「掛売 — 全額未払」にチェックが入っていますか？
• 掛売りの場合、請求書の経過日数が正しく計算されるよう支払条件が設定されていますか？
• 保存した後ではなく保存する前に、合計欄の税額が正しいか確認しましたか？