1C Enterprise 8.3 Trade Management 11.1（以降1C UTと呼ばれる）と1C-Bitrix 14.0（以降Bitrixと呼ばれる）に基づくオンラインストアとの間の注文の交換は、これらのシステム間の標準の「ボックス化」交換メカニズムの一部です。 ユーザーはサイトで注文を作成し、スケジュールに従って、特定の注文ステータスから始めて、注文を1C UTにアップロードします。 標準形式でのこのメカニズムの説明は、この記事の最後にあるリンクにあります。この記事では、この機能を拡張して特定の商社のドキュメントフローに合わせる方法について説明しています。
標準バージョンでは、この交換メカニズムは1C UT側のマネージャーの作業を完全には自動化しません。事実、支払い方法、配送方法などの注文の詳細が1C UT側に転送され、追加で記録されます。 注文の詳細。
ただし、注文の配送フィールド、および運送業者（運送業者による配送時）、支払方法、倉庫は空白のままです。
また、注文をさらにワークフローに入れるために、ユーザーは追加情報を見て、注文にリストされているすべてのフィールドに手動で入力する必要があります（倉庫の自動入力はもちろん重要なポイントですが、原則として、注文を作成するときにデフォルトで選択するのが便利ですメイン倉庫）。
これはマウスを8回クリックするだけのように見えますが、1日あたりの注文数が多いため、これらの日常的な操作はユーザーにとって非常に面倒です。 したがって、交換中に配送フィールド、運送業者、支払い方法フィールド、倉庫フィールドが自動的に入力されるように、Bitrixから1C UTへの注文のエクスポートを完了するタスクが発生しました。
さらに、タスクの重要な条件は、サポートから削除されないように1C UT構成の整合性に違反しないことでもあったため、注文の交換を担当する交換モジュールの一部を割り当て、それを外部処理に転送し、この外部処理の機能を改良することが決定されました。
これは1Cプログラマーにとってよく知られているものであるため、1C Enterprise 8.3プラットフォームの外部処理の配置方法については詳しく説明しません。 キーポイントのみを見ていきましょう。 処理は手動起動時とスケジュールされたタスク実行時（スケジュール内）の両方で機能するため、メイン外部処理モジュールでは、これらの外部処理機能の両方のパラメーターをこれらのモードの両方で指定する必要があります。
() = ; .("", " "); .("", ); .("", "1.0"); .("", ""); .("", " , "); = ; ..(""); ..(""); ..(""); ..(""); ..(""); = .(); . = "1"; . = " ()"; . = ; . = ""; . = ""; = .(); . = "2"; . = " ()"; . = ; . = ""; . = ""; .("", ); ;
同じ場所で、メイン処理モジュールで、スケジュールされたタスクにハングアップし、交換を直接開始する手順を記述する必要があります。
() (); (., ("ru = ' '"));
上記の手順では、詳細のダウンロード機能の呼び出しを使用しました。 この機能では、リポジトリから以前に指定した追加の交換設定の詳細を選択します。
() = ""; = " "; = "SHARE"; = (); = .().; = .(,,,); (" ."); ; = (" !"); [.] = [.]; ([.]); ; ;
そして、高度な交換パラメーターを設定するために、ユーザーが注文交換サイト（標準マニュアルに従って事前設定された注文交換サイト）を選択できるフォームを外部処理に追加し、サイトの配送方法と1C側の配送方法を比較しますUT、およびサイトの支払い方法と1C UT側の支払い方法。 貨物運送業者-1C UT側-が相手方であることを明確にする必要があります。したがって、遠征便で行われる配送方法を比較する場合、相手方-貨物輸送を選択する必要もあります。 これにより、今後、取引相手を毎回選択する必要なく、注文ごとに納品書を作成できるようになります。
交換の追加の詳細の保存は、フォームモジュールからの詳細の保存手順によって実行されます（メインの外部処理モジュールと混同しないでください）。
() = ""; = " "; = "SHARE"; = (); = (""); = .().; = ([.]); = ("") .(., [.].()); .(., [.]); ; .(, , , , );
パラメータは一般設定ウェアハウスに保存されます-これは1C Enterpriseプラットフォームにとって非常に便利なツールです。
同じ場所のフォームモジュールでは、メインの外部処理モジュールのLoadRequirements（）プロシージャと同じ方法でLoadRequirements（）プロシージャを説明します。
フォームモジュールのもう1つの手順は、交換を手動で開始する手順です。
() = (""); .(., ("ru = ' '"));
準備データが完了したら、構成サイト1C UTの標準交換モジュールから、注文を交換するために必要なすべての手順をコピーします（モジュールのテキスト全体をコピーできます）。 さらに、高度な注文交換のための外部処理モジュールで既に、交換手順を変更して、この処理を介して交換するときに追加の設定が考慮されるようにします。
CreateUpdateDocumentsプロシージャでは、追加の注文情報が入力される場所（サイクル内）を見つけます。
注文のプロパティ、貼り付け（小道具、値）;
この行の後に追加します。
= " " = ..(, ""); = .. = .; .. = .; ... .. = .; ;
追加するサイクルの終了後、同じ手順で。 情報を挿入：
. .. [""] = ..; ; ;
これは、デフォルトでメインウェアハウスの順序をすぐに設定するために行われます。
以上です。 エンタープライズモードで処理を登録するだけです（これは、管理-システム設定の構成-印刷されたフォームのレポートと処理-追加のレポートと処理で行われます）。
支払い方法のマッチングを設定します。
配送方法の一致を設定します。
ルーチンでハング処理を行うと、サイトからの注文にはすぐに必要なすべてのプロパティが設定されるため、すぐに現金受け取りまたはキャッシュレス資金の受け取り、商品やサービスの販売などを行うことができます。
参照：
1.
1C-Bitrixと1C Enterprise UT間の注文交換のプロトコルの説明 。
2.
1C-Bitrix側の標準交換設定の説明 。
3.
UT Enterpriseの1C側の標準交換設定の説明 。
4.
CommerceML 2形式の説明 。