Xpoint
   [напомнить пароль]

Разделение объектов управления

Метки: [без меток]
2005-09-25 06:09:28 [обр] kuglik[досье]

Доброе время суток всем. Т.к. я здесь впервые, то не уверен, что выбрал правильный раздел форума. Ежели не туда, то заранее приношу свои извинения.

Я зациклился в таком вот вопросе: Имеется БД какого-то там учёта. Получилось так что БД обслуживает как бы две фирмы. На самом деле обе принадлежат одному и тому же юр.лицу. Поначалу и расчётный счёт был общим. Профили у фирм разные, но всё же клиентские базы могут перекрываться. Т.е., например, один и тот же клиент может являться для одной фирмы поставщиком, а для другой клиентом. Кстати, как будет правильно назвать совокупность клиенты/поставщики/прочие, а то сейчас в меню общем Клиенты подпункт Клиенты, что несколько странно.

Назрела необходимость как-то, может быть не физически, а, и желательно, программно, разделить эти две фирмы. Физически не хочу разделять по причине общего счёта. Бухгалтеры должны видеть общее состояние счёта.

Оператор работающий только с фирмой 1 в принципе не должен видеть клиентов другой фирмы, он вообще может не знать о существовании второй. То же самое по отношению к операторам второй фирмы. Кроме того есть операторы с повышенными полномочиями: могут видеть и тех и других. Проблема возникает когда один из "ограниченных" операторов заводит нового клиента который уже является клиентом другой фирмы. Т.к. он ни сном, ни духом о второй фирме, то получается дублирование данных. Можно ограничить полномочия на добавление нового клиента, но это вызовет другие, уже организационые, проблемы: для занесения нового клиента нужно будет постоянно дёргать полномочного оператора, а он может находиться совсем не близко. Теряется оперативность.

Надо ли выделять самостоятельные фирмы вплоть до введения спец. поля FirmId или как-то сгруппировать? Или просто управлять доступом через настройки прав операторов? Если группировать, то стоит ли вводить иерархию? Например, Фирма1-->Поставщики; Фирма1-->Клиенты; Фирма2-->Поставщики и т.д. Как в такой иерархии предлагать выбор клиента при оформлении, например, заказа полномочным оператором (который имеет доступ к обеим фирмам)? Всех Клиентов обоих фирм сваливать в один список или сначала выбор фирмы? В общем вопросов пока море. Кроме того, прочитав тему lance10t "Пишу CMS (мысли вслух, концепции, идеи, решения)" понял насколько я за годы спокойной работы, даже в той же области, отстал от жизни.

Как правильнее поступить в этой ситуации? Может есть пример для подражания?

P.S.: Эта БД досталась мне в "наследство". Абсолютно не структурирована. Данных навалено, именно навалено, аж с 2000 года. Пока даже не знаю с какого конца за неё браться. Опыта полностью самостоятельной разработки проекта не имею. Программистом в команде работал несколько лет, но это совсем другой опыт. А тут нужен опыт именно архитектурных (или как они называются? с терминологией пока тоже не освоился) решений.
И на всякий случай: БД на Access, web-интерфейс на JScript-ASP

P.P.S.: Всё же не дают покоя все эти группировки с иерархией и без, с зацикливанием и т.п. Всё время кручусь вокруг них, но никак не найду точки отсчёта или опоры.

спустя 5 часов [обр] Александр aka Efreeti(3/111)[досье]
Толково спроектировать новую БД и скриптом перегнать туда данные из Access. С ней и работать.
Это более провильный вариант, но требует бОльших трудозатрат, чем латание текущей БД.
спустя 1 час 17 минут [обр] kuglik[досье]
Александр aka Efreeti[досье] Возможно в перспективе так и будет, но результаты нужны уже вчера :). И в любом случае, принятие решения о перепроектировании не отменяет вопроса. Там тоже небходимо определиться, как в итоге хранить данные. Разделить совсем или всё же попытаться как-то унифицировать работу с ними.
спустя 1 час 50 минут [обр] Старынин Валерий(0/57)[досье]
Есть такой термин - "Контрагенты".
А при добавлении нового контрагента надо запрашивать имя, к примеру, потом искать по всем доступным и предлагать. Или просто дать возможность посмотреть на всех и выбрать. И хранить таблицу, указывающую доступных для каждой фирмы (ID, ContrID, FirmID). Хотя можно у каждого завести по 2 поля, и ставить там флаги принадлежности.
спустя 43 минуты [обр] glebushka(0/3)[досье]

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

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

Короткое замечание по поводу проверки существования контрагента по имени.
Так делать нельзя. Юзер может написать:

  1. "Рога и копыта"
  2. Рога и копыта
  3. Рога и Копыта
  4. ОАО Рога и копыта
  5. ОАО "Рога и копыта"
  6. ну и т.д. какие только вариации не встриечаются.

Нужно давать юезрам возможность просматривать полный список. Иначе будут дубли.

спустя 8 минут [обр] kuglik[досье]

Старынин Валерий[досье]Спасибо за термин.

И хранить таблицу, указывающую доступных для каждой фирмы (ID, ContrID, FirmID).

Ну это-то понятно, и это есть. Вопрос следующий: контрагент может выступать как поставщик для одной фирмы и как клиент для другой, так и в комбинации - клиент обеих + поставщик для вторй и т.п. Таблица контрагент-тип контрагента это дело связывает, но пока без привязки к фирме. Т.е. можно выбрать всех контрагент-клиентов или контрагент-поставщиков, или контрагент-прочие и т.д. Теперь связываем контрагент с фирмой. При выборе, например, поставщика у нас есть инфа, что контрагент является поставщиком и принадлежитт обеим фирмам. Как отсюда определить для какой фирмы он является поставщиком? Никак. Или для ф1 он поставщик, для ф2 - клиент, полномочный оператор видит пересечение этих множеств. Определить для какой из фирм он поставщик, а для какой клиент невозможно. Нужна доп. инф. Например новые категории, Фирма1-поставщик, Фирма2-поставщик, что есть не красиво и не нормализовано.

спустя 12 минут [обр] kuglik[досье]

glebushka[досье]

kuglik, рекомендовал бы ознакомиться с 1С:Управление торговлей 8.0

Спасибо, ознакомляюсь.

Пока учёт в рамках договора не актуален, точнее актуален, но не сейчас. Тут бы хоть чуточку разгрести.

Нужно давать юезрам возможность просматривать полный список

Не хочет работодатель показывать всех своих клиентов временным работникам, практикантам и т.п., но которые в то же время активно работают с клиентами. Конкуренция :(

спустя 3 часа 41 минуту [обр] glebushka(0/3)[досье]
kuglik[досье], тогда в вашем случае нужно точнее описать задачу. Иначе подсказать ничего невозможно. Если не нужно показывать весь список, логично предположить что каждый работник работает только со "своими" контрагентами", в этом случае храните для каждого из контрагентов список "отвественных менеджеров". И показывайте данного контрагента только им.
Подумайте как часто происходит добавление нового контрагента. Если не часто - возложите эту задачу на тех меенеджеров, которые видят весь список.
Про договора - я не говорю, что там должен реализован быть полный функционал.
Создайте два вида договоров в системе: "с покупателем", "с поставщиком". В каждом договоре три поля: Наименование, Ссылка на контрагента (с которым заключён данный договор), Ссылка на вашу фирму (одну из ваших фирм, которые вы ведёте в одной базе).
А далее будет очень просто понять кем выступает данный контрагент для каждой из фирм, посмотрев на созданные договоры.
Этот механизм, кстати, гораздо легче объяснить пользователем, чем всякие галочки и пересечения множеств:) Есть договор данной фирмы с данным контрагентом с типом "покупатель". Значит контрагент - покупатель. Нет - значит не покупатель:)
спустя 4 часа 26 минут [обр] Старынин Валерий(0/57)[досье]
glebushka[досье] Я про имя для примера. Лучше дать просто список с возможностью добавить себе кого-то из ранее созданных.
И еще. Делать общий список и покупателей и продавцов в кучу - неудобно для оператора. Но я не вижу проблемы в том, чтобы ввести поля Ф1-прод., Ф1-пок., Ф2-прод., Ф2-пок. Это разные признаки, ничего плохого в этом нет.
спустя 4 часа 3 минуты [обр] glebushka(0/3)[досье]

Старынин Валерий[досье], ну общий список контрагентов зачастую бывает нужен (пример: юзеру абсолютно наплевать, покупатель или поставщик контрагент, он просто хочет посмотреть контактную инфу конретной фирмы).

 не вижу проблемы в том, чтобы ввести поля

Ну появится Ф3...

спустя 6 часов [обр] Старынин Валерий(0/57)[досье]
Общий список - пожалуйста, отдельная команда на выбор всего. Но это бывает реже, чем при заполнении договора, а там - только отдельно. Но ведь проблем-то нет.
Что есть Ф3?
спустя 13 часов [обр] glebushka(0/3)[досье]
 Что есть Ф3?
 ввести поля Ф1-прод., Ф1-пок., Ф2-прод., Ф2-пок
спустя 1 час 2 минуты [обр] kuglik[досье]

glebushka[досье]Старынин Валерий[досье] Спасибо за участие.

С добавлением, точнее с дубликатами пока не разобрался, а с группировкой вроде бы наметилось решение. Собственно группировкой будет заниматься манагер, а вот при выборе оператором сделал быстрый поиск по подстроке с выводом в выпадающий список. Теперь не нужно помнить все номера контрагентов или искать в списке из более чем 4000 позиций. При вводе "Рога" будут показаны все варианты из списка выше с номерами и городами, так что ошибиться при выборе будет тяжело. А уж кем он является клиентом или поставщиком этом случае уже не важно. Это для всяких там отчётов и, может быть, если не найдут в поле поиска, группировка при выборе из списка.

По поводу пересечения контрагентов ф1 и ф2: я склонен их всё же разделить, т.к., исследовав БД, заметил, что с одним и тем же контрагентом ф1 контактирует с теми кто занимается рекламой, а ф2 - товарами. Поэтому контактные лица почти всегда разные, т.е. можно считать, что и контрагенты разные.

По поводу новых клиентов мысль такая: как правило неполномочные операторы не имеют права составлять новые договора и пр. док. А вот найти нового клиента могут, например по газете. При добавлении быстрый поиск поможет избавиться от дубликатов, а если такой контрагент есть, но не доступен для данного оператора, то тоже ничего страшного. Пусть спокойно вносит новых, а они будут сваливаться в группу "новые". Позже манагер сможет их раскидать по нужным группам и проверить на дубликаты. Такая вот идея. Будут возражения, поправки?

спустя 20 минут [обр] Старынин Валерий(0/57)[досье]
glebushka[досье] Ф3 - новое поле будет. Как новый признак. А можно таблицу завести, и там хранить пары Фирма-контрагент, возможно дополняя их типом отношений, но это вроде бы стало ненужно.
kuglik[досье] С новыми проблем не будет. Только если Вы нового объявляете копией старого, то его ID везде меняется на другой. Это необратимо. Учтите. Да и надо помнить, гле менять. А так ничего, хорошая идея.
спустя 1 день 22 часа [обр] glebushka(0/3)[досье]
kuglik[досье], по выпадающему списку - неплохая мысль. Главное протестировать на предполагаемых объёмах и нагрузке (количестве одновременно работающих операторв) чтоб не тормозило.
По поводу того, что одного и того же контрагента считать разными и вносить дважды в базу - категорически не согласен. Правда, я вообще поклонник всяких модных црм-штучек, поэтому мнение моё субъективно. Но я пока не встречал ни одной фирмы, у которой бы хоть раз возникли проблемы от слишком полной инфы о контрагенте, а вот обратных ситуаций, когда есть контрагент, но не знают кто там за что отвечает, с кем связаться по тому или иному вопросу - море (причём инфа как таковая уже попадала на фирму - просто сотрудник который занимался этим вопросом в прошлый раз в командировке, в отпуске, заболел, уволился - нужное подчеркнуть). А контактное лицо нужно прямо здесь и сейчас.
И если уж есть централизованная база данных. То в неё нужно собирать как можно больше инфы. По каждому контрагенту. Любую инфу - в идеале регистрировать все контакты менеджеров: вид контакта, время, тема, итог. Вообще полезно накапливать любую даже самую отрывочную инфу начиная от телефонов и заканчивая кличкой любимой собаки руководителя:) (шучу конечно, хотя если и вправду такая инфа будет занесена, то точно никому хуже не будет - авось зачем-нибудь сгодится). Всё это конечно очень сильно зависит от вида бизнеса.
Но своими же руками ухудшать качество данных о своих контрагентах - просто глупо. ИМХО, разумеется.
спустя 11 часов [обр] kuglik[досье]

glebushka[досье]

чтоб не тормозило

Пока не тормозит. Как будет дальше - посмотрим.

категорически не согласен

Мне тоже не очень нравится, но пока не вижу приемлемого решения.

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

