ViPRosGarya,

ну и как ты предлагаешь системе выспрашивать забытую характеристику?Она просто не дает ее забыть. Она ее сама добавляет все характеристики родительского типа в дочерний подтип после выбора родительского типа - некоторые позволяет модифицировать (и даже удалить), а некоторые не даст потому что сотрудник, администрирующий корневую часть иерархии задал такие правила наследования. Забыть, конечно, что-то можно, но только очень специфическое исключительное для данного подтипа, но не для родительского типа.

ViPRosв моем случае - при вводе "насос" или "плунжерный" или "вихревый" система что то покажет ( в первом случае плунжерный и вихревый, а в других насос и подтипы плунжерного или вихревого), если введеннего свойства в системе не существует то она по желанию добавить его в систему, типизирует и предложить включить его в имеющиеся классификаторыНу не нравится, извини...
Конкретная номенклатура насоса может иметь километровое наименование, состоящее из груды циферек, буковок и спецсимволов, и в наименовании, как правило, отсутствуют фразы "вихревой" или "плунжерный". Даже в закодированном виде в наименование может быть включена только некоторая часть характеристик. Кстати, правило формирования наименования - тоже наследуется. Пользователь вводит характеристики, а наименование бац - и само сформировалось по шаблону (в 1С подобный механизм тоже есть). Но у насосов, произведенных в России, по ГОСТ имеются одни правила формирования, в других странах - другие, к тому же, не все производители эти правила соблюдают, так что возможны вариации правил формирования наименования при систематизированных характеристиках.

Вспомни Excel - там есть такая фишка - "автофильтр". А теперь представь, что ты встал в какой-то узел иерархии. В нем родительская запись имеет перечень характеристик. Выбираешь интересующую характеристику, включаешь "автофильтр" - и по всему поддереву (или только по следущему уровню) у тебя автоматом отфильтровываются только те части дочернего поддерева, в которых есть записи с заданным значением характеристики... Это правда прикольно - те кто видел, просто балдели... :) Потому что на таблицах автофильтр видели, а вот на иерархических данных - не всем довелось... :)

ViPRos"характеристика" важнее чем объект, потому сначала словарь надо загнать в модельЯ не спорю. Только словарь этот можно упорядочить по иерархии дерева, в котором он задействован. Это удобно. Позволяет не рыскать глазами по всему словарю, когда из словаря выбираются характеристики, имеющие смысл только для насосов.

ViPRosViPRos,

Так ведь список - линейный. Глазами по всему шарить придется. Отсюда и ошибки - кто-нибудь проглядит золотое зерно, перелопачивая груды руды.

GaryaViPRosGarya,

ну и как ты предлагаешь системе выспрашивать забытую характеристику?Она просто не дает ее забыть. Она ее сама добавляет все характеристики родительского типа в дочерний подтип после выбора родительского типа - некоторые позволяет модифицировать (и даже удалить), а некоторые не даст потому что сотрудник, администрирующий корневую часть иерархии задал такие правила наследования. Забыть, конечно, что-то можно, но только очень специфическое исключительное для данного подтипа, но не для родительского типа.Посмотри "мультик" на слайде №17 - там показан пример, как можно работать с механизмом наследования. Родительская запись задает перечень характеристик, но без указания значений. На следующем уровне перечень характеристик автоматически наследуется - то есть, как только мы добавляем туда запись, перечень характеристик родительской записи у нее уже сразу есть. Но на этом уровне разным записям мы можем присвоить разные значения этим характеристикам. На третьем уровне механизм наследования будет в каждую подгруппу второго уровня добавлять записи третьего уровня и с перечнем характеристик, и со значениями, которые определены на втором уровне, но с разными значениями для каждой ветви.
Если на уровне родительской записи не запрещены модификация или удаление унаследованных характеристик, то на следующем уровне можно удалить родительскую характеристику и добавить какую-то другую - и в данной ветви дерева наследоваться уже будет она. Причем, если задано ее значение, то вместе со значением. Таким образом, в разных ветвях поддерева может быть разный состав характеристик. Может быть совсем-совсем-разный, а может быть немного-разный... :)

ViPRosну, ты лукавишь
того чего нет (забыто) ниоткуда не возьмешь и никто тебя никак не может заставить его не забыть

