WEBVTT

00:00:00.880 --> 00:00:08.700
仕入れ先からの請求書があなたのデスクに届きます 商品はすでに倉庫にあるかサービスは完了しているかもしれませんが支払いの期限はすぐに迫って

00:00:08.700 --> 00:00:12.000
きます では実際に会社からお金が出ていくまでに何が起きているのでしょうか

00:00:12.000 --> 00:00:19.420
m 365 fm のナレッジナゲットへようこそ私はミルピーターズです 今日はダイナミクス365の買いかけ金をわかりやすい言葉で解説します

00:00:19.420 --> 00:00:26.760
ここは単に誰かが画面に請求書を入力するだけの場所ではありません 会社の財務部門が各請求書を確認し誰が送ったか何を合意して購入したか

00:00:26.760 --> 00:00:33.960
そして支払うべきかを精査する場所です最もシンプルな定義はこうです 買いかけ金とはすでに購入した商品やサービスに対してあなたの会社が仕入れ先に支払う

00:00:33.960 --> 00:00:42.720
べきお金のことです大きな建物の中にある支払い窓口のようなものだと考えてください 請求書が受付に届き会社の記録と称号され承認を経てようやく支払い担当者の

00:00:42.720 --> 00:00:47.120
もとへたどり着きます 仕入れ先レコードから最終的な支払い済みのスタンプが押されるまでのプロセスを追っていき

00:00:47.120 --> 00:00:55.280
ましょうダイナミクス365ではこれを決済と呼びます なぜ買いかけ金が必要なのでしょうかあなたがオフィス家具を販売する小さな会社を経営していると

00:00:55.280 --> 00:01:03.820
想像してください机を売るためにはまず机が必要です さらに梱包箱清掃サービスインターネット回線交換部品そして配送会社も必要かもしれません

00:01:03.820 --> 00:01:11.060
注文の度にすべての仕入れ先に即時払いしなければならないとしたらものの購入はすぐに非常に 困難なものとなるでしょうほとんどのビジネスでは合意された条件の下で

00:01:11.060 --> 00:01:20.120
先に購入し後から支払います仕入れ先は商品やサービスを提供しその後に請求書を 送りますあなたの会社はその金額を支払う義務を負いますが内容を確認せずに送金することは

00:01:20.120 --> 00:01:28.960
ありませんその見払い金額は会社の帳簿上で負債として記録されます 負債は恐ろしい財務用語に聞こえるかもしれませんが意味は単純です会社が他社に支払う

00:01:28.960 --> 00:01:37.740
べき金額のことです事務用品の請求書を受け取ってまだ支払っていない場合 その請求書は支払いが完了するまで買いかけ金となります現時点では現金は手元に

00:01:37.740 --> 00:01:44.360
ありますが会社には果たすべき約束があるのです 銀行口座の残高が健全に見えても未払いの請求書が山積みになっている可能性があるため

00:01:44.360 --> 00:01:51.580
これは重要です財務チームは両方の側面を把握する必要があります 銀行にいくら現金がありそのうちのどれだけが近いうちに出ていく必要があるのか

00:01:51.580 --> 00:01:55.920
ということです 財務システムが統合される前この業務はしばしば紙の追跡作業になっていました

00:01:55.920 --> 00:02:03.840
請求書が郵送で届いてデスクに置かれ社内便で承認のために回される一方で別の 請求書はメールの受信トレイに眠っているといった状況ですある人が同じ請求書を

00:02:03.840 --> 00:02:11.360
スプレッドシートに入力し別の人が会計システムに入力してしまう可能性もありました それがよくある問題を引き起こすのですマネージャーが承認メールを見落としたり

00:02:11.360 --> 00:02:17.000
支払いが遅れたりあるいはサプライヤーから同じ請求書が再送されてもすでに経理チームに届いている ことに誰も気づかないといった状況が起こり得ます

00:02:17.000 --> 00:02:21.420
さらに悪いことに紙の請求書とメールの請求書が別々のものとみなされ 20に支払ってしまう可能性さえあります

00:02:21.420 --> 00:02:30.040
ダイナミクス365はこうした業務を一元管理するための場所を企業に提供します 会社が支払うべき金額を記録し請求書の確認を支援し請求書の到着から支払い完了までの明確な

00:02:30.040 --> 00:02:33.900
プロセスを維持します これはすべての請求書が人の確認なしで処理されるという意味ではありません

