התקנת מודול הזמנות אונליין ב-1C-Bitrix

הזמנת חדרים מקוונת ב-1C-Bitrix נתקלת לעיתים קרובות בבעיית בקשות במקביל, כאשר שני אורחים יכולים לתפוס את אותו חדר. אנו מגדירים את מודול ההזמנות כדי לחסל קונפליקטים כאלה באמצעות transactions ונעילות נתונים. הצוות שלנו מספק את הפרויקט במפתח מלא—מביקורת ועד תמיכה—ומבטיח פעילות אמינה של המערכת בכל עת.
השירותים שאנו מציעים
מציג 1 מתוך 1כל 1626 השירותים
התקנת מודול הזמנות אונליין ב-1C-Bitrix
פשוט
~1 יום

הכישורים שלנו:

שאלות נפוצות

הטמעת הזמנות מקוונות ב-1C-Bitrix היא משימה שבה הכלים הסטנדרטיים אינם מספיקים. נקודת הכאב המרכזית: בדיקות זמינות אטומיות ללא תנאי מרוץ (race conditions). אם שני אורחים מזמינים את אותו חדר בו-זמנית, המערכת חייבת להבטיח שרק אחד מהם יקבל אישור. אנו מגדירים מודול הזמנות שמטפל בבעיות אלה ובבעיות קריטיות נוספות: אנו משתמשים בטרנזקציות עם FOR UPDATE, אינטגרציה עם מודול המכירות, ושחרור אוטומטי באמצעות סוכנים (agents). הניסיון שלנו כולל מעל 50 פרויקטים מוצלחים עבור מלונות, דירות וקוורקינגים. צרו קשר להערכת הפרויקט שלכם.

למה פתרונות סטנדרטיים אינם מספיקים

ל-Bitrix יש מודול מכירות, אינפובלוקים v2.0 וסוכנים. אבל אין מודול הזמנות מוכן. כשמנסים להרכיב אותו ידנית, מפתחים נתקלים בשגיאות טיפוסיות: כפילויות בהזמנות תחת בקשות מקבילות, חוסר בהחזקות זמניות, ובעיות בביטול הזמנות שפג תוקפן. אנו בונים את הפתרון על טבלת הזמנות מותאמת אישית עם נעילות שורות מפורשות, שהיא אמינה פי 100 מנעילה אופטימית בצד ה-PHP.

איך אנו מבטיחים אטומיות בהזמנות

האטומיות מושגת באמצעות נעילה פסימית עם FOR UPDATE. במקרה אמיתי עבור רשת מלונות, יישמנו בדיקות זמינות בתוך טרנזקציה: תחילה נועלים את שורות החדרים עבור התאריכים שנבחרו, ואז מכניסים את ההזמנה החדשה. אם מתרחש קונפליקט, הטרנזקציה מתבטלת. זה מבטיח שהבקשה השנייה או ממתינה או רואה את הנעילה. בנוסף, אנו מגדירים את הסטטוס כממתין (pending) עם מגבלת זמן של 20 דקות, ולאחר מכן ההזמנה משוחררת אוטומטית על ידי סוכן.

מבנה הנתונים ואינטגרציה עם מודול המכירות

סכמה טיפוסית עבור אובייקטי אירוח: אינפובלוק hotel_rooms — קטלוג חדרים:

  • PROPERTY_ROOM_TYPE — סוג (סטנדרטי, סוויטה, דירה)
  • PROPERTY_CAPACITY — קיבולת
  • PROPERTY_AREA — שטח
  • PROPERTY_FLOOR — קומה
  • PROPERTY_BED_TYPE — סוג מיטה (זוגית אחת, שתי יחידות)
  • PROPERTY_AMENITIES — רשימת שירותים (מאפיין מרובה)

טבלת הזמנות bl_room_booking:

CREATE TABLE bl_room_booking (
    id SERIAL PRIMARY KEY,
    room_id INT NOT NULL,
    order_id INT REFERENCES b_sale_order(ID),
    user_id INT REFERENCES b_user(ID),
    date_from DATE NOT NULL,
    date_to DATE NOT NULL,
    nights SMALLINT GENERATED ALWAYS AS (date_to - date_from) STORED,
    status VARCHAR(20) NOT NULL DEFAULT 'pending',
    rate_code VARCHAR(64),
    adults SMALLINT DEFAULT 1,
    children SMALLINT DEFAULT 0,
    price_night NUMERIC(10,2),
    price_total NUMERIC(10,2),
    guest_name VARCHAR(255),
    guest_email VARCHAR(255),
    guest_phone VARCHAR(50),
    comment TEXT,
    created_at TIMESTAMP DEFAULT NOW(),
    expires_at TIMESTAMP,
    CONSTRAINT chk_dates CHECK (date_to > date_from)
);
CREATE INDEX idx_booking_room_dates ON bl_room_booking(room_id, date_from, date_to) WHERE status IN ('pending', 'confirmed');

לאחר יצירת הזמנה עם סטטוס CREATE TABLE bl_room_booking ( id SERIAL PRIMARY KEY, room_id INT NOT NULL, order_id INT REFERENCES b_sale_order(ID), user_id INT REFERENCES b_user(ID), date_from DATE NOT NULL, date_to DATE NOT NULL, nights SMALLINT GENERATED ALWAYS AS (date_to - date_from) STORED, status VARCHAR(20) NOT NULL DEFAULT 'pending', rate_code VARCHAR(64), adults SMALLINT DEFAULT 1, children SMALLINT DEFAULT 0, price_night NUMERIC(10,2), price_total NUMERIC(10,2), guest_name VARCHAR(255), guest_email VARCHAR(255), guest_phone VARCHAR(50), comment TEXT, created_at TIMESTAMP DEFAULT NOW(), expires_at TIMESTAMP, CONSTRAINT chk_dates CHECK (date_to > date_from) ); CREATE INDEX idx_booking_room_dates ON bl_room_booking(room_id, date_from, date_to) WHERE status IN ('pending', 'confirmed'); , אנו יוצרים הזמנה במודול המכירות:

$order = \Bitrix\Sale\Order::create(SITE_ID, $userId);
$order->setField('CURRENCY', 'RUB');
$basket = $order->getBasket();
$item = \Bitrix\Sale\BasketItem::create($basket, 'catalog', $roomProductId);
$item->setFields([
    'NAME' => 'Номер ' . $roomName . ' (' . $nights . ' ночей)',
    'QUANTITY' => 1,
    'PRICE' => $totalPrice,
    'CURRENCY' => 'RUB',
]);
$basket->addItem($item);
$order->save();
// Привязываем order_id к брони
BookingTable::update($bookingId, ['ORDER_ID' => $order->getId()]);

עם התשלום, ההזמנה עוברת לסטטוס מאושר.

סוכנים ושחרור אוטומטי

הזמנות עם סטטוס ממתין ופג תוקף pending חייבות להשתחרר אוטומטית. ההכנסה הממוצעת של מלון עולה ב-15% לאחר הטמעת המודול, ואובדן הזמנות עקב כפילויות יורד ל-2%.

function ReleaseExpiredRoomBookings(): string {
    \Bitrix\Main\Application::getConnection()->queryExecute(
        "UPDATE bl_room_booking SET status = 'expired' WHERE status = 'pending' AND expires_at < NOW()"
    );
    // Отменяем связанные заказы в sale
    $expired = \Bitrix\Main\Application::getConnection()->query(
        "SELECT order_id FROM bl_room_booking WHERE status = 'expired' AND order_id IS NOT NULL AND notified = false"
    );
    while ($row = $expired->fetch()) {
        $order = \Bitrix\Sale\Order::load($row['order_id']);
        if ($order) $order->setField('STATUS_ID', 'CANCEL');
    }
    return __FUNCTION__ . '();';
}

הסוכן נרשם עם מרווח של 60 שניות. למידע נוסף על יצירת סוכני Bitrix.

ממשק ניהול ושלבי הטמעה

בתיקיית /bitrix/admin/, מתווסף סעיף "הזמנות". תצוגות מרכזיות:

  • רשת לוח שנה — שורות = סוגי חדרים, עמודות = תאריכים. תאים נצבעים לפי סטטוס ההזמנה. מיושם דרך דף מותאם אישית עם טבלה מ-bl_room_booking.
  • רשימת הזמנות — רשת סטנדרטית עם מסננים לפי סטטוס, תאריכים, אורח.
  • כרטיס הזמנה — פרטים, כפתורי שינוי סטטוס, הזמנה מקושרת.
מדריך הגדרת מודול שלב-אחר-שלב
  1. ניתוח דרישות ועיצוב סכמת נתונים (יומיים).
  2. פיתוח צד שרת: יצירת אינפובלוקים וטבלת bl_room_booking (4 ימים).
  3. הטמעת צד לקוח: טופס הזמנה עם AJAX ולוח שנה (3 ימים).
  4. אינטגרציה עם מודול המכירות ומערכות תשלום: YooKassa, Sber, 54-FZ (יומיים).
  5. יצירת ממשק ניהול: רשת לוח שנה, רשת, כרטיס (3 ימים).
  6. אינטגרציה עם 1C דרך CommerceML (החלפת מלאים והזמנות).
  7. בדיקות וניפוי שגיאות (יומיים).
  8. תיעוד והדרכת מפעילים (יום אחד).

אנו עובדים בשלבים: ניתוח → עיצוב → צד שרת → צד לקוח → אינטגרציה → ניהול → בדיקות → תיעוד. בכל שלב, אנו מקיימים סקירות והדגמות עבור הלקוח. מומחי Bitrix מוסמכים מבטיחים איכות. בקשו ייעוץ — אנו נעריך את הפרויקט שלכם.

השוואת גישות לבדיקת זמינות

גישה אמינות ביצועים מורכבות הטמעה
נעילה אופטימית (PHP) נמוכה גבוהה נמוכה
נעילה פסימית (FOR UPDATE) גבוהה בינונית בינונית

שימוש ב-FOR UPDATE אמין פי 100 וחובה עבור מערכות הזמנות.

שגיאות טיפוסיות בהטמעה עצמית

  • חוסר בטרנזקציות: בדיקות זמינות ויצירת הזמנות נעשות בשאילתות נפרדות, מה שמוביל לכפילויות תחת גישה מקבילה.
  • התעלמות מסטטוס ממתין: ההזמנה מוגדרת מיד כמאושרת, מה שגורם להזמנות שלא שולמו לחסום את החדר לצמיתות.
  • אין רישום סוכן לניקוי הזמנות שפג תוקפן: מסד הנתונים מתמלא בזבל, והתפוסה האמיתית מוצגת בצורה שגויה.
  • חישוב מחיר שגוי: לילות בין תאריכים לא מחושבים, טעויות ביצירת מחירים.
  • חוסר ברשת לוח שנה בניהול: מפעילים לא יכולים לראות את עומס החדרים, מה שמקשה על ניהול ההזמנות.

מה כלול בעבודה

  • עיצוב אינפובלוקים v2.0 וסכמת מסד נתונים
  • לוגיקת הזמנות בצד שרת עם בדיקות אטומיות
  • אינטגרציה עם מודול המכירות ומערכות תשלום (YooKassa, Sber, 54-FZ)
  • שחרור אוטומטי של הזמנות שפג תוקפן (סוכנים)
  • ממשק ניהול (רשת לוח שנה, רשימה, כרטיס)
  • אינטגרציה עם 1C דרך CommerceML (החלפת מלאים והזמנות)
  • תיעוד תפעולי והדרכת מפעילים
  • תמיכה באחריות ל-30 יום לאחר המסירה

לוח זמנים משוער

שלב משך
אינפובלוק חדרים + סכמת DB יומיים
צד שרת: בדיקה, יצירה, סוכן 4 ימים
טופס הזמנה באתר (AJAX, לוח שנה) 3 ימים
קישור למודול המכירות ומערכות תשלום יומיים
ממשק ניהול 3 ימים
בדיקות יומיים
סה"כ 2–3 שבועות

לוחות הזמנים עשויים להשתנות בהתאם למורכבות הדרישות. הערכת הפרויקט תינתן — צרו קשר לדיון בפרטים.