Clarify warranty claim procedure

docs/tz-fregat.typ

@@ -2663,48 +2663,17 @@ Wireframe-прототип:
 Ключевые сторонние компоненты, используемые в текущей реализации, перечислены в разделе технической архитектуры настоящего технического задания.
 
 #pagebreak(weak: true)
-= 12. Технико-экономические показатели
+= 12. Стадии и этапы разработки
 
 
-== 12.1 Назначение показателей
-
-
-Технико-экономические показатели используются для фиксации ожидаемого прикладного эффекта от разработки программного продукта.
-
-Расчет финансовой эффективности, окупаемости или экономического эффекта в денежном выражении не входит в состав настоящего технического задания, если стороны не согласуют такой расчет отдельно.
-
-== 12.2 Ожидаемый прикладной эффект
-
-
-Разработка программного продукта должна обеспечить:
-
-- снижение объема ручной коммуникации при приеме и сопровождении заказов
-- единый интерфейс для клиента, менеджера и суперменеджера
-- ускорение обработки заявок за счет фиксации состава, параметров и статусов в системе
-- снижение риска потери информации по заказам, заявкам и бонусным операциям
-- повышение прозрачности статусов заказов и актуальности данных для клиента
-- централизованное хранение истории изменений
-- возможность дальнейшего развития клиентского, менеджерского, бонусного и интеграционного контуров
-
-== 12.3 Ограничения
-
-
-Программный продукт не заменяет учетную систему 1С и не является первичным источником бухгалтерских, складских или финансовых данных.
-
-Экономический эффект зависит от полноты внедрения продукта в рабочие процессы заказчика, качества данных 1С, доступности внешних каналов уведомлений и соблюдения эксплуатационных требований.
-
-#pagebreak(weak: true)
-= 13. Стадии и этапы разработки
-
-
-== 13.1 Общий порядок выполнения работ
+== 12.1 Общий порядок выполнения работ
 
 
 Работы выполняются поэтапно, чтобы согласовывать ключевые решения до перехода к следующей части реализации.
 
 Переход к следующему этапу выполняется после согласования сторонами результата предыдущего этапа либо после фиксации замечаний, не препятствующих продолжению работ.
 
-== 13.2 Этап 1. Разработка и согласование технического задания
+== 12.2 Этап 1. Разработка и согласование технического задания
 
 
 На этапе разрабатывается и согласуется настоящее техническое задание.
@@ -2718,7 +2687,7 @@ Wireframe-прототип:
 
 Критерий завершения этапа: утверждение технического задания сторонами.
 
-== 13.3 Этап 2. UX/UI и согласование визуального подхода
+== 12.3 Этап 2. UX/UI и согласование визуального подхода
 
 
 На этапе подготавливаются 2-3 сверстанные страницы личного кабинета с основными элементами интерфейса.
@@ -2738,7 +2707,7 @@ Wireframe-прототип:
 
 Критерий завершения этапа: согласование визуального подхода сторонами.
 
-== 13.4 Этап 3. Функциональная реализация без интеграции с 1С
+== 12.4 Этап 3. Функциональная реализация без интеграции с 1С
 
 
 На этапе реализуются основные пользовательские и менеджерские сценарии без подключения обмена с 1С.
@@ -2763,7 +2732,7 @@ Wireframe-прототип:
 
 Критерий завершения этапа: готовность и приемка основного функционала без интеграции с 1С.
 
-== 13.5 Этап 4. Интеграция с 1С и отладка обмена
+== 12.5 Этап 4. Интеграция с 1С и отладка обмена
 
 
 На этапе выполняются подключение, настройка и отладка интеграции с 1С.
@@ -2786,7 +2755,7 @@ Wireframe-прототип:
 
 Критерий завершения этапа: подтвержденная сторонами работоспособность сценариев с 1С в согласованном объеме.
 
-== 13.6 Этап 5. Передача результата и приемка
+== 12.6 Этап 5. Передача результата и приемка
 
 
 На этапе выполняются итоговая проверка, устранение критичных замечаний и передача результата работ.
@@ -2802,10 +2771,10 @@ Wireframe-прототип:
 Критерий завершения этапа: подписание акта приемки либо наступление условий приемки, предусмотренных договором.
 
 #pagebreak(weak: true)
-= 14. Порядок контроля, приемки и гарантийного сопровождения
+= 13. Порядок контроля, приемки и гарантийного сопровождения
 
 
-== 14.1 Общие положения приемки
+== 13.1 Общие положения приемки
 
 
 Приемка результата работ должна подтверждать соответствие программного продукта требованиям настоящего технического задания, условиям договора и согласованным требованиям заказчика.
@@ -2823,7 +2792,7 @@ Wireframe-прототип:
 - интеграционный обмен с 1С в согласованном объеме
 - пользовательская и эксплуатационная документация в согласованном объеме
 
-== 14.2 Виды проверок
+== 13.2 Виды проверок
 
 
 Для контроля результата работ используются следующие виды проверок:
@@ -2836,7 +2805,7 @@ Wireframe-прототип:
 - проверка интеграционного обмена с 1С
 - проверка запуска и работы сервисов в согласованном эксплуатационном контуре
 
-== 14.3 Критерии приемки
+== 13.3 Критерии приемки
 
 
 Программный продукт считается соответствующим требованиям, если:
@@ -2852,7 +2821,7 @@ Wireframe-прототип:
 - текущая задолженность клиента и дата актуальности данных отображаются при наличии этих сведений из 1С
 - критичные дефекты, препятствующие выполнению основных сценариев, устранены до передачи результата
 
-== 14.4 Передаваемые материалы
+== 13.4 Передаваемые материалы
 
 
 В состав передаваемых заказчику материалов входят:
@@ -2867,7 +2836,7 @@ Wireframe-прототип:
 
 Технические схемы, модель данных, роли, архитектура, стек, состав сервисов и требования к интеграциям являются частью настоящего технического задания и не дублируются в отдельных документах без отдельного согласования сторон.
 
-== 14.5 Порядок фиксации замечаний
+== 13.5 Порядок фиксации замечаний
 
 
 Каждое замечание, выявленное при приемке, должно содержать:
@@ -2881,17 +2850,35 @@ Wireframe-прототип:
 
 Замечания, не препятствующие выполнению основных пользовательских и интеграционных сценариев, могут быть зафиксированы сторонами для последующего устранения в согласованном порядке.
 
-== 14.6 Гарантийный срок
+== 13.6 Гарантийный срок
 
 
 Гарантийный срок на разработанные модули, сервисы и дополнительный функционал составляет 6 месяцев с даты подписания акта приемки выполненных работ, если иной порядок не согласован сторонами.
 
 Гарантия распространяется на дефекты разработанного программного продукта, проявившиеся при штатной эксплуатации и относящиеся к функционалу, реализованному исполнителем.
 
-== 14.7 Порядок гарантийного обращения
+== 13.7 Первичная проверка гарантийного случая заказчиком
 
 
-Гарантийное обращение должно быть передано исполнителю в письменной форме или иным согласованным сторонами способом.
+До направления гарантийного обращения заказчик выполняет первичную проверку на своей стороне и исключает причины, не относящиеся к разработанному программному продукту.
+
+В рамках первичной проверки заказчик проверяет:
+
+- доступность сервера, контейнеров, базы данных и сетевой инфраструктуры, на которых размещен программный продукт
+- работоспособность домена, DNS, TLS-сертификатов, reverse proxy и иных инфраструктурных компонентов заказчика
+- наличие необходимых ресурсов сервера, включая доступное место, память и процессорную нагрузку
+- корректность переменных окружения, секретов, токенов и доступов, которые находятся в зоне ответственности заказчика
+- доступность и корректную работу 1С, внешних API, почтового сервиса, Telegram, Max и иных внешних систем
+- отсутствие изменений в форматах, правах доступа, настройках интеграций и учетных данных внешних систем
+- отсутствие самостоятельных изменений кода, конфигурации, базы данных или инфраструктуры без согласования с исполнителем
+- воспроизводимость проблемы на конкретном пользовательском сценарии
+
+Если по итогам первичной проверки заказчик предполагает, что причина относится к разработанному исполнителем функционалу, заказчик направляет гарантийное обращение исполнителю.
+
+== 13.8 Порядок гарантийного обращения
+
+
+Гарантийное обращение должно быть передано исполнителю в письменной форме или иным согласованным сторонами способом после первичной проверки на стороне заказчика.
 
 В обращении должны быть указаны:
 
@@ -2901,13 +2888,17 @@ Wireframe-прототип:
 - ожидаемый результат
 - фактический результат
 - дата и время обнаружения
+- результат первичной проверки на стороне заказчика
+- сведения о состоянии сервера, контейнеров, базы данных и внешних систем, если они связаны с проявлением дефекта
 - дополнительные материалы, если они нужны для диагностики
 
-Исполнитель выполняет диагностику дефекта и, если дефект относится к гарантийной зоне ответственности, устраняет его без дополнительной оплаты.
+Исполнитель выполняет диагностику обращения в пределах разработанного им функционала. Если по результатам диагностики дефект относится к гарантийной зоне ответственности исполнителя, исполнитель устраняет его без дополнительной оплаты.
 
-Срок устранения гарантийного дефекта составляет не более 3 дней с даты получения обращения либо иной срок, согласованный сторонами с учетом критичности и характера дефекта.
+Если по результатам диагностики причина связана с инфраструктурой заказчика, внешними системами, изменением доступов, изменением форматов обмена, настройками 1С, почтовыми или мессенджерными сервисами, такое обращение не считается гарантийным дефектом программного продукта.
 
-== 14.8 Ограничения гарантийного сопровождения
+Срок устранения гарантийного дефекта составляет не более 3 дней с даты получения полного обращения, содержащего сведения, достаточные для воспроизведения и диагностики дефекта, либо иной срок, согласованный сторонами с учетом критичности и характера дефекта.
+
+== 13.9 Ограничения гарантийного сопровождения
 
 
 Гарантийное сопровождение не распространяется на случаи, когда некорректная работа вызвана: