営業キャッシュフロー計画またはキャッシュフロー管理システムの構築方法。支出資金用サブシステム「電子申請」支出資金申請書 1c upp

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 を含む） 小規模な金融会社の部門.

「資金支出要求書」という文書は、支払いの計画と調整を目的としています。
文書「DS 支出リクエスト」は、「財務」-「資金の計画と管理」-「DS 支出リクエスト」-「作成」セクションに移動して作成できます。
「DS支出申請書」には、作成時に選択する数種類の操作があります。各タイプのアプリケーションはさまざまなビジネストランザクションを反映することを目的としており、それぞれについてはこの説明書で説明します。
作成した書類「DS支出申請書」は「支払調書」書類を利用して収集・同意されます。承認後、申請に基づいて「非現金 DS の償却」書類が自動的に作成され、銀行による支払いのためにクライアントの銀行にアップロードされます。
以下に、「DS支出申請書」という書類の作成例を業務ごとに示します。

サプライヤーへの支払い
サプライヤーへの支払いトランザクションを処理するには、文書「DS 支出要求」のトランザクションタイプが「サプライヤーへの支払い」であることが意図されています。
新しい文書「DS 支出申請書」では、文書を処理するために入力が必要なフィールドが赤でマークされています。文書は「未承認」ステータスで作成されますが、支払登録の承認中にステータスは自動的に変更されます。アプリケーション作成時の優先度は自動的に「中」に設定されます。

図 1. 書類フォーム「DS 支出申請書」、操作の種類「サプライヤーへの支払い」（未記入）
書類「DS利用申請書」の内容は以下の通りです。
基本タブ
番号– 実行中に自動的に生成され、手動で設定することはできません。
日付– 作成時に、現在の日付が設定されます。
組織– ボタンを使用して組織の提案されたリストから選択するか、フィールドに名前を入力すると、必要な値が選択用に表示されます。
区画– 「Enterprise Structure」ディレクトリから、支払いが発生する部門を選択する必要があります。
申請者– デフォルトでは、アプリケーションを作成している現在のシステムユーザーが表示されます。
企画– デフォルト設定は「支払い通貨で」であり、変更できません。
和– は必要な支払い金額を示します。
通貨– 必要な支払いの通貨を示します。
手術– 作成時に選択した書類「DS支出申請書」の取引種類が反映されます
支払期日– サプライヤーへの支払いをスケジュールする必要がある日付を示します。
支払形式– デフォルト設定は「任意の形式」であり、変更できません。
受信者– 支払いが行われる必要がある「取引先」ディレクトリのサプライヤーを示します。
受取人のアカウント– 「受取人」を選択すると、受取人の口座が自動的に設定されます。必要に応じて、サプライヤーから提供される「支払い請求書」に別の口座が示されている場合は、「銀行口座」ディレクトリから必要な口座を選択する必要があります。
限度を超えて– システムが支店およびキャッシュフロー項目それぞれのコンテキストで現金支出を制限するシステムを維持している場合、行われる支払い金額が以前に制限に含まれていなかった場合、ドキュメントを転記するときにユーザーはエラーメッセージを受け取ります。申請は処理されません。

図 2. 制限が計画されていなかった注文を行う際のエラーの例。
限度額を超えて注文するには、「限度額超過」フラグを設定する必要があります。
予算に振り替える– このフラグは、支払いが予算への振替である場合に設定されます。フラグを設定すると、予算への支払いに必要なKBKやOKTMOなどの値を入力できるようになります。

図 3. 「予算に転送」フラグを設定する例。
UIP– 一意の支払い識別子。受取人との契約で規定されている場合にのみ示されます。
支払いの目的- プログラムには、「挿入」ボタンを使用して支払い目的を自動入力するためのいくつかのオプションが用意されています。

図 4. 「支払い目的」フィールドを自動入力するためのオプション。
書類のリスト（以下を含む）バット- 「支払い復号化」タブから決済オブジェクトに関する情報が表示されます。

VAT (18%) を含む (全額)、消費税を含む VAT（10％）（全額）、税抜（VAT）- 入力したテキストに VAT 情報が追加されます。

受信者の銀行口座からのテキスト- 取引相手のアカウントカードから「支払目的テキスト」フィールドに指定されたテキストを挿入します。

図 5. 「基本」タブへの入力例。

