WEBVTT

00:00:00.000 --> 00:00:05.500
売上を上げ請求書を送付したはずなのにその代金はいつ口座に振り込まれるのでしょうか もし支払われないとしたらどうなるのでしょうか

00:00:05.500 --> 00:00:14.580
m 365 fm でお届けするマイクロソフトナレッジナゲッツ今回のエピソードへようこそ 司会のメルコピーターズです今回はダイナミクス365の売りかけ金管理についてわかりやすく解説します

00:00:14.580 --> 00:00:21.280
このエピソードが終わる頃にはある顧客の売上が支払いに至るまでの流れと支払いが 遅延した際の企業の対応が理解できるはずです

00:00:21.280 --> 00:00:31.160
最もシンプルな定義から始めましょう売りかけ金とは顧客からの未回収金とそれに対する 入金状況を管理するものですビジネスにおけるお金の管理用キャビネットだと考えてください

00:00:31.160 --> 00:00:37.600
顧客ごとに一つのフォルダーが用意されます そのフォルダーには請求書支払い期日そしてその後のフォローアップ作業が記録されます

00:00:37.600 --> 00:00:45.000
スプレッドシートでも一覧は作れますが新規の売上合意した期日銀行振込そして予診判断といった情報を 会社全体で確実に紐付けることはできません

00:00:45.000 --> 00:00:50.600
ダイナミクス365ファイナンスならそれが可能です では基本となる顧客アカウントから見ていきましょう

00:00:50.600 --> 00:00:58.220
一つ目すべての請求書の出発点となる顧客アカウントです ノースウィンドエクイップメントという顧客を例に挙げます

00:00:58.220 --> 00:01:06.180
注文を受ける前にダイナミクス365には名前や電話番号以上の情報が必要です ノースウィンド社と取引を行うための財務上のルール設定が必要です

00:01:06.180 --> 00:01:13.020
顧客アカウントとは先ほどのキャビネットにあるラベルの付いたフォルダーのことです ここにはダイナミクス365が顧客を識別するための情報

00:01:13.020 --> 00:01:21.920
請求書の送付先一般的な支払い方法そして会社が許可する余信額などの詳細がすべて 保持されます基本的な設定に聞こえるかもしれませんが後々の混乱を大きく防ぐことが

00:01:21.920 --> 00:01:27.160
できます 例えばアカウントには顧客の請求書送付先住所が保存されますこれは配送先住所とは異なることがよくあります

00:01:27.160 --> 00:01:34.640
機器は工場へ発送し請求書は経理部門へ送るといった具合です また支払い条件も保持されます支払い条件とは顧客の支払い猶予期間はどれくらいかという

00:01:34.640 --> 00:01:41.440
シンプルな問いに対する答えですノースウィンド社は30日払いかもしれません 前払いをする顧客もいれば大口顧客なら60日払いで交渉することもあるでしょう

00:01:41.440 --> 00:01:49.220
条件がアカウントに設定されればダイナミクス365が期日を自動的に計算します メールの履歴を探したり30日払いの起算日が注文日なのか配送日なのか

00:01:49.220 --> 00:01:56.740
請求書発行日なのかを推測する必要はありません システムが自動的に把握します重要なのはここです顧客アカウントには通常の支払い方法も保存されます

00:01:56.740 --> 00:02:02.040
ノースウィンド社が銀行振り込みで別の顧客がクレジットカードで支払う場合でも 経理チームは支払い時に適切なプロセスを進めることができます

00:02:02.040 --> 00:02:10.360
すべての顧客を毎回個別に扱う必要はありません そして予診限度額もあります予診限度額とは企業が顧客に対して一度に許可する見払い金額の最大値のことです

00:02:10.360 --> 00:02:15.680
オフィスビルの受付デスクをイメージしてみてください 受付係はその人が上の階へ行く許可があるかを確認します

00:02:15.680 --> 00:02:20.240
人柄が良いかどうかではなくルールで許可されているかだけを見ます ここでも同じ考え方です

00:02:20.240 --> 00:02:28.780
予診限度額は営業部門と財務部門に明確な境界線を示します ノースウィンド社が有料顧客であってもすでに多額の見払いがあるなら企業は次の大きな注文を受ける前に一度立ち止まるべきです

00:02:28.780 --> 00:02:34.660
裏側ではダイナミクス365は顧客グループや天気プロファイルも活用しています これらの名前に惑わされないでください

