Commerce catalogue
Offers, attributes and usable product-selection journeys.
← All technologies
1C-Bitrix · BIG FISH
Web development with 1C-Bitrix
We build corporate and commerce websites with bespoke design, catalogues and accounting-system integration. This is the Bitrix Site Manager platform, not the Bitrix24 CRM.
BIG FISH / 1C-BITRIX
01Accounting system
02Batch validation
03Catalogue and cache
04Customer product page
Design × technology × your workflow
PRODUCT CAPABILITIES
Technology becomes
a working product.
Accounting integration
Agreed rules for exchanging prices, stock and orders.
Partner sales
Customer groups and contract terms in one interface.
INTERACTIVE EXAMPLE
Try the workflow.
See the outcome.
Inspect price and stock synchronisation. The accounting system sends a new data version and the website updates the product for the selected customer group.
Educational example with fictional data. Actions stay in your browser. This models the workflow; it is not a connected CMS, server or database.
1C-Bitrix
1C-BitrixWorkflow result
The example is ready to explore.
WORKFLOW ARCHITECTURE
Every step has
a responsibility.
01
Accounting system
02
Batch validation
03
Catalogue and cache
04
Customer product page
| Layer | Outcome |
|---|---|
| Interface | Input, limits, loading and errors are clear. Keyboard operation is available. |
| Data | Values have an owner, format and freshness rules. |
| Release | Critical journeys, backups and recovery have been checked. |
BIG FISH · DESIGN & DEVELOPMENT
Strong design.
In every state.
We design beyond the opening screen. Empty data, loading, access restrictions and errors are all part of the product. Consistent components help preserve quality as the website evolves.
PRACTICAL GUIDE
Building a product
with 1C-Bitrix.
Architecture, constraints and testable workflows. The exact configuration follows the project requirements.
1C-Bitrix / 01
Platform and edition
Start with the required tasks and modules available in the selected edition: content, commerce catalogue, orders and exchange. Do not confuse Site Manager with Bitrix24. Account for licences, renewals and external solutions separately from development. Review the existing environment and configuration limits before designing the product.
Acceptance check
The required module exists in the selected edition.
1C-Bitrix / 02
Catalogue and offers
Distinguish a product, a saleable offer and its attributes. A size or configuration may require a separate SKU with its own stock. Filters need consistent types and units rather than arbitrary strings. Model images, documents and related services separately to avoid unnecessary catalogue duplication across information blocks.
Acceptance check
Different SKUs have independent stock.
1C-Bitrix / 03
Components and design
Build the interface through controlled component templates and project code. Keep platform updates compatible with the presentation layer. Test discounted products, multiple offers, missing photos and long names. Mobile filters and basket interactions need their own design decisions rather than simply shrinking the desktop layout.
Acceptance check
A card without an image remains usable.
Batch: catalogue-108
Source: accounting system
Version: 2
Fields: sku, price, available_quantity
Apply: validate → write → invalidate cache1C-Bitrix / 04
Prices and customers
Retail and contract prices may depend on user groups and sales terms. Recalculate the order and check offer availability on the server. Cache keys must account for permissions and price types that affect the response. Personal terms must never come from a shared public card, even if the interface hides them afterwards.
Acceptance check
Anonymous buyers cannot access dealer pricing.
1C-Bitrix / 05
Accounting-system exchange
Assign ownership of prices, stock, descriptions and order status. Exchange contents depend on the 1C configuration and selected mechanism. Validate a batch before applying it and retain its identifier and processing outcome. Define atomicity and recovery so a failure does not silently leave different catalogue sections on inconsistent versions.
Acceptance check
An invalid batch leaves active data unchanged.
1C-Bitrix / 06
Orders and payments
Order, payment and delivery states are distinct. Verify payment notifications on the server and process repeats without duplicate credit. Recalculate totals when order contents change and apply agreed restrictions. Test cancellation, partial payment, delivery-provider outages and stock changes that occur while checkout is in progress.
Acceptance check
A repeated notification does not create another payment.
1C-Bitrix / 07
Caching and performance
Measure category pages, search, filtering and checkout against a realistic catalogue. Define which changes invalidate component caches. Faster public browsing must not mix customers’ baskets or prices. Optimise queries, images and markup, then test load against an agreed usage profile.
Acceptance check
The new price appears after synchronisation.
1C-Bitrix / 08
Acceptance and support
Test duplicate batches, invalid data, different customer groups and recovery after interruption. Validate module updates on a project copy first. Hand over the exchange procedure, status definitions and operator instructions. Restrict accounting-system credentials and payment settings to the employees who need them.
Acceptance check
The operator knows the next step after failure.
FAQ
Before we start
Is this a ready-made product?
No. The example illustrates a proposed workflow for 1C-Bitrix. We design the production system around your requirements, data and integrations.
Can we retain our current systems?
We first review their interfaces, data ownership and constraints. The result may be an integration, a phased migration or a focused replacement of one component.
What do we receive at handover?
The agreed deliverables include design assets, source code, environment requirements and operational instructions. Scope, ownership and support are recorded in the contract.
Let’s design your product
Tell us about your workflow, audience and existing systems. We will define the interface, technical boundaries and delivery stages.