コンピューター ウィンドウズ インターネット

1cは、ユニバーサルフォーマットを介して交換のルールを変更します。 1Cは、ビジネスデータを交換するためのEnterpriseData形式を提供します。 EnterpriseDataフォーマットとは

この記事の目的は、KD3に関する最初の質問に答え、簡単な例を使用して、標準ルールを変更する方法を示すことです。 この情報は、初心者や、すでにマスタリングを始めて新しい質問がある人に役立ちます。

この出版物で受け入れられている略語

KD2-構成データ変換、リビジョン2.0。
KD3-構成データ変換、リビジョン3.0、構成3.0.5.3。
ED-ユニバーサル交換フォーマットEnterpriseData。

KD3との表面的な知り合いの後の質問への回答。 KD3が必要な理由がわかっている場合は、この段落をスキップできます;)

質問と回答

  • KD3はKD2の新しいバージョンですか? 番号! これは、KD2と同様の問題を解決する別のツールです。 各ツールには独自のアプリケーションがあります。
  • KD3はKD2よりも優れていますか? それらを比較することはできません。 それらは異なるツールであり、それぞれに独自の長所と短所があります。
  • KD3を交換するためのルールを変更するには、 サポートから構成を削除するには? 番号 サポートから撤退する必要はありません! 通常の構成では、外部処理をルールに標準で接続でき、プラットフォーム8.3.10以降をサポートする構成では、拡張機能を使用してルールを編集できます。
  • 社内構成からデータを転送する必要があります。 研究目的で、KD3を使用できますか? あなたがこの質問をしているなら、おそらくあなたはそうすることができません。 KD3の場合、構成には、ユニバーサル形式を介した同期を備えたBSP2.3以降が含まれている必要があります。 KD2は100%あなたに合うでしょう、KD3は疑わしいです。
  • KD3は、一般的な変更された構成に使用できますか? はい、できます。 非定型データをEDまたはAdditionalInfo小道具を使用して渡すことができる場合は、それで問題ありません。 それ以外の場合は、交換形式(XMLスキーマ)を変更するオプションがあります。 この場合、CD3の機能はCD2とほぼ同じになりますが、CD3の主な利点である交換フォーマットの多様性は失われます。
  • EDをサポートする構成は相互に交換できますか? はい! ただし、BP 3.0-BP 3.0の交換の場合、同期を作成するときにBP3.0を選択することはできません。 大丈夫です、「その他のプログラム」を選択してください。 1回限りの交換が必要な場合は、[すべての機能]メニューの[EnterpriseDataのアップロード/ロード]処理を使用するだけで十分です。
  • 構成を更新した後、配布キットから最新のルールをダウンロードする必要がありますか? 番号! ルールは構成モジュールに含まれています。 他の1Cデータベースと交換するために、別のデータベースのルールをロードする必要はありません。 どうして? この記事の詳細。
  • 1つのデータベースを更新した後、交換に参加している他のデータベースを最新の状態にする必要がありますか? 番号! 交換に参加しているすべてのデータベースを同期的に更新する必要はありません。 これがKD3の利点の1つです。
  • 構成が大幅に改善されました。新しいタイプのドキュメントとディレクトリがありますが、KD3はそれらを転送できますか? フォーマットを変更しないとできない可能性があります。 これは、KD2と比較したKD3の「欠点」の1つです。

では、なぜKD3が必要なのですか? 長所と短所

KD3の利点

頻繁に発生するタスクの例を使用して、KD3の主な利点を考えてみましょう。 UT 11.3構成がありますが、何らかの理由で更新されていません。 現在のリリースに絶えず更新されているBP3.0との交換を組織する必要があります。

問題ない。

  • KD3で使用されているユニバーサル交換フォーマットは、このような問題を解決するために設計されています。
  • UTの交換ルールは、BPとの交換用ではなく、ユニバーサル形式のEnterpriseDataとの交換用に作成されます。
  • KD2で運用している場合、UTはED構成と交換しますが、これは変更されません。 BP3.0もEDと交換されます。

各構成には、EDと交換するための独自のルールがあります。 したがって、UTは常に同じ形式でデータをアップロードします。 BP 3.0構成は、それがどれほど新しくても、この形式からデータを受信できるはずです。

UTは、BPがいくつかの詳細を変更するという事実を心配する必要がないことがわかりました。 タスクは単純です。EDにアップロードすると、PSU構成はこの形式のデータを受け入れることができるはずです。

  • ソースは常に1つの形式で構成をアップロードするため、どの構成レシーバーもこのユニバーサル形式からデータをアップロードできます。
    それらの。 交換の任意の組み合わせUT-BP、UT-KA、UT-ERP、KA-BP、ERP-BP。 個別のルールを作成する必要はありません。 KD3では、ルールは普遍的です。 ユニバーサルフォーマット交換をサポートする構成は、EDフォーマットをサポートする構成と交換できます。

アルゴリズムとルールのデバッグは、構成自体で利用できます。 すべてのルールはコードです 共通モジュールまたは外部処理。 KD3がなくても、エラーをすばやく修正できます。

KD2の短所

交換ルールは、構成のペアごとに個別です。 異なるタイプの構成と異なるバージョンの構成の間の交換の上記のすべての組み合わせには、独自の交換ルールが必要です。 したがって、UT11.3とBP3.0を交換するという上記の問題を解決するには、BP3.0を更新するたびに交換ルールをデバッグおよび改良する必要があります。

アルゴリズムとルールのデバッグは、初心者のプログラマーやこのタスクにめったに直面しない人にとっては困難です。 ルールはxmlファイルに保存されます。 利用可能なクイックフィックスはありません。 ルールをKD2にロードし、修正してアンロードする必要があります。

KD3の短所

ユニバーサルフォーマットは、ドキュメントとディレクトリのタイプに制限を課します。 これは、一般的な構成向けに設計されています。 非定型の必要条件またはタイプのドキュメントがある場合、交換が難しい場合があります。

ED形式で同期するには、構成がこれらのメカニズムをサポートしている必要があります。 これはすべてBSP2.3以降にあります。 これは実際にはマイナスではなく、むしろ機能です。

フォーマットをサポートするための限られた時間枠のため、メインプラスは少しフェードします。 これは、BP3.0と交換するUT11.1、UT11.2のユーザーによってすでに感じられています。 サポート時間はここにリストされています。 保証フォーマットの最低サポート期間は1年、実際には約3年とのことです。 したがって、今日同期を設定した場合、少なくとも1年間は、UT 11データベースを更新できません。その後、構成を更新するか、単に新しい形式を追加して、BSPとルールに小さな変更を加えます。必要であれば。 どうやってするの? この記事の後半で説明します。

KD2の利点

KD2の可能性は無限大です。 任意のプラットフォーム上の任意の構成の交換ルールを作成できます。 1C7.7から最後の8.3まで。 構成から何も必要ありません。BSPはオプションです。 ルールはで作成できます 自動モード洗練された。

上記の長所と短所に関連して、一般的な構成にはKD3を使用することをお勧めします。 KD2はどの構成にも使用できますが、その欠点を考えると、KD3を使用する方が便利な場合があることを忘れないでください。

KD3が必要な理由をご理解いただければ幸いです。今後もメリットを継続していきます。

さらに受け入れられた略語

BSP-標準サブシステムのライブラリ。
-データ処理ルール。
PKO-オブジェクト変換ルール。
PKPD-事前定義されたデータを変換するためのルール。
PKS-プロパティ変換ルール。

例を考えてみましょう-BP3.0とUT11.3の交換の標準ルールを変更する必要があります

黄色の背景に、KD3で開く手順の手順があります。 この記事で提案されている手順の順序は、混乱しないように、また開始されたアクションをすぐに論理的に完了するために異なります。

EDルールを変更するにはどうすればよいですか?
  1. モジュールを変更する構成内の交換ルールを使用します。 このオプションはまだ検討していません。 何をどこで変更する必要があるかを理解するには、KD3で少なくとも1回は変更する必要があります。 この場合、将来的には問題を迅速に解決し、モジュールでデバッグし、必要に応じてKD3に転送することが容易になります。
  2. KD3を使用する.
    これはKD2でどのように行われますか? 両方の構成のメタデータをアンロードし、KD2にロードします。
    ステップ1。 KD3の場合も同じことを行います。エンタープライズモードの各構成で、次の処理を行います。 \ tmplts \ 1c \変換\ 3_0_5_3 \ MD83Exp.epf構成メタデータをアップロードし、
    たとえば、フォルダ「 D:\ルールBP3 \ BP 3.0.54.15 \"、 ファイル名 " MD.xml».

この処理の設定がどのような目的で非表示になっているのかは明確ではありません。その結果、デフォルトでは、情報レジスタのデータはアンロードされません。 この欠陥を排除します。
メインフォームのChangeProcessingMode()プロシージャで、次の行をコメントアウトします。

// Elements.Settings.Visibility = False;

処理を保存し、エンタープライズモードで開き、「情報レジスタのアンロード」にフラグを設定して、アンロードします。

ステップ3。以前に作成したファイルをロードします MD.xml「KD3では、セクションフラグ」 V 新しいバージョン構成».

なぜなら KD3では、「中間構成」(ED)が交換に使用され、その「メタデータ」もロードされます。 XMLスキーマ、拡張子が「xsd」のファイル。 ステップ2。 UT11またはBP3.0構成から取得できます。 それらは同じです。 構成を開き、検索バーに「 入力"、私たちは木に見えます 一般-XDTOパッケージこのようないくつかのパッケージ: EnterpriseData_1_3_8、EnterpriseData_1_4_4など..これらは、それぞれ1.3と1.4の形式のバージョンであり、存在する場合は1.2、1.1、1.0のバージョンです。 右ボタンパッケージ上のマウス、 コンテキストメニュー選ぶ ""。

ステップ4。 KD3セクションで、拡張子が「xsd」の以前にアップロードされたファイルを選択します。 1つのファイルを選択する必要があります! と組み合わせた複数の選択肢 ExchangeMes​​sageは必要ありません! これは古いKD3の説明で提案されていました 以前のバージョン..。 最後のCD3では、これは必要ありません。

セクションにフォーマットをロードした後 データフォーマット-フォーマットオブジェクトツリー、フォーマットバージョンを選択します。 そこにドキュメントとディレクトリがある場合は、アップロードしています 正しいファイル..。 そうでない場合は、新しい空のCD3からやり直し、最初にフォーマットをロードして、ツリーを確認します。

ステージ2。メタデータをCD3にロードした後、標準の交換ルールのロードに進みます。
これはKD2でどのように行われますか? ルールは変換にロードされます。
KD3でもほぼ同じです。 標準のルールからルールをアンロードし、変換を作成してから、ルールをロードします。

CD3にロードするための構成からの一般的なルールのアンロード

構成は、交換フォーマットの最大共通バージョンで交換されます。 たとえば、1つの構成の最大フォーマットは1.5で、もう1つの構成は1.6です。これは、1.5フォーマットで相互に交換することを意味します。 したがって、両方の構成から1.5形式をアンロードし、ルールにロードするだけで十分です。

BP3.0またはUT11.3の構成をコンフィギュレーターモードで開きます。検索バーに「」と入力できます。 男性ユニ」、一般モジュールを開きます。 これがBP3.0の場合は、それを開きます。 開いているモジュールで、メニューに移動します ファイル-コピーを保存します、ファイルを任意の名前で保存します。例:「 D:\ルールBP3 \ BP 3.0.54.15 \ユニバーサルフォーマット経由の共通モジュールExchangeManager».
エンタープライズモードで構成BP3.0またはUT11.3を開き、処理を開きます \ tmplts \ 1c \変換\ 3_0_5_3 \同期ルールをアップロードします。epf

典型的な処理の欠如:

  • 多くの場合失敗します。
  • ノードに接続された外部処理からルールをアンロードしますが、一般的なルールが必要です。
  • BP3.0.53以降では機能しません。

メイン処理フォームのモジュールの変更。 手順を変更する OnCreateAtServer.

&AtServer Procedure OnCreateAtServer(Cancel、StandardProcessing)//選択したフォーマットバージョンのリスト。 フォーマットバージョン=新しい一致; データExchangeRedefinable.WhenGettingAvailableFormatVersions(FormatVersions); DataExchangeRepUsedExchangePlansBSPからの各ExchangePlanについて()サイクルIf DataExchangeRepeat.ThisExchangePlanXDTO(ExchangePlan)Then ExchangePlan Format Versions = New Match; BSP243バージョン= GeneralPurposeClientServer.CompareVersions(StandardSubsystemsServer.Libraryバージョン()、 "2.4.3.1")> = 0; ModuleDataServer =汎用。CommonModule( "Data ExchangeServer"); BSP243バージョンの場合ExchangePlaneFormatVersions = DataExchange ModuleServer.ExchangePlanSettingsValue(ExchangePlan、 "ExchangeFormatVersions"); それ以外の場合、ExchangePlans [ExchangePlan] .GetExchangeFormatVersions(ExchangePlanFormatVersions); EndIf; ExchangePlanFormatVersionからのExchangePlaneVersionごとにCycleManagerModule = FormatVersions.Get(ExchangePlaneVersion.Key); マネージャーユニット=未定義またはマネージャーユニットの場合<>ExchangePlaneVersion.Value Then FormatVersions.Insert(ExchangePlaneVersion.Key、ExchangePlaneVersion.Value); EndIf; サイクルの終わり; EndIf; サイクルの終わり; EachFormatVersion FROMFormatVersion.Loop Items.FormatVersionNumber.SelectionList.Add(FormatVersion.Key);の場合 サイクルの終わり; FormatVersionStoreAddress = PutToTemporaryStore(フォーマットバージョン、UniqueIdentifier); 手順の終了

  • 「フォーマットバージョン番号」を選択します。たとえば、「 1.3 »,
  • 「Exchangeディレクトリ」-「」などのフォルダを作成します
  • ボタンを押す " アンロード».

他のバージョンのフォーマットについてもこれらの手順を繰り返し、対応するフォルダ「1.4」、「1.5」などに保存します。BP3.0の場合、1.3以降のすべてのフォーマットをアンロードするだけで十分です。 1.2以降の他の構成の場合。

