2 クラウド型販売管理(個別受注型)

クラウド型販売管理のうち個別受注型に関して記載しております。例えば、IT企業のアプリ開発会社であれば、顧客のご要望に応じてアプリの仕様がことなりますので、見積してから受注し、受注後も開発プロジェクトがスタートし、開発を行ったアプリを納品して、顧客にて検収して頂くことになります。見積、受注、納品、検収、売上の流れになります。また、納品までには外注会社からのデザイン画像を受け入れる場合もあります。よって、受注残や発注残をきちんと管理する必要があるのです。

一方で一般消費者を対象に商品を販売するECサイト(ストアサイトやショッピングサイトとも呼ばれてます)は、ほぼシステムで自動処理されるのが通常です。クラウド型販売管理としてはECサイトで購入決定の受注から始まることになります。そして、商品を発送することで売上が立ちます。もちろん、商品の在庫がある前提で受注しますので、受注に対する発注残という考え方はないのです。(仕入に対する発注残の管理はあります。)

 

投稿者:systemkanri 投稿日時:

2-1 受注残とは

受注残とは

2-1

受注残とは

未だ顧客へ納品(あるいは出荷)していない注文のこと

 受注残とは、顧客から注文を受けた商品サービスについて、未だ顧客へ納品(あるいは出荷)していない注文のことを言います。例えば、単価100円のA商品を数量10個で注文を受けたとします。このとき、受注残は、数量10個(1,000円)になります。その後、販売者側の都合により、7個を納品したとします。このときの受注残は、数量3個(300円)になります。そして、受注残の数量3個を納品すれば、受注残は0になり、1つの受注に対して納品を完了したことになります。つまり、受注残は注文主である顧客に対する納品までの進捗状況を管理することができるのです。

なお、納品日と検収日を分けて受注を管理することもあります。納品後に顧客側での検収作業あり、検収基準で売上計上する場合です。この場合、受注残は納品日で消えますが、検収残として管理する必要が出てくるのです。受注残を検収日まで含めるのか、あるいは、検収残という考え方を持つのか、自社業務に合わせてクラウド型販売管理システムをカスタマイズする必要があるのです。
※「検収」という言葉は仕入にも使いますので、受注検収という言葉を使うことをお勧め致します。
クラウド型販売管理の受注残は、顧客単位、受注単位に受注残を一覧で参照したり、受注残のある顧客リストや受注一覧を表示することができます。顧客からの問い合わせ対応に役立つことになります。

「販売9」
freee連携kintoneプラグイン
統合型ワークフロー

投稿者:systemkanri 投稿日時:

2-2 発注残とは

発注残とは、自社の商品サービス等の仕入先への発注について、未だ自社に納品されていない発注のことを言います。例えば、仕入単価70円のA商品を数量10個で発注したとします。このとき、発注残は、数量10個(700円)になります。その後、仕入先の都合により、7個が分納されたとします。このときの発注残は、数量3個(210円)になります。そして、発注残の数量3個が納品されれば、発注残は0になり、1つの発注に対して仕入が完了したことになります。
つまり、発注残は、仕入先からの納品の進捗状況を管理することができるのです。

なお、納品日と検収日を分けて発注を管理することもあります。納品後に自社での検収作業があり、検収基準で仕入計上する場合です。この場合、発注残は納品日で消えますが、検収残として管理する必要が出てくるのです。発注残を検収日まで含めるか、あるいは、検収残という考え方を持つのか、自社業務に合わせてクラウド型販売管理システムをカスタマイズする必要があります。

※「検収」という言葉は受注にも使いますので、仕入検収おちう言葉を使うことをお勧め致します。

なお、クラウド型販売管理としては、仕入先を社内部門として位置付けることにより内作の管理に利用することもあります。

クラウド型販売管理の発注残は、仕入先単位、発注単位に発注残を一覧で参照したり、発注残のある仕入先リストや発注一覧を表示することができます。仕入先からの問い合わせ対応に役立つことになります。

投稿者:systemkanri 投稿日時:

2-3 受注残と発注残の関係

個別受注型では、基本的に在庫をもたず、1つの受注について都度仕入を行ったり、内作により商品サービスを提供するケースです。複数の仕入先が関係する場合もあり、1つの受注についてリードタイムが異なる発注をそれぞれの仕入先に行うことになり、業務管理が煩雑になります。

1つの受注について、この受注から発生する複数の発注を関連付けて管理できることがクラウド型販売管理に求められます。
例えば、受注一覧において受注残が見れることは当然ですが、同時に発注残もこの受注一覧に表示されるというものです。もちろん、1つの受注の参照画面でも、発注残を確認できるということです。

これにより、発注残が0になった受注は、仕入が完了しているので顧客への納品が可能であることが分かります。仕入担当と営業担当が分かれている企業の場合には、このような受注残と発注残の一元管理がとても重要な役割になります。

個別受注型では、受注残と発注残を一元管理できることが求められるのです。

 

投稿者:systemkanri 投稿日時:

2-4 何を根拠に、請求している?

請求することは、企業にとってはとても慎重になる業務です。二重請求はもっての外であり、請求漏れも企業の信頼を損ないます。皆さまの会社では、どのようなルールで請求業務を行っておりますか?

個別受注型では、納品あるいは受注検収がされたものを請求するというのが基本ルールになります。
クラウド型販売管理では、受注残が0になったタイミングで請求が可能になるというロジックになります。請求可能になった状態から実際に請求書を発行した際には、その受注について請求済みにする必要があります。そうすることで、二重請求を防ぐことができます。

聞きなれない言葉かもしれませんが、請求残という考え方があります。
10個の受注を受けて、その後に納品まで行ったとします。受注残は0になりますが、同時に請求残を10個とするのです。そして、請求書を発行した際には、請求残を0にするという考え方です。受注残、発注残と同様にクラウド型販売管理では、請求残のロジックを実装することができるのです。受注一覧画面では、受注残、発注残と請求残を同時に参照することができますので、受注から請求完了までを一つの画面で確認することが可能となります。

請求残の考え方を業務に組み込むことで、請求漏れや二重請求を防ぐことができるのです。
自社の請求関連業務を今一度見直ししてみてはいかがでしょうか。

 

投稿者:systemkanri 投稿日時:

2-5 売掛を管理できている?

請求書を発行したあとは、入金を待つことになります。
売掛つまり売掛金とは、「信用取引にて商品サービスを提供した代金を受け取る権利(およびその金額)」を言います。
クラウド型販売管理としてロジックを考えると、以下のようになります。
「商品サービスを提供した」は、納品あるいは受注検収がされた日に、販売代金を売掛金にプラスします。
「受け取り権利」が消滅するのは、支払があった日、銀行口座に入金があった日に、入金額を売掛金からマイナスします。

こうしてみると簡単なロジックなのですが、実際にはもう少し複雑なのです。
売掛金は、取引先毎に管理するのが基本です。クラウド会計などの売掛金リストは、取引先単位でかつ月別の集計表で表示されるのが一般的です。さらに、商品サービスを提供した単位(これを取引と言います)、請求書を発行した単位に、入金を管理できることが求められます。これを入金消込と呼んでます。

請求書は、複数の取引を請求明細としてまとめて1つの請求書として発行することがあります。取引は日付が異なる場合があります。例えば、前月1日から末日までの取引をまとめて1つの請求書として発行するケースです。
前月10日に1万円、前月20日に2万円の取引があったとすると、請求書の請求額は3万円になります。その後、3万円の入金があったとすると、前月10日と20日の取引にこの3万円を割り当てて消し込みを行うと同時に、発行した請求書についても消し込むことになります。そして、売掛金をマイナスします。

売掛金の消し込みは、システム観点からしても意外と複雑なロジックになりますが、顧客や取引先との信頼関係に直結することですので、とても慎重に行う必要があります。

