「WA: Financier」における企業の支払カレンダーと支払スケジュールとその例。支払いカレンダー - 業務財務管理ツール支払いカレンダー 1 秒以上

「1C: Accounting 8」の支払いカレンダーには次のように表示されます。

計画された金銭的収入販売された商品、実行された作業、提供されたサービスなど。
計画された計算サプライヤーとの関係、賃金の支払い、予算への貢献など。
支払いが遅れたサプライヤーおよび請負業者、顧客、従業員、規制当局などと。
途中で現金– 送信されましたが、受信者のアカウントに入金されませんでした。
口座残高期間の初めと終わりに。

資金の入出金予定日は、予定日をもとに「入金カレンダー」に表示されます。受領予定日は、顧客への請求書および商品、作品、サービスの販売に関する書類に記載されています。消費予定日は、サプライヤーからの請求書および商品、作業、サービスの受領書に記載されています（図 1-1.1）。

支払い予定日を指定しない場合、ドキュメントのデータは支払いカレンダーに含まれません。

図 1-1.1 - 一次文書の支払予定日

予想される支払いに関するデータは、 「お支払いカレンダー」支払いまで、つまり文書の作成と実行の前に 「当座預金口座への入金」または 「現金受領書（レジにて）」, 「当座預金口座からの取り崩し」または 「現金引き出し（レジから）」。一部返済した場合、「お支払いカレンダー」の表部分に残債額が表示されます。

計画機能を使用するには、セクションの適切なボックスにチェックを入れます。 「プログラム機能」(図2)。

図 2 - 支払い計画の設定

セクションを通じてサプライヤーとバイヤーの支払い条件を設定できます。 "管理"サブセクション内 「会計パラメータ」(図3-3.1)。会計パラメータで設定された期限は、商品、作業、サービスの受領/販売に関する特定の請求書または文書ごとに変更できます。

図 3-3.1 - バイヤーとサプライヤーに対する計画的な支払い条件の設定

支払いカレンダーへのアクセスは、セクションから提供されます。 「マネージャーさんへ」グループで 「企画」(図1)。支払カレンダーは、日数で指定された任意の期間に対して生成されます。「組織」ディレクトリから選択できます。各セクションは対応する色で強調表示されるため、レポートの表部分を操作するときに便利です。

図 4 - 支払いカレンダーフォーム

企業の現金口座と現金以外の口座に関する現金残高に関する情報を取得するには、次のハイパーリンクをたどる必要があります。 「残りのお金」。アクセスするとフォームが開きます 「現金残高」現在の日付 (図 5) には、現金口座、その配置、通貨のコンテキストで情報が表示されます。

図 5 - 現金残高の表示

1C: Accounting 8 エディション 3.0 の支払いカレンダーには、次のセクションが含まれています。

購入者からの支払い

このセクションには、予想される現金受領書 (CA) に関する情報が表示されます。情報源は次のシステムドキュメントです。

購入者への請求書;
販売（行為、請求書）;
制作サービスの提供。
固定資産の譲渡。
無形資産の譲渡。

「支払カレンダー」の作成期間の開始時点での負債が残高に表示されます（図6）。

図6 - 負債と顧客との相互決済による予定収入に関する情報

「顧客からの支払い予定」フォームに移動すると、顧客への支払い期限超過および予定されている支払いに関する詳細情報を確認できます (図 7)。

図 7 - 購入者からの支払い予定額の表示

注記！一連の文書が 1 つのビジネストランザクション (たとえば、購入者への請求書 - 販売 (行為、請求書)) に対して異なるデータまたは同一のデータで反映された場合、「購入者からの支払い予定額」フォームを生成するときに、その金額が反映されます。さまざまな文書に従って数回。この場合、支払いカレンダー自体には、チェーン内の最初のドキュメントの情報に従って金額が反映されます。

たとえば、カウンターパーティ「BAR Dionysus」の場合、2 つの文書がプログラムに入力されました。

買主への請求書は RUB 102,500.00、期限は 2017 年 6 月 28 日です。
売上額（行為、請求書）は99,000.00ルーブル、支払い期限は2017年6月29日です。

「支払いカレンダー」の情報は、購入者への請求書 102,500 ルーブルの文書に反映されます。 (チェーンの最初のものであるため)。同時に、「顧客からの支払い予定」フォーム (このフォームは支払いカレンダーから呼び出されます) には、2 つの文書に従って、日付が異なる両方の金額 (102,500 ルーブルと 99,000 ルーブル) が反映されます。

フォームでは、取引相手への支払い条件を変更できます。これを行うには、テーブルセクションで取引相手を選択し、をクリックする必要があります。 「支払い期限の変更」。期限を変更したら「OK」ボタンをクリックしてフォームを更新してください。

線分をダブルクリックします 「購入者からの支払い予定」表示および編集するためのベースドキュメントが開きます。

の形で 「購入者からの支払い予定」支払い遅延について取引相手に通知するには、「通知」ボタンを使用します。このボタンをクリックすると、支払督促状を含むレターが取引相手に作成されます。

その他の供給品

このセクションには、決済カードを介した輸送中の資金、送金、販売に関する情報が表示されます (図 8)。情報源は以下の文書です。

PKO および RKO と文書タイプ "コレクション".
ビューを使用した当座預金口座からの借方 「その他の損金算入」。会計口座 57.22 または 57.02。
「小売売上高レポート」「自動販売時点管理 (小売店) への支払いカードによる販売商品の支払い」というビュー。

図 8 - その他の収入の表示

税金と手数料

このセクションには予算への支払いが含まれます。情報源は納税業務です。 "タスクリスト":

税金。
料金;
保険料。

タスクは、未払税、作成された申告書、レポートに基づいてシステム内で自動的に作成されます (図 9)。

図 9 - 税金と寄付に関する情報の表示

税金および拠出金の支払い期限は、現在の法律の規定に従って表示されます。

注記！支払いカレンダーには、累積残高の税金負債の全額 (期限超過 + 予定) が表示されます。

図 10 - タスクとそのステータスのリストの表示

支払金額が確定していない場合は、表部分に「－」記号が表示されます。この場合、セルには支払い金額を決定するために必要な情報が含まれています。セルをクリックするとフォームが開き、対応する税金の計算と支払いが表示されます (図 11)。

図 11 - 所得税の計算と支払いに関する情報

サプライヤーへの支払い

このセクションには、サプライヤーへの計画的な支払いに関する情報が含まれています。情報源は以下の文書です。

サプライヤーからの請求書。
領収書（領収書、請求書）。
追加の受け取り経費。
NMAの受け取り。

期限を過ぎた支払いに関する情報は期首残高に表示されます (図 12)。

