Comments 31
В такой широкоиспользуемой системе, как 1С сложно говорить о бесполезности. То что вы перечислили, это скорее редкоиспользуемые вещи. Речь не о том, что это легаси, которое просто нельзя выпилить. Вполне возможно, что тот 0.X% пользователей бизнес-процессов, построили на них всё у себя, имеют штат специалистов, которые постоянно смотрят на схемы и адаптируют их под изменяющиеся обстоятельства. Т.е. для них это реально полезные вещи
В свое время я БитФинанс настраивал и у нас вполне использовались бизнеспроцессы в согласовании документов и двольно обширные и развесистые, очень сильно жизнь облегчали в плане донастроек процессов
В БИТ:ФИНАНС не использовались бизнес-процессы. У них реализован отдельный собственный механизм, который позволяет настраивать "довольно обширные и развесистые" маршруты. А вот на типовых бизнес-процессах такое не реализуешь, точнее реализуешь, но для каждого изменения необходимо будет менять конфигурацию.
Про блок-схемы - в некоторых случаях это удобно, например настроить потоки работ (воркфлоу) или какие-то чисто бесчеловечные цепочки действий, например, ночная обработка потока заданий с ветвлением, ожиданиями и пр. В общем, то, что не нужно лично вам, не значит, что не нужно никому. А вот когда оно понадобится, а его не будет - вот тогда будет настоящая проблема.
Давайте вместе попробуем описать реальную задачу, где без бизнес-процессов никак не обойтись
Можно обойтись даже без 1С и даже без электричества. Но я однажды делал конфигуратор ночных заданий на похожем инструменте (в другой системе) - очень удобно из кубиков и стрелочек и логических операторов набираешь что должно сделаться ночью (передача данных, обработка, расчёты, отчёты, что делать если данные не передались успешно и т.д.). Утром приходишь - всё готово. Или цепочку утверждения какого-то документа или действия - тоже удобно нарисовать и поддерживать в таком виде.
Бизнес-процессы упрощают разработку логики переходов и уменьшают количество кода на описание этих переходов. Самый простой пример использования бизнес-процессов - согласование документов по сложным маршрутам.
Вроде в 1с:Документооборот бизнес-процессы широко используются.
ВЫБРАТЬ валюта, курс, дата
ИЗ РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ дата В (ВЫБРАТЬ МАКСИМУМ(дата) ИЗ КурсыВалют КАК Т ГДЕ Т.Валюта = КурсыВалют.Валюта)
Запрос, приведенный для замены среза последних ошибочен. Он может выдать две строки. Конечно мы можем надеяться, что никто не будет писать две записи на одну и ту же дату, но что если нужна последняя продажная цена? Приведенное решение плохое.
Штатный срез последних тоже может выдать две(и более) строки
Данный запрос синтаксически не верен. В периодических регистрах сведений измерение называется Период, а не Дата. Во вложенной выборке используется несуществующая ВТ КурсыВалют. Там тоже должно быть написано "ИЗ РегистрСведений.КурсыВалют "
Запрос в статье ошибочен. Если есть 2 валюты, и последние курсы находятся в разных датах, ваш запрос вернёт только одну валюту, а срез последних две.
Бизнес-процессы "не летят" по двум причинам:
1) их нельзя менять вне конфигуратора;
2) они методически противоречат принципу "обратимости" операций.
Поэтому, область их применения таким образом сужена, и чаще всего то же самое может быть реализовано более традиционными методами. Но нельзя сказать, что они не используются вообще. Например, процедуры закрытия месяца сделаны на БП.
Но в платформе есть и другие "нелетящие" вещи: географическая схема, анализ данных (вы знали, что в платформе почти с рождения целый движок для этого "из коробки"?)
Кстати, да. Про анализ данных я забыл. Он там действительно почти с рождения. И почти с рождения не обновляется. На сегодня, когда у нас есть scikit-learn, он, конечно, выглядит бесполезнее, чем бизнес-процессы
Причина одна и та же: их воткнули в платформу под "конкретных" заказчиков "чтоб было" и забиыли. В типовых оно не используется, следовательно, никто толком не понимает, как оно работает и какие задачи решает.
Интересная история. Вы знаете под кого именно "втыкали" анализ данных?
Достоверно не знаю. Но вы много можете назвать российских компаний, которым в первой половине 00х могла потребоваться такая функциональность? И кто из них был в то время подопытным "флагманских внедрений"?
И то, что эта богатая функциональность не используется в типовых, позволяет сделать вывод, что добавлена она была под конкретный проект.
1) их нельзя менять вне конфигуратора;
Вообще-то можно. В конфигурации 1С Документооборот есть Комплексный БП - он настраивается в режиме 1С Предприятие 8. Возможности, конечно несколько ограниченные (по алгоритмической части, но это во всей платформе так). Но это всё, конечно, заслуги движка уже реализованного в самой конфигурации 1С Документооборот. Безусловно, более широкие возможности БП в рамках платформы были бы хороши Но это плака о двух концах - встроенные реализации внутри платформы менять нельзя, а вот что сделано в рамках конфигурации - можно. Но это уже проблема отсутствия модульности в платформе 1С Предприятие 8 - а то можно было бы вынести весь блок работы с БП в отдельный модуль и применять где понадобится, оставив платформе только самый базовый уровень отображения и исполнения, по сути практически столько сколько есть сейчас (хотя то что есть сейчас давно уже выглядит устаревшим и нуждается в некотором апгрейде)
2) они методически противоречат принципу "обратимости" операций.
Не понял, что Вы имели в виду - могли бы пояснить? Вообще есть в 1С Документооборот такой БП как Согласование - он цикличный - там можно проводить повторное согласование, в рамках одного БП, сколько потребуется - т.е. движения назад тут вполне возможны. Но да - там это все делается опять же на уровне движка внутри конфигурации 1С Документооборот. Прямой подход этого не позволяет. Но напрямую БП никто и не использует
1) " заслуги движка уже реализованного в самой конфигурации 1С Документооборот " - вот именно. Как очередной образец борьбы разработчиков типовых с "фатальными недостатками" платформы. Называется "выкинем всё и напишем своё". В этом случае от "платформенной" функциональности БП осталость чуть меньше ничего.
2) Под "принципом обратимости" я подразумеваю возможность "откатить" любую операцию, она же "отмена проведения". При которой логика документа должна по возможности вернуть состояние "как было". С другой стороны, исполнение БП не подразумевает "отмену" идеологически (отмена БП - это другой БП!). Поэтому, вся логика БП когнитивно "плывёт" по отношению к остальной системе (например, при установке пометки удаления на БП следует ли "откатить" всё, что этот БП понаделал?)
Называется "выкинем всё и напишем своё" -
Как и написал выше - что лучше минимальный уровень внутри платформы и широкие возможности по расширению функционала в конфигурации или широкий функционал ограниченны к расширению. Понятно, что мог бы быть и гибридный вариант, но почему-то в его развитие вкладываться не стали.
При которой логика документа должна по возможности вернуть состояние "как было"
Это было бы круто, но не знаю где было бы такое вообще реализовано.
Ну а про БП написал - там состояния можно перемешивать достаточно произвольно (но только с программной обработкой).
следует ли "откатить" всё, что этот БП понаделал
Теоретически может быть бы и стоило, но это слишком сложно. И такие задачи перед БП не ставятся
Полностью согласен про регистры расчёта - это уже вторая (если я не ошибаюсь) попытка реализовать что-то дельное для расчётов (первая была журналы расчёта - и помню на 7-ке их использовали не только для расчёта зарплаты, а например для ЖКХ - но это антиутопия).
Но с таким же азартом можно сказать, что и регстры Бухгалтерии слишком специфичны и применяются только для различных видов бух учета. Если ранее в системы могло быть несколько Бух регистров, то сейчас уже тенденция к сведению к одному - с перегрузкой этого регистра (т.к. его базовая архитектура не предназначена к такому увеличению нагрузки).
Но проблема разных типов регистров скорее не в том что их возможности не нужны - а в том как неудачно продумана изначально архитектура виртуальных таблиц - для регистров расчёта особенно неудачно - тут вообще чаще идёт работа условно физической таблицей). Думаю для решения всех задач накопления достаточно было бы одного регистра (накопления) + некий общий механизм настройки таблиц итогов + более частные конфигурации этих таблиц уже под каждое конкретное применение. То есть больше универсальности и больше свободы. Но изначально (да и сейчас - хоть это уже издёвка) компания 1С (и братья Нуралиевы в частности) проектировали систему исходя из упрощения её применения (в т.ч. программистами, коих тогда активно называли конфигураторами) - жёстко направляя решения определённых задач в определённое русло без кучи опций и нетривиального выбора вариантов настроек.
Вот над чем ещё стоило подумать - это над операциями отражения изменений в этих регистрах.
Сейчас это просто набор записей, где (в частности для регистра накопления) есть доп. поле с направлением движения - влияющего на авторасчёт итогов и виртуальные таблицы.
Но, на мой взгляд, правильнее было бы сосредоточиться на более конкретном выделении операций над регистрами (с вынесением их в отдельные объекты), как:
Изменение величины на заданную
Прибавление к величине
Убавление от величины
Включение/Отключение величины
Удаление величины (удаление мне не очень нравится, но и зануление тоже не совсем корректно - я бы сказал обNULLение величины)
И вот этими операциями и регулировал бы остальную разницу между регистрами (в т.ч. и для регистров сведений).
Тут же можно было бы сделать и периодическое действие операций - гарантирующих обратное возвращение "предшествующего" результата (только относительно данной операции, но не относительно других).
Третьим правильным нововведением (относительно 7-ки, ну или теперь уже на будущее - относительно 1С Предприятие 8) могли бы пользовательские виртуальные таблицы (в т.ч. переопределяемые стандартные) как привязанные к регистрам (хотя не обязательно только к регистрам), так и глобальные (работающие со всей конфигурацией) - эдакие аналоги не то View не то Хранимых процедур. Это могли бы быть достаточно гибко настраиваемые источники данных (а-ла как компоновка данных, хотя бы на уровне для Динамических списков), которые далее можно было бы произвольно использовать как источники данных (в т.ч. в произвольных запросах). Сами же виртуальные таблицы могли бы иметь и возможность программной обработки - тогда при обращении к ним внутри запросов данные могли автоматически выгружаться на сервер приложения, обрабатываться и обратно загружаться в во временную таблицу - это, конечно, не эффективный вариант, но допустимый для ряда случаев - в большинстве случаев должен строиться запрос для СУБД из специального ЯП запросов на диалекте СКД).
Такие пользовательские виртуальные таблицы могли бы быть очень полезны для многих сфер применения. Из них как из кирпичиков можно было бы складывать сложные выборки данных. Причём структуру виртуальных таблиц можно было бы динамически подстраивать (по заданным параметрам вызова) - меняя стратегию выборки или динамически строят запрос.
Ну а сами данные так же могли бы кэшироваться. Не только на время сеанса, но сохраняться в СУБД или на сервере Дата акселератора для общего использования.
Ну и про гибкую настройку индексов всё-таки забывать не стоит - хотя их уж, вроде бы обещали сделать.
И, вот странно, почему автор не назвал никчёмными Планы видов характеристик - вот что что - а это явный архитектурный косяк. И их аналог в лице "Определяемых типов" выглядит куда полезнее. Хранение вида типа как значения можно было бы на справочниках/регистрах организовать. Тоже касается и Планов видов расчёта и Планов счетов.
Неудачная реализация и Перечислений - они лишние когда есть куда более продвинутые в использовании справочники с предопределёнными элюентами (и развивать нужно было именно их).
Но Перечисления могли бы быть тоже полезны - как элементы форм и (общих) модулей т.е. внутри текста алгоритмов - вот где их действительно не хватает (ну и параметрах сеанса и хранилищах данных).
Но вернусь к ПВХ - как реализации Видов субконто - сами Субконто чутка хорошая, но на фоне появившихся измерений в Бух регистрах не такая уж уже полезная - и их архитектурная реализация желает лучшего. Это тупиковая ветвь. Вот идея расширенной аналитики - другое дело - и в платформе правильно было бы встраивать более глубокую поддержку именно такого подхода - когда аналитика регистра (а может и справочника/документа) становится квазидинамической - и легко меняется от записи к записи в рамках "одной" виртуальной таблицы.
А что насчёт Журналов документов - если в 7-ке они вполне были востребованы, то в 8-ке с каждой подредакцией платформы теряли свою востребованность. В итоге они сейчас уже неиспользуютс в ТАКСИ (есть же динамические списки) - очень неудачно реализованный вид объекта.
Аналогично - Последовательности документов - изначально были очень даже востребованы но..... в очень не эффективными и утратили свою актуальность.
Как и Константы - когда в 8-ке они перестали быть периодическими, а появились регистры сведений Константы постепенно почти сошли на нет. Особенно по началу, когда они были в все в одной таблице, то создавали ещё и кучу проблем с параллельным доступом на изменение.
Что до Бизнес-процессов - по мне так штука весьма интересная просто не развиваемая никак - сделали для галочки и забили - хотя из них вполне себе мог вырасти целый декларативный сценарий проектирования сложных схем взаимодействий. Но в нынешнем виде где даже сравнение/объединение этих схем БП выполнить эффективно нельзя - это тупик. Хотя для 1С Документооборота Бизнес-процессы очень даже хороши - и ничто не мешало бы так же строить процессы в других комплексных конфигурациях. Но тут нужно больше гибкости и интеграции. Ну и, безусловно, больше продвижения самой идеи. Текущая же модель даже в 1С Бухгалтерии практически полностью отдана на откуп конфигурации - т.е. сама платформа там почти ничего не делает - только схемки рисует - вся обработка чисто реализована в алгоритмах конфигурации, что говорит о том, что БП не прошли проверку эксплуатацией в первоначальной архитектурной задумке, а на их развитие в компании 1С "болт забили" - что печально. Я бы наоборот активнее встраивал бы БП во все конфигурации, а саму подсистему документарного взаимодействия и постановки задач прямо в платформу - чтобы это было всегда под ругой как стандартный API!
Но, на мой взгляд, правильнее было бы сосредоточиться на более конкретном выделении операций над регистрами (с вынесением их в отдельные объекты)
Может пояснить этот момент в терминах физических таблиц SQL? Вместо одной таблицы для регистра использовать несколько?
Журналы вытеснились регистрами сведений с составным измерением типов входящих документов. Вместо графов журнала гибче настроить ресурсы регистра через подписки событий документов.
Вообще регистры сведений настолько удачное решение, что в типовых они уже в какой-то мере заменяют итоговые таблицы регистров накопления.
В итоге вижу три вида таблиц:
Сущности (справочники, документы, ПВХ и проч)
Табличные части сущностей (а почему бы не сделать табличные части табличных частей?)
Регистры сведений - всё что вне сущностей, от регистров накоплений до регистрации планов обменов
Вы правы. Про "возможную" эволюцию регистров пишу отдельную статью (своё виденье развития) - там всё не так просто, как кажется на первый взгляд (там много низкоуровневых нюансов, в т.ч. диктуемых общим желанием развития платформы; так и управляющих фич развития структуры метаданных).
Мысль "Не разделять Справочники и Документы" у меня тоже давно витала в голове - но пока думаю, что эффективнее их разделить - тут всё-таки логически разное использование:
Справочник - это обычно классификатор (в общем смысле), некая аналитика или некое хранилище.
Документ - это почти в 99% случаев некий процесс (начинающийся или завершающийся; в т.ч. как часть этапа вышестоящего процесса; причём почти всегда это именно хронологический процесс) - тут Документы куда ближе к Бизнес-процессам, чем к Справочникам.
Но вот в 1С Документообороте Документов как раз с гулькин нос - почти не используются - а весь документооборот строится как раз на Справочниках и БП. И это оправдано, несмотря на наличие у большинства документов хронологической привязки. Документы в 1С Документообороте - это скорее для интеграции с разными БСП и другими конфигурациями, а так же для ряда процессов (присущих другим конфигурациям) - чтобы не выбиваться из общей канвы - быть привычными и не замусоривать БП операциями (тут БП имеют очень чёткое узкое применение - все являются разновидностями обобщённого "Поручения").
По сути эмулировать Документ на Справочнике не так уж сложно... если бы Справочники могли быть регистраторами в регистрах - а они это, увы, технически не могут. Это не то чтобы очень сильное техническое ограничение, но с точки зрения оптимизации процессов а имеющейся архитектуре 1С Предприятие 8 - это очень существенное ограничение - с периодическими регистрами (я не только про регистры сведений, все остальные регистры априори периодические) эффективно работать с привязкой по регистратору - но это только в рамках нынешней архитектуры. Впрочем эту идею я считаю верной и вообще исключил бы работу с регистрами без привязки к регистратору!
Ещё у Документов есть Последовательности - идея была интересная, но на корню как-то загубленная - и хорошо эмулируется через регистры сведений.
Ещё у Документов есть Нумераторы - тоже хорошая идея, но опять же плохо развитая и в итоге, в 1С Документообороте сведённая к полностью мануальный реализации нумераторов (там через справочники и регистры сведений сделано).
Ну и Документы могли отражаться в Журналах документов - что уже не актуально (о опять же легко эмулируется от Динамического списка до просто Регистра сведений). Хотя у Журналов могла бы быть ещё одна интересная функция (как, кстати о ещё одном, уже более обобщённом, и кстати, тут (в статье) совершенно забытом, как, впрочем и большинством программистов 1С, объекте - "Критерий отбора") - это унифицированная группировка разных ссылочных сущностей с отбором по какой-то заданной аналитике. Но да и тут Регистры сведений выходят более эффективными - тут преимущества у отдельных сущностей метаданных скорее в более гибкой автоматической интеграции в интерфейс пользователя (вот бы ещё индексы произвольно настраивать - но тут вроде бы официально обещали в будущих релизах платформы 1С Предприятие 8 - может дадут в ближайшие годы).
А вот чего нет в документах - это делать подчинённые элементы справочников - вот тут реально не хватает! Хотя формально подчинённые документы есть - механизм ввод на основании (хоть это не совсем тот, и тут нет некоторой встроенной автоматизации для подчинённых справочников).
Тем самым кроме логического вынесения Документов в отдельный список и возможности только через них двигать подчинённые регистратору регистры (а это почти все) - в общем ничего особенного в Документах нет.
Если дать возможность двигать регистры более общей сущности метаданных - пусть это будет тот же Справочник, готовый впитать в себя остальные ссылочные сущности. Интерфейсную интеграцию больше сосредоточить на Командах, Маршрутах, Представлениях (и/или более общих кастомных Виртуальных таблицах - они же Общие запросы (СКД) с параметрами и секцией инициализации, и постобработки) и Динамических списках.
А так же реализовать в конфигурации поддержку шаблонного заполнения - когда можно создавать новый объект метаданных с привязкой к шаблону (и как бы наследованием его преднастроенной структуры и кода, в идеале - если после создания связь сохраняется - при изменении шаблона можно было бы полуавтоматизировано сделать мердж и апдейт связанных с ним объектов метаданных) - чтобы логически разные бизнес сущности можно было просто легко создавать с разных базовых шаблонов (где уже будут настроены все тонкости - коих при унификации многих сущностей в одну соберётся очень много и эта базовая настройка будет уже не такой уж тривиальной как сейчас).
И, совсем уж в идеале, добавить поддержу ООП (т.е. наследование сущностей, хотя шаблонного создания тоже вполне будет достаточно) - но, хотя бы, в части поддержки Интерфейсов - было бы очень здорово - что дало бы больше возможностей унификации API и разных форм его представления для тех или иных задач - тогда за Интерфейсами ООП можно было бы скрывать любую исходную сущность - гибко представляя её в контексте нужным видом API; или эффективно фильтруя элементы коллекций (в т.ч. запросами) по реализации того или иного Интерфейса (а не по конкретным типам) - что тоже очень эффективно. То это очень сильно бы развязало руки в свободе проектирования архитектуры конфигураций, программного кода, их расширения и интеграции подсистем друг с другом и с другими конфигурациями (ИБ и внешними системами).
Но всё это отдельная тема. Я сейчас пишу статью про обобщение регистров. Потом мне хотелось бы написать и статью про обобщение ссылочных объектов в гипотетической будущей учётный платформе (может которую потом и удастся создать совместными усилиями заинтересованных лиц - общая архитектура у меня же давно сложилась в голове и отчасти на бумаге - идея у меня очень мощная и, надеюсь, очень современная - покруче чем SAP Business Suite и Microsoft Dynamics, и уже тем более чем 1С Предприятие 8 - и скорее всего даже чем возможная будущая 1С Предприятие 9).
Есть ещё один нюанс - это интерфейсные Формы объектов - тут тоже есть много узких мест даже с переходом на Управляемые формы. Тут в корне нужно менять подход - переходя на гибкую интерфейсную сборку - это тоже тем для отдельной статьи! Может в будущем (базис уже есть на бумаге), если тема будет интересна читателям
табличные части табличных частей?
Про это скажу так - технически на реляционных СУБД это возможно только через эмуляцию - и такое в конфигурациях 1С есть. Но реально высокой востребованности в этом нет. Хотя есть потребность в связях между элементами таблиц - но это всё сейчас делается программно в тех не особо частых случаях, когда это нужно. Хотя "форин" ключи были бы, наверное, интересным нововведением.
Но правильнее было бы сделать структурированные реквизиты (реквизиты, внутри наборы других реквизиты), с поддержкой механизма свойств (с обработчиками получения, установки, а так же некоторыми другими), сделать "не сохраняемые" напрямую в ИБ реквизиты (с персональными обработчиками чтения и записи, в идеале так же доступные не только в объектной модели но в запросах - там обработчики доступа нужно прописывать особым образом на ЯП, доступно в запросах). Ну и до кучи, если уж так хочется - можно делать подчинённые справочники (которые могут содержать и ТЧ) и назначать их как типы реквизитов, с пометкой в реквизите - что объект справочника является частью основного объекта и в объектной модели реквизит должен быть представлен не ссылкой, а целым объектом - естественно только в серверном контексте, хотя ещё в формах, думаю привязки можно было бы настроить). Хотя эта идея мне не очень нравится. Это уже перегруз.
Аналогично можно было бы привязать реквизит к регистру сведений, особенно к ресурсу периодического регистра (а Период к другому реквизиту) - и иметь как-бы периодический реквизиты как было в 1С 7.7 - вот этого порой очень не хватает! Когда обычные реквизиты объекта нужно переделать в хронологические не перекрывая весь API их использования!
В принципе об этом можно было бы подробнее поговорить в статье про унификацию ссылочных объектов (отталкиваясь от архитектуры 1С Предприятия 8) когда до этой статьи у меня руки дойдут :-)
Бесполезные вещи в 1С