К этой публикации меня подтолкнула зависимость кода разработчика от опыта.
Вернее, обсуждение данной темы...
С одной стороны оптимальное решение поставленной задачи и код, решающий её, это тот самый "бриллиант" и стремление к достижению "совершенной огранки" похвально.
И хорошо, что его нет, если бы этот "бриллиант" существовал, то все бы его "зазубрили" в начальной школе, и обсуждения бы не было.
Такие "технологические" обсуждения нужны и интересны, но...всё-таки отличие Junior'а от Oldschool'а в большей степени сказывается в подходе к решению других задач.
Собственно, второй побудительной причиной к написанию, оказалась случайно возникшая во время "неудачной" стажировки ниже описанная постановка задачи.
В "историческом прошлом" приходилось "решать" множество "непонятных мне хотелок" по 1С - от "добавления 5-ти знаков после запятой в цену" до печатной формы "Накладной на отпуск материалов на сторону (М-15)" для документа "Перемещение товаров", который из Управления торговлей потом должен перегрузиться в Бухгалтерию.
И спорить с инициатором в обоих случаях было бесполезно.
Оправдание им, только недопонимание "экономическими" специалистами сути их "хотелок", в первом случае упорствование в своём желании перенести свои "экселевские" достижения на другую "почву", без оглядки на очевидное, что у нас копейки, в США центы, и меньше просто не бывает.
Во-втором, непонимании логики применения того или иного вида документа, "неосознании" того, что М-15 подразумевает передачу материальных ценностей из одного предприятия в другое, а Перемещение как документ нет.
Вред от реализации таких "хотелок" не очень большой, со знаками после запятой вообще минимальный, так неудобство.
С "печатной" формой чуть сложнее, заново после "затыка" с переносом в другую базу, создать положенные документы вместо перемещений, чтобы вернуться в "законодательное русло"
Гораздо больше бизнес теряет от неправильно выбранного метода решения, при котором происходит "потеря информации", которая обычно выявляется апостериори, когда уже собственно "потеря" произошла.
Постановка задачи:
В компании используется "Управление IT-отделом 8", учёт ведётся по множеству организаций и множеству складов - территориально-распределенное торговое оборудование.
Есть проблема - стандартно для справочника "Карточки номенклатуры" никаких ограничений нет, каждый сотрудник видит все карточки.
Собственно, задача - надо ограничить форму списка "Карточки номенклатуры" только "нужными" позициями, в первую очередь по месту хранения.
Начинающий (Junior) и Уже с опытом (Middle) прочитав такую постановку сразу примутся за дело - ведь "ограничить" - это же "чистый" RLS.
Делов-то, добавим в карточку реквизит "Склад", сделаем его обязательным и задача нами решена. На вопрос - оператор будет его всегда выбирать? - сразу без раздумий звучит ответ - нет, мы его возьмём и заполним из настроек пользователя. Никаких сомнений - результат достигнут!
Ведущий разработчик (Senior), Эксперт (Expert) и тем более Огромный опыт (Oldschool) должны и поступят иначе. Зададут себе вопросы, чтобы оценить последствия от выбора того или иного варианта решения?
Первый вопрос - зачем карточки номенклатуры в конфигурации? Какова цель их применения?
Описание справочника из помощи
Карточки номенклатуры
Справочник предназначен для хранения элементов каждой комплектующей.
Чтобы понять, что такое карточка номенклатуры и чем она отличается от номенклатуры рассмотрим пример:
Номенклатура: Автомобиль ВАЗ 2107
Карточка номенклатуры: Автомобиль ВАЗ 2107 гос. номер: К117ВТ 123 RUS
Т.е. номенклатура описывает вид объекта, а карточка указывает на конкретный экземпляр.
В списке запись с шрифтом зеленого цвета означает, что данный элемент не выбран ни в одном документе "Поступление".
Вроде всё однозначно - это номенклатура, обладающая уникальными свойствами, единичные экземпляры.
Но, обращу внимание на последнее предложение, карточка номенклатуры по аналогии с номенклатурой может быть создана до её использования.
Второй вопрос - как часто карточка используется в конфигурации с "архитектурной" точки зрения. Поиск ссылок на объект поможет в этом.
Анализ показывает, что данный справочник связан с другими объектами: справочниками Местоположения и Шаблоны заданий, документами Задание, Изменение показателей оборудования, Инвентаризация, Наряд на работы, Начало обслуживания, Окончание обслуживания, Перемещение, Поступление, Продажа, Разбиение комплектации, Сборка комплектации, Списание, Учет денежных средств, регистрах сведений Бюджеты, Состояние карточек номенклатуры, Статусы карточек номенклатуры, Характеристики, Штрихкоды номенклатуры и в регистрах накопления Закупки, Комплектация, Обслуживание контрагентами, Остатки, Показатели оборудования, Продажи, Ремонты.
Как видим степень "вовлеченности" карточки в "архитектуру" значительна. Добавление нового реквизита возможно приведёт к необходимости изменений где-то ещё.
Третий вопрос - какова может быть "история жизни" в базе конкретного экземпляра карточки?
Обсудим "Автомобиль ВАЗ 2107 гос. номер: К117ВТ 123 RUS" из справки.
Когда-то он нами был куплен и определен на место хранения "Склад 1".
Эксплуатировался ежедневно, и в какой-то момент возникла необходимость в ремонте.
У нас крупная организация и есть подразделение, которое выполнит такой ремонт - машина поехала туда и через некоторое время вернулась на своё первоначальное место хранения. Через какое-то время головное руководство приняло решение купить нам новый автомобиль, а этот переместить в другой филиал, где через несколько лет он был продан или списан.
"Жизненный путь" может быть долгим и местонахождений объекта в течении этого цикла может быть множество.
Теперь давайте вернёмся к нашим действующим лицам, к тем кто уже решил поставленную задачу и не видит в ней никакой сложности.
Зададим им вопрос, который обязательно зададут те, кто будет эксплуатировать базу после доработки.
Что нужно сделать с реквизитом карточки "Склад", когда машина поехала на ремонт?
Поменять на место ремонта, но тогда здесь карточка из списка "пропадёт".
Оставить как есть, но тогда она в ремонтном подразделении не "появится".
Значит и тем, и тем дать доступ к этим складам. Ремонтное подразделение конечно может желать видеть с чем им придётся иметь дело. А зачем lдругим видеть всё, что оприходовано в ремонтном подразделении?
А если её передали в другой филиал?
Тогда точно поменять "Склад" на новое место. А что тогда мы увидим в документе первоначального поступления её в организацию?
То есть, выбрав такое решение, "бизнес" получит "потери":
Про автомобиль переданный в ремонт кто-то может "забыть", а ремонтники по этой причине будут не торопиться его вернуть. Никто же не торопит с возвратом.
Открыв документ из прошлого окажемся в ситуации - искать бумажные версии документов в которых можно найти, что же было в них - в базе же, там где должна быть карточка -"белое пятно".
Вывод: Решение лежащее на поверхности - добавление реквизита и RLS - приведёт к новым проблемам.
А как же решать:
Найти то, единственное в данном случае место, в которое нужно внести изменения.
Локализуем код, который будем править, в форме списка "Карточки номенклатуры" используется динамический список
ВЫБРАТЬ РАЗРЕШЕННЫЕ
СправочникКарточкиНоменклатуры.Ссылка,
СправочникКарточкиНоменклатуры.ВерсияДанных,
СправочникКарточкиНоменклатуры.ПометкаУдаления,
СправочникКарточкиНоменклатуры.Предопределенный,
СправочникКарточкиНоменклатуры.Владелец,
СправочникКарточкиНоменклатуры.Код,
СправочникКарточкиНоменклатуры.Наименование,
СправочникКарточкиНоменклатуры.ИнвентарныйНомер,
СправочникКарточкиНоменклатуры.СерийныйНомер,
СправочникКарточкиНоменклатуры.БухНомер,
СправочникКарточкиНоменклатуры.Комментарий,
СправочникКарточкиНоменклатуры.ЕстьОграниченияПоСрокуДействияЛицензии,
СправочникКарточкиНоменклатуры.ДатаНачалаЛицензии,
СправочникКарточкиНоменклатуры.ДатаОкончанияЛицензии,
СправочникКарточкиНоменклатуры.ЕстьОграниченияПоСрокуДействияОбновлений,
СправочникКарточкиНоменклатуры.ДатаНачалаПодпискиОбновлений,
СправочникКарточкиНоменклатуры.ДатаОкончанияПодпискиОбновлений,
СправочникКарточкиНоменклатуры.КоличествоПользователейЛицензии,
СправочникКарточкиНоменклатуры.ЕстьОграниченияПоКоличествуПользователейЛицензии,
СправочникКарточкиНоменклатуры.ВерсияПО,
СправочникКарточкиНоменклатуры.ДатаУстановкиПО,
СправочникКарточкиНоменклатуры.КлючАктивации,
СправочникКарточкиНоменклатуры.Владелец.ВидНоменклатуры.НавСсылка КАК НавСсылка,
СправочникКарточкиНоменклатуры.ГарантияМесяцев,
ВЫБОР
КОГДА СправочникКарточкиНоменклатуры.ЕстьГарантия
ТОГДА ДОБАВИТЬКДАТЕ(СправочникКарточкиНоменклатуры.ДокументПоступления.Дата, МЕСЯЦ, СправочникКарточкиНоменклатуры.ГарантияМесяцев)
ИНАЧЕ ДАТАВРЕМЯ(1, 1, 1)
КОНЕЦ КАК ДатаОкончанияГарантии,
СправочникКарточкиНоменклатуры.ДокументПоступления,
СправочникКарточкиНоменклатуры.ВидНоменклатуры,
ЕСТЬNULL(ОстаткиПоКарточкам.Количество, 0) КАК Количество,
ЕСТЬNULL(ОстаткиПоКарточкам.Сумма, 0) КАК Сумма,
СтатусыКарточекНоменклатурыСрезПоследних.Статус,
СтатусыКарточекНоменклатурыСрезПоследних.Статус.НавСсылка КАК КартинкаСтатуса
ИЗ
Справочник.КарточкиНоменклатуры КАК СправочникКарточкиНоменклатуры
ЛЕВОЕ СОЕДИНЕНИЕ (ВЫБРАТЬ
ОстаткиОстатки.Номенклатура КАК КарточкаНоменклатуры,
СУММА(ЕСТЬNULL(ОстаткиОстатки.КоличествоОстаток, 0)) КАК Количество,
СУММА(ЕСТЬNULL(ОстаткиОстатки.СуммаОстаток, 0)) КАК Сумма
ИЗ
РегистрНакопления.Остатки.Остатки(, ТИПЗНАЧЕНИЯ(Номенклатура) = ТИП(Справочник.КарточкиНоменклатуры)) КАК ОстаткиОстатки
СГРУППИРОВАТЬ ПО
ОстаткиОстатки.Номенклатура) КАК ОстаткиПоКарточкам
ПО СправочникКарточкиНоменклатуры.Ссылка = ОстаткиПоКарточкам.КарточкаНоменклатуры
ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СтатусыКарточекНоменклатуры.СрезПоследних КАК СтатусыКарточекНоменклатурыСрезПоследних
ПО СправочникКарточкиНоменклатуры.Ссылка = СтатусыКарточекНоменклатурыСрезПоследних.КарточкаНоменклатуры
Вот его-то и надо исправить для достижения требуемого результата.
Сразу заметим, в запросе левое соединение с регистром "Остатки", который участвует в RLS, и уже одно исправление левого соединения на внутреннее ограничит список карточками номенклатуры, которые есть на остатках на доступных пользователю группах доступа мест хранения. И, собственно, это уже практически тот же результат, что и у "начинающих" программистов.
Но для полноценного решения этого недостаточно.
Следующими доступными пользователю карточками должны стать те, которые в истории "побывали" на доступных пользователю местах хранения. На форме списка они выделяются красным цветом шрифта.
И, наконец, наши созданные, но ещё не использованные карточки.
Собственно, всё это в прилагаемом файле - технология, доступная всем от .Junior'а до Oldschool'а.
Лишь пару примечаний:
В динамическом запросе используется основная таблица "Справочник.КарточкиНоменклатуры", поэтому изменяя запрос можно получить "Обнаружено дублирование...", если не обеспечить одну запись справочника единственной записью при дополнении данных соединением.
Конструируя запрос нужно не забывать, что выполняться он будет под ограниченными правами, и это надо учитывать. Получение незадействованных карточек запросом исключения не сработает.
Работа расширения проверена на Управление IT-отделом 8, редакция 3.1 (3.1.3.15) (softonit.ru).
В заключение:
Надеюсь, данная публикация поможет начинающим в деле становления по пути к экспертам.
И всем тем, кто "ощущает" себя уже "сеньором", но всё ещё выбирает "добавить Склад".
Мои публикации:
- Код для поиска номенклатуры в конфигурациях 1С. Использование мнемоники по первым буквам как вариант применения
- Анализ оборачиваемости для УТ 11.4