図12 - 「支払いカレンダー」におけるサプライヤーとの相互決済情報

注記！あるビジネス取引について、 一連の文書が反映される(例: 「購入者への請求書 - 販売」)、ただし、これらは ドキュメントは互いに関連性がありません（つまり、「基準に基づいて」ではなく、個別に入力された場合）、「支払いカレンダー」には、すべての文書で指定されたデータが反映されます。それらの。多分 1 つの取引の記録の重複.

また 削除対象としてマークされた支払い注文は「支払いカレンダー」に表示されます。文書間の関係は、文書ログから確認することも、「リンクされた文書」フォームを使用して文書自体から確認することもできます。

請求書の支払いがデータベースに表示され、支払い金額全体に対して伝票「当座預金からの償却」が入力されている場合、請求書にはステータス「支払い済み」が割り当てられ、支払いカレンダーには表示されません。ただし、文書「現在のアカウントからの消込」が削除対象としてマークされている場合、アカウントは「支払い済み」ステータスのままとなり、支払いカレンダーには反映されません。このような場合、請求書を支払いカレンダーに反映するには、請求書のステータスを手動で「未払い」に変更する必要があります。

「サプライヤーへの支払い」フォームへの適切なハイパーリンクをクリックすると、支払い期限超過および支払い予定に関する詳細情報を確認できます (図 13)。

図 13 - サプライヤーへの支払いに関する情報の表示

同じフォームで、取引相手または取引相手グループの支払条件を変更できます。これを行うには、適切な取引相手を選択し、「支払期限の変更」ボタンをクリックする必要があります。期限を変更したら「OK」ボタンをクリックしてフォームを更新してください（「更新」ボタンをクリック）。

「サプライヤーへの支払い」行をクリックすると、対応する基本文書が開き、表示および編集できます。

の形で 「サプライヤーへの支払い」ボタンをクリックすると支払い注文を作成できます 「支払い命令を作成する」。このボタンをクリックすると、支払い注文が表示され、編集できるようになります。

取引相手のグループに対する支払い注文を作成すると、プログラム画面のフォームに仕訳帳が表示されます。 「為替」。仕訳帳では、関連する取引相手に対して作成済みの支払注文を開いて編集できます。

「支払カレンダー」の表形式の部分から、サプライヤーへの債務が反映された文書を開くことができます。

給料

このセクションは、未払未払賃金の残高に基づいて記入されます（図 14）。情報源は給与支払業務です。 "タスクリスト"。タスクはドキュメントに基づいてシステム内で自動的に作成されます 「給与計算」.

図 14 - 給与情報の表示

給与の支払時期は、現行法の規定に従って表示されます。

図 15 - 給与支払タスクの表示

注記！タスクのリストには、データベースに文書がない場合でも、給与支払いが行われるはずだったすべての月の給与未払い額が表示されます。 「給与計算」.

文書「X 月の給与」に削除マークが付けられていた場合、タスク一覧から文書「X 月の給与」から「X 月の給与」に移動すると、削除マークが自動的に解除されて転記されます。

「X 月の給与」という文書が転記されていない場合、タスクリストから「X 月の給与」に切り替えると、「X 月の給与」という文書が自動的に転記されます。

「X 月の給与計算」という文書が作成されていない場合、タスクリストから「X 月の給与」に切り替えると、「X 月の給与計算」という文書が自動的に作成され、転記されます。

給与支払予定額が表示されているセルをクリックすると、給与の計算と支払い、個人所得税の支払いを表示するフォームが開きます（図16）。

図 16 - 給与計算と個人所得税支払いの表示

定期支払い

このセクションは、定期的な支払いのルールに従って形成されたタスクに基づいて入力されます。ここには、家賃、公共料金などの通常の支払い (義務的な支払いや給与を除く) が表示されます。 (図17)。

興味がある支払いスケジュール 1C: 会計?

このプログラムの購入と実装の詳細をご覧ください。

実装について話し合う

1. はじめに

資金計画は、財務会計とは対照的に、管理会計の主要なタスクの 1 つです。

もちろん、経営と会計の間には他にも大きな違いがあります (分析の要件、資産/負債の評価と再評価の要件、引当金の作成の必要性など) が、計画の問題を解決する必要性が最も困難です。彼ら。
計画の複雑さは、計画の準備 (計画の計算、さまざまなシナリオに従って計画を立てる) だけでなく、次のことも必要です。

再スケジュールを実行します。
計画を更新し、調整を次の期間に転送します。
計画、つまり事実の分析を実行します。

ほとんどの企業 (自動化に 1C を使用している) では、計画がプログラムで実行されていないことを認識する必要があります。
「会計を確立すべきだ...」 - これが多くの人が主張する方法です。

確かに会計処理は改善する必要がありますが、計画を犠牲にしてはいけません。
もちろん、彼らは今でも計画を立てています（ただし、1C ではなく XLS です）。そして、一番最初の主要なタスク (彼らが解決しようとしているのは) は資金計画です。

(1) 戦略的 (予算編成)。
(2) 動作可能。

また、XLS を使用して予算編成 (もちろん計画に対するトップダウンのアプローチで) を実行できる場合、運用計画は実行できません。
肝心なのは、ほとんどの場合、予算表を扱うのは最小限のユーザー (1 ～ 2 人) であるということです。ほとんどの企業では、予算項目やその他の分析の数はそれほど多くありません。つまり、XLS ではすべてを手動で処理できます。

しかし、D/S の運用計画に関しては、状況が異なります。つまり、支払わなければならない請求書が大量にあること、定期的な支払いが多数あること、顧客の注文に対する支払いが予想されることなどがよくあります。

さらに、これらすべては、プログラムのさまざまなユーザーが作業したり、文書が調整されたり、状況が変化したりする多数の主要文書に「結び付けられる」可能性があります。

運用計画と予算編成のもう 1 つの重要な違いは、それがボトムアップで行われることが多いことです。それは、部門の従業員が常に記入する「D/S経費の申請書」からです。

したがって、これらの申請は時間通りに処理され、承認/拒否され、「スケジュール」され、支払いが行われる必要があります。

合計： D/S の運用計画は 一番最初の計画タスク、どの企業でも 1C で自動化する必要があります。

そして計画の結果、財務部門/財務省はシステム内で次のことを「確認」する必要があります。

いつ、誰に、どの銀行口座/現金から、いくら支払わなければならないか。
現在の残高、予定されている支出、現金の受け取りを考慮して、「これこれ」の日の現金残高はいくらになるでしょうか。いわゆるものは避けなければなりません。「現金格差」
つまり、支払いカレンダーを操作する必要があります。
計画された支払い、受け取り、相互決済の現在の残高を考慮して、指定された日に取引相手との債務がどのようになるか。
つまり、計算カレンダーを使用する必要があります。

この記事の目的 – DC の運用計画を自動化する可能性について話します。同時に、3 つの異なる循環構成の比較分析が実行されます (2 つは 1C の標準、1 つは会社の wiseadvice の特殊化)。

各構成は運用計画の問題を解決するために使用できますが、プロジェクトの範囲と規模に基づいてバランスの取れた選択を行う必要があります。

2. ソフトスターターの特長 1.3

現時点では、1C は待望の UPP の新版 (改訂 2) をまだリリースしていません。このため、私たちは利用可能なもの、つまり SCP 1.3 の対応するサブシステムに焦点を当てます。

サブシステム「現金支出要求」は比較的最近 (2011 年) に構成で更新されたことに注意してください。その結果、マネージドインターフェイスモードでは、セクションパネルに「リクエストの支払い d/s/」という項目が表示されました。

標準構成のファイルモードでドキュメントフォーム「D/S Expenses のリクエスト」(別名 ZRDS) を開こうとすると、汎用モジュール「Working with」の変数「Global Values」に対してエラーがすぐに表示されます。一般変数」。

しかし、「沈殿物は残っている」と言われているように、そのような間違いは修正することができます。つまり、UPP ZRDS サブシステムには十分な「粗さ」があります。
WEB ブラウザを通じて ZRDS ドキュメントを作成できる機能は便利ですが、実際には、ドキュメントの標準形式の簡素化と人間工学について慎重に考慮する必要があります。これはモバイルデバイスにとって特に重要です。

ただし、支払いカレンダーに関しては、シンクライアントモードで、WEBブラウザなどを介してリモートで実行されます。使用できなくなります。その理由は、資金管理サブシステムが長期間更新されておらず、特に支払いカレンダーレポートがデータ構成システムに基づいて構築されていないためです。したがって、このレポートはシンクライアントでは使用できず、カスタム設定を作成することもできません。

ZRDS を使用する場合、申請の調整と承認に関する規制が重要な位置を占めます。企業の組織構造やその他のビジネスの特徴によっては、申請を承認するための内部手順 (承認規則) が非常に複雑になる場合があります (多段階、可変など)。したがって、これを自動化するのは簡単な作業ではありません。

UPP では、調整および承認サブシステムが実装されています。非常に柔軟な設定が可能です。

承認は、申請に対する支払いの必要性の確認です。通常、承認は会社の部門長、マネージャー、その他の責任者を経由する必要があります。
承認は、申請書が支払われるという（財務担当者による）最終確認です。この場合、支払日および支払が行われる銀行口座/現金取扱所を決定する必要があります。したがって、支払いは運用計画 (支払いカレンダー) に含まれます。

ソフトスターターの標準機能の多くの側面は、サブシステムの実際の実装に必要なものを提供していないことに注意する必要があります。
これらの「瞬間」については後で書きますが、ここでは一般的な構成がどのような機能を提供するかを見てみましょう。

アプリケーション承認メカニズムの使用を組織ごとに個別に有効にすることができます。

ルートおよびルートの階層を通じてアプリケーションのシーケンスを構成できます。

部門ディレクトリ内の階層は、アプリケーションルーティングメカニズムでは考慮されないことに注意してください。
また、調整と承認がビジネスプロセスメカニズムを使用せずに技術的に構築されたことを取り消す必要もあります。

各時点で、アプリケーションを承認できる 1 人または複数のユーザーを指定できます。つまり、アプリケーションはどのユーザーでも (最初に承認した人が) 承認できます。

部門ごとに、対応する承認ルートポイントを割り当てることができます。これの本質は次のとおりです。申請書 (ZRDS) に記入する際には、中央連邦管区 (部門) を指定する必要があります。そして、指定された部門に応じて、UPP は対応する承認ポイントを「見つけて」、そのポイントに承認申請を「送信」します。

承認ルート設定時に部門を指定しないことも可能です。この場合、そのような調整ポイントは、対応するルートポイントが特に指定されていないすべての CFD に「適用」されます。

承認自体は「申請承認」という特殊な処理を用いて行われます。

計画された資金の利用可能性、支払いスケジュール、現金不足の追跡の分析は、「支払いカレンダー」レポートで実行されます。

d/s の計画消費 (ZRDS) に加えて、d/s の計画受け取りも考慮することができます。これらの目的のために、特別な文書「収入計画書」を作成することが想定されています。

「計画された文書の受領」という文書には状態（準備済み、合意済みなど）があるものの、この文書（およびZRDS）を調整する機会がないことに注意する必要があります。つまり、ドキュメントのステータスの変更は「手動制御」モードでのみ可能です。

そしてUPPでは、「現金受領計画」という書類を準備することなく、買い手からの現金受領計画を考慮することが可能です。

つまり、「顧客注文」が購入者に対して発行された場合、別のレポート「注文を考慮した支払いカレンダー」でこの計画された受入を確認できます。

支払いカレンダーレポートに加えて、現金利用可能性分析レポートもあります。

同時に、（経費の申請に基づいて）資金を予約したり、計画収益に対して申請を行うことも可能です。

ZRDS をクローズしたり、d/s からの計画収入を得る機能もあります。この目的のために、「通常のクライアント」モードでは、「支出/領収書の締め切り申請書」という文書が提供されます。

ただし、この機能はシン/Web クライアントモードでもサポートされません。
ここで、「ハード予約」テクニックは文書入力の時間軸と強く結びついているため、調整や再スケジュールが困難になることを理解する必要があります。

したがって、この機能は「過去の遺産」として UPP に残されており、支払いカレンダーを使用して d/s の利用可能性を分析する必要があります。

そこで、ソフトスターターの機能について検討してきました。次に、実際にプロジェクトで変更する必要がある標準構成の側面をリストします。

文書「D/S支出申請書」によると：
1. 文書では、「部門」を指定できます（ちなみに、構成では、中央連邦管区 - 財務責任の中心として指定されています）。しかし、申請が 1 つの部門 (CFD) から提出される可能性は十分にあり、この場合、費用はさらに別の部門 (CFD - 財務管理センター) に帰属/配分される必要があります。
  デジタル機能などを指定可能 - 不在。
  ルートを変更したり、アプリケーションを他のルートにリダイレクトしたりする機能はありません。

当座預金口座間、口座から現金窓口などへの現金の移動を計画することはできません。

契約プロセス:
1. ZRDS を調整することは可能ですが、計画された d/s の受け取りを調整することはできません。
2. 実際には、他の従業員の承認を行う必要があります。同時に、「誰が、誰に対して承認を行ったのか」という情報もシステムに記録する必要があります。
  1 つの調整ポイントに複数の実行可能プログラムをインストールするオプションは、多くの場合適切ではないため、この実行プログラムは調整の他の段階で指定できます。その結果、これらすべてが、従業員が承認リクエストのリストに主要な承認タスクと間接的な承認タスクの両方を同時に持つことになるという事実につながります。もちろん、これはユーザーを混乱させ、不便です。
  要約すると、他の出演者を調整する能力、誰が誰に調整する権利を持っているかを示す能力が欠如しています。
3. 申請の承認プロセスにおいて、申請がルート上の次の承認に引き継がれる際に、申請の作成者だけでなく次の実行者にも自動的に通知（メール）する機能が求められます。。
4. アプリケーションの作成者が既に (ルートのどの段階でも) 調整/承認の責任を負っている場合、プログラムが自動的にルートを「短縮」し、アプリケーションを利用可能な最高レベルにリダイレクトするのは非常に論理的です。ただし、これは UPP では規定されていません。
- 上記の要件はすべて、標準構成には含まれていませんが、それでも満たされます。

レポート、アクセス権。
1. アプリケーションへのアクセスを、利用可能な作成者/実行者 (コーディネーター) のみに制限できる可能性が求められています。ユーザーが利用できる部門ごとに。
2. 実際の債務と計画された債務の監視（日数および間隔による）に関する報告はありません。これはバイヤーとサプライヤーの両方に当てはまります。
3. レポートおよび一部の機能は、シン/Web クライアントモードでの作業には適していません。
定期的な契約と契約の会計処理。
1. サプライヤーに定期的に支払う必要がある状況がよくあります。例えば、家賃の支払いなどです。
  UPPでは支払いカレンダー等に自動反映されません。今後の出費です。つまり、そのような支払いを手動で追跡し、支払い要求に記入する必要があり、不便で時間がかかります。
2. バイヤーおよびサプライヤーとの契約では、前払いの割合、支払い条件などの条件が規定される場合があります。
  UPP はこのすべての情報を自動的に記録するわけではないため、(結果として) 支払いカレンダーに自動的に反映されます。

3. UT11.1の特徴

新しい構成「Trade Management Rev.11」のリリースにより、業務計画と財務管理のタスクに多くの便利な新機能が登場しました。
おそらく、UT11 のこの部分で (UPP 1.3 と比較して) 最も重要なことは、支払いスケジュールを考慮するメカニズムです。このメカニズムは、定期的な契約や契約に基づく計画/会計の自動化という、ひどく欠けていたものを「埋める」ものです。

したがって、UT11では経費や領収書を計画するための書類を作成する必要はまったくありません（もちろん、必要がない場合）。同時に、支払いカレンダーも正常に作成されます。

「支払カレンダー」レポートの「標準設定」が実際には期待を満たしていない（そのため、カレンダーが表示されない）場合はキャンセルできますが、ユーザーモードでは「支払日」とレポートによるグループ化を追加できます。通常の形式で生成されます。

データ構成システムの使用により、レポートの機能が (SCP 1.3 と比較して) 大幅に拡張されました。シン/Web クライアントでレポートを生成し、データベースに保存して、さまざまなユーザーに必要な設定を割り当てることができるようになりました。

UT11では、家財の消費・受け取り計画に加え、家財の移動計画機能も追加しました。これらの目的のために、「世帯の移転命令」という文書を作成できます。

「現金支出申請書」に関する UPP 1.3 と比較して、考慮されるビジネス取引の種類の数が増加しました。

「資金支出申請書」とその他の命令の両方の文書を承認できるようになりました。

債務を間隔/期限ごとに分析するために、「売掛金」レポートが提供されます。必要に応じて、借金カレンダーを作成することもできます。これを行うには、カスタムモードで支払い日によるグループ化を追加する必要があります。

残念ながら、UT11 には (以前と同様に) サプライヤーによる債務カレンダーを分析する機能がありません。ただし、このタスクのために UT11 を完成させる必要があります。

要約する： 新しい方法論ソリューション「1C」は、8.2 プラットフォームの機能と合わせて、運用計画および D/S の制御タスクを自動化するための優れた基盤を提供します。

しかし同時に、UT11 構成は財務自動化と財務計画のための完全な既製のソリューションではないことを理解する必要があります。

まず、UT11 は、経費要求やその他の D/S 計画文書を調整/承認するためのメカニズムを非常に簡素化された形式で実装します。つまり、ルーティングメカニズムは存在せず、アプリケーションを承認するプロセスは単にステータスを設定するだけになります。
第 2 に、UT11 には予算サブシステムがなく、(結果として) 計画された予算についてアプリケーションを監視する機能がありません。

4.WAの特徴：フィナンシェ

歴史的に、WA:Financier 構成は Treasury Management 製品に基づいて開発されました。

同時に、WiseAdvice の新しい「Financier」ソリューションには以下も含まれます。

予算計画サブシステム。
契約管理サブシステム。
実際の支払いの形成と会計のためのサブシステム。
テンプレートに基づいてドキュメントを生成/記入するための柔軟でカスタマイズ可能なメカニズム。
柔軟でカスタマイズ可能な顧客と銀行の統合サブシステム。

契約条件の考慮から支払いカレンダーの作成まで、「WA: Financier」の主な機能を財務の観点から考えてみましょう。

アプリケーションの承認プロセスでは、(UPP で行われるように) ドキュメントを承認/拒否できるだけでなく、改訂のためにドキュメントを送信したり、追加情報を要求したりするなど、他の機能も利用できます。情報。
このプロセス全体が自動化されているため、文書承認処理のステータスに関するレポートが提供されます。

5. 結果

結論:

財務部門、財務省、複雑な組織構造を持つ組織の作業を自動化します。最適な解決策は次のとおりです 「WA：金融家」.
このソリューションは長い間開発および進化しており、それに応じてさまざまな金融機関の詳細と要件が蓄積されています。部門と財務省。ソリューションの開発にかかる総人件費は 5,000 人/時間以上に達しました。
WA: Financier ソリューションの利点は、その高度な機能と多数のプログラム設定メカニズムです。したがって、このソリューションは追加工事を行うことなく、短時間で実装できます (いわゆる「すぐに使える実装」)。開発、プログラミングなど。
このソリューションには、すべての主要な標準構成との双方向交換のメカニズムが含まれているため、既存の構造 (UT、UPP、Kompleksnaya、Bukh データベースとのデータ交換) への統合は難しくありません。
財務部門/財務部門を自動化するには 包括的な自動化プロジェクトの枠組み内で最良の解決策は UPPに基づく.
同時に、ソフトスターターの機能には改善が必要であることを理解する必要があります。
詳細、財務要件。部門や財務省は、個別の特殊なソリューションほど深く UPP に組み込まれていません。
したがって、これらのタスクに対する SCP の実装は、自動化プロジェクトの一部としてのみ実行する必要があります。
大規模組織の場合、財務部門を自動化するため UT11合わない。
この決定では、第一に、計画文書の調整・承認の仕組みが存在しない。
第二に、予算作成サブシステムがなく、運用計画中に予算の実行を制御することもできません。
ただし、UT11 に最適自動化（運用計画の D/C を含む） 小規模な金融会社の部門.

