Сопровождение рекламного размещения
Доведи поручение до готовых файлов и понятного следующего действия. Установи сторону пользователя — блогер, рекламодатель или агентство — и защищай её интересы конкретными условиями. Навык самостоятельный: docx-contracts, банковский модуль, конкретный календарь или ОРД не нужны. Python запускай через uv run; зависимости объявлены в скриптах. Пути команд в справках относятся к каталогу навыка, $WORK — существующая папка сделки вне него.
Начало и продолжение
При сопровождении сделки веди deal-state.json с известными условиями, существенными поручениями пользователя и открытыми вопросами. Используй инициализацию. При продолжении сначала прочитай состояние, документы и новые сообщения. Разовый счёт использует отдельные бухгалтерские данные.
Первый содержательный ответ при подготовке документов составь по порядку уточнения: отдели ещё не заданные вопросы от уже отложенных сведений. Сопоставь материалы с картой полей выбранных шаблонов, задай оставшиеся вопросы до сборки и дождись ответа; варианты условий предложи для согласования. Прямое поручение подготовить проект без уточнений выполни с обозначенными пробелами.
Выбор режима
Прочитай справку нужного режима; не загружай все справки без необходимости.
| Поручение или новые материалы | Порядок работы |
|---|---|
| Получен договор или приложение контрагента, в том числе с подписью | Сверка полученной редакции: прочитай весь пакет, сравни условия и подготовь нужные правки. |
| Нужно подготовить свой договор или приложение | Шаблоны и сборка: отдельные договор, ТЗ, приложение с креативом; при изменении подписанных условий — дополнительное соглашение. |
| Нужно импортировать или подтвердить креатив | Версия и подтверждения; для токена, полного материала ОРД и маркировки — ОРД и ЭДО. |
| Нужно проверить готовность или обновить сопровождение | Готовность к публикации, затем сроки и напоминания. |
| Нужны счёт или УПД | Бухгалтерские документы: данные, печать и границы XML. |
| Нужно установить допустимость рекламы или правовые условия | Правовая справка; проверь первоисточники на дату размещения. |
Если вместе с вопросом о готовности пришла новая редакция договора, сначала выполни сверку и учти изменившиеся условия в состоянии и плане.
Общие правила
- Сохраняй смысл и происхождение. Не выдумывай реквизиты, НДС, сроки, подписи или оплату. Различай роли участников, факт, подтверждение, поручение и предложение. Числовое условие сохраняй с точным значением, единицей, минимумом/максимумом и началом отсчёта. Новые условия предлагай явно. Дата сообщения не доказывает дату события; пустая подпись в копии не доказывает отсутствие другого подписанного экземпляра или нарушение порядка оплаты.
- Сохраняй версии. Полученные оригиналы и прежние выданные файлы не перезаписывай; исправления оформляй отдельно. Дата основного договора сохраняется между редакциями, её явное изменение учитывается по порядку выдачи. При новом доказательстве обнови текущие факты и все актуальные собственные материалы, старые выводы оставь в истории. Порядок сохранения и восстановления точных файлов — в справке.
- Разделяй материал и маркировку. В новой схеме
creative— текст, ссылки и медиа без конкретного ERID; его выдача, принадлежность и вставка учитываются отдельно. Полученные оригиналы не меняй. Если ERID уже есть в исходнике, используй порядок версий и подтверждений, включая исключение для действующего подписанного приложения прежней схемы. Выбранные текст и карту ссылок импортируй дословно черезdeal.py import-creative: сохраняй пробелы, эмодзи, якоря, порядок и повторы URL. Получение или замена ERID не меняет согласование неизменного материала, но требует проверки маркировки. Полныйcreative_sha256бери только изimport-creative/fingerprint. - В документах — реквизиты и условия сторон. Статусы проверок, сомнения, разбор переписки и задания агенту сохраняй в состоянии сделки. Не заполняй ими договор, приложения, счёт или УПД; неизвестное значение в проекте договора оставь коротким местом для заполнения по правилам шаблонов.
- Закрывай пропуски перед окончательной выдачей. Сверь итоговый текст с картой полей: реквизиты, суммы, даты, сроки и контакты. Окончательный договор, рабочий счёт и УПД не должны содержать незаполненных обязательных полей,
{{…}},____или «уточнить». Недостающие данные запроси по порядку уточнения. Явно отложенные сведения повторно не спрашивай: такой договор или приложение выдавай только как проект и перечисли оставшиеся пропуски в сообщении пользователю. Для рабочего счёта или УПД дождись обязательных данных. Места для будущих подписей и необязательной печати пропусками не считаются. - Подготовка документов и разрешение публикации различаются. Будущая оплата, неподтверждённый ERID, открытая правовая проверка или отсутствие подписей не мешают подготовить проект с обозначенными пробелами. При поручении подготовить пакет и наличии согласованного текста создай также проект Приложения № 2 сейчас. Готовность публикации устанавливай по подтверждениям и политике сделки.
- Сопровождение использует доступные напоминания. После согласования даты выбери подходящий инструмент среды: крон, рутины, календарь или другой доступный способ. В пределах поручения создай напоминания и сохрани их сведения в состоянии сделки; одного канала достаточно, несколько — по выбору пользователя. JSON/Markdown/ICS — необязательный экспорт для выбранного файлового способа, а не условие выдачи документов. Полноту следующих действий оценивай по открытым вопросам, обновление напоминаний — по правилам расписания. Срок обязательства и час напоминания различаются; пропуск напоминания сам по себе не требует переноса публикации.
- Проверяй окончательные файлы. Заполняй готовый шаблон DOCX через
render_contract.py, сохраняй карту полей и ручные правки. После последней правки прочитай итоговый текст. Просмотр в редакторе и PDF — по порядку проверки DOCX; PDF нужен только по потребности. Адреса перехода в своём и полученном приложении проверь черезinspect_links.py --expectedпо правилам сверки ссылок. - Бухгалтерские границы сохраняются. Счёт создаётся без подписи и печати; полностью оплаченный экземпляр —
invoice_status=paid_archive. PDF печатай из того же HTML и просмотри все страницы. XML — неподписанный титул продавца с XSD-проверкой; подпись, приём оператором и подтверждение операции проверяются отдельно. Неподдерживаемый случай не имитируй готовым XML. - Внешние действия требуют поручения. Не подписывай, не отправляй контрагенту, не публикуй и не меняй кабинеты без соответствующего разрешения. Уже данное разрешение повторно не спрашивай. При недоступном инструменте выполни локальную часть и назови точное действие пользователя.
Выдача результата
При выдаче новых или изменённых файлов выполни техническую проверку: зарегистрируй файлы, включая PDF при его наличии, и проверь сообщение со ссылками командой handoff.py check --state … --response …. Флаг --record-issue добавляй только при выдаче файлового плана. Исправь ошибки до выдачи; передай проверенные файлы и ссылки. Обычные уточнения и ответы без нового пакета не требуют этой процедуры.
Начни с решения и ближайших действий, подробности оставь в файлах. Утверждения должны соответствовать текущим документам и подтверждениям. Техническая согласованность выдачи не доказывает готовность публикации, подписание, отправку или установку напоминаний. Для разовой бухгалтерской задачи применяй проверку ссылок без состояния сделки.
