Всем привет.

Интересует такой вопрос. Стоит задача реализовать систему согласования заявки.
Процесс выглядит примерно вот так: https://image.prntscr.com/image/zv5Td82cTw6F7-nJO5hk-g.png (не совсем правильно конечно, с точки зрения моделирования, но суть отражает)

Скажите, можно ли реализовать это на платформе 1с, и не будет ли это "костылями"? Насколько знаю в стандартной УТ 8.3 есть что-то похожее.  

Также важно ведение версионности. Насколько знаю в 8.3 это тоже реализовано. Или просто поставить галочку "версионность" мало и необходимо будет делать доработки?

После УТ 8.3 не стоит

(0) УТ - она 11.4

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

Немного дополню... вопрос стоит в том, как лучше реализовать согласование документов, (и возможно правки во время согласование). При этом необходимо видеть историю изменений.
Еще один из вариантов реализации - использование СЭД, например alfresco. Но это, как мне кажется, еще больший костыль. Да и "лишняя" система не есть хорошо

(0) Можно,  и можно сложнее намного...
У меня сейчас вот такая схема работает
http://www.imageup.ru/img229/2986525/2018-02-09_16-44-57.png

(3) Во время согласования правки невозможны в принципе. Иначе первый согласующий согласует совершенно другой документ, чем последний.

+ причем данная схема отражается в самой 1С и видно графически на какой точке маршрута стоит задача

(6) допилено к какой-то стандартной конфигурации?

(7) Допилка в УПП

а что, бесшовная интеграция с документооборотом не модно?

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

(10) ну так вот работают бизнеспроцессы 1с...

(11) Да я не против, смотря для чего схема

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

(9) Он денег стоит.

(13) +100

(14) Сколько потратили на разработку БП из (4)? =)))

Хрен знает, ненавижу огромные схемы БП, их всегда можно упростить ИМХО

(10) схема специально в таком виде задумывалась и именно с просмотром в граф. виде на каком этапе процесс.
(16) за месяц не особо напрягаясь сам сделал

(18) ДО стоит меньше в любом случае. А как вы задумывали - да мне как-то все-равно, свое важное мнение высказал по этому поводу

(19) ДО еще настроить надо, а это отдельный бюджет )

Схема согласования служебки
http://www.imageup.ru/img229/2986576/slujhebka.png

Делай на бизнес-процессах 1С, самый сок

(21) вопрос возможно глупый... бизнесс-процессы 1С - это какие-то метаданные в новых платформах, или реализованы в каких-то конфигурациях (документооборот, например)?

(22) Метаданные. Наиболее полно реализованы в ДО (из типовых)

(21) +1

ДО от 1С в целом зло, но работает, однако...

(22) Это старые метаданные в старых и новых платформах. Если реализовывать самостоятельно - вообще огонь (и прокачиваешься, и глаз радуется, как это все работает на благо пользлователей) :)

(20) Отмена на этапе исполнения на предусмотрена?

(27) Нет.
Исполнитель может или заморозить исполнение указав причину или исполнить задачу, скажем со статусом исполнить не могу.
Автор служебки может или принять такой статус - задача исполнится и закроется или отклонить и тогда задача вернется в работу исполнителю.
Получается зацикливание до момента пока автор не утвердит результат исполнения задачи т.е. результат контролирует Автор.

(0) можно. делать лучше свой БП. нужен программист. есть еще системы, которые можно внедрить в вашу конфу и настроить ПРОИЗВОЛЬНЫЙ БП.

(9) в ДО ФИКСИРОВАННАЯ схема движения. чтобы под себя ее сделать скорее умрешь чем сделаешь. и еще и эта "типа бесшовная интеграция". интересно посмотреть на тех кто этим реально пользуется.

(29) +++
Я так и не понял как в 1С ДО сделать параллельное исполнение задачи и что бы задачу могли скажем исполнять несколько исполнителей одновременно...в итоге плюнул и сделал свои БП, понятные, обыгрываемые, минимум кода, минимум не нужной информации в базе...

(29) ну ими пользуются, но как минимум нужна версия ДО КОРП, иначе не имеет смысла. И да, в ДО КОРП разрабатывают _свои_ БП.

Причем, смешно, что смысл лепить _свои_ где-то сбоку, когда гораздо удобней их встраивать непосредственно в ту конфиг, в которой все работают оперативно. Хотя, какие-то преимущества у разделения комплексного решения на две или даже три базы может быть и есть.

(0) средствами платформы можно еще и не такое. А вот костыли это будут или нет, зависит от того, кто будет делать.

(28) >исполнить задачу, скажем со статусом исполнить не могу

Это по-нашему!

А еще такой вопрос. Можно ли на БП (или другими средствами) реализовать совместное заполнение табличной части документа. Т.е. один пользователь, например, заполняет номенклатуру и количество, а другой цены.

при этом доступ к редактированию "чужих" ячеек не имеет.

(34) Тому, кто вносит количество и номенклатуру запрети проводить документ. А проводит пусть тот, кто выставляет цены. Хотя подобный подход (раздельное заполнение документа) не рационально.

(35) непосредственно внутри документов разделение доступа по строчкам табличной части... мдя

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

(35) если не очевиден такой подход, задавай вопрос - дам пояснения

(30) Параллельное исполнение задачи несколькими исполнителями одновременно - настраивается в процессе, по очереди или совместно. Одновременная постановка задачи нескольким пользователям - используешь роль, заносишь туда необходимых пользователей, ставишь задачу на роль.

(34) Можно всё. Только параллельная работа в одном документе разных юзеров - невозможна.

(40) при Должной доле упоротости- возможна.

Например, 2 человека работают с принципиально разными аспектами документа. И ты выносишь на форму что-то, а хранишь это что-то не в документе, а... ну например в регистре(данные тч например), и внезапно оказывается, что можно изменять документ его не сохраняя... а следовательно не вызывая коллизий.


ЗЫ я понимаю, что сама идея дурно пахнет, но чисто теоретическая возможность есть... )

(30) Параллельные процессы вообще элементарно настраиваются мышом. Да и ролевую адресацию никто не отменял. Не понимаю в чем тут проблема вообще возникнуть может.

(39) Технически все верно. Практически если адресовать задачу нескольким исполнителям, то не выполнит ее никто, понадеявшись на товарища :) Я перестал такую херню делать очень давно - адресую задачу руководителю группы, а он уже назначает ее кому посчитает необходимым.

(43) Если всех дрючить за невыполнение - они между собой быстро разберутся, как работу организовать :)

(34) можно, но лучше так не делать. От таких решений голова болит через какое-то время.
Причем - на любой платформе. Решение потому, что очень плохое.

Бюрократия :)

Нужно согласовывать заказ на закупку. Пока придумали такой вариант:
например, в табличной части документа содержится чекбокс. Данный элемент доступен пользователям определенной роли. Если чек бокс поставлен, значит данная позиция является согласованной.

Или может быть можно реализовать это каким-то другим более удобным способом?

Это фиаско, братан

(0) А почему инженер и спецификация выделены отдельными блоками?

(0) Что вы там в версионировании (ибо это история изменения объекта) хотите увидеть?
Добавляйте, механизм примитивен, и его можно тупо слизать с любой конфигурации поддерживающую историю изменения объекта.

(47) Что такое "Чекбокс"? В вашем понимании, расшифруй... Забавно послушать :)

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

+ т.е. документ есть, но как шаблон, означающий начало работы :)

(49) не совсем понял вопрос. Если про БП, то спецификация - информация, предоставляемая в электронном виде, инженер - субъект, должностной исполнителя.

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

(52) Я так делал. Было полностью самопальное решение и там работало именно так. Взамен табличной части обрабатывались различные наборы записей регистра, а реквизиты документа нужны были для управления правами доступа, статусами и т.п.