しかし、この記事を読むのをやめないでください。これは主なアイデアではありません。 主なことは、論理的なtrapに陥ることではなく、1Cが企業内のすべてのプロセスの自動化のどの部分においても絶対に不可欠であると考えないことです。 議論するべきものと提供するものがあります。 コンピューター会社のビジネス活動の最も多様な側面を自動化した1つの成功した経験、そしてもちろん、このソリューションを1Cにドッキングすることについてお話したいと思います。 自主開発システムと1Cプログラムを組み合わせる必要から生まれましたが、このアプローチ（2つのプログラムブロックに分割）は、一般的な情報システム構築の本格的な哲学に発展させることができます。
当初、タスクは次のとおりでした。 Microsoft Accessで記述された企業自動化システムがありました。 長い年月の開発を通じて、銀行の維持、請求、出荷用の会計文書の発行、倉庫の保管、シリアル番号によるコンポーネントの会計、生産カードの作成など、ほぼすべての日常業務を吸収してきました。 最近、システムの機能が追加されました：入金口座に基づいて銀行支払いを直接作成する、Webリソースで公開するためのさまざまな形式で価格表を自動生成する、会社のWebサイトを更新する、既存のテンプレートに基づいて契約を作成する（いわゆるオフィスオートメーション） 。 さらに、多数の分析の存在とすべての管理会計の維持。 これにより、システムは完全に不可欠になりました。この機能をすべて1Cに移行するには、多くの時間と費用がかかります。
一方、1C-Enterpriseプログラムは、会計および会計情報と報告を維持するための簿記のニーズのみに対応しました。 したがって、1Cは会社の日々の機能から「解かれ」、実施された文書は事後データベースに入力されました。
そのようなスキームは何に適していますか？ いくつかの利点があります。
-「神聖」の管理者およびその他の（責任のない）責任者の不容認-会計ベース。これは、主題についての考えを持つ従業員によってのみ形成されるべきです。 正確な参考書
-それとは関係のないすべてのものの1Cからの削除：会計への反映を必要としない管理タスクから、会社に固有であり、部外者がアクセスすべきでない他のポイントまで、
-ライセンスの節約：1Cジョブには多額の費用がかかりますが、
-重要なポイント：上記のすべての追加機能を1Cの「内部」に直接実装する場合、製品の更新がリリースされたときに開発を継続的に行う必要があります。 もちろん、これは1Cプログラマーのほぼ一定の雇用を保証しますが、これはあなたが多くを節約できる場所です。
もちろん、ファットマイナスは、すべてのドキュメントを再確認してディレクトリを補充する必要があることです。
実際、これが主な仕事でした-二重の仕事から逃れるためです。
まず、あらゆる種類のディレクトリを処理する必要があります-まず第一に、これは請負業者と命名法のディレクトリです。 この種のプログラムで頻繁に発生するディレクトリ同期の問題は、実装が十分に発達しており、理解できるものです。 ただし、この場合、相互同期で2つのディレクトリを使用するのではなく、MS Accessにインストールされているソースオプションを1つ、1Cに単純に複製するという強い意思決定が行われました（フィードバックはMS Accessでこれが位置はすでにアンロードされています）。
このアプローチにより、タスクが大幅に簡素化されます。 純粋にアカウンティングのニーズについては、そのようなディレクトリでのポジションはほとんど必要ありません。また、定式化された原則に違反しないように、外部プログラムで開始します。 したがって、もう1つの一般的な問題を取り除くことができます-使用されている命名法のディレクトリの莫大な膨張。 以下は製品グループ「モニター」です
1Cディレクトリへのこのような恐怖のロード（およびほぼ毎週新しいモニターモデルが表示される）は、画面全体のフレームカラーとピクセル数のニュアンスがアカウンティングにまったく関係ないため、すべて1つの位置に収まるように構成できます。 そして、対角線のサイズは、正直なところ-それが0.5インチ異なっていればなおさらです。
さらに、外部プログラムでは、特にカウンターパーティディレクトリで、ディレクトリ内の重複した位置の組み合わせをはるかに少ない損失で解決することができます。
したがって、「1C」では、「精製」、クリーニング、および適切な形式のデータのみがアップロードされます。 アンロードは一定の周期で行うことができます-分割により、日中（またはより長い期間）に何かがキャンセル、変更、再度実行された場合、簿記をデバッグし、不必要な作業を回避できます-これらすべてはMS Access作業データベースで発生し、 「情勢は1Cに入っています。 さらに、この種のアンロードはバックアップ操作と同期でき、1Cデータベースの現在の状態が正しいことを常に確認できます。
もちろん、ドキュメントは自動投稿されません（これはカスタマイズできます）。 ちなみに、MS Accessデータベース自体は、倉庫で必要な商品の可用性をチェックします-出荷への借方記入（ジレンマは、請求書が現在の日付までに発行できること、借方記入に必要なすべてのアイテムが倉庫にあることを確認することです-つまり、購入または生産する必要があります... 1Cに文書を投稿します。どうやら、マネージャーはこれをマネージャーに信頼すべきではない-または会計担当者は常にマネージャーの背後にいるべきです）
実装について説明します。 1Cプログラムは、ADOメカニズムを介してデータ交換インターフェースをサポートします。 1Cの部分では、標準プログラムインターフェイスを使用してディレクトリおよびドキュメントの要素を作成します。そのため、このメカニズムの動作は1C実装の内部の詳細に依存しません。 一方、開発の主なスローガンは「可能な限り1Cの使用を最大化すること」でした。 したがって、MS Accessからのバンドルの最終的な実装では、取引相手の名前とTINのみが読み込まれました。データは、ビルトイン1Cメカニズムを使用して、法的エンティティと個人起業家の統一国家登録簿から「プルアップ」されました（銀行の詳細にも適用されます-BICによって更新されます）
クエリは外部MS Accessデータベースで作成され、1Cでロードするために必要なすべてのデータを準備します-取得して、ドキュメントおよびフィールドでソートします。
アンロードスキームは2つの段階で構成されます。 最初に、取引先と命名ディレクトリの新しい位置がロードされます。 割り当てられた1C GUIDがMS Accessに返されるため、2番目の段階ですべてのドキュメントをアンロードするときに、ディレクトリに正しいバインディングを設定します。 こんな感じ
このような情報システム構築のイデオロギーは、非1Cシステムを継承している企業だけでなく、MS Accessで大きな成果を上げているため、新しい法人の業務を組織化する際の基盤としても利用できると考えています。 このアプローチの利点は上記のとおりです。