00:02:34.660 --> 00:02:40.160
顧客グループとは似たような顧客をまとめる手法にすぎません 小売は小売グループに卸売は別のグループにまとめます

00:02:40.160 --> 00:02:49.440
そうすることで企業は合理的な範囲で共通のルールを適用できます 天気プロファイルとは請求書が登録された際どの財務官場に債務を記録すべきかをダイナミクス365に支持する会計ルールです

00:02:49.440 --> 00:02:56.680
営業担当者や顧客としてその作業を直接目にすることは通常ありません しかし財務部門にとってはすべての金額を正しい場所に記録する必要があるため不可欠なものです

00:02:56.680 --> 00:03:06.180
そしてここに真の強みがあります顧客アカウントは営業サイドと財務サイドを接続します 営業担当者がノースウィンド社の注文を作成すれば財務部門が後でその情報を再構築する必要はありません

00:03:06.180 --> 00:03:13.760
彼らは顧客情報支払い条件予診状況見払い金額を確認できます すべてが自動的につながるのですそれこそが連絡先リストと顧客アカウントの違いです

00:03:13.760 --> 00:03:21.160
連絡先リストは相手に電話をかけるためのものです 顧客アカウントは販売時のルールを含め金銭的な関係性を記録するものです

00:03:21.160 --> 00:03:27.320
ノースウィンド社が何かを購入したらダイナミクス365はその販売を適切な支払い請求へと変換する必要があります

00:03:27.320 --> 00:03:37.720
その2請求書の作成つまり販売を未払い再建へと変換することです では注文と請求書の違いは何でしょうか注文書は顧客の希望を請求書は支払うべき金額を示します

00:03:37.720 --> 00:03:46.220
重要なポイントはこれです請求書は顧客アカウントに未決済残高を作成します 転記されると正式な請求となり売りかけ金として管理できるようになります

00:03:46.220 --> 00:03:53.140
ノースウィンドエキップメント社の例に戻りましょう 彼らが機器を10個注文し営業チームが注文を記録し倉庫が準備して出荷します

00:03:53.140 --> 00:03:59.480
これでノースウィンド社は製品を手にしました その時点で何を買ったかいくらかかるか支払い期限はいつかという明確な記録が必要です

00:03:59.480 --> 00:04:05.020
その記録が顧客請求書です ダイナミクス365ファイナンスの請求書のほとんどは販売注文から直接作成されます

00:04:05.020 --> 00:04:12.140
これにより請求書は元の販売内容と紐付いたままになります 顧客の品目価格数量そして合意されたすべてのルールがすでにファイルに記録されているからです

00:04:12.140 --> 00:04:20.900
それらの詳細を別の請求システムに再入力する必要はありません 商品の出荷時やサービスが請求対象のマイルストーンに達した時点で受注から請求書を作成します

00:04:20.900 --> 00:04:26.980
正確なタイミングは記者の業務プロセスによって異なります 出荷時に請求する企業もあれば作業の段階が完了した後に請求する企業もあります

00:04:26.980 --> 00:04:33.760
コンサルティング会社であればマイルストーンの達成後に請求書を発行することもあります ダイナミクス365は記者が設定済みのプロセスに従います

00:04:33.760 --> 00:04:40.880
梱包明細書請求という言葉を耳にすることがあるかもしれません 梱包明細書は実際に倉庫から出荷され配送段階に達したものを確認する書類です

00:04:40.880 --> 00:04:47.940
出荷実績に基づいて請求を行う場合請求書はその確定した配送詳細を利用できます これによりよくある問題を回避できます

00:04:47.940 --> 00:04:55.160
例えば10個の注文があっても在庫待ちで2個が未発送のため今日8個だけ出荷されたとします 梱包明細書から請求すれば実際に出荷された8個分だけを請求できます

00:04:55.160 --> 00:05:02.400
ノースウィンド社が受け取っていない残り2個分まで請求することにはなりません 注文情報は重要ですが確定した配送内容によって今回の請求書に何を記載すべきかが決まります

00:05:02.400 --> 00:05:07.880
しかしすべての請求書が受注から始まるわけではありません 出荷を伴わない単発の費用を請求しなければならない場合もあります

00:05:07.880 --> 00:05:14.380
例えばノースウィンド社が特別なトレーニングセッションを依頼した場合などです サービス料金やプロジェクト費用あるいは修正のために個別の請求書が必要になることもあります

00:05:14.380 --> 00:05:21.000
そのようなケースに対応するためダイナミクス365ファイナンスではフリーテキスト請求書をサポートしています フリーテキストとはいい加減や非公式という意味ではありません

00:05:21.000 --> 00:05:27.700
請求書が受注情報とリンクしていないことを意味します 顧客料金金額必要な場合は税情報そして支払い情報を入力します

00:05:27.700 --> 00:05:34.520
転記されるとそれは顧客アカウント上の通常の未払金額となります 顧客には正式な請求書が届きます財務部門は未決済の残高を確認できます

00:05:34.520 --> 00:05:39.000
継続的な業務についてはどうでしょうか ノースウィンド社が機器のメンテナンス料を月額で支払う場合を想定してください

00:05:39.000 --> 00:05:46.940
毎月手作業で同じ請求書を作成するのは時間の無駄であり小さなミスを招く原因にもなります サブスクリプション請求では請求スケジュールを使用して繰り返しの請求を処理します

00:05:46.940 --> 00:05:58.700
契約と請求時期を設定すればダイナミクス365が各請求期間の到来に合わせて請求書を作成します これにより継続的なサービスを繰り返し請求でき顧客は同意したスケジュールに基づいた請求書を受け取れます

00:05:58.700 --> 00:06:05.460
転記は販売ステータスを更新する重要な瞬間です これにより金額がノースウィンド社の顧客アカウントに未払金として記録されます

00:06:05.460 --> 00:06:14.220
またその金額は会社の財務記録にも送られ販売が請求済みであり支払いがまだ未完了 であることが確認できます請求書はもはや誰かが気軽に変更できるような下書きではありません

00:06:14.220 --> 00:06:23.180
それは財務記録の一部となります具体的に見ていきましょう ノースウィンド社が1万ドル相当の機器を注文します8ユニットが先に出荷されるためその8ユニット分の請求書を発行します

00:06:23.180 --> 00:06:31.740
請求書には金額支払期日及び支払い方法が記載されています ノースウィンド社が請求書を受け取るとダイナミクス365はその同額を見払い残高として記録します

00:06:31.740 --> 00:06:40.480
この共有記録により営業倉庫担当財務部門は同じ取引に集中できるようになります 異なるファイルで異なるバージョンを巡って争う必要はありませんが請求書はあくまで支払いを求めるものです

00:06:40.480 --> 00:06:48.180
次の仕事は支払いが到着したことを確認し適切な未払い残高と紐付けることです 2月3日支払いの受け取りと称号です正しい請求書の消し込み作業です

00:06:48.180 --> 00:06:55.700
支払いの到着は単純なことに思えます銀行残高が増えれば仕事は完了したのでしょうか そうとは限りません財務部門はまだ2つの問いに答える必要があります

00:06:55.700 --> 00:07:01.960
誰が送金したのかそしてそのお金でどの未払い請求書を消し込むべきかということです ノースウィンド社が設備代金の請求書を支払う場面を考えてみましょう

00:07:01.960 --> 00:07:09.420
銀行には短い参照番号金額日付とともに支払いが表示されるかもしれません その支払いをノースウィンド社の未払い残高と称号しなければ銀行には現金がある一方で

00:07:09.420 --> 00:07:13.700
ノースウィンド社にはまだ未払いがあるという表示になってしまいます これらの記録を一致させる必要があります

00:07:13.700 --> 00:07:22.940
ダイナミクス365ファイナンスは様々な顧客の支払い方法に対応しています 現金小切手クレジットカード銀行振込などを受け取るほか一部のビジネスプロセスでは

00:07:22.940 --> 00:07:28.060
為替手形といった正式な支払い書類も扱います それぞれの方法には財務記録に至る固有のルートがあります

00:07:28.180 --> 00:07:33.240
銀行振込は銀行明細に記載されます 小切手は銀行で決済される前に記録が必要になる場合があります

00:07:33.240 --> 00:07:40.160
カード決済は決済サービスを通じて行われます ダイナミクス365は適切な顧客アカウントに対して支払い詳細を記録する場所を財務部門に提供します

00:07:40.160 --> 00:07:48.020
その場所が多くの場合顧客支払い仕分け帳です 仕分け帳と聞くと紙の台帳を連想しますがダイナミクス365では支払いを転記する前に管理課で入力