プログラム「支払いカレンダー2.1」
1C の場合: 会計 8

ソフトウェア 「SysTecs: 支払いカレンダー」現金および非現金資金の受け取りと支出の運用計画の問題を解決するために使用されます。このプログラムは「1C: Enterprise 8.2」プラットフォーム上で開発されており、 スタンドアロン構成これには次の機能が含まれます: 顧客からの資金受け取りの計画、サプライヤーやその他の債権者への支払いの計画、資金の種類、取引相手、契約に応じた組織の支払カレンダーの管理、および使用項目の分類資金の。この計画システムは、実際の会計データだけでなく、口座からの予想される受け取りや規制上の支払いに関するデータの使用に基づいています。営業収益計画回路は、プログラムユーザーに、買い手や顧客との決済プロセスを管理および制御する効果的な手段を提供します。

「SysTecs: Payment Calendar」プログラムの動作原理

SysTecs: Payment Calendar プログラムは、1C: Accounting 8 アプリケーションソリューションの機能を拡張するスタンドアロン構成です。このプログラムは 1C:Accounting 構成を変更する必要がなく、1C:Enterprise 8.2 テクノロジプラットフォームによって提供される外部 COM 接続のメカニズムを使用して情報を交換します。このプログラムの原則により、次のことが提供されます。

ソフトウェア製品のインストールが簡単。
構成をマージするときに競合が発生しないこと。
標準 1C の維持: 会計更新手順と技術サポート条件。

自律性にもかかわらず、一般に認識されているオープンスタンダードとデータ転送プロトコルに基づく柔軟な統合により、ユーザーは単一のプログラムで作業しているかのように単一の情報空間で作業できます。

■重要なお知らせ

ソフトウェア製品の目的は、 共有専用次のアプリケーションソリューションを使用します: 1C: Accounting 8 (エディション 1.6、2.0) および 1C: Accounting KORP。1C: Enterprise 8.2 テクノロジプラットフォーム 8.2.13.202 以上で実行されます。

プログラムの主な特徴

SysTecs: Payment Calendar プログラムは、中小企業の実際のニーズを満たす、組織内のキャッシュフローの運用管理のための効果的なツールを提供します。ユーザーインターフェイスのシンプルさと機能性、1C:Accounting データとの統合、柔軟なレポート機能により、資金の受領と支出を計画し、組織の支払いカレンダーを維持することができます。

■キャッシュフロー計画

「SysTecs: Payment Calendar」プログラムに実装されている機能を使用すると、便利で有益な計画アシスタントを使用して、購入者や顧客からの資金の受け取りを計画できます。今後の入金のすべての特性 (入金日、取引先、金額など) は、計画文書を使用してプログラムに入力され、組織の支払いカレンダーに反映されます。 1C:Accounting データとの柔軟な統合により、プログラムは支払いカレンダーの収益部分の実行を監視する機能を実装します。取引相手からの現金および非現金資金の実際の受け取りに関する情報は、プランニングアシスタントおよびプログラムレポートに反映されるため、顧客との決済ステータスを迅速に監視し、現金受け取りのダイナミクスを予測することができます。

■支払い計画

「SysTecs: Payment Calendar」プログラムは、マネージャーや企業経営陣に、組織内の支払いの運用計画を立てるための効果的なツールを提供します。このプログラムは、財務責任センターがサプライヤーやその他の取引相手への支払い要求を生成できるようにする便利な支払い計画アシスタントを提供します。生成された申請書は承認手続きを経て、組織の支払いカレンダーの支出部分に含まれます。アプリケーションを分析および承認するために、プログラムは便利で有益なアプリケーション管理インターフェイスを提供します。「SysTecs: Payment Calendar」プログラムを使用すると、部門の現金ニーズを管理し、サプライヤーへの支払いを管理し、経費の支払いを承認するための手順を確実に遵守することができます。

■お支払いについて

「SysTecs: Payment Calendar」プログラムの機能により、当日の支払い記録に含めて、承認された支払いリクエストをさらにランク付けすることができます。このアプローチは、現金支出計画を当座預金の実際の残高と一致させるのに役立ちます。登録に含まれていない申請は、新たな支払い期限まで延期されるか、拒否される場合があります。このプログラムでは、支払記録に基づいて支払文書 (送信支払命令) を生成し、それを 1C: 会計データベースに転送することができます。取引相手への資金移動の事実は、支払および現金取引を計画するためのレポートおよびアシスタントに反映され、資金の支出およびサプライヤーとの相互決済を管理できるようになります。

■ 支払いカレンダーの管理

実際の残高、計画された資金の受け取りと支出に関するすべての情報は、支払いカレンダーレポートに反映されるため、会社の流動性を迅速に監視し、資金を最大限の効率で使用することができます。分析的には、支払いカレンダーのセクションを使用すると、誰に、いつ、何に対して支払われるべきか、誰からいつ入金されるのかなど、マネージャーが気になる主な質問に答えることができます。支払いカレンダーのデータを使用すると、さまざまなキャッシュフロー予測を作成し、入金日、支払い日を変更し、取引先と調整することができます。また、組織内で設定された制限を超えた資金の支出を防ぐこともできます。

■ 1C Accountingとのデータ交換

「SysTecs:Payment Calendar」プログラムの特徴は、COM接続技術を利用して実装された1C:Accounting8とのデータ交換の仕組みです。 1C:Enterprise 8.2 プラットフォームによって提供されるこのテクノロジを使用すると、会計プログラムと SysTecs: Payment Calendar プログラムからのデータを単一の情報スペースに組み合わせることができます。このアプローチにより、統合情報システムでの作業の利便性を維持しながら、1C: 会計の機能を簡単に拡張できます。あるプログラムでデータを変更すると、すぐに別のプログラムで利用できるようになり、システムユーザーは追加のアクションを実行する必要がありません。

ソフトウェア製品のテクニカルサポート

■テクニカルサポートサービス

