Вайб-спекинг 1С в эпоху Вайб-кодинга или "Cursor" в облаке для бизнес-аналитика 1С

1. Краткий вердикт

В ERP 2.5.27 интеграция с 1С:Документооборот есть: в метаданных выделена подсистема «Интеграция с 1С:Документооборотом» с поддержкой редакций 2 и 3 Документооборота и общей базовой функциональностью (БИД).

2. Факты по конфигурации

Структура подсистемы

Подсистема не выведена в командный интерфейс (IncludeInCommandInterface = false); работа идёт через команды на формах объектов, общие команды и панель администрирования.

Ключевые объекты по группам

Обмен и связь с ДО

Общие модули (ядро логики)

• Базовая функциональность: ИнтеграцияС1СДокументооборотБазоваяФункциональность (+ клиент, сервер, повторное использование, переопределяемые, глобальный).

• Редакция 2: ИнтеграцияС1СДокументооборот, ИнтеграцияС1СДокументооборотОбмен, ИнтеграцияС1СДокументооборотВызовСервера, клиентские/серверные варианты.

• Редакция 3: ИнтеграцияС1СДокументооборот3, ИнтеграцияС1СДокументооборот3Обмен, ИнтеграцияС1СДокументооборот3ВызовСервера, клиентские/серверные варианты.

• ОбновлениеИнформационнойБазыБИД — обновление подсистемы интеграции.

Правила сопоставления объектов ERP ↔ ДО

Через переопределяемые типы в ERP задаётся, какие документы и справочники участвуют в интеграции.

Регистры сведений

Константы и функциональные опции (включение возможностей)

Примеры: ИспользоватьИнтеграциюС1СДокументооборот, ИспользоватьИнтеграциюС1СДокументооборот3, АдресВебСервиса1СДокументооборот, учётные данные обмена, ИспользоватьСогласованиеЧерез1СДокументооборот, ИспользоватьПроцессыИЗадачи1СДокументооборота, ИспользоватьСвязанныеДокументы1СДокументооборота, ИспользоватьПрисоединенныеФайлы1СДокументооборота, ИспользоватьФайловоеХранилище1СДокументооборота, ИспользоватьЭлектроннуюПочту1СДокументооборота, ИспользоватьОбработкуОбъектов1СДокументооборота, лимиты файлов и хранения сообщений.

Команды и UI

• Группа Документооборот, общие команды: вход в ДО, задачи, присоединённые файлы, создание процессов/писем, описание веб-сервисов, «начать обработку» (ДО3).

• ОбщаяФорма.ИнтеграцияС1СДокументооборотЗадачиИсполнителя.

• Подписки на события записи документов/справочников и констант для синхронизации с ДО.

Права

• Роль.БазовыеПраваБИД

• Роль.ИспользованиеИнтеграцииС1СДокументооборотом

Перечисления (бизнес-смысл интеграции)

Например: СостоянияСогласованияВДокументообороте, ВариантыПравилЗаполненияРеквизитов, РежимИзмененияПроведенногоДокументаДанными1СДокументооборота, КлючиСопоставленияПользователей1СДокументооборот.

В составе базовой подсистемы также много общих картинок и элементов стиля для отображения задач, файлов и процессов ДО в интерфейсе ERP — это UI-обеспечение интеграции, а не отдельный бизнес-функционал.

Что не относится к 1С:Документооборот

В конфигурации есть другие подсистемы и объекты со словом «документооборот» (обмен с банками, ФНС/СФР, контролирующими органами). Это не интеграция с продуктом 1С:Документооборот.

3. Выводы / рекомендации

• Интеграция в ERP 2.5.27 — типовая библиотека интеграции с Документооборотом (БИД) плюс переопределяемые точки под прикладные объекты ERP.

• На практике выбирается редакция ДО (2 или 3) через соответствующие константы и функциональные опции; одновременно обычно активна одна линия интеграции под вашу версию ДО.

• Состав интегрируемых документов ERP определяется не «жёстким списком в подсистеме», а правилами интеграции и заполнением переопределяемых типов — это место, где смотреть, что именно у заказчика заведено в базе.

4. Риски и неизвестное

• В выгрузке не видно, включена ли интеграция в конкретной ИБ и какая редакция ДО используется — это только константы/ФО в базе.

• Не подтверждено по метаданным полное перечисление всех прикладных документов ERP с командами ДО без просмотра состава переопределяемых типов и правил в конфигурации/данных.

• Риски внедрения: права (БИД), сеть и веб-сервис ДО, размер файлов, регламентное задание обмена, сопоставление пользователей.

5. Следующие шаги

1. У заказчика уточнить версию 1С:Документооборот (редакция 2 или 3) и включённые опции (согласование, задачи, файлы, связанные документы).

2. В конфигураторе или админ-панели БИД посмотреть ПравилаИнтеграции… и переопределяемые типы — получить фактический список объектов ERP в обмене.

3. При необходимости — разобрать цепочку для одного документа (создание в ДО, согласование, возврат статуса в СостоянияСогласованияВДокументообороте).

Если нужно, могу отдельно выписать только прикладные объекты ERP (документы/справочники), перечисленные в переопределяемых типах интеграции в этой выгрузке.

1. Краткий вердикт

В Документообороте 3.0.21 есть ежедневные отчёты, отсутствия и механизм уведомлений, но типового напоминания «не заполнен ежедневный отчёт» нет. Доработку целесообразно делать расширением: регламентное задание + очередь уведомлений по образцу контроля авансовых отчётов, с отдельным списком обязанных сотрудников и исключением выходных/отсутствий.

2. Факты по конфигурации

3. Выводы / рекомендации

Оптимальный вариант

Регламентное напоминание через очередь уведомлений (не через НапоминанияПользователя):

1. Утром следующего рабочего дня (или в настраиваемое время) регламент находит обязанных, у кого за вчера нет проведённого ЕжедневныйОтчет.

2. Исключает: нерабочий день по графику; отсутствие по Документ.Отсутствие (отпуски и прочие виды вне фонда / все полные дни — по правилу ниже).

3. Кладёт уведомление в ОчередьУведомлений → сотрудник получает его штатными способами.

4. Для контроля — отчёт/список «не сдавшие» для роли КонтрольЕжедневныхОтчетов (и опционально эскалация руководителю на N-й день).

Почему так: повторяет уже работающий паттерн авансовых отчётов; не ломает типовую рассылку сводок; не требует держать сеанс пользователя; масштабируется.

Альтернатива «персональные напоминания БСП» — слабее для массового регламента и контроля. Вечернее напоминание «за сегодня» — дополнение, не замена утреннего контроля «за вчера».

Техническое задание

Конфигурация: Документооборот 3.0.21
Способ реализации: расширение конфигурации (без изменения типовых объектов «на месте»)
Цель: напоминать сотрудникам о заполнении ежедневного отчёта и дать руководителям инструмент контроля, с учётом регламента «кто обязан» и отсутствий/нерабочих дней.

1. Назначение

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

2. Участники и объекты учёта

• Сотрудник — адресат напоминания (связь с пользователем через типовые регистры сотрудников/пользователей).

• Контролёр — пользователь с правом контроля ежедневных отчётов / руководитель подразделения.

• Администратор — настройка списка обязанных, расписания, текста, эскалации.

Предмет контроля: Документ.ЕжедневныйОтчет за календарный день Дата (начало дня), статус — проведён.

3. Кто обязан вести отчёт

В типовой нет персонального признака обязанности.

В расширении — один из вариантов (рекомендуется А):

Начальное заполнение — вручную или загрузкой по списку из регламента заказчика.

Необязанные сотрудники никогда не получают напоминание и не попадают в контроль «обязан, но не сдал».

4. Правила «нужно ли напоминать за дату D»

Напоминание за день D сотруднику S, если выполнены все условия:

1. Включена ФО использования ежедневных отчётов (типовая политика учёта рабочего времени).