00:07:48.020 --> 00:07:55.060
確認を行うための場所です 財務部門は顧客金額支払い方法銀行口座そして支払いに付随する参照番号を記録します

00:07:55.060 --> 00:08:01.940
次に決済という言葉がありますがこれは響きほど難しいものではありません 決済とは支払いをその対象となる請求書と称号することを意味します

00:08:01.940 --> 00:08:08.080
ノースウィンド社が設備請求書の全額を支払ったとします 財務部門はその支払いと未払い請求書を選択し両者を決済します

00:08:08.080 --> 00:08:15.120
転記されるとその請求書は未払いとして表示されなくなります 支払いによって消し込まれたからです顧客残高はその金額分だけ減少します

00:08:15.120 --> 00:08:20.700
これが重要なのは決済を行わないと現金を受け取っているにも関わらず 請求書が未払いのまま残ってしまうためです

00:08:20.700 --> 00:08:25.360
そうなると不正確なレポートや不要なフォローアップ さらにはすでに支払い済みの顧客への気まずい連絡が発生してしまいます

00:08:25.360 --> 00:08:31.640
支払い額が請求書の全額に満たない場合もあります 例えばノースウィンド社が金額の一部を先に支払い残りは後で支払うと合意した場合などです

00:08:31.640 --> 00:08:36.260
ダイナミクス365では支払われた金額を請求書に重当しつつ 未払い分をそのまま残しておくことができます

00:08:36.260 --> 00:08:41.400
入金があったからといって請求書が消えてしまうことはありません 経理部門は正確な残高を把握できます

00:08:41.400 --> 00:08:47.300
これは誤って請求書を全額支払い済みとして処理し後からメモや別のスプレッド シートで不足分を追いかけるよりもはるかに優れた方法です

00:08:47.300 --> 00:08:54.000
多くの企業にとって銀行振込は大量に発生します すべての振込と未決済の請求書を手作業で確認するのは時間がかかります

00:08:54.000 --> 00:08:58.880
特に顧客が複数の請求書をまとめて支払ったり参照番号が不明瞭な場合はなおさらです

00:08:58.880 --> 00:09:03.100
ダイナミクス365にはこの作業のための支払い消耗仕分け帳があります

00:09:03.100 --> 00:09:14.900
チームは銀行取引明細情報をインポートしそれを使って入金と未決済の顧客請求書を 称号できます支払い参照番号金額顧客詳細および称号ルールによりシステムが入金の割り当て先を提案します

00:09:14.900 --> 00:09:21.580
結果は必ず確認してください その工程が重要です自動化で検索の手間は減りますが支払いと正しい請求書が

00:09:21.580 --> 00:09:29.220
称号されているかを確認する責任は経理部門にあります 顧客が複数の請求書に対して一度に送金した場合処理担当者はその支払いを複数の請求書に割り当てることが

00:09:29.220 --> 00:09:38.060
できます参照番号が間違ったドキュメントを指している場合転機前に修正可能です 目的は人間の判断を排除することではなく担当者が1日中銀行ファイルや請求書リストを

00:09:38.060 --> 00:09:43.640
探し回る時間をなくすことです さてノースウィンド社がグループ内の複数の会社で事業を展開していると仮定しましょう

00:09:43.640 --> 00:09:52.620
ある法人が機器を販売しグループ全体の中央財務会社が支払いを受け取るというケースです ダイナミクス365はそのような状況での集中支払いをサポートしています

00:09:52.620 --> 00:10:01.300
ある法人が別の法人の代理として支払いを記録できます 販売した会社に直接入金があったかのように装ったりシステム外でプロセスを管理したりする必要はありません

00:10:01.300 --> 00:10:10.480
記録には入金先とそれがどの顧客の再建を決済したかが示されます これにより特に複数の会社が一つの中央キャッシュチームを利用する場合共有の経理業務がより整理されます

00:10:10.480 --> 00:10:19.500
つまり完全な支払いプロセスとは単に銀行への入金を記録するだけのものではありません ダイナミクス365は未決済残高がなくなるかあるいは残高が経理部門に追加の支払いを促すまで

00:10:19.500 --> 00:10:26.360
顧客支払い請求書をリンクし続けます これで今日の支払いは完了です次の疑問は次の販売を行う前に生じます

00:10:26.360 --> 00:10:33.200
その顧客にさらに駆け売りを許可すべきでしょうか 4つ目は予診管理つまりいつまで販売を継続するかという判断です

00:10:33.200 --> 00:10:40.720
支払いを受け取り古い残高が解消されました 簡単そうですよねしかし次の注文を進める前に予診管理ではこのような問いが生まれます

00:10:40.720 --> 00:10:47.720
あなたのビジネスはあとどれくらいのリスクを許容できますか ホテルのフロントを想像してみてください宿泊客が遠泊を希望した場合スタッフは予約状況

00:10:47.720 --> 00:10:53.780
支払い状況規定を確認してから新しいルームキーを渡します それと全く同じことを販売注文に対して行うのが予診管理です

00:10:53.780 --> 00:11:00.960
ノースウィンドエキップメント社が全体として有料顧客かどうかを判断するわけではありません 会社が定めたルールに基づき現在の財務状況をチェックするだけです

00:11:00.960 --> 00:11:06.740
そうしたルールの一つが予診限度額です 予診限度額とは顧客が一度に終える債務の最大額のことです

00:11:07.060 --> 00:11:13.060
例えばノースウィンド社の限度額が5万ドルですでに4万5000ドルの債務がある場合 2万ドルの新規注文には注意が必要です

00:11:13.060 --> 00:11:20.180
注文自体は可能ですが企業としてその決定を見過ごしてはなりません ダイナミクス365なら複数の数値を同時にチェックできます

00:11:20.180 --> 00:11:26.180
未処理の請求書その支払い期限の超過状況 新規注文の金額そして顧客の利用可能な予診枠を確認します

00:11:26.180 --> 00:11:32.820
期限通りに支払う顧客には予診の余地があるかもしれませんが別の顧客は限度額内であっても 深刻な支払い遅延があるかもしれません

00:11:32.820 --> 00:11:39.680
これらはそれぞれ異なるリスクです ルールに抵触した場合ダイナミクス365は販売注文を予診保留にし

00:11:39.680 --> 00:11:45.780
商品出荷や未払いの作業を一時停止させます 営業部門は保留を確認でき経理部門はその理由を把握できるため

00:11:45.780 --> 00:11:51.640
倉庫から出荷した後に問題が発覚することはありません 余診保留は注文が完全に拒否されたことを意味するわけではありません

00:11:51.640 --> 00:11:58.460
誰かが内容を確認する必要があるということです ノースウィンド社が支払いの証明を送ってきた経理担当が請求ミスによる遅延だと

00:11:58.460 --> 00:12:03.400
知っているあるいは大規模な承認済みプロジェクトのために 一時的な増額を求められているといったケースです

00:12:03.400 --> 00:12:10.180
正当な理由があれば権限を持つ担当者が注文を承認できます ビジネスルールには現実に対応できる余地が必要なためこの部分は重要です

00:12:10.180 --> 00:12:15.700
システムは自動的な判断を停止させますが最終的に次に何をするかを決定し その決定の記録を残すのは担当者です

00:12:15.700 --> 00:12:21.700
ここで営業部門と経理部門が同じ情報を共有する必要があります 営業は顧客のビジネスを止めないことを優先し

00:12:21.700 --> 00:12:29.040
経理は回収不能な債権の増加から会社を守る必要があります どちらかが議論に勝つ必要はありません必要なのは注文

00:12:29.040 --> 00:12:35.720
未払額予診ルールを一元管理することだけです 予診管理と聞くと顧客を断ることだと誤解する人が多くいます

00:12:35.720 --> 00:12:40.760
そうではありません支払いの遅延が大きな問題に発展する前に安全な境界線を合意しておく ということです

00:12:40.760 --> 00:12:47.860
有料顧客を支援し例外を承認し自信を持って販売を続けることができます 単に事実を確認せずに債務を増やすことを防ぐだけなのです

00:12:47.860 --> 00:12:56.360
請求書の期日が過ぎると予防からフォローアップへとフェーズが変わります 5番目債権回収と紛争管理顧客を失うことなく支払いを促す方法です

00:12:56.360 --> 00:13:04.640
期日を過ぎた瞬間業務の性質が変わります企業はもはや信用供与の可否を判断する段階ではありません 期限を過ぎた代金を明確かつ誠実に請求する必要があります

00:13:04.640 --> 00:13:11.500
ダイナミクス365ファイナンスはその業務を回収ページに集約します これは期限が過ぎた顧客アカウントのための共有デスクのようなものです

00:13:11.500 --> 00:13:20.200
メールでメモを残す人スプレッドシートで通話を記録する人 経理で請求書を確認する人といった分断はなく回収チームは顧客残高とフォローアップ活動の

00:13:20.200 --> 00:13:28.020
すべてを一元管理できますこれにより対話の質が変わります 回収担当者は回収基準に基づいた顧客リストを使用して作業します

00:13:28.020 --> 00:13:36.080
これには特定の期日を過ぎた請求書一定金額以上の滞納 あるいは社内の回収ルールに基づき対応が必要な顧客などが抽出されます

00:13:36.080 --> 00:13:44.040
そのためチームは誰に最初に連絡すべきか迷う必要がありません 担当者は各顧客に対しリマインダーの送信特速上の作成メール送信

00:13:44.040 --> 00:13:51.860
または電話のためのタスク追加といったアクションを実行できます 目的は威圧的なメッセージを送ることではありませんほとんどの支払い遅延はありふれた理由から始まります

00:13:51.860 --> 00:13:57.260
請求書が誤った宛先に届いた顧客がコピーを必要としている あるいは支払い担当者が期日を見落としていたといったものです

00:13:57.260 --> 00:14:02.840
冷静なリマインダーで解決できることは多々あります 時には来週の金曜日に支払うという約束が顧客から返ってくることもあります

00:14:02.840 --> 00:14:09.520
ダイナミクス365ではそれを支払いの約束として記録できるため チームは確約があることを把握し予定通りに入金されたかを確認できます

00:14:09.520 --> 00:14:15.140
そのような記録がなければ翌朝別の担当者が同じ顧客に電話をかけ 既に期日が合意されていることを知らずに二重の特速をしてしまうかもしれません

00:14:15.140 --> 00:14:17.780
紛争 異議申し立てにも同様の配慮が必要です

00:14:17.780 --> 00:14:27.340
紛争とは顧客が請求書の全部または一部に異議を唱えることを指します 価格の誤り一部の商品未着あるいは承認していない作業に対する請求などがその理由です

00:14:27.340 --> 00:14:35.880
最悪の対応は問題をメールボックスの中に放置してしまうことです ダイナミクス365では請求書に紛争のフラグを立て回収業務中にそのステータスが常に可視化されるようにできます

00:14:35.880 --> 00:14:45.040
チームは状況や解決に必要な作業を追跡でき顧客が沈黙していることを理由に同じ特速を送り続けるような事態を避けられます これは企業が繰り返される問題を発見するのにも役立ちます

00:14:45.040 --> 00:14:50.640
複数の顧客が同じ種類の請求に異議を唱えている場合 経理部門は単なる支払遅延以上の重要な情報を得ることになります

00:14:50.640 --> 00:14:55.980
請求販売配送あるいは顧客サービスといった部門で紛争を生じさせているプロセスを修正する必要があるかもしれません

00:14:55.980 --> 00:15:04.860
回収業務では未払金額を未決済期間ごとに分類するエイジングレポートも活用されます 期限内または30日60日90日と経過日数に応じた未払額を確認することができます

00:15:04.860 --> 00:15:09.720
これらの期間区分によりチームは事態が深刻化して対応が困難になる前にどの再建に注意を払うべきかを把握できます

00:15:09.720 --> 00:15:15.380
支払いが2日遅れているだけの請求書と3ヶ月間未払いの請求書では同じ対応が求められるわけではありません

00:15:15.380 --> 00:15:25.660
財務部門は利用可能な場合は支払い予測機能を使用し過去の請求書の支払いデータや顧客データに基づいて未払い請求書の支払いが期限通りか遅れるか大幅に遅れるかを推定できます

00:15:25.660 --> 00:15:32.940
エイジングレポートは過去の状況を示すものですが予測機能を使えば支払い遅延が問題化する前にチームがどこに注力すべきかを判断できます

00:15:32.940 --> 00:15:35.280
それは判断にとって変わるものではありません

00:15:35.280 --> 00:15:40.240
多数の顧客アカウントから対応先を選択する必要がある際特速チームに新たな判断材料を提供します

00:15:40.240 --> 00:15:41.620
目標はシンプルです

