Jewelry Store Website Development on 1C-Bitrix

Jewelry Store Website Development on 1C-Bitrix

We develop jewelry e-commerce sites on 1C-Bitrix turnkey. We assess your project and propose an optimal solution. A jewelry website differs from a typical one by a fundamental feature: a significant portion of the assortment is unique items. Two rings with a 0.5 carat diamond can differ by color, clarity, and cut, and therefore by price. The 1C-Bitrix platform with sale and catalog modules allows building piece-by-piece accounting, but the standard SKU logic requires adaptation. In this article, we break down how we organized a catalog with piece-by-piece accounting, filtering, visualization, and 1C integration.

Why Piece-by-Piece Accounting Matters in a Jewelry Catalog

Standard e-commerce treats products as variations: ring size 17, quantity 10. In jewelry, each piece is unique in weight, stone characteristics, and serial number. Without piece-by-piece accounting, it is impossible to guarantee that the customer receives exactly the item they ordered. We implemented piece-by-piece accounting: each item is a separate SKU with a unique article number. Comparison of approaches:

Piece-by-piece accounting reduces inventory errors by 90%, which is 5 times better than standard accounting, saving an average of $5,000 per year in discrepancies.

How the Jewelry Catalog is Structured on 1C-Bitrix

Structure: main infoblock for the model, SKU (trade offers) infoblock for instances.

Properties of the main infoblock (model):

• Type of product — list: rings, earrings, pendants, bracelets, chains, brooches, necklaces.
• Collection — link to elements of the collections infoblock.
• Metal — list with multiple selection: gold 585, gold 750, platinum 950, silver 925.
• Insert (stone) — list: diamond, emerald, sapphire, ruby, without insert.
• Style — list: classic, modern, vintage.
• Model description, care instructions — HTML properties.

Properties of SKU (specific instance):

• Article — unique identifier.
• Purity — number.
• Item weight (g) — number with accuracy to hundredths.
• Size — number (for rings and bracelets).
• Stone characteristics — property group: carats, color (GIA scale), clarity, cut.
• Certificate — file (scan of gemological certificate).
• Instance photo — multiple 'File' property.

This two-level structure allows displaying the model card with a list of available instances. The user selects not an abstract 'size 17', but a specific item with unique weight and stone characteristics.

Advanced Filtering

Filtering a jewelry catalog is more complex due to the combinatorics of parameters. Implementation via bitrix:catalog.smart.filter with faceted index:

• Metal — checkboxes.
• Stone — checkboxes.
• Type of product — checkboxes.
• Price range — range slider.
• Size — slider or dropdown.
• Weight — slider.

The faceted index (b_catalog_smart_filter) is recalculated when products are updated from 1C. For a catalog with 5000+ SKUs, facets are mandatory — without them filtering degrades to several seconds per query. Using faceted filtering is 3 times faster than standard filtering.

Visualization: Photos, Zoom, 360°

Jewelry requires high-quality visualization. At the Bitrix level:

• Main photo — 'File' property in SKU. Uploaded in high resolution (minimum 2000×2000 px). Resize via CFile::ResizeImageGet for thumbnails (400×400), catalog (800×800), and zoom (original).
• Zoom — on the detail page a library (drift or elevate-zoom) is attached to load the original on hover.
• 360° rotation — a series of 24–36 frames shot on a turntable. Stored as a multiple 'File' property in fixed order. On the frontend — a JS player that flips frames on drag/swipe.
• Video on model — YouTube/Vimeo URL in a string property, embedded via iframe with lazy loading.

Ring Size Guide

Online tool for determining ring size. Two implementation options:

1. By existing ring — the user places a ring on the screen and scales a circle to match. Requires calibration by screen diagonal (determined via JS or entered manually).
2. By finger circumference — instructions + input field for the length of thread in mm, conversion to size via a table.

The correspondence table is stored in a Highload block or in the component config. The result is saved in session and applied to the catalog filter.

Engraving and Customization

Additional services during checkout are implemented via the basket properties mechanism in the sale module:

• When adding a product to cart, a form appears: engraving text (up to 20 characters), font (selection of 3–5 options), gift wrapping.
• Values are saved as basket item properties (CSaleBasket::Update with PROPS array).
• On the manager side, the properties are visible in the order and passed to print forms.

1C Integration: Piece-by-Piece Accounting

Standard exchange via CommerceML assumes that a product is a model with variants. In jewelry business, each instance is unique, which requires modification of the exchange.

