Восьмая версия платформы 1С существует уже более 20 лет. Это если считать от момента выпуска т.н. ознакомительной версии, которую обычно называют бетой. Сейчас в ней более 10 миллионов строк кода. И много, много всего. Но, как говорится, не все одинаково полезно. Нет ничего удивительного в том, что в таком большом хозяйстве какие-то концепции, объекты, функции оказались удачными и востребованными, а какие-то не очень. Разумеется, это всегда субъективно. Кому-то непонятно, зачем "в бухгалтерии" нужны тригонометрические функции, а кто-то жить без них не может. Кто-то страдал без паузы, пока ее наконец не сделали и т.д. Мой личный список бесполезных вещей в 1С такой же субъективный.
Я выбрал три наиболее бесполезных на мой взгляд предмета из того, что есть в платформе 1С. Важное замечание. Бесполезность предмета не означает, что его можно игнорировать во всех случаях. Если бесполезное встречается вам в типовой конфигурации, и вам надо решить проблему с его участием, то деваться некуда. Но если вы проектируете какое-то свое решение, тогда имеет смысл помнить о том, что принесет вам пользу, а что нет.
Бизнес-процессы
В 1С есть достаточно стройная концепция моделирования бизнеса, или, как любят выражаться в 1С, хозяйственной деятельности. Документы отражаются в регистрах, регистры служат источником данных для любого анализа в широком смысле (в узком смысле это называется отчетами). Справочники помогают структурировать информацию как в документах, так и в регистрах.
Бизнес-процессы прилетели в 1С откуда-то сбоку. Если опустить несущественные детали, идея такая. Рисуем... блок-схему.
Для элементов блок-схемы пишем код обработчиков событий и можно запускать процессы! Всякий запущенный процесс будет продвигаться по блок-схеме, а мы сможем на это смотреть.
Возможно, что для того, кто это придумал, идея совместить блок-схемы и бизнес казалась многообещающей. Но, довольно быстро выяснилось, что смотреть на эти красивые картинки некому. Программиста не волнует бизнес. А бизнесмена не волнуют блок-схемы.
Можно конечно и не смотреть. На сайте 1С так прямо и говорят:
...
В этом случае пользователи смогут работать привычным образом, не пользуясь списком заданий и не подозревая о существовании бизнес-процессов. Однако выполняемые ими операции будут приводить к продвижению соответствующих бизнес-процессов дальше по маршруту.
Но если пользователи не подозревают о бизнес-процессах, то разработчику они зачем? Процессы прекрасно можно моделировать на документах или, как вариант, на справочниках. При этом, бизнес логику можно упаковать в хорошо сделанный код, а не растаскивать ее по обработчикам событий.
На сегодняшний день бизнес-процессы все еще встречаются в типовых конфигурациях, но в ограниченных масштабах. А, например, в типовой бухгалтерии бизнес-процессы и вовсе выродились вот в это
Регистры расчета
Вообще, в 1С есть три вида регистров: регистр накопления, регистр бухгалтерии и регистр расчета. Добавлять ли к ним регистр сведений или нет, вопрос спорный, но мы не будем его сейчас обсуждать.
Можно сказать, что регистр бухгалтерии это дань традиции. Регистр накопления это удачное упрощение бухгалтерского регистра. А вот регистр расчета это попытка изобрести еще чего-то, чтобы было.
Как нетрудно догадаться, регистр расчета появился для того, чтобы считать зарплату. На заре компьютеризации расчетчики зарплаты любили рассказывать какая у них сложная работа. Только все рассчитал, а тут кто-то несет больничный лист. И теперь надо по этому человеку все пересчитывать. Внимательно смотреть на дни. Потому что если человек болел, значит он не работал.
Эта нехитрая мысль и легла в основу регистра расчета. Делаешь записи в регистр, и при этом одна запись может вытеснить другую. Дело в том, что одного этого не достаточно для такого фундаментального понятия, как регистр. Во-первых, это слишком узко, нигде, кроме расчета зарплаты не используется. Во-вторых, и это пожалуй главное, все то же самое можно сделать и без специального регистра. При этом результат будет прозрачнее.
У регистра расчета есть еще одна способность. Это расчет базы. Если вы платите премию процентом, то надо сначала посчитать от чего этот процент взять. Но даже эти две способности в сумме не тянут на отдельный регистр. Он живет почти исключительно в очень специфической типовой конфигурации под названием Зарплата и управление персоналом. Если кто-то проектирует свое решение, он скорее всего этим регистром пользоваться не будет. Лично я наблюдал зарождение и развитие идеи этого регистра еще с версии, которая была до седьмой. И именно потому, что я хорошо представляю себе что это такое, у меня и в мыслях не было использовать это в тех случаях, когда надо было реализовать расчет достаточно сложной зарплаты.
Срез последних
Получить последние по времени значения чего-либо это достаточно часто встречающаяся задача. В 1С можно создать специальный регистр сведений называемый периодическим. И этот регистр сможет выдавать последние записи (а также и первые, но этим никто не пользуется). Для начинающих специалистов выглядит, как магия. Но в основе этого лежит достаточно простой запрос. Например, у нас в регистре курсов валют есть дата, валюта и курс. Запрос на получение последних курсов выглядит так:
ВЫБРАТЬ валюта, курс, дата
ИЗ РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ дата В (ВЫБРАТЬ МАКСИМУМ(дата) ИЗ КурсыВалют КАК Т ГДЕ Т.Валюта = КурсыВалют.Валюта)Есть и чуть более громоздкий вариант этого запроса. Его можно использовать, если коррелированный подзапрос вызывает проблемы с производительностью.
Как бы там ни было, вы всегда можете получить список последних значений, используя простой или чуть более сложный запрос. И лучше использовать запрос, чем обращаться к срезу последних регистра сведений. Например, нам надо получить список последних документов по клиентам. Что делать? Создавать под это регистр сведений? Но это будет дополнительная сущность. Более того. Если нам нужен еще и список последних документов по товарам, а также список последних документов по связке товар+клиент, тогда надо будет создать три регистра сведений! Не один, с измерениями товар и клиент. Такой регистр будет работать только на связку товар+клиент, а по отдельности работать не будет. Это не оборотный регистр, где такое возможно.
Подход с использованием запроса более универсален. Есть только одно исключение. С некоторых пор периодический регистр сведений обзавелся опциональной служебной таблицей последних значений. В тех случаях, когда надо получать список последних значений из большого объема данных, эта таблица существенно ускоряет процесс. Поэтому, если есть проблемы с производительностью, следует использовать ее.
Как определить, какой программный продукт 1С подойдёт именно вашему предприятию / проекту? Это обсудим с коллегами из OTUS на открытом уроке 21 июня. На этой встрече мы:
Изучим функционал казначейства во флагманских продуктах 1С.
Обсудим преимущества и недостатки двух подсистем.
Определим критерии, благодаря которым мы сможем принять правильное решение о выборе программного продукта 1С для внедрения.
Записаться на открытый урок можно на странице курса «Бизнес-аналитик 1С».
Комментарии (21)
DMGarikk
20.06.2023 08:59В свое время я БитФинанс настраивал и у нас вполне использовались бизнеспроцессы в согласовании документов и двольно обширные и развесистые, очень сильно жизнь облегчали в плане донастроек процессов
Dynasaur
20.06.2023 08:59Про блок-схемы - в некоторых случаях это удобно, например настроить потоки работ (воркфлоу) или какие-то чисто бесчеловечные цепочки действий, например, ночная обработка потока заданий с ветвлением, ожиданиями и пр. В общем, то, что не нужно лично вам, не значит, что не нужно никому. А вот когда оно понадобится, а его не будет - вот тогда будет настоящая проблема.
exwill Автор
20.06.2023 08:59+1Давайте вместе попробуем описать реальную задачу, где без бизнес-процессов никак не обойтись
Dynasaur
20.06.2023 08:59Можно обойтись даже без 1С и даже без электричества. Но я однажды делал конфигуратор ночных заданий на похожем инструменте (в другой системе) - очень удобно из кубиков и стрелочек и логических операторов набираешь что должно сделаться ночью (передача данных, обработка, расчёты, отчёты, что делать если данные не передались успешно и т.д.). Утром приходишь - всё готово. Или цепочку утверждения какого-то документа или действия - тоже удобно нарисовать и поддерживать в таком виде.
exwill Автор
20.06.2023 08:59+1Соглашусь с вами, что воркфлоу как таковое прекрасно работает. Но ведь в других системах, как вы сами сказали
itmind
20.06.2023 08:59Бизнес-процессы упрощают разработку логики переходов и уменьшают количество кода на описание этих переходов. Самый простой пример использования бизнес-процессов - согласование документов по сложным маршрутам.
Вроде в 1с:Документооборот бизнес-процессы широко используются.
Hardcoin
20.06.2023 08:59+2ВЫБРАТЬ валюта, курс, дата
ИЗ РегистрСведений.КурсыВалют КАК КурсыВалют
ГДЕ дата В (ВЫБРАТЬ МАКСИМУМ(дата) ИЗ КурсыВалют КАК Т ГДЕ Т.Валюта = КурсыВалют.Валюта)
Запрос, приведенный для замены среза последних ошибочен. Он может выдать две строки. Конечно мы можем надеяться, что никто не будет писать две записи на одну и ту же дату, но что если нужна последняя продажная цена? Приведенное решение плохое.
exwill Автор
20.06.2023 08:59Штатный срез последних тоже может выдать две(и более) строки
itmind
20.06.2023 08:59Данный запрос синтаксически не верен. В периодических регистрах сведений измерение называется Период, а не Дата. Во вложенной выборке используется несуществующая ВТ КурсыВалют. Там тоже должно быть написано "ИЗ РегистрСведений.КурсыВалют "
Asmody
20.06.2023 08:59Бизнес-процессы "не летят" по двум причинам:
1) их нельзя менять вне конфигуратора;
2) они методически противоречат принципу "обратимости" операций.
Поэтому, область их применения таким образом сужена, и чаще всего то же самое может быть реализовано более традиционными методами. Но нельзя сказать, что они не используются вообще. Например, процедуры закрытия месяца сделаны на БП.
Но в платформе есть и другие "нелетящие" вещи: географическая схема, анализ данных (вы знали, что в платформе почти с рождения целый движок для этого "из коробки"?)
exwill Автор
20.06.2023 08:59+1Кстати, да. Про анализ данных я забыл. Он там действительно почти с рождения. И почти с рождения не обновляется. На сегодня, когда у нас есть scikit-learn, он, конечно, выглядит бесполезнее, чем бизнес-процессы
Asmody
20.06.2023 08:59Причина одна и та же: их воткнули в платформу под "конкретных" заказчиков "чтоб было" и заб
иыли. В типовых оно не используется, следовательно, никто толком не понимает, как оно работает и какие задачи решает.exwill Автор
20.06.2023 08:59Интересная история. Вы знаете под кого именно "втыкали" анализ данных?
Asmody
20.06.2023 08:59Достоверно не знаю. Но вы много можете назвать российских компаний, которым в первой половине 00х могла потребоваться такая функциональность? И кто из них был в то время подопытным "флагманских внедрений"?
И то, что эта богатая функциональность не используется в типовых, позволяет сделать вывод, что добавлена она была под конкретный проект.
LordDarklight
20.06.2023 08:59+1Полностью согласен про регистры расчёта - это уже вторая (если я не ошибаюсь) попытка реализовать что-то дельное для расчётов (первая была журналы расчёта - и помню на 7-ке их использовали не только для расчёта зарплаты, а например для ЖКХ - но это антиутопия).
Но с таким же азартом можно сказать, что и регстры Бухгалтерии слишком специфичны и применяются только для различных видов бух учета. Если ранее в системы могло быть несколько Бух регистров, то сейчас уже тенденция к сведению к одному - с перегрузкой этого регистра (т.к. его базовая архитектура не предназначена к такому увеличению нагрузки).
Но проблема разных типов регистров скорее не в том что их возможности не нужны - а в том как неудачно продумана изначально архитектура виртуальных таблиц - для регистров расчёта особенно неудачно - тут вообще чаще идёт работа условно физической таблицей). Думаю для решения всех задач накопления достаточно было бы одного регистра (накопления) + некий общий механизм настройки таблиц итогов + более частные конфигурации этих таблиц уже под каждое конкретное применение. То есть больше универсальности и больше свободы. Но изначально (да и сейчас - хоть это уже издёвка) компания 1С (и братья Нуралиевы в частности) проектировали систему исходя из упрощения её применения (в т.ч. программистами, коих тогда активно называли конфигураторами) - жёстко направляя решения определённых задач в определённое русло без кучи опций и нетривиального выбора вариантов настроек.
Вот над чем ещё стоило подумать - это над операциями отражения изменений в этих регистрах.
Сейчас это просто набор записей, где (в частности для регистра накопления) есть доп. поле с направлением движения - влияющего на авторасчёт итогов и виртуальные таблицы.
Но, на мой взгляд, правильнее было бы сосредоточиться на более конкретном выделении операций над регистрами (с вынесением их в отдельные объекты), как:
Изменение величины на заданную
Прибавление к величине
Убавление от величины
Включение/Отключение величины
Удаление величины (удаление мне не очень нравится, но и зануление тоже не совсем корректно - я бы сказал обNULLение величины)
И вот этими операциями и регулировал бы остальную разницу между регистрами (в т.ч. и для регистров сведений).
Тут же можно было бы сделать и периодическое действие операций - гарантирующих обратное возвращение "предшествующего" результата (только относительно данной операции, но не относительно других).
Третьим правильным нововведением (относительно 7-ки, ну или теперь уже на будущее - относительно 1С Предприятие 8) могли бы пользовательские виртуальные таблицы (в т.ч. переопределяемые стандартные) как привязанные к регистрам (хотя не обязательно только к регистрам), так и глобальные (работающие со всей конфигурацией) - эдакие аналоги не то View не то Хранимых процедур. Это могли бы быть достаточно гибко настраиваемые источники данных (а-ла как компоновка данных, хотя бы на уровне для Динамических списков), которые далее можно было бы произвольно использовать как источники данных (в т.ч. в произвольных запросах). Сами же виртуальные таблицы могли бы иметь и возможность программной обработки - тогда при обращении к ним внутри запросов данные могли автоматически выгружаться на сервер приложения, обрабатываться и обратно загружаться в во временную таблицу - это, конечно, не эффективный вариант, но допустимый для ряда случаев - в большинстве случаев должен строиться запрос для СУБД из специального ЯП запросов на диалекте СКД).
Такие пользовательские виртуальные таблицы могли бы быть очень полезны для многих сфер применения. Из них как из кирпичиков можно было бы складывать сложные выборки данных. Причём структуру виртуальных таблиц можно было бы динамически подстраивать (по заданным параметрам вызова) - меняя стратегию выборки или динамически строят запрос.
Ну а сами данные так же могли бы кэшироваться. Не только на время сеанса, но сохраняться в СУБД или на сервере Дата акселератора для общего использования.
Ну и про гибкую настройку индексов всё-таки забывать не стоит - хотя их уж, вроде бы обещали сделать.
И, вот странно, почему автор не назвал никчёмными Планы видов характеристик - вот что что - а это явный архитектурный косяк. И их аналог в лице "Определяемых типов" выглядит куда полезнее. Хранение вида типа как значения можно было бы на справочниках/регистрах организовать. Тоже касается и Планов видов расчёта и Планов счетов.
Неудачная реализация и Перечислений - они лишние когда есть куда более продвинутые в использовании справочники с предопределёнными элюентами (и развивать нужно было именно их).
Но Перечисления могли бы быть тоже полезны - как элементы форм и (общих) модулей т.е. внутри текста алгоритмов - вот где их действительно не хватает (ну и параметрах сеанса и хранилищах данных).
Но вернусь к ПВХ - как реализации Видов субконто - сами Субконто чутка хорошая, но на фоне появившихся измерений в Бух регистрах не такая уж уже полезная - и их архитектурная реализация желает лучшего. Это тупиковая ветвь. Вот идея расширенной аналитики - другое дело - и в платформе правильно было бы встраивать более глубокую поддержку именно такого подхода - когда аналитика регистра (а может и справочника/документа) становится квазидинамической - и легко меняется от записи к записи в рамках "одной" виртуальной таблицы.
А что насчёт Журналов документов - если в 7-ке они вполне были востребованы, то в 8-ке с каждой подредакцией платформы теряли свою востребованность. В итоге они сейчас уже неиспользуютс в ТАКСИ (есть же динамические списки) - очень неудачно реализованный вид объекта.
Аналогично - Последовательности документов - изначально были очень даже востребованы но..... в очень не эффективными и утратили свою актуальность.
Как и Константы - когда в 8-ке они перестали быть периодическими, а появились регистры сведений Константы постепенно почти сошли на нет. Особенно по началу, когда они были в все в одной таблице, то создавали ещё и кучу проблем с параллельным доступом на изменение.
Что до Бизнес-процессов - по мне так штука весьма интересная просто не развиваемая никак - сделали для галочки и забили - хотя из них вполне себе мог вырасти целый декларативный сценарий проектирования сложных схем взаимодействий. Но в нынешнем виде где даже сравнение/объединение этих схем БП выполнить эффективно нельзя - это тупик. Хотя для 1С Документооборота Бизнес-процессы очень даже хороши - и ничто не мешало бы так же строить процессы в других комплексных конфигурациях. Но тут нужно больше гибкости и интеграции. Ну и, безусловно, больше продвижения самой идеи. Текущая же модель даже в 1С Бухгалтерии практически полностью отдана на откуп конфигурации - т.е. сама платформа там почти ничего не делает - только схемки рисует - вся обработка чисто реализована в алгоритмах конфигурации, что говорит о том, что БП не прошли проверку эксплуатацией в первоначальной архитектурной задумке, а на их развитие в компании 1С "болт забили" - что печально. Я бы наоборот активнее встраивал бы БП во все конфигурации, а саму подсистему документарного взаимодействия и постановки задач прямо в платформу - чтобы это было всегда под ругой как стандартный API!
itmind
20.06.2023 08:59Но, на мой взгляд, правильнее было бы сосредоточиться на более конкретном выделении операций над регистрами (с вынесением их в отдельные объекты)
Может пояснить этот момент в терминах физических таблиц SQL? Вместо одной таблицы для регистра использовать несколько?
zVadim
В такой широкоиспользуемой системе, как 1С сложно говорить о бесполезности. То что вы перечислили, это скорее редкоиспользуемые вещи. Речь не о том, что это легаси, которое просто нельзя выпилить. Вполне возможно, что тот 0.X% пользователей бизнес-процессов, построили на них всё у себя, имеют штат специалистов, которые постоянно смотрят на схемы и адаптируют их под изменяющиеся обстоятельства. Т.е. для них это реально полезные вещи