gifts2017

Когда добавлять предопределенные элементы справочников уже поздно... но ОЧЕНЬ хочется

Опубликовал Тартаковский Геннадий (torch) в раздел Программирование - Практика программирования

Понимание того, что некоторые элементы некоторых справочников следовало бы изначально сделать предопределенными, иногда приходит поздно. Но, как говорит Риддик голосом Ван Дизеля... "Во Вселенной ничто не происходит вовремя - или поздно, или слишком поздно"

При разработке новых конфигураций разработчик не всегда вовремя понимает, какие элементы и в каких справочниках следует сделать предопределенными. По крайней мере у меня это стандартно происходит со справочником "СтатьиДоходовРасходов" и с некоторыми другими. Так, например, недавно для конфигурации "Интернет-магазин" ввел справочник "Страны". Пользователи его заполнили, и стали юзать... но потом возникла потребность привязать некоторые алгоритмы расчета доставки, комиссии оплаты, способов доставки и проч. к конкретным странам. Что делает в этой ситуации большинство программистов?

1. Обвинить заказчика "почему Вы мне об этом раньше не сказали"

2. Покусать себе локти "почему я сам не додумался, что так будет"

3. Использовать старый "семерочный" способ определения элемента справочника... что-то типа "Если Спр.Код = "007" Тогда...."

 

Есть конечно вариант добавить-таки предопределенные элементы, а потом групповой обработкой переписать все ссылки на новые элементы....

Я поступаю иначе. Понимая, что эта ситуация типична, будет повторяться в будущем и уйти от нее НЕВОЗМОЖНО, я в каждой своей конфигурации создаю служебный справочник "ПреодпеределенныеЭлементыСправочников" с единственным реквизитом "СправочникЯкорь" (Тип - СправочникСсылка). Когда мне понадобилось при расчете стоимости доставки выделить страну "Украина", я добавил в мой справочник предопределенный элемент "СтранаУкраина" и указал в нем ссылку на соответствующий элемент справочника "Страны", а в алгоритме расчета доставки использовал конструкцию

"Если Заказ.Страна = Справочники.ПредопределенныеЭлементыСправочников.СтранаУкраина.СправочникЯкорь Тогда..."

В этот же справочник я могу поместить ссылки на любые другие элементы любых других справочников. Например, могу создать элемент "СтатьяАмортизацияЗданийСооружений" или "ВалютаДоллар" или "КонтрагентЛюбовницаШефа"... правда, в последнем случае будет очень больно, если в этом месте программа даст сбой и выведет пользователю сообщение с соответствующим текстом из программного модуля...

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей Куликов (ksvd) 11.12.13 10:26
Надо проверить сегодня. За идею спасибо
4. Павел Алексеенко (qwinter) 12.12.13 16:44
В 8.3 с этим славо богу проще)
5. rasswet (rasswet) 18.12.13 08:58
почти аналогично делаю.
6. Иван Иванов (kosmo0) 18.12.13 09:24
я добавил в мой справочник предопределенный элемент "СтранаУкраина"

Наверное я что-то не понимаю. Чтобы не создавать предопределенный элемент в нужном справочнике автор создает предопределенный элемент в специально созданном справочнике? Если это так, то это бред.
AnryMc; Stim213; +2 Ответить 3
7. Тартаковский Геннадий (torch) 18.12.13 11:09
(6) Я хотел создать предопределенный элемент в справочнике "Страны". Но когда я понял, что мне это надо - было уже поздно. Пользователи создали его интерактивно
8. Павел Колмаков (Stim213) 18.12.13 13:12
Если честно, это похоже на изобретение велосипеда. Конешн, так проще, чем создавать предопределенный элемент справочника Страны, переносить все ссылки на него.. но простой вариант не значит правильный!

Предопределенный элемент - это в первую очередь элемент, заданный разработчиком и изменяющийся только разработчиком! Ваш же якорь могут изменять любые пользователи, имеющие доступ к справочнику "предопределенных" элементов. И не факт, что однажды в Справочники.ПредопределенныеЭлементыСправочников.СтранаУкраина.СправочникЯкорь не окажется страна Замбабве, скажем.
Кроме того, созданием нового справочника с якорями вы только усложняете структуру связей в конфигураторе, "замусориваете" код и затрудняете дальнейшее сопровождение.

В общем, хороший такой костыль. временный.
9. Тартаковский Геннадий (torch) 18.12.13 15:04
(8) Во-первых переносить ссылки не всегда получается, т.к. некоторые клиенты используют закрытие периода и блокируют документы до определенной даты. А во-вторых справочник ПредопределенныеЭлементыСправочников является служебным, заполняется мною лично и остальным пользователям даже не показывается
10. DAnry (DAnry) 18.12.13 17:52
Супер идея. Спасибо. Довольно часто стыкался с подобными проблемами. Решал их через метод НайтиПоКоду или НайтиПоНаименованию , что не совсем правильно. Возьму на вооружение.
11. Кирилл Бондаренко (karapuzzzz) 19.12.13 04:24
Идея, конечно не новая. Пользуюсь подобным справочником довольно давно. Это намного лучше, чем "НайтиПоНаименованию" или "НайтиПоКоду". Я бы даже сказал - более правильно.
Сначала я хотел написать комментарий из серии "Автор, пользуйся поиском..." или "Зачем писать прописные истины...". Но после просмотра комментариев - автор, спасибо, что подняли эту тему и сдули с нее пыль.
(8) Stim213, (6) kosmo0, пожалуйста, поделитесь "правильным" способом. В топике есть ситуация, предложите свое решение.
12. Павел Колмаков (Stim213) 20.12.13 15:18
оххх..
(11) karapuzzzz, решений несколько, выбор того или иного способа зависит от условий бизнес-процессов, которые автор не описал.