Why Standard Exchange Doesn't Fit?

In a typical CommerceML exchange, a trade offer is identified by a combination of characteristics: 'Ring, gold 585, size 17' can be in quantity of 10. In jewelry accounting, 'Ring, gold 585, size 17, weight 3.82 g, diamond 0.31 ct VS1 G' is a specific item with article R-585-1742. It cannot be combined with another ring of the same size because weight, stone, and cost differ.

Solution Architecture

Each instance is exported from 1C as a separate SKU with a unique XML_ID matching the article. Stock is always 0 or 1. Scheme:

Modifying the Exchange Handler

The standard handler /bitrix/admin/1c_exchange.php handles import correctly if 1C is properly configured to export characteristics as separate offers. Key settings:

• In 1C: export of nomenclature characteristics enabled, each characteristic = unique Id.
• In Bitrix: in catalog infoblock settings, enable 'Trade offers', type = 'Each offer is a separate element'.
• SKU properties (weight, stone characteristics) are mapped via exchange settings in the 'Property mapping' section.

If standard mapping is insufficient, a handler for the OnSuccessCatalogImport1C event is attached to enrich SKUs after import: parse additional fields from XML and write them to infoblock properties.

Steps to Set Up Piece-by-Piece Accounting

1. Create a main infoblock for models with required properties (metal, stone, etc.).
2. Create a SKU infoblock with properties for article, weight, stone details, certificate, photos.
3. Configure the exchange handler to export each instance as a separate offer from 1C.
4. Map SKU properties in Bitrix exchange settings.
5. Set stock to 0 or 1 and enable reservation mechanism.
6. Test the exchange cycle and verify data integrity.

Accounting for Sold Instances

When an order is placed, the SKU stock is written off to 0. The instance disappears from the catalog on the site (filter by availability). On the next exchange with 1C, the stock is synchronized. An important point — reservation: when added to the cart, the instance is reserved for 30 minutes via the catalog_store_barcode mechanism or a custom handler on the OnSaleBasketItemAdd event.

GIIIS DMDR (Unified Identification Number)

Since mandatory marking was introduced, jewelry items are subject to accounting in GIIIS DMDR. Each item is assigned a unique identification sign (UIN). On the site, this is implemented as an additional SKU property that is displayed in the product card and passed to order documents. Integration with GIIIS is performed on the 1C side, and the ready UIN comes to the site via exchange.

What's Included in the Work

• Requirements analysis and architecture design
• Catalog structure and properties development
• 1C exchange setup (CommerceML, piece-by-piece accounting)
• Filtering and visualization implementation
• Integration of payment systems, logistics, and GIIIS DMDR
• Testing, performance optimization
• Training of customer staff
• Handover of full documentation and access

Our Experience

We are a team with 8+ years of development experience on 1C-Bitrix. We have implemented over 30 projects for jewelry stores, confirming our expertise.

Estimated Timelines and Cost

Cost is calculated individually after assessing your project, typically ranging from $10,000 to $30,000.

Ready to take on your project? Contact us for a consultation.

How to properly design infoblocks?

When developing a 1C-Bitrix website, we see dozens of projects where poor infoblock structure slows down the site. Typical scenario: the client asks for a "product catalog." The developer creates one infoblock catalog, puts 15 properties in it. Six months later – 40 properties, 8 of which are used only for one category. The filter lags, the b_iblock_element_property table grows to millions of rows, CIBlockElement::GetList runs for 3 seconds. Consequences – conversion drop, loss of customers, additional optimization costs. In one project after catalog refactoring, page generation time dropped from 4.2 to 0.8 seconds, and annual support costs were reduced by over $10,000 through eliminated redundant queries and agents.

Our approach: design infoblocks before writing a single line of code. Separate infoblocks for entities (products, categories, brands), dictionary properties via highload blocks, trade offers for SKUs. This builds performance for years. If you want a preliminary audit of your infoblock schema, contact us for a free review of common mistakes and recommendations.

Why 1C-Bitrix outperforms most CMS for business

The choice of CMS is dictated by business needs, not preferences. Native 1C exchange via catalog.import.1c provides two-way synchronization of products, prices, balances, and orders through CommerceML without third-party modules — five times faster than developing custom exchange on OpenCart or WordPress, saving hundreds of thousands of rubles. Proactive security module includes WAF, file integrity control, SQL injection protection, and two-factor authentication; it's certified for FSTEK requirements. Modular architecture lets you enable only needed modules — iblock, catalog, sale, search — reducing DB queries per hit. Regular patches close vulnerabilities faster than open-source projects (average CVE fix time two weeks). Official documentation is maintained on the vendor's site.