「支払い詳細」タブ
「支払いデコード」タブには、支払いおよび受取人との相互決済に関する詳細情報が表示されます。
支払いはリストとして入力できます。複数の計算オブジェクトに分散することも、分割せずに 1 つの計算オブジェクトのみを選択することもできます。
州防衛基金からの支払い– フラグは、支払いが国防政府命令の枠組み内で行われた場合にのみ設定され、その他の場合にはフラグは設定されません。
計算対象– 決済対象として、「相手方との合意」（このタイプの申請書類の操作では、選択すると、関係タイプが「サプライヤー/履行者と」の協定が利用可能）または合意文書「注文」を指定できます。サプライヤーへ」。
プロバイダー
相互決済金額– ドキュメントの投稿時に自動的に設定されます。
通貨– は計算対象を選択すると自動的に設定されます。
DDS記事– 支払いの種類に対応するキャッシュフロー項目を示します。
コメント– 必要に応じて、支払いの復号化に関するコメントを示します。

図 6. 「Payment Decoding」タブへの入力例。
アカウント配布タブ
「口座への配分」タブには、資金の引き落とし先となる組織の銀行口座が表示されます。支払金額と支払日は、「基本」タブで指定したデータに従って自動的に設定されます。

図 7. 「アカウント別の分布」タブへの入力例。

図 8. 取引タイプが「サプライヤーへの支払い」であるアプリケーション用に自動的に作成されたドキュメント「非現金 DS の償却」の例。

顧客への代金の返還
顧客への払い戻し取引を処理するには、文書「DS 支出申請書」の取引タイプは「顧客への支払いの返還」を対象としています。
このタイプの操作における文書「DS 支出申請書」の明細の構成は、サプライヤーに支払うときの明細の構成と同じであり、唯一の違いは取引相手の種類と決済の対象です。

図 9. 書類の形式「DS 支出申請書」、操作の種類「顧客への支払いの返還」
受信者– 支払いを行う必要がある「取引相手」ディレクトリのクライアントを示します。
計算対象– 決済対象として、「取引相手との合意書」（この種の申請書類の操作では、選択時に関係タイプが「買主/顧客との間」の契約書が利用可能）または合意書面「」を指定できます。顧客の注文」。
買い手– 計算オブジェクトを選択すると、フィールドは自動的に入力されます。計算オブジェクトの対応するフィールドで指定された「Partners」ディレクトリ要素がインストールされます。

図 10. 「Payment Decoding」タブへの入力例。
すべての承認段階を通過すると、文書「DS 支出申請書」にはステータス「支払い用」が割り当てられ、文書「非現金 DS の償却」が自動的に作成されます。

図 11. 操作タイプ「クライアントへの支払いの返還」を持つアプリケーションに基づいて自動的に作成されたドキュメント「非現金 DS の償却」の例。

責任者への発行
責任者の銀行口座に資金を発行するトランザクションを形式化するには、文書のトランザクションタイプ「DS の使用申請」-「責任者への発行」が対象となります。

図 12. 文書の形式「DS 支出申請書」、操作の種類「責任者への発行」
責任者– 従業員はディレクトリから示されます。個人」に送金する必要があります。
報告– 提案された期間リストから、会計士が受け取った金額を報告する必要がある期間を示す必要があります。

図 13. 「Payment Decoding」タブへの入力例。
すべての承認段階を通過すると、文書「DS 支出申請書」にはステータス「支払い用」が割り当てられ、文書「非現金 DS の償却」が自動的に作成されます。

図 14. 操作タイプ「責任者への発行」のアプリケーションに基づいて自動的に作成された文書「非現金 DS の償却」の例。

現代の競争環境において企業が効果的に存続するための必須条件は、効果的な管理メカニズムの構築です。キャッシュフロー迅速かつ信頼できる情報の生成、相互決済の規制、支払い規律の強化、そして最終的には現金回転の加速を確保します。

この構成には、企業の資金管理を自動化するためのツールが含まれており、次の 2 つの主要な機能を実行します。

決済口座および現金窓口における企業の実際の資金の動きの運用会計。
企業の現金の入出金の業務計画。

企業の支出と資金の受け取りの一般的な計画は、予算編成の枠組みの中で実行されます。作成される財務計画 (予算) は、資金管理サブシステムの一連のガイドラインと制約として機能します。

しかし、現金管理機能の枠組みの中で、運用上の財務計画、つまり支払いカレンダーが維持されます。数日前に支払いカレンダーを作成するのが合理的です。

支払いカレンダーは、支出資金の要求と予定されている現金の受け取りをまとめたものです。支払いカレンダーは、企業の銀行口座やレジなど、資金が保管されている場所に至るまで詳細をまとめて作成されます。支払いカレンダーを作成する際、その実行可能性、つまり保管場所の現金準備金が十分であるかどうかが自動的にチェックされます。