кроме того, справочник Страны - должен(!) заполняться на основании классификатора стран мира (Общероссийский классификатор стран мира )
там есть и правильный названия стран и коды и многое другое.
При правильном ведении учета(а мы же говорим про него?) на этапе внедрения разработки справочника нужно как минимум проанализоровать дальнейшую его бизнес-логику, а не бросать его в растерзание пользователям. Заполнить справочник из классификатора, заполнить все служебные реквизиты, по которым будет идти поиск.. в крайнем случае заполнить справочник предопределенными значениями на основании того же классификатора..
НО ЭТО ВСЕ ДЕЛАЕТСЯ ДО(!), А НЕ ПОСЛЕ ВНЕДРЕНИЯ! не тогда, когда пользователи набивают 100500 одинаковых стран и используют их в 100500^100500 документах.
Если вы в чем-то сомневаетесь, господа - посмотрите хотя бы как это реализованы в типовых. От ошибок и они не застрахованы, но с архитектурой там все в порядке.
13. Павел Колмаков (Stim213) 20.12.13 15:43
+ а когда "уже все поздно" - можно обойтись и без дополнительных справочников.
но все опять же зависит от бизнес-логики и структуры базы, универсальных советов дать не смогу..
Например, если доставка для разных стран разная, то можно справочнику Доставки дать табличную часть Страны, разграничив таким образом различные доставки по разным странам. Возможно, это будет какой-то регистр с настройками.

Да и вообще, старайтесь строить архитектуру своих решений с минимальными возможными изменениями. Продумывайте свои действия на пару шагов вперед.
Дайте пользователям больше возможностей для персональных настроек и настроек программы. Это истинный арийский подход).
Те, кто работают с типовыми, наверняка, уже успели оценить механизм установки ролей(прав) пользователей в управляемых приложениях(пользователи ИБ регистрируются из режима Предприятия)
Чем меньше пользователи будут вас дергать по пустякам - тем лучше им и вам. Оставьте время для серьезных разработок.
14. Кирилл Бондаренко (karapuzzzz) 20.12.13 17:36
(12) Stim213, Типовые на то и типовые, что пытаются охватить многое, но не все. Считается нормальным 10% бюджета на внедрение выделять на программирование.
Вы говорите "старайтесь строить архитектуру своих решений с минимальными возможными изменениями. Продумывайте свои действия на пару шагов вперед.". Я продумываю свои действия. Но продумать действия заказчика невозможно.
Судя по вашим ответам, можно сделать вывод, что все программирование происходит только во время внедрения. А потом всеми руками и ногами отбрыкиваемся от заказчика. А он ведь как: "сначала не хочу, а потом хочу" или "ой, а как же мы все это время жили без этой кнопки?".
Ваш "Возможно, это будет какой-то регистр с настройками." предполагает создание еже одного объекта. Так почему регистр с настройками лучше справочника?
15. Павел Колмаков (Stim213) 20.12.13 20:32
"Так почему регистр с настройками лучше справочника?"
Потому что в 1С настройки программы или отдельных подсистем хранятся в основном в регистрах сведений:)
нет, ну можно конешн хранить и в справочниках, и в документах. можно даже во внешних файлах сохранять, в двоичных данных или во внешней базе. реализовать можно как угодно, но нужно - в унификации с типовой.
Тем более регистр сведений наиболее оптимален для хранения и чтения периодически изменяющейся информации.

"все программирование происходит только во время внедрения." - так и должно быть. К этому нужно стремиться, по крайней мере. До начала внедрения все вопросы должны быть решены. Конешн, всех затыков не избежать, но в конкретной ситуации с автором - при проектировании справочника Страны - нужно было бы сразу вспомнить о классификаторе стран мира и обсудить вариант с его с клиентом.
Костылями пользуются все в той или иной степени, но выкладывать сверкающий и нарядный костыль как универсальное решение, вместо того, чтобы сделать как надо - имхо, бред.

Господа, читайте мануалы! http://its.1c.ru/db/v8std#browse:13:-1
16. Андрей Журавлев (Wrols) 23.12.13 09:03
(15) Stim213, программирование происходит не только во время внедрения.
А у вас довольно-таки идиалистический взгляд...

Практика показывает, что бизнес меняется, а из-за этого меняются и требования к учетной системе.
Всё течет, всё изменяется. Это жизнь. Это нормально.

Предложенное решение автора имеет право на существование. А то, что справочник "Страны" упомянут - так это же только пример.

Вот только минусы имеет - производительность и такое обращение не сработает в запросе...

17. Кирилл Бондаренко (karapuzzzz) 07.02.14 16:00
(16) Wrols, Почему не сработает? Можно в запросе напрямую обращаться к предопределенному элементу (не используя параметры).
Идея предопределенного элемента сводиться к тому, что можно жестко обратиться к нему из конфигуратора. С регистром так не получиться.
18. red 80 (red80) 02.09.14 10:07
(6) kosmo0, ты действительно не понимаешь. Чтобы понять, нужен опыт обновлений типовой.
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа