Согласование дополнительных работ и запчастей

Отвечать письменно не нужно - это список того, что я бы уточнил на старте. Отсортирован по силе влияния: первые четыре меняют модель данных, остальные - правила и интерфейс. Дальше в документе я отвечаю на них сам, чтобы работа не стояла.

1. Что для вас является достаточным подтверждением согласия клиента: устного подтверждения по телефону с фиксацией сотрудником хватает, или нужна подпись либо код из СМС? Отсюда следует, нужен ли клиенту отдельный интерфейс и храним ли мы доказательство согласия, а не только запись о нём.
2. Есть ли порог, ниже которого доработку можно делать без отдельного согласования - скажем, до определённой суммы или процента от исходной сметы? Кто этот порог устанавливает? Если порога нет, каждая мелочь останавливает ремонт, и процесс начнут обходить мимо системы.
3. Клиент решает по каждой позиции или по предложению целиком? Может ли он согласовать работу, но отказаться от запчасти, без которой она невозможна? Определяет, нужна ли связка позиций и на каком уровне живёт статус.
4. Откуда берётся цена: есть ли в системе прайс нормо-часов и запчастей, или мастер вводит суммы руками? Что делать, если закупочная цена изменилась уже после согласования? Определяет, храним ли мы снимок цены в позиции или ссылку на справочник.
5. Какие каналы связи с клиентом используются сейчас и какой из них основной: звонок, СМС, мессенджер, личный кабинет?
6. Что делать, если клиент не отвечает, а машина занимает подъёмник: есть ли правило эскалации, платного хранения или право руководителя решить самостоятельно?
7. Нужна ли интеграция со складом и 1С, и считается ли резерв запчасти частью согласования или отдельным шагом?
8. Система должна технически запрещать механику делать несогласованные работы, или достаточно фиксировать нарушение и уведомлять руководителя?
9. Сколько раз можно пересогласовывать одно предложение? Ведём версии или каждая попытка - отдельный документ?
10. Кто вправе дать скидку или списать позицию, и проходит ли это через тот же процесс?
11. Нужна ли печатная форма дополнительного соглашения к заказ-наряду и как она нумеруется?
12. Новый срок считает система по нормо-часам и срокам поставки, или мастер ставит дату вручную?

Ответов пока нет, поэтому фиксирую собственные решения - всё дальнейшее опирается на них. В скобках указано, что придётся переделать, если у вас принято иначе.

• 1Решение принимается по каждой позиции. Поэтому статус живёт и на предложении, и на позиции: статус предложения - производный. Если согласование только целиком, половина логики уходит.
• 2Позиции собираются в пакеты. Работа и запчасти, без которых она невозможна, согласуются вместе: нельзя согласовать замену дисков и отказаться от самих дисков. Влияет на интерфейс и проверки.
• 3Достаточно зафиксировать факт согласия. Храним канал, сотрудника, точное время, дословный комментарий и снимок состава. Подпись и код из СМС - за рамками первой версии, но модель данных к ним готова.
• 4Цена фиксируется снимком. При формировании предложения цена копируется в позицию. Позднее изменение прайса не меняет согласованную сумму: клиент согласовал конкретные цифры.
• 5Предложение версионируется. После отправки правка запрещена, любое изменение создаёт версию +1, прежняя помечается заменённой. Так история остаётся читаемой.
• 6Запчасти резервируются в момент согласования. Раньше - нельзя, иначе остаток блокируется под несогласованные заказы. Наличие проверяется дважды: при формировании и при согласовании.
• 7Запрет на работы до согласования - мягкий. Перевести позицию в работу нельзя, но если она всё же отмечена выполненной, создаётся инцидент и уведомление руководителю. Жёсткую блокировку в сервисе обходят, инцидент - нет.
• 8Один активный черновик на заказ-наряд. Новые находки добавляются в текущее предложение, пока оно не отправлено. После отправки создаётся следующее по номеру.
• 9Срок считает система, мастер может переопределить. Расчёт по сумме нормо-часов и максимальному сроку поставки; ручное значение требует комментария и попадает в историю.
• 10Роли - как в задании: механик, мастер-приёмщик, кассир, руководитель. Отдельной роли оператора нет, её функции у мастера-приёмщика.

Процесс разделён на две зоны ответственности: техническую - механик находит и обосновывает, и коммерческую - мастер-приёмщик оценивает, говорит с клиентом и фиксирует решение. Разделение нужно, чтобы механик не назначал цены, а мастер не выдумывал неисправности.

Схема 1. Путь предложения от находки механика до документов.

Статусов два уровня. На позиции - решение клиента, на предложении - общий итог. Иначе частичное согласование не описать честно: статус «согласовано частично» не говорит, что именно разрешено делать, а статус позиции говорит.

ожидает согласована отклонена снята сотрудником в работе выполнена нет запчасти

Схема 2. Статусы предложения по стадиям; под каждым - куда из него можно перейти.

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

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

Центральная сущность - версия предложения, к ней привязано всё остальное. Решение хранится по позициям, а не одним полем: иначе частичное согласование невозможно восстановить.

Ключевой экран - карточка дополнительных работ, рабочее место мастера-приёмщика в момент разговора с клиентом.

Использовал Claude как инструмент проектирования: черновики структуры, проверка модели на полноту, вычитка. Решения принимал сам и за результат отвечаю сам - ниже что отдавал, что взял и что забраковал.

1. Затрачено времени2 часа 40 минут: разбор задачи и вопросы - 40 минут, процесс, статусы и данные - час, макет экрана - 40 минут, сборка и вычитка - 20 минут.
2. Что сам, что с ИИСам: архитектурные решения - двухуровневые статусы, пакеты позиций, снимок цены, мягкая блокировка; макет экрана; проверка на противоречия; редактура. С ИИ: черновики списков, проверка модели на полноту, единый формат критериев. Всё, что выдал ИИ, проверял и правил - подробности в разделе 10.
3. Что проработал бы дополнительноУведомления клиента и шаблоны сообщений по каналам; интеграцию со складом и 1С, включая резервы и поставку под заказ; права согласования у клиентов-юрлиц; печатные формы дополнительного соглашения; отчёт по отклонению от первоначальной сметы в разрезе мастеров; работу мастера с телефона в цехе.
4. Срок полной реализации2 недели10 рабочих дней после знакомства с проектом. Первые 2 дня - разбор кода и ответы на вопросы из раздела 1, дальше серверная часть и интерфейс параллельно, последние 2 дня - тестирование и правки.
5. Ориентировочная стоимость100 000 ₽Фиксированная цена за описанный объём, а не почасовая ставка.
6. Что входит в стоимостьАнализ и уточнение требований, проектирование модели данных и статусов, интерфейс экрана дополнительных работ, серверная часть и интеграция с существующим заказ-нарядом, история изменений и права ролей, тестирование, исправление замечаний по итогам приёмки и запуск на вашем окружении.
7. Что может повлиять на срок и стоимостьСостояние существующего кода и наличие документации; интеграция со складом и 1С - это отдельный объём; требование юридически значимого подтверждения согласия (подпись, код из СМС) - плюс примерно неделя; личный кабинет клиента для самостоятельного согласования - отдельная задача; скорость ответов по вопросам из раздела 1 и доступ к тестовому стенду.
8. Проектная работаДа, готов. Оформление через ИП, договор и закрывающие документы предоставлю.
9. Загрузка40 часов в неделюПри необходимости больше, включая вечера и выходные. График гибкий.
10. Готовность приступитьСразуВ день подтверждения договорённостей.