Предложение по механизму расширения функционала документов в конфигурациях 1С 8 (неупр. формы) без снятия их с поддержки.

Цель: создать метод разработки для неуправляемых форм платформы 1с 8.2 (и выше) (в перспективе и для управляемых), который позволит, не снимая с поддержки документы конфигурации, добиться, чтобы пользователь вносил в штатный документ некие дополнительные данные, по которым в отдельных регистрах должны формироваться движения. При этом важно чтобы внесенные данные сохраняли полную информационную целостность с документом. То есть:

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

Реализация:
1.    Создается документ, который будет содержать дополнительные данные (далее Документ дополнение). Он должен содержать следующие служебные (в пользовательской форме не отображаются, кроме последнего!) реквизиты:
•    ДокументВладелец – ссылка на документ, который дополняется;
•    ДокументЗаполнен – булево;
•    ДокументВладелецПроведен – булево.
Документ имеет следующие нетривиальные черты:

    Документ всегда делает проводки по регистру сведений СоответствиеДокументов (см. п.3). Документ не помечается на удаление, а удаляется автоматически при пометке на удаление Дополняемого документа, о чем пользователь получает предупреждение с таймаутом.

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

2.    Создается новый журнал для документа, который требует дополнительных данных (далее Дополняемый документ). В форме нового журнала при выборе перехватывается форма Дополняемого документа, в основной панели создается дополнительная закладка, на которой размещается реквизит Документ дополнение. В свойстве данного реквизита «Изменяет данные» должно быть установлено значение Истина. При этом выполняется запрос к регистру сведений СоответствиеДокументов (см. п.3) и устанавливается ссылка в этот реквизит. В модуле менеджера Документа дополнение идет переопределение формы и при нажатии на реквизит пользователь видит не форму списка документов, а форму для редактирования Документа дополнение. Таким образом, пользователь всегда может отредактировать дополнительные данные. А после редактирования данных Дополняемый документ считается модифицированным и требует перепроведения.

3.    Создается регистр сведений СоответствиеДокументов, с измерением «Дополняемый документ» и ресурсом «Документ дополнение». Регистратором регистра является Документ дополнение.

4.    Создается подписка на событие «Перед Записью», где источник Дополняемый документ. В обработчике события выполняется следующее (если режим записи = проведение):
    поиск по регистру сведений СоответствиеДокументов (см. п.3) Документа дополнение;
    найденный документ проходит проверку соответствия данных внесенных в нем с данными внесенными в Источник (Дополняемый документ). Если данные внесены корректно, в Документе дополнении выставляются флаги: ДокументЗаполнен = Истина, ДокументВладелецПроведен = Истина. В противном случае флаги устанавливаются в Ложь, и для дополняемого документа устанавливается режим записи «отмена проведения», пользователю выводится соответствующее сообщение;
    Документ дополнение проводится.

5.    Создается подписка на событие «При Записи», где источник Дополняемый документ. В обработчике этого события выполняется поиск Документа дополнения по регистру сведений СоответствиеДокументов (см. п.3), если Документ дополнение не найден, то он создается, записывается и проводится. При этом флаги документа дополнения устанавливаются так:

•    Документ Владелец – Источник.Ссылка;
•    ДокументЗаполнен – Ложь;
•    ДокументВладелецПроведен – Ложь.

Примечание: функционал создания документа выносится в событие «При Записи», так как тут всегда существует ссылка на Источник.
6.    Создать для пользователя дополнительный интерфейс, в котором установить для Дополняемого документа вызов через журнал (см. п.2).

Как это работает:
    Пользователь начинает работу в интерфейсе из п.6;
    Открывает журнал документов из п.2;
    В журнале создает новый документ (или открывает существующий);
    Заполняя документ, переходит к дополнительной закладке и приступает к редактированию реквизита «Дополнительные данные»;
    Если Дополняемый документ еще не записан, пользователь получает сообщение о том, что документ необходимо записать. При перезаписи приступает к редактированию Документа дополнение.
    Пользователь закрывает Документ дополнение, проводит дополняемый документ – дополнительные движения по дополнительным данным готовы.

Ну и что ты тут ТЗ выложил? иди работай!

Цель: создать метод разработки для неуправляемых форм платформы 1с 8.2 (и выше) (в перспективе и для управляемых), который позволит, не снимая с поддержки документы конфигурации, добиться, чтобы пользователь вносил в штатный документ некие дополнительные данные, по которым в отдельных регистрах должны формироваться движения. При этом важно чтобы внесенные данные сохраняли полную информационную целостность с документом.

Накуя?

(1) Это не ТЗ это пошагово расписанная реализация (за исключением мелочей), я это уже сделал в типовой конфигурации. Вроде бы работает нормально. Просто хочу спросить мнение у 1С общественности. Возможно кто-то увидит существенный недостаток из- за которого в дальнейшем все может накрытся медным тазом...

(1) Я так полагаю, он сам это ТЗ составлял. Но думает, что оно кривое.

(2) Для того чтобы при каждом обновлении не иметь головной боли в виде выставления галочек...

(4) Я не думаю что оно красивое, написал как мог...

Видел базу, где штатные возможности сильно расширены - и новые разделы учёта, и детализированы/изменены существующие. Обновление занимает 15 минут. Вторичный документ там вовсю используется приблизительно таким образом.

(4) и ручного редактирования форм документов

(7) Спасибо!!! А можешь поподробней, или ссылку...

(7) Просто я такой методики в разжеваном виде в интернете не встречал, нагородил велосипед а сам и думаю если его до меня никто не использует, то наверно на то есть причины...

(0) Да нормально всё. У меня почти так же.
свой интерфейс, свои документы, регистры, задачи, обработки и т.д. Подписки рулят и т.п.

Навешано было на конфигурацию КА, а недавно перешел на УПП.
На поддержке, все ок.

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

Вкратце - свои объекты (ОМ, спр, док, подписки) допустимы без ограничений, новые реквизиты типовых объектов нежелательны,  но допустимы, изменять состав типовых реквизитов нельзя, что не может делать подписка - делает дополнительный документ.

(11) Спасибо!
А как у тебя реализована пометка на удаление Дополняемого документа? При этом документ-дополнение физически удаляется?

(12), если можешь, ответь на 13 ,пожалуйста.

Вечером попробую посмотреть. Напиши в мыло после обеда.

(15) Спасибо!

(13) не-не, такого у меня нет. обошелся подписками и своими регистрами

(0) 1. Документ не помечается на удаление, а удаляется автоматически при пометке на удаление Дополняемого документа, о чем пользователь получает предупреждение с таймаутом.
Сразу же 2 вопроса: При удалении доп. документа очищаются ссылки на него? В режиме пакетной обработки документов отключаешь модальное окно с предупреждением?

4.    Создается подписка на событие «Перед Записью», где источник Дополняемый документ. В обработчике события выполняется следующее (если режим записи = проведение):
    поиск по регистру сведений СоответствиеДокументов (см. п.3) Документа дополнение;
    найденный документ проходит проверку соответствия данных внесенных в нем с данными внесенными в Источник (Дополняемый документ). Если данные внесены корректно, в Документе дополнении выставляются флаги: ДокументЗаполнен = Истина, ДокументВладелецПроведен = Истина. В противном случае флаги устанавливаются в Ложь, и для дополняемого документа устанавливается режим записи «отмена проведения», пользователю выводится соответствующее сообщение;
    Документ дополнение проводится.

Сколько будет длиться поиск документа в регистре сведений и  его перепроведение, если база предполагает документооборот, к примеру, 1000+ документов в день и в этих доках используется ваш механизм? Может это негативно скажется на производительности?

6.    Создать для пользователя дополнительный интерфейс, в котором установить для Дополняемого документа вызов через журнал (см. п.2).

Это все распространяется только на один вид документов? Или на все? Если у меня 10 видов документов изменяемых подобным образом, то для каждого создается отдельный журнал или общий? Если общий, то не сложна ли будет навигация по нему?

(17) но документ-дополнение у тебя есть, или ты добавляешь реквизиты документу на поддержке?

(18) Ну я на счет общего журнала не задумывался, у меня пока для каждого вида документов свой журнал

(19) нет, есть РС который дергаю по подпискам

+ и пришлось добавить в реквизит "Основание" ЗаказПокупателя свой документ. К большому сожалению. Иначе не работает структура подчиненности

(18) Не все вопросы увидел:) Отвечаю теперь последовательно
1. Упс. На доп документ не предполагается нигде ссылок. Но если будут предполагатся то этот метод увы не рулит...
Про пакетную обработку документов тоже не задумывался...

2. 1000 документов в день тоже не тестировал... Для той базы, которую предстоит допиливать это не грозит...
Вообще конечно этот метод не может не сказатся на быстродействии так как будут при проведении происходить дополнительные обращения, запросы...
Скажем так предполагается его использовать на небольших базах с невысоким документооборотом...
Хотя согласен необходимо делать так чтобы было по минимуму затратно для вычислительных ресурсов...
Буду еще додумывать...

http://infostart.ru/public/236363/

Пришли ко мне бухи и говорят:
- у нас в 7.7 было окошко в документе с датами оплаты для книги покупок, сделай нам в 3.0 такое-же.
Ну я типа
- так придется снимать с поддержки, потом при любом обновлении Вам придется все тестировать.... короче геморрой и мне и Вам!
Бухи слезно
- ну надо, очень!
Почесал я репу и стал думать, как и на елку залезть и попу не уколоть...

(21) а где хранятся дополнительные данные, только в РС?

(22) и при отмене проведения основного документа отменяется проведение документа-основание (Документа с дополнительными данными)?

(24)Спасибо, сейчас почитаю

(24) в моем случае боюсь это не подойдет, потому что надо делать движения в своем регистре накопления, а ему требуется регистратор. А документ хотелось бы оставить на поддержке полностью.

а не гемор ли пользователям работать в двух документах?
может проще рисовать обработку, которая будет включать данные основного и дополнительного документа, причем состав колонок ессно добавлять программно?

(25) да, только РС. своих РН у меня нету
(26) нет, нет необходимости. Но можно и отменять, не вижу проблемы

(0) а зачем это надо. лучше набыдлокодить со снятием с поддержки, потом получать удой на обновлениях. Какие програмизды дураки.

(29)  у меня сделано так: в форму основного документа (Как она получается см в 0 пункт2) добавляется реквизит документ-дополнение и пользователи его открывают из основного документа как некое дополнительное окно...

Если использовать обработку в которой соединять формы двух документов то я буду заложником обновлений: изменится логика формы основного документа - мне нужно будет ее менять в форме обработки...

(23) Относительно ссылок, я сейчас может глупость скажу по незнанию, но разве на доп. документ нет ссылок в твоем РС? Или после снятия проведения основного документа запись полностью очищается в РС?

(31) я фикси, а значит чем меньше времени траится на обновления - тем лучше. Да и не хочется через год- два вспоминать что ты делал, для того, чтобы менять вручную

(32) нуяхз, если пользователям не западло лазать по двум формам, то я не против )

(29) Пользователи даже не подозревают, что работают в дополнительных документах :)

(33) В РС ссылка есть, все верно, но РС у меня подчинен регистратору (Док дополнение) и записи РС вместе с ним удалятся.

(35) возможно документ дополнение будет открываться в виде модального окна, ну или его кошерной эмуляции для УФ.
В любом случае с дополнительным документом пользователь потратит всего на 2 клика мышкой больше.

(37) Понял. Вопросов больше не имею. ИМХО: метод имеет право на жизнь.
Для примера у нас в конфе 7.7 собственной разработки доп. табличные части документов реализованы через отдельный подчиненный справочник. На форме документа таблица значений с элементами управления, куда все это в ПриОткрытии() выводится.

Так что любая реализация имеет право быть, если вписывается в конкретную учетную систему.

(33) Со ссылками можно еще решить так, при пометке удаления Дополняемого документа выполнять проверка, если на документ-дополнение есть ссылки- не давать пометить на удаление...

(38)
"Как это работает:

...

Заполняя документ, переходит к дополнительной закладке и приступает к редактированию реквизита «Дополнительные данные»; "

Вопрос - получается типовая форма на поддержке снимается с поддержки? Т.е все-таки есть снятие с поддержки?

п.6 непонятен.

(37) а зачем нужен вообще регистр соответствий, если в документе-дополнении есть ссылка на дополняемый документ?

(41) Нет снятия с поддержки нет.
См пункт 2 из 0
Коротко:
Дополняемый документ на поддержке вызывается из СОЗДАННОГО НАМИ  интерфейса, в котором пользователь создает новый документ или открывает существующий из СОЗДАНННОГО НАМИ журнала.
В этом журнале захватывается форма Дополняемого документа на поддержке и в нее динамически добавляется реквизит...

(42) Чтобы не делать поиск по всем документам, которых за несколько лет накопится много. 1С рекомендует делать все запросы по регистрам типа так быстрее.

(43)
Да, понял, не заметил сразу.
Тогда схема нормальная, наверное, единственная из возможных)

(0) Любая такого рода велосипед оправдан если небольшие и не сложные изменения. Если разработка очень сложная и много изменений это затратно. И еще может быть не совсем удобной.
Такая схема может быть оправдана если есть некая нужная и востребованная подсистема. Хотя ведь эту подсистему можно внедрить в типовую чтоб было на поддержке.

(45) ну в общем наверное да, а вот в деталях могут быть большие различия.
До сих пор не решил как лучше Делать РС подчиненным регистратору или нет (сейчас подчиненный, так надежнее, но с пометкой на удаление вышеописанные головняки)

(0)
Еще вопрос по созданию доп. закладки - допустим, в документе-дополнении у меня сложные данные отображаемые и изменяемые в Поле табличного Документа, или еще какие-то сложные вещи (не просто пара реквизитов подряд).

Не совсем понял, как на доп. закладке будут отображены реквизиты и т.ч. "Дополнительного" документа. Элементы формы доп. документа копируются? А привязки и прочее?

(46) а как ее внедрить, чтобы  сохранить поддержку, если нужно трогать типовые документы. Вот конкретная задача вдохновившая меня на этот велосипед:

В бухгалтерию (фирма небольшая), добавляется своя подсистемка по заказу ТМЦ и планированию закупок. А в ней подразумевается что Приходная накладная должна сделать расходные движения по РН "Потребность в ТМЦ" Как это сделать не сняв с поддержки. Делать дополнительный документ не комильфо.

(48)
Я так понял открывается вторая форма (форма доп. документа) и именно в ней меняем доп. данные.

(48) нет, на доп закладке всего лишь один реквизит Документ-дополнение (Для пользователей он будет называтся красиво).
По щелчку на нем в модуле менеджера идет переопределение форм и открывается не форма выбора документов дополнение, а форма редактирования именно этого документа. Форма редактирования для пользователей естественно не содержит всех служебных данных

(50) см 51

(52)
Может быть неудобно, если пользователи не очень.. усердные :)
Или если они быстро что-то редактируют. Будут забывать и путаться в формах. А если будут открыты 3 элемента справочника одновременно и 3 доп. формы - то вообще с ума кто-то может сойти )) Но в общем случае для "долгоиграющих" данных пойдет.

(53) по этой причине думаю открывать документ-дополнение модально. (Сейчас пока открывается просто)

(53)У меня реализована еще одна фича. Я о ней не писал в 0 дабы народ не путать.
У меня реализовано следующее:
1. Пользователь открыл Дополняемый Документ, из него Документ дополнение, внес туда данные, закрыл.
2. После этого открыл снова данные - те что он внес, что-то откорректировал, закрыл.
3. Закрывает Дополняемый документ, ему вопрос: Данные изменены- перепровести? Он отказывается, закрывает.
4. Проводки по Документу-Дополнение не меняются.

При открытии Документа-дополнение заново из вновь открытого Дополняемого документа в нем стоят старые данные. То что он редактировал, но не сохранил при проведении Дополняемого документа не сохранилось.

(53) Реализовано это (согласен выглядит коряво) методом дублирования всех полезных(несущих реальную информацию) реквизитов документа. В дубли реквизитов сохраняются данные до проведения Дополняемого документа. А в сами реквизиты они записываются при полном проведении документа дополнение Из Дополняемого документа (который на поддержке). При этом данные в реквизитах дублях очищаются.

(30) Перечитываю ветку и возник еще один вопрос: Связка между Дополняемым документом  и документом Дополнение у тебя задается в регистре, или за счет документа основания?

(57) связь в регистре. Основание нужно тупо для работы обработки "структура подчиненности"

(58) А регистр подчинен регистратору, или режим записи независимый?

(59) независимый

(60) а как контролируется удаление записи привязки, просто доступом пользователей к регистру?
Измерение Дополняемый Документ ведущее?