オンラインストアと1C：Enterpriseの統合を開発した方法と、なぜそれが大規模になったのか。 パート3

1C：Bitrixオンラインストアと1C：Trade Managementシステムの統合の実装についての話の最後の部分では、顧客の注文に関するデータを交換するというビジネス上の問題の解決についてお話したいと思います。







このトピックに関する以前のトピックの本質を思い出させてください。



最初の投稿では、オンラインストアの所有者が直面するタスクの分析方法、データ交換の概念の選択、1Cとオンラインストア間の交換プロトコルの開発についてお話しました。



2つ目は、商品のデータベースを1Cからサイトにアップロードするビジネス上の問題に対する特定のソリューションを示しました。アップロードの命名法の選択、サイト側のデータ処理設定、および大量のデータのアップロードの安定性を確保するためのいくつかの技術的ソリューションが含まれます。



さて、オンラインストアには1Cからアンロードされた商品のカタログがあり、注文処理プロセス自体の観点から商品をクライアントに販売する必要があります。



製品をバスケットに追加した後、クライアントはチェックアウトフォームに移動して詳細を入力しました。







彼は連絡先情報、支払い方法を示し、配達オプションを選択しました。 注文には特定の番号が割り当てられ、システムに保存されます。クライアントは注文の履歴を表示するための個人アカウントを利用できます。







今何をしますか？ もちろん、「注文を処理します。」 しかし、それをどこで処理するか-サイト上または1Cで？ 結局のところ、統合されています。 注文を処理するためのビジネスモデルを選択する必要があり、一般にそのようなモデルが3つあります。

サイトで直接注文を処理する

注文管理のためのCMSの管理部分の機能が使用されます。 客観的に言えば、1C-Bitrix：Site Managementシステムのこのような機能は、ほとんどの店舗にとって非常に幅広く十分です。

-フィルターで注文を検索

-注文に関するデータの表示、

-注文の編集（連絡先の詳細、注文の詳細）、

-無制限の注文ステータスと、各ステータスを操作するためのさまざまなユーザー権限

-ドキュメントなどの印刷







通常、そのようなモデルは、店舗が唯一またはほとんどの主要な販売元である人によって選択されます。 一度に1つのシステムで、顧客は注文の変更をすぐに確認し、通知を受け取ります。



1Cがある場合、注文が既に処理され、お金が受け取られ、注文が配達されている場合、レポートのために1Cで注文をアンロードします。

1Cでの注文の処理

一部の顧客は、サイトの管理パネルに豊富な処理機能があることさえ見て、 すべての処理が1Cシステムで実行されると主張しています 。 言い換えると、顧客は、サイトで作成された注文をすぐに1Cに表示して 、さらに処理することを望んでいます。



通常、これらはオンラインストアが販売チャネルの1つに過ぎない会社であり、たとえば小売店やディーラーの販売も含まれます。 この場合、そのようなモデルは、注文を処理するための単一のセンターで、単一の場所ですべての処理を保証する必要性によってのみ決定されます。



この場合、すべての処理は単一のシステムで実行され、在庫、在庫残高、引当金などが保存されます。 確かに非常に便利です。



このようなビジネスモデルの場合、1Cをオンラインストアと統合するための重要な要件は、サイトからの注文に関するデータを受信する速度と完全性です 。 ここでの追加の複雑さ：顧客が個人アカウントで注文執行のプロセスを監視できるようにするには、1Cが作業中に発生した注文の変更についてサイトに通知する必要があります。

混合モデル

操作の一部がサイトで実行され、一部が1Cで実行される場合、さまざまな結合スキームを編成することが必要になる場合があります。 サイト上で注文の一部処理を実行することができます（たとえば、注文を受け取ってバイヤーに確認するなど）。注文が指定されたステータスになったら、1Cに転送します。

1Cと1C-Bitrixの統合におけるビジネスモデルの実装

ご覧のとおり、一目で注文を統合するビジネスタスクは単純ですが、多くの微妙な違いがあります。 次に、統合実装機能を見てみましょう。

サイト側の設定

交換プロトコルによると、1Cは定期的にサイトにリクエストを送信し、CommerceML形式で結果のレスポンスを受信します。 1C-Bitrixシステムの管理部分には、この回答を生成するプロセスに影響を与える一連の設定があります。



注文の統合設定の最初の部分は、1Cとの統合の一般設定の「注文」タブにあります（前の部分では「カタログ」タブを考慮しましたが、これは商品の輸入に関するものです）。







ここに示されています：

