1c XML 形式での汎用データ交換。 Universal Data Exchange を使用する場合の外観と機能。 では、なぜ KD3 が必要なのでしょうか? 長所と短所
- ビデオ – 21 時間の授業
- PDF形式の教材 - A4 117ページ
- 教師による解決策を含む 16 の実践的なタスク
コース形式、サポート
教材は注文の支払い後すぐに利用できます。サイトからダウンロードして、いつでも都合の良いときに学習できます。
サポートは、Web サイトのマスター グループを通じて提供されます。
マスターグループへのフルアクセスをアクティブ化する必要があります 購入後100日以内。
コースの関連性
コース教材は BSP バージョン 2.3.2.73 に関連しています。
古いバージョンの BSP を使用する予定がある場合は、BSP の「データ交換」サブシステムの操作メカニズムが変更され、インターフェイスも変更されていることに注意してください。
BSP の最新バージョン用の新しいコースが開発中で、数か月以内にリリースされる予定です。 ただし、BSP 2.3.2.73 以前のバージョンの場合は、現在のレートが関係します。
コース料金
9,700ルーブル
保証
私たちは2008年から教えており、コースの質に自信を持っており、 標準の60日間保証.
これは、コースを受講し始めたものの、突然考えが変わった（または機会がなかった）場合、決定を下すまでの 60 日間の期間があり、復帰した場合には 100 ドルを返金することを意味します。支払いの%。
分割払い
私たちのコースは、無利息を含む分割払いまたは分割払いで支払うことができます。 その中で 資料にすぐにアクセスできます.
これは個人からの 3,000 ルーブル以上の支払いで可能です。 最大150,000摩擦。
あなたがしなければならないのは、支払い方法「Yandex.Checkoutによる支払い」を選択することだけです。 次に、支払いシステムの Web サイトで [分割払い] を選択し、支払い期間と金額を指定し、短いフォームに記入します。すると、数分で決定結果が届きます。
支払いオプション
すべての主要な支払い方法を受け入れます。
個人から– カード支払い、電子マネー（WebMoney、YandexMoney）による支払い、インターネットバンキングによる支払い、通信ショップによる支払いなど。 追加利息なしを含め、分割払い（分割払い）で注文を支払うことも可能です。
ご注文を開始すると、2 番目のステップでご希望の支払い方法を選択できます。
団体や個人起業家から– キャッシュレス決済、配送書類が提供されます。 注文を入力すると、支払い用の請求書をすぐに印刷できます。
複数の従業員のトレーニング
私たちのコースは個人学習向けに設計されています。 ワンセットでの集団トレーニングは違法配信です。
企業が複数の従業員をトレーニングする必要がある場合、通常、コストが 40% 安い「アドオン キット」を提供します。
「追加キット」をご注文いただくには フォームで2つ以上のコースセットを選択してください、第2セットから コース料金が40％安くなります.
追加キットを使用するには 3 つの条件があります。
- 通常セットを少なくとも1つ以前に（または一緒に）購入していない場合、追加セットのみを購入することはできません。
- 追加セットに対するその他の割引はありません（すでに割引されており、「割引の上の割引」となります）。
- 同じ理由で、追加のセット (たとえば、7,000 ルーブルの補償) にはプロモーションは無効です。
印刷 (Ctrl+P)
ユニバーサルフォーマットによる交換
標準サブシステムのライブラリの「データ交換」サブシステムには、さまざまな情報ベース間の情報交換のための 4 つのオプション (テクノロジ) が含まれています。
- 分散情報ベース (RIB)。
- ユニバーサルフォーマットによるデータ交換。
- 交換ルールに従ったデータ交換 (交換ルールは「データ変換」構成、エディション 2.1 を使用して作成されます)。
- 交換ルールなしのデータ交換。
この記事では、 ユニバーサル EnterpriseData フォーマット。 このテクノロジは、バージョン 2.3.1.62 以降の「標準サブシステム ライブラリ」で利用可能です。 2016年初頭にリリースされました。 現在、BSP 2.3 の最新版 (互換モードが無効になっているバージョン 8.3.8.1652 以上の 1C:Enterprise 8.3 プラットフォームで使用する場合) のリリースは 2.3.6.17 です。
米。 1 BSP 2.3 の最新リリース
1C アプリケーション ソリューションを提供するためのファイルの中には、テキスト ファイル「ライブラリ バージョン」があり、アプリケーションが開発された BSP のバージョンに基づいて記述されています。たとえば、アプリケーション ソリューション UT 11.3.3.231 に基づいて、 BSP 2.3.5.65 が作成されました。
「1C:Enterprise 8.3」プラットフォームのバージョンで使用する場合は、それ以下のバージョンではないことに注意してください。 8.3.10.2168 互換モードが無効になったエディションがリリースされました BSP2.4。
EnterpriseData 形式の説明
EnterpriseData 形式とは何ですか?
これは、情報ベース オブジェクト (取引先、請求書など) を記述したり、このオブジェクトが削除されたという事実を報告したりできる形式です。 EnterpriseData 形式でファイルを受信する構成は、それに応じて反応することが期待されます。つまり、新しいオブジェクトが作成され、ファイル内で削除済みとしてマークされているオブジェクトが削除されます。 これは、UT、RT、UNF、BP 構成間の情報交換を目的としています。 この形式は、他の情報システムと情報を交換するためにも使用できます。この形式は、交換に参加する独自のソフトウェアの機能や情報ベース構造に依存せず、使用に対する明らかな制限もありません。
EnterpriseData フォーマットのバージョン
図に示すように、フォーマット データは、一般的なデータベース構成ブランチの XDTO パッケージに保存されます。 2
図 2 XDTO – EnterpriseData データ形式パッケージ 図では、 2 は、複数の XDTO パッケージがあることを示しています。 これらは形式の異なるバージョンです。 フォーマットのバージョン番号は X.Y.Z で構成されます。X.Y はバージョン、Z はマイナー バージョンです。 マイナー バージョンは、バグ修正やその他の変更が行われた場合に増加します。形式の前のバージョンに基づくデータ変換ロジックの機能が維持されます (形式を通じて現在のデータ転送アルゴリズムの下位互換性が維持されます)。 変換ロジックの新しい形式機能のサポートは任意です。 このような変更の例としては、エラーの修正、フォーマット オブジェクトのプロパティの変更、データ変換時に使用が必須ではないプロパティの追加などが挙げられます。 他のケースでは、形式が変更されるとメジャー バージョンが増加します。X – グローバル再構築の場合、Y – その他の場合。
この形式は、オブジェクト (ドキュメントまたはディレクトリ要素) の表現を XML ファイルの形式で記述します。 バージョン 1.0.1 には、さまざまな分野 (財務、生産、購買と販売、倉庫業務) の 94 個のオブジェクトの説明が含まれています。 タイプの名前は、通常、よく理解されており、追加の説明は必要ありません。たとえば、「Document.Act of Completed Work」や「Directory.Counterparty」などです。 ご覧のとおり、ドキュメント タイプの説明は接頭辞「Documentary.」で始まり、ディレクトリ要素は接頭辞「Directory.」で始まります。 形式の詳細な説明はこちらをご覧ください。
最新バージョンは 1.3 ですが、最も一般的に使用されているバージョンは 1.0 です。 バージョン間の違いはあまりありません。 フォーマット EnterpriseDataExchange_1_0_1_1
Webサービス経由でやり取りする際に使用します。
ご了承ください EnterpriseData データ形式パッケージが一緒に使用されること メッセージ交換変換ルールを作成するとき。 type オブジェクトが含まれるのはこのパッケージです 追加情報これは任意の値タイプを持つことができ、構成オブジェクト間の変換ルールを作成するときに使用されます。 データ形式ではないもの。 まさに、ありがとう 追加情報XDTO パッケージ内の形式データを変更せずに、交換ルールを適応およびカスタマイズできます。
米。 3 XDTO パッケージExchangeMessage の構造 EnterpriseData 形式でデータを交換するにはどうすればよいですか?
EnterpriseData 形式のデータと構成の交換はファイル交換です。 外部アプリケーションから受信したファイルに応答して、構成はそれを処理し、応答ファイルを作成します。 ファイルは次のように交換できます。
- 専用のファイルディレクトリを介して、
- FTPディレクトリ経由で、
- 情報ベース側にデプロイされた Web サービスを通じて。 データ ファイルはパラメータとして Web メソッドに渡されます。
注記。 サードパーティ アプリケーションと情報ベース側の設定の間で双方向のデータ交換を行うには、多くの設定を行う必要があります。サードパーティ アプリケーションを情報ベースに登録し、交換チャネルを定義する必要があります (ファイルまたは FTP ディレクトリ) など。 ただし、単純な統合の場合、サードパーティ アプリケーションからインフォベースに情報を転送するだけで十分で、インフォベースからサードパーティ アプリケーションへのデータの逆転送は必要ありません (オンライン ストアの統合など)。売上情報を1C:会計に転送する）には、Webサービスを介して作業する、側で設定を必要としない簡易バージョンがあります。
同期中に構成交換プランを使用して交換する場合、最後の同期以降に発生した変更に関する情報のみが送信されます (転送される情報量を最小限に抑えるため)。 初めて同期するとき、構成はすべての EnterpriseData 形式のオブジェクトを XML ファイルにダンプします (サードパーティ アプリケーションにとってはすべて「新しい」ため)。
次のステップはサードパーティ アプリケーションです。サードパーティ アプリケーションは XML ファイルからの情報を処理し、次の同期セッション中にその情報をセクションに配置する必要があります。
受信メッセージを受信した後、構成は、前のメッセージで送信されたすべての変更を正常に同期されたものとしてマークします。 次回の同期セッションでは、オブジェクトに対する非同期の変更 (新しいものの作成、既存の変更と削除) のみが外部アプリケーションに送信されます。
外部アプリケーションから構成にデータを転送する場合、図は反転します。 申請書はセクションに記入する必要があります
ファイルの処理後、構成は受信メッセージと、構成側からの同期用の新しいデータ (最後の同期セッション以降にデータがある場合) を含む XML ファイルを生成します。
1C:Enterprise プラットフォーム上のアプリケーション ソリューションとのデータ交換の詳細を EnterpriseData 形式で確認できます。
「ユニバーサルフォーマットによる交換マネージャー」の汎用モジュール。
情報ベースから交換フォーマットにデータをダウンロードするためのルールと、交換フォーマットから情報ベースにデータをロードするためのルールを完全に記述する手順と機能は、共通モジュール、つまりユニバーサルフォーマットを介した交換マネージャモジュールで開発されます。
米。 4 ユニバーサルフォーマットによる交換マネージャーモジュールの構造 モジュールは、「データ変換」構成、エディション 3.0 を使用して、構成された交換ルールに基づいて自動的に作成されるか、コンフィギュレーターで手動で作成されます。
このモジュールはいくつかの大きなセクションで構成されており、各セクションには独自のプロシージャと関数のグループが含まれています。
- コメント。 モジュールの最初の行には、変換の名前を含むコメントが含まれています。 この行は、たとえばデータ変換プログラム (エディション 3.0) でコマンドを使用するときにモジュールを識別するために必要です。 // 2017/06/01 19:51:50より変換UP2.2.3
- 変換手順。 データ同期のさまざまな段階（変換前、変換後、遅延充填前）で実行される事前定義された手順が含まれています。
- データ処理ルール (DPR)。 データ処理のルールを記述したプロシージャと関数が含まれています。
- オブジェクト変換ルール (OCR)。 オブジェクトを変換するためのルールと、これらのオブジェクトのプロパティを変換するためのルールを記述するプロシージャと関数が含まれています。
- 事前定義されたデータ変換ルール (PDC)。事前定義されたデータを変換するためのルールを入力するプロシージャが含まれています。
- アルゴリズム。 他のルール (POD または PKO) から呼び出される任意のアルゴリズムが含まれます。
- オプション。変換パラメータを入力するためのロジックが含まれています。
- 一般的用途。 ルールとアルゴリズムで広く使用されるプロシージャと関数が含まれています。
マネージャーモジュールの各種プロシージャで使用されるプロシージャおよび関数のパラメータを以下に説明します。
コンポーネントを交換します。 タイプ - 構造。 交換セッションの一部として初期化されるパラメータと交換ルールが含まれます。
交換の方向。 タイプ - 文字列。 「送信」か「受信」のどちらかです。
IBデータ。 タイプ – ディレクトリオブジェクトまたは ドキュメントオブジェクト.
コンバージョンイベントに関する手続き
変換プロセス中に呼び出される事前定義されたプロシージャが 3 つあります。
- 変換前。 データ同期が行われる前に呼び出されます。 通常、このプロシージャには、さまざまな変換パラメータの初期化、デフォルト値の設定などのためのロジックが含まれています。パラメータ: コンポーネント交換.
- 変換後。 データ同期が完了した後、遅延パディングが発生する前に呼び出されます。 オプション: コンポーネント交換.
- 遅延前充填。 遅延充填が発生する前に呼び出されます。 遅延充填の対象となるオブジェクトのテーブルをソートまたは調整するためのロジックは、ここにあります。 オプション: コンポーネント交換.
AMLの手順
データ処理ルールを入力します。 データ処理ルールを入力するためのロジックを含むエクスポート プロシージャ。 特定のオブジェクトを処理するためのルールをルール テーブルに追加する他のプロシージャへの呼び出しが含まれます (以下の手順を参照) AMLの追加）。 オプション: 交換の方向性, データ処理ルール
UNDER_ を追加<ИмяПОД>。 特定のオブジェクトのルールに基づいてテーブルにデータを設定する一連のプロシージャ。 このようなプロシージャの数は、データ変換プログラム バージョン 3.0 でこの変換に提供される AML の数に対応します。 オプション: データ処理ルール(交換セッションの一部として初期化された値のテーブル)。
下_<ИмяПОД>_処理時。 プロシージャにはハンドラテキストが含まれています 処理中特定の AML の場合。 ハンドラーは、オブジェクト レベルで変換ロジックを実装するように設計されています。 たとえば、オブジェクトの内容に応じて、特定のオブジェクトに特定の PQO を割り当てます。 オプション:
- 情報Bデータまたは データXDTO(交換の方向によって異なります):
- 送信時 – オブジェクト ( ディレクトリオブジェクト,ドキュメントオブジェクト);
- 受信時 - XDTO オブジェクトの説明を含む構造体。
- PKOの利用。 タイプ - 構造。 キーには、PCO の名前と type の値を含む文字列が含まれます。 ブール値 (真実– PKOが使用され、 嘘– PKOは使用されません）。
- コンポーネント交換.
下_<ИмяПОД>_データサンプリング。 関数にはハンドラーテキストが含まれています 荷降ろし時。 ハンドラーは、アンロードするオブジェクトを選択するための任意のアルゴリズムを実装するように設計されています。 戻り値: アンロードされるオブジェクトの配列。 配列には、情報ベース オブジェクトへのリンクと、アップロードするデータを含む構造の両方を含めることができます。 オプション: コンポーネント交換.
PKO手順
オブジェクト変換ルールを入力します。 オブジェクトを変換するためのルールを入力するためのロジックを含むエクスポート プロシージャ。 特定のオブジェクト変換ルールをルール テーブルに追加する他のプロシージャへの呼び出しが含まれます (以下の手順を参照) PKOを追加）。 オプション: 交換の方向性, 変換ルール(交換セッションの一部として初期化された値のテーブル)。
PKO を追加_<ИмяПКО>。 特定のオブジェクトのルールを PKO テーブルに入力する一連のプロシージャ。 このようなプロシージャの数は、データ変換プログラム バージョン 3.0 でこの変換に提供される PKO の数に対応します。 オプション: 変換ルール(交換セッションの一部として初期化された値のテーブル)。
PKO_<ИмяПКО>_データ送信時。 プロシージャにはハンドラテキストが含まれています 送信時特定の PKO の場合。 ハンドラーはデータをアップロードするときに使用されます。 インフォベース オブジェクトに含まれるデータを XDTO オブジェクトの記述に変換するロジックを実装するように設計されています。 オプション:
- 情報Bデータ。 タイプ - ディレクトリオブジェクト, ドキュメントオブジェクト。 処理中の情報ベース オブジェクト。
- データXDTO。 タイプ - 構造。 XDTO オブジェクト データにアクセスするように設計されています。
- コンポーネント交換.
- スタックアップロード。 タイプ - 配列。 ネストを考慮して、アンロードされたオブジェクトへのリンクが含まれます。
PKO_<ИмяПКО>_XDTOデータを変換する場合。 プロシージャにはハンドラテキストが含まれています DataXDTO変換時特定の PKO の場合。 ハンドラーはデータをロードするときに使用されます。 任意の XDTO データ変換ロジックを実装するように設計されています。 オプション:
- データXDTO。 タイプ - 構造。 アクセスしやすくするために前処理された XDTO オブジェクトのプロパティ。
- 受信データ。 タイプ - ディレクトリオブジェクト, ドキュメントオブジェクト。 XDTO データを変換することによって形成される Infobase オブジェクト。 情報データベースには記録されていません。
- コンポーネント交換.
PKO_<ИмяПКО>_受信データを記録する前に。 プロシージャにはハンドラテキストが含まれています 受信データを記録する前に特定の PKO の場合。 ハンドラーはデータをロードするときに使用されます。 インフォベースにオブジェクトを記録する前に実行する必要がある追加ロジックを実装するように設計されています。 たとえば、変更を既存の情報セキュリティ データにロードする必要があるか、それとも新しいデータとしてロードする必要があります。 オプション:
- 受信データ。 タイプ - ディレクトリオブジェクト, ドキュメントオブジェクト。 XDTO データを変換して生成されるデータ要素。
このデータが情報ベースにとって新しい場合に記録されます (パラメータ 情報Bデータ値が含まれています 未定義).
さもないと 受信データ交換する 情報Bデータ(すべてのプロパティは 受信データに転送されました 情報Bデータ).
情報セキュリティ データを受信データと標準的に置き換える必要がない場合は、独自の転送ロジックを作成し、パラメータを設定する必要があります。 受信データ意味 未定義:
- 情報Bデータ。 タイプ - ディレクトリオブジェクト, ドキュメントオブジェクト。 受信したデータに対応する情報ベース データ要素。 一致するデータが見つからない場合は、次の内容が含まれます 未定義.
- プロパティの変換。 タイプ - 値の表。 交換セッションの一部として初期化される、現在のオブジェクトのプロパティを変換するためのルールが含まれています。
- コンポーネント交換.
PCPD手順
定義済みデータの変換ルールを入力します。 事前定義されたデータを変換するためのルールを入力するためのロジックを含むエクスポート プロシージャ。 オプション: 交換の方向性, 変換ルール(交換セッションの一部として初期化された値のテーブル)。
アルゴリズム
「データ変換」プログラム、エディション 3.0 では、AML および PKPD ハンドラーから呼び出される任意のアルゴリズムを作成できます。 アルゴリズムの名前、パラメータ、および内容は、ルールの開発時に決定されます。
オプション
ConversionParameters に入力します。 変換パラメータを含む構造体を入力するエクスポート手順。 オプション: 変換オプション（タイプ - 構造).
汎用プロシージャと関数
ManagerModuleプロシージャを実行します。 オプション: プロシージャ名（ライン）、 オプション（構造）。 エクスポート プロシージャ。非エクスポート モジュール プロシージャを呼び出すことを目的としており、その名前とパラメータが入力として受信されます。 メソッドを使用せずに、行でプロシージャまたは関数を呼び出すことができます。 実行する.
マネージャーモジュール関数を実行します。 オプション: プロシージャ名（ライン）、 オプション（構造）。 機能、目的は同様 マネージャーモジュールプロシージャの実行。 違いは、関数を呼び出してその値を返すことです。
1C 8 交換ルールを開発する場合、プログラムによって交換ルールの動作を再定義する機能、つまりハンドラー メカニズムが広く使用されます。 イベント ハンドラーは機能を大幅に拡張し、対話型の構成機能では不十分な場合に交換ルールを設定するために不可欠なツールです。
ハンドラーとアルゴリズムは、交換中に実行されるプラットフォームの言語で記述されます。
これが 1C: Enterprise 7.7 プラットフォームの場合、ハンドラー コードはアップロードまたはダウンロードの処理コードに統合されます。 したがって、各ハンドラーまたはアルゴリズムは個別の関数に分離され、交換中のデバッグに利用できます。
アップロードまたはダウンロードが 1C: Enterprise 8 プラットフォームで行われる場合、ハンドラー コードはデータ交換処理コードに統合されませんが、交換ルール ファイルにアップロードされます。 データ交換プロセス中に、ハンドラーまたはアルゴリズムのコードがルール ファイルから取得され、「Run」ステートメントのコンテキストで直接実行されます。 ハンドラーとアルゴリズムのコードをデバッグするには、「Universal XML Data Interchange」処理を使用できます。
自動制御システムはほとんどの場合、個別のデータベースで構成され、地理的に分散した構造になっていることがよくあります。 同時に、データ交換が正しく実装されることは、このようなシステムを効果的に運用するために必要な条件です。
1C:Enterprise プラットフォーム上の製品の場合のように、同種のソースを扱う場合でも、交換の初期設定には、プログラミングだけでなくコンサルティングの点でも多くのアクションが必要となる場合があります。 1C Exchange (または 1C 8.3 ではデータ同期とも呼ばれる) の設定が、統合プロジェクトの中で最も時間と費用がかかる作業になる理由について、この記事で説明します。
1C 環境でのデータ交換により、次のことが可能になります。
- 書類の二重入力を排除します。
- 関連するビジネスプロセスを自動化します。
- 分散した部門間のやり取りを最適化します。
- さまざまな部門の専門家の作業に関するデータを迅速に更新します。
- 異なる種類の会計を「区別」します。*
※ある会計のデータが別の会計のデータと大きく異なる場合、情報の機密性を確保し、情報の流れを「区切る」必要があります。 たとえば、1C UT と 1C Accounting の間のデータ交換では、管理データを規制会計データベースにアップロードする必要はありません。 1C での同期はここでは不完全になります.
オブジェクトの少なくとも 1 つが 1C プロダクトである場合に、プライマリ データ交換を実装するための標準プロセスを想像すると、次の段階を区別できます。
- 取引所の構成の調整。
- トランスポート (交換プロトコル) の定義。
- ルールの設定。
- スケジューリング。
1C交換の組成の特定
交換の対象は「送り手」と「受け手」に分けられます。 同時に 2 つの役割を同時に実行できます。これを双方向交換と呼びます。 送信元と宛先は、システムのニーズや機能に応じて論理的に決定されます。*
※例えば、「1C:Enterprise」をベースに開発された財務会計保守・財務管理ソリューション「WA:Financier」を統合する場合、WiseAdviceの専門家はマスターシステムとして推奨しています。 これは、アプリケーション ポリシーのルールに準拠し、それに応じてソリューションの有効性を確保するための制御ツールが利用できるためです。
次に、ユーザーから受信および記録された要件に基づいて、交換するデータのリストが作成され、その量と交換頻度の要件が決定され、エラーへの対処と例外状況 (衝突) の処理プロセスが規定されます。
同じ段階で、既存のシステムのフリートと企業の構造に応じて、交換形式が決定されます。
分散型情報ベース
- RIB は、各交換ペアに明確な「マスター/スレーブ」制御構造を備えた、同一の 1C データベース構成間の交換を意味します。 テクノロジー プラットフォームの要素として、RIB はデータに加えて、データベースの構成変更や管理情報を送信できます (ただし、マスターからスレーブにのみ)。
1C でのユニバーサル データ交換
- 1C:Enterprise プラットフォーム上の構成とサードパーティ システムの両方で、1C データベースの交換を構成できるメカニズム。 交換は、「交換計画」に従ってデータをユニバーサル XML 形式に転送することによって実行されます。
エンタープライズデータ
- 1C の最新開発。1C:Enterprise プラットフォームで作成された製品と自動化システムの間で XML 形式のデータ交換を実装するように設計されています。 EnterpriseData を使用すると、交換に関連する変更が簡素化されます。 以前は、新しい構成がシステムに含まれる場合、そのシステムと既存のシステムの両方に対して、データをインポートおよびエクスポートするためのメカニズムを実装する必要がありました。 現在、EnterpriseData をサポートするシステムには変更が必要なく、入り口と出口のポイントが 1 つだけあります。
トランスポート（交換プロトコル）の定義
1C:Enterprise 8 プラットフォーム上のシステムでは、一般に受け入れられている普遍的な標準 (xml、テキスト ファイル、Excel、ADO 接続など) を使用して情報リソースとの交換を組織するための幅広い可能性が提供されています。 したがって、交換データのトランスポートを決定するときは、サードパーティ システムのデータベース機能に依存する必要があります。
ディレクトリの同期
ディレクトリを効果的に同期するための基本原則は、単一のエントリ ポイントが存在することです。 しかし、歴史的に異なるルールに従って入力されてきたディレクトリの操作について話している場合、交換を「共通項」にするために同期フィールドを明確に定義する必要があります。
※この段階で、データソース側で参照データを正規化する作業が必要になる場合があります。 ディレクトリとそのボリュームの状態に応じて、要素の比較、エラーと重複の認識、特定、および欠落フィールドの埋め込みと同期フィールドの割り当てのプロセスには、専門家のグループ全体の作業が必要になる場合があります。インテグレーターの一部 (マスターデータ正規化技術の所有者) と顧客側の両方です。
ルールの設定
ソース システムからのデータを受信側で表示できるかどうかは、正しく定義された交換ルールに依存します。 XML 形式で示されるルールは、ソースとレシーバーのオブジェクトの主要な詳細の対応を規制します。 1C:Data Conversion ソリューションは、1 回限りの交換と永続的な交換の両方を実装するためのルールの作成を自動化するように設計されています。
交換プランでは交換中のデータ損失がないことを保証します。 これは、1C:Enterprise プラットフォーム上のあらゆる構成に不可欠な部分であり、1C 交換手順、つまりデータ構成 (詳細を「識別」するドキュメント) とノード (受信機と送信機の情報ベース)、および RIB のアクティブ化を完全に記述します。選択された交換方向。
交換計画に入力されたデータの変更はすべて記録され、「変更」のサインが表示されます。 変更されたデータが受信側と送信側のノードで一致するまで、符号はリセットされず、システムは両方のノードに制御メッセージを送信します。 データをアップロードし、両方のシステムで完全に準拠していることを確認した後、サインはリセットされます。
1Cでの交流スケジュール
定期的なやり取りを自動化するために、データのアップロード頻度を設定します。 交換の頻度は、ニーズと技術的能力によって異なります。 また、1C:Enterprise プラットフォームの構成では、イベント発生時のデータ交換を構成できます。
交換を実装する標準的なプロセスを検討したので、さまざまな段階で改善が必要となる要素に注目してみましょう。
- 非標準の、高度に変更されたデータベース構成。
- 1C:Enterprise プラットフォームのさまざまなバージョン。
- 長期間更新されていない構成バージョン。
- 以前に変更が加えられた交換対象。
- 非標準の交換ルールの必要性。
- 既存の参考書とはまったく異なる詳細の設定と構成。
一次データ交換を実装するための標準的なアクションでも専門知識が必要なため、1C 専門家の参加を得て実行することが推奨されます。 上記の手順をすべて完了した後でのみ、構成での交換のセットアップに進む必要があります。 1C:UPP と 1C:Retail の例を使用してデータベースの統合を見てみましょう (1C:UT との交換は同じスキームを使用して設定されます)。 標準同期には、SCP 間の交換も含まれています。これは、最大規模の産業企業の大規模自動化システムでは一般的です。
[サービス] サブメニューで、[プラットフォーム上の製品とのデータ交換...] を選択します ([小売] との直接交換を選択すると、COM オブジェクト レベルでエラーが発生することがよくあります)。 「この機能は利用できません。」というサービス メッセージに注意してください。
この問題を解決するには、「通信の構成」を選択する必要があります。
...ボックスにチェックを入れます。 次に、エラー メッセージを無視します。
データ同期設定で、「「小売」との取引所を作成...」を選択します。
ローカルまたはネットワーク ディレクトリを介して接続設定を構成する前に、ディスク上にディレクトリ用のスペースがあることを確認する必要があります。 原則として、30 ～ 50 MB を超えることはありませんが、例外的に、最大 600 MB が必要になる場合があります。 必要なディレクトリはコンフィギュレータから直接作成できます。
ネットワーク ディレクトリ経由で接続する場合、「次へ」をクリックして FTP アドレスおよび電子メールによる接続を設定するという提案は無視されます。
設定では、データベースのシンボルであるプレフィックス (通常は BP、UPP、RO) を手動で入力し、ルールとデータ アップロードの開始日を設定します。 ドキュメントの名前には、ドキュメントが作成されたデータベースを示す接頭辞が表示されます。 アップロード ルールが編集されていない場合、データはデフォルトで利用可能なすべてのパラメータに従ってアップロードされます。
私たちは同じ行為を繰り返さないように、「Retail」用の交換設定ファイルを作成します。 同期設定後すぐにデータを送信する必要がある場合は、チェックボックスをオンにします。
交換プロセスを自動化するには、スケジュールを設定する必要があります。
メニュー「小売」。
チェックボックスをオンにして「同期」を選択します。
Production Enterprise Management を選択して、「逆」セットアップを実行します。
UPPで作成した設定ファイルを読み込みます。
チェックを入れると、システムが自動的にアドレスを取得します。
UPP と同じように動作します。
検証データの比較 (この作業は交換の実装プロセスで最も労力を要する可能性があるため、準備段階で手動でデータを比較することをお勧めします)。 マウスをダブルクリックすると比較ウィンドウが開きます。
同期エラーが発生した場合、「詳細...」は「なし...」に置き換えられます。
「詳細...」では、交換に関する更新情報が記載されたログが開きます。
準備ができて。
構成を変更せずに自動データ交換を行うために必要なものは次のとおりです。
1) 「XML形式のUniversal Data Interchange」の処理、ほとんどの標準構成に含まれています。 そこにない場合は、ITS ディスクまたはインターネットで簡単に見つけることができます。 構成では、「Universal XML Data Exchange」と呼ばれます。
2) データ交換ルール。「データ変換」を利用して作成しました。 マスターしなければならない仕事です。 ビデオコースやチュートリアルもあります。 例: http://programmist1s.ru/wp-content/uploads/2013/06/Konvertatsiya_dannyih._Metodika_rabotyi_i_primeryi.pdf
3) 外部処理、ロード/アンロード手順が含まれます。 作成を始めましょう:
外部処理がオブジェクト モジュール内に作成され、以下のテキストが含まれます (データベースとユーザーのデータを置き換えます)。 データを交換するための完全な権限を持つ別のユーザーを作成することをお勧めします。 この処理を、たとえば「Data Exchange.epf」と呼びます。
LaunchParameter = "Upload" の場合、Processing=Processing.UniversalXMLDataExchange.Create(); //アップロードに必要なパラメータを設定します（編集の場合はオプション） Processing.ExchangeMode="Upload"; Processing.LoadDataInExchangeMode=True; Processing.WriteRegistersRecordSets = True; Processing.RememberLoadedObjects=True; Processing.UseSelectionByDateForAllObjects=True; Processing.UploadOnlyAllowed=True; //!アップロードに必要なパラメータを設定します //これらのパラメータは再入力する必要があります 必須 //オブジェクトの日付によるアップロードの制限を設定します Processing.StartDate = CurrentDate() - 60*60*24*2; Processing.EndDate = "00010101"; //データをファイルにアップロードする場合は、False に設定します。True の場合、受信データベースにアップロードされます。 Processing.DirectReadingVIBReceiver=True; //アップロードされたデータの受信データベースがサーバーの場合は False。 ファイルの場合 - True Processing.InformationBaseForConnectionType=True; //!必須パラメータが再入力されました //データをファイルにアップロードする場合 If Not Processing.DirectReadingVIBReceiver then Processing.ExchangeFileName = "C:\Inbox\OlegA\Conversion\upload.xml"; //データをデータベースにアップロードする場合、それ以外の場合は Processing.PasswordInformationBaseForConnection="Admin"; Processing.ConnectionInfoBaseUser="スーパークール"; Processing.AuthenticationWindowsInformationBaseForConnection=False; //データ受信者がサーバーベースの場合 If Processing.ConnectionInformationBaseType = False then Processing.ConnectionInformationBaseServerName="MainServ"; Processing.InformationBaseNameOnServerForConnection="ブヒア"; //データ受信者がファイルデータベースの場合、それ以外の場合 Processing.InformationBasePlatformVersionForConnection="V82"; Processing.InformationBaseDirectoryForConnection="C:\Inbox\OlegA\Clients\Zeus BP20\Zeus BP20"; endIf; endIf; //交換計画に従ってアンロードするときの登録に関するアクション Processing.RegistrationDeletionTypeofChangesForExchangeNodesAfterUpload=0; // 0 - 登録を解除しません。 // 1 - 登録を解除します。 Processing.LoadExchangeRules(); //交換計画に従ってアップロードする必要がある場合は、このブロックを有効にして独自の交換計画ノードを送信します。 //Processing.UploadRulesTable.Lines の各ページに対して Cycle //Page.Enable=1; // PageLine ループからの各 Page1 について // Line1.Enable=1; // Page1.LinkToExchangeNode=ExchangePlans.Full. FindByCode("BP20"); //エンドサイクル; //エンドサイクル; Processing.Perform Upload(); シャットダウンシステム(False); ElseIf LaunchParameter = "Load" then ExchangeProcessing = Processing.UniversalXMLDataExchange.Create(); ExchangeProcessing.ExchangeFileName = "C:\Inbox\OlegA\Upload.xml"; ExchangeProcessing.ExchangeMode = "読み込み中"; ExchangeProcessing.OpenDownloadFile(True); ProcessExchange.ArchiveFile = False; ProcessExchange.PerformLoad(); ExchangeProcessing = 未定義; シャットダウンシステム(False); endIf;
4) Batファイルのアップロード、ユーザーの下で起動パラメーターを使用して 1C と外部処理を起動します。これはデータ交換を目的としています。 ファイルは、たとえば OEM (MS-Dos) エンコーディングを使用して notepad++ で作成する必要があります。そうしないと機能しません。 たとえば、ファイルに「BatVygruz.bat」という名前を付けます。 本文は以下のようになります。
データベースがファイルの場合:
"C:\Program Files (x86)\1cv82\common\1cestart.exe" ENTERPRISE /F"C:\Inbox\KBF\1Cv8_Base_8.1\Zeus 83 BP3\Zeus 83 BP3" /N"Data Exchange Robot" /P "pass " /DisableStartupMessages /RunModeManagedApplication /Execute"C:\Inbox\OlegA\DataExchange.epf" /C"Upload"
説明:
b) C:\Inbox\KBF\1Cv8_Base_8.1\Zeus 83 BP3\Zeus 83 BP3 - データのアップロード元となるファイル データベースへのパス
c) データ交換ロボット - データ交換のために 1C を実行するユーザー名
d) pass - ユーザーパスワード
e) /DisableStartupMessages - 1C の起動時にポップアップ ウィンドウを閉じる
e) /RunModeOrdinaryApplication - シック クライアントを通常モードで実行します。
g) C:\Inbox\OlegA\Data Exchange.epf - 起動時に開始される処理へのパス
h) アップロード - 1C 起動パラメータを渡します。データをアップロードする必要があることがわかります。
データベースがサーバーベースの場合:
"C:\Program Files (x86)\1cv82\common\1cestart.exe" ENTERPRISE /S"Server1C/DataBase" /N"Data Exchange Robot" /P"pass" /DisableStartupMessages /RunModeManatedApplication /Execute"C:\Inbox\ Oleg\ データ交換.epf" /C"アップロード"
説明:
a) C:\Program Files (x86)\1cv82\common\1cestart.exe - 1C スターターへのパス
b) Server1C/DataBase - データベースが配置されているサーバーと、データのアップロード元となるデータベース自体の名前。
残りのパラメータは、bat ファイルのファイル バージョンと同様です。
5) Bat ファイルのダウンロード (必要な場合)。データをデータベースに直接アップロードするのではなく、ファイルにアップロードする場合。 次に、このアイテムも必要になります（通常は必要です）。
Bat ダウンロード ファイルの作成はアップロード ファイルと似ていますが、起動パラメータのみが異なります。「アップロード」の代わりに「ダウンロード」を使用します。
6) 起動スケジュールを設定するサーバー上での Bat ファイルのロード/アップロード。 これを行うには、サーバー上のコントロール パネルの管理に移動し、タスク スケジューラで、毎日 23 時にダウンロード ファイルを実行する新しいタスクと、Bat ダウンロード ファイルを指定するダウンロード タスクを作成する必要があります (必要）たとえば04時。