ルールがアンロードされたので、KD3にロードする必要があります。 KD2では、変換の作成と同時にルールがロードされます。 CD3では、変換を作成してルールをロードする必要があります。
KD3セクション 変換-変換-作成..。 ..。 構成の選択。 便宜上、要素編集モードに移動して構成の名前を変更できます。 たとえば、代わりに 会計企業示す " BP 3.0.54.15"。 小道具 名前変更する必要はありません! 名前変換は同じように指定できます。たとえば、「 BP 3.0.54.15"。 表のセクションで、サポートされている形式のバージョンを選択します。 フォーマットのバージョンは、上記のデータベースからダウンロードしたものです。 変換を保存します。

セクションに移動します 変換-ファイルから同期ルールをロードする.
:

    読み込み場所: " 既存の変換へ»

    交換ディレクトリ: " D:\ルールBP3 \ BP 3.0.54.15 \ 1.3»

  • 交換モジュールを使用したファイル: " D:\ルールBP3 \ BP 3.0.54.15 \ UniversalFormat13_Module.txt経由の共通モジュールExchangeManager»
  • 会話: " BP 3.0.54.15»

UT 11.3のファイルから同期ルールをロードすると、エラーが表示されます。 オブジェクトフィールドが検出されません"。理由はTekPKO.UseForReceive = Falseです。CD3は受信時に識別オプションに関する情報を必要とします。これがルールファイルにない場合、エラーが発生します。この誤解を修正します。このフォームをサポートから削除するか、拡大。

// LoadingSynchronizationRulesFromFilesを処理する主な形式//変更が行われる前://プロシージャは、オブジェクトを変換するためのルールをロードし、サーバー上でプロシージャLoadPKO()... FillProperty Values(TekPKO、Attribute Structure); //識別オプション-特別なロジック。 TekPKO.ObjectIdentification Option = Enumerations.Object Identification Options [AttributesStructure.Identification Option]; ElseIf XMLReader.NodeType = XMLNodeType.EndItem Then //ロードされたPOCを書き込みます。 ... //変更は「// ED」でマークされます//プロシージャはオブジェクトを変換するためのルールをロードします&サーバー上プロシージャLoadPKO()... FillProperty値(TekPKO、属性構造); //識別オプション-特別なロジック。 If TekPKO.UseFor Getting Then // ED TekPKO.Identification Option = Enumerations.Object Identification Options [Attributes Structure.Identifying Option]; EndIf; ElseIf XMLReader.NodeType = XMLNodeType.EndItem Then //ロードされたPOCを書き込みます。 ..。

ボタンを押す " ダウンロード». « ハンドラーは、BP 3.0.44(フォーマット1.4)という別の変換を目的としています。 ダウンロードを続行しますか?"クリック" はい».
フォームを閉じずに、別の「 Exchangeディレクトリ「そしてボタンを押してください」「。 各フォーマットのルールを現在の変換にロードすることを数回繰り返します。
ロードに成功したら、「」セクションに移動します。 変換 "-"変換ルールの構成"、リストフォームから変換を開きます。
PODなどが表示された場合、CD3へのロードは成功しています。

読み込みルールの正確さの確認

これはオプションの操作です! ルールで同じバージョンの形式を使用する場合は、モジュールテキストのIDを取得する必要はありません。

  • BP configuratorを開き、新しい外部処理を作成します。たとえば、Name“ EDBPの同期"、の同義語" 同期EDBP 3.0».
  • KD3では「 交換ルールの設定「」ボタンを押して、このコードをクリップボードから新しい処理に貼り付けます。
  • BP configuratorで、モジュールに構文エラーがないかチェックします。 処理を保存します。
  • BPに別の空の処理を作成します。たとえば、Name“ 同期EDB標準"、の同義語" 同期EDBP3.0標準"。 一般電源モジュールのテキストをコピーします UniversalFormat13を介したExchangeManager処理モジュールに保存します。

両方の治療法を比較してみましょう。 メニュー ファイル-ファイルを比較する.

標準モジュールにルールにないプロシージャが含まれている場合は、すべてのデータ形式の変換ルールをロードしていないことを意味します。 必要であれば欠落している形式のルールを変換にロードし、ルールと標準のルールの比較を繰り返します。 アイデンティティを達成したとき ルールの完成に安全に進むことができます..。 どの交換フォーマットが同期に使用されないかがわかっている場合は、完全なIDを取得する必要はありません。

同様の方法で、KD3でUT11.3の変換を作成します。

BP 3.0.54.15

  • 発見 誤った読み込み PKO " Reference_Users"。修正する必要があります。修正する必要があります。
  • PKOで」 Document_Product Inventory_Shipment「PKS用」 担当者「指定されていないPQS。開いて、構成プロパティとフォーマットプロパティを再選択し、タイプを入力します。その後、「 プロパティ変換ルール"。 選択する" Directory_Persons_Send".

改訂の例を考えてみましょう

この例の主な目的は、交換フォーマットに適合しない追加データを転送するための改善の可能性を示すことです。

小道具を転送する必要があります」 TypeNomenclature「参考書」命名法「変数の種類」 Directory.ViewsNomenclatures"。この種の参考書は、標準のKD3規則には含まれておらず、1.6より前のED形式バージョンではサポートされていません。

この問題を解決するためのいくつかのオプションがあります。

  • XDTOパッケージの変更、「Reference.NomenclatureTypes」オブジェクトをフォーマットに追加します。 その結果、ユニバーサルフォーマットの主な利点が失われます-それはユニバーサルではなくなります。 XDTOパッケージの変更は、交換に参加しているすべてのデータベースで必要になります。
  • フォーマットプロパティを使用する " 追加の詳細"、これは多くのオブジェクトに含まれています。このオプションは、複雑さがあるため、この記事では考慮されません。そのような方法があることに注意してください。
  • 小道具 追加情報。これは、すべてのフォーマットオブジェクトのヘッダーにあります。 いかなるタイプ。 そのような場合のために設計されています。 最も簡単な方法として使用します。

標準ルールの改良に進む前に、ルールグループに2つのグループを作成しましょう。 によって追加», « かわった"。 これは「 変換-".
新しいPOD、PKO、アルゴリズムなど。 「追加」グループで作成し、変更を加える標準オブジェクトを「変更」グループに転送します。 これにより、変更されたルールのその後の保守が容易になります。

それでは始めましょう。

UT11.3のルールの変更

KD3では「 UT11.3.4.12交換ルールの設定「タブで アルゴリズム新しいアルゴリズムの作成

  • アルゴリズム名「AdditionalInfoInsert」
  • グループ:「追加」

パラメータ: "DataXDTO、Name、AdditionalValue"

アルゴリズムコード

If DataXDTO.Property( "AdditionalInfo")AND TypeValue(DataXDTO.AdditionalInfo)= Type( "Structure")Then AdditionalData = DataXDTO.AdditionalInfo; それ以外の場合、AdditionalData =新しい構造; EndIf; AdditionalData.Insert(Name、AdditionalValue); DataXDTO.Insert( "AdditionalInfo"、AdditionalData);

アルゴリズムを保存して、「 オブジェクト変換ルール»

ボタンで「 探す「「命名法」を探して、PKOを開く」 Reference_Nomenclature_Send"。 タブに移動します " 送信時"。 「ハンドラー名:」「」フィールドが表示されます。 そこで直接変更を加えることができます。
デバッグが必要なより複雑なコードを構成に書き込むことができます。 UT 11.3の交換モジュールで、「 PQS_Reference_Nomenclature_Send_WhenSendingData「そしてそこでそれを完成させます。
変更をUT11.3からKD3に転送するには、手順全体をクリップボードにコピーし、「KD3」の形式でコピーします。 交換ルールの設定"ボタンを押す" "。