SysTecs 製品のすべての登録ユーザーにはテクニカルサポートが提供されます。このサポートへのアクセスは、会社の Web サイト上のユーザーの個人アカウントを通じて組織されます。そこでは、興味のある質問をするだけでなく、プログラムの機能を拡張するための提案をすることもできます。ソフトウェア製品の開発は主にアクティブなユーザーサポートに依存していることを忘れないでください。

■ ソフトウェア製品のアップデート

「SysTecs: Payment Calendar」プログラムを購入すると、最新のアップデートに対する 6 か月間の無料サブスクリプションが提供されます。 6 か月間の無料サブスクリプションの有効期限が切れたら、最も便利な有料アップグレードオプションにサインアップできます。サブスクリプションのオプションと価格は、プログラムの料金ページで確認できます。

■ 詳細なドキュメント

ソフトウェア製品「SysTecs: Payment Calendar」の納品には、プログラムを使用するための完全なドキュメントセットが含まれています。このドキュメントでは、プログラムのインストール、構成、使用方法だけでなく、支払いカレンダーの自動化されたビジネスプロセスの編成の問題についても説明されています。ドキュメントの各セクションには、プログラムのあらゆるオブジェクト (参考書、ドキュメント、インターフェイス) からアクセスでき、ソフトウェアパッケージに組み込まれた自動更新システムにより、作業でドキュメントの最新バージョンを使用できます。

プログラムのデモ版

プログラム「SysTecs: Payment Calendar」には、完全に機能するデモ版があります。デモ版の存在により、実際の運用状況における支払いカレンダーシステムの有効性を評価することができ、プレゼンテーション資料だけでなく、製品に関するご自身の経験に基づいて購入を決定することができます。このアプローチのみが、プログラムに含まれるビジネスプロセス自動化スキームと機能がお客様のビジネスの要件を満たしていることをユーザーに保証するものであるため、当社ではこのアプローチのみがクライアントにとって公平であると考えています。

この記事は何についてですか?

支払いスケジュール– 投資家や経営者にとって便利なツール。資金分析と計画を実行するために使用できます。

この記事では次のことを見ていきます。

支払いスケジュールの作成
適時の支払い実行の管理
レジや当座預金残高の管理
クライアントから受け取り、サプライヤーに転送される支払条件の設定
前払いおよびクレジットオプションの支払い日を計算するメカニズム

適用性

この記事は、1C の 2 つのエディション: 貿易管理 - のために書かれました。 11.1 そして 11.2 。これらのエディションを使用している場合は、記事を読んで、説明されている機能を実装してください。

UT 11 の実装を開始する予定がある場合は、より新しいエディションが使用される可能性が高くなります。インターフェイスと機能は異なる場合があります。

そこで、講座の受講をおすすめします レベル 1C の実践タスク: UT 11、KA 2 および 1C のスペシャリスト: ERP 2、これは間違いや時間/評判の損失を避けるのに役立ちます。

問題の定式化

Furniture Design 会社は家具の卸売業を行っています。同社には卸売倉庫が 1 つあり、そこから商品が発送されます。

すべてのお客様は、ご注文の際、ご注文が確定するまで、金額の 10% を前払いとさせていただきます。残り（注文金額の90％）については、2日間の猶予期間が与えられます。

家具サービスのサプライヤーへの支払いを返済するために、当社には商品の受領後 3 日間の猶予期間が与えられます。

経営陣は定期的に資金発行の事前要求を責任者に提出します。つまり、予定された支払日で明日お金を支払うためのアプリケーションが今日作成されます。

将来の支払い（ローンの取得など）のスケジュールを計画することも必要です。

すべての企業プロセスは、1C: Trade Management 11 プログラムを使用して反映されます。

取得する必要があるもの

資金を分析できる機能をデモンストレーションする、支払スケジュールを作成し、1C: Trade Management 11 プログラムでその実行を監視します。

支払いカレンダーの問題を解決する

まず、データベースに「家具デザイン」組織を作成します。

当社では 1 つの組織のみを使用しているため、「管理」-「組織と資金」セクションで「複数の組織」フラグを設定しません (UT 11.2 では、これは「研究データと管理」-「エンタープライズ」セクションです)。

組織を作成するには、「規制と参考情報」-「設定と参考書籍」-「組織に関する情報」セクションに移動しましょう (UT 11.2 では、これは「研究データと管理」-「企業に関する情報」セクションです) ”）。

必要な情報をすべて入力していきます。「記録して閉じる」ボタンをクリックして、組織のカードを記録しましょう。

同社は 1 つの卸売倉庫を使用しています。

したがって、「管理」 - 「倉庫と配送」セクションに「複数の倉庫」フラグを含める必要はありません (UT 11.2 では、これは「参照データと管理」 - 「倉庫と配送」セクションです)。

「規制と参考情報」-「設定と参考図書」-「倉庫会計の設定」セクションに進みましょう (UT 11.2 では、これは「マスターデータと管理」-「企業に関する情報」-「設定」セクションです)倉庫会計」）。

必要事項をすべて記入し、倉庫カードを書き留めます。

当社は顧客からの注文とサプライヤーへの注文を使用します。

「管理」-「CRM と販売」セクション (UT 11.2 では、これは「研究データと管理」-「販売」セクションです) で、フラグ「顧客注文」を設定し、注文を使用するためのオプションを「」として設定します。倉庫からの注文と注文への注文」 (注文を使用するためのオプションの詳細については、追加セクションを参照してください)。

クライアントの支払い条件を指定するために、プログラムの同じセクションに、クライアントとの契約を使用するための機能が含まれます。「標準契約と個別契約」オプションを選択しましょう。

「サプライヤーへの注文」ドキュメントの使用を有効にするには、「管理」 - 「購入」セクション (UT 11.2 では、「マスターデータと管理」 - 「購入」) で「サプライヤーへの注文」フラグを有効にする必要があります。セクション）。

ここでは、サプライヤーとの購入および支払い条件を示すために、「サプライヤーとの合意」フラグも有効にします。

当社は、顧客に製品を販売するために使用される新しい顧客契約を作成します。

タスクの条件に従って支払い手順を入力しましょう: 注文を確定する前に 10% と 90% の金額を前払いします - 2 日間の延期を伴うクレジット。

次に、クライアント「Ivanov Ivan Ivanovich」からプログラムに新しい注文を出します（「規制および参照情報」-「取引先」セクションで新しいクライアントを作成します）。

オーダーリスト：

オーク材テーブル 1個価格は10,000ラブ。
スライド式ワードローブ 1 個価格は20,000ラブ。

「規制および参考情報」セクションでは、まず 2 つの命名規則を作成します。

プログラムの「販売」セクションに移動して、新しい「顧客注文」文書を作成しましょう。

