| |
|
|
| | Требуется БД для складского учета. Еще клиент хочет чтобы наценку можно было фиксировать или нет, т.е. при фиксированной наценке ОтпускнаяЦена=ЗакупочнаяЦена*КоэфНаценки (следовательно при изменении закупочной цены ОтпускнаяЦенаТакже изменится); а при нефиксированной наценке должен измениться КоэфНаценки, а отпускная цена должна остаться прежней)
Как бы такое получше реализовать?
И основной вопрос - как лучше организовать данные?
Мне думается - в одной таблице - приход положительные числа, расход - отрицательные  | |
| |
| |
| |
|
|
| | можно и ещё колоночку добавить и в ней прямо писать приход
или расход. или другие слова и по ним потом при расчётах ориентироваться или запросом выбирать или формулой считать.
Может добавить табличку "Справочник наценок" и пусть сами пишут туда чё хотят 10%, 60% .... | |
| |
| |
| |
|
|
| | "Мне думается - в одной таблице - приход положительные числа, расход - отрицательные"
мне тоже думается что в одной таблице, но не с разным знаком, а с разным типом операции (отдельное поле)
А вот про наценки ... тут нужно подробнее, может ли у одного товара быть и фиксированная и не фиксированная наценка, как часто модет меняться наценка, для все товаров или только для конкретного (или группы), для одной единицы товара или для всех единиц данного товара, на одну операцию продажи или навсегда.... | |
| |
| |
| |
|
|
| | а если один товар, но от разных поставщиков?
в свое время извращался так: писалась отдельная процедура выбора продажи товара. (к примеру товар Х поставляют 2 поставщика А и В, но В более выгодные условия для магазина, соответственно сначала продается товар от В потом от А) | |
| |
| |
| |
|
|
| | "...а с разным типом операции (отдельное поле)" - а как потом карточку товара и прочее организовать - разные запросы, формы на прих и расх? ...
С наценками там алгоритм такой:
Получили заказ от заказчика на комплектующие, пошарились по поставщикам, нашли что нужно и выписали заказчику счет или "а'ля товарный чек" по принципу ЦенаДляЗаказчика=ПримернаяЦенаПоставщика*КоэфНаценки (коэф может меняться). Точная цена поставщика на данный момент не известна. Потом купили, оприходовали по факту, естественно поставили реальную цену. Должен измениться коэф., а ЦенаДляЗаказчика остаться прежней. Т.е. коэф. это одновременно и вычисляемое поле и НЕ вычисляемое. | |
| |
| |
| |
|
|
| | "...а с разным типом операции (отдельное поле)" - а как потом карточку товара и прочее организовать - разные запросы, формы на прих и расх? ...
Встречный вопрос.
А как вы собирались это делать с + и -?
Или вы хотели определение знака на пользователя возложить?
Не нужно разных форм, запросы конечно разные (как и в случае c + и -)
Просто появляется поле "знак операции", котороое определяет в какую сторону пошли товары (деньги) в + или в -
а вся остальная логикак такая же.
Что касается структуры. поскольку ЦенаДляЗаказчика величина постоянная после первого вычисления, я бы сохранил ее в заказе (счете заказчика) и потом от нее плясал, вычисляя коефф. т.е. есть коэфф к товару (это одно поле) и есть коэфф к этому товару в заказе (другое поле) | |
| |
| |
| |
|
|
| | 1. Я думал для ВВОДА данных сделать две формы отдельно для прихода и для расхода. В форме для расхода в поле количество сделать маску ввода чтобы минус сам подставлялся. А в карточке товара и т.п. суммировать поле Количество - и вот нам остаток.
2. Да, теперь все встало на свои места. | |
| |
| |
| |
|
|
| | http://silasoft.mall.su/view.php?cls=soft&lang=&guid=184
http://silasoft.mall.su/view.php?cls=soft&lang=&guid=178 | |
| |
| |