• 注文が1Cにアップロードされるサイト。 1つのエンジンに複数の店舗が存在する可能性があり、リクエスト1Cで注文を出すのはどこかを明確にする必要があります。
• ダウンロードが許可されているユーザーのグループ-1Cが注文を受け取るユーザー権限
• zip圧縮を使用する-商品の転送の場合と同様に、送信されるトラフィックの量を減らすことができますが、注文のリストについてはそれほど多くの荷降ろしはできません

ビジネスプロセスに影響するその他のパラメーター：

• 有料注文のみをアンロードする
• 許可された配送でのみ注文を発送
• ステータスから始まる注文をアンロードします

実際、これらの3つのパラメーターを使用して、顧客は店舗のモデルを選択します。 または、最初のステータスからすぐに注文が1Cに分類され、すべての処理が1Cで行われます。 または、すべての処理がストアで行われ、最終ステータスでアンロードが行われます。 または、ある種の混合オプションが選択されています。

支払い済みの注文のみ、または承認済みの発送のみをアンロードする-ステータスに関係なく、「有料」と「発送用」のフラグによって注文のアンロードを厳密に制限します。 結局、ステータスはカスタムのものであり、これらのフラグに関連付けられていない可能性があります。

1C側の設定

このサイトは、取引先データ、商品アイテムのリスト、サービス情報など、注文に関するデータを含むCommerceMLファイルを準備し、リクエストに応じて1Cを提供しました。 次に、この注文を1Cでどのように処理して保存するかを構成する必要があります。



注文を保存するプロセスには、いくつかのステップが含まれます。

• カウンターパーティの識別（既存のものの中から検索するか、新しいものを作成します）
• 注文したアイテムの識別（ストックリストディレクトリで検索するか、新しいアイテムを作成します）
• ドキュメント「Sales Order」の作成と実装
• 注文ステータスの識別とドキュメント「販売注文」のステータスの設定

注文による統合を有効にするには、「基本設定」タブを確認する必要があり、専用の設定タブが表示されます。







「基本設定」タブで、サイトへの1Cアクセスの間隔を設定できることを思い出させてください。 たとえば、注文は5分ごとに収集できます。



タブで交換注文が設定されます：







1）取引相手を識別する方法。



この設定は、1Cの既存のカウンターパーティ間のサイトからのカウンターパーティ検索アルゴリズムを制御します。 現在、選択できる識別方法は2つあります。名前（通常は個人）と、法人のTIN + KPPの組み合わせです。 近い将来、別の識別オプションを追加する予定です-サイトのユーザーID（大規模店舗の名前は繰り返し使用できます）。

相手が見つからなかった場合、新しい相手が作成されます。



2）ディレクトリ「命名法」の新しい要素を作成するためのパラメータ



この設定は、製品が注文されているが1Cではない場合に必要です。 または見つけることができません。 この場合、1Cのデータの論理的な整合性を確保するには、製品が存在する必要があります。この場合、1Cは単にその命名規則ディレクトリにインポートします。



[詳細設定]タブには、注文のキャンセルなど、1Cでドキュメントを実行するためのパラメーターが表示されます。重要な設定は[注文ステータスのコンプライアンス]です。







サイト側と同様に、1Cはサイトでの注文のステータスに応じて「顧客注文」ドキュメントのステータスを設定することもできます。 たとえば、サイトでの注文が確認されると、1Cで自動的に「同意済み」のステータスを受け取ります。 これは便利です。

1Cからサイトへの注文のエクスポート

統合スキームでの商品の交換とは異なり、注文の交換は双方向です。 サイトは、受注に関する1Cデータを提供するだけでなく、1Cで以前にアップロードおよび変更された注文についてもサイトに通知します。 通常、これは、支払いと配送がサイトで実行されない場合に1Cで注文を処理するモデルの例です。



1Cのマネージャーはクライアントに電話をかけ、通信中にポジションのリスト、価格の変更、値引き、配達または支払いパラメーターの変更を行うことができます。 サイトがこれらの変更について知らされない場合、クライアントは彼の個人アカウントに彼の注文に関する古い情報を持ちます。



1Cの作業スキームは次のとおりです。 サイトからダウンロードした注文が変更された場合、次の交換セッションで1Cはこれらの変更をサイトにアップロードし（CommerceML形式でも）、サイトはそれらを受け入れて注文に関する情報を更新します。



1Cで注文を変更するもう1つのケースは、ステータスの変更です。 会計士は支払いを受け取り、支払い注文を作成しました。注文は支払い済みになりました。サイトでステータスを変更する必要もあります。 サイトのオンラインストアモジュールの設定には、さらに2つのパラメーターがあります。