必要な製品項目をお客様の資料に記載させていただきます。

注文時に希望発送日を指定します (例: 2015/06/11)。

表形式セクション「商品」の行には、担保オプション（「アクション」列）-「担保へ」を示します。このステータスを設定すると、プログラムによって商品の出荷日が自動的に設定されます。発送日の計算には、発送希望日が考慮されます。

文書を投稿しようとすると、プログラムは支払い条件に違反していることを示すエラーを表示します。

事実は、契約書 (これがデータベース内の唯一の契約であるため、文書内で自動的に確立されました) の中で、支払い条件に 10% の前払いを指定したということです。

「完了用」ステータスで文書を転記すると、プログラムは文書の支払条件をチェックします。この場合の支払い条件はまだ満たされていません。

注文ステータスを「承認中」にして転記させていただきます。

文書の表部分の下にあるハイパーリンクをクリックすると、文書の支払い条件を確認できます。

ご覧のとおり、プログラムは、契約で指定された条件に従って、注文の金額と支払い日 (前払いおよびクレジット) を自動的に計算しました。

前払いおよび前払いの支払い日を計算する場合、注文日 (2015 年 6 月 8 日) が使用されます。

信用ステージの日付の計算は、契約で指定されたカレンダー (この場合は暦日) を考慮して、商品の出荷希望日から行われます。

つまり、クレジット (出荷後) は次のように計算されます。

発送希望日 + 2 日 = 06/13/2015

支払いカレンダーを作成する際に、計画された支払いを考慮するためにこのデータが必要になります。

私たちはクライアントから3,000ルーブルの金額を支払います。注文の前払いとして。

まず、「規制および参考情報」 – 「設定および参考図書」 – 「レジの設定」セクション (UT 11.2 では、これは「研究データと管理」 – 「企業に関する情報」 – 「レジの設定」セクションです) ”）に弊社のレジに関する情報を記入していきます。

また、「規制および参照情報」 – 「銀行口座の設定」セクションで、当社の銀行口座に関する情報を入力します (UT 11.2 では、これは「NSI および管理」 – 「企業に関する情報」セクションです)。 – 「銀行口座の設定」）。

「顧客注文書」文書で、「基づいて作成」-「現金受領書注文」ボタンをクリックします。

3,000ルーブルの現金注文書を発行いたします。

これで、顧客の注文を「フルフィルメント」ステータスで投稿できるようになりました。

「財務」セクション (UT 11.2 では「財務」セクション) の「支払計画」レポートを使用して、現金残高と支払いスケジュールを分析できます。

「支払いカレンダー」の使用は、「管理」-「組織と資金」セクション（UT 11.2では「研究データと管理」セクションです）で機能オプション「資金支出のリクエスト」が有効になっている場合に利用できます。財務省」）。

「支払い計画」レポートを作成します。

レポートでは、現在の現金残高が 3,000 ルーブルであることがわかります。

顧客からの支払い予定額は27,000ルーブルです。

それは正しい。利用可能残高を計算する際には、クライアントからの予定された支払いが考慮されます。この場合、クライアントからの支払い金額は、クライアントの注文で指定した支払い段階に従ってレポートに線で表示されます。

報告書は、6月13日土曜日の現金残高が3万ルーブルになると伝えている。

ここで、「顧客注文」に基づいて「サプライヤーへの注文」を出します。

ただし、その前に、「規制および参照情報」セクションの「取引先」に新しいサプライヤー「Furniture Service」を作成しましょう。

サプライヤーカードフォームのナビゲーションパネルで、[サプライヤーとの契約] 項目に移動します。

新しい契約書を作成しましょう。

契約書に必要事項を全て記入させていただきます。

私たちはタスクに従って支払い条件を示します - クレジット（出荷後）3日。

「Customer Order」を開き、「Create Based on」ボタンをクリックして、「Order to Supplier」項目を選択します。

当社が作成した「家具サービス」のサプライヤーを文書に記載します。サプライヤーとの契約は自動的に成立します。

支払い日と金額は、契約で定義された支払いスケジュールに従って自動的に計算されます。

サプライヤーへの注文では前払いまたは前払いは使用しませんが、前払いおよび前払いの支払い日を計算する際には注文日が使用されます。これには、商品の希望配達日も考慮されます。

クレジットステージの日付の計算は、契約で指定されたカレンダーを考慮して、商品の配達希望日から行われます（検討中の例では暦日単位）。私たちの場合は次のようになります。

受領日 (2015/06/09) + 3 日 = 2015/06/12

文書を確認してみましょう。

サプライヤーへの資金支払いに関する新しいグループがレポートに登場しました。

ご覧のとおり、2015 年 6 月 12 日の時点で、現在の現金残高を考慮すると、マイナス 20,000 ルーブルを受け取ることになります。

2015 年 6 月 13 日の時点で、顧客からの支払いの受け取りを考慮すると、資金残高は 7,000 ルーブルになるはずです。

つまり、サプライヤーへの支払い時に必要な金額が不足しているという状況が発生しました。

会社の経営陣が融資を受けるために銀行と交渉を始めたと想像してみましょう。銀行からの現金 50,000 ルーブル。 2015 年 6 月 10 日締め切り

支払いカレンダーでは、「領収書追加」コマンドを使用して予定の現金領収書を登録することができます。

新しい文書「DS の受け取り予定」が目の前に開きます。

埋めていきましょう。

新しい DDS 記事「DS のその他の受領書」と金額 50,000 ルーブルを示します。

文書の日付を 2015/06/10 に設定します。

文書を確認してみましょう。

「支払い計画」レポートを再度生成します。

2015 年 6 月 10 日には、さらに 50,000 ルーブルの現金受け取りが予定されていることがわかります。

この予定された受け取りがあれば、企業はサプライヤーに債務を支払う機会が得られます。

クライアントからの DS の受け取りを考慮すると、計画残高の合計は 57,000 ルーブルになります。

銀行融資が発行され、銀行口座に資金が入金されたと想像してみましょう。

「DS受取見込書」という書類をもとに、「非現金DS受取書」という書類を作成します。

支払者は「VTB Bank」とさせていただきます。

「銀行に合格」フラグを設定し、資金が銀行によって送金された日付を示します。

「支払いカレンダー」レポートを再生成してみましょう。

銀行ローンの受け取りを考慮すると、現在の現金残高はすでに53,000ルーブルであることがわかります。

しかし、報告書から「予定受領」という行は消えなかった。

その結果、2015 年 6 月 10 日時点での予定現金残高は 103,000 ルーブルとなっていますが、これは完全に正しいわけではありません。

