создать новую тему раскрыть все
 
Куда мне ввести банковские реквизиты этих агентов? В ту крохотную строчку "примечание"? Это ужасно неудобно.
Приходится базу по агентам держать в екселе.
свернуть/развернуть ветвь А я говорил! Говорил же! [cheburek 07/06/2005 12:53] # написать ответ
 
Что из-за этих примечаний приходиться вести паралеллельно какую-то базу и синхроинизироваться постоянно...
 
Воооут.
 
то было предложено в качестве решения в дереве агентов создавать ветви с интересующими реквизитами в качестве названий. При этом можно посмотреть реквизиты прямо в дереве.
 
свернуть/развернуть ветвь случайно ентер нажал [Explorer 07/06/2005 17:31] # написать ответ
 
однако формировать таким образом запись о клиенте не очень удобно
 
я предложил бы во время создания нового классификатора, одновременно создавать шаблон - т.е. формировать набор полей признаков свойственных для этого классификатора...
 
т.е. помимо того, чтобы предложить пользоваетелю указать название классификатора во множественном и в единственном числе и проч.
 
дать пользователю возможность создать несколько User Defined properties
 
<<< для классификатора контрагент/конрагенты это могут быть например
 
ИНН
Имя контакта
Название компании
Телефон
 
для подразделения компании это может быть
 
название отдела
руководитель
намер центра затрат
 
для расходов по квартире это может быть
 
адрес
номер договора аренды
имя владельца
 
и проч.>>>
 
сформировав таким образом окружение и признаки некоей сущности отображаемой как классификатор
 
Аналогичная тема в другой теме форума. Ну да ладно.
 
Итак, реквизиты плательщика/получателя просто просятся в счетах. И это относительно просто сделать. А вот по классификаторам...
 
Я уже написал (в другой теме форума), что для классификаторов всё едино, они все хранятся вместе. И если делать "в лоб", добавлять эти поля в классификаторы, то они появятся и в агентах и в статьях и в проектах, точнее, во всех классификаторах. Что, на мой взгляд, не есть хорошо.
 
Решение, которое предложил уважаемый Explorer - возможный вариант снятия этой проблемы. Однако, как я понял из предложения, например, даже в рамках контрагентов у разных узлов дерева возможны разные поля. Я правильно понял?
 
Таким образом получается, что нужно делать что-то типа адресной книги Аутлука, с одним отличием: в Аутлуке какой-никакой, но состав полей определён довольно жёстко. А тут, похоже, нужна просто очень гибкая структура, которая бы позволяла создавать новые поля "на лету". Всё верно?
 
в пределах одного классификатора - некоторый шаблон (вероятно настраиваемый)
 
например сейчас...
 
я создал классификатор "контрагенты" на вкладке "классификаторы"
в появившейся вкладке "контрагенты" я вижу родительскую запись "контрагенты"
для нее я создаю Child записи "Рога и копыта"
для "Рога и копыта" я создаю Child записи "ИНН контрагента" "Расчетные счета контрагента" "Адреса контрагента" "Телефоны контрагента" "Контакты контрагента"
 
в ИНН контрагента я сразу забиваю в поле примечание ИНН
 
для расчетных счетов я создаю Child ("основной" "дополнительный")записи если счетов несколько
-//-//-// для адресов
-//-//-// для контактов и телефонов
 
для адресов контрагента я создаю Child записи
 
"юридический" в примечании юр. адрес
"почтовый" в примечании почтовый адрес
 
для контактов контрагента я создаю подчиненные
 
"гл бухгалтер" в примечании имя фамилия
"руководитель" в примечании имя фамилия
"представитель" в примечании имя фамилия
 
и так для любого следующего контрагента...
 
так вот, хотелось бы иметь возможность формировать шаблон такой структуры на этапе создания классификатора (и возвращаться потом для редактированияч этого шаблона), в дльнейшем, при добавлении нового контрагента вся структура Child записей создается автоматически...
 
примерно так
 
Well))
 
а потм еще сделать настраиваемое дерево - например <показывать по юр. адресам >< показывать по ИНН >< показывать по Имени гл. бухгалтера><показывать по алфавиту>
 
Я это представлял немного иначе. Но, похоже, ваш подход куда мощнее. Нужно обдумать.
 
Спасибо!
 
Первое замечани (дополнение) которое приходит на ум, состоит в том, что потребуется ввести некоторые "ограничители". Так, чтобы (на вашем примере) в операциях можно было выбирать только контрагента, но не его реквизиты. Я правильно понимаю, что такой ограничитель будет оправдан? Как вы считаете?
 
Для каждого классификатора задается свой набор... хм... примечаний. то есть информационных полей, которые можно заполнить для всех классификаторов данного типа. В операциях эти данные не фигурируют (нельзя их выбирать), но могут использоваться для поиска, группировки и сортировки.
 
...так думал вначале. Но предложенный подход мне показался очень интересным. И даже не потому, что такая реализация влечёт меньше трудозатрат в программировании. Дело в том, что если добавлять "примечания", да ещё и именованные (а добавление колонок именно это и подразмевает), то внутренние таблицы начнут просто "пухнуть" вширь. Что не есть хорошо. Можно, конечно, извратиться, но это будет как-то не очень хорошо.
 
А подход уважаемого Explorer-а хорош как раз тем, что он позволяет решать проблему количества полей универсальным способом. Очень, на мой взгляд, удачно. И даже немного жаль, что такая идея не посетила мою голову. Well
 
которая будет увеличивать количество экземпляров записей а не количество аттрибутов записи... изменения структуры хранилища данных (таблицы, условно говоря) не потребуется...
 
ограничения на число вложеных (иерархически подчиненных) аттрибутов имеет смысл ввести, если это связано со скоростью работы базы, в противном случае нет смысла их вводить...
 
вопрос - как отличить экземпляр записи в классификаторе от аттрибута записи в классификаторе - ИМХО придется ввести доп. признак - служебное поле по которому будет определяться - является ли экземпляр записи отображением сущности-классификатора или ее свойства-аттрибута
 
вопрос - имеет ли смысл заморачиваться и устанавливать свойства для такого иерархического аттрибута... ИМХО вряд ли это оправдано - это усложнит процедуру (алгоритм) создания такого шаблона - путь будут обычные текстовые поля 50 - 70 символов
 
каждый раз руками создавать иерархическую структуру - хлопотно, вариант с шаблоном, формируемым одновременно с созданием классификатора мне кажется достаточно оправданным
 
...у меня возник вопрос, навеянный фразой (заметкой) "показывать по Имени гл.бухгалтера".
 
Кто такой главный бухгалтер? Человек.
 
Кто такой "контрагент"? Это физические и юридические лица.
 
Может ли главный бухгалтер некоторого юридического лица-контрагента выступить в качестве самостоятельного контрагента-физического лица? Безусловно, да.
 
Вопрос: как в этом случае избежать дублирования в таком усовершенствованном дереве контрагентов? Есть какие-то критерии?
 
я мог открыть примечание (например двойным нажатием на поле примечание), которое отображалось уже не в виде одной тонкой строки, а как комментарий в этой форме отправки сообщения на этот форум, то есть, поле ввода и просмотра информации было бы квадратным в котором соблюдалось при сохранении форматирование.
 
Тогда я бы просто вставлял туда текст такого формата:
 
инн 34343344
кпп 343434
бик 343434
 
И когда мне надо было бы посмотреть реквизиты этого агента, то я бы нажимал на строке с нужным мне агентом два раза и мне выскакивало квадратного окошко "примечание", в котором бы была сохраненная ранее информация.
 
По большому счету это похоже на примечания в ms excel (отображаются на строке, но сами по себе могут содержать огромное количество текста, если это примечание раскрыть).  
 
...для вас этого достаточно. Но это неструктурировано и, на мой взгляд, менее красиво, чем предложенный вариант с подветвями.
 
в этои программе ИМХО нет смысла копать очень глубоко, поскольку задачи разработки и применения объектно ориентированных подходов весьма и весьма нетривиальны...
 
то, что в Кэш частично решается именно ООБД уже хорошо
 
поддержание целостности и нормализация, которая позволит избежать дублирования информации решается в реляционных СУБД - РСУБД - это тоже весма нетривиальная задача, если только вы не хотите написать собственное ядро БД типа Jet или SQL
 
REM&gt;&gt; <SUP>(например в продуктах майкрософт мы создаем дублирующиеся записи постоянно - в аресной книге АутЛук, например... для каждого контакта я должен указать компанию в которой он работает - даже если в некоторой компании работает сто человек моих контактов, ее название я должен буду вностить все сто раз...)</SUP>
 

мне кажется можно найти разумную середину создав два классификатора (и два типа шаблонов) - "контрагенты частные лица" и "контрагенты юр. лица", копать глубже - это значит обречь себя на прорву неблагодарной работы...
 
что может быть критерием... пожелания пользователя... пусть они сами решают как оптимально разработать структуру хранения информации - мне кажется минимально достаточным будет дать простой инструмент...
 
Мне показалось - что не будет неоправдано сложным реализовать модель с шаблонами структура аттрибутов классификатора - мне кажется это может оказаться хорошим решением "малой кровью"
 
дерево классификатора можно строить по разным признакам...
 
напримерпо названию компании, по городу, по иному признаку,  
 
выбор структуры должен быть простым и понятным - как комбобокс - "построить дерево по:" и весь список аттрибутов классификатора - пусть например полей (в действительности записей) восемь-девять или два три...
 
например если в ходе работы с классификатором выясняется, что некоторое поле (аттрибут) излишнее - можно построить дерево по этому полю- и проверить в каких именно записях оно было использовано, затем отредактировать запись и легко удалить необязательный аттрибут
 
например в ходе работы с классификатором выясняется, что некоторый аттрибут обязателен для заполнения - например не так давно обязательным стало указание КПП в счете-фактуре... построив дерево по аттрибуту КПП можно выбрать записи где это поле не заполнено - и отредактировать такие записи.
 
Не напортачить бы...
свернуть/развернуть ветвь а если [Explorer 15/06/2005 11:53] # написать ответ
 
сделать что то вроде опции - "создать пустую копию"
 
например создав один раз набор признаков "компания" со вложеными атрибутами вроде тех, которые я описывал, пользователь потом сможет дублировать всю ветку - создать подобный же граф, только с незаполненым полем "примечание"
 
один раз описав компанию признаками
 
название-
расчетные счета+
валютный-
рублевые+
основной-
дополнительный-
адреса+
юридический-
фактический-
почтовый-
Контакты+
исполнительный персонал+
директор+
ФИО-
телефон-
Бухгалтер+
ФИО-
телефон-
технический персонал+
Должность+
ФИО-
телефон-
прочие контакты
 
пользователь получит набор записей формирующих подобную структуру
нажав кнопку "создать пустую копию &amp; "компания"
 
в дальнейшем он мог бы создать дополниетльные ветки вложенные в эту структуру, например
 
создав в существующей компании признак "филиал" он мог бы выбрать опцию "создать пустую копию &amp; компания" и получить аналогичную структуру для филиала подчиненную этой записи о компании, подредактировав ее:
 
выбросив лишние признаки о компании или добавив нужные признаки для филиала в дальнейшем он смог бы использовать "создать пустую копию &amp; филиал"
 
такая вот модернизация