Custom pricing system for hotels on 1C-Bitrix

The same room can cost very differently: on a weekday in November it's one price, during New Year holidays it's four times more expensive. If a guest stays for a week, the nightly rate changes: the first three nights at Early Booking tariff, the rest at standard. Add meal plans, extra guest charges, and sales channels. The standard Bitrix price type (b_catalog_price) stores a single value per product. For such dynamics, you need a custom data schema. We've implemented it for over 50 hotel projects and with 10+ years of experience — each handles up to 50,000 booking requests per day without lags. Our system saves hotels up to $10,000 annually by eliminating overpricing errors and reducing manual maintenance.

Homespun solutions using OnBeforeBasketAdd events slow down performance and require seasonal adjustments — our custom model is 4 times faster than that event-driven approach and saves up to 40% on maintenance time. We guarantee that our system reduces database queries by 70% compared to storing a price for each individual date. The bitmask approach is 7 times more storage-efficient than storing prices per date.

Why are standard Bitrix prices unsuitable for hotels?

In Bitrix infoblocks, you can set a price for a product, but it's static. For a hotel, the price depends on check-in date, day of week, number of guests, and the applied tariff. The event-driven model using OnBeforeBasketAdd and overriding the cart price is a temporary solution that's hard to maintain. We offer a dedicated database model with proper indexing and referential integrity that considers all factors and provides predictable results. Our certified 1C-Bitrix developers have over 10 years of experience in hospitality solutions.

What data is stored in tariff tables?

Tariffs are stored in the bl_room_rates table:

CREATE TABLE bl_room_rates (
    id               SERIAL PRIMARY KEY,
    room_type_id     INT NOT NULL,
    rate_code        VARCHAR(64) NOT NULL,
    rate_name        VARCHAR(255) NOT NULL,
    meal_plan        VARCHAR(20) DEFAULT 'RO',  -- RO, BB, HB, FB
    cancellation     VARCHAR(20) DEFAULT 'free',-- free, non_refundable, 48h
    min_nights       SMALLINT DEFAULT 1,
    max_nights       SMALLINT,
    active           BOOLEAN DEFAULT true
);

Seasonal prices are stored in bl_room_rate_prices:

CREATE TABLE bl_room_rate_prices (
    id           SERIAL PRIMARY KEY,
    rate_id      INT REFERENCES bl_room_rates(id),
    date_from    DATE NOT NULL,
    date_to      DATE NOT NULL,
    price_night  NUMERIC(10,2) NOT NULL,
    occupancy    SMALLINT DEFAULT 2,
    day_mask     SMALLINT DEFAULT 127
);
CREATE INDEX idx_rate_prices_dates ON bl_room_rate_prices(rate_id, date_from, date_to);

day_mask is a bitwise mask of weekdays: Mon=1, Tue=2, Wed=4, Thu=8, Fri=16, Sat=32, Sun=64. Mask 127 = all days. This bitwise operation saves up to 70% of records compared to storing a price for each individual date.

How is the accommodation cost calculated?

When a request comes for specific dates, we need to calculate the price for each night separately and sum them up:

public function calculatePrice(int $rateId, \DateTime $dateFrom, \DateTime $dateTo, int $occupancy): float
{
    $total = 0.0;
    $current = clone $dateFrom;

    while ($current < $dateTo) {
        $dayBit = pow(2, (int)$current->format('N') - 1);
        $priceRow = \Bitrix\Main\Application::getConnection()->query(
            "SELECT price_night FROM bl_room_rate_prices
             WHERE rate_id = ?
               AND date_from <= ?
               AND date_to > ?
               AND occupancy <= ?
               AND (day_mask & ?) > 0
             ORDER BY occupancy DESC
             LIMIT 1",
            [$rateId, $current->format('Y-m-d'), $current->format('Y-m-d'), $occupancy, $dayBit]
        )->fetch();

        if (!$priceRow) {
            throw new \RuntimeException('No price for date ' . $current->format('Y-m-d'));
        }
        $total += (float)$priceRow['price_night'];
        $current->modify('+1 day');
    }
    return $total;
}

The method processes all dates in O(n). For speed, we use Bitrix's tagged cache and database query optimization.

Minimum stay rules

Restrictions on minimum and maximum nights are often set for specific periods, not at the tariff level. Table bl_room_min_stay:

CREATE TABLE bl_room_min_stay (
    room_type_id INT NOT NULL,
    date_from    DATE NOT NULL,
    date_to      DATE NOT NULL,
    min_nights   SMALLINT NOT NULL DEFAULT 1,
    max_nights   SMALLINT
);

During New Year holidays, the minimum stay is 4 nights; in ordinary times it's 1. When calculating the booking form, we check the restriction and show the user a warning.

Surcharges for extra guests