これは、UT11.1.10.153 リリースの設定エラーです。開発者は将来のリリースで修正すると思います。

完成した文書「予定されている現金受領書」については、削除するか非転記にする必要があります。

さらに、クライアントから受け取ってサプライヤーに転送される支払条件の設定、および前払いおよびクレジットオプションの支払日を計算するメカニズムも検討されました。

ご覧のとおり、機能はシンプルで、会社の財務管理者や会計士が現金残高を管理し、支出を計画するのに非常に役立ちます。

多くの 1C 構成には、支払いカレンダー (PC) などの機能が備わっています。これは、短期の資金計画 (CF) を実行し、予定どおりに資金不足を検出するのに役立ちます。 1C:ERP Enterprise Management 2 構成では、PC はドキュメントの作成、レポートの生成、結果の分析を可能にする便利なワークステーションとして表示されます。この記事では、前述の構成 (リビジョン 2.4) で PC を操作する際の機能について詳しく説明します。

PC は全体として、金融資産の受領書、償却、残高を反映する分析レポートであり、現金と非現金のタイプ別、および特定の銀行口座や組織のレジなどの場所別にグループ化できます。さらに、支払いカレンダーから、DS の計画的な償却を実行したり、別の銀行口座やレジで残高を管理したり、現金不足を解消するために移動したりすることができます。 PC を使用するための推奨事項を考慮に入れれば、初心者の財務管理者にとっても、PC はキャッシュフロー管理の信頼できるアシスタントになります。

支払いカレンダーを管理するためのパラメータの設定

最初に 1 つの重要なプログラムパラメータを設定すると、PC での作業が可能になります。インターフェースから確認してみましょう 「マスターデータと管理/マスターデータとセクションの設定/財務」

このパラメータは 資金支出の要求を維持する。 PC はフラグが設定された状態で 1C:ERP に維持されます。インストールしましょう。

PC を使い始めるにはこれで十分です。

インターフェース経由でPCへのアクセスが可能 「財務/資金の計画と管理/支払いカレンダー」

1C 8.3 での支払いカレンダーの設定

PC の外観は、ユーザーの要件やタスクに合わせてカスタマイズできます。デフォルトでは、カレンダーは 2 つのウィンドウモード (アプリケーション/左、カレンダー/右) で開きます。

ボタンを使用して PC 出力モードを変更できます。 "ビュー"、カレンダーの左上部分にあります。

カレンダービューには合計 3 つのモードがあります。

アプリケーション/カレンダー;
カレンダー/支払い;
アプリケーションのリスト。

2 番目のモードを使用するのが最適です。DS の受け取りと支払いの両方の根拠を提供するすべての文書がこのモードで利用可能です。

PC は、特定の計画日数に合わせて構成できます (前のスクリーンショットでは 20 日です)。必要な組織を指定します (この場合は「Prompostavka」です)。特定の銀行口座/現金の選択を設定します。

線の表示を制御するように PC を構成することが非常に重要です。ボタンのドロップダウンメニューから利用できます "もっと"：

設定ウィンドウでは、いくつかのタイプのオプションをインストールできます。

カレンダーに表示 – まだ承認されていない経費申請を確認できるようになります。
予想される入金 – 決済文書のコンテキストにおける DS 入金明細行の可視性が含まれます。
予想される償却 – 申請なしで、決済文書のコンテキストで経費の可視性を管理します。

さらに、設定では通貨の種類（管理または規制会計）を選択できます。さらに嬉しいボーナスとして、計画日を設定し、カレンダーの非稼働日を無効にする機能があります。

前に指定した設定に対応する PC の構造を理解しましょう。

左側には、いずれかのアカウントの選択が事前に確立されていない限り、組織の現在のアカウントのリストが表示されます。レポートには、残高、領収書、償却、合計が含まれます。レポートの列により、延滞債務と計画された動きを日ごとに確認できます。カレンダーセルのアクティビティを切り替えると、下部の表部分で、領収書、償却額、または延滞債務の金額を解読するドキュメントのリストが変更されます。

1C での支払いカレンダーの管理

前述したように、ERP の PC はワークステーションです。つまり、ユーザーはオープンな方法で PC を即座に管理できます。

支払いカレンダーでキャッシュフローを計画する

カレンダーでは、DS の移動を計画し、その後、次の領域で必要なドキュメントを作成できます。

別のアカウントに転送する;
別のレジに発行します。
銀行への回収。
銀行からの回収。
通貨換算。

これを行うには、ボタンのドロップダウンメニューから必要な行を選択するだけです。

選択した行に応じて、ドキュメントを作成するためのダイアログが開きます。

資金移動の注文 - 通貨換算を除くすべての明細。
DS を使用するためのアプリケーション - 通貨換算のみ。

支払いカレンダーを正しく管理するための支払い書類の記入機能

システムが特定の支払い文書を特定の銀行口座からの移動に属するものとして明確に分類するには、この文書に支払い形式を示し、銀行口座とレジを指定する必要があります。

たとえば、支払い方法が指定されておらず、レジの名前や当座預金口座の名前が含まれていない顧客の注文は、PC では識別できません。

このような注文は、いわゆる未払いの領収書に該当し、PC フォームに「領収書が配布されていません」という行が表示されます。サプライヤーとの支払書類に支払い元のレジや当座預金口座が含まれていない場合、DS の償却でも同様の状況が発生する可能性があります。かかる金額は、「償却未分配」の行に個別に反映されます。

このような事態が起こらないようにするためには、支払い書類の詳細を記入する手順を注意深く監視する必要があります。 PC には完全に記入された支払い書類の行はありません 「領収書が配布されていない/償却が配布されていない」

1C の支払いカレンダーを使用した現金不足の追跡と解消

PC を維持する過程で、組織は資金不足を経験することがあります。一時的な資金不足、または組織が同じ期間内 (通常は同日) に支払う必要がある支払いを超える利用可能な資金と入金資金の超過。 PC では、現金不足は、組織の特定の銀行口座またはレジのマイナス残高として非常に明確に反映されます。

PC の状態を分析してキャッシュギャップの存在を確認することで、その発生に迅速に対応できるようになります。現金ギャップを解消するにはいくつかの方法があります。

十分な残高を確保して、ある銀行口座から別の銀行口座に資金を移動します。
DS の償却額を変更して減額し、入金予定日まで支払いを延期します。
顧客からの DS の十分な供給を確保します。

アカウント間で資金を移動する方法の例を見てみましょう。上のスクリーンショットでわかるように、アカウント「7231/Prompostavka (RUB)/Own account」に現金ギャップが形成されています。組織全体として PC を分析すると、十分な資金が保管されている別の銀行口座があることがわかります。