00:02:33.900 --> 00:02:40.400
異常がある場合は引き続き経理チームが判断しますがシステムが記録とルールを提供する ことで社内で紙の書類を追い回すことなく判断を下せるようになります

00:02:40.400 --> 00:02:47.220
同じ文脈で売りかけ金アカウントレシーバブルという言葉を耳にすることもあるでしょう 名前はよく似ていますがこれらは正反対の概念を指しています

00:02:47.220 --> 00:02:55.240
買いかけ金は仕入れ先に対する支払いのために会社から出ていくお金を管理するものです 売りかけ金は顧客から支払われるべきお金として会社に入ってくるお金を管理するものです

00:02:55.240 --> 00:03:04.060
会社がサプライヤーからプリンターを購入した場合その請求は買いかけ金として処理され ます会社が顧客にデスクを販売して請求書を送付した場合その顧客への請求は売りかけ金として処理されます

00:03:04.060 --> 00:03:11.060
つまり買いかけ金は支払うべきものを売りかけ金は受け取るべきものを管理するのです 買いかけ金管理の目的は極めて実務的な成果にあります

00:03:11.060 --> 00:03:17.740
正しい仕入れ先に正しい金額を合意された期日に支払うことです 支払いが早すぎれば会社は本来必要のない時期にキャッシュを失うことになります

00:03:17.740 --> 00:03:27.280
支払いが遅すぎればサプライヤーから特速を受けたり有利な取引条件を取り消されたり する恐れがあります金額を間違えて支払えば後でメールやクレジットノートのやり取りなど多大な労力をかけて

00:03:27.280 --> 00:03:35.160
ミスを修正しなければなりません そのため請求書がこのプロセスを通過する前にダイナミクス365が仕入れ先を正確に特定しその関係に適用される

00:03:35.160 --> 00:03:42.060
ルールを把握しておく必要があります 仕入れ先という基盤を構築するダイナミクス365で請求書を処理するにはまずその請求書が誰から送られて

00:03:42.060 --> 00:03:48.980
きたのかを正確に特定しなければなりませんそこで必要になるのが仕入れ先レコードです これがないとシステムは誰に支払うべきかどのようなルールに従うべきかを判断できません

00:03:48.980 --> 00:03:56.240
仕入れ先は紙やノートパソコン予備部品といった物理的な製品を提供するかもしれません あるいは経理やソフトウェアサポートのようなサービスを提供するかもしれません

00:03:56.240 --> 00:04:01.800
提供するものは違っても果たすべき役割は同じです いずれも会社が支払う必要が生じる可能性のある相手です

00:04:01.800 --> 00:04:10.400
仕入れ先レコードとはダイナミクス365における仕入れ先のファイルだと考えてください これには経理チームが必要とする基本情報が格納されるだけでなくその後の処理を制御するルールも設定されます

00:04:10.400 --> 00:04:18.240
仕入れ先の名前住所連絡先情報を入力することで会社は取引相手が誰であるかを正確に把握できる ようになります請求書や支払いに使用する通貨を記録することもできます

00:04:18.240 --> 00:04:25.800
これは様々な国の仕入れ先から購入する場合に大きな意味を持ちます 次に支払いの詳細についてですが仕入れ先レコードには支払い条件や支払い方法を含めることができます

00:04:25.800 --> 00:04:33.480
画面上の小さな項目に見えるかもしれませんがこれらは非常に実務的な疑問に答えるものです この仕入れ先への支払いはいつ行うべきかそして会社はどうやって送金すべきか

00:04:33.480 --> 00:04:39.760
支払い条件によって期日のルールが決まります 請求書発行日から30日後の支払いを認める仕入れ先もあれば14日以内の支払いを求める仕入れ先もあります

00:04:39.760 --> 00:04:46.960
早期支払いで割引を提供する仕入れ先さえあります ダイナミクス365は記録された条件を使用して各請求書の支払い期日を自動的に計算します

00:04:46.960 --> 00:04:55.380
誰も契約内容を記憶しておく必要はありませんこれにより一貫性が生まれます 同じ仕入れ先の請求書を5人の担当者が処理しても全員が同じ支払いルールに従います

00:04:55.380 --> 00:04:59.700
請求書の支払い時期を確認するために古いメールを掘り返したり 購買チームに電話したりする必要はもうありません

