Documenting 1C-Bitrix Projects: Infoblocks, DB, Integrations

1C-Bitrix Project Documentation: Infoblocks, DB, Integrations You receive a 1C-Bitrix project with hundreds of infoblocks, dozens of integrations, and custom components — and not a single document. The first day goes into **reverse engineering**: ID 17 is the product catalog, ID 23 is stock balan

Our competencies:

Frequently Asked Questions

1C-Bitrix Project Documentation: Infoblocks, DB, Integrations

You receive a 1C-Bitrix project with hundreds of infoblocks, dozens of integrations, and custom components — and not a single document. The first day goes into reverse engineering: ID 17 is the product catalog, ID 23 is stock balances. Without documentation, any change risks downtime. We document the project turnkey: from audit to auto-generation of schemas. 10 years of experience in Bitrix development, guarantee of relevance. The result is a complete project map ready for handover. We reduce adaptation time from weeks to days, cutting support costs by 50%.

Why Documentation is Not a Luxury but a Necessity

In projects without documentation, every update is a lottery. Infoblocks are renamed without recalculating bindings, integrations break due to token changes, new developers spend weeks studying code. Documentation pays for itself in 2–3 months by accelerating typical tasks: fixing a template takes 15 minutes instead of an hour, and finding an error takes a day instead of an hour.

How to Document Infoblocks

Infoblocks are the heart of the project. Documentation begins with automatic extraction of metadata. A script based on ORM collects IDs, codes, properties and generates Markdown files. Example:

// Script for generating infoblock documentation $iblocks = \Bitrix\Iblock\IblockTable::getList([ 'select' => ['ID', 'NAME', 'CODE', 'IBLOCK_TYPE_ID', 'DESCRIPTION'], 'order' => ['IBLOCK_TYPE_ID' => 'ASC', 'NAME' => 'ASC'], ])->fetchAll(); foreach ($iblocks as $iblock) { $props = \Bitrix\Iblock\PropertyTable::getList([ 'filter' => ['IBLOCK_ID' => $iblock['ID']], 'select' => ['ID', 'NAME', 'CODE', 'PROPERTY_TYPE', 'USER_TYPE', 'LINK_IBLOCK_ID'], 'order' => ['SORT' => 'ASC'], ])->fetchAll(); // Generate Markdown page for the infoblock echo "## {$iblock['NAME']} (ID: {$iblock['ID']}, CODE: {$iblock['CODE']})\n"; // ... } 

Result: property tables in a git repository, updated on deployment. Example documentation for an infoblock:

Code Name Type Notes
VENDOR_CODE Article S (string) Required, unique
BRAND Brand E (link) → Infoblock ID 8 (Brands)
WEIGHT Weight (g) N (number) For delivery calculation
IMAGES Additional photos F (file) Multiple

For catalogs of 10,000+ items, we add indexes on IBLOCK_ELEMENT.IBLOCK_ID and IBLOCK_ELEMENT_PROPERTY.VALUE — without documentation such optimization is easy to miss.

What's Included in Integration Documentation

Integrations are points of failure. The integration map includes:

  • Bitrix24 CRM ↔ Site: REST API + webhooks, bidirectional, leads from forms → B24, order statuses B24 → site. Tokens in /bitrix/.settings_extra.php, variable B24_WEBHOOK_URL. Update every 15 minutes (agent \Integration\B24Agent::sync()). Logs: /local/logs/b24_integration.log.
  • 1C:Enterprise ↔ Site: CommerceML 2.0, products and stock from 1C, orders to 1C. Schedule — every 2 hours. For more than 10,000 items, exchange takes over 30 minutes — configured split by files.

For each integration, we specify type, direction, token location, schedule, and logs. More details in the Bitrix documentation.

Documenting Custom Database

For custom tables: ERD diagram and text description. Example:

Field Type Description
ID INT AUTO_INCREMENT PK
SPECIALIST_ID INT FK → b_user.ID
SERVICE_ID INT FK → b_iblock_element.ID (IB 12)
DATE_FROM DATETIME Slot start
DATE_TO DATETIME Slot end
STATUS ENUM('free','booked','blocked') Current status
BOOKING_ID INT NULL FK → bookings.ID when STATUS=booked

Indexes: (SPECIALIST_ID, DATE_FROM), (STATUS). Created by module local.booking in install/db/mysql/install.sql.

How to Document Components

For custom components: component.php file with parameter description and a separate Markdown with examples:

<?$APPLICATION->IncludeComponent('local:catalog.filter.extended', '', [ 'IBLOCK_ID' => 5, 'PRICE_TYPES' => [1, 2], 'USE_RANGE' => true, ]);?> 

Component parameters:

Parameter Type Default Description
IBLOCK_ID int Catalog infoblock ID (required)
PRICE_TYPES array [1] Price type IDs for filter
USE_RANGE bool true Enable price range filter
AJAX_MODE bool true Update without page reload

Known limitations: does not work with SKU.

How We Document a Project in 5 Steps

  1. Audit — inventory of infoblocks, tables, modules, integrations. Identify undocumented areas.
  2. Auto-generation of schemas — scripts extract structure from the database and generate Markdown.
  3. Writing documents — describe infoblocks, integrations, components, database. Add examples and limitations.
  4. Diagrams — ERD and interaction diagrams in PlantUML or Mermaid.
  5. Process setup — update rules, PR templates, auto-generation on deployment.

Keeping Documentation Up to Date

Documentation without an update process becomes stale. Rules:

  • Changing an infoblock → update the infoblock file in the same PR.
  • Adding a table → description in /docs/database/.
  • New integration → update the map.
  • Deployment → run schema auto-generation.

Work Stages and Timelines

Stage Content Duration
Project audit Inventory of infoblocks, tables, modules 2–3 days
Schema auto-generation Scripts to extract structure from DB 1–2 days
Writing key documents Infoblocks, integrations, components 3–7 days
Diagrams ERD, integration schemas 2–3 days
Process setup Update rules, templates 1 day

Total: 2–4 weeks for a medium-sized project. Get a consultation — contact us, and we will prepare an individual plan. Time savings on support will pay for documentation in 2–3 months. Leave a request on the website — we will assess your project.