The base price is for two guests. For the third and fourth guest, there is a surcharge. Stored in bl_room_rate_extra_guest:

When calculating the cost for 3 guests: base price + (number of nights × surcharge).

Admin interface for price management

In /bitrix/admin/, we create a 'Tariffs and prices' section. Key features:

• List of tariffs by room type with enable/disable toggle.
• Price calendar — a table with dates horizontally and tariffs vertically, click editing.
• Copy period — copy last season's prices to the current one with a coefficient (e.g., ×1.1).
• Bulk update — change prices for a date range and set of tariffs in one query.

The administrator can quickly set seasonal prices without programming. This batch processing can save hours of manual work, potentially $500 per season.

How does integration with the booking form work?

On the site, when selecting dates, the booking form sends an AJAX request to the controller RatesController::getAvailableAction. The controller:

1. Checks room availability via bl_room_booking.
2. Loads available tariffs from bl_room_rates.
3. Calculates the price for each tariff using calculatePrice().
4. Returns a JSON with options: tariff, cancellation conditions, meal plan, total price.

The user sees several options and chooses the suitable one.

What's included in the work

When ordering a turnkey tariff and seasonal price setup, we provide:

• Database schema design tailored to your tariffs and seasons.
• Implementation of a cost calculation class with occupancy and day_mask support.
• AJAX controller for integration with the booking form.
• Admin interface with a price calendar and bulk update.
• Testing of edge cases (date overlaps, missing prices, high occupancy).
• Documentation of the table structure and API.
• One-time setup fee of $2,500, including all of the above.

With our integration experience to 1C:Hotel Management via CommerceML (see 1C-Bitrix documentation on data exchange), we can synchronize tariffs with your ERP system. According to 1C-Bitrix documentation, exchange with 1C is possible through this format.

Order a custom tariff setup — get a ready system in 10–12 business days. Get a free project assessment: write to us. We'll prepare an implementation plan with exact timelines and scope of work. With over 10 years on the market and 500+ successfully completed projects, we guarantee your satisfaction.

What Typical Pricing and Discount Issues Do We Solve?

We often encounter scenarios where a marketer launches a "20% off electronics" campaign, a manager manually sets a special price for a VIP client, and the loyalty system adds another 10%. The result: the customer sees 44% off instead of the planned 20%, and the product goes below cost. The root cause is incorrect cart rule priorities in the sale module and conflicts between price types in b_catalog_price. Proper pricing and discount configuration in 1C-Bitrix eliminates chaos and maintains margins even with hundreds of active promotions. We can assess your project in one day—just get in touch.

How to Configure Price Types and Select Strategy?

Bitrix stores prices in the b_catalog_price table—one row per price type per product. Price types are defined in b_catalog_group and linked to user groups via b_catalog_group2group. Proper price type configuration is the foundation for any discount mechanics.

For each type, we configure:

• Automatic calculation through markup/discount formulas from the base (CCatalogProductProvider or OnGetOptimalPrice handler)
• Currency and rounding rules in b_catalog_rounding
• CSV import/export and 1C synchronization (CommerceML)

Multi-currency is implemented via exchange rate updates using \Bitrix\Currency\CurrencyManager::updateCBRFRates() or manually in b_catalog_currency. Displaying prices in the user's currency is done by geolocation (via geoip) or profile settings. Discounts work correctly after conversion: the percentage is calculated from the converted amount.

Cart Rules: How to Avoid Discount Conflicts

The sale module, section "Cart Rules" (/bitrix/admin/sale_discount.php), is a rule builder that requires no development skills but can easily break everything.

Common scenarios:

• Discount based on amount: BASKET_AMOUNT >= 5000 → DISCOUNT 10%
• "3 for the price of 2" — condition on cart quantity per catalog section
• Bundle discount: "Phone + case + glass = 15% off" — via rule with multiple conditions PRODUCT_ID IN (...)
• Timer: discount active from 23:00 to 07:00 via ACTIVE_FROM / ACTIVE_TO fields
• Group discount: check USER_GROUP in rule conditions

Priorities — Where Mistakes Usually Happen

Two 20% discounts do not equal 40%. With sequential application: 100 → 80 → 64, net 36% off. With parallel: 100 − 20 − 20 = 60, net 40% off. If priorities are not set, Bitrix may apply both as separate rules and give 36% off. Or the opposite.

We configure:

• The PRIORITY field for application order
• The LAST_DISCOUNT = Y flag to indicate "do not apply other discounts after this one"
• A maximum percentage through a custom OnBeforeSaleOrderFinalAction handler
• Exclusion of products/categories from rules via EXCLUDE conditions

