Django admin

Основная админка управляет городами, точками, пользователями, каталогом, оплатой и интеграциями. Клиентский dashboard покрывает только часть настроек; остальные меняет техподдержка.

City

Источник: dostavixbe/locations/city/models.py.

Главные блоки:

• основные поля: город, страна, часовой пояс, длительности этапов заказа;
• флаги активности и приема заказов;
• настройки оплаты;
• бонусы и баллы;
• описания доставки;
• социальные сети;
• legal info;
• телефоны и часы работы.

Когда менять:

• город не принимает заказы;
• неверное расчетное время доставки или приготовления;
• нужно включить или отключить способ оплаты;
• меняются тексты доставки или юридическая информация;
• call center должен начать или перестать принимать заказы города.

Department

Источник: dostavixbe/locations/department/models.py и locations/department/admin.py.

Главные блоки:

• адрес и координаты;
• активность точки;
• dashboard-модули;
• единицы измерения ингредиентов и блюд;
• складские ограничения;
• график и смены;
• зоны доставки;
• настройки KKM;
• Yandex credentials;
• показатели успеха.

Поля, которые чаще всего влияют на инциденты:

• modules - какие разделы видит персонал;
• is_active - доступность точки;
• can_full_edit_confirmed_orders - редактирование подтвержденных заказов;
• show_order_to_cooker_and_packer_synchronously - видимость заказа упаковщику;
• enable_write_off_goods - списание товаров со склада;
• enable_display_of_stock_balances - показ остатков;
• is_the_sound_signal_looped и sound_interval_in_seconds - звуковой сигнал;
• kitchen_success_rate_target, delivery_success_rate_target - цели метрик.

Способы оплаты, минимальная сумма, правила баллов и переключатель блока звонка оператору могут быть заданы на уровне точки. Клиентское мобильное приложение и call center сначала используют Department, а старые настройки City служат запасным значением.

История заказа в Django admin

В карточке заказа ссылка Открыть историю ведёт к списку событий. Откройте конкретную запись, чтобы увидеть:

• название и время действия;
• кто его выполнил;
• источник: пользователь, admin, интеграция, webhook или система;
• изменённые поля в формате Было → Стало;
• состояние заказа после события.

Для новых событий снимок состояния включает основные поля заказа, позиции, группы и варианты модификаторов, а для агрегаторного заказа — данные агрегатора. Внизу остаются полный JSON снимка и технические метаданные для сложной диагностики.

Старые записи могут показывать сообщение Для этой записи снимок состояния не сохранялся — это нормальная история до появления снимков. Если снимок не сохранился для нового события, изменения полей всё равно остаются в истории; зафиксируйте запись и передайте разработчикам.

При разборе спорного заказа:

1. Откройте события по времени от старых к новым.
2. Найдите первое неожиданное изменение.
3. Сравните автора, источник и значения Было/Стало.
4. Проверьте снимок после предыдущего и текущего события.
5. Не редактируйте заказ из admin до завершения разбора — это создаст новое событие и изменит состояние.

Настройки ККМ в Department

Эти настройки критичны для печати:

• kkm_cashier_name - имя кассира в чеке;
• kkm_cashier_tax_number - ИНН кассира;
• kkm_tax_tag - НДС в процентах или тег НДС, -1 используется как НДС не облагается;
• kkm_receipt_copies - количество копий;
• kkm_pay_by_processing - проводить оплату через эквайринговый терминал;
• check_printing_of_receipts - проверка печати;
• print_a_slip_check_anyway - печатать пречек в отдельных сценариях;
• cook_printer_device_numbers - номера устройств кухонных принтеров;
• auto_print_cook_receipt_on_confirm - автопечать на кухню;
• allow_close_order_with_printed_slip_check - разрешить закрытие заказа по пречеку без фискального чека;
• fiscal_receipt_is_enabled_by_default - фискальный чек выбран по умолчанию;
• split_delivery_price_by_item_in_receipt - распределять доставку по позициям или печатать отдельной строкой;
• enable_cooking_duration_in_receipt - печатать время приготовления;
• enable_big_order_number_in_receipt - печатать крупный номер заказа;
• fee_receipt_label - подпись сервисного сбора;
• slip_receipt_limit - лимит печати пречеков.

Ошибка

Налоговые параметры должны соответствовать регистрации ККТ и требованиям фискализации. Поддержка настраивает систему, но не заменяет налогового консультанта клиента.

Сервисные сборы

Клиентская документация описывает сервисный сбор как настройку точки. Для диагностики поддержки важно разделять автоматические сборы по источнику заказа и ручные сборы, которые оператор выбирает в заказе.

Автосервисный сбор по источнику

