Опять складские дела

← →
Ломброзо © (2006-10-24 22:42) [0]

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

← →
Sergey Masloff (2006-10-24 22:52) [1]

Хранить формуляр и состав отдельно?
Формуляр: дата мастер название
Состав
1 Стрижка 100 р
1.1 Мытье головы за счет заведения
1.2 Сушка феном 30 р
2 Расходные материалы 20 р
2.1 5 пшиков одеколона -
2.2 Затупились лезвия -
3 Прочее -
3.1 Клиент хамил - штраф 50 р

Редактируются отдельные позиции дерева. Где бесплатно составляющие но есть общая услуга - нолик у составляющих все вешается на корень.

Общая сумма ненулевых позиций поднимается в формуляр

← →
Sergey Masloff (2006-10-24 22:53) [2]

Ну ненаглыядно получилось формуляр это как-бы совсем отдельное и отдельно составляющие.

← →
Ломброзо © (2006-10-24 22:59) [3]

Аспасиба. Но вот момент:
> Общая сумма ненулевых позиций поднимается в формуляр
Номенклатурный справочник у меня поддерживает историю цен. Вот эта самая общая сумма должна храниться в базе данных и пересчитываться по факту изменения стоимости любой из составляющих, или допустимо сделать стоимость сложной услуги вычисляемым значением? Мне сдается, что первое.

← →
Sergey Masloff (2006-10-24 23:06) [4]

Ломброзо © (24.10.06 22:59) [3]
Нет зачем? У тебя есть справочник цен. Они поменялись. Ты мне что пришлешь доп. счет я стригся полгода назад.

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

Я далек от складов но у себя делаю примерно так.

← →
Наиль © (2006-10-24 23:07) [5]

Лучше делать поле "составной стоимости услуги" вычисляемой.
Пусть СостУслуга состоит из 100 примитивов.
Пусть цена каждого примитива меняется раз в месяц, тогда СостУслуга будет менятся в среднем три раза в день. Это не реальный пример, но всё таки.

Что касается интерфейса, то в докомпьютерную эру это выглядело так:
СостУслуга, в том числе ...

← →
Наиль © (2006-10-24 23:09) [6]

> "составной стоимости услуги"

читать как "стоимости составной услуги"

← →
Mike Kouzmine © (2006-10-24 23:23) [7]

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

← →
Ломброзо © (2006-10-24 23:57) [8]

Mike Kouzmine © (24.10.06 23:23) [7]

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

← →
Наиль © (2006-10-25 00:03) [9]

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

← →
Mike Kouzmine © (2006-10-25 00:03) [10]

Что значит в тихаря. Должен быть приказ руководства или утвержденный прайс. Должен быть ответственный за оперативные изменения. И всякий раз вычислять по текущему прайсу. Как в накладной. Услуга или товар, какая разница. Правда по услуге немного сложнее (если это не бытовая населению), но это тонкости.

← →
Наиль © (2006-10-25 00:06) [11]

Третий вариант плох тогда, когда состав сложной услуги может меняться.
В этом случае к истории цен, нужна будет история изменении состава сложной услуги.
Но даже в таком случае третий вариант лучше остальных.

← →
Mike Kouzmine © (2006-10-25 00:08) [12]

Наиль © (25.10.06 00:06) [11]
Третий вариант плох тогда, когда состав сложной услуги может меняться.

Она не может меняться. Сложная услуга - это растянутая на несколько отчетных периодов. Но там есть свои механизмы учета.

← →
Sergey Masloff (2006-10-25 06:30) [13]

Ломброзо © (24.10.06 23:57) [8]
Давай еще раз. Может все же я тебя не понял. Если разделить термины?

Назовем услугой то что получает клиент. Он это называет: я сходил в парикмахерскую (подстригся, оболванился...) Для него это одна услуга.

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

Есть справочник "элементарных" услуг.

Есть справочник цен за определенные услуги

А теперь мне непонятна цель (хотя "моя" система вроде без проблем их решает). Варианты.

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

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

3) Почти тоже самое что 2 но еще к шаблонам добавляется конструктор когда клиент может сам удалять-добавлять элементы - и смотреть как что подорожает подешевеет.

← →
Александр Иванов © (2006-10-25 07:53) [14]

> Ломброзо © (24.10.06 22:42)

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

Александр Иванов © (25.10.06 07:53) [14] Вы забыли добавить - вывоз мусора, покупка утенка для унитаза. Не надо доводить все до абсурда.

2 Ломброзо ©
ИМХО, "история цен" - совершенно бессмысленное понятие, если это учетная задача.
Максимум - должна быть текущая цена в справонике.
В учете существует история сделок (продаж. услуг), осуществленных по каким-то конкретным историческим ценам.
А история цен - это когда даже если сделок нет, то все равно всякое изменение цены записывается и хранится в виде истории именно цены в условиях отсутствия сделок.
Это может быть осмысленно в маркетологических задачах, но не в учетных. В учете нет такого факта как "измененная цена". Максимум, что может быть - это "прайс от такого-то числа" - отдельный документ, в котором перечислены все позиции, на которые вводилась новая цена, и автор такого прайса. Такой прайс можно распечатать торжестаенно и повесить на стену, а потом положить в ящичек и наслаждаться, если делать больше нечего. Хотя ппроще складывать в ящичек "текущий прайс". Зачем хранить все эти прайсы задним числом - я не знаю. Наверно для того чтобы еще больше склонить пользователя к безалаберности и дать ему еще одну взоможность запускать дела и вводить данные задним числом, этак три месяца спустя того, как произошли реальные события и так приперло, что дальше некуда.

> Mike Kouzmine © (25.10.06 09:56) [15]

Не понял, где там абсурд. Может и есть, но не вижу.
Мне показалось, что задача очень близка к задаче производственного учета. И, если это так, то в сети есть масса описаний реализации.

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

← →
VICTOR_ (2006-10-25 11:01) [19]

>>>2) Выдать злобное перудпреждение и повелеть администратору нажать специальную кнопку для пересчёта и проделать все те же манипуляции со старой и новой ценами

Дело в том, что клиент действительно оплачивает услуги по прайс-листу. То есть расчет на лету возможен только, если в прайс-лист НЕ включаются "сложные услуги".
Если же в прайс-лист включены и "сложные услуги", тогда при изменении стоимости "простой услуги" программа должна все аккуратно пересчитать, распечатать новые калькуляционные листы(сметы) и новый прайс-лист.

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

Формировать цены по текущим ценам из справочника,
но писать в базу по каждой сделке что заплачено конкретно по какой позиции - отпадает надобность в танцах с бубном с историей цен.

Опять складские дела Найти похожие ветки