財務計画機能を 2 つの構成サブシステム (予算サブシステムと資金管理サブシステム) に分割することは、企業のさまざまな部門と従業員間での財務管理機能の分割に対応します。予算が金融サービスによって作成される場合、支出資金の要求は、会社の取引先と直接やり取りする従業員および部門によって生成されます。

この構成では、金銭文書 (支払命令、現金受領書、借方命令など) が生成され、「銀行クライアント」などの特殊な銀行プログラムとの対話が確保され、資金の流れが制御され、保管領域内の資金の可用性が保証されます。監視されています。外貨による現金支払いも可能です。

「資金支出の要求」という文書は、現金または現金以外の支払い（一連の支払い）を行うか、または資金を移動するかの決定を記録することを目的としています。書類の内容や利用手順は、基本的に「支払命令書（出金）」や「現金支出命令書」と同様です。

予約および配置パラメータは自動的に入力されます。この目的のために、このドキュメントではフラグと 「自動配置」.

これらのフラグを設定すると、ボタンをクリックしたときに「配置」列が自動的に入力されます。 「記入して投稿」.

自動配置スキームと手動配置スキームを組み合わせることができます。フラグが設定されているとき 「自動予約」そして 「自動配置」塗布量の一部について配置オプションを手動で指定できます。そしてボタンを押すと 「記入して投稿」残額のみ自動入金となります。

操作タイプを「」に設定した場合 サプライヤーへの支払い」または " 購入者に返金してください」取引相手との業務上の決済に変更が加えられる。

「支出資金申請書」という書類に基づいて、銀行や現金での支払い書類を入力することができます。このような文書には、必要な要件が含まれています。 応用"に基づいて入力するか、手動で入力することもできます。指定された支出資金申請に支払文書を転記する場合、文書の金額がこの申請の現在の未払い残高と一致しているかどうかがチェックされます。

追加の権利を設定する場合、ユーザーが資金の使用申請を示さずに支払い文書を処理することを禁止することができます。

文書「資金支出要求」は、現金管理サブシステムと予算作成サブシステムの間のリンクとしても機能します。この目的のために、アプリケーションは「予算運営」文書と同様の詳細のブロック (計画シナリオ、売上高項目、中央金融地区、プロジェクトなど) を提供します。申請書を提出する際、指定された詳細を使用して、支出が承認された資金の総額が以前に設定された制限値に準拠しているかどうかが監視されます。

アプリケーション承認メカニズムを使用する場合のアプリケーションの操作の機能

アプリケーション承認メカニズムは、組織のリストに対してオプションで使用されます。

アプリケーション照合メカニズムを使用すると、次の機能が生じます。

申請に組織が示されていない場合、この申請は承認に参加しません。

申請を承認するルートは、申請に指定された部門に応じた設定に従って決定されます。

申請が承認ルートを通っていない場合（申請ステータスが「承認」でない場合）、その申請に基づいて支払書類を発行することはできません。

申請が承認ルートを通過し始めた場合、申請は変更される可能性があります

現在申請を承認中のユーザー

承認の上位段階でアプリケーションを承認するユーザー
他のユーザーはアプリケーションを変更できません。

注文が「承認済み」状態の場合は変更できません

申請が「拒否」状態になった場合、申請はキャンセルされます。

アプリケーションの現在のステータスはアプリケーションのリストに表示されます

ステータスは別の列に表示されます

注文ステータスによるグループ化が使用されます

アプリケーションは背景色で強調表示されます
- 拒否されました - ピンク

記事の後半では、「資金支出申請書」を作成し、承認ルートに沿って通過させ、作成した申請書に従って資金を発行するという原則について考えます。
例を見てみましょう:

調達会計士は、IP Dobronravovのサプライヤーに材料の供給のために前払いを行うために、資金の支出要求を作成します。
CFO は申請を検討して承認する必要があります。
承認された申請に基づいて、調達会計担当者は現金入金指示書を作成します（「支払い済み」マークはありませんが、「業務会計に反映」マークが付いています）。
上級レジ担当者は、現金受け取り注文を確認した後、資金を発行します (そして文書に「支払い済み」とマークします)。
現金取引の会計担当者は現金受領書をチェックします (会計および税務会計記録に反映するためのボックスにチェックを入れて、会計および税務会計の仕訳が生成されるようにします)。

取引を反映しやすくするために、インターフェースを「資金管理」に切り替えてみましょう。
資金支出の申請を開始する前に、すべての項目を入力する必要があります。背景情報。最初に記入する必要があるのは、情報登録「支出資金申請承認設定」です。「申請の承認の設定」では、この仕組みを利用する組織と承認仕組みの利用開始日を示します。この設定は、組織 StroyTorg LLC が 2013 年 1 月 1 日から資金の支出リクエストを承認するメカニズムを使用することをプログラムが決定できるようにするために必要です。

また、連携ルートの設定も必要です（図2）。この設定は情報台帳「承認ルート開始設定」に示され、承認ルートと部門の対応が決定されます。承認ルート（「承認ルート」ディレクトリ）は、その段階とその段階における承認者のリストを示します。この例では、作成されたアプリケーションは、最初に財務ディレクターによる承認の 1 段階を通過する必要があります。

また、「資金支出申請承認設定」の情報台帳を設定し（図1）、申請を承認する段階（ルート）を決定する必要があります（図2）。

米。 1

米。 2

調整ルートアプリケーションは、設定に従って、アプリケーションで指定された部門に応じて決定されます。

注記 1 つの部門は 1 つの調整ルートのみに対応する必要があります。部門ごとに承認ルートを指定する必要があります。そうしないと、この部門に対して作成されたすべてのアプリケーションの承認プロセスが有効になりません。

1. 購買担当者は「資金支出依頼書」という書類を作成します。

私たちが選択した「資金管理」インターフェースで、メニュー項目「計画」-「リクエスト」-「支出資金のリクエスト」に移動します(図3)。ステータスタイプが「準備完了」の「資金支出申請書」を作成しましょう（図5）

本アプリケーションには、「現金出金注文」と「出金注文」の操作を繰り返す数種類の操作があります（図4）。

「取引相手との決済」タブの「資金支出依頼」には、資金の発行先となる支払相手、契約内容、金額、組織、部門、地位などの基本情報が表示されます。

「説明」タブで指定できます追加情報どのような形でも。

「割り当て」タブでは、資金を予約して配置することができます (図 6)。これは、この例では、購買会計士がサプライヤーに前払いを支払うために資金を予約し、資金がどのレジから発行されるかを示すことができることを意味します。予約および配置パラメータは自動的に入力されます。ドキュメントにはこの目的のためのフラグがあります。 「自動予約」そして 「自動配置」。これらのフラグを設定すると、ボタンをクリックしたときに「配置」列が自動的に入力されます。 「記入して投稿」。自動配置スキームと手動配置スキームを組み合わせることができます。

「予算」タブのデータは、予算作成サブシステムと資金管理サブシステムの間のリンクとして使用できます。このタブに表示される情報は、計画された予算に従って支出が計画されている資金の量を制御するために役立ちます (図 7)。

調達会計担当者はアクセス権限が限られているため、「資金支出依頼書」のステータスは「準備済み」のみ設定でき、「承認」、「延期」、「同意」、「却下」のステータスは設定できません。ユーザーによって設定され、アプリケーションを承認する責任があります。

2. 財務ディレクターは、120,000 ルーブルの資金支出申請を審査し、承認します。

財務ディレクターは、「申請承認ステータス」処理を使用して、検討が必要な申請のリストを分析できます（図8）。

「申請承認ステータス」の処理を開始すると、「準備済み」、「承認」、「延期」、「同意」、「却下」などの特定のステータス（状態）ごとにグループ化されたすべての申請のリストが表示されます。便宜上、「期間の設定」ボタンを使用して、たとえば、日、週、月、10年、四半期、半年、1年などを選択してから、すべてのアプリケーションのうち、指定された期間内にあるアプリケーションのみが残ります。

支出資金の申請状況を「準備中」から「承認済み」などに変更するには、別の処理（「申請状況」）が必要です。

この処理では以下から選択できます。一般的なリストたとえば、ステータスが「承認待ち」、「延期」、「前の段階で承認待ち」、「処理中」のアプリケーションです (図 9)。

Processingでは、連携していないアプリケーションの一覧が表示され、アプリケーションのステータスを変更できます（図10）。この処理はメニュー項目「企画」－「依頼」－「申請調整」から行うことができます。

財務ディレクターは、資金支出のリクエストを「承認」、「延期」または「拒否」することができます。「ステータス変更」→「同意する」を選択すると、承認が必要な申請にチェックボックスが付きます。キュー内の残りの申請は、文書ログ「申請の承認」で確認できます。

申請が承認ルートを通過していない（申請ステータスが「承認」でない）場合、それに基づいて支払い文書を発行することはできません。

アプリケーションが承認ルートを通過し始めた場合、アプリケーションを変更できます。

現在申請が承認されているユーザー。

