Есть конфигурация на базе УТ 10.3. Есть некий самодельный документ. Пользователь делает в своем бизнес-процессе несколько вариантов этого документа и хочет знать, что когда кто менял.
Как лучше, быстрее, эффективнее реализовать?
1) взять из БСП версионирование
2) сделать цепочку документов, каждый следующий на основании предыдущего, и к этому какой-то отчет об изменениях
3) еще что-то?
У кого какой опыт и соображения?
(1) не очень понятно...
если речь идет о исправлениях документа, т.е. ошибочно ввели, потом исправили, чтобы правильно сели взаиморасчеты, или себестоимость...то это типовое версионирование, - включаем новый документ в подписку, и потом анализируем, по потребности, кто что менял.
И совсем другое дело, если этого требует бизнес процесс...тогда, мягко говоря, сам документ спроектирован неверно. Документ - как смертный приговор, доказали, создали, оформили, подписали, провели - расстреляли. Документ остался в истории.
Если там промежуточные какие то этапы, то нужно все этапы каким то образом документировать, они должны оставаться в базе, и по ним должны строится разнообразные отчеты. Тут уже перетряхивать, ваш бизнес процесс необходимо и архитектуру.
(4) это именно промежуточные этапы проектирования. Делаем предварительный проект. Сначала конструкторы нарисовали и составили список комплектующих. Потом изучили рынок, цены, конструкторы пошевелили извилинами, поменяли что-то. Поменяли предварительный проект. Потом заказчик сказал, что ему надо не синее, а зеленое в крапинку. Опять поменяли. Так может быть несколько раз до того момента, когда утвердили проект окончательно и он пошел закуперам.
Чем плох документ и архитектура, не совсем понятно. Но хотим видеть изменения.
(2), (3) с БСП опасаюсь, что требуемые ресурсы (как то время разработки, замедление работы программы) не соответствуют масштабу задачи. С другой стороны, версионирование потом можно прикрутить и к обычным документам, отслеживать, кто что менял.
Может, сделать документ "предварительный проект", и каждое изменение делать вводом на основании предыдущего?
как вариант,
типа корректировочного документа, как в ЗУПе, документ верхнего уровня блокируется для редактирования если есть корректировка.
Зато все по процессу и все видно.
Чем плох документ и архитектура, не совсем понятно. Но хотим видеть изменения.
документ, сам по себе отражает какое то событие и является учетной единицей...а вам нужно отражать и хранить много промежуточных действий - по фен шую - это много документов..а как вы там это организуете, уже процесс ваш, внутренний.
по грамотному - это (7),
более просто, это завести регистр сведений, подписку на документ при записи, и анализируем табличную часть, пишем все изменения туда.
Вытаскиваем отчетом.
самое простое - это версионирование, но нужно понимать, что это администраторский инструмент, и красиво, печатной формой, или отчетом - особо не пооперируешь
(7) да вот я тоже думаю, что это правильнее, чем версионирование делать. Можно будет посмотреть любой промежуточный этап.
(9) ну вот и будет у меня документ отражать факт того, что кто-то что-то спроектировал. Там действительно придется аккуратно разрешения на редактирование отслеживать. Но зато все этапы будут наглядно существовать.
(6)Как вариант посмотреть какие есть подсистемы версионирования на ИС. Где то попадались разработки которые хранят историю во внешней SQL базе. Тем самым не увеличивают рабочую базу.
(12) спасибо, интересная штука, но совсем не нужная в рассматриваемом случае. Слишком глобально.
Я сделал цепочку документов, примерно как в (7), для рассмотрения изменений отчет.
(12) по журналу регистрации с версии 8.3...., короче скоро, ожидаются масштабные изменения на уровне платформы и написанная ранее для него функциональность станет только обузой.
мне еще нравится, как в последней УНФ-ке сделали подсистему, обсуждения. Изменение ключевых реквизитов в документах и справочниках, регистрируются с отдельном регистре сведений, в привязкой к объекту, еще и комментировать можно и обсуждать, что и для чего было сделано. Все на пользовательском уровне.
А полное версионирование, - это ресурсоемкое, да и больше для админов, чем для обычных пользователей занятие.