最初のものは「在庫管理」の問題に対処します。
システムが超過残高を制御する方法。
1Cの用語では、 運用と非運用の2種類のドキュメントがあります。
動作モードは、ビジネストランザクションの事実が現在の時刻に記録されることを意味し、 非動作モードは、ビジネストランザクションが現在の時刻から数秒前であっても過去に反映されることを意味します。
1Cプログラムの典型的な構成のイデオロギーでは、 非稼働モードで残りの商品をチェックする必要はないと考えられるという大きな秘密を明らかにしません。
システムの初期バージョンでバランスを制御するための本格的なメカニズムが欠如している理由については説明しませんが、オンラインモードでのみバランスを制御することは実際のワークフローにはあまり適していません。 多くの場合、ドキュメントは受信時に入力され、通常は遡及的に入力されます。
どのように機能しますか？
私の記事では、基本構成として、最大数のサブシステムが含まれているため、SCP（製造企業の管理）を検討します。 提示された方法は、「無料残高」の登録がある他の1Cシステムにも適しています。
システムにはデモデータが含まれており、「Free Balances」制御メカニズムが有効になっています。
レジスタ自体について少し。
このレジスターは少し前にSCPに登場しましたが、その外観は製品バランスに関するデータを1か所にまとめる必要があったためです。また、バッチが使用されなかったRUAZ（コスト分析の拡張会計）の戦略的進歩により、製品バランスをパーティーレジスターから分離しました。
さらなる開発では、商品バランスのすべての制御はそれに基づいています。
しかし、問題に戻りましょう。 過去の期間に、故意に過大評価された金額で複数の文書を実行した後、システムが超過に応答しないことがわかります。
実際に何が起こるか見てみましょう。
モジュール内のシステム内のすべての文書には、残差制御を処理するブロックがあります。 通常、次のようになります。
すべて順調です。 コントロールがあるようです。 しかし、実装に失敗しました（ F12キー）。 上記のすべてが表示されます。 システムは、運転バランスのみを制御します。
制御なしのシステムは、過去の期間に入力されたドキュメントのほとんどをスキップします。 文書がアーカイブにあり、真実を見つけることができない月を閉じるときではなく、オペレータが手元にプライマリドキュメントを持っているとき、その出現時にデータエラーを報告することは論理的です。
完全に異なるプロジェクトを開始するたびに、最初に閉じなければならなかったのは、まさにバランスの制御におけるこのギャップでした。 この1つのアクションのみが、システムデータの品質と全体としての有用性を大幅に向上させることができます。
非運用行為の処理を補完します。
良いニュースです。
大幅な変更は不要で、すべての改善は4行に削減されます。
1.実行が実行可能でない場合、手順の終了をブロックします。
// <> . // ; //;
2.リクエストに、残りの日付を取得する日付を決定するパラメーターを追加します。
| ..(&,
3.さらに、このパラメーターをリクエストに渡します。
.("", ?(=.,(), (..(),.)));
確認します。
過去の期間にドキュメントを作成し、残高を超えた場合にシステムがその実装をブロックするようにします。 さらに、レポート「倉庫内の商品の在庫状況の分析」を使用します。
結論
この記事では、典型的な1Cシステムを改善する方法の1つを取り上げます。 ドキュメントを保持する方法とその機能について話しました。 数回のストロークでシステムデータの品質を大幅に改善できることが示されています。
ご清聴ありがとうございました。
PS著者によって提案されたソリューションは、単純さとアクセス性に特徴がありますが、以下の記事で説明されているように、100％の保証はありません。