2. S входит в список обязанных на дату D.

3. D — рабочий день для S (при включённых графиках — по ГрафикРаботы сотрудника / основному графику; иначе — по производственному календарю организации / пн–пт — зафиксировать в настройках).

4. На D нет пересекающегося проведённого/действующего Отсутствие с полным днём (или достаточным покрытием дня).

   • Базовый API: Отсутствия.ПолучитьТаблицуОтсутствий.

   • Рекомендуется учитывать виды с ВФондеРабочегоВремени = Ложь (отпуск, болезнь и т.п.); удалённую работу / «в фонде» — не считать основанием пропуска отчёта (уточнить у заказчика).

5. Нет проведённого ЕжедневныйОтчет по S на D (УчетВремени.ЕстьЕжедневныеОтчетыНаДату или аналог в расширении).

6. Черновик / непроведённый документ не засчитывается (если заказчик хочет иначе — отдельное решение).

«Вчера не работал»: если D = вчера и п.3 или п.4 не выполнены — напоминание не формируется.

5. Когда и как напоминать

Опционально (фаза 2): вечернее мягкое напоминание в день D («заполните отчёт за сегодня») без эскалации.

6. Контроль заполнения

1. Отчёт/обработка расширения «Контроль ежедневных отчётов»: период, подразделение, только обязанные, статусы «сдан / не сдан / не требовался (выходной/отсутствие)».

2. Права — на базе роли КонтрольЕжедневныхОтчетов (+ роль расширения при необходимости).

3. Эскалация (опционально): если отчёт не сдан N рабочих дней — уведомление руководителю подразделения / контролёру (настраиваемо).

4. Типовые журналы «свои / подчинённые» остаются; расширение их не подменяет.

7. Состав объектов расширения (план)

• Регистр (или реквизит) списка обязанных.

• Константы/настройки: время запуска, лимит повторов, учитывать ли только отсутствия «не в фонде», текст, признак эскалации, N дней.

• Регламентное задание + общий модуль логики отбора и постановки в очередь.

• Значение события уведомлений + обработчики представления текста/ссылки (через расширение типовых модулей уведомлений / переопределяемые точки, без правки ядра «в лоб»).

• Отчёт контроля + команда/подсистема в интерфейсе учёта времени.

• Роли на чтение/изменение настроек и отчёта.

Типовые ЕжедневныйОтчет, Отсутствие, графики — только чтение и вызовы экспортного API.

8. Нефункциональные требования

• Выполнение под привилегированным режимом в регламенте (как у типовых контролей), с корректным сопоставлением Сотрудник ↔ Пользователь.

• Пакетные запросы (без запроса в цикле по сотрудникам).

• Идемпотентность: повторный запуск в тот же день не плодит дубли в очереди.

• Совместимость с обновлениями типовой; минимум &ИзменениеИКонтроль в типовых модулях — только необходимые точки уведомлений.

9. Критерии приёмки

1. Обязанный сотрудник без отчёта за вчерашний рабочий день получает напоминание в заданное время.

2. Необязанный — не получает.

3. Отпуск/отсутствие на вчера — не получает.

4. Выходной по графику на вчера — не получает.

5. После проведения отчёта за D повторные напоминания за D не уходят.

6. Контролёр видит список несдавших за период.

7. При выключенной ФО ежедневных отчётов регламент ничего не делает.

8. Расширение устанавливается на типовую 3.0.21 без изменения основной конфигурации.

4. Риски и неизвестное

• Риски: расширение перечисления СобытияУведомлений и врезок в формирование текста уведомлений может требовать аккуратного сопровождения при обновлениях; неверное сопоставление сотрудник/пользователь — «тихие» пропуски; при неведённых графиках критерий «рабочий день» будет спорным.

• Не найдено в выгрузке: готового события/регламента «не заполнен ежедневный отчёт»; персонального флага обязанности в Сотрудники.

• Нужно уточнить у заказчика: источник списка обязанных; засчитывать ли непроведённый документ; полный день отсутствия vs частичный; удалённая работа / виды «в фонде»; нужна ли эскалация руководителю; канал по умолчанию (только окно или ещё почта).

5. Следующие шаги

1. Зафиксировать ответы по уточнениям из §4.

2. Утвердить вариант хранения обязанных (регистр vs реквизит) и параметры расписания.

3. Оценить трудозатраты: настройка обязанных + регламент/уведомления + отчёт контроля (+ эскалация отдельным этапом).

4. После утверждения ТЗ — реализация в расширении и тест-кейсы по критериям приёмки §9.

1. Краткий вердикт

В УНФ 3.0.13 цепочка «заявка клиента → производство → отгрузка» строится вокруг Заказа покупателя, затем Заказа на производство и документа Производство, а завершается Расходной накладной. Ниже — пошаговая инструкция: что заводить, чем контролировать и на что смотреть.

2. Факты по конфигурации

Схема процесса

graph TB
Z["Заказ покупателя<br/>заявка / заказ на продажу"] --> OPT1{"Нужно производство?"}
OPT1 -->|Нет, есть остаток| R["Расходная накладная"]
OPT1 -->|Да| ZP["Заказ на производство"]
Z --> REZ["Резервирование запасов<br/>(по необходимости)"]
Z --> SC["Счет на оплату<br/>(по необходимости)"]
ZP --> MAT{"Материалов хватает?"}
MAT -->|Нет| ZS["Заказ поставщику"]
ZS --> PN["Приходная накладная"]
MAT -->|Да| PR["Производство<br/>СборкаЗапасов"]
PN --> PR
ZP --> PR
PR --> MOV["Перемещение запасов<br/>(по необходимости)"]
PR --> R
MOV --> R
Z --> R
R --> PAY["Оплата от покупателя"]

Diagram: Заявка - производство - отгрузка (flowchart)
[Заказ покупателя] --> {Нужно производство?}
{Нужно производство?} -- Нет --> [Расходная накладная]
{Нужно производство?} -- Да --> [Заказ на производство]
[Заказ покупателя] --> [Резервирование запасов]
[Заказ покупателя] --> [Счет на оплату]
[Заказ на производство] --> {Материалов хватает?}
{Материалов хватает?} -- Нет --> [Заказ поставщику] --> [Приходная накладная]
{Материалов хватает?} -- Да --> [Производство]
[Приходная накладная] --> [Производство]
[Заказ на производство] --> [Производство]
[Производство] --> [Перемещение запасов] --> [Расходная накладная]
[Производство] --> [Расходная накладная]
[Заказ покупателя] --> [Расходная накладная]
[Расходная накладная] --> [Оплата от покупателя]

Инструкция: какие документы заводить

Шаг 0. Подготовка (один раз)

Шаг 1. Заявка / заказ клиента

1. Создайте Документ.ЗаказПокупателя (раздел Продажи).

2. Выберите операцию:

   • Заявка на продажу — первичная заявка;

   • Заказ на продажу — подтверждённый заказ под производство/отгрузку;

   • Заказ-наряд / Заявка (заказ-наряд) — если это работы/услуги с исполнением в самом заказе.

3. Заполните контрагента, номенклатуру, количество, дату отгрузки, склад резерва при необходимости.

4. Проведите документ. Движения идут в т.ч. по ЗаказыПокупателей, ПотребностьВЗапасах, Запасы / резервам (в зависимости от настроек и заполнения).

По желанию на основании заказа:

• Документ.СчетНаОплату — выставить счёт;

• Документ.РезервированиеЗапасов — закрепить свободный остаток под заказ.

Шаг 2. Планирование производства

1. На основании Заказа покупателя создайте Документ.ЗаказНаПроизводство (раздел Производство).

2. Операция: Сборка (выпуск изделия) или Разборка.

3. В ТЧ Продукция — что производить; спецификация подтягивает материалы в ТЧ Запасы.

4. Укажите изготовителя, склад резерва / получателя продукции, сроки (Старт / Финиш), состояние заказа.

5. Проведите: движения по ЗаказыНаПроизводство, ПотребностьВЗапасах, ЭтапыПроизводства (если этапы включены) и др.

Если материалов не хватает:

1. На основании заказа покупателя или заказа на производство — Документ.ЗаказПоставщику.

2. По факту поставки — Документ.ПриходнаяНакладная.

Шаг 3. Факт производства

1. На основании Заказа на производство (или заказа покупателя) создайте Документ.СборкаЗапасов — в интерфейсе это «Производство».

2. Операция: Сборка / Разборка.

3. Проверьте: продукция, материалы, склады списания и поступления выпуска, связь с заказом покупателя / заказом на производство.

4. Проведите: выпуск на склад, списание материалов, закрытие потребности / заказа на производство.

Дополнительно по ситуации:

• Документ.ПеремещениеЗапасов — если выпуск на одном складе, а отгрузка с другого;

• Документ.СдельныйНаряд — учёт сдельной работы (ввод на основании заказа на производство / производства / заказа покупателя);

• Документ.РаспределениеЗатрат — распределение косвенных затрат на выпуск.

Шаг 4. Отгрузка клиенту

1. На основании Заказа покупателя (также возможен ввод из производства) создайте Документ.РасходнаяНакладная.

2. Операция для продажи: Продажа покупателю.

3. Проверьте склад, количество, заказ в шапке/строках, цены, НДС.

4. Проведите: списание запасов, закрытие заказа покупателя, расчёты с покупателем, продажи.

Если отгружаются услуги/работы — вместо или вместе с накладной может использоваться Документ.АктВыполненныхРабот (ввод на основании заказа покупателя).

Шаг 5. Оплата (после отгрузки или по счёту)

Типовые документы оплаты: Поступление на счет / Поступление в кассу (и связанные с оплатой заказа/счёта регистры).

Отчёты по теме

Ключевые объекты цепочки

3. Выводы / рекомендации

Как пользоваться цепочкой на практике:

1. Не пропускайте заказ покупателя — через него связываются производство, отгрузка, оплата и отчёты по исполнению.

2. Заявка ≠ заказ. Если нужна только фиксация интереса — операция «Заявка на продажу»; для запуска производства и резерва обычно переходят к «Заказ на продажу».

3. Сначала проверьте остатки (Анализ доступности / Запасы). Если товар уже на складе — производство не обязательно, сразу расходная накладная.

4. Спецификация обязательна для корректного выпуска — иначе материалы и себестоимость придётся заполнять вручную и легко ошибиться.

5. Ведите связь «заказ покупателя» во всех документах производства и отгрузки — иначе отчёты по выполнению заказа «разъедутся».

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

7. Контролируйте закрытие заказа состоянием/ВариантЗавершения и отчётом «Анализ выполнения заказов покупателей».

4. Риски и неизвестное

• Риски: производство без включённой подсистемы; выпуск без спецификации; отгрузка не с того склада; заказ не указан в накладной — «висит» невыполненным; резерв без последующей отгрузки блокирует свободный остаток.

• Риски: этапы производства, ордерный склад, серии/ГТД/прослеживаемость усложняют проведение — нужны соответствующие настройки и заполнение.

• Не найдено в выгрузке как отдельный документ «Заявка клиента»: в типовой это вид операции документа Заказ покупателя («Заявка на продажу»), а не отдельный объект.

• Какие именно состояния заказов и какие ФО включены у вас в базе — нужны данные информационной базы (в метаданных есть справочники состояний и опции, но фактические значения — в ИБ).

5. Следующие шаги

1. Пройти один сквозной тестовый пример: заказ → заказ на производство → производство → расходная накладная и сверить отчёты из таблицы выше.

2. Уточнить у заказчика: производство всегда под заказ или есть складской запас готовой продукции; нужны ли этапы, ордера, сдельные наряды.

3. При необходимости подготовить чек-лист проверки прав ролей и включённых функциональных опций производства/резервирования.