Тот же вопрос и по поводу изменения названия продукции. В старых счетах это тоже отразится. Как быть?

спустя 5 дней [обр] glebushka(0/3)[досье]
kuglik[досье], единственный способ отслеживать изменения того или иного реквизита - это сделать его периодическим и хранить с привязкой к конкретной дате. С адресом, банковским счётом и прочим - другая история. Необходимо давать возможность пользователю вводить несколько банковских счетов для контрагента. Ну, и например, указывать конкретный счёт как основной. Чтобы автоматически подставлялся в документе. Тогда со сменой счёта проблем не возникнет.
При изменении названия продукции как раз лучше создавать просто новую позицию, а не хранить историю изменений.
Существование одной и той же организации в двух экземплярах не допустимо. Если бы я был менеджером вашего проекта. То я бы сделал всё чтобы убедить клиента отказаться от этой дури. Если б не получилось, накатал бы на страничку аргументов, почему этого не стоит делать, и что исполнитель категорически возражает против такого солюшена. И заставил бы клиента подписаться, что он ознакомился и настаивает на своём. Эта бумага вам поможет, когда возникнут проблему и начнуться поиски крайнего. А проблемы возникнут. Обязательно. У меня есть некоторый опыт, и развился нюх на подобные вещи:)
ЗЫ. Как я понял Управление торговлей 1С вы смотреть не стали. Зря. Все вопросы ваши снимутся внимательным изучением данной конфы.
спустя 16 часов [обр] kuglik[досье]

glebushka[досье]Извиняюсь за так некстати навалившийся грипп. Надо бы ответить, а сил нет. Подождите, пожалуйста, пару дней.

Управление торговлей 1С вы смотреть не стали. Зря

То, что есть по этому вопросу в интернете (не всё, конечно), я смотрел. К сожалению пощупать его "живьём" нет возможности. Я не в России. Или есть какие-нибудь демо версии?

спустя 7 часов [обр] glebushka(0/3)[досье]

kuglik[досье], демо верий не бывает. А щупать в вашем случае обязательно нужно вживую. Большиство (если не все) ваши вопросы в 1С решили. Просто в рекламных описаниях и даже описаниях для пользователей вы этой инфы не найдёте. Ведь пользователям не важно, как решается проблема в программе, главное чтобы она была решена.
В странах СНГ и Балтии в принципе есть достаточно много фирм франчайзи, так что можете попробовать найти через знакомых. Пригласите знакомого на (пиво,чай с коньяком, нужное подчеркнуть:)) к себе в офис с ключом защиты, и посмотрите конфу. Самое правильное решение.
Ну и наконец народные умельцы научились эмулировать ключ защиты платформы 1С:8.0 Правда это:

  1. не законно
  2. гарантированно устаревшая версия платформы
  3. постоянно будете "вылетать" из программы

Может сейчас положение чуть изменилась, я лично этими вопросами не очень интересуюсь. Но в принципе, поимев немного геммороя с поиском кряков вы сможете посмотреть что представляет из себя программа.
Хотя вариант с поиском знакомого из фирмы франчайзи 1С гораздо лучше и с практической, и с морально-эстетической точек зрения.

спустя 9 часов [обр] Алексей Севрюков(2/1280)[досье]
glebushka[досье] На этом форуме запрещено обсуждать кряки, взлом софта и т.д. Запрещено напрочь, даже для якобы "благих" целей.
спустя 11 часов [обр] glebushka(0/3)[досье]
Алексей Севрюков[досье], сорри. Просьба к модератору отредактировать моё сообщение, убрав всё, начиная со второго абзаца.
спустя 4 дня [обр] kuglik[досье]

glebushka[досье]

демо верий не бывает

Жаль

А щупать в вашем случае обязательно нужно вживую

К сожалению не получится. Все выше изложенные способы не подходят. Буду изобретать велосипед.

Кстати, чем вживую лучше? Какая там БД? Неужели открытый формат? Или Вы имеете в виду, просто поэкпериментировав, предположить как там этот механизм реализован?

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

спустя 2 дня 7 часов [обр] glebushka(0/3)[досье]
 Неужели открытый формат?
Не знаю, что вы подразумеваете под форматом, а вот исходный код конфигурации действительно открыт (только не путайте конфигурацию и платформу).
Но на большинство своих вопросов вы найдёте ответы простым эксперементированием.
Powered by POEM™ Engine Copyright © 2002-2005