Developing a personal user account on 1C-Bitrix

Developing a Personal Account for 1C-Bitrix

A client calls the manager: "What's the status of my order?", "Send me a reconciliation statement for last quarter," "I need a copy of the invoice." The manager digs into 1C, generates the document, sends it by email. Five minutes per request, twenty such calls daily—an hour and a half of time on work that should be handled by a personal account. A personal account (PA) on 1C-Bitrix is built from ready components, but a full B2B account with multi-user access and 1C integration always requires customization.

Personal Account Architecture

A typical PA is a section of the site /personal/ with a set of subsections, each implemented via a Bitrix component or custom page.

Standard components:

• bitrix:main.profile — viewing and editing profile
• bitrix:sale.personal.order — order list with details
• bitrix:sale.personal.order.cancel — cancel order
• bitrix:catalog.viewed — viewed products
• bitrix:main.feedback — contact form

In practice, this set is enough for a simple online shop: a consumer buys, tracks orders, downloads receipts. For B2B, where multiple people from one organization work with different roles, an overlay is needed.

Navigation within the PA is via SEF rules in .urlrewrite.php or a complex component with SEF mode. The second option is more convenient: all PA pages are managed from one place.

Access Rights Management

Bitrix's permissions system relies on user groups. For a PA it looks like this:

• Registered user — base access: profile, their own orders
• Wholesale client — wholesale prices, extra sections (receivables, reconciliation statements)
• Contractor — documents and payables for their organization
• Partner — referral stats, marketing materials

Groups are assigned at registration via OnAfterUserRegister handler or manually by manager. Rights are checked at two levels: file system (/personal/b2b/—access only for "Wholesale" group) and inside components (filter data by $USER->GetID()).

Deep-dive: B2B Account with Multi-User Access

Standard PA—one user, one account, their orders. In B2B, one organization has a purchaser, accountant, manager—each needs their own data set and rights. This is the main architectural challenge.

"Organization" entity. Created via a highload-block or infoblock with fields: name, TIN, KPP, legal address, payment terms, credit limit. Users are tied to an organization via a custom field UF_COMPANY_ID.

Roles within the organization:

The organization's admin adds employees via PA interface: sends invitation by email, new user registers and is automatically tied to the organization with the specified role. No need to call the manager and ask "can you add our new purchaser?"

Technical implementation:

• User -> organization binding is stored in UF_COMPANY_ID or a separate relation table (to support multi-organization access, when one person works with multiple entities)
• Roles—separate highload-block: user_id, company_id, role
• On login, organization context and user role are loaded into the session
• Components filter data by company_id: purchaser sees their orders, admin—all organization orders
• Switching between organizations—selector in the PA header

Order approval. In large organizations, orders don't go directly to supplier:

1. Purchaser creates order (status "Draft")
2. Procurement lead gets a notification, checks contents and budget
3. Approves or returns with a comment for revision
4. After approval, order moves to "Confirmed" and goes into processing

Implemented via custom order statuses in the sale module and event handlers OnSaleOrderBeforeSaved, OnSaleStatusOrder.

Personal Account Sections

Orders

Component sale.personal.order—list with filtering by status, date, amount. Details: contents, payment and delivery statuses, tracking number. Extensions:

• Repeat order — copy contents to cart with one click
• Complaint — complaint form tied to specific order and line item
• Print forms — generate invoice, act, packing slip via \Bitrix\Sale\Order::getDocuments()

Documents

Section for downloading closing documents: invoices, acts, VAT invoices, UPD. Documents are generated from the sale module or uploaded from 1C via integration. Storage is tied to the order or user via a highload-block.

For B2B it's critical that the accountant sees all organization documents, not just their own. Filter by company_id, not user_id.

Requests

Ticket system: user creates a request, attaches files, sees history and status. Implementation—via support module (technical support) or custom on an infoblock / smart CRM process. The second option is more convenient if requests should land in CRM and be handled by manager in their familiar interface.

Balance and Receivables

For B2B clients: current balance, payment history, accounts receivable. Data comes from 1C via REST or file exchange. A reconciliation statement is generated on request—user clicks a button, request goes to 1C, PDF returns in minutes.

Integration with 1C

Linking the PA to 1C is a mandatory element for B2B. The standard exchange module sale + catalog syncs catalog and orders, but for a full-featured PA, expanded exchange is needed.

From 1C to PA:

• Order history, including those placed by phone or through manager
• Accounts receivable by counterparty
• Reconciliation statements in PDF
• Personal pricing and discounts by counterparty price list
• Shipment and payment statuses

Exchange is via REST API (module rest), SOAP services, or CommerceML with extended schema. For high-load systems, data is cached in highload-blocks: on PA user request, it reads local cache rather than waiting for 1C. Sync is scheduled (cron-agent) or event-driven (webhook on 1C data change).

Security

The PA works with personal data and financial information. Minimum measures:

• HTTPS for all /personal/ section
• CAPTCHA or rate-limiting on login form—protection from brute force
• Two-factor authentication via security module (OTP)
• User action logging in "Proactive Protection" module
• Auto session termination on inactivity (configured in security module)
• For B2B—optional IP-based session restriction

Development Stages

Cost is calculated after requirements analysis—too large a range between "profile + orders" and "multi-organizational B2B account with approval and integration to three accounting systems."