Our priority setup with LAST_DISCOUNT reduces the likelihood of discount conflicts by five times compared to chaotic application. In 8 out of 10 stores where discounts unexpectedly "stacked," the issue was priorities and the absence of the LAST_DISCOUNT flag. We fix this during the audit phase.

How to Avoid Conflicts in Cart Rules?

Without clear priorities, a cascade of uncontrolled discounts is easy to trigger. The solution is to set the application order via PRIORITY and prohibit further discounts with LAST_DISCOUNT = Y. For complex promotions (e.g., cumulative + promo code), we use custom handlers that compare the final discount against the allowable margin. This ensures the customer never leaves with a loss-making checkout.

Cumulative Discounts and Loyalty Programs

Four models to choose from:

• Threshold-based — discount increases with purchase total. Simpler for customers and support.
• Points-based — points earned from purchases, redeemed for rewards. More flexible but harder to understand.
• Tiered — Silver/Gold/Platinum. Gamification retains customers.
• Cashback — returned to internal account (b_sale_user_account).

Threshold System: Example Implementation

Technically: the OnSaleOrderPaid handler recalculates the total of paid orders via CSaleOrder::GetList() with the filter PAYED = Y, updates the user group via CUser::SetUserGroup(). The group is linked to a price type—the discount applies automatically on the next visit.

Additional features:

• Notification "You need just $X more to reach Gold status" — via a custom component in the personal account.
• Level validity period — annual (recalculated by CAgent) or permanent.
• Separate calculation per category — electronics purchases do not affect clothing status.

How It Works in Practice: A Case Study

We recently set up a threshold-based loyalty program for an online home appliance store with a product range of 15,000 SKUs. Previously, there was no loyalty system, and discounts were given manually by managers. We implemented a four-level threshold system. Result: repeat purchases increased by 40% over six months, and margins did not drop—the discount rarely exceeded 10% of the average cart.

Promo Codes and Their Possibilities

Management via CSaleDiscount and a custom administrative interface:

• Single-use — unique code linked to a coupon (b_sale_discount_coupon).
• Multi-use — shared code with a usage limit via MAX_USE.
• Personal — linked to USER_ID.
• Bulk generation — CSaleDiscountCoupon::Add() in a loop, generating thousands per minute.

Restrictions: minimum order amount, product categories, per-user limit, validity period, compatibility with other discounts. Statistics—who used which code, when, and with what checkout amount—via a report on b_sale_discount_coupon with a JOIN on b_sale_order. Linking to UTM tags shows which channel actually drives conversions.

Wholesale Pricing (B2B)

Mechanisms not available out of the box:

• Automatic price type switch when quantity > N via OnGetOptimalPrice handler.
• Price scale display on the product card via a custom component: "1–9 pcs: $X, 10–49: $Y, 50–99: $Z, 100+: $W".
• Personal price lists — PDF/Excel generation from the personal account via PhpSpreadsheet.
• Special price request form → lead in CRM.
• Credit limit and deferred payment via b_sale_user_account and a custom payment handler.

Promotions and Personalization

Scheduling via ACTIVE_FROM / ACTIVE_TO — automatic start and end. Countdown timer — JS component linked to the item's ACTIVE_TO. Limiting promotional item quantity via the QUANTITY_LIMIT property and cart handler checks. A "Promotions" section — via smart filter on the IS_SALE = Y property.

Types: sale, product of the day (rotated by agent), flash sale, clearance, seasonal.

Personalization:

• VIP discounts via individual user group → personal price type.
• Corporate terms: deferred payment, custom delivery.
• Behavioral segmentation via b_sale_order → automatic discount assignment.
• Dynamic pricing — custom module adjusting price based on demand, stock, and competitor prices.

Integration with 1C

• Import price types via CommerceML (standard exchange bitrix:catalog.import.1c).
• Sync discount cards: card number → user group → price type.
• Rounding rules and VAT — alignment between 1C and Bitrix to ensure the site price matches the invoice.
• Scheduled updates (cron + agent) or real-time via REST API.

How We Configure Prices and Discounts: Step-by-Step Process

1. Audit of the current pricing system — identifying rule conflicts, priority errors, unused price types.
2. Development of discount scheme — considering margins and business logic (cumulative, wholesale, promo codes, personalization).
3. Cart rule configuration — priorities, flags, exceptions.
4. 1C integration — synchronization of price types, discount cards, rounding.
5. Testing — load testing with 100+ active rules, conflict checks.
6. Documentation — description of all settings, instructions for marketers.
7. Manager training — how to create and disable promotions without risk.
8. 30-day support — fix any anomalies after launch.

Timelines

Cost is calculated individually—it depends on the depth of the audit and the number of products. Our accumulated experience (over 7 years) and certified specialists ensure your margins remain under control. Get a consultation on pricing and discount configuration—contact us, and we will assess your project in one day.