«Правильная» типовая конфигурация
С типовой конфигурацией на платформе 1С:Предприятие работают трое:
· Разработчик типовой конфигурации
· Пользователь типовой конфигурации
· Внедренец типовой конфигурации
Правильный разработчик должен понимать, что типовая конфигурация не может охватить всех потребностей всех пользователей. На каждом предприятии есть свои особенности, бизнес-процессы, правила оформления документов, специфические отчеты и т.д. Поэтому разработчик должен осознавать, что типовая конфигурация будет настраиваться и дорабатываться внедренцем. А значит, правильный разработчик должен заботиться не только об удобстве конечного пользователя, но и об удобстве внедренца.
В свою очередь, правильный внедренец должен заботиться о сохранности типовой конфигурации и должен хотеть работать так, чтобы не трогать код разработчика. Платформа 8.1 дает для этого достаточно возможностей.
Основная цель - сделать конфигурацию такой, чтобы с ней могли в интересах пользователя параллельно работать разработчик и внедренец и при этом друг другу не мешать.
В качестве примера будем рассматривать типовую конфигурацию "Бухгалтерия предприятия".
Чего же хотят пользователи от внедренцев, а внедренцы от разработчиков ?
Очевидно, что разработчик типовой конфигурации, сколько бы интерфейсов он не создал в конфигурации, не сможет удовлетворить всме потребностям всех пользователей. Потому что разденение прав и обязанностей у конкретного пользователя зависит от многих факторов, от исторически сложившихся традиций делового оборота до клановых и родственных отношений в коллективе. Кроме того, интерфейс - это первый уровень в системе ограничения доступа к информации. Кому что можно видеть, кому что нельзя решает конкретный пользователь. Разработчик всем угодить не может в принципе и не должен к этому стремиться.
В типовых конфигурациях 1С в режиме Предприятие интерфейс формировать нельзя, ну сделали бы, чтобы хотя бы в Конфигураторе можно было бы работать не вмешиваясь в код 1С. Но непереключаемый интерфейс (в типовых конфигурациях 1С это интерфейс Общий) пользователю и в этом мешает.
Казалось бы, чего проще: создал свои интерфйсы, какие нужно, назначил пользователю и все. Но нет, кроме созданного интерфейса пользователь увидит еще и общий интерфейс. Зачем так делать? Пункты интерфейса прекрасно копируются, можно было просто раскопировать пункты общего интерфейса во все другие (в типовых конфигурациях все интерфейсов не так уж и много), а общий интерфейс не делать. В Управлении торговлей 10.2 можно посмотреть, что пришлось наворотить разработчикам, чтобы в интерфейсе кассира отключить видимость общего интерфейса. Одни разработчики делают, другие отключют.
И не могу не упомянуть про европейскую традицию "сверху вниз, слева-напаво". Это записано в стандартах 1С. Почему разработчики все делают в этой традиции, а нижнюю командную панель форм делают в арабской традиции справа налево, мне непонятно. Сверху все кнопки расположены слева, в форме основные элементы слева, тексты прижаты влево. Вводишь новый, например, или открываешь существующий документ, ведешь мышкой и глазами сверху вниз по левому краю формы, доходишь до низа, хочешь закрыть или нажать ОК, а там их нет. Они на правом краю. А если монитор широкоформатный? И вот мышью туда-сюда водишь.
На мой взгляд переключение интерфейсов должно быть встроено в платформу, в меню "Операции", аналогично выбору справочников, документов и т.д. Открываем меню "Операции", выбираем пункт "Интерфейсы" и выбираем нужный интерфейс. Да и в дереве конфигурации ветку Интерфейсы можно вытащить на уровень вверх.
Ну и дополнительно можно при разработке конфигурации предусмотреть переключение интерфейсов, как в типовых конфигурациях и сделано.
В 8.2 (в управляемом приложении) принцип построения интерфейса другой, это радует. Но все-таки хочется видеть кнопку Закрыть не только в правом верхнем, но и в левом нижнем углу.
Механизм поключаемых отчетов и обработок в режиме Предприятие - обязательная часть правильной типовой конфигурации.
Он должен обечпечивать подключение разных объектов (прежде всего встроенных или внешних отчетов и обработок) к различным точкам подключения.
Пишу об этом потому, что такую подсистему разработал и использую сам. И буду на нее часто ссылаться.
Суть в том, что разработчик типовой конфигурации закладывает при разработке точки подключения, к которым можно подключать разные объекты. У меня это встроенные отчеты и обработки, внешние отчеты и обработки, вызов процедуры общего модуля или открытие любой формы конфигурации или внешнего отчета или обработки.
И тогда пользователь с внедренцем могут типовые объекты от этих точек отключить, свои подключить и все это в режиме Предприятие, без изменения конфигурации и без снятия с поддержки, если пользоваться внешними отчетами и обработками.
Кроме того, в подсистеме есть управление доступностью подключаемых объектов для групп пользователей и отдельных пользователей, так что она является и частью системы ограничения доступа и позволяет создавать разные интерфейсы для разных групп пользователей.
Вообще подсистема подключаемых объектов должна быть центральной системой любой правильной типовой конфигурации. Еще лучше, если это будет одна и та же подсистема во всех конфигурациях, как от 1С, так и от партнеров.
Вот сейчас 1С пытается сделать библиотеку стандартных подсистем для 8.2, и это очень правильно. Но пока там нет такой подсистемы, и это очень неправильно.
Разработчик не может знать всех возможных последовательностей цепочек документов, которые пользователь вводит на основании друг друга.
Значит либо в конфигурации надо предусматривать ввод всего на основании всего, либо сделать настройку этого механизма в режиме Предприятие и пусть этим занимается пользователь.
Вот например, хочет пользователь в УТ 10.3 вводить оприходование товаров (готовая продукция) на основании заказа покупателя. Нормальное желание, если у них бизнес процесс так проходит. Ну смешно же ради этого лезть в конфигурацию. Конечно в УТ есть стандартный механизм заполнения табличной части через кнопку "Изменить", но уж больно много действий надо совершить, чтобы заполнить "ОприходованиеТоваров" на основании "ЗаказаПокупателя". Когда это единичный случай такой механизм приемлем, но если это регулярное действие - то неприемлем.
Вот в бухгалтерии наткнулся: хочется ввести перемещение на основании требования-накладной - нельзя. Вводим новое перемещение, в нем есть кнопка "Изменить", там операция "Добавить из документа", но в списке возможных видов документа нет требования-накладной.
Ну не должен разработчик типовой конфигурации ограничивать возможность ввода на основании конкретным перечнем типов объектов. Это пользователь должен определять, а внедренец помочь ему это настроить без изменения конфигурации. В этом ему поможет подсистема подключаемых объектов.
Я удивляюсь разработчикам типовых решений. Все согласны, что должен быть механизм подключаемых внешних печатных форм. Может хотят и не все, но давление пользователей (внедренцев) заставляет такой механизм иметь. Ну не могут разработчики удовлетворить всем запросам всех пользователй в части печатных форм, и стремиться к этому не должны. И при этом все разработчии имеют и другой механизм для встроенных печатных форм. Зачем поддерживать два различных механизма?
Сейчас внедряем конфигурацию от Раруса. Внешние печатные формы подключить можно, а отключить встроенные нельзя. В результате список печатных форм к документу увеличивается почти в два раза и становится хуже. Значит надо лезьть в конфигурацию. В конфигурациях 1С можно заменить внешней формой встроенную, но все это дополнительные навороты.
А ведь подсистема подключаемых объектов решает все вопросы. Разработчики пусть подключают к кнопке "Печать" свои встроенные отчеты и обработки, а конечный пользователь может некоторые отключить и подключить свои, хоть внешние, хоть встроенные печатные формы.
Вообще такая подсистема должна быть центром любой типовой конфигурации. Я давно применяю такую подсистему и на платформе 7.7 и на платформе 8 у все больше в этом мнении укрепляюсь.
Внедряли "Учет медицинских услуг" от АналитИКС. Там программисты выпендрились: есть настройка (по умолчанию включена), которая скрывает в списках помеченные на удаление объекты. Ну а персонал как везде, много молодых неопытных девушек. Чуть что не так - нажимают "Del" и элемент(документ) пропадает с глаз долой. Они радуются. Пока мы разобрались база оказалась в таком состоянии ....
В связи с этим подумал, что право на пометку на удалению любых объектов (и снятие пометки соответственно) должно быть собрано в отдельную роль "ПравоНаУдаление". А в других ролях его вообще не должно быть, в том числе и в роли "ПолныеПрава".
Ну в самом деле: нормальная эксплуатация любой конфигурации не предполагает вообще какое-либо удаление каких-либо объектов. Трудно представить, что разработчик будет проектировать бизнес-процесс, в котором надо что-то ввести, а потом удалить.
А уж если надо что-то удалить, например, результат ошибки, пусть обращаются к специально обученным пользователям, у которых доступна роль "ПравоНаУдаление". Они их накажут за ошибки, глядишь их и меньше станет. Такие же специально обученные люди должны делать и редкие регламентные операции с базой данных, которые требуют удаления объектов, напрмер, свертку базы.
- в "правильной" типовой конфигурации не должно быть непереключаемого интерфейса и должен быть механизм формирования интерфейса для групп пользователей (и отдельного пользователя) в режиме Предприятие. И стиль разработки форм должен быть единым: европейская традиция, сверху-вниз, слева-направо.
- управление вводом на основании должено находиться на уровне Предприятия, а не в Конфигурации.
- правильная типовая кофигурация должна соержать роль ПравоНаУдаление, в которой собраны права пометки на удаление для всех объектов. Другие роли (включая роль ПолныеПрава) права пометки объектов на удаления иметь не должны.