00:04:59.700 --> 00:05:06.240
支払い方法はその資金がどのように送金されるかを表します ある仕入れ先には電子振込で支払い別の仕入れ先には小切手で支払うといった対応が可能です

00:05:06.240 --> 00:05:14.680
場合によっては約束手形を使用する企業もあります ダイナミクス365では独自の支払い方法を定義でき必要に応じてシステム上のタイプと関連付けることができます

00:05:14.680 --> 00:05:21.260
さて企業は通常複数の仕入れ先と取引を行います 成長中の企業であれば数十数百あるいは数千もの取引先があるでしょう

00:05:21.260 --> 00:05:28.100
一つ一つゼロから設定を作成していては時間の無駄でありミスも招きます そこでダイナミクス365では仕入れ先グループを使用します

00:05:28.100 --> 00:05:36.440
仕入れ先グループは共通の広範な財務ルールを持つ仕入れ先をまとめるものです 例えば地元の事務用品業者を一つのグループに海外の仕入れ先を別のグループにまとめるといったことが可能です

00:05:36.440 --> 00:05:42.780
グループには取引の転記方法支払いや決済の仕組み 仕入れ先残高の報告方法などの共通設定が保持されます

00:05:42.780 --> 00:05:50.640
もちろん各仕入れ先のレコードは個別に維持されます 仕入れ先ごとに固有の名前住所支払詳細履歴が必要になるためこれは重要です

00:05:50.640 --> 00:05:55.860
仕入れ先グループは共通の出発点を提供するだけであり 経理部門は同じルールを何度も作り直す必要がなくなります

00:05:55.860 --> 00:06:02.260
舞台裏では仕入れ先転記プロファイルと呼ばれる別の要素が機能しています 名前は専門的ですが平易な言葉で説明しましょう

00:06:02.260 --> 00:06:07.700
転記プロファイルとは仕入れ先取引を相関上元町のどこに記録すべきかを ダイナミクス365に指示するマップのようなものです

00:06:07.700 --> 00:06:14.440
相関上元町は会社の主要な財務会計帳簿です 請求書が転記される際ダイナミクス365は会社が何を追っているのか

00:06:14.440 --> 00:06:21.020
そして関連するコストをどこに計上すべきかを記録する必要があります 転記プロファイルは仕入れ先や仕入れ先グループに設定したルールを使用して

00:06:21.020 --> 00:06:27.240
仕分けにおける仕入れ先側の処理をガイドします 財務担当者が毎回記憶を頼りに勘定科目を選択する必要はありません

00:06:27.240 --> 00:06:32.620
代わりにシステムがマッピングに従うため不整合な入力が減り 財務チームは仕入れ先債務をより正確に把握できます

00:06:32.620 --> 00:06:39.660
企業は請求書が届く前に支払いの準備も進めておきます 現金及び銀行管理において仕入れ先への支払いに使用する銀行口座を設定します

00:06:39.660 --> 00:06:48.080
支払い仕分け帳は承認済みの方法で支払いを準備及び記録するための作業場所となります まとめると仕入れ先レコードによって支払い先を特定します

00:06:48.080 --> 00:07:00.400
支払い条件で期日を決定し支払い方法と銀行口座で資金の支出方法を定めます これらのルールが準備されていれば請求書は財務部門に届き到着から承認までのプロセスを開始できます

00:07:00.480 --> 00:07:08.660
仕入れ先レコードが設定されていればダイナミクス365は支払い先と適用すべきルールを認識します では実際に請求書が届いたときはどうなるのでしょうか

00:07:08.660 --> 00:07:16.560
財務担当者が手入力することもありますこれはメール紙の書類または仕入れ先ポータル経由で請求書が届き 誰かが詳細をシステムに入力する必要がある場合に有効です

00:07:16.560 --> 00:07:26.560
担当者は仕入れ先を選択し請求書番号と日付を入力して明細金額税金及び請求に関連する発注番号を追加します 請求書番号には注意が必要です

00:07:26.620 --> 00:07:35.480
それは自社ではなく仕入れ先が発行するものであり特定の請求書を特定するために役立ちます ノースウィンドオフィスサプライズから1200ドルの請求書番号N148が届いた場合

00:07:35.480 --> 00:07:42.080
ダイナミクス365はその番号と仕入れ先レコードを称号して重複入力を防ぐことができます 添付書類もレコードと一緒に管理します

00:07:42.080 --> 00:07:52.360
pdf形式の請求書スキャンした文書または関連書類をダイナミクス365の請求書データと共に保存できます そのためレコードを確認する担当者は共有メールボックスやキャビネットを探し回ることなく

00:07:52.360 --> 00:07:57.920
数字の裏付けとなる文書を確認できます 件数が多い場合は請求書を電子的に取り込むことができます

00:07:57.920 --> 00:08:06.720
ダイナミクス365はデータエンティティを介した請求書データのインポートをサポートしています データエンティティとは他のシステムがダイナミクス365へ情報を送信する前に記入する標準的な

00:08:06.720 --> 00:08:11.440
フォームのようなものだと考えてください 例えば外部の請求書取り込みサービスを利用すればヘッダー情報

00:08:11.440 --> 00:08:20.740
明細および添付文書をすべて一つのデータパッケージとして送信できます ヘッダーには仕入れ先請求書番号日付通貨合計金額発注番号など請求書の主要な詳細が保持されます

00:08:20.740 --> 00:08:27.140
明細には請求内容の詳細が記載されます ある業はプリンター用紙別の業はトナーさらに別の業は配送料といった具合です

00:08:27.140 --> 00:08:33.360
詳細を分けて管理することで財務担当者は何を承認しているのかを正確に把握できます 税情報も請求書とともに引き継がれます

00:08:33.360 --> 00:08:41.100
企業が請求を正しく記録するためにダイナミクス365は税額と関連詳細を必要とします 請求書が確認なしに処理されないようにする要因がいくつかあります

00:08:41.100 --> 00:08:47.360
ベンダー情報の欠落無効な日付重複する請求書番号 合計金額の不一致などが挙げられますこの一時停止が会社を守ります

00:08:47.360 --> 00:08:56.200
ベンダー請求書ポリシーにより請求書が記者のルールに従っているかチェックされます 重複チェックでは同じベンダーや請求書番号がすでに登録されていないか確認します

00:08:56.200 --> 00:09:04.500
その目的はベンダーの過失を責めることではありません ベンダーは請求書が届いたか不安で再送する場合があります担当者が誤って同じ pdf を20に入力することもあります

00:09:04.500 --> 00:09:10.860
いずれにせよ同じ請求書の20払いは誰も望まない余計な作業を生みます ダイナミクス365が請求書を受け付けた後次の質問はシンプルです

00:09:10.860 --> 00:09:16.880
誰がそれを承認できるのでしょうかそこで登場するのがワークフローです ワークフローとはシステム内での承認経路のことです

00:09:16.880 --> 00:09:24.840
pdf をマネージャーにメールで送り返信を待つのではなく ダイナミクス365が記者のルールで指定された担当者や役割に請求書を送信します

00:09:24.840 --> 00:09:32.000
各組織は資金に関する決定をどのように管理したいかに基づいてルールを定めます 小規模な日常的な請求書は短い経路をたどるかもしれません

00:09:32.000 --> 00:09:38.800
一定金額を超える請求書には上級マネージャーの承認が必要になる場合があります 特定の部門に関連する請求書はその部門のマネージャーへ送信できます

00:09:38.800 --> 00:09:45.960
在庫供給業者サービスベンダー受け負い業者などベンダーの種類ごとに異なる 承認経路を作成することも可能です経路は人の記憶ではなくルールに従います

00:09:45.960 --> 00:09:53.300
これにより承認状況の追跡がはるかに容易になります 財務部門は請求書が審査待ちか承認済みかまたは詳細情報が必要かを確認できます

00:09:53.300 --> 00:09:57.940
承認者は請求書をチェックしそれが自部門に関連するものか 請求額が適切か判断できます

00:09:57.940 --> 00:10:05.480
すべてのルールを満たした請求書は自動的に先へ進みます ベンダーが特定されておりインポートされた詳細が完全でポリシーチェックを通過した場合です

00:10:05.480 --> 00:10:10.800
そうした請求書に対して毎回誰かが同じ基本的なチェックを繰り返す必要はありません その他の請求書は例外となります

00:10:10.800 --> 00:10:14.700
ベンダーアカウントが欠落しているかもしれません 請求書番号がすでに存在するかもしれません

00:10:14.700 --> 00:10:21.720
インポートされた業にエラーがあるかもしれません ダイナミクス365はそれらの請求書をインポート失敗リストに保持し財務担当者がエラーメッセージを確認して

