Удобная реализация конечных автоматов в 1С8 #811624

По диагонали пролистал статью на Хабре (или ГТ?) про КА. Вижу, что они часто у нас встречаются. Вкратце, КА - набор состояний и  правил перехода между ними. Сейчас, видя что пользователю сложно нажимать пронумерованные кнопки последовательно, очередной раз понял, что в форме должно быть открыто только то, что по логике переходов допустимо, и надеяться на разумность пользователя или мануалы - непрофессионально. Есть готовые и простые в использовании, документировании, доработке способы реализации КА в формах документов?

в терминах 1с: работа от процессов, а не от документов

собственно под это дело и нужен объект Бизнесс-Процесс

Да, это хороший вариант. Но при развитии существующего решения уже есть документ с 5, к примеру, состояниями. Его тоже удобно изменять через новый БП?

БП это удобный способ упорядочить по времени операции _различных_ исполнителей. Нефиг его тащить куда попало.

но в 1с у большинства документов нет никаких "состояний". Просто: есть документ или его нет

А в чем вопрос, собственно? Прятать элементы в зависимости от состояния?

Полно их, в той же ЕРП. И это нифига не хорошо, имхо.

и за это многие критикуют ерп

Заполнена некоторых ТЧ, проведение, наличие подчинённых. Прятать элементы формы, разрешать изменение/проведение.

корректное заполнение и проведение документа - это единый процесс. делить его на состояния- глупо

Я не могу так категорично утверждать. Пример перед глазами (ОЕМ выпуск) - ТЧ с данными о выпуске уже известна, расчётный курс документа будет через пару дней, часть отчётов уже надо делать.

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

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

Непосредственно решаемая задача - отчёт по ОЕМ выпуску, но необходимость в гибком решении встречалась десятки раз. Я тебе не говорил, что тебя надо поймать, напоить, слушать и записывать на цитаты? Ну так говорю :) В Сорочаны/Волен/etc не собираешься? Я на машине буду, напиши за день.

я вот вообще жалею, что задачи в БП не могут делать движения

Это легко обходится

на эти выходные уже меня зарезервировали на работы. Но если на след.выходные и заранее утрясти - то я всегда за.В будни кстати вечером весьма норм. Прикатить на горку часов в 21, час полтора отказаться и назад - товарищ меня так регулярно подхватывал...

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

и правильно .. И... Неправильно...Документы не должны быть зависимы от того кто их вводит...Значит документы или процесс их ввода должны быть существенно формализованы... Это позволит сделать процесс ввода чисто техническим (технологическим?) процессом... Но это будет негибко.? Ибо быстро и адекватно менять процессы может только квалифицированный персонал (бизнес-аналитик?) и получается засада...Стремясь сделать процессы независимыми от альтернатив исполнителей мы эти процессы тем самым костеним....

Что за пронумерованные кнопки? Применительно к сферическому коню в вакууме нет такого. Во-вторых, формализация хоз. процессов под КА это путь к сжиранию своего мозга. В некотором роде какие-то приёмчики есть типа контроль отрицательных остатков по всяким регистрам, проверка статусов и проч.

пронумерованных кнопки - это запросто. Даже сейчас если включу комп такой скриншот среди своих обработок есть.Если это не делать - то надо делать мастера по вводу, где на одномэкоаге не больше одного поля и одной кнопки "дальше". Если этого не делать придётся делать кучу ТУПЫХ защит от дурака. Потому чтоипользюкт просто тупые по жизни. Не в том смысле что глупые или дураки тупые, а просто тупые потому что им лень думать и хотя бы просто напрячь мозг. Что сначала надо выбрать файл для загрузки, потом выбрать схему загрузки т потом нажать загрузить...

что за статья?

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

да и просто, ну представяьте себе, что будет, если в задаче будет обработка проведения: вариант 1 - в этой процедуре невдолбически рогатый код, который проверяет, надо ли делать движения и какие именно и вызывает соответствующую фнукцию, передавая ей хрен знает что (для этого будет еще один рогатый говнометод на полтора олимпиада строк). Это, если объект метаданных Задача в системе один или их немного. Кому-то надо объяснять, чем это плохо? вариант 2 - в системе будет объекты метаданных ЗадачаПроцессаОприходованияТоваров ЗвдачаПРоцессаТамЕщеКакойТоУзкозаточеннойХерни ЗвдачаПРоцессаТамЕщеКакойТоДругойУзкозаточеннойХерни в итоге мы приходим к тому, что в конфе объектов метаданных типа Задача будет столько, сколько учетных документов. Кому не очевидно, что это ни чем не лучше варианта 1?.. Дичь, короче, будет дичайшая

КА много где бывают нужны, не только в формах. Я бы тоже не отказался от хорошей нативной (не ВК) библиотечки. На ИС я не копался, может там есть что-то достойное?

Имхо, для КА делоне в библиотечках и прочем. Это не алгоритм, а способ организации архитектуры твоего кода. Когда понимаешь и спроектируешь схематично сами состояния и правила перехода между ними - написать реализацию никакого труда не составит, алгоритмически КА элементарны и просты.

Написать труда не составит, но потом дорабатывать такой код и поддерживать его в читабельном виде будет тяжело. Это как сравнить КД и ручной перенос данных через Excel.

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

Даже самый простой пример который регулярно всплывает на мистер , типаПерсонал постоянно создаёт дубли при заведении контрагентов - с одинаковыми инн и прочее.Ну просто люди так устроены. Им лень думать. Им проще хреняк и в продакшен.. На сейчас он свою задачу выполнил + клиента ввёл.А потом начинается свистопляска - то акт не те цифры бо не тот экземпляр клиента выбрали, то у клиента исчез договор и меня подымают в 9 утра - по ому что нужный договор есть но в другом экземпляре клиента итд.В результате запилил жёсткая. Ситуация нормализовалась. Почти...

Пример плохого дизайна и данных и UI, имхо. Пример плохо выстроенных процессов имхо. Пусть манагер вначеле вводит как угодно, если ему так удобнее. Но без правильного ИНН и других обязательных реквизитов ни одна поставка не пройдет и бонус ему соответственно не упадет. А дубля ИНН система не примет ни за что. А если для разгребания его ошибок пришлось напрячь программиста — соответственно штраф в размере стоимости времени программиста.

в сабже правильная мысль - сделать так, чтобы на форме не было у пользователя возможности сделать то, чего нельзя, просто, чтобы неположенное не отображалось. Только для этого не конченые автоматы городить надо, а функциональные опции использовать. Отдавать такие контроли в руки пользователям нельзя, надо, чтобы система это контролировала - тут все верно. омерзительно. Это происходит потому, что права на изменение нормативно-справочной информации раздали всем подряд. Нельзя так просто делать и всё. НСИ должны править, создавать, удалять люди, которые понимают, что делают, и за свои действия. Процесс не организован, орагнизатору надо оторвать яйцо или хотя бы скрученой газетой по носу навернуть и сказать "фу".

хотя нет, про функциональные опции чушь, ибо они system-wide.

как только мне начнут платить отдельно за UI и дизайн - так сразу будет хорошо А пока юзаем то, что лал производитель решения.Пример условный.

нси - да, согласен! Только проблема в том, что в нси  куча инфы которая важна для бухпроцессов, куча которая важна для торговых процессов и куча для условно складских процессов. В самом худшем случае - это все в одном обьекте

Вопрос: кто должен вводить ВСЮ НСИ? А особенно когда один и тот же реквизит условно говоря относится к разным контурам ответственности. Да, вы тут начнете меня шпынять что бизнес процессы не устаканены, персонал не обучен итд. Да, все так, но "мне" от этого не легче. Если все делать правильно - то все будет правильно. Но не я определяют как и что делается. В итоге приходим к необходимости работы по бизнес-процессам. Пусть сначала по грубым и не сильно адекватным - будем подстраивать по ходу. Если смотреть дальше - то работать надо с использованием мастеров. Но это замедляет. Но гарантирует. С повышением квалификации и ответственности персонала - можно перейти от мастеров к документам. Но квалифицированный персонал ушёл/потерялся - получаем жпс.

Сами посмотрите - куча вопросов что считает что-то неправильно - потому что что-то или гезаполнено или заполнено неправильно. Вопрос: как не допустить такого?

вы в своей деятельности видели много организаторов которым платят именно за организацию?

Я в своей конторе и не в одной в основном только тем и занимался что ставил процессы и меня били по рукам когда я выходил на уровень управления

справедливое замечание

в итоге пробился лбом об бетонную стену и послал все на.Теперь вместо того, чтобы сделать хорошо на все время - желаю хорошо когда возникает постоянно плохо. Сейчас плохо - сделаю будет сейчас хорошо. Ой, опять плохо? Нивапрос - сделать хорошо

И? Процесс идёт - денежки капают!

Все плохомутно когда "ну как нибудь так..." я, блин, военный. Могу копать, могу не копать. Копать плохо кактотне получается ... Когда плохо копать - получается плохо ;-)

Чет понесло меня

Вся проблема в том что сделать хорошо сразу - требует большого объёма предварительных работ... Поэтому получается как-нибудь так...

А это бяка

И так - много где

горшочек, не вари :)