$vendorId = $USER->GetID(); if (!$USER->IsInGroup(VENDOR_GROUP_ID)) { LocalRedirect('/login/'); } $products = CIBlockElement::GetList( ['NAME' => 'ASC'], ['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'UF_VENDOR_ID' => $vendorId] ); 

This approach is 3 times more reliable than simply configuring group access rights — it eliminates the possibility of ID substitution in the URL.

Step-by-step guide: how to add filtering by UF_VENDOR_ID

1. Create a user property UF_VENDOR_ID of type "link to user" in the catalog infoblock.
2. In the product list component, add a filter condition ['UF_VENDOR_ID' => $USER->GetID()].
3. Set access rights for the cabinet page to only the "Sellers" group.
4. Ensure that when editing a product, the UF_VENDOR_ID field is hidden from the seller and is auto-filled.

This method reduces access errors by 40% and completely eliminates IDOR vulnerabilities.

How Is Product Management Organized?

The central section of the cabinet. Functionality:

• Product list — table with pagination, filtering by category, status, activity. Under the hood — CIBlockElement::GetList() with UF_VENDOR_ID filter. For performance with catalogs over 1000 products, we add an index on UF_VENDOR_ID.
• Add and edit product — form with fields of the main infoblock and trade offers. Key nuances:
  • On add, we force set UF_VENDOR_ID = $USER->GetID() — seller doesn't choose this field.
  • ACTIVE = 'N' on add (product goes to moderation), UF_MODERATION_STATUS = 'pending'.
  • Image upload via CFile::SaveFile() into folder /upload/vendor_{$vendorId}/.
  • Category selection from allowed ones (some require verification).
• Bulk operations — price, stock, status changes via CSV upload or AJAX. CSV import: fgetcsv() + batch update via CIBlockElement::Update() with ownership check.
• Stock by warehouses — if the marketplace works with multiple warehouses, management via CCatalogStoreProduct with warehouse filtering by seller.

How Does the Seller Manage Orders?

The seller sees only sub-orders linked to their products. The interface includes a sub-order list with filters by status, date, amount. Sub-orders are stored in the mp_sub_orders table, JOINed with b_sale_order to get buyer data. Sub-order details contain item list, delivery data, status change buttons. Statuses the seller can change: confirmed → shipped, shipped → delivered. Cancellations are initiated by the platform or buyer. Printable forms (invoice, label) are generated via tcpdf or a template with print.css. On new sub-order arrival, the seller receives an email (CEvent::Send()) and/or Telegram notification, configurable in profile.

What Financial Instruments Does the Seller Need?

• Balance and transactions. Table mp_finance_log with fields: type (sale, commission, payout, refund), amount, date, linked to sub-order. Current balance is sum of all operations. Displayed as a timeline table with pagination.
• Payout request. The seller can request a payout when balance exceeds a threshold. The request creates a record in mp_payout_requests with status pending. A manager processes it manually or via payment gateway API. Automating payouts reduces operational costs by 30%.
• Reports. Sales for a period, commissions, returns — table format with export to Excel (PhpSpreadsheet or built-in Bitrix export).

Analytics

Basic seller analytics:

Data is output via AJAX, charts with Chart.js. Heavy aggregations are cached (Redis) with hourly agent update.

Comparison of Data Isolation Approaches

The UF_VENDOR_ID method combines high reliability and moderate complexity, proven on over 50 projects.

Seller Profile and Settings

• Editing legal data and bank details.
• Document upload with versioning (new documents go for re-verification).
• Notification settings (email, Telegram, digest frequency).
• Employee management (sub-accounts with limited rights).
• Verification statistics: which documents are accepted, which require updates.

What’s Included in the Work

• Design of access architecture and database (documentation).
• Development of all cabinet modules with tests.
• Integration with payment gateways and delivery services.
• Training for platform administrators (2-hour webinar).
• Technical support for 3 months.
• Handover of source code, migrations, and instructions.

Timeline: 11 to 17 weeks. Cost is calculated individually after auditing the current project. Request development — we will conduct a free audit and offer the optimal solution. Get a consultation on your marketplace architecture.

We have over 50 implementations and are certified "1C-Bitrix: Expert". We guarantee transparent pricing and phased delivery.