ПОЛИТОТДЕЛ — ОЧЕРЕДЬ ЗАКАЗОВ ДЛЯ 1С Сборка 20.10.2026, дополнение к приёму остатков Quotes. СХЕМА ОБМЕНА 1. Гость выбирает тип, даты, гостей и питание отдельно каждому от 2 лет. 2. После включения передачи в админке сайт сохраняет контакты, цену и заявку. 3. 1С каждые 5 секунд получает очередь через GET /api/Sync/Orders. 4. 1С создаёт заказ и отвечает через POST /api/Sync/SetStatusOrder. 5. Сайт убирает подтверждённое событие из очереди и показывает гостю результат. 6. Отмена проходит через ту же очередь и требует отдельного ответа 1С. На основании присланных файлов приняты значения: orderStatus = 1 — создание; orderStatus = 3 — отмена; syncStatus = 0 — создание принято; syncStatus = 2 — отмена обработана. Это вывод из примеров, его нужно подтвердить у разработчика 1С. Путь /api/Sync/SetStatusOrder выбран по именам файлов; точный URL вызова в обработке 1С пока не был предоставлен. При необходимости его нужно согласовать. Коды ошибок и отказа 1С, кроме показанных успешных ответов, пока не известны. Они отклоняются с 422 и не снимают заявку с очереди. ПОЛУЧЕНИЕ ОЧЕРДИ GET https://booking.politotdel.ru/api/Sync/Orders?companyId=64&token=<исходный токен> companyId и token передаются как в вашей строке 1С. URL-кодируйте значения параметров при сборке адреса. Авторизация браузера, cookie и CSRF не нужны. HTTPS обязателен. Заголовок Authorization необязателен; если передан, должен содержать тот же исходный токен без Bearer. Ответ не кешируется. Файлы .js являются JSON-примерами, исполнять JavaScript не нужно. Сайт возвращает JSON в теле HTTP-ответа, отдельные скачиваемые ссылки не создаёт. По умолчанию повторена обёртка из файлов: { "СтруктураМассивОтвет": [ ...заказы... ] } Если новых событий нет: {"СтруктураМассивОтвет":[]} Если «СтруктураМассивОтвет» добавляет только ваш журнал 1С, а HTTP-клиент ждёт массив, выберите в админке «Массив заказов без обёртки». Тогда ответ [...] или [] соответственно. Формат нельзя менять без согласования с обработкой 1С. В одном ответе до 100 событий. Неподтверждённые повторяются при следующих опросах. События, которые дольше не выдавались, идут первыми, чтобы не блокировать очередь. GET отмечает попытку выдачи, но НЕ означает успешное создание заказа. ЗАЩИТА ОТ ПОВТОРОВ У заказа постоянный числовой orderId; отмена использует тот же orderId. На сайте повтор кнопки оформления с тем же ключом не создаёт новый заказ. В 1С обязательно хранить связь (companyId, orderId) с собственным документом и искать её ДО создания. Если документ уже создан, отправляйте тот же ответ. Сам HTTP не гарантирует доставку ровно один раз: ответ может потеряться. Одинаковый orderId в повторной выдаче нельзя воспринимать как новый заказ. 1С должна атомарно проверить физический номер на весь заезд, включая ручные продажи, и только после этого подтвердить создание заказа. СОСТАВ ЗАКАЗА Сохранены все 110 имён полей из приложенных Orders-файлов. - companyId, orderId, roomCategoryId — числа в ответе. - roomCategoryId — исходный тип сайта, не физический номер. - proffitRoomCategoryId — отдельный внутренний код из настроек соответствий. - price — полная стоимость проживания и питания в рублях, с копейками. На сервере расчёт идёт в целых копейках; браузер цену не задаёт. - arrivalDate/departureDate — даты с T00:00:00; заезд включён, выезд исключён. - arrivalTime/departureTime — по умолчанию 17:00/15:00, локальное время Омска. - countAdults, countChilds, childAge1..10 — фактический состав гостей. - countChildsWithBeds — только дети от 2 лет. Дети 0–1 года места не занимают. Нулевой возраст отличайте от пустых childAge-полей по countChilds. - vidPitName — название питания по уточнению владельца от 20.10.2026. vidPitId не используется; в новых заявках равен null. Старые снимки и уже выданные заказы не переписываются. - roomPricePeriodId, proffitPatternId — отдельные коды из настроек админки. - tourist, touristName, email, phone — только данные нового гостя. touristId равен ID новой заявки; повторные гости автоматически не объединяются. tourist.userId — отдельный случайный UUID, не ID сессии браузера. - roomNumber — null: конкретный номер определяет 1С. - hasPayment=false, payment=0, paymentCount=0: оплаты в этой сборке нет. - token в объекте заказа — null, секрет обратно не возвращается. - Неизвестные паспортные, агентские и прочие данные остаются null. Паспортные сведения форма не запрашивает. Тарифы и коды фиксируются в снимке заявки: изменение админки не меняет уже выданный заказ. Старые контакты, ID гостей, условия возврата и тексты из примеров в поставку не перенесены. cancelOrderRule пока пуст. ПИТАНИЕ ПО ГОСТЯМ На сайте четыре пакета, цены общие для всех номеров и задаются в админке: - lunch → «Только обед»; - breakfastLunch → «Завтрак + обед»; - lunchDinner → «Обед + ужин»; - fullBoard → «3-х разовое» (по умолчанию). Минимум — обед. У каждого взрослого и ребёнка от 2 лет свой выбор. Дети 0–1 года не выбирают и не оплачивают пакет, место не занимают. За питание начисляется цена пакета × число ночей отдельно каждому гостю. Новый тариф «Завтрак + обед» изначально пуст: его должен задать администратор. При обновлении старые тарифы и суммы прежних заказов сохраняются. Внутренний API сайта принимает guestMeals: массив ID пакетов, сначала взрослые, затем дети в порядке childrenAges. Для каждого ребёнка младше 2 лет — null. Пример: adults=2, childrenAges=[1,5], guestMeals=["fullBoard","lunch",null,"breakfastLunch"]. Это внутренний формат сайта, НЕ новый согласованный контракт 1С. Без guestMeals применяется прежнее единое mealId либо fullBoard по умолчанию; дети младше 2 лет автоматически исключаются из начислений. Когда у всех гостей от 2 лет одинаковый пакет, Orders передаёт его название в единственном vidPitName. Например: "vidPitName":"3-х разовое", "vidPitId":null. Обработку питания по гостям в 1С владелец завершит позже. Эта задача больше не блокирует оформление на сайте: смешанная заявка сохраняется с ценами, контактами, guestMeals и guestMealLines, а также признаком syncDeferred=true. В базе sync_deferred=1, event=NULL и export_snapshot содержит JSON null. Формат 1С для неё не формируется, Orders такую заявку не выдаёт. Гость и администратор видят «Сохранена на сайте», а не подтверждение 1С. Временное удержание номера действует 15 минут, как у других новых заявок. По истечении срока она отменяется локально, удержание снимается, данные остаются в истории. Ручная отмена также не создаёт событие в 1С. Ответы SetStatusOrder для отложенной заявки отклоняются с 409. Повтор оформления с тем же ключом возвращает ту же заявку. При обновлении добавляется столбец sync_deferred с нулём для старых заявок; старые события и экспортные снимки не меняются. Автоматической отправки отложенных заявок после будущей доработки нет: порядок их обработки будет решён отдельно. additionalTourists не заполняется неподтверждённой структурой. ОТВЕТ СОЗДАНИЯ POST https://booking.politotdel.ru/api/Sync/SetStatusOrder Content-Type: application/JSON { "companyId": "64", "token": "<исходный токен>", "orderId": "", "syncStatus": 0, "proffitOrderId": "<настоящий ID заказа 1С>", "syncMessage": "", "arrivalTime": null, "departureTime": null } Значения-заполнители заменяются реальными. Для успешного создания нельзя передавать proffitOrderId "000000". Число или строка ID допустимы; сохранённый ID нельзя заменить другим повторным ответом. Один ID 1С нельзя связать с двумя разными заявками сайта. Повтор того же ответа безопасен. arrivalTime/departureTime могут быть null либо локальным временем той же даты в формате YYYY-MM-DDTHH:mm:ss[.fff]. Изменение дат требует отдельного согласования. Ответ сайта, HTTP 200: {"success":true,"orderId":1000000000,"duplicate":false} При повторе duplicate=true. Число в примере — условное, не рекомендованный ID. Не нужно ждать cookie или входа администратора. ОТМЕНА Заказ, который ещё ни разу не выдавался, отменяется локально без отправки в 1С. Если выдача уже была, сайт не освобождает удержание без завершения обмена. Если создание ещё не подтверждено, оно повторяется до ответа, затем выдаётся отмена. Так потерянный ответ создания не оставит бесконтрольный заказ в 1С. В очереди отмена имеет orderStatus=3, исходный orderId, сохранённый proffitOrderId, price=0 и prepayment=0, как в ваших файлах. Исходная стоимость остаётся в базе и карточке заявки; нулевая цена отмены не означает возврат денег. После обработки отмены 1С отправляет тот же объект SetStatusOrder: syncStatus=2, proffitOrderId="000000" (как в примерах) либо настоящий ID заказа. Значение "000000" не затирает сохранённую связь с документом 1С. Отмена снимается с очереди только после ответа. Поздний повтор подтверждения создания не возвращает уже отменённый заказ в активные. СРОКИ И ОПЛАТА На ответ создания отведено 15 минут. Если срок прошёл, невыданная заявка отменяется локально; выданная завершает обмен созданием и затем отменой. После ответа создания начинается срок неоплаченной заявки — по умолчанию 60 минут, в админке 15–1440 минут. Истечение приводит к запросу отмены. Проверка срока выполняется при опросе 1С, чтении заявок гостем и администратором. Отдельный cron не требуется при работающем опросе каждые 5 секунд. Если 1С недоступна, неотвеченная выданная заявка продолжает удерживать место. PayKeeper пока не подключён. Ответ 1С не подтверждает платёж. В настоящем оформлении нет кнопки имитации оплаты; она остаётся только для старых демо-броней. Не используйте этот этап как завершённый запуск онлайн-продаж. НАСТРОЙКИ ПЕРЕД ВКЛЮЧЕНИЕМ Админка → «Заявки в 1С» → «Настройки передачи и соответствия кодов». Нужно заполнить: 1. Начальный orderId из свободного диапазона до 2147483647, согласованный с 1С. Диапазон не должен пересекаться с прежним сайтом. После первой заявки счётчик меняется только автоматически. По старым примерам актуальный максимум неизвестен. 2. Актуальные roomPricePeriodId и proffitPatternId. В примерах оба 56, но это заявки на январь 2026 года, поэтому эти значения не включены автоматически. 3. proffitRoomCategoryId для каждого продаваемого типа. Из примеров сохранены 16591 → 29, 16593 → 8, 16596 → 11. Остальные нужно получить из 1С. 4. Формат ответа, фактический путь SetStatusOrder и значения статусов. Коды питания не требуются: используется vidPitName, vidPitId игнорируется. Передача разных пакетов в одной заявке отложена до завершения обработки 1С. Это не мешает сохранить такую заявку на сайте. Также нужны полные остатки Quotes. После включения форма создаёт реальные заявки, но типы без внутреннего кода остаются недоступны для оформления. Выключение передачи останавливает создание новых заявок; существующая очередь продолжает обслуживаться, чтобы не терять уже выданные в 1С заказы и отмены. Старые demo_bookings никогда не выгружаются в Orders. ОСТАТКИ И СВЕРКА Текущий Quotes не содержит номера версии или перечня учтённых заказов. Нельзя надёжно понять, отражён ли конкретный новый заказ в пришедшем остатке: пакет может прийти до или после ответа создания, а также повториться. Поэтому сайт сохраняет дополнительное удержание квоты и после ответа создания. Это безопасно в отношении выдаваемой квоты, но может занизить доступность. В админке для принятого заказа есть «Сверено с 1С». Используйте только после проверки, что заказ учтён в шахматке и свежих остатках на каждую ночь. Сервер дополнительно требует время получения остатков позже ответа создания. После сверки дополнительное вычитание этого заказа отключается; остаётся квота 1С. При подтверждённой отмене локальное удержание тоже снимается. Для полной автоматизации нужны связанные с заказами/версией остатки либо явная гарантия порядка полной сверки со стороны вашей обработки 1С. ДОСТУП, ОШИБКИ И ЗАПАСНЫЕ АДРЕСА Настройки и контакты всех заявок доступны только администратору. Гость видит свои заявки по cookie браузера; ID в URL не даёт доступа к чужой заявке. JSON-ошибка: {"success":false,"error":"Пояснение"}. 400 — JSON; 401 — токен; 403 — компания; 404 — заказ/метод не найден; 405 — HTTP-метод; 409 — несовместимое состояние/ID; 413 — размер тела; 415 — Content-Type; 422 — данные/неизвестный статус; 426 — требуется HTTPS; 500 — ошибка сервера. Повторы отправляйте с тем же ID. Запасные URL без mod_rewrite: GET /sync-orders.php?action=Orders&companyId=64&token=<исходный токен> POST /sync-orders.php?action=SetStatusOrder Также /api.php?path=/api/Sync/Orders&companyId=64&token=... и /api.php?path=/api/Sync/SetStatusOrder. Приложение не пишет токены, тела запросов и контакты в журнал ошибок. Однако токен в GET-адресе может попадать в access-log самого хостинга: попросите поддержку исключить query string этих адресов из журнала или скрыть параметр token. Не публикуйте полные URL с токеном в скриншотах и общедоступных инструкциях. ПРОВЕРЕНО На PHP 8.2 пройдены 34 проверки обмена заказами и параллельное оформление: 11 попыток в 3 PHP-процессах при квоте 3 создают 3 заявки с разными ID. Проверены повторная выдача, ключ оформления, защита контактов, возврат статуса, нулевые оплаты, отмена до выдачи и после неё, поздние ответы, истечение срока, отключение новых заявок без потери очереди, сверка квоты и формат массива. Дополнительно прошли 33 проверки основной системы, 29 проверок Quotes и 29 проверок питания по гостям, обновления базы и отложенной передачи. Визуальная проверка браузером, Apache на вашем хостинге и настоящий обмен с 1С пока не выполнены. Готовый архив нужно загрузить и провести пробный обмен.