今どきのクラウド会計では、AIを駆使して入金消込を自動で行ってくれる会計システムもあります。お勧めなのが、会計freeeです。会計とう領域であるものの販売管理に近い「取引」という考え方を取り入れ、かつ、請求書を作成かつ郵送してくれます。銀行口座ともネット接続し、AIを駆使して入金消込も自動で行ってくれるのです。会計freeeは一度、お試しする価値はあります。

弊社では、kintoneと会計freeeを連携させるプラグインをご提供しております。業務効率化のお役に立てれば何よりです。

 

投稿者:systemkanri 投稿日時:

2-6 買掛金から振込ファイル(全銀ファイル)を作成

買掛は、売掛と同様に考えれば良いのですが、大きな違いとしては、支払を行い買掛金を消し込むことです。一般的に支払は、実際の振込日の数日前に行います。買掛金の消し込みは、実際に支払った日に消滅します。つまり、支払操作を行った日と買掛金が消滅する日にタイムラグがあり、支払操作を行ったことを記録しておき、二重振込等の間違いを起こさないようにシステムでロジックを組む必要があるのです。

そもそも、買掛金とは、「掛け取引によって、商品サービスを購入した代金を支払う義務(およびその金額)」を言います。

クラウド型販売管理としてロジックを考えると、以下のようになります。
「商品サービスを購入」は、仕入の商品サービスが納品された、または検収した日に、仕入金額を買掛金にプラスします。
「代金を支払う義務」が消滅するのは、支払った日に、仕入金額を買掛金からマイナスします。

単純なロジックではありますが、この買掛金のプラスとマイナスの間には、請求書を受け取る、請求金額を確認する、支払操作をするという業務があります。これらの業務が煩雑な作業になっているのです。

まず、請求書を受け取り、請求金を確認するという業務では、仕入をした代金をいつ支払うのか?が問題になります。例えば、仕入を行った月の翌々月末払いのケースです。この場合は、今月末日に支払うのは、前々月の仕入金額の合計になります。この金額には、前月の仕入は含みません。でも、買掛金としての今現在の残高は前月分も含まれますので、注意が必要です。
これを管理するために、支払期日が必要になるのです。商品サービスを仕入れ、または検収した日を基準に、翌々月末など仕入先毎に異なる支払サイトに従って、支払期日を算出するのです。こうしておくことで、今月に支払いするべき金額を支払期日をもとに合計することができるのです。
仕入先から受領した請求書が、クラウド型販売管理やクラウド会計で計算した支払するべき金額と一致することで、請求書の確認できるようになるのです。

そして、次は支払です。クラウド会計を利用すると、支払期日で合計した金額をもとに、銀行振込ファイル(総合振込ファイル)を作成してくれます。これをオンラインバンキングで振込ファイルをアップロードすることで支払操作が完了します。しかし、注意が必要です。
オンラインバンキングで振込ファイルをアップロードした後、実際に振込みされるのは、数日後です。では、買掛金はいつ消し込むべきでしょうか?という疑問がでてきます。

  • (1)クラウド会計で振込ファイルを出力したタイミング
  • (2)実際に振込が完了した後の銀行明細をクラウド会計に取込んだタイミング

(1)では、未来の振込予定日に支払したことにして、買掛金を消し込むことになります。もし、振込が失敗したらどうなるのか?と懸念されます。(実際は手補正になります。)
(2)は、振込した事実に基づき買掛金を消し込みますので、振込み失敗の場合も対応が可能なのですが、(2)のタイミングまで買掛金が残っているので、振込ファイルを誤って二重作成してしまうことが懸念されます。この場合は、特に承認申請フローなどの業務ルールをきちんと作成しておく必要があります。

(1)と(2)は、利便性や業務フローの構築など、一長一短があります。どちらのケースでシステム化を行うかは、自社の業務レベルに合わせて検討されることをお勧め致します。

なお、クラウド会計の会計freeeでは、(1)と(2)のどちらでも対応が可能です。

 

投稿者:systemkanri 投稿日時: