ビトリックス。 統合 2つのアイテムグループ構造を持つカタログの実装

免責事項



この記事は、CMSのキャンペーンではありません。どんなに良いか悪いかに関係なく...



プロローグ



1Cとオンラインストアの統合の作業を開始するときに現れる最初の最も一般的な問題の1つは、ディレクトリ構造の問題です。 原則として、顧客の1Cデータベースで利用できる命名法の構造は、控えめに言っても、サイトにエクスポートする準備ができていません。顧客はそれを変更することに非常に反対しています。 ビジネスプロセスが完成し、誰もがそのような構造に慣れており、習慣を変えたいというわずかな欲求も誰も持っていません。

この状況では通常何をしますか? 他と同じように、別の構造を作成し、すべての製品をそれに添付し、新しい構造をサイトにアップロードし、1Cデータベースには古い構造をそのまま残していると思います。 最後に、誰もが幸せです。 これをBitrixと組み合わせて実装するには、キットに付属のアンロードをわずかに近代化するだけで十分です... *



*-この記事を書くことで、それぞれBitrixの12番目のバージョンのリリースとアップロードの更新の前に計画されました。 1Cデータベースで使用されているものとは異なるディレクトリ構造を作成するための人員配置機能が発表されました。 はい、もちろん、フルタイムの機能を持つことは素晴らしいことですが、それでも、アンロードの構成中に構造調整を行うことは必ずしも便利ではないように思えます。 しかし、これはそれぞれの状況と味の問題です...



したがって、構造の問題が基本構造の変更に消極的である場合、グループを置換する問題を簡単に解決できます。 しかし、結局のところ、データベース内のこのような階層が気まぐれではなく、ビジネスプロセスの要件であるとしたらどうでしょうか。



挑戦する



ある日、私たちはそのような仕事を得ました。 今回はすべてがより興味深いものであるため、商品グループに割引をリンクする必要性が追加されました。新しいグループではなく、データベース内のグループに割引がリンクされています。 例:



データベースには次の階層があります(例では、メーカーに基づいてグループを選択しましたが、実際のデータベースには共通のロジックはありませんでした。たとえば、メーカー、サプライヤー、商品の種類ごとにグループを作成できます)。



 フィリップス
	 TV P11-100rub
	鉄P11-50rub
サムスン
	 TV S11-110rub
	電話S11-80rub




オンラインストアの階層は異なります。

テクニック
	アイアン
		鉄P11
	テレビセット
		テレビP11
		テレビS11
	携帯電話
		電話S11




取引先AがPhilipsグループのすべての製品を10%割引し、Samsung製品を15%割引するとします。 取引相手のBフィリップス-20%、サムスン製品-30%。



次に、取引先Aが次のようなディレクトリを確認する必要があります。

テクニック
	アイアン
		鉄P11-45rub
	テレビセット
		 TV P11-90rub
		 TV S11-93.5rub
	携帯電話
		電話S11-68rub




取引先B:

テクニック
	アイアン
		鉄P11-40rub
	テレビセット
		 TV P11-80rub
		 TV S11-77rub
	携帯電話
		電話S11-56rub




Bitrixには割引を処理するための優れたメカニズムがあります。 これらの変更は、他の多くの編集を引っ張っていたでしょう。 はい、もちろん、理論的には、品目グループではなく特定の製品で割引を行うことは可能ですが、荷降ろし時には製品ごとに割引のセットを取得する必要があります。 そして現在、データベースには約1万の製品と約1000のカウンターパーティがあり、それぞれに数十のユニークな割引があり、さらにデータベースが成長しているため、カウンターパーティが追加されています...このアプローチはすぐに破棄されました。

明らかに、サイトは、価格の計算を最初に依存し、カタログツリーを構築するために2番目に依存するために、両方のグループ構造を知る必要があります。



解決策



これを解決するには、Bitrixの情報ブロック要素の非常に便利なプロパティである「セクションへのバインド」が必要です。 また、Bitrix APIを使用して要素のリストを取得する場合、CIBlockElement :: GetList関数は、このグループ内の要素だけでなく、「セクションにバインド」プロパティを介してバインディングを持つ要素も返すという点で便利です。 また、「セクションへのバインド」プロパティに対して同じインフォブロックのセクションを選択できないことも興味深いですが、同時に、同様の「要素へのバインド」プロパティはそのような制限を課しません。 これはすぐに、1つに2つの情報ブロック、要素自体を含む最初の構造、および2つ目のグループ代替グループがあることを示唆しています。

すべてがモジュールレベルで提供されるため、問題は解決されたように見えますが、それ以上の問題はないはずであり、2番目の情報ブロックのグループを基礎として、最初の要素を取り出します。 しかし、そこにありました。 カタログの標準コンポーネントは、その方法を知りません。 サポートリクエストにより、これは不可能であることが確認されました。 しかし、なぜですか? 結局のところ、このためのすべてがあり、必要なプロパティとプラットフォーム自体もそのような選択を行うために研ぎ澄まされていますが、悲しいかな...