Модель: DepartmentSourceServiceFee.

Связь: Department.auto_service_fee_source_rules.

Поля правила:

• source - источник заказа;
• fee_type - percent или fixed;
• value - значение сбора;
• is_enabled - включено ли правило;
• department - точка.

Поддерживаемые источники:

Source	Что означает
dashboard	Заказ из кабинета оператора.
app	Заказ из мобильного приложения.
site	Заказ с сайта.
aggregator	Заказ из агрегатора.
call_center	Заказ из call center.

Dashboard управляющего показывает только dashboard, app и site. Правила для aggregator и call_center поддерживаются backend и могут проверяться через админку или API.

Правила приходят и сохраняются в DepartmentSerializer через поле auto_service_fee_source_rules. Для процента значение не должно быть больше 100.

Ручной сервисный сбор

Модель: DepartmentManualServiceFee.

Endpoint:

• GET/POST /v2/departments/{department_slug}/manual-service-fees/;
• GET/PATCH/DELETE /v2/departments/{department_slug}/manual-service-fees/{id}/.

Поля:

• title - название, уникальное в рамках точки;
• fee_type - percent или fixed;
• value - значение сбора;
• is_active - доступен ли сбор оператору;
• department - точка.

Оператор передает выбранный сбор в заказе через manual_service_fee. Serializer проверяет, что сбор относится к той же точке, что и заказ.

Приоритет расчета

Расчет находится в shop/order/services/pricing.py.

Порядок:

1. Если в заказе выбран активный manual_service_fee, применяется он.
2. Если ручного сбора нет, система ищет включенное правило DepartmentSourceServiceFee по order.source.
3. Если подходящего включенного правила нет, сервисный сбор равен 0.

Фиксированный сбор добавляется как сумма. Процентный сбор считается от суммы товаров после скидок, промокодов, ручных скидок, баллов и скидок по типу доставки, но до доставки.

Поля для диагностики заказа:

• manual_service_fee - выбранный ручной сбор;
• payment_info.service_percent - процент сбора, если применен процентный сбор;
• payment_info.service_percent_amount - рассчитанная сумма сбора;
• payment_info.total_fees - суммарные начисления, включая сервисный сбор и доставку.

Если оператор не видит ожидаемый сбор, проверьте:

1. Точку заказа.
2. Источник заказа.
3. Активность ручного сбора.
4. Наличие ручного сбора в заказе.
5. Включенность правила автосбора по source.
6. Тип сбора и значение.
7. Пересчет payment_info после изменения заказа.

Offline mode

Глобальный флаг: AppSettings.enable_offline_mode.

Endpoint настроек приложения отдает флаг во frontend, после чего dashboard решает, можно ли переводить оператора в offline flow. Это не настройка точки и не модуль dashboard.

Если offline flow не включается:

1. Проверьте AppSettings.enable_offline_mode.
2. Проверьте, что frontend получил актуальные app settings.
3. Проверьте состояние сети браузера и доступность API.
4. Не смешивайте эту настройку с модулями точки или ролями пользователя.

Техническая миграция процентов заказа

В релизах вокруг сервисных сборов service_percent переводился на decimal-тип. Это техническая миграция данных заказа, а не клиентская функция.

Для диагностики старых заказов проверяйте:

• фактическое значение service_percent;
• рассчитанное service_percent_amount;
• наличие manual_service_fee;
• источник заказа и правило автосбора на дату создания заказа.

CloudPayments

Модель: CloudPaymentsCredential.

Поля:

• public_id;
• secret_key;
• привязка к city или department;
• retailer.

Правила:

• secret_key не отправлять в чатах и не добавлять в документацию;
• после изменения webhook или ключей сделать тестовую онлайн-оплату;
• если есть привязка и к городу, и к точке, используется credential точки; credential города применяется только когда у заказа нет настройки точки.

Users и Groups

Модель пользователя содержит клиентские и сотруднические поля. Для сотрудников важны:

• department;
• responsible_for_categories;
• is_receive_bot_alerts;
• is_active;
• is_staff;
• is_for_test_login;
• groups;
• retailer.

Для клиентов не меняйте вручную баллы и комментарии без согласованного основания.

Каталог

Основные модели:

• Category;
• MenuItem;
• MenuItemCityAttr;
• Modifier;
• ModifierGroup;
• Ingredient;
• Label.

Проверяйте связки город/точка/ритейлер. Частая причина “блюдо не видно” - позиция есть в каталоге, но не активна или не привязана к нужному городу/точке.

Export templates

ExportTemplate и ExportJob используются для клиентских выгрузок. Перед изменением шаблона проверьте, какие роли и страницы используют эту выгрузку.