Food delivery website development using 1C-Bitrix

Food Delivery Website Development on 1C-Bitrix

Food delivery website — full e-commerce project with catering specifics. Not just catalog and cart: there are delivery zones with different timing and minimums, dish modifiers (sauce, size, toppings), kitchen system integration for auto-order transmission, and courier tracking. 1C-Bitrix covers foundation via sale module and commerce catalog, while delivery specifics enhanced with custom handlers and integrations.

Menu Catalog: Info Block with Trade Offers

Catalog built on Bitrix commerce catalog. Each dish — info block element with linked trade catalog. Categories (pizza, sushi, burgers, drinks, desserts) — info block sections.

Element properties:

• Composition — text field
• Weight — numeric (grams)
• Calories / Macros — numeric properties
• Cook Time — numeric (minutes), used for delivery time calculation
• Labels — multiple list (spicy, vegetarian, new, bestseller)
• Photo — mandatory file property

Modifiers via Trade Offers (SKU). 25cm and 35cm pizza — two SKUs with different price and weight. Toppings (double cheese, bacon, mushrooms) — trade offer properties type "list" with markup. On front, JS component recalculates total on topping selection.

Alternative for mass modifiers (sauces for each dish) — separate "Add-ons" info block with many-to-many link via binding property. On front, dish addition popup shows add-on selection.

Promo Codes and Loyalty Program

Promo codes — native sale module mechanism. Discount types:

• Fixed sum for order over N rubles
• Percent on whole order or category
• Free delivery
• Gift on order (product with zero cost)

Loyalty program — accumulative. Internal user account (module sale, "Customer Accounts" section): bonus accrual as order percentage, deduction next order. Accrual rules configured via module business logic without custom development.

Push Notifications on Order Status

On status change (accepted → cooking → en route → delivered) client gets notification. Channels:

• SMS — via messageservice with connected provider (SMS.ru, SMSC)
• Email — sale module mail event templates
• Push in Browser — Web Push API (Service Worker + VAPID-keys)

Push implemented as custom event handler OnSaleStatusOrder. Status change triggers handler checking subscription and sending via Web Push. Subscription requested at first order.

Cart with Delivery Zones

Delivery cart differs from regular e-shop. Key features:

Delivery Zones by Geolocation. City divided into zones, each with parameters:

Zones stored in highload-block with coordinate polygons (GeoJSON). On checkout, customer enters address, JavaScript sends request to Yandex.Geocoder (or DaData), gets coordinates, determines zone via point-in-polygon. Result cached by address.

Implementation in sale: zones connected as delivery services (handler CDeliveryHandler). Custom handler gets coordinates from order property, determines zone, returns cost and times. If address outside zones — delivery unavailable, checkout blocked.

Min Order checked in two places: front (JS blocks button) and backend (handler OnSaleBeforeOrderAdd returns error). Dual check prevents bypass via direct POST.

Time Slots. Customer chooses "ASAP" or specific slot (12:00–12:30, 12:30–13:00). Available slots generated dynamically: current time + cook time of longest dish + delivery time by zone. Past slots and overloaded (order limit per slot) — unavailable.

Kitchen System Integration

iiko or R-Keeper transmission — mandatory integration for automation. Without it, manager manually transfers order from site to POS, losing time and making errors.

iiko Interaction Scheme:

1. Order completed on site → event OnSaleOrderAdd
2. Handler forms JSON request to iiko Transport API (/api/1/deliveries/create)
3. Request: positions with iiko SKU (map via info block property "ID in iiko"), address, phone, comment, delivery time
4. iiko returns order ID, saved to Bitrix order property
5. Cron agent every 2 minutes polls iiko status (/api/1/deliveries/by_id)
6. Status change (cooking → ready → en route) — updates sale order status, notifications trigger

Nomenclature Mapping — critical. Each dish on site matches iiko position. Link via property "External ID". New dish addition requires admin to fill this field — without it order won't transmit. Validation on element save via handler OnBeforeIBlockElementUpdate.

Modifiers transmitted as nested JSON objects. Modifier structure between iiko and site must match — mapping configured during integration, fixed in docs.

Error Handling: if iiko unavailable — order saved in Bitrix with "Awaiting Kitchen Transmission" status. Cron repeats every 5 minutes. Manager sees such orders in separate filter in admin and can transmit manually.

R-Keeper similar but via XML (R-Keeper XML API) or intermediate service (UCS Delivery). Same principle: mapping, transmission, status polling.

Courier Tracking

Basic — order statuses without map. Extended — courier display on map.

Extended version: courier uses mobile app (own or third-party — Yandex.Routing, Bringo), transmits coordinates. Site gets coordinates via courier service API and displays on Yandex.Map in customer personal cabinet. Update — on request (button) or auto via polling every 30 seconds.

Development Stages

Total: 12–14 weeks. Main timeline risk — kitchen system integration: depends on third-party documentation and API stability.