はい、もちろん、誰もあなたのコンポーネントを作成してそこで何もすることを気にしませんが、第一に、それは開発時間、したがってコストを大幅に増加させ、第二に、それが邪魔になった標準コンポーネントに何があるのか​​興味がありました。 通常のカタログを選択し、可能な場合はカスタマイズして、必要な機能のサポートを実装することが決定されました。



最初に、上記の2つの情報ブロックを作成し、テスト情報を入力して、バインディングを設定します。 これを取得する必要があります。







(左側には上記の2つの情報ブロックがあり、右側には最初の情報ブロックのPhlipsセクションの要素があります)







(そして、右側には、最初の情報ブロックのSamsungセクションの要素があります)



カタログのメインページを開くと、情報ブロックのセクションが表示されます。







テレビなどのセクションに移動する場合は、空であることを確認してください。







それでは、ここから始めましょう。 使用するカタログコンポーネントはマルチページです。 内部では、1ページのコンポーネントのセットで構成されています。

カタログのメインコンポーネントのSection.phpは、特定のセクションのコンテンツを表示する役割を果たします。 開いて、1ページのコンポーネントbitrix:catalog.sectionが呼び出される場所を見つけます。 これは、要素のリストを表示する1ページのコンポーネントです。 すぐにカスタムディレクトリにコピーし、呼び出しをcustom:catalog.sectionに置き換えます。

custom:catalog.sectionコンポーネントのロジックを担当するcomponent.phpファイルを開きます。 API呼び出しCIBlockElement :: GetListは、興味深いものを見つけます(はい、実際には唯一のものです)。 私たちは$ arFilterに興味があります、なぜなら どのレコードをフィルタリングするかを決定するのはこのパラメーターです。 少し上に、$ arFilter自体が定義されている場所を見つけます。

$arFilter = array( "IBLOCK_ID" => $arParams["IBLOCK_ID"], "IBLOCK_LID" => SITE_ID, "IBLOCK_ACTIVE" => "Y", "ACTIVE_DATE" => "Y", "ACTIVE" => "Y", "CHECK_PERMISSIONS" => "Y", "MIN_PERMISSION" => "R", "INCLUDE_SUBSECTIONS" => $arParams["INCLUDE_SUBSECTIO NS"], );
      
      





コンポーネントが要素を認識しない理由は、「IBLOCK_ID」=> $ arParams ["IBLOCK_ID"]のように見えます。 この行を使用して、情報ブロックの外側にあるすべての要素を除外し、1つの要素と必要な他のセクションに2つの情報ブロックがあります。 原則として、この行を削除し、TVセクションのページを更新すれば十分です。要素が表示されていることがわかります。







すべて問題ありませんが、インフォブロックによるフィルタリングを削除すると、GetList関数はすべてのインフォブロックの要素を検索します。これは、まったく必要のない要素であっても、明らかにパフォーマンスを追加しません。 したがって、カタログコンポーネント自体をカスタマイズし、追加のパラメーターID_IBLOCK2を追加して、custom:catalog.sectionコンポーネントに渡すことをお勧めします。 したがって、$ arFilterの定義は次のようになります。

 $arFilter = array( "IBLOCK_ID" => $arParams["IBLOCK_ID2"], "IBLOCK_LID" => SITE_ID, "IBLOCK_ACTIVE" => "Y", "ACTIVE_DATE" => "Y", "ACTIVE" => "Y", "CHECK_PERMISSIONS" => "Y", "MIN_PERMISSION" => "R", "INCLUDE_SUBSECTIONS" => $arParams["INCLUDE_SUBSECTIONS"], );
      
      





すべてが、今ではすべてが要素のリストに整然と並んでいますが、TV P11などの製品カードページを開こうとすると、エラーが表示されます。







ここではすべてが類似しており、catalog.sectionを扱いましたが、catalog.elementはまだ別の情報ブロックで製品を探しています。 私たちもカスタマイズします。 一番上の行を見つけます。

 $arParams["IBLOCK_ID"] = intval($arParams["IBLOCK_ID"]);
      
      





したがって、次のように変更します。

 $arParams["IBLOCK_ID"] = intval($arParams["IBLOCK_ID2"]);
      
      





そして成功、製品カードが開き始めました:







それだけです 最初の情報ブロックのグループに対して割引を作成でき、カタログを作成するときにすべてが機能します。

このソリューションは、3種類の価格、1000の取引先、5000を超える割引を備えた1万製品までの作業サイトでテストされました。



エピローグ



このような簡単な操作で、タスクを解決し、私たちの唯一のケースでは必要とは思えない興味深い機能を実現しました...この機能をボックスから実装するための障害はありませんが、残念ながら...



興味深い場合は、次の記事で他のレシピを共有できます。これらのレシピは、Bitrixの十分な経験がない人にとってはすぐにはわかりませんが、役に立つことが多いです。



追記



ご清聴ありがとうございました! あなたのコメント、質問、議論に喜んでいます。

タイプミスや何らかのエラー、ドラッグの歓迎に気づいた場合;)



All Articles