00:10:21.720 --> 00:10:30.380
保留中の請求書を作成する前に問題を修正できるようにします 審査中もドキュメントは重要ですダイナミクス365の請求書ページには添付ファイルビューアーがあるため

00:10:30.380 --> 00:10:39.720
財務担当者は修正中のレコードの横で請求書の画像を確認できます 元の請求書に6000と書かれていたか8000と書かれていたかを確認するために画面を切り替える必要はありません

00:10:39.720 --> 00:10:46.240
自動化が日常的な処理を担います 疑問点への対応は人が行います承認は正しい人物が請求書の処理に同意したことを証明しますが

00:10:46.240 --> 00:10:53.680
ベンダーが注文内容や受領内容と完全に一致する金額を請求したことまではまだ証明しません そのためにダイナミクス365は書類を称号します請求書称号です

00:10:53.680 --> 00:11:02.960
会社が何を発注したかを確認し承認によって適切な担当者が請求書を確認したことを保証します しかし称号は別の問いに答えるものです請求書の内容は会社が実際に購入に合意したものと一致しているでしょうか

00:11:02.960 --> 00:11:10.260
購買が発注書から始まる場合ダイナミクス365には称号用の記録が存在します 発注書は会社の注文伝票のようなものだと考えてください

00:11:10.260 --> 00:11:18.660
そこにはベンダー要求した品目数量価格条件が記録されます 請求書が届く前に購買担当者がその注文を作成しますなぜこれが重要なのでしょうか

00:11:18.660 --> 00:11:24.400
発注書は請求書が届く前に合意内容を記録しておくものだからです それがなければ財務担当者はベンダー名が書かれた請求書を見るだけになります

00:11:24.400 --> 00:11:30.460
発注書があればサプライヤーの請求額を当初の要求内容と照らし合わせることができます 物理的な商品についてはもう一つ重要な記録があります

00:11:30.460 --> 00:11:38.280
配送品が届くと倉庫チームが製品受領書を記録します これは商品が会社に届いたこととその数量を示すダイナミクス365内の証拠となります

00:11:38.280 --> 00:11:44.900
すべての品目が完璧であったことを意味するわけではありませんが発注に対して何が受け取られたかを記録します ある会社がオフィスチェアを10客注文したと想像してください

00:11:44.900 --> 00:11:51.580
発注書には合意価格で10客と記載されていますがトラックが到着した際 倉庫では2客がバックオーダー入荷待ちとなっているため8足しか確認できません

00:11:51.580 --> 00:11:56.940
受領チームは8客分の製品受領書を計上します その後サプライヤーは10客分の請求書を送付します

00:11:56.940 --> 00:12:02.780
サプライヤーの視点では残り2足の出荷前に注文全体を請求することは正しいかもしれません しかしこれで記者には差異が生じました

00:12:02.780 --> 00:12:09.380
10客注文し8客受け取り10客分を請求されたのです ダイナミクス365は請求書称号を通じてその際を検知できます

00:12:09.380 --> 00:12:19.180
2社間称号は発注書とベンダーの請求書を比較し請求金額や数量が注文と一致しているかを確認します これは当初の注文内容を確認するだけで十分な管理ができる購入に適しています

00:12:21.580 --> 00:12:27.840
請求してきた場合は検知できますが発注書と請求書の2つの記録しか比較しないため 商品が実際に届いたかどうかは確認できません

00:12:27.840 --> 00:12:35.460
3社間称号ではこれに製品受領書が加わります そのためダイナミクス365は発注書製品受領書請求書をまとめて比較します

00:12:35.460 --> 00:12:45.120
先ほどの椅子の例ではシステムは10客の注文8客の受領10客の請求書を確認します そしてその際は請求書の処理をそのまま進めるのではなく一時保留にする理由となります

00:12:45.120 --> 00:12:55.720
在庫や設備あるいは大量の物理的な商品を扱う企業にとってこのチェック機能は 未着の品物や受領主体以上の数量に対して支払うことを防ぐため財務部門により強力な管理能力を提供します

00:12:55.720 --> 00:13:01.440
購買は合意内容を確実なものにします 入庫担当は届いた品を確認し仕入れ先からの請求書は支払いを要求します

00:13:01.440 --> 00:13:07.300
おっと3つの記録はすべて整合性が取れている必要があります 実際の業務では小さな差異が生じることは避けられません

00:13:07.300 --> 00:13:17.080
単数処理で価格が異なったり仕入れ先が許容範囲内の数量変更を行ったりする場合です わずかな際で請求書が止まってしまうと経理チームは些細な問題の解消に追われてしまいます

00:13:17.080 --> 00:13:27.960
そこでダイナミクス365では企業が商合ポリシーと許容範囲を設定できるようになっています 許容範囲とは認められる際のことで企業は価格数量合計関連費用に対して受け入れ

00:13:27.960 --> 00:13:34.820
可能な金額や割合を決定します その範囲内のものは会社のルールに従って処理され範囲を超えるものは確認対象としてフラグが立てられます

00:13:37.300 --> 00:13:44.580
高価な事務用品には小さな差異を許容し高価な機械類には厳しい制限を設けるといったことが可能です 何が妥当かを判断するのはシステムではありません

00:13:44.580 --> 00:13:51.740
財務部門と購買部門がルールを定めダイナミクス365が一貫してそれを適用します これにより経理チームの時間の使い方が変わります

00:13:51.740 --> 00:14:00.500
すべての正常な請求書を1行ずつチェックする代わりに例外的なものに集中できます 価格の変更受領書の欠落数量の不一致などがある請求書の調査です

00:14:00.500 --> 00:14:07.120
正常な請求書は自動的に処理され人は判断が必要な場所に注意を向けることができます それこそが称号機能の真の価値です

00:14:07.120 --> 00:14:13.080
システムがルーチンチェックを処理し人間が判断を要する問題に対応するのです これはシステムが人間の判断にとって変わるということではありません

00:14:13.080 --> 00:14:17.780
日常的なチェックと検討が必要な課題を仕分けるということなのです 1点混乱を招く可能性があります

00:14:17.780 --> 00:14:28.140
標準のダイナミクス365の称号機能は2方向および3方向の称号に対応しています 検査記録のような別のチェックを追加する4方向称号などが必要な場合はカスタマイズや別のソリューションでの対応が必要です

00:14:28.140 --> 00:14:36.460
称号には明確な役割があります はい仕入れ先の請求書と自社の購買入庫記録を照らし合わせ支払い前に相違点を指摘することです

00:14:36.460 --> 00:14:44.080
請求書が確認と称号チェックを通過するとそれは支払うべき債務となり 仕入れ先への支払いや帳簿の整理が可能になります

00:14:44.080 --> 00:14:49.200
請求書が会社で定めたチェックを通過した後 ダイナミクス365で転記を行うことができます

00:14:49.200 --> 00:14:56.820
転記とは請求書が公式な財務記録となることで会社は仕入れ先への負債を計上し 支払いが完了するまで未払いとして表示されます

00:14:56.820 --> 00:15:03.680
請求書の準備は整いましたが即座に資金が移動するわけではありません 経理チームは支払い実行でどの請求書を支払うかを決定する必要があります

00:15:03.680 --> 00:15:11.340
ダイナミクス365は支払い提案機能で支援し 期日を迎えた請求書を確認して会社が選択したルールに基づき支払うべきものを提案します

00:15:11.340 --> 00:15:20.080
支払い提案はあくまで開始リストであり最終的には人が確認を行います 仕入れ先への支払い期限が今週のものもあれば契約条件に従って月末まで待てるものもあるでしょう

00:15:20.080 --> 00:15:26.080
財務チームは支払い予定の請求書を確認し必要に応じて項目を追加または削除してから 支払い仕分け帳を作成します

00:15:26.080 --> 00:15:33.360
このように支払いをグループ化して管理することでバラバラに送金する事態を防げます 支払い仕分け帳は会社における支払いのワークシートだと考えてください

00:15:33.360 --> 00:15:41.620
そこには会社が送金予定の仕入れ先への支払い明細金額支払い詳細が記載されます 財務担当者はこれを利用して請求書ごとにバラバラに送金して記録が共有されない状態を避け

00:15:41.620 --> 00:15:45.400
管理された一括支払いを作成します では資金はどのように送金されるのでしょうか

00:15:45.400 --> 00:15:55.180
それは仕入れ先と自社で設定した支払い方法によって決まります ダイナミクス365では独自の支払い方法を作成し小切手電子支払い約束手形といった支払いタイプと関連付けることができます

00:15:55.180 --> 00:15:59.920
小切手は馴染み深いものです 電子支払いは銀行のプロセスを通じて資金を送金します