この例では、コードは次のとおりです。

If ValueFilled(DataIB.NomenclatureView)Then // ED AdditionalInfoInsert(DataXDTO、 "NomenclatureView"、String(DataIB.NomenclatureView.UniqueIdentifier())); AdditionalInfo Insert(XDTO Data、 "NomenclatureNomenclatureName"、General Purpose.ObjectAttributeValue(DataIB.NomenclatureView、 "Name")); // AdditionalInfo Insert ... //他のサービスの詳細を追加しますEndIf;

変更をKD3に転送した後、ボタン「 ExchangeManagerモジュールを保存します"そして、コードをバッファからUTモジュール11.3に転送します。

BP3.0でのルールの変更

PKOに変更を加えます」 Reference_Nomenclature_Getting"、" XDTOデータを変換する場合"、プロシージャ名" PKO_Reference_Nomenclature_Getting_WhenXDTODataConversion".

モジュール「PKO_Reference_Nomenclature_Getting_WhenXDTODataConversion」に追加されたコード

If DataXDTO.Property( "AdditionalInfo")AND TypeValue(DataXDTO.AdditionalInfo)= Type( "Structure")Then // ED AdditionalData = DataXDTO.AdditionalInfo; If AdditionalData.Property( "NomenclatureType")ThenNomenclatureType = ExchangeDataXDTOServer.ObjectLinkPoUIDObjectXDTO(AdditionalData.NomenclatureView、Type( "DirectoryLink.NomenclatureType")、Exchange Components); IfNomenclature.GetObject()= Undefined AND AdditionalData.Property( "NomenclatureKindName")Then // newNomenclatureKindObject = Directories.NomenclatureTypes.CreateElement();を作成します。 NomenclatureKindObject.SetNewLink(NomenclatureKind); 命名法typeObject.Name = AdditionalData.Nomenclature typeName; //他のサービスの詳細を入力しますFillPropertyValues(NomenclatureKindObject、AdditionalData); NomenclatureKindObject.Write(); NomenclatureKind = NomenclatureKindObject.Ref; EndIf; ReceivedData.NomenclatureType = NomenclatureType; EndIf; EndIf;

コードだけでは不十分です。 [プロパティ変換ルール]タブで、構成プロパティ ""とチェックボックス "を使用してPKSを追加する必要があります。 使用される変換アルゴリズム".

ExchangeManagerモジュールをBP3構成モジュールまたは外部処理に転送します。

CD3の変更されたルールをデータベースにアップロードするにはどうすればよいですか?

CD2でルールを交換する構成では、これはノード設定で行われます。 KD3で作成されたルールについては、登録ルールを変更する機会のみが表示されます。

KD3で作成されたルールは、3つの方法で構成にインストールできます。

  1. サポートから構成を削除し、共通モジュールに変更を加えます ユニバーサルフォーマットによるExchangeManager;
  2. プラットフォーム互換モード8.3.10以降で実行されている構成では、拡張機能を使用して共有モジュールにパッチを適用できます。
  3. 一般モジュールをルールに完全に置き換える拡張機能を接続します。
  4. 構成をサポートから削除せずに、ルールを使用して外部処理をノードに接続します。

最初のオプションでは、すべてが明確であり、ドキュメントに記載されています。欠点は、サポートから構成を削除する必要があることです。 2番目のオプション-選択したプロシージャを拡張機能で修正することも1Cプログラマーにとって難しいことではありません-2つの処理を標準ルールとこの記事で前述したように変更したルールと比較し、必要なものに変更を加える必要があります手順。

3番目のオプションは ユニバーサル形式の交換ルールで拡張機能を使用する 現在最も最適です。 唯一の欠点があります-フラグを削除する必要があります " セーフモード「この拡張機能を接続するとき。これにより、での使用が制限されます。 クラウドサービス..。 ユニバーサルフォーマットの交換ルールを1Cフレッシュに置き換える手順について、1Cからの決定を待っています。

肝心なのは、交換フォーマットのバージョンに応じて、共通モジュールの選択を担当するコードのセクションを構成内で見つけ、モジュールの選択を独自のモジュールに置き換える必要があるということです。 BP 3.0.67の例:

//////// //汎用データ交換モジュールが上書きされ、代わりに( "利用可能なフォーマットバージョンの取得時")プロシージャED_利用可能なフォーマットバージョンを取得する場合(フォーマットバージョン)ED_Exchanging DataServer。利用可能なフォーマットバージョンを取得する場合(フォーマットバージョン) ; EndProcedure //////// //ユニバーサルフォーマットを介したExchangeプランデータの同期:マネージャーモジュール#サーバーまたはシッククライアントの通常のアプリケーションまたはExternalConnectionの場合(「設定を受信する場合」)の代わりに手順ED_設定を受信する場合(設定)設定.DefaultName = GeneralConfigurations; Settings.ThisExchangePlanXDTO = True; Settings.WarningOnMismatchRuleVersion = False; Settings.ExchangeFormat = "http://v8.1c.ru/edi/edi_stnd/EnterpriseData"; フォーマットバージョン=新しい一致; ED_DataServer.AvailableFormatバージョン(フォーマットバージョン)を受信する場合。 // ED Settings.ExchangeFormatVersions = FormatVersions; Settings.ExchangePlanUsedInServiceModel = True; Settings.Algorithms.WhenGettingExchangeSettingsVariants = True; Settings.Algorithms.OnGettingOptionDescriptionSettings = True; Settings.Algorithms.InteractiveOffsetSelection View = True; Settings.Algorithms.ConfigureInteractiveOffload = True; EndProcedure #EndIf //////// // ED_Data_ExtensionServerプロシージャの汎用モジュールOnGetAvailableFormatVersions(FormatVersions)ExportFormatVersion.Insert( "1.2"、ExchangeManagerViaUniversalFormat); Format Versions.Insert( "1.3"、ED_ExchangeManagerViaUniversalFormat); Format Versions.Insert( "1.4"、ED_ExchangeManagerViaUniversalFormat); Format Versions.Insert( "1.5"、ED_ExchangeManagerViaUniversalFormat); Format Versions.Insert( "1.6"、ED_ExchangeManagerViaUniversalFormat); EndProcedure //////////拡張機能ED_ExchangeManagerの共通モジュールThroughthe UniversalFormat // 11/27/2018 11:23:58からのBP3.0.44(フォーマット1.6)の変換// BP3.0.67の改善。 x31.12から......。

ドキュメントに記載されていない4番目のオプションについて考えてみましょう。 BSPにはそのような可能性はありません。 このオプションはすでに非推奨です。 ルールによる外部処理 ユニバーサル交換フォーマットの最初のバージョンで使用されました。 現在、1Cはこの機能を徐々に削除しています。

エンタープライズモードでは、管理セクションで、リンクをたどります データ同期-データ同期設定、 ボタンを押す " 曲...「設定が1つまたは」の場合 変化する「複数の設定がある場合。メニューからフォーム編集モードに移動してください」 " 、 拡大 " グループ"、そこに隠しフォーム要素を含めます" "、" わかった".
サービス情報"選ぶ" エクスチェンジマネージャーへのパス"、処理をそこにあるルールに置き換えます。

