Development of Seller Personal Cabinet on Marketplace in 1C-Bitrix
Standard Bitrix cabinet (/personal/) designed for buyer: order history, favorites, delivery addresses. Seller needs fundamentally different interface — catalog management, processing incoming orders, financial analytics. Separate site section with own access logic, components and AJAX handlers.
Access architecture
Seller cabinet — closed section, accessible only to "Sellers" group users. Protection on two levels:
URL level — in section settings (b_iblock_rights or public section settings) access only for "Sellers" group. Unauthorized user gets redirect to login page.
Data level — each data request (products, orders, analytics) filters by UF_VENDOR_ID = $USER->GetID(). Protection from IDOR attacks: seller can't get another seller's data by substituting foreign ID in request.
// Fundamental pattern — mandatory in every request
$vendorId = $USER->GetID();
if (!$USER->IsInGroup(VENDOR_GROUP_ID)) {
LocalRedirect('/login/');
}
// All data selections — with strict vendorId filter
$products = CIBlockElement::GetList(
['NAME' => 'ASC'],
['IBLOCK_ID' => CATALOG_IBLOCK_ID, 'UF_VENDOR_ID' => $vendorId]
);
Product management
Central cabinet section. Functionality:
Product list — table with pagination, filtering by category/status/activity. Under hood — CIBlockElement::GetList() with UF_VENDOR_ID filter. For performance with large catalog (1000+ products) — add index on UF_VENDOR_ID in MySQL/PostgreSQL.
Product add/edit — form with main infoblock and offer infoblock fields. Key nuances:
- On add force set
UF_VENDOR_ID = $USER->GetID()— seller doesn't select this field -
ACTIVE = 'N'on add (product goes to moderation),UF_MODERATION_STATUS = 'pending' - Image upload via
CFile::SaveFile()to/upload/vendor_{$vendorId}/ - Category selection — from allowed (some categories may require additional verification)
Bulk operations — change prices, stocks, status via CSV upload or AJAX. CSV import: fgetcsv() + batch update via CIBlockElement::Update() with check that all edited IDs belong to current seller.
Stock by warehouses — if marketplace works with multiple warehouses, stock management via CCatalogStoreProduct with seller warehouse filtering.
Order management
Seller sees only sub-orders linked to his products. Interface:
Sub-order list — with filters by status, date, amount. Sub-orders from mp_sub_orders table (custom marketplace table, see multi-vendor architecture article). JOIN with b_sale_order for buyer data.
Sub-order details — item list, shipping data (address, recipient), status change buttons. Statuses seller can change: confirmed → shipped, shipped → delivered. Cancellation initiated by platform or buyer, not seller unilaterally.
Print forms — invoice, shipping label. PDF generation via fpdf/tcpdf or HTML template with print.css.
Auto notifications — on new sub-order arrival seller gets email (CEvent::Send()) and/or Telegram (webhook). Configured in seller profile.
Finance section
Balance and operations. Finance operations table mp_finance_log with fields: type (sale / commission / payout / refund), amount, date, link to sub-order. Current balance = sum of all operations by UF_VENDOR_ID. Displayed as timeline table with pagination.
Payout request. Seller can request accumulated balance payout (if above minimum threshold). Request creates record in mp_payout_requests with pending status. Platform manager processes manually or via payment gateway API.
Reports. Sales per period, commissions, returns — tabular format with Excel export (via PHPExcel/PhpSpreadsheet or built-in Bitrix export).
Analytics
Basic seller analytics:
| Metric | Source |
|---|---|
| Revenue per period | mp_sub_orders, GROUP BY date |
| Top products by sales | b_sale_basket JOIN mp_sub_orders |
| Conversion by status | mp_sub_orders, GROUP BY status |
| Rating dynamics | mp_vendor_ratings |
| Returns (%) | mp_sub_orders WHERE status = 'refunded' |
Data displayed via AJAX requests, charts — via Chart.js or ApexCharts. Heavy aggregations moved to cache (Redis or b_cache) with hourly update via Bitrix agent.
Seller profile and settings
- Edit legal data and details
- Document upload (with versioning: new documents go to re-check)
- Notification settings (email, Telegram, digest frequency)
- Employee management (sub-accounts with limited permissions — if needed)
- Verification stats: which documents accepted, which need update
Development timeline
| Section | Timeline |
|---|---|
| Access architecture, cabinet template | 1–2 weeks |
| Product management (CRUD + CSV import) | 3–4 weeks |
| Order management (sub-orders) | 2–3 weeks |
| Finance section (balance, operations, payout request) | 2–3 weeks |
| Analytics | 2–3 weeks |
| Profile and notifications | 1–2 weeks |
| Total | 11–17 weeks |