00:15:59.920 --> 00:16:08.740
約束手形は合意した条件の下で支払うという正式な約束を記録するものです 全ての企業が全ての方法を使うわけではありませんがダイナミクス365なら利用する手段を記録できます

00:16:08.740 --> 00:16:18.300
各支払い方法は適切な会社の銀行口座に関連付ける必要があります この紐付けは重要です企業は法人間通貨または支払い目的ごとに異なる口座を持つことがあるからです

00:16:18.300 --> 00:16:26.360
財務部門が支払いを作成する際システムはどの銀行口座から資金を出すかを把握する必要があります そうでなければ担当者が正しい支払い金額を作成しても誤った口座から引き落とされる可能性があります

00:16:26.360 --> 00:16:32.920
支払いのタイミングにも注意が必要です 期日を過ぎて支払うと特則やトラブルまたは仕入れ先との関係悪化につながる恐れがあります

00:16:32.920 --> 00:16:42.820
早すぎる支払いは本来出す必要のないタイミングでキャッシュを流出させてしまいます ダイナミクス365は請求書の期日を常に表示するため財務部門は各仕入れ先との契約条件に基づいて

00:16:42.820 --> 00:16:49.600
支払い計画を立てることができキャッシュの流出をより適切に管理できます ダイナミクス365はあるシンプルな問いに答える必要があります

00:16:49.600 --> 00:16:57.420
その支払いはどの請求書に対するものかその答えが決済消し込みです 決済とは支払いをそれに対応する特定の仕入れ先請求書と紐付ける作業です

00:16:57.420 --> 00:17:04.740
領収書を生産対象の請求書と称号する作業だと考えてください 決済を行わなければ仕入れ先のアカウントに請求書と支払いが存在していてもそれらが

00:17:04.740 --> 00:17:10.480
互いに関連しているという明確な記録が残りません 全額支払えば請求書も全額決済されますがビジネスは常にそれほど単純ではありません

00:17:10.480 --> 00:17:18.380
請求書の一部を先に支払い残りを後で支払う場合もあります 決済は一部の支払いを記録し残高を未決済のままにすることで仕入れ先への未払い額を財務部門が正確に

00:17:18.380 --> 00:17:22.060
把握できるようにします この可視性は仕入れ先の残高を正確に保つために不可欠です

00:17:22.060 --> 00:17:28.820
1回の支払いで複数の請求書をまとめて決済することも可能です 例えばある企業が同じ仕入れ先からの5つの期限到来済みの請求書を1回の電子決済で

00:17:28.820 --> 00:17:37.240
支払うとします決済処理はその1回の支払い金額を消し込まれる各請求書に紐付け ます支払い額が全ての請求書を完全にはカバーしない場合でも未決済残高は不明瞭な

00:17:37.240 --> 00:17:42.740
合計額に紛れることなく明確に保持されます これにより追跡可能な記録が作成され請求書の承認から

00:17:42.740 --> 00:17:47.880
称号結果までをたどることができます 仕分け帳で準備された支払いを確認しその支払いがどのように仕入れ先の

00:17:47.880 --> 00:17:53.320
残高を消し込んだかを確認できます なぜ資金が流出したのかを尋ねられた際経理部門がメールや銀行明細から

00:17:58.820 --> 00:18:04.480
ことがありますが各レコードは一つの管理された流れとしてつながり 買いかけ金管理の全体像を形成します

00:18:04.480 --> 00:18:10.080
オフィス用品の請求書を1枚受け取ったと想像してください 仕入れ先レコードには支払いルールが保持されており

00:18:10.080 --> 00:18:15.420
インポートされた請求書には詳細とドキュメントそのものが含まれています 購買部門が発注書を提供します

00:18:15.420 --> 00:18:19.680
受け入れ部門が受領書を提供するため 称号プロセスでは比較対象となる未データが揃います

00:18:19.680 --> 00:18:28.760
そして裏側では転記プロファイルが不採と経費を正しい相関上元帳へ計上します 現金及び銀行管理機能が使用する支払い方法と相関根元の銀行口座を制御します

00:18:28.760 --> 00:18:33.940
添付ファイルは取引に紐付いたまま保存されるため 後からいつでも元の請求書を呼び出して確認できます

00:18:33.940 --> 00:18:50.680
自動化は経理チームの判断にとって変わるものではありません 熱

00:18:50.680 --> 00:19:10.100
熱