ルールを使用した外部処理をBP3.0.52以降に接続する

不明な理由によるBP3.0.52以降 外部処理ルール付きは使用されません。 処理を接続するためのインターフェースは残ります。 それをありがとう。

拡張機能を使用して、ルールによる処理を有効にできます。 共通モジュールを修正する必要があります」 データ交換XDTOServer"、 関数" 形式VersionsExchange".

EDm_PoluchitVersiyuFormataObmena手順(VersiiFormataがUzelInformatsionnoyBazyを意味する)クエリが(「各種SELECT新しいクエリを= | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzheruObmena AS PutKMenedzheruObmena、| SinhronizatsiyaDannyhCherezUniversalnyyFormat.VersiyaFormataObmena AS VersiyaFormataObmena | HOW PlanObmena.SinhronizatsiyaDannyhCherezUniversalnyyFormat SinhronizatsiyaDannyhCherezUniversalnyyFormat | | | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzheruObmena FROM<>"" "" | そして、GenericFormat.Ref =&Link "); Query.SetParameter(" Reference "、InformationBase Node); Fetch = Query.Run()。Select(); While Fetch.Next()Loop ProcessingName = Fetch.Pathtoを介したデータ同期SharedOnderが使用できない場合のマネージャー;()Then ProcessingData = New BinaryData(ProcessingName); ProcessingAddress = PutToTemporaryStore(ProcessingData); If GeneralPurpose.There is Protection Against Dangerous Actions()Then ProcessingName =ExternalProcessing.Descriptions。EndIf; EndIf; ExchangeManager = ExternalProcessing.Create(ProcessName); Format Versions.Insert(Selection.ExchangeFormatVersion、ExchangeManager); End of Loop; EndProcedure&Institute of( "ExchangeFormatVersion")EDMNodeVersionNodeVersionValue 追加(InfoBaseノード)Then ExchangePlaneName = InfoBaseNode.Metadata()。Name; ExchangeFormatVersions = DataExchangeServer.ExchangePlanSettingsValue(ExchangePlaneName、 "ExchangeFormatVersions"); EDm_GetExchangeFormatVersion(ExchangeFormatVersions、InformationBaseノード); それ以外の場合、DataExchangeRedefinable.WhenGettingAvailableFormatVersions(ExchangeFormatVersions); EndIf; If ExchangeFormatVersions.Number()= 0 Then CallExceptionStringFunctionsClientServer.SubstituteParametersVSString(HStr( "ru =" Exchange形式のバージョンが指定されていません。| Exchangeプラン名:%1 |プロシージャ:GetExchangeFormatVersions(<ВерсииФорматаОбмена>) "")、DatabaseNode.Metadata()。名前); EndIf; 結果=新しい一致; バージョンごとにFromVersionFormatExchangeサイクルResult.Insert(AbbrLP(Version.Key)、Version.Value); サイクルの終わり; 返金結果; EndFunction

外部処理でルールをデバッグする方法

    コンフィギュレーターで " サービス->パラメータ-> 1Cの開始:エンタープライズ->パラメータの開始"、パラメータ" "を指定します。

  • 以下は、UT 11.4、KA 2.4、ERP2.4の拡張機能のコードです。 BP3.0のコードは上記のとおりです。 ユニバーサルフォーマットを介したExchangeプランマネージャモジュールのデータ同期。

拡張コードEDデバッグ

&( "GetExchangeFormatVersions")の代わりにプロシージャED_GetExchangeFormatVersions(FormatVersions)DataExchangeUT.AvailableUniversalFormatVersions(FormatVersions); リクエスト=新しいクエリ( "SELECT DIFFERENT | UniversalFormat.PathTo Exchange Managerを介したデータ同期、| UniversalFormat.ExchangeFormatVersionを介したデータ同期| FROM | Exchangeプラン。<>"" "" "); Fetch = Query.Execute()。Select(); While Fetch.Next()Loop ProcessingName = Fetch.PathToExchange Manager; IF NOT SharedPurposeClientServer.Debug Mode()Then // EDProcessingData = New BinaryData)( NameProcessingData; AdresObrabotki = PomestitVoVremennoeHranilische(DannyeObrabotki)場合ObschegoNaznacheniya.EstZaschitaOtOpasnyhDeystvy()次にImyaObrabotki = VneshnieObrabotki.Podklyuchit(AdresObrabotki、ObschegoNaznacheniya.OpisanieZaschityBezPreduprezhdeny());そうでなければImyaObrabotki = VneshnieObrabotki.Podklyuchit(AdresObrabotki); ENDIF; ENDIF; MenedzherObmena VneshnieObrabotki.Sozdat(= ImyaObrabotki)VersiiFormata.Vstavit(Vyborka.VersiyaFormataObmena、MenedzherObmena)KonetsTsikla;代わりにKonetsProtsedury&( "DostupnyeVersiiFormataObmena")ED_DostupnyeVersiiFormataObmena手順(VersiiFormata)ObmenDannymiUT.DostupnyeVersiiUniversalnogoFormata(VersiiFormata)クエリ=新しいクエリ(「各種SELECT | SinhronizatsiyaDannyhCherezUniversalnyyFormat.PutKMenedzherは、 取引所で| データ同期ViaUniversalFormat.ExchangeFormatVersion | FROM | UniversalFormatを介したExchangePlan.Data同期ASUniversalFormatを介したデータ同期| WHERE | UniversalFormatを介したデータ同期。ExchangeManagerへのパス<>"" "" "); Fetch = Query.Execute()。Select(); While Fetch.Next()Loop ProcessingName = Fetch.PathToExchange Manager; IF NOT SharedClientServer.Debug Mode()Then // EDProcessingData = New BinaryData)( NameProcessingData; AdresObrabotki = PomestitVoVremennoeHranilische(DannyeObrabotki)場合ObschegoNaznacheniya.EstZaschitaOtOpasnyhDeystvy()次にImyaObrabotki = VneshnieObrabotki.Podklyuchit(AdresObrabotki、ObschegoNaznacheniya.OpisanieZaschityBezPreduprezhdeny());そうでなければImyaObrabotki = VneshnieObrabotki.Podklyuchit(AdresObrabotki); ENDIF; ENDIF; MenedzherObmena VneshnieObrabotki.Sozdat(= ProcessingName); Format Versions.Insert(Fetch.ExchangeFormatVersion、ExchangeManager); EndLoop; EndProcedure

デバッグは、ファイルデータベースで行うのが最も簡単です。 ルールを使用した処理でブレークポイントを設定します。 必要な手順を見つけるには、KD3を使用します。 PKO、POD、またはアルゴリズムが見つかりました。「 ハンドラー名" また " アルゴリズム名"、ルールモジュールでこのプロシージャを探しています。モジュールを編集した後、プロシージャをクリップボードにコピーして、CD3のボタン" "を押すことを忘れないでください。同じ変換を開く必要があることに注意してください。

それは今のところすべてです。 この情報は、1CプログラマーがKD3を独立して習得し、1Cベース間の最新の同期方法を正常に維持するのにすでに十分です。 白い斑点がある場合は、質問してください。記事は補足され、何かを忘れた場合は元に戻すことができます。

KD3に関するドキュメントへのよく知られたリンク:
  • 1C-トレーニングセンターNo.3、「データ変換3.0」-http://www.1c-uc3.ru/konvert30.html
これらの出版物を使用して、KD3の適用範囲を拡大できます。
  • -プラットフォーム8.2以下の以前のバージョンの構成はEDに準拠します。
時間を節約し、既成のルールを使用して 最新バージョン構成はここにあります
  • -拡張機能、バグ修正。

この記事では、これまでのところ、ユニバーサルEnterpriseData形式を使用してデータ交換を整理した経験について説明します。

私の場合、取引所は「Trade Management11.2」(以下UT)と「EnterpriseAccounting3.0.43」(以下BP)の構成で構成されています。 交換は、UTからBPへの一方向です。 Trade Management 11.1からバージョン11.2にアップグレードする前は、データ交換はData Conversion2.0構成を使用して構成されていました。 しかし、「貿易管理」で「11.2」に切り替えた後、ユーザーの作業にエラーが発生しました。 交換ルールの更新手順を実行しましたが、何の結果も得られませんでした。 デバッガーは、問題が通信であることを示しました。 両方の構成で通信設定を削除し、再度設定することにしました。

「TradeManagement」と「EnterpriseAccounting」の両方がクライアントサーバーバージョンで機能します。 UTとの同期の設定を開始しました。 データがUTからファイルにアンロードされるように実行しました。 つまり、ネットワークディレクトリを介した同期です。 電源ユニットでは、電源ユニットからデータがアンロードされないように交換機を設置しました。

コンテキストメソッドの呼び出し中にエラーが発生しました(チェック):XDTOデータのチェック中にエラーが発生しました:
オブジェクト「/カウンターパーティの銀行口座/銀行」の構造は、タイプに対応していません:(http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)
「BIC」プロパティの確認:
形状:要素
名前:(http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIC
タイプ:
必要なプロパティがありません
対象:相手方との契約番号..。

エラーを分析するために、「送信するデータの構成」アイコンをクリックし、発送登録された請負業者のリストで、エラーが表示される契約を見つけました。 契約を締結し、契約で指定された相手方の銀行口座を思い出しました。 それから私は出荷のために登録された銀行口座に切り替えました。 必要なアカウントが登録済みのアカウントのリストにないことが判明しました。 問題のある銀行口座と契約を再転記します。 その後、必要な銀行口座を手動で登録しました。

UTからのデータを再度同期しようとしました。 今回は、データが正常にアンロードされました。 V ネットワークフォルダ形成された XMLファイル UTからBPに転送するためのデータが含まれています。

次のステップは、ファイルから企業経理部門にデータをロードすることです。 「エンタープライズアカウンティング」構成で、「同期」ボタンを押すと、「データ分析が進行中です」というメッセージが表示された処理フォームが開きました。 少し後、メッセージが「データのアンロード」に変わりました。 同時に、インジケータとカウンタは、8万を超えるオブジェクトが電源ユニットからアンロードされていることを示しました。 設定で電源ユニットから何もアンロードしてはいけないことを示したので、これは私を混乱させました。 処理にかなりの時間がかかり、エラーで終了しました。

イベント:データ交換
(SharedModule.LongedOperations.Module(371)):バックグラウンドジョブワークフローが異常終了しました
CallException(ErrorText);

エラーを特定するために、BPベースの同期設定と操作オプションを変更しようとしました。 その結果、データベースをファイルバージョンに切り替えると、システムは適切に機能しました。2つのデータベースを比較するためのフォームが開きました。 オブジェクトを照合した後、最初の同期は成功しました。 次に、データベースをクライアントサーバーバージョンに戻しました。

同期のさらなる「慣らし運転」中に、オブジェクトを変換するためのルールにいくつかの変更を加える必要がありました。 今こそ、データ変換3.0構成を使用するときです。 オンライン構成ヘルプでは、作業方法について説明しています。 ITSWebサイトの記事も役に立ちました。

その結果、次のデータを「データ変換3.0」にロードしました。

  • 2つのベースからの共通モジュール「DataExchangeManagerViaUniversalFormat」のテキスト
  • 両方の拠点のスキーム
  • EnterpriseData形式の説明(任意の1つのデータベースから)
  • 変換ルール

ロード後、「データ変換3.0」でデータ、オブジェクト、プロパティを変換するためのルールを開きました。 私のために必要な編集を行いました。 次に、「ExchangeManagerモジュールのアンロード」ボタンを使用しました。 モジュールのテキストがクリップボードにコピーされました。 構成に挿入するだけです。

「データ変換3.0」でルールを設定してみたところ、変更が重要でない場合は、共通モジュール「DataExchange」のUTおよびBP構成で直接ルールを設定する方が簡単であると自分で結論付けました。 ManagerViaUniversalFormat」。 たとえば、取引所に新しいオブジェクトを追加するなど、編集が深刻な場合は、構成を使用する必要があります。 データ変換3.0 "。

「サプライヤへの注文」というドキュメントを「」を使用して交換計画に追加するタスクを実行しました。 データ変換3.0 "。 標準バージョン UT-交換計画におけるこの文書のBPはそうではありません。

アップロードするオブジェクトを登録するためのルールは、引き続き「データ変換2.0」構成で構成されていることに注意してください。

これらは、ユニバーサルEnterpriseData形式によるデータ同期の第一印象です。

追伸 ユニバーサルフォーマットと構成を介したデータ交換について質問や独自の見解がある場合」 データ変換3.0 "、コメントを書いてください。経験を交換します。

  • データ同期
  • 一般的なEntepriseData形式
  • データ変換3.0
  • データ変換2.0
  • 貿易管理
  • エンタープライズアカウンティング

簡単な実際の例を見てみましょう。 他の会社と同じように、この会社でも卸売りと小売りの取引を行っている会社があるとしましょう。 企業には2つの標準ベースがあります。これらはそれぞれUT(貿易管理)とBP(企業会計)です。各ベースは、会計BPで、貿易に関連するすべてのトランザクションを反映するために、管理UTで独自の会計を維持します。 二重の仕事をしないために、すなわち 2つの拠点で同じドキュメントを作成しないでください(結局のところ、移動は管理と会計のためでなければなりません) これらの拠点間の同期を設定するだけです.

一方向のデータ交換を設定します、UT ---> BPから。 双方向の交換を設定することも可能ですが、実際にはそれほど必要とされないため、この例では考慮しません。

BPで取引所を設定するための準備手順

同期の設定を開始しましょう。最初に1C「EnterpriseAccounting3.0」データベース(レシーバー)に移動します。このデータベースで同期が有効になっているかどうかを確認する必要があります。これを行うには、最初にデータベースに移動する必要があります。 ベースが開いたらすぐにタブに移動します 「管理」--->「データ同期設定」


新しいタブが目の前に開きます。情報ベースのプレフィックスを除いて、下のスクリーンショットと同じ方法で入力する必要があります。 プレフィックスは2文字で構成する必要があり、任意の1つを設定できますが、1C標準によれば、構成の名前でプレフィックスを設定することをお勧めします。つまり、「エンタープライズアカウンティング」の場合、プレフィックスは「BP」になります。 複雑な取引所を設定し、複数の会計ベースがある場合、プレフィックスは明らかに互いに異なる必要があります。ここでは、組織名の最初の2文字を省略形として使用できます。

UTでデータ同期を構成し続けます


レシーバーベース(BP 3.0)で必要なすべてのアクションを実行した後、データ交換のセットアップを続行するには、ソースベース(UT 11.1)を開く必要があります。 メニューの左側にある[管理]タブに移動し、[データ同期設定]の項目を選択します..。 同期が有効になっていない場合は、チェックボックスを使用して同期を有効にし、ソースベースのプレフィックスを指定することを忘れないでください。 下の画像に示すように、ポイント1〜4をすべて完了したら、[データ同期]ハイパーリンク(ポイント5)をクリックする必要があります。


表示される新しいウィンドウで、緑色のプラス記号(データ同期の構成)をクリックする必要があります。ドロップダウンメニューで、[エンタープライズアカウンティング3.0]の項目を選択します。

UTとPSU間のデータ交換における重要なポイントの構成


これで、1Cでデータ同期を設定するウィンドウが表示されます。[設定を手動で指定する]項目を選択して、[次へ]をクリックします。


1Cでデータ交換を設定し続けます。次のタブで、受信側インフォベースに接続するオプションを選択する必要があります( 直接接続プログラムへ)、接続パラメータ(上 このコンピュータまたはで 地元のネットワーク)、受信者ベースが配置されているディレクトリ、および必要な認証データ(ベース内のユーザー名とパスワード)。


次のページでは、BP 3.0構成(レシーバー)との間でデータを送受信するためのルールを入力する必要があります。 [データのアップロードのルールを変更する]をクリックします。


「データ送信ルール」ウィンドウが表示され、次のパラメータを設定します。

  • どのNSIが送信されるか(この例では、ドキュメントとその中で使用されるNSIのみに関心があるため、適切な項目に移動しました。最初の項目「すべて送信」を選択すると、すべてのディレクトリが一緒に再ロードされます。文書、多くの場合、情報が文書で使用されていない場合、それは会計にまったく影響を与えないため、受信者にとっては役に立ちません)
  • すべての情報を送信する日付から(この記事では手動同期については考慮しません)
  • どの組織またはどの組織にデータを送信するか(この例では、1つの組織IE「起業家」を選択しました)
  • 契約形成のルール
  • 一般倉庫
  • 倉庫でドキュメントを折りたたむかどうか

設定が終わったら、「保存して閉じる」をクリックします。


この例では、UTからBPへの一方向の交換を設定して使用しているためです。の場合、「Enterprise Accounting 3.0」からデータを取得するためのルールの設定は重要ではないので、「次へ」をクリックします。


新しいウィンドウで、レシーバーベース(BP)のルールを構成するように求められます。 ポイント1では、ベースをなんらかの方法で呼び出し、プレフィックスを付けます。 PREFIXは、この記事の冒頭でBPデータベース自体に設定したものと同じである必要があります。プレフィックスが異なる場合、1Cプログラムでのデータ同期は機能しません。その後、ポイント2を押し、次にポイント3を押します。



段落3では、ドキュメントがデータベースにロードされるときにドキュメントを投稿できるようにする必要があります。 「保存して閉じる」をクリックします。


これで、ウィンドウは次のようになります。[次へ]をクリックします。


このウィンドウには、1Cで作成された同期に関する参照情報が含まれています。 「次へ」ボタンをクリックするだけです。 データ同期の設定時にプログラムでエラーが表示された場合は、1Cスペシャリストが今すぐサポートできるように、当社に連絡する必要があります。


次のステップで プログラムは、データ交換設定を作成した直後に同期を実行することを提案します..。 これに同意して、「完了」をクリックしましょう。

同期がどのように進行しているかについての情報を表示するウィンドウが目の前に表示されます。 レシーバーベースが空でない場合、つまり アカウンティングはすでに保持されているため、1Cプログラムのユーザーは、オブジェクトを手動で比較するように求められます。 データ同期中の1Cのオブジェクトの比較は、レシーバーの同じオブジェクトとソースの同じオブジェクトの比較です。

例を考えてみましょう。たとえば、UTに「PharmGroupLLC」とTIN 1234567という名前のカウンターパーティがあり、BPにもTIN 1234567のカウンターパーティがありますが、これら2つのオブジェクトを比較しない場合、「PharmGroup」という名前になります。同期段階でデータを比較し、レシーバー(Enterprise Accounting 3.0)で同期した後、TIN 1234567の2つのカウンターパーティと、それぞれ「PharmGroupLLC」と「PharmGroup」という2つの名前があります。 このような状況を回避するために、オブジェクトを照合するメカニズムが発明されました。


この例では、レシーバーベースが空であるため、オブジェクトマッピングウィンドウが開きませんでした。 しかし、いくつかの操作を実行した後、システムは確かにユーザーにいくつかのデータを追加して次のウィンドウを表示するように促します。 追加のデータを転送する必要はありません。以前に必要なものはすべて構成済みなので、このステップでは「送信にドキュメントを追加しない」を選択します。 「次へ」をクリックします。

1C間のデータ交換の最終段階


最終段階で、プログラムは次のウィンドウを表示します。このウィンドウで、同期が成功したことがユーザーに通知されます。[完了]をクリックします。 これで、「Trade Management11.1」(UT)から「EnterpriseAccounting3.0」(BP)への一方向交換の拠点間の同期が完了します。

自動化されたシステムほとんどの場合、管理は個別のデータベースで構成され、地理的に分散した構造になっていることがよくあります。 同時に、正しく実装されたデータ交換は、そのようなシステムの効果的な運用の前提条件です。

同時に、1C:Enterpriseプラットフォームの製品の場合のように、同種のソースを扱っている場合でも、初期の交換セットアップには、プログラミングだけでなくコンサルティングの観点からも多くのアクションが必要になる場合があります。 1C交換のセットアップ(または、1C 8.3でのデータ同期)が統合プロジェクトの最も時間と費用のかかるタスクになる理由について、この記事で検討します。

1C環境でのデータ交換により、次のことが可能になります。

  • 文書の複式簿記を除外します。
  • 関連するビジネスプロセスを自動化します。
  • 分散ユニット間の通信を最適化します。
  • さまざまな部門の専門家の作業に関するデータを迅速に更新します。
  • さまざまな種類の会計を「描写」します。*

※会計の種類によってデータが大きく異なる場合は、情報の機密性を確保し、情報の流れを「区切る」必要があります。 たとえば、1C UTと1Cアカウンティングの間のデータ交換では、管理データを通常のアカウンティングデータベースにアップロードする必要はありません。 1Cでの同期はここでは不完全になります.

プライマリデータ交換を実装する標準プロセスを表す場合、そのオブジェクトの少なくとも1つが1C製品である場合、次の段階を区別できます。

  • 交換の構成の調整;
  • トランスポートの定義(交換プロトコル);
  • ルールの設定;
  • スケジューリング。

取引所1Cの構成を明らかにする

交換の対象は、条件付きで「ソース」と「レシーバー」に分けることができます。 同時に、彼らは同時に2つの役割を実行することができます。これは、二国間交換と呼ばれます。 送信元と宛先の決定は、必要性またはに応じて、論理的な方法で行われます。 機能性システム。 *

*たとえば、「1C:Enterprise」に基づいて開発された、財務会計と財務プロセス管理のソリューションである「WA:Financier」を統合する場合、WiseAdviceの専門家はそれをマスターシステムとして推奨します。 これは、アプリケーションポリシーのルールに準拠し、それに応じてソリューションの有効性を確保するための制御ツールが利用できるためです。

さらに、ユーザーから受信および記録された要件に基づいて、交換用のデータのリストが作成され、それらのボリューム、交換頻度の要件が決定され、エラーの処理および例外的な状況(衝突)の処理が行われます。所定。

同じ段階で、既存のシステムのフリートと企業の構造に応じて、交換形式が決定されます。

分散情報ベース

  • RIBは、交換ペアごとに明確なマスタースレーブ制御構造を備えた、1Cデータベースの同一構成間の交換を意味します。 技術プラットフォームの要素として、RIBは、データに加えて、データベースの構成および管理情報への変更を転送できます(ただし、マスターからスレーブにのみ)。

1Cでのユニバーサルデータ交換

  • 1C:Enterpriseプラットフォームでの構成と、サードパーティシステムの両方で、1Cデータベースの交換を構成できるメカニズム。 交換は、「交換計画」に従ってデータをユニバーサルxml形式に変換することによって実行されます。

EnterpriseData

  • 1Cで作成された製品間でxml形式のデータ交換を実装するように設計された1Cの最新の開発:任意の自動化システムを備えたエンタープライズプラットフォーム。 EnterpriseDataを使用すると、交換関連の改善が簡単になります。 以前は、新しい構成がシステムに含まれる場合、データと既存のシステムの両方のデータをインポートおよびエクスポートするためのメカニズムを実装する必要がありました。 これで、EnterpriseDataをサポートするシステムを変更する必要がなくなり、「入口-出口」ポイントが1つだけになります。

トランスポートの定義(交換プロトコル)

1C:Enterprise 8プラットフォームに基づくシステムの場合、一般的に受け入れられているユニバーサル標準(xml、 テキストファイル、Excel、ADO接続など)。 したがって、交換データのトランスポートを定義するときは、サードパーティのシステムデータベースの機能から始める必要があります。

ディレクトリの同期

ディレクトリの効果的な同期の主な原則は、1つのエントリポイントの存在です。 しかし、歴史的に異なる規則に従って記入された参考書を扱う場合は、交換を「最小公分母」にするために同期フィールドを明確に定義する必要があります。*

※この段階で、データソース側の参照データの正規化作業が必要になる場合があります。 参考書の状態とその量によっては、要素の照合、認識、エラーと重複の検出、欠落しているフィールドへの入力、同期フィールドの割り当てのプロセスで、両方の専門家グループ全体の作業が必要になる場合があります。インテグレーター(参照データの標準化方法の所有者)および顧客側から。

ルールの設定

レシーバーでソースシステムからのデータを表示する機能は、正しく指定された交換ルールに依存します。 xml形式で表示されるルールは、送信元と宛先のオブジェクトの主要な属性の対応を規制します。 ソリューション「1C:データ変換」は、1回限りの交換と永続的な交換の両方を実装するためのルールの作成を自動化するように設計されています。

Exchangeプランを交換するときにデータが失われないようにします。 これは、1C:Enterpriseプラットフォームの構成に不可欠な部分であり、1C:データ構成(「識別」の詳細を含むドキュメント)とノード(「識別」の詳細を含むドキュメント)を交換する手順を完全に説明しています。 情報ベース送信機-受信機)、および選択した交換方向のRIBのアクティブ化。

交換プランに入力されたデータの変更はすべて記録され、「変更」のサインを受け取ります。 変更されたデータが送信機と受信機のノードで一致するまで、フラグはクリアされず、システムは両方のノードに制御メッセージを送信します。 データをアンロードし、両方のシステムで完全に対応していることを確認した後、符号がリセットされます。

1Cでの交換スケジュール

定期的な交換を自動化するために、データのアップロードの頻度が設定されています。 交換頻度は、ニーズと技術的能力によって異なります。 また、1C:Enterpriseプラットフォームの構成では、イベントが発生したときにデータ交換をセットアップできます。

標準の交換実装プロセスを検討したので、さまざまな段階で改善が必要になる要因に注意を払いましょう。

  • 非典型的で高度に変更されたデータベース構成。
  • 異なるバージョン 1C:エンタープライズプラットフォーム。
  • 長期間更新されていない、 現在のバージョン構成;
  • 以前に改訂された交換の対象。
  • 非標準の交換ルールの必要性。
  • 既存の参考書の必要条件の非常に異なるセットと構成。

一次データ交換を実施するための標準的な行動でさえ専門家の知識を必要とするため、1Cの専門家の参加を得て実施することをお勧めします。 上記のすべての手順を完了した後でのみ、構成での交換のセットアップに進む必要があります。 「1C:UPP」と「1C:Retail」の例を使用してデータベースの統合を考えてみましょう(同じスキームに従って、「1C:UT」との交換が構成されています)。 また、典型的な同期には、SCPの交換が含まれます。SCPは、最大の産業企業の大規模な自動化システムで典型的です。

[サービス]サブメニューで、[プラットフォーム上の製品とのデータ交換...]を選択します([小売]との直接交換を選択すると、COMオブジェクトのレベルでエラーが発生することがよくあります)。 「この機能は利用できません」というサービスメッセージに注目しましょう。


この問題を解決するには、「通信設定」を選択する必要があります


...そしてボックスにチェックを入れます。 次に、エラーメッセージを無視します。


データ同期設定で、[リテールとの取引所を作成する]を選択します...



ローカルディレクトリまたはネットワークディレクトリを介して接続するための設定を構成する前に、ディレクトリ用にディスク上に十分なスペースがあることを確認してください。 原則として、30〜50 MBを超えることはありませんが、例外的なケースでは、最大600MBが必要になる場合があります。 必要なディレクトリは、コンフィギュレータから直接作成できます。



ネットワークディレクトリを介して接続する場合、FTPアドレスおよびを介して接続を構成することを提案します Eメール「次へ」をクリックすると無視されます。


設定では、プレフィックス(ベースの規則(原則として、BP、UPP、RO))を手動で設定し、ルールとデータアップロードの開始日を設定します。 プレフィックスは、ドキュメントの名前に示され、ドキュメントが作成されたベースを示します。 アンロードルールが編集されていない場合、データはデフォルトで使用可能なすべてのパラメーターに対してアンロードされます。



アクションを繰り返さないように、「小売」の交換設定ファイルを作成します。 同期を設定した直後にデータを送信する必要がある場合は、チェックボックスをオンにします。


交換プロセスを自動化するには、スケジュールを設定する必要があります。


小売メニュー。


チェックボックスをオンにして、[同期]を選択します。


Manufacturing Enterprise Managementを選択して、「逆」設定を行います。




SCPで作成された設定ファイルをロードします。


ティックを入れると、システムが自動的にアドレスを取得します。





私たちはUPPと同じように行動します。









検証データの比較(この作業は交換を実装するプロセスで最も時間がかかる可能性があるため、準備段階で手動のデータ比較をお勧めします)。 マッピングウィンドウはによって開かれます ダブルクリックマウス。



同期エラーが発生した場合、「詳細...」は「なし...」に置き換えられます。


「詳細...」は、取引所に関する最新情報を含む登録ログを開きます。


準備。