00:15:41.620 --> 00:15:47.320
顧客を番号で管理するのではなく顧客として尊重しながら着実かつかし化された方法で入金を回収することです

00:15:47.320 --> 00:15:50.580
では一連の流れを一つの単純な例で見ていきましょう

00:15:50.580 --> 00:15:51.520
6つのステップ

00:15:51.520 --> 00:15:52.720
1つの請求書

00:15:52.720 --> 00:15:54.120
1つの連携プロセス

00:15:54.120 --> 00:15:55.280
そして全体像です

00:15:55.280 --> 00:16:03.080
ノースウィンド社が注文を行いシステムで処理され合意した請求ポイントに達すると請求書が発行されるまでの流れを確認しましょう

00:16:03.080 --> 00:16:10.600
顧客アカウントには支払い条件が保持されているためダイナミクス365がノースウィンド社との合意ルールに基づいて期日を自動計算します

00:16:10.600 --> 00:16:14.640
財務部門は未回収額を確認し顧客には明確な支払い依頼が届きます

00:16:14.640 --> 00:16:16.320
これがプロセスの始まりです

00:16:16.320 --> 00:16:19.780
数週間後ノースウィンド社から請求書番号が明記された銀行振込が行われます

00:16:19.780 --> 00:16:22.780
財務担当者は入金と請求書を称号し消し込み処理を行います

00:16:22.780 --> 00:16:26.980
未決済残高はなくなり顧客アカウント上でその取引が完了したことが示されます

00:16:26.980 --> 00:16:28.820
手作業による称号は不要です

00:16:28.820 --> 00:16:31.000
ではうまくいかない場合はどうなるでしょうか

00:16:31.000 --> 00:16:34.320
ノースウィンド社が支払い期日を過ぎると請求書は特速対象となります

00:16:34.320 --> 00:16:38.680
担当者が特速を送るとノースウィンド社から請求額の一部に誤りがあるとの回答があり

00:16:38.680 --> 00:16:41.460
チームはそれを単なる未払いではなく紛争として記録します

00:16:41.460 --> 00:16:46.280
全ての情報が一箇所に集約されているため全員が同じ状況を把握し次のアクションを認識できます

00:16:46.280 --> 00:16:49.020
これがダイナミクス365ファイナンスの違いです

00:16:49.020 --> 00:16:50.600
情報は分離されません

00:16:50.600 --> 00:16:56.140
受注、請求書支払い、予診管理、特速業務のすべてが同一の顧客関係に紐付いているため

00:16:56.140 --> 00:16:59.080
複数のシステム間で情報を追いかける必要はありません

00:16:59.080 --> 00:17:02.180
これにより意思決定が迅速化しミスも減ります

00:17:02.180 --> 00:17:06.880
従来の方法では情報がスプレッドシートやメール、紙のメモ、銀行ファイルに散らばり

00:17:06.880 --> 00:17:09.980
どの情報が正しいのかを確認する無駄な時間が発生していました

00:17:09.980 --> 00:17:15.000
ダイナミクス365は情報を一元管理し顧客の全体像をエンドツーエンドで把握できるようにします

00:17:15.000 --> 00:17:20.540
売掛金管理とは誰がいつ支払う必要があるのか、これまでのいきさつ、そして次に何をすべきかを正確に把握することに他なりません

00:17:20.540 --> 00:17:24.420
どこかが欠けていると会社は多くを売っても現金がどこにあるのか把握できなくなります

00:17:24.420 --> 00:17:27.380
だからこそこの一連の繋がったプロセスが重要なのです

00:17:27.380 --> 00:17:28.300
結論です

00:17:28.300 --> 00:17:30.560
内部の資金を管理下に置きましょう

00:17:30.560 --> 00:17:32.960
請求書はプロセスの始まりに過ぎません

00:17:32.960 --> 00:17:38.740
売掛金は残高が解消されるか、見払い分に対して誰かが対応するまで資金を追いかけていますか?

00:17:38.740 --> 00:17:42.640
その内部資金を管理下に置くことはビジネスの健全性にとって不可欠です

00:17:42.640 --> 00:17:43.880
ミルコ・ピーターズでした

00:17:43.880 --> 00:17:51.980
M365FMでマイクロソフトのナレッジマグネットを登録し、画面上のダイナミクス365ファイナンスの関連エピソードを見て、分かりやすい全体像を把握し続けましょう