承認の上位段階でアプリケーションを承認するユーザー。

他のユーザーはアプリケーションを変更できません。

アプリケーションが「承認済み」状態の場合、変更はできません（編集が非アクティブになります）。そのため、購買担当者に対してアプリケーション内のフィールドは灰色になり、変更できません。

3. 承認された申請に基づいて、購買会計担当者は、IP Dobronravov のサプライヤーへの前払いの発行のために、「支払済み」マークのない取引タイプ「サプライヤーへの支払い」の現金領収書を作成します（図 11）。

注記, 購買担当者が作成した入金指示書では、「管理会計に反映する」と「業務会計に反映する」のチェックボックスのみがチェックされていることがわかります。「支払済み」チェックボックスは、現金受領オーダーの正しい構成を確認した後、上級レジ係によってチェックされなければなりません。また、どのアプリケーションに基づいて現金受領書を生成しているかを現金受領書に示します。

現金受領オーダーに管理会計のみのチェックボックスがある場合、そのような伝票では転記 (会計レコード) は生成されません。しかし、彼は蓄積簿に「償却用の現金」と「取引相手との決済」を記入します（図12）。この情報は、「未払いの送信書類」セクションの「支払いカレンダー」レポートに入力されます (図 13)。

4. 上級レジ担当者は現金受け取り注文を確認し、「支払い済み」チェックボックスをオンにして現金を発行します。

現金受領書の支払いが完了すると、文書内のフィールドが灰色になり、この例の購買会計士やその他の参加者は編集できなくなります。特定のユーザーに設定されているアクセス権に応じて、特定のドキュメント、ドキュメント内のフィールドなどを編集できる場合があります。

注記：多数のレジがあり、それぞれのレジで「有料」チェックボックスをオンにする必要がある場合は、ディレクトリとドキュメントのグループ処理 (メニュー項目「サービス」) を使用できます。この処理に進むには、完全なインターフェースのメニュー項目「サービス」に移動します (図 14)。

詳細を変更するには、「設定」ボタンをクリックし、「オブジェクトの詳細の変更を許可する」フラグを選択します。分析を容易にするために、「すべての列を表示」フラグを設定しましょう (図 15)。

グループ処理を使用して、現金受け取りオーダーに「支払い済み」フラグを置きたいと考えています。これを行うには、グループ処理の「選択」セクションで、StroyTorg LLC という組織を指定します。オプション「有料」-「いいえ」を使用して、2013 年 1 月 1 日から 2013 年 1 月 21 日までの期間に処理されたドキュメントのみを選択します。

「処理中」タブの「選択」ボタンをクリックすると、「有料」のマークを付ける必要がある書類が表示されます（図16）。「アクション」行で、「詳細の変更[リンク.有料] - インストール」を選択します。そして「走る」。

詳細の値を変更した後、変更したドキュメントを再転記する必要があります。「アクション」フィールドで「変更: [ドキュメントを転記] - 設定 - 「実行」を選択します (図 17 を参照)。

5. 現金会計担当者は、現金受領書を確認します (会計および税務会計記録に反映するためのボックスにチェックを入れて、会計および税務会計の仕訳が生成されるようにします)。

さらに、たとえば、営業日の終わりに、現金取引の会計担当者は、「支払済み」とマークされているすべての現金出注文をチェックし、文書内の BU および NU ボックスにチェックを入れて、文書に会計および税務会計エントリが生成されるようにします。 (図18)

注記： BU および NU ボックスをチェックする必要がある現金領収書の注文が多数ある場合は、「参考図書および文書のグループ処理」を使用できます (図 19)。

ディレクトリと文書のグループ処理では、文書「現金支出命令 [TC: 支払デコード]」を選択します。その表部分で、「会計に反映する」チェックボックスをオンにする必要があります。

「選択」フィールドでは、どの組織の文書を選択する必要があるかを示し、2013/01/01 から 2013/01/21 までの期間に処理された文書 (および現金領収書) のみに関心があることを示します。「会計に反映する」チェックボックスがチェックされていない）会計」）。すべてのパラメータを入力した後、「選択」ボタンをクリックすると、指定した条件を満たす文書が選択されます。処理画面下部の「属性変更」－「反映」を選択します。会計「 - 「インストール」を選択し、「実行」ボタンをクリックします。書類が処理された後、再転記する必要があります (図 16)。次に、同じことを繰り返す必要がありますが、「税務会計に反映する」ボックスにチェックを入れる必要があります。

「現金支出命令」という文書を転記すると、会計口座だけでなくレジスターにも動きが発生します（図20、21）。