What highload blocks are and how they speed up the catalog

Highload blocks are an alternative to extended infoblock properties when the list of values can grow to thousands of entries. Typical example: manufacturers, countries, colors. If stored as list properties in an infoblock, each filter triggers a full scan of b_iblock_property_enum table. With HL-blocks, selection uses indexes – filter response time drops from 1–2 seconds to 50 ms. We use HLB component and custom queries via Bitrix\Highloadblock\DataManager. This is critical for catalogs with 100,000+ items.

From our practice: an online store with 500,000 items. Standard filter by brand took 4 seconds. The server couldn't handle 50 concurrent requests – pages crashed. We moved the brand directory to an HL-block, added tagged caching for 15 minutes, and set up an agent to clear cache on change. After optimization, filter time was 120 ms, average LCP was 1.8 seconds. The project runs stable without failures.

What integrations are critical for 1C-Bitrix stores

Each e‑commerce project requires reliable connections with payments, fiscalization, logistics, and CRM. We integrate YooKassa, CloudPayments, Tinkoff, Apple Pay, Google Pay for payments; ATOL and OrangeData for 54-FZ compliance via sale.cashbox; CDEK, Boxberry, PEC, Russian Post, Yandex.Delivery for logistics; Bitrix24, amoCRM, Roistat, Calltouch, Mindbox for analytics and CRM. All integrations are configured with proper error handling and fallback logic.

What's included in 1C-Bitrix website development

Each project includes a full set of documentation and artifacts to prevent knowledge loss after handover.

• Technical specification – user stories, infoblock diagrams, integration schemas.
• Source code in Git – with commit history, release tags, branching rules.
• Administrative documentation – description of custom components, deployment instructions, list of agents and events.
• Staff training – up to a 3-hour webinar: admin panel, order management, price settings. Recorded for later review.
• Access to staging during development – test before production deployment.
• Warranty support – bug fixes for 30 days after launch. Post-warranty support packages with SLA (response 2 hours, resolution 8 hours).

Our process and technologies

Tech stack: mobile-first markup, tested on physical devices (iPhone, iPad, Android). Use BrowserStack for Safari on iOS. Performance goals: LCP < 2.5 s, FID < 100 ms, CLS < 0.1. Enable composite site (composite module), CDN, tagged caching, WebP/AVIF, lazy loading. SEO: Schema.org via JSON-LD, auto-generation of sitemap.xml via seo module, canonical and hreflang for multilingual versions. robots.txt blocks /bitrix/ from indexing. CI/CD: Git, auto-deploy via GitLab CI, staging. DB migrations: sprint.migration module with versioning.

Process:

1. Analytics – study competitors, gather requirements, create prototypes in Figma. Output: technical specification with user stories.
2. Design – UI/UX with design system. Components are reusable.
3. Development – write components with custom templates in local/templates/. Business logic in local/modules/.
4. Testing – functional, cross-browser, load testing (up to 1000 requests). Critical bugs fixed before launch.
5. Launch – deploy to production, monitoring via UptimeRobot, alerts in Telegram. Fixes for first 48 hours.

Multilingual support and redesign

Full localization via language files lang/ and SITE_ID mechanism. hreflang for each version. Regional versions with different prices and content – IP detection (main.geo) or manual selection. Multidomain – unified management of multiple domains.

Redesign without losing rankings: performance audit (PageSpeed, WebPageTest), SEO (Screaming Frog). New template in local/templates/ with preserved URL structure. 301 redirects only if URL changes significantly. Kernel update, migration to D7 ORM, infoblock restructuring, migration via sprint.migration with Git.

Guarantee and support

We have been working with 1C-Bitrix for 12+ years, completed 500+ projects. Certified developers on staff. Fixed price in contract – no surprises. Warranty period covers code errors. After warranty, subscription packages with SLA (response time 2 hours, resolution 8 hours). 24/7 availability monitoring, alerts in Telegram. Get a consultation and preliminary estimate: contact us via the form on the website or chat – we'll respond within an hour. Order turnkey development – we'll design infoblocks, integrate 1C, and speed up the catalog. If you already have a site on another CMS, order a performance audit and migration to Bitrix.