つまり、支払いおよび（または）出荷時に1Cからデータを受信すると、サイトは注文のステータスを自動的に変更します。 ステータスを変更するには、ハンドラーを「ハング」させ、クライアントにメッセージを送信します（電子メールまたはSMSで）。



合計：注文処理はサイト外で行われますが、統合は購入者に通知するタスクです。

追加の統合オプション

サイトの1Cから1C-Bitrixへのすべての統合設定は、デフォルトのデフォルト設定であり、デフォルトの統合スクリプトhttp：// <your_site> /bitrix/admin/1c_exchange.phpを参照します。



しかし、技術的な観点から、サイトの側面からの統合インターフェイス全体は1C-Bitrixシステムの2つのコンポーネントであり、開発者はこれを使用して、1Cとやり取りし、既存の機能を改良および拡張するための独自の任意のインターフェイスを作成できます。



これらは、コンポーネント「bitrix：catalog.import.1c」および「bitrix：sale.export.1c」です。 ビジュアルエディターで直接利用できます。 個別の設定で独自の統合スクリプトを作成できます。 すべてが基本的に行われます：



1）サイトにページを作成し、ビジュアルエディターで直接作成できます（既定のインターフェイスのように、商品と注文の両方に単一のURLを作成できますが、別のURLを作成することもできます）

2）1Cとの交換のコンポーネントをページに配置し、必要なパラメーターを構成します







原則として、ステップ1と2を使用して、サイトと統合する各1Cに個別の交換インターフェースを構成できます。 たとえば、同じエンジンに複数のオンラインストアがあり、それぞれが独自の1Cを交換します。 または、1つのオンラインストアがあり、複数のサプライヤがあり、それぞれが1つの1Cを持っているとします。 各1Cに商品をインポートするための独自のインターフェイスを作成する方が、より論理的で正しいです。



しかし、それだけではありません。



コンポーネント「catalog.import.1c」および「sale.export.1c」は、1C-Bitrixプラットフォームの通常のコンポーネント2.0です。 標準的な手法でカスタマイズしたり、名前空間に置いてソースコードを任意に変更したりすることもできます。



たとえば、サイトデータベースに書き込む前に追加のデータ処理を実行したり、他のサイトエンティティにデータを関連付けたりすることができます。



つまり、デフォルトとは異なる独自のインターフェース設定を作成するだけでなく、インターフェース全般を変更する機会を与えます。



この機会を利用して、他の1C製品（当然、反対側に統合メカニズムがある場合）または他のベンダーの製品との交換を実装できます。

統合に関する一般的な結論：

このトピックに関する3つの投稿を要約します。

1. 1Cとオンラインストアの間に既製の統合メカニズムが実装されており、カタログをアンロードして注文を交換するために、すぐに使用できる多数の典型的な顧客タスクを解決できます。
2. クライアントのビジネスの詳細に合わせて、1C-Bitrik：サイト管理と1C：トレード管理の両方から柔軟な統合設定の可能性があります
3. 統合機能のカスタマイズと改良の機会があります
4. データ交換は、オープンXML標準のCommerceMLを使用して実行されます
5. データ交換プロトコルは最大限に簡素化され、HTTP（S）を使用し、サイトスクリプトの作業に関する一般的なホスティング業者の制限を考慮します。
6. 統合アーキテクチャは1Cを保護します。インターネットからの脅威から可能な限り企業を保護し、1Cは常に交換のイニシエーターとして機能し、サイトはリクエストにのみ応答します

一般に、私たちは最初の段階で目標を達成したと信じています。



はい、すべてが可能な限り便利になるように管理されたわけではありませんが、統合を改善するための作業は数年間継続的に継続され、今後も継続されます。



お客様やパートナーから非常に強力なフィードバックをいただいています。 サポートサービスには1C製品の技術スペシャリストがおり、1C-Bitrix開発者と一緒に、システムの接合部にしばしばある複雑な問題を解決できます。 すべての願いが記録され、合理的なオファーが必ず実装されます。



1Cと一緒に、統合とデータ交換のための閉じたアーキテクチャを作成しませんでしたが、使用しやすく、改善と修正のために開かれたものにし、オンラインストアの現代のCMS間のこのような統合の普及により、この目標が確認されました達成しました！



ストリーム内の次のエントリを読むには、会社プロフィールの [いいね]をクリックして 、 フィード設定を確認してください。