Garyaкак только мы добавляем туда запись, перечень характеристик родительской записи у нее уже сразу есть
Как можно "забыть" то, что уже есть? :)

ViPRos,

Да ладно, забудь. :)
Это я немного поностальгировал. От той системы остались лишь воспоминания.
Руководство приказало остановить разработку и внедрение самописной системы и использовать типовой функционал какой-нибудь тиражной системы... :) Даже если он более кривой и менее функциональный. При этом ошибочно полагая, что с внедрением тиражной системы проблем будет меньше. Проблем оказалось существенно больше, но, тем не менее, я исполнил приказ, потому что исполнительный... :)

ViPRosGarya,

да не наследование это, а шаблоны. про них я тебе и рассказывал
но у вас там как токо шаблон поменяешь, так сразу все беременны этими изменениями
а у меня это по желаниюУ меня тоже по желанию. Если по каким-либо причинам принято решение изменить или дополнить состав характеристик родительской записи, у которой уже есть груда дочерних на нескольких уровнях иерархии, можно указать, на сколько уровней иерархии изменения должны размножиться. Можно сделать так, что они не затронут ранее введенные записи, а будут влиять только на те, которые будут добавляться в дальнейшем. А можно сделать и так, чтобы характеристики были у материнской записи, а к дочерним вообще не наследовались. В общем, ограничено лишь полетом фантазии... :)

Однако, реально мы НЕ-наследуемые характеристики практически не использовали.

ViPRos, вырезал скриншот из презентации.

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

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

Слева внизу - "свойства" (из "словаря"), которые могут наследоваться или НЕ наследоваться со значениями или без значений от "папки" к записи, которая в нее добавляется. Обрати внимание, как выглядит словарь "свойств" - это тоже иерархия. Получается иерархия в иерархии... :)

Справа внизу - то, что мы не обсуждали. Информация по версионности и журнализации по двум осям времен - учетному и календарному (реальному). Календарное (реальное) онлайн-время используется для журнализации, а учетное время используется для версионности записей по оси учетного времени. Но это уже совсем другая тема...

ViPRos,

Видишь треугольничек возле каждой строки свойства? Это - "автофильтр"! :)

Во фрейме свойств (левая нижняя часть) отображается перечень свойств и значений только одной записи справочника - той, которая выделена в правой верхней части. Перечь записей, отображаемых в правой верхней части, можно "отавтофильтровать" по значению некоторой комбинации "свойств" и "полей".

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

Александр ПузаковGaryaКстати, для айтишников, знакомых с принципами объектно-ориентированного программирования, не должно быть проблемой трансформации подобных принципов на предметную область. В конце концов, можно было бы реализовать (при желании, конечно) механизмы наследования между разными уровнями сущностей, как минимум. Тогда можно было бы создавать, типа, группу номенклатуры с привязанной к группе некоторой совокупностью атрибутов. При добавлении новой записи в группу дочерние записи "наследуют" некоторые атрибуты без возможности их изменения, другие записи с возможностью изменения. Те атрибуты, которые без возможности изменения, можно сделать еще и ретроспективно-модифицируемыми - то есть, при изменении родительской сущности чтобы аналогичные атрибуты автоматически модифицировались и у всех дочерних сущностей. А для модифицируемых атрибутов такая концепция позволила бы реализовать механизм определения "значений по умолчанию", которые используются чаще всего в разных частях, например, номенклатурного справочника (но и не только).
В 1С такое настроить элементарно. Всего несколько строчек кода и изменение одного свойства у реквизитов справочника.Возможно, избавившись в 1С от поддержки (а без снятия типовой конфигурации с поддержки предложенное "настроить элементарно" не получится) и превратив тиражную систему в той или иной степени в самописку, в 1С можно решить любую задачу.
Вот только зачем покупать тиражную систему (в частности, 1С), если у предприятия есть кого занять написанием кода?

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

FEGarya... Как бы Вы отнеслись к разработчику операционной системы, который предлагал бы переписать исходный код проданной им операционной системы, если бы в ней какое-либо приложение невозможно было бы запустить или если бы копирование основной массы файлов работало бы нормально, за исключением файлов PDF?

Linux?...

Дико извиняюсь, не мог удержаться... А что, в Linux такое случается, что его требуется переписать перед тем как скопировать файлы?