|
|
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! У меня такие данные: Предприятие оказывает несколько видов услуг. На некоторые услуги оформляются заказы. Параллельно заказу может быть оформлен договор. Соответственно данные для договора берутся из заказа. Некоторые услуги оказываются только по договорам. Счета могут быть выставлены на основании договора или заказа. Как пример: в управлении есть нежилые помещения (НП), по которым заключен договор с собственником на обслуживание НП. По этим договорам ежемесячно оплачиваются счета. То есть имеем Клиент-Договор-Счет. Есть собственные НП, которые могут быть сданы в аренду. В этом случае оформляется заказ на аренду и оформляется договор на аренду. То есть - Клиент-Заказ-Договор-Счет. Иногда, аренда может быть без договора, т.е. Заказ-Счет. Счет получается либо по договору, либо по заказу. Схема никак не вырисовывается (прикладываю ее ниже). Обработка счетов мне кажется будет сложной. Например, чтобы вывести счета по заказу, нужно сначала сделать выборку счетов, где основанием являются заказы, потом объединить ее с выборкой счетов по договорам, относящимся к этому заказу... Может подскажете, как правильнее связи построить. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:03 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Можно попробовать упростить: 1. заказы считать договорами разового исполнения 2. состав услуг по договорам и по счетам выделить в отдельные таблицы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:19 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Naf2. состав услуг по договорам и по счетам выделить в отдельные таблицы Поясните, пожалуйста, что вы имеете в виду? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:27 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikK, Клиент ----> Заказ-Договор <---- Услуга - В услугах весь перечень - и обслуживание и аренда... - В клиентах и те кого обслуживаем и те кому сдаем в аренду (можно добавить признак арендатор или нет)... - В Заказ-Договор вся информация для заказа, договора и счета + возможно признак наличия договора... Собственно то, что и предложено в самом начале в другом форуме, ничего не изменилось по большому счету... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:33 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
vmag- В Заказ-Договор вся информация для заказа, договора и счета А есть идеи как такая сущность могла бы называться вместо Заказ-Договор? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:40 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
vmag- В услугах весь перечень - и обслуживание и аренда... Сразу дополняю возможные не понятки: в услуги тоже можно добавить признак что это такое и в формах с отчетами не выводить не нужные поля для заполнения или чтения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:40 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKА есть идеи как такая сущность могла бы называться вместо Заказ-Договор? куча_мала ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:41 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
vmagкуча_мала Не подходит, как тогда определить добавление элемента сущности - новая куча-мала? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:47 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
как два пальца об асфальт Клиент --> Заказ (у одного клиента много заказов) Заказ --> Договор (заказ может иметь договор, договор может иметь несколько заказов) Заказ --> Счет (заказ имеет один или несколько счетов, опционально можно добавить поле в Счет - идентификатор договора, не обязательное) Заказ --> Элемент заказа (заказ имеет один или несколько элементов, каждый элемент - это услуга, работа, товар, материал и т.п.) RodikKчтобы вывести счета по заказу Код: sql 1. 2. 3. 4. чтоб вывести счета по заказ и договору Код: sql 1. 2. 3. 4. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 11:47 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKкак тогда определить добавление элемента сущности - новая куча-мала? "Ещё одна сделка." Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 12:05 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77как два пальца об асфальт Да, не устану повторять, в том случае, если для собственника НП оформляем заказ на обслуживание НП, потом договор. А менеджеры привыкли оформлять Договор на обслуживание НП и никакого заказа. Если это обозвать Dimitry Sibiryakov...сделка то боюсь, меня тоже не поймут. Вообще по бизнес процессу удобно было бы организовать поиск по заказам и отдельно поиск по договорам. Потому что, в управлении есть гараж и есть разовые заказы на парковку, шиномонтаж и т.д. Ежемесячно проводится аналитика по договорам собственников, а текущая работа в основном с разовыми заказами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 12:35 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Набросал тут за полчаса на досуге. Код: plaintext 1. 2. 3. 4. 5. То есть приходит клиент с заявкой на услугу. Оператор создаёт заявку, в которой указывает требуется ли для данной заявки договор и заказ Если договор требуется, а его нет, то оператор создаёт договор, если требуется заказ - то заказ создаётся автоматически (ну может не сильно автоматически, ибо надо указать начало и завершение заказа, но это решается в интерфейсе) Счёт выписывается на заявку. Заявки сделал активными и неактивными, ибо как я понимаю от одного клиента не может быть несколько заявок по одной услуге одновременно, и при этом не знаю условий задачи, может ли клиент с действующим договором отказываться от услуги а затем заказывать её вновь. Ну и таблички СведенияпоуслугеХ вообще не понравились. Думается мне, что эти таблички можно сделать по религии EAV в виде трёх таблиц: Код: plaintext 1. 2. 3. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 12:38 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKбоюсь, меня тоже не поймут. Я тебе открою маленький секрет: формат хранения данных очень слабо связан с интерфейсом их редактирования. Хотят менеджеры договор отдельно от заказа - не проблема, сделай им два примерно одинаковых окна. А данные, что они введут - вали в одну таблицу и никому не говори как она называется. То, что не знаешь, тебя не беспокоит. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 12:41 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKв управлении есть гараж и есть разовые заказы на парковку, шиномонтаж и т.д. Ежемесячно проводится аналитика по договорам собственников, а текущая работа в основном с разовыми заказами. Это получается, что список объектов надо делать, какие услуги могут быть оказаны в объекте (вторая таблица), ибо проведение мойки автомобиля в офисе директора провести невозможно из-за отсутствия соответствующего оборудования и путей транспортировки. Ну а в заявку указывать в каком объекте она выполняется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 12:48 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, в добавление к описанию структура таблиц Код: plaintext 1. 2. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 12:51 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKв том случае, если для собственника НП оформляем заказ на обслуживание НП, потом договор. А менеджеры привыкли оформлять Договор на обслуживание НП и никакого заказа. ну так меняйте заголовок формы - в одном случае - это заказ, в другом - договор, а данные будете пихать по таблицам - так как надо и это будет скрыто от глаз юзера ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:00 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineТо есть приходит клиент с заявкой на услугу. Оператор создаёт заявку, в которой указывает требуется ли для данной заявки договор и заказ Если договор требуется, а его нет, то оператор создаёт договор, если требуется заказ - то заказ создаётся автоматически (ну может не сильно автоматически, ибо надо указать начало и завершение заказа, но это решается в интерфейсе) Счёт выписывается на заявку. Заявки сделал активными и неактивными, ибо как я понимаю от одного клиента не может быть несколько заявок по одной услуге одновременно, и при этом не знаю условий задачи, может ли клиент с действующим договором отказываться от услуги а затем заказывать её вновь. лишнее усложение и так непонятной ситуации, за отсутствием полной информации об автоматизируемом объекте пока что ясно, что нет никаких заявок, есть сразу либо договор, либо заказ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:03 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77, договор-то договором, а вот как понять, что клиенту надо, пока не пришёл и не заявил об этом? потому прежде всего идёт заявка на услугу, в уж потом разбираемся с договором есть он или придётся его создавать, распечатывать, подписывать :- ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:09 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineRodikKв управлении есть гараж и есть разовые заказы на парковку, шиномонтаж и т.д. Ежемесячно проводится аналитика по договорам собственников, а текущая работа в основном с разовыми заказами. Это получается, что список объектов надо делать, какие услуги могут быть оказаны в объекте (вторая таблица), ибо проведение мойки автомобиля в офисе директора провести невозможно из-за отсутствия соответствующего оборудования и путей транспортировки. Ну а в заявку указывать в каком объекте она выполняется. мдаа, вы вообще представляете себе процесс? стоит очередь, очередной клиент хочет мойку, оператору надо быстрее ему выписать заказ и послать в кассу, а тыкать сначала услугу, а потом место, где эта услуга будет выполнятся, а если случайно промахнешься - злая программа покажет красненькую надпись - "ты че дурак? мойку не делают в офисе директора", вы такой программой бизнес угробите, так как время ожидания в очереди возрастет в два-три-пять раз ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:12 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, ну а после договора смотрим требуется ли оформление заказа. И если требуется - оформляем. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:13 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine17-77, договор-то договором, а вот как понять, что клиенту надо, пока не пришёл и не заявил об этом? потому прежде всего идёт заявка на услугу, в уж потом разбираемся с договором есть он или придётся его создавать, распечатывать, подписывать :- ) эмм.... еще раз, стоит очередь, клиент орет - "хочу мойку, вот деньги", оператор тыкает большую кнопку "клиент хочет мойку", спрашивает фио, вводит, жмет ОК, из принтера вылезает бумажка, оператор посылает клиента с этой бумажкой в кассу, где тут заявка? и сколько времени надо убить на заявку, чтобы проставить все эти галки? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:15 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77Mr.Fontaineпропущено... Это получается, что список объектов надо делать, какие услуги могут быть оказаны в объекте (вторая таблица), ибо проведение мойки автомобиля в офисе директора провести невозможно из-за отсутствия соответствующего оборудования и путей транспортировки. Ну а в заявку указывать в каком объекте она выполняется. мдаа, вы вообще представляете себе процесс? стоит очередь, очередной клиент хочет мойку, оператору надо быстрее ему выписать заказ и послать в кассу, а тыкать сначала услугу, а потом место, где эта услуга будет выполнятся, а если случайно промахнешься - злая программа покажет красненькую надпись - "ты че дурак? мойку не делают в офисе директора", вы такой программой бизнес угробите, так как время ожидания в очереди возрастет в два-три-пять раз Уж сколько раз твердили миру - в общем случае интерфейс программы вообще никак не связан с тем, как хранятся в базе данные.Никак от слова "вообще". И по схеме данных пытаться судить о том, "возрастет ли время ожидания клиентов в очереди" -мягко говоря, смешно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:20 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77мдаа, вы вообще представляете себе процесс? стоит очередь, очередной клиент хочет мойку, оператору надо быстрее ему выписать заказ и послать в кассу, а тыкать сначала услугу, а потом место, где эта услуга будет выполнятся, а если случайно промахнешься - злая программа покажет красненькую надпись - "ты че дурак? мойку не делают в офисе директора", вы такой программой бизнес угробите, так как время ожидания в очереди возрастет в два-три-пять раз ну можно же указание места сделать необязательным. Сразу выписать заказ на мойку а клиент пусть сам бегает ищет где машину помыть в столовке или кабинете директора. Зато очередей не будет ни у оператора, ни в моечном отделении. P.S. Ну и в качестве оффтопа, как вы без указания места проведения завяки сможете посчитать сколько шиномонтажей было произведено гаражом №13? Тут конечно есть вариант, что сам работник 13-ого гаража будет указывать, по каким заказам он работал, но вот дело в том, что всё равно кто-то должен указать где была оказана услуга: либо оператор, либо работник гаража. С оператором оно проще, с работником веселее читать отчёты, а ну как к нему прибегут с заказом на уборку мусора. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:23 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, связь самая прямая: Mr.FontaineОператор создаёт заявку, в которой указывает требуется ли для данной заявки договор и заказ это означает, что надо показать форму заявки с полями ввода - это лишнее время => лишнее время в очереди => меньше клиентов => меньше денег => банкротство ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:23 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaineну можно же указание места сделать необязательным отлично, вы повысили свой уровень, теперь вопрос - зачем тогда вообще эти объекты и бизнес-правила, где какие услуги должны оказываться? Mr.FontaineP.S. Ну и в качестве оффтопа, как вы без указания места проведения завяки сможете посчитать сколько шиномонтажей было произведено гаражом №13? почему вы додумываете за заказчика программы, что ему надо? было такое требование в первом сообщении в этой теме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:27 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77Mr.Fontaine17-77, договор-то договором, а вот как понять, что клиенту надо, пока не пришёл и не заявил об этом? потому прежде всего идёт заявка на услугу, в уж потом разбираемся с договором есть он или придётся его создавать, распечатывать, подписывать :- ) эмм.... еще раз, стоит очередь, клиент орет - "хочу мойку, вот деньги", оператор тыкает большую кнопку "клиент хочет мойку", спрашивает фио, вводит, жмет ОК, из принтера вылезает бумажка, оператор посылает клиента с этой бумажкой в кассу, где тут заявка? и сколько времени надо убить на заявку, чтобы проставить все эти галки? Заявка вот тут 17-77клиент орет - "хочу мойку" P.S. 17-77оператор тыкает большую кнопку "клиент хочет мойку" А вы представляете сколько времени оператор будет искать её среди сотни таких же больших одинаково серых кнопок, да ещё расположенных на нескольких закладках в произвольном порядке? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:29 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77Mr.Fontaineну можно же указание места сделать необязательным отлично, вы повысили свой уровень, теперь вопрос - зачем тогда вообще эти объекты и бизнес-правила, где какие услуги должны оказываться? Mr.FontaineP.S. Ну и в качестве оффтопа, как вы без указания места проведения завяки сможете посчитать сколько шиномонтажей было произведено гаражом №13? почему вы додумываете за заказчика программы, что ему надо? было такое требование в первом сообщении в этой теме? Я конечно понимаю, что читать сообщения это лишняя трата времени, но у атора было далеко не в первом сообщении авторв управлении есть гараж и есть разовые заказы на парковку, шиномонтаж и т.д. Ежемесячно проводится аналитика по договорам собственников, а текущая работа в основном с разовыми заказами. Аналитику по работам в гараже №13 за месяц надо делать однако ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:32 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77Кот Матроскин, связь самая прямая: Mr.FontaineОператор создаёт заявку, в которой указывает требуется ли для данной заявки договор и заказ это означает, что надо показать форму заявки с полями ввода - это лишнее время => лишнее время в очереди => меньше клиентов => меньше денег => банкротство "Оператор указывает в заявке, требуется ли договор и заказ" - это уже как раз не схема данных, а описание интерфейса - и оно может быть кривым. А в базе сущности "заявка", "договор", "заказ", "платеж", "черт лысый" и т.п. - могут создаваться одним кликом мышки, по описанным заранее шаблонам. Может возникнуть вопрос "Для чего они тогда нужны?" - а для того, чтобы при изменении бизнес-процесса не надо было менять схему данных, и все отчеты, аналитика и т.п. остались актуальными. Что касается самой схемы - мне флаги "требуется договор", "требуется заказ" в заявке тоже кажутся излишними. Довольно очевидно, что требуется ли такой-то заявке договор - это компетенция не девочки оператора, а бизнес-аналитика, которому надо дать механизм указания "Для обладающих такими-то свойствами заявок нужно автоматически создавать договор". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 13:41 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин Что касается самой схемы - мне флаги "требуется договор", "требуется заказ" в заявке тоже кажутся излишними. Довольно очевидно, что требуется ли такой-то заявке договор - это компетенция не девочки оператора, а бизнес-аналитика, которому надо дать механизм указания "Для обладающих такими-то свойствами заявок нужно автоматически создавать договор". Ну вот по теме пошла критика. Объясню. Во-первых, у ТС в первом сообщении была фраза авторНа некоторые услуги оформляются заказы. Параллельно заказу может быть оформлен договор. Соответственно данные для договора берутся из заказа. Некоторые услуги оказываются только по договорам. Поэтому в таблице "Услуги" есть флаг "Требуется договор". Если этот флаг отмечен, то договор должен будет создаваться автоматически. Но как быть с услугой у которой нет такого флага? Тут конечно надо послушать автора топика по этому вопросу Я конечно фонтанировать своими фантазими засирая топик, например, поставить такой же флаг "Требуется договор" у конкретного клиента или клиентов разбить на группы и к группе привязать этот флаг, но опять же это больше к интерфейсу вопросы. Мне же флаги "требуется договор", "требуется заказ" в таблице заявки кажутся необходимыми, чтобы по их наличию/отсутствию искать информацию о договоре и заказе в соответствующих таблицах. Как они будут заполняться не столь важно. Главное их назначение - при наличии флага бежать в соответствующую таблицу с договорами и/или заказами для получения необходимой информации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:04 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineА вы представляете сколько времени оператор будет искать её среди сотни таких же больших одинаково серых кнопок, да ещё расположенных на нескольких закладках в произвольном порядке? И вот тут возникает резонный вопрос: какой идиот дал оператору мойки интерфейс с тучей левых кнопок и закладок? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:14 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Спасибо всем, участвующим в обсуждении. Про указание места пока не будем говорить, с этим вопросов не возникает. Что касается схемы, то Клиент-->Заявка_на_услуги-->Договор (как признак) и Заявка_на_услуги -->Счет выглядит вполне приемлемо и даже для менеджера звучит понятно. Но если Заявка_на_услуги содержит всю информацию тогда нет смысла в таблицах Договоры и Заказы. Если их не использовать нужно думать как разделить интерфейс менеджера на привычные "заказы" и "договоры". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:16 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Dimitry SibiryakovMr.FontaineА вы представляете сколько времени оператор будет искать её среди сотни таких же больших одинаково серых кнопок, да ещё расположенных на нескольких закладках в произвольном порядке? И вот тут возникает резонный вопрос: какой идиот дал оператору мойки интерфейс с тучей левых кнопок и закладок? Любитель больших кнопок не? да и не факт, кстати, что мойки. Из слов автора видно, что БД готовится для какого-то управления. Чем управляет эта организация, пока что не очень понятно. А когда непонятно чем занимаешься, вполне возможно с течением времени напридумывать под сотню различных услуг. И на каждую кнопочку. Но всё же хотелось бы по схеме БД разговарить :- ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:21 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine А когда непонятно чем занимаешься, вполне возможно с течением времени напридумывать под сотню различных услуг. И на каждую кнопочку Именно сейчас у нас так и происходит. Поэтому стоит задача упорядочить контроль на данном этапе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:25 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikK, если Вы о моей схеме, то там заявка содержит только информацию о клиенте, оказываемой услуге и необходимостью наличия договора и заказа. Никакой информации о договоре в заявке нет. Для того и существуют отдельные таблицы Заказы и Договоры, чтобы при наличии отметок о необходимости договора идти в таблицу договоров, а при необходимости оформления заказа - в таблицу заказов. То есть в моей схеме от этих таблиц отказаться никак нельзя. Или вы про какую схему? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:28 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineЗаявка вот тут 17-77клиент орет - "хочу мойку" зачем давать оператору заполнять дополнительные поля? и зачем сохранять в базу? если, грубо говоря, форма "заказа" и так означает, что надо создать заказ, а форма "договор" - создать и заказ и договор? Mr.FontaineP.S. А вы представляете сколько времени оператор будет искать её среди сотни таких же больших одинаково серых кнопок, да ещё расположенных на нескольких закладках в произвольном порядке? не надо показывать кучу кнопок, если комп стоит в гараже - то всего две (условно) - мойка, шиномонтаж, так как эти услуги оказываются там в 99% случаев Mr.FontaineАналитику по работам в гараже №13 за месяц надо делать однако прочитайте внимательней еще раз - там написано - аналитику по договорам и заказам, а не по объектам Кот Матроскин Может возникнуть вопрос "Для чего они тогда нужны?" - а для того, чтобы при изменении бизнес-процесса не надо было менять схему данных, и все отчеты, аналитика и т.п. остались актуальными. невозможно не менять схему БД при изменении бизнес-процесса, точнее в каких-то пределах можно, но тут уже вопрос к тому, насколько делать универсально сразу и сколько это потребует денег ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:34 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineКот Матроскин Что касается самой схемы - мне флаги "требуется договор", "требуется заказ" в заявке тоже кажутся излишними. Довольно очевидно, что требуется ли такой-то заявке договор - это компетенция не девочки оператора, а бизнес-аналитика, которому надо дать механизм указания "Для обладающих такими-то свойствами заявок нужно автоматически создавать договор". Ну вот по теме пошла критика. Объясню. Во-первых, у ТС в первом сообщении была фраза авторНа некоторые услуги оформляются заказы. Параллельно заказу может быть оформлен договор. Соответственно данные для договора берутся из заказа. Некоторые услуги оказываются только по договорам. Поэтому в таблице "Услуги" есть флаг "Требуется договор". Если этот флаг отмечен, то договор должен будет создаваться автоматически. Но как быть с услугой у которой нет такого флага? Тут конечно надо послушать автора топика по этому вопросу Я конечно фонтанировать своими фантазими засирая топик, например, поставить такой же флаг "Требуется договор" у конкретного клиента или клиентов разбить на группы и к группе привязать этот флаг, но опять же это больше к интерфейсу вопросы. Ну я бы не сказал что это вопросы к интерфейсу - но соглашусь с тем, что вопросы шаблонирования операций явно пока для ТС-а не очень актуальны, и с темой топика их лучше не путать Mr.FontaineМне же флаги "требуется договор", "требуется заказ" в таблице заявки кажутся необходимыми, чтобы по их наличию/отсутствию искать информацию о договоре и заказе в соответствующих таблицах. Как они будут заполняться не столь важно. Главное их назначение - при наличии флага бежать в соответствующую таблицу с договорами и/или заказами для получения необходимой информации. Это не очень хорошо, поскольку Вы дублируете информацию и, следовательно, напрашиваетесь на аномалии обновления - что будет, если договор удалили, а галочку не сняли? или наоборот, галочку не поставили, а договор создали? Сделать соединение по номеру заявки с таблицей договоров или заказов - недорогая операция, почему бы не делать ее в любом случае? И даже если Вы считаете ее дорогой - все равно имеет смысл построить эти флаги в виде вычисляемых полей, возложив проблему синхронизации на СУБД. Но в модели им делать нечего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:38 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Истина здесь: RodikKЧто касается схемы, то Клиент-->Заявка_на_услуги-->Договор (как признак) и Заявка_на_услуги -->Счет выглядит вполне приемлемо и даже для менеджера звучит понятно. Но если Заявка_на_услуги содержит всю информацию тогда нет смысла в таблицах Договоры и Заказы. Если их не использовать нужно думать как разделить интерфейс менеджера на привычные "заказы" и "договоры" . Если в Заявка_на_услуги есть вся информация, то остается только на просьбу клиента "Мне нужен договор" просто нажать кнопку "Печать Договора" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:40 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77, давайте про схему разговаривать. Интерфейс сейчас дело неактуальное. Ибо не надо тут фантазировать. И про то, что заказ создаётся в обоих случаях. В единственном прочитанном Вами первом сообщении и то написано, что некоторые услуги оказываются только по договорам (без создания заказов) и даже пример приведён. Трудно осмыслить что ли? Во-вторых, не надо фантазировать про количество кнопок и гараж. Опять же сам автор утверждает, что они могут заниматься хоть чем и количество в сотню услуг его не смущает. а по вашей версии с большой кнопкой "клмиент хочет мойку" придётся делать ещё кучу кнопок и про шиномонтаж и про уборку территории и про аренду помещений и прочие варианты, которые пока что не озвучены автором. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:44 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, свое решение я уже постил, и вам указал на то, что заявки - лишняя таблица, можно обойтись и без нее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:48 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинMr.FontaineМне же флаги "требуется договор", "требуется заказ" в таблице заявки кажутся необходимыми, чтобы по их наличию/отсутствию искать информацию о договоре и заказе в соответствующих таблицах. Как они будут заполняться не столь важно. Главное их назначение - при наличии флага бежать в соответствующую таблицу с договорами и/или заказами для получения необходимой информации. Это не очень хорошо, поскольку Вы дублируете информацию и, следовательно, напрашиваетесь на аномалии обновления - что будет, если договор удалили, а галочку не сняли? или наоборот, галочку не поставили, а договор создали? Сделать соединение по номеру заявки с таблицей договоров или заказов - недорогая операция, почему бы не делать ее в любом случае? И даже если Вы считаете ее дорогой - все равно имеет смысл построить эти флаги в виде вычисляемых полей, возложив проблему синхронизации на СУБД. Но в модели им делать нечего. Во-первых, информация не дублируется. Она указывает, какая информация требуется для выполнения заявки. Если в заявке стоит что договор необходим, а в таблице договоров у этого клиента по указанной в заявке услуге договора нет, то заявка не может быть выполнена, пока не будет создан договор. Соответственно по уже выполняемой или выполненной заявке нельзя позволять удаление договора. Соединение таблицы заявок с таблицами договоров и заказов надо делать всегда. Просто при наличии флагов в таблице заявок можно сделать вывод можно ли выполнить заявку. То есть если стоит флаг необходимости договора а в таблице договоров его нет, то сразу выдавать сообщение о невозможности выполнения заявки и требованием оформить с клиентом договор ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:55 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77Mr.Fontaine, свое решение я уже постил, и вам указал на то, что заявки - лишняя таблица, можно обойтись и без нее в своём решении вы ведёте все запросы через заказы, и не учитываете вариант, когда нет заказа. есть только договор. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 14:58 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaineв своём решении вы ведёте все запросы через заказы, и не учитываете вариант, когда нет заказа. есть только договор. Мля... ЕСТЬ ТОЛЬКО ИНФОРМАЦИЯ .... ПОЛНАЯ ИНФОРМАЦИЯ В ОДНОЙ ТАБЛИЦЕ и для договора и для счета и для заявки и для акта и для х()якта так зачем плодить еще эти доп суррогаты (таблицы договор, и т.д.) ??? Это путь через задне проходное отверстие, путь как в 1С: баба деду выдала мешок картошки за 100 рублей, значит нужны таблицы : Счет, Счет-фактура, Акт, Договор, Торг-12.... а нельзя сцуко все эти документы выдать всего из одной таблицы - "Баба деду выдала" ??? А потом квадратные глаза: них()ра се... пустая база торговля и склад 8.2 весит 1 Гиг..... ЗЫ..... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:12 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineКот Матроскинпропущено... Это не очень хорошо, поскольку Вы дублируете информацию и, следовательно, напрашиваетесь на аномалии обновления - что будет, если договор удалили, а галочку не сняли? или наоборот, галочку не поставили, а договор создали? Сделать соединение по номеру заявки с таблицей договоров или заказов - недорогая операция, почему бы не делать ее в любом случае? И даже если Вы считаете ее дорогой - все равно имеет смысл построить эти флаги в виде вычисляемых полей, возложив проблему синхронизации на СУБД. Но в модели им делать нечего. Во-первых, информация не дублируется. Она указывает, какая информация требуется для выполнения заявки. Если в заявке стоит что договор необходим, а в таблице договоров у этого клиента по указанной в заявке услуге договора нет, то заявка не может быть выполнена, пока не будет создан договор. При таком толковании у Вас нарушение 3НФ- в заявке атрибут "необходим договор" зависит от неключевого атрибута "ID услуги" (поскольку у услуги уже есть атрибут "необходим договор"). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:19 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaineв своём решении вы ведёте все запросы через заказы, и не учитываете вариант, когда нет заказа. есть только договор. как я уже рассказывал (в эту тему я переполз из другой темы автора, где все началось) - без заказа не будет заказчика, и заказ - это основная сущность, она есть всегда, даже если ее якобы нет заказ - это то, что будет выполнено, поставлено, продано при развитии системы на это будет завязываться куча других модулей (склад, зарплата и т.п.) и в моем решении - при создании договора без заказа - программа, автоматом создает заказ-по-шаблону, и крепит к нему договор на самом деле тоже самое можно сказать и про договор - насколько я знаю, в судах - факт оплаты считается как бы заключением договора по условиям ГК РФ, хотя самого договора может и не быть в виде бумажного носителя, т.е. счет (платежка) = договор и, следовательно, договор есть всегда а так получается - проще не ломать голову, а всегда создавать записи в таблицах договора и заказа, и не парить моск, надо - распечатают, не надо - не будут ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:24 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Если использовать Заявку_на_услуги, то со Счетами становится проще. Но непонятно как хранить сведения по заказу или договору, различающие в зависимости от услуги. К примеру, есть договор на обслуживание с собственником машино-места в гараже. То есть сделали заявку, что он "хочет" обслуживания, потом выдали ему договор на руки. В результате появилась запись в заявках, потом появилась запись в договорах и запись в сведении по договору по типу номера машино-места. Теперь начинаем оформлять заказы на аренду машино-мест. Машино-места в нашей собственности. Делаем заявку, оформляем заказ и далее нужен договор на аренду. И вот непонятно, как хранить номер машино-места. По идее первоначально указываем его в сведениях о заказе. Но в договоре оно тоже должно быть. По-моему получается опять не совсем правильно: Договор-->Заявка_на_услуги-->Заказ-->Сведения_по_услуге (номер ММ). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:38 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинMr.Fontaineпропущено... Во-первых, информация не дублируется. Она указывает, какая информация требуется для выполнения заявки. Если в заявке стоит что договор необходим, а в таблице договоров у этого клиента по указанной в заявке услуге договора нет, то заявка не может быть выполнена, пока не будет создан договор. При таком толковании у Вас нарушение 3НФ- в заявке атрибут "необходим договор" зависит от неключевого атрибута "ID услуги" (поскольку у услуги уже есть атрибут "необходим договор"). Ну запросто нарушение есть. Это возникло из-за неполного описания требований к наличию заказа и договора. Нет точного понимания может ли одна и также услуга в разных заявках иметь только заказ или заказ и договор. Ладно, удаляем эти столбцы из таблицы заявок. Они собственно только подразумевают проверку необходимости создания заказа и договора при оформлении заявки. Это не отражается на гланой проблеме топикстартера - выборке счетов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:38 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77, по вашей логике получается, что если клиент захочет в интерфейсе поиск по заказам, то он увидит вместе с заказами на аренду, заказы на обслуживание и получение э/э, к примеру. Или вы предлагаете дополнительно обрабатывать те заказы, которые клиент не должен видеть, потому что их как бы не существует? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:41 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Вот схема с Заявками_на_услуги ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:42 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
И опять же, по последней проблеме. Если создан заказ на аренду машино-места и он содержит начало и окончание, зачем дублировать это в договоре... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:44 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikK, если ты ждёшь ответов по моей схеме (а упоминаение слова "заявка" склоняет меня к этой мысли), то я завтра тебе отвечу. Ибо у нас тут ужо поздно малость. Темно однако. Ну а если рассматриваешь схему vmaga то может чего он тебе и ответит ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:50 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
17-77как я уже рассказывал (в эту тему я переполз из другой темы автора, где все началось) - без заказа не будет заказчика, и заказ - это основная сущность, она есть всегда, даже если ее якобы нет я это называю заявкой, а так-то дальше наши мысли неожиданно совпадают. До завтра ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 15:52 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKЕсли создан заказ на аренду машино-места и он содержит начало и окончание, зачем дублировать это в договоре... Например затем, что эта информация может отличаться. Заказали машиноместо на три года, но договор смогли составить только на два, поскольку третий год уже был занят. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 16:04 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine17-77как я уже рассказывал (в эту тему я переполз из другой темы автора, где все началось) - без заказа не будет заказчика, и заказ - это основная сущность, она есть всегда, даже если ее якобы нет Все верно, для нашей фирмы Заказ первичен. Договор это больше информация для клиента. Но появились в последнее время договора на обслуживание и прочие, которые не требуют заказов, а финансовый учет такой же как по заказам. Вот поэтому и пересматриваю структуру БД. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.09.2014, 16:18 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Всем здравствуйте! С вашего позволения вернусь к вчерашнему обсуждению. Mr.Fontaine, RodikKЕсли использовать Заявку_на_услуги, то со Счетами становится проще. Но непонятно как хранить сведения по заказу или договору, различающие в зависимости от услуги. К примеру, есть договор на обслуживание с собственником машино-места в гараже. То есть сделали заявку, что он "хочет" обслуживания, потом выдали ему договор на руки. В результате появилась запись в заявках, потом появилась запись в договорах и запись в сведении по договору по типу номера машино-места. Теперь начинаем оформлять заказы на аренду машино-мест. Машино-места в нашей собственности. Делаем заявку, оформляем заказ и далее нужен договор на аренду. И вот непонятно, как хранить номер машино-места. По идее первоначально указываем его в сведениях о заказе. Но в договоре оно тоже должно быть. По-моему получается опять не совсем правильно: Договор-->Заявка_на_услуги-->Заказ-->Сведения_по_услуге (номер ММ). что думаете про хранение сведений_об_услуге в таких обстоятельствах? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 09:18 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKСчет получается либо по договору, либо по заказу. Схема никак не вырисовывается (прикладываю ее ниже). Я не вижу тут вообще сколько-нибудь вменяемой схемы данных БД. последнюю схему также смотрел. Тебе видимо надо всё выбросить, и начасть сначала. Предварительно можно почитать какие-нибудь книжки на эту тему , типа учебников. Например, сведения по услуге №1 и 2. Во-первых, в БД не должно быть таких похожих таблиц, это должна быть одна таблица. Во-вторых, где там вообще собственно УСЛУГА, если это сведения по услуге ? RodikKОбработка счетов мне кажется будет сложной. При проектировании БД не думают об обработке. Обработка -- это алгоритмы работы с данными, а ты проктируешь структуру данных, она от её последующей обработки не зависит. RodikKМожет подскажете, как правильнее связи построить. Спасибо. Т.е. типа "нарисуй схему БД за меня". Не, я таким занимаюсь только профессионально, за деньги. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 10:01 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
MasterZiv, Названия таблиц и полей на данном этапе условные. В таблицах сведения_об_услуге должна хранится информация относящейся к конкретной услуге - например в аренде это будет номер помещения и стоимость аренды, к примеру, а для шиномонтажа - список выполненных операций (монтаж, балансировка и т.д.). За меня построить я ничего не прошу, только советов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 10:25 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
MasterZivПри проектировании БД не думают об обработке. Обработка -- это алгоритмы работы с данными, а ты проктируешь структуру данных, она от её последующей обработки не зависит. Говорите за себя, Портос, когда провозглашаете такие нелепости (с) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 11:23 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
RodikKВсем здравствуйте! С вашего позволения вернусь к вчерашнему обсуждению. Mr.Fontaine, RodikKЕсли использовать Заявку_на_услуги, то со Счетами становится проще. Но непонятно как хранить сведения по заказу или договору, различающие в зависимости от услуги. К примеру, есть договор на обслуживание с собственником машино-места в гараже. То есть сделали заявку, что он "хочет" обслуживания, потом выдали ему договор на руки. В результате появилась запись в заявках, потом появилась запись в договорах и запись в сведении по договору по типу номера машино-места. Теперь начинаем оформлять заказы на аренду машино-мест. Машино-места в нашей собственности. Делаем заявку, оформляем заказ и далее нужен договор на аренду. И вот непонятно, как хранить номер машино-места. По идее первоначально указываем его в сведениях о заказе. Но в договоре оно тоже должно быть. По-моему получается опять не совсем правильно: Договор-->Заявка_на_услуги-->Заказ-->Сведения_по_услуге (номер ММ). что думаете про хранение сведений_об_услуге в таких обстоятельствах? По-моему номер машиноместа надо привязать к Заявке, потому посмотри на таблицу Заявка_параметры. Там и храни номер машиноместа. Оно конечно придутся в таблицу Параметры занести строку "Номер машиноместа" и можно в отдельной таблице указать, что номер машиноместа используется для услуги "Аренда" и "Обслуживание". Но это только лишь для того, чтобы удобней было в интерфейсе смотреть не все имеющиеся в системе параметры, а только те, которые относятся к данной услуге Запросы будут элементарные. Например, список всех машиномест с указанием кто занимает и какой услугой пользуются Код: sql 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 11:48 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine, хотя я в запросе с inner join малость поторопился. Если нет заказа, то ничего и не появится. Убрать надо inner join ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 11:51 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.Fontaine Код: plaintext 1. 2. 3. Некоторые параметры требуют выбор значения. Можно сделать отдельно табличку по значениям, но если к примеру, параметр код помещения должен иметь два столбца - код и номер помещения, т.е. значение параметра будет код помещения, но для менеджера виден номер. Не получается такое сделать, это возможно при такой схеме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 13:19 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
[quot RodikK]Mr.FontaineНекоторые параметры требуют выбор значения. Можно сделать отдельно табличку по значениям, но если к примеру, параметр код помещения должен иметь два столбца - код и номер помещения, т.е. значение параметра будет код помещения, но для менеджера виден номер. Не получается такое сделать, это возможно при такой схеме? Не получится. Параметрами могут быть только простые значения. Чтобы подцеплять справочники, которые надо хранить в отдельных таблицах проще коды из этих справочников сразу в таблицу заявки, договоров или заказов запихивать, смотря к чему их требуется отнести. Например, вчера я описывал возможность добавления в таблицу заявок поля id_Объект. То есть таблица объектов - это справочник по объектам, а в таблице заявки храним id этого объекта. Тогда в таблице параметров заявки это значение хранить не надо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 14:26 |
|
||
|
Не получается структура БД
|
|||
|---|---|---|---|
|
#18+
Mr.FontaineRodikKпропущено... Не получится. Параметрами могут быть только простые значения. Несложно доработать схему, чтобы в параметры можно было запихивать и справочники - другой вопрос что система становится монструозной и плохоуправляемой. Правильнее все множество параметров как-то формализовать в четкий набор атрибутов (например, обьект, действие, период ) и действительно держать их прямо в заявке. Обьект - машиноместо №16, действие - аренда, период - с 01.01. по 01.02. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2014, 14:53 |
|
||
|
|
start [/forum/search_topic.php?author=%D0%A1%D1%82%D1%80%D0%BE%D0%BC%D0%BF%D1%80%D1%81%D1%82%D0%B5%D0%BD&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
get settings: |
8ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
56ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
114ms |
get tp. blocked users: |
1ms |
| others: | 661ms |
| total: | 894ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
