Я работаю с 1с более 15 лет, до этого занимался и бизнесом и программированием на других языках. Как мне кажется, что сейчас компания 1с слегка оторвалась от реалий в своем стремлении развиться и поработить мир.
Все что здесь написано, является исключительно моими наблюдениями и домыслами.
Если компания 1с сочтет, что мой труд несет, какие то зародыши здравого смысла, просьба связаться со мной по почте (может чего полезной и выйдет, я открыт для диалога)
По этому я решил рассмотреть наиболее важные на мой взгляд моменты касающиеся и идеологического и технического развития 1с. Последней каплей для написания данной статьи стало столкновение меня с новой системой БСП (библиотекой стандартных подсистем) в документообороте и бух 3.0. А так же некий диспут на вечный спор про 1с и ООП (объектно-ориентированное программирование)
Тому, кто уже читал: проведен анализ, что именно реализовано за прошедший год, можно сказать, что 30% из предложений сейчас выполнены или находятся в процессе.
Всего предложений - 20
Полностью выполненых - 4 (20%)
В процессе - 2 (10%)
Не выполненых - 14 (70%)
Поехали:
--------------------------------------------------------------------------------------------------------------
Платформа, есть файловая версия и есть клиент серверная в различных вариантах.
файловая версия
|
1c предполагает |
Реалии |
|
Файловая версия поставляется "как есть", и будет эксплуатироваться ларьками с малым количеством пользователей (в идеале одним пользователем). Или использоваться для обучения. |
файловую базу франчи впаривают жадным компаниям, у которых нет своего специалиста (из-за жадности) и из-за этого они покупают именно файловую версию, даже если предполагается, что там будет работать 20 бухгалтеров. Логика руководства при этом такая: "7.7 файловая в терминале работала? Работала и ни кто не жаловался, а новая 1с более современная и работать должна не хуже". А после перехода начинается нытье, что 1с полное г....о. |
Согласитесь, что от этого портится репутация 1с и в дальнейшем рынок 1с теряет потенциальных клиентов. Кроме того даже на курсах по новым конфигурациям преподаватели открыто говорят, что при включении RLS на новых релизах файловая база начинает тормозить (и ведь действительно тормозит).
Не реализовано. На мой взгляд, необходимо запретить использовать файловую версию в многопользовательском режиме, во-первых в монопольном режиме включать RLS вряд ли кто будет, во вторых это немного повысит и безопасность и надежность базы. Данное предложение уменьшит поток нареканий по поводу "1с-это тормоз". Да и не смотрите на меня так, сначала дочитайте остальные мои предложения до конца (после разбора клиент серверного варианта SQL).
Клиент серверная версия (SQL)
|
1c предполагает |
Реалии |
|
База будет устанавливаться, и эксплуатироваться опытными специалистами, причем сервер SQL - это серьезная тема (и дорогая) и ее будет настраивать DBA администратор. |
Клиент серверную SQL базу покупают 2 вида клиентов: 1. действительно большие компании где есть специалисты по SQL и там в общем все нормально. 2. компании где есть 1с специалисты но те которые просто не могут сэкономить на бесплатном сервере баз данных PostgreSQL (из-за отсутствие специалистов) но понимают что на файловой базе у них будут проблемы. Поэтому они берут SQL как продукт наименее геморройный, но при этом в компании ни кто не знает чего с ним нужно делать, сколько и каких лицензий и т.д. Не редко SQL, 1с и клиентские сессии висят на одном сервере. |
Вторая категория, устанавливающая SQL, наверно самая обширная и согласитесь, что она проблемная.
1. Для компаний до 30 пользователей покупать SQL и лицензии на него все же накладно, да и отдельный железный сервер чисто под SQL далеко не обязателен.
2. Квалификация собственных IT специалистов довольно низкая. Использовать франчайзи или прочих сторонних специалистов конечно можно, но это имеет рад неудобств и получаемые услуги зачастую то же довольно низкого качества.
В результате мы имеем частые проблемы с настройками SQL, дополнительные траты и не очень хорошую производительность. Что конечно ухудшает мнение о продукте компании 1с.
Клиент серверная версия (postgresql)
|
1c предполагает |
Реалии |
|
База будет устанавливаться и эксплуатироваться опытными специалистами желающими сэкономить на лицензиях как SQL так и Windows. |
Реально такой вариант изначально выбирают не ради экономии, а по тому что есть специалист, который все это умеет и именно он убеждает руководство в псевдо экономии. Конечно, пока он работает в компании, то компания экономит, но вот после его увольнения найти нормальную замену сложно и дорого. |
Такая категория то же находится в зоне риска слегка разочароваться в 1с.
Что можно сделать для улучшения клиент серверных вариантов установки:
1. Реализовано (минисервер). Для маленьких компаний добавить возможность использовать серверу 1с вместо SQL базу данных формата 1cd, сделать такой вариант относительно дешевым. Тем более такая возможность почти реализована в службе удаленного хранилища.
2. Не реализовано. Для консоли управления сервером добавить мастера
а. Мастер создания новой базы и регламента бекапов, обновления статистики, реиндексации
б. Мастер создания/пересоздания копии с базы, при этом копия базы должна располагаться в детках основной, (отключение фоновых заданий, выполнение произвольного скрипта в самой базе перед первым запуском, например, изменить наименование базы, поменять константы). Правильное пере подключение к хранилищу.
в. мастер проверки безопасности (проверка пароля на кластер, проверки паролей в базах)
г. мастер бекапа и восстановления средствами СУБД (непосредственно из консоли)
д. мастер тестирования бекапа (восстановление в отдельную временную базу, запуск произвольного скрипта и удаление)
3. Не реализовано. Интегрировать консоль управления и службу удаленного хранилища, чтобы хранилище объединяло прямо в кластере несколько баз
В результате мы получим следующие варианты основных поставок
1. Файловая для монопольного использования (некий аналог базовой но с возможностью программировать), рассчитан вариант на ЧП, домашнего использования, для ведения крошечных фирм с 1 бухгалтером. (ориентировочно 200$)
2. Серверная с поддержкой только формата 1cd, предназначена для небольших фирм от 2х до 30 пользователей, простая в поддержке с автоматическим бекапом средствами сервера 1с. С ограничениями файлового формата. (ориентировочно 500$ + пользовательские лицензии)
3. Полная серверная версия с возможностью выполнять 100% действий по администрированию/настройки/бекапированию/регламентов конечной СУБД (SQL) не вникая в тонкости самой СУБД. (ориентировочно 2500$ + пользовательские лицензии)
Эти три варианта уменьшат проблемы с низкой квалификацией IT специалистов и увеличат реноме компании 1с. Так же второй вариант поможет многим компаниям сэкономить на сторонних лицензиях не прибегая к "узким" специалистам. Правда, возможно уменьшение сумм покупки (часть покупателей серверной части перескочат на второй вариант) но его можно компенсировать увеличением цены на третий вариант.
WEB интерфейс
Безусловно, web интерфейс это большой шаг вперед, но давайте посмотрим, когда он был сделан? Правильно когда управляемых форм и тонкого клиента еще не было в помине, с тех пор как сама 1с сильно шагнула вперед, этот компонент выглядит неким рудиментом. А развитие сервисов вообще делает web интерфейс не сильно нужным.
|
1c предполагает |
Реалии |
|
Основным назначением WEB интерфейса является универсальность запуска с любого компьютера, без установки платформы 1с |
Реально для запуска 1с через браузер пользователь (а точнее IT специалист, по тому что пользователь сам не справится да и прав у него может не быть) должен настроить безопасность (при чем часто это идет в разрез установленным в компании политикам) и еще кучу галочек. Кроме того браузеров много разных и у всех настройки разные. Поэтому в реальном мире универсальность и простота использования браузера – это миф |
|
Web интерфейс поддерживает весь функционал 1с, и любая конфигурация без проблем в нем «взлетает». |
Если даже не брать криворукость кода, то простые ограничения браузера по памяти, делает невозможным работать с большими объёмами данных. Да и в языке столько специфики касаемо web интерфейса, что мы начинаем выходить из привычной концепции 1с. |
|
Для сложных случаев (1с признает, что с браузером есть «сложные случаи») есть тонкий клиент через WEB интерфейс. |
Конечно, это решение лучше, чем просто web интерфейс, но дело в том, что 1с запрещает передавать третьим лицам (например, филиалу, или своему партнеру) любые компоненты платформы (не смотря, что лицензии используются сервером 1с). Поэтому для конечного пользователя необходимо покупать базовую поставку при полном отсутствии необходимости иметь лицензию для работы. Кроме того при работе тонкого клиента через web требуется одна версия сервера и клиента (зачем – не понятно) и при обновлении платформы на сервере приходится обновлять клиента у всех «партнеров» |
Что можно сделать для работы с web интерфейсом:
- Реализовано. Сделать бесплатным и общедоступным дистрибутив тонкого клиента без поддержки файловых баз, при этом 1с ни чего не потеряет в продажах, пользовательские лицензии все равно нужны.
- Не реализовано. Сделать мастер административной настройки браузера для работы с web клиентом.
- В процессе. Развивать сервисы 1с с прицелом полного перехода web интерфейсов именно на сервисы.
Файлы логов
Как и 15 лет назад лог файл сейчас живет отдельно от базы, если раньше это особых проблем не составляло то сейчас, безусловно, проблемы есть (например, на бух 3.0 при логе в 1 гиг при попытке что-то посмотреть сервер почти «умирает»). Наиболее видимая альтернатива ведению в файле – это ведение непосредственно в базе. Попробуем сравнить эти два варианта.
|
Ведение в отдельном файле |
Ведение в базе данных |
|
Плюсы:
|
Плюсы:
|
|
Минусы:
|
Минусы:
|
Как мы видим, обе схемы имеют в себе серьезные минусы. Поэтому истина, где то посередине.
Что можно сделать?
Я вижу 2 варианта
- Не реализовано. Разделить место хранения событий между файлом и базой, например, все критические события храним в базе, а все остальное в файле. Этот вариант решит часть проблем, но не будет панацеей.
- Реализовано. Хранить лог в отдельной базе данных (для файловых баз в формате 1cd для клиент-серверных на сервере баз данных). Этот вариант тоже немного странный, зато снимает практически все минусы кроме отдельных усилий по администрированию этой базы
--------------------------------------------------------------------------------------------------------------
Общее увеличение сложности конфигураций и внедрение БСП.
Прикидывая количество строк кода в бух 7.7 и бух 3.0 (прикидывал я путем глобального поиска точки с запятой) я пришел к следующим значениям
бух 7.7 - примерно 200 000 строк
бух 3.0 - примерно 1 000 000 строк
То есть бухгалтерия из довольно простой и понятной для одного человека конфигурации превратилась в монстра, количество вложенных вызовов процедур зашкаливает. Увеличивается как сложность понимания, так и время выполнения кода, в результате приходится бить железом (увеличивать память, ЦП и т.д.). С увеличением размера кода сложнее искать ошибки, да и самих ошибок становится больше. Что то подправить то же проблема, по тому как обновления необходимо накатывать намного чаще (в 7.7 можно было год жить, в 3.0 максиму квартал), и не смотря на более дружественный интерфейс объединения все равно обновление не типовой - это геморрой. 1с продвигает БСП (библиотека стандартных подсистем), безусловно это шаг вперед, хотя как ни странно но для "самописок" это шаг довольно сомнительный
|
1c предполагает |
Реалии |
|
БСП решает проблемы сборки собственных конфигураций. Достаточно только связать соответствующие подсистемы и немного доработать напильником и все взлетит. |
Реально самописки делают по двум причинам: 1. хочется выкинуть лишнее и получить быстрое, в этом варианте БСП подходит только для самого минимума функций, по тому что БСП это более менее универсальный монстр с кучей "лишнего" 2. есть принципиальные расхождения требуемых алгоритмов от того что есть в типовых, в данном случае то же БСП не сильно подходит. |
|
БСП решает проблемы отраслевых решений разрабатываемых франчами. |
Отраслевые решения франчей как правило строятся на типовых конфигурациях, введение БСП им особо не вредит, но и не помогает, так как удобство обновлений нивелируется размерами требующего проверки кода после обновления. |
|
БСП - ведет к блочному построению всей системы, что упрощает понимание, и уменьшает повторяемость кода. |
В том виде какая БСП сейчас там все так переплетено, что ни о каком блочном построении и речи быть не может, а полное отсутствие каких либо инструментов для поиска требуемого функционала заставляет большинство программистов просто писать все в одном флаконе, без использования встроенных универсальных процедур БСП. |
Что можно сделать:
1. Не реализовано. Кесарю - кесарево, то есть вернуть БСП более логичное назначение, а именно не пытаться в нее впихнуть конкретику ведения учета, а сделать разделение на ДВЕ системы.
а. БП (Библиотека подсистем) - библиотека процедур функций и переопределяемых метаданных, данная библиотека должна быть хорошо задокументирована, отлажена и редко изменятся, для того что бы она стала неким расширением языка и все ею пользовались. А почему нельзя все это запихнуть в язык? Да по тому что в процедуре языка нельзя реализовать работу с метаданными которых еще нет (например, нельзя в функцию поместить две валюты и число а на выходе получить пересчитанную сумму), причем обновление этой библиотеки должно идти отдельно от обновление конфигурации.
б. Библиотеки прикладных подсистем - библиотеки реализующие конкретную бизнес логику, вот именно тут и раздолье для самописок и отраслевых решений.
Стоп!!! а что это за слово промелькнуло "переопределяемых метаданных"???
2. Не реализовано. Бинго! я веду в сторону ООП, вариант реализации:
а. для объекта "подсистемы" добавляем модуль (или несколько модулей с разными режимами НаСервере/СервереБезКонтекста), в них и размещаем БП это упростит поиск модуля по смыслу.
б. в модулях добавить строку подключаемых модулей (по аналогии с паскалем), этим можно будет в одном месте управлять перекрытием процедур модулей, да и наглядность будет выше. Пример: есть модуль подсистемы УправлениеПользователями в котором описаны 2 функции УстановитьПароль(НовыйПароль) и УстановитьПараметр(Параметр, Значение). И модуль подчиненной подсистемы УправлениеПользователямиРарус в котором переопределена функция УстановитьПароль(НовыйПароль) (например в ней добавили почтовое уведомление о смене пароля). Если в модуле формы в разделе описания подключаемых модулей будет стоять УправлениеПользователямиРарус то будет доступна функция УстановитьПароль (из модуля раруса) и УстановитьПараметр (из БП, по тому что есть иерархия).
в. по сколько формы у нас управляемые, то вполне можно сделать формы с подчинением, на пример есть форма ПКО в ней описываем общие поля, закладки и т.д. Далее вместо создания перечисления ТипыПКО и делания из него функциональной опции мы делаем на каждый тип ПКО свою форму в которую автоматом наследуется основная форма ПКО. Тем самым мы отсекам кучу ненужного кода а оставляем только код который требуется именно нашему виду документа. Согласитесь это удобно! Кстати давно пора у формы сделать 2 модуля "клиентский" и "серверный".
г. переопределяемые метаданные, например Документ ПКО, у него делаем подчиненный документ ПКО_Омега, все модули и формы наследуются, нам нужно только добавит в документ реквизит "КоментарийОмега" и в журнале вместо типа ДокументПКО указать ДокментПКО_Омега и все, при этом любые обновления документа ПКО будут проходить на ура.
В результате получим следующий пирог
|
Источник |
Функционал |
Пример |
|
Библиотека подсистем |
Базовые объекты (расширяемые) |
Подсистема «УправлениеПользователями», модуль Функция УстановитьПароль(Пользователь, НовыйПароль) Экспорт … КонецФункции; Процедура УстановитьПараметрСеанса(Параметр, Значение) Экспорт … КонецПроцедуры; ***************************** Подсистема «ДенежныеДокументы_Базовая», документ ПКО_Базовый – объект виртуальный, нужен для возможности использовать тип документа и реквизитов в тексте и метаданных. |
|
Отраслевые решения, конечные «допилы на местах» |
Расширения и изменения базовых объектов |
Подсистема «УправлениеПользователямиРарус» (подчинена «УправлениеПользователями»), модуль // добавляем почтовое уведомление при смене пароля Функция УстановитьПароль(Пользователь, НовыйПароль) Экспорт Результат = Подсистема.УправлениеПользователями.УстановитьПароль(Пользователь, НовыйПароль); Если Результат Тогда ПослатьПочтовоеУведомлениеОСменеПароля(Пользователь); КонецЕсли; Возврат Результат; КонецФункции; |
|
Библиотеки прикладных подсистем |
Функциональные объекты |
Подсистема «ДенежныеДокументы» на основании «ДенежныеДокументы_ Базовая», документ ПКО на основании «ПКО_Базовый», в нем определяется базовый функционал документа и форм, всякие кнопки печати и присвоение номера т. д. Документы «ПКО_ ОплатаОтПокупателя», «ПКО_ РозничнаяВыручка», «ПКО_ ВозвратОтПоставщика» на основании «ПКО» все эти документы содержат только дополнительные, по отношению к «ПКО», реквизиты. Формы автоматически наследуют функционал базовый функционала форм и по этому содержат только «новый» код. |
|
Отраслевые решения |
Расширения и изменения функциональных объектов |
Подсистема «ДенежныеДокументыРарус» на основании «ДенежныеДокументы», документ ПКО_ ОплатаОтПокупателя_Рарус на основании «ПКО_ ОплатаОтПокупателя», в нем добавляется реквизит «Коментарий_Рарус» и определяется функционал работы с ним. |
|
Конечные «допилы на местах» под специфику конкретной организации |
Расширение и изменение функционала отраслевых и типовых решений |
Внешняя обработка РеестрПКО, Вариант 1, модуль: Модули Подсистема. ДенежныеДокументыРарус; // здесь будут доступны формы «ПКО_ ОплатаОтПокупателя_Рарус», «ПКО_ РозничнаяВыручка», «ПКО_ ВозвратОтПоставщика» Вариант 2, модуль: Модули Подсистема. ДенежныеДокументы; // здесь будут доступны формы «ПКО_ ОплатаОтПокупателя», «ПКО_ РозничнаяВыручка», «ПКО_ ВозвратОтПоставщика» |
Каждый слой пирога обновляется самостоятельно с некоторыми ограничениями, но практически все слои могут обновляться полностью автоматически.
--------------------------------------------------------------------------------------------------------------
Запросы и все что с ними связано.
Отсутствие UpDate
100% запись в базу средствами 1с продиктована с одной стороны безопасностью и желанием дать возможность использовать промежуточный код 1с, а также для выполнения операций требуемых ядру 1с (расчет итогов, кеширование и т.д.). С другой стороны за это платим скоростью и масштабируемостью. Имеется в виду не запись одного регистра, а запись «транзакции». После введения «гибких» блокировок ситуация заметно улучшилась, но при том количестве дублируемых регистров 1с все равно безнадежно отстает от требований сильно нагруженных систем.
|
100% запись в базу средствами 1с |
UpDate средствами SQL |
|
Плюсы:
|
Плюсы:
|
|
Минусы:
|
Минусы:
|
На мой взгляд, прямой UpDate для 1с давать нельзя, с другой стороны явно нужны инструменты ускорения длительных операций записи.
Чего можно сделать:
- Не реализовано. Для справочников/документов/пвх/регистров необходимо реализовать оператор изменения одного реквизита по отбору (такая операция довольно часто будет использоваться, например, для изменения прав доступа или добавление нового реквизита и его заполнения). Сейчас похожая возможность есть у регистров «НаборЗаписей», но хочется иметь возможность на вход ему давать текст запроса вместо отбора. Разумеется при выполнении такого оператора должны выполняться проверки на необходимость дополнительных действий (например пере проведение), определять требуется или нет обрабатывать код реакторов 1с (модуль объекта, подписки на события) следует или по метаданным или аналогично Объект.ОбмнеДанными.Загрузка = Истина.
- В процессе. Разделить весь учет (и все регистры) на «оперативный» и «не оперативный» (собственно эту идею частично используют в УПП), но мне бы виделся вариант решения несколько иным (пока до конца идеи не сформировал, но думать в этом направлении нужно).
Временные таблицы или вложенные запросы
Однозначного рецепта здесь нет, приведу лишь видимые мною плюсы и минусы обоих подходов.
|
Временные таблицы |
Вложенные запросы |
|
Плюсы:
|
Плюсы:
|
|
Минусы:
|
Минусы:
|
Сам стараюсь использовать ВТ только в 2х случаях: Повторное использование или необходимость индексирования результата.
Пакетные запросы
Это довольно сильное новшество 1с но, даже не смотря на это, и у него есть минусы или пожелания. Первое пожелание сделать выполнение пакетов в двух режимах последовательное/параллельное, понимаю, что при параллельном выполнении будут недоступны ВТ предыдущих пакетов, но зато за счет этого можно будет ускорить те тяжелые запросы, которые есть сейчас. Конечно, Вы скажете, что сам SQL умеет распараллеливать вычисления, но как распараллелить то, чего еще не послано сервер.
|
1c предполагает |
Реалии |
|
Пакеты запросов уменьшают обмен между клиентом и сервером уменьшают время его выполнения и упрощают код. |
Отчасти 1с права, но существуют и накладные расходы по формированию сложных структур, кроме того получается некий монстр в результате работы которого получаем вместо простого рекордсета сложную структуру. Читабельность кода уменьшается. |
Что можно сделать:
- Не реализовано. Ввести в запрос и самое главное в поддержку конструктора комментарии. Что упростит разбор простыней запросов.
- Не реализовано. Ввести поля комментарии в получаемую при выполнении пакета структуру.
RLS
Разграничение доступа на уровне записи (или даже отдельных полей), очень полезное и нужное новшество восьмерки. Но, как и всегда есть минусы.
|
Плюсы RLS |
Минусы RLS |
|
Самым главным плюсом является глобальное упрощение форм, отчетов и любой другой формы вывода информации, кажется, что вообще не нужно заботиться ни о чем. |
Самым главным минусом является падение скорости выполнения запросов и кода 1с. |
|
Безусловно, система RLS не всегда понятна для рядовых программистов и многие ее просто боятся использовать, причина простая – вполне реально получить отчет (за который реально получить взбучку вместо премии): Иванов – 2р Петров – 3р ------------------- Итого – 1254р |
|
|
Текущие реализации RLS в БСП – это просто монстры вселенной, кто смотрел – тот поймет. Десятки тысяч строк шаблона … Что либо изменить в текущей реализации – не реально, можно только писать рядом «свое» |
|
|
RLS частенько порождает «Объект не найден», особенно на формах в реквизитах. Часто бизнес требует «скрыть» а вместо этого имеем «Объект не найден». |
|
|
RLS не всегда и не везде можно применять, например динамический список в виде дерева по справочнику с RLS – это смерть всему живому (по тому что 1с не может в дереве определить количество элементов которые помещаются на экран). |
Что можно сделать:
- Не реализовано. По сколько шаблоны RLS компилируются в запросы на сервере (и кэшируются), можно ввести в шаблоны поддержку вложенных шаблонов RLS (разумеется, есть опасность зацикливания). Это даст превращение текущих RLS БСП в более менее читабельный и расширяемый код строк так на 500.
- Рализовано. Ввести конструктор запроса для создания шаблонов RLS
- Не реализовано. Ввести просмотр скомпилированного запроса RLS. (с возможностью подстановки произвольных параметров)
--------------------------------------------------------------------------------------------------------------
Интерфейсы и все с чем работает пользователь.
Про юзабельность и интерфейсы
Стоит признать, что текущие конфигурации на управляемых формах довольно хорошо продуманы, и 90% всего, что требуется пользователю ему доступно в 3 клика. Это очень хороший показатель и учитывая тот факт, что за счет функциональных опций скрывается неиспользуемый функционал интерфейс и для пользователей выглядит довольно дружелюбным. Но как мы знаем большинство действий можно выполнить несколькими способами, и каждый пользователь работает «по своему». Например, кто-то снимает с проведения, зайдя в документ, а кто-то из списка. Кроме того существует индивидуальная настройка форм. Вроде все хорошо, но давайте пройдемся по списку.
|
Текущее поведение 1с |
Желаемое поведение |
|
Каждый пользователь может индивидуально под себя настроить «меню» и формы. При определенных условиях (смене компьютера/переподключении базы) все теряется. |
Во первых хочется иметь возможность изменять форму и меню согласно некоторому корпоративному шаблону. Вы скажете, что для этого есть роли, и будете правы но только отчасти, хочется например единым шаблоном у всех пользователей открыть меню «дополнительные отчеты». Короче хочется что-то вроде переключаемого интерфейса (вспоминаем обычные формы и плачем по хорошо забытому старому). Во вторых при столь подвижном интерфейсе остро встает вопрос об инструкциях, если на скриншоте у пользователя есть меню «Дополнительные отчеты», а в программе оно «спряталось» - то, как минимум будет звонок «помоги», а то и письмо «опять все сломали». К сожалению, квалификация огромного количества пользователей не позволяет добиться от них хоть самого маленького усилия по самостоятельному поиску решения. В третьих хочется иметь возможность копирования интерфейсов и самое главное всех настроек от другого пользователя. Вспоминаем ситуацию, когда приходит новый человек и начальство говорит – «Он пришел на замену Иванова», сейчас приходится лазить и перетаскивать кучу настроек. |
|
Текущие настройки содержат некорректные настройки, которые нельзя изменить по кусочкам. Часто доходит до того что приходится сносить все персональные настройки. |
Хочется иметь универсальную кнопку сброса всех настроек пользователя привязанных к конкретной форме. |
Про отчеты
Новая система отчетов, продвигаемая в БСП на 100% реализована на регламентных заданиях. Давайте разберем.
|
1c предполагает |
Реалии |
|
Каждый отчет создает отдельное регламентное задание и выполняется в фоновом режиме. Вроде тут одни плюсы, по сколько пока отчет «думает» пользователь может выполнять любые другие действия. |
Для «первичных» отчетов действительно пользователь готов ждать результата, а вот для получения расшифровки из 10 строчек ожидание в 3 секунды – это реально создает мнение, что программисты полные идиоты и 1с г..о |
Что можно сделать:
Насколько я понимаю, есть два проблемных места
- Не реализовано. Ожидание клиента, сейчас раз в 1 сек. проверяется как там задание, выполнилось или нет. Тут мне видится логичным реализовать новый оператор оповещения конкретной клиентской сессии из регламентного задания.
- Не реализовано. Очередь на сервере для запуска регламента, тут можно добавить параметр «приоритет» и например расшифровки выполнять с более высоким приоритетом, чем все остальные.
