|
|
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Доброго. За неимением опыта стою у развилки ... подтолкните, пжлст. Таблицы: АУКЦИОН ID УЧАСТНИКИ Аукцион_ID Сумма Нужно сделать проводку на ОБЩУЮ сумму участников аукциона. Расчитывается она просто (select sum(уч.сумма) from участники уч where уч.аукцион_ID = :A) НО! В исключительных случаях эта сумма должна быть другой (добавляется ручная коррекция). Нужно знать: сумма "нормальная" или "подкручена ручками" Нужно знать, была ли сформирована эта проводка или нет, дабы "заморозить" участников аукциона. (+ возможность отмены формирования доков) Вариант первый: Добавляем в АУКЦИОН поля сумма (перерасчитываем при каждом изменении участников) ручная_корр. (Если флаг стоит, то сумма была поставлена руками - перерасчет игнорируем. При снятии флага наново расчитываем сумму) выгружено (теперь изменение участников запрещено) При каждом изменении/редактировании участников Смотрим на эти флаги, принимаем решение, добавлять или нет, перерасчитываем общую сумму и т.д. Вариант второй: Добавляем поля корр_сумма (если NULL - нужно рассчитать "нормальную сумму", при необходимости. Иначе - была ручная коррекция, её сумма перед Вами) выгружено (стоит флаг - всё и всех морозим) Участников в каждом аукционе ожидается около сотни. Или есть более красивый вариант? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 17:12 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Gordeev_Andry Или есть более красивый вариант? Правильней второй вариант, но не совсем так... А примерно вот так: Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.05.2009, 20:34 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Роман Дынник, Соглашусь - так правильнее и практичней. Еще могу добавить, что если перспективы развития таких "корректировок" туманны, то можно вынести их в отдельную таблицу и завести справочник "видов корректировок", где будут указываться причины корректировки. Тогда на одну расчитанную сумму можно вносить много корректировок, разбивая их на причины, с комментариями. Таким образом, расчитанные суммы останутся такими, какими они были расчитанны. Но возникает другая проблемма - при перерасчете, если новая расчитанная сумма другая, то необходимо стирать все корректировки, или корректировать их на сумму разницы сторого расчета и нового... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 09:19 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Мы ведем у себя 2 поля - "расчет" и "факт" и затем в зависимости что необходимо используем то или иное поле ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 16:08 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
AlkatrazРоман Дынник, Соглашусь - так правильнее и практичней. Еще могу добавить, что если перспективы развития таких "корректировок" туманны, то можно вынести их в отдельную таблицу и завести справочник "видов корректировок", где будут указываться причины корректировки. Тогда на одну расчитанную сумму можно вносить много корректировок, разбивая их на причины, с комментариями. Таким образом, расчитанные суммы останутся такими, какими они были расчитанны. Но возникает другая проблемма - при перерасчете, если новая расчитанная сумма другая, то необходимо стирать все корректировки, или корректировать их на сумму разницы сторого расчета и нового... тогда может УЧАСТНИКИ Аукцион_ID Сумма Тип_ID ТИПЫСУММ ID ...(можно и Parent_ID ) где ID =1 Это "нормальная" 2- "подкручена ручками" 3- .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 16:17 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
ветерочек тогда может УЧАСТНИКИ Аукцион_ID Сумма Тип_ID ТИПЫСУММ ID ...(можно и Parent_ID ) где ID =1 Это "нормальная" 2- "подкручена ручками" 3- .... Не рекомендую - в случае, если справочник типа суммы задается пользователем, то придется резервировать код, кроме того эта таблица будет редактируемой и надо будет запрещать редактирование соответствующих записей. По моему опыту надо разделять данные генерируемые системой и данные, вводимые пользователями. Таким образом есть гарантия, что расчетные данные на будут затронуты пользовательским вводом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 16:34 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Alkatrazветерочек тогда может УЧАСТНИКИ Аукцион_ID Сумма Тип_ID ТИПЫСУММ ID ...(можно и Parent_ID ) где ID =1 Это "нормальная" 2- "подкручена ручками" 3- .... Не рекомендую - в случае, если справочник типа суммы задается пользователем, то придется резервировать код, кроме того эта таблица будет редактируемой и надо будет запрещать редактирование соответствующих записей. По моему опыту надо разделять данные генерируемые системой и данные, вводимые пользователями. Таким образом есть гарантия, что расчетные данные на будут затронуты пользовательским вводом. ИМХО чем проще тем лучше , я бы лучше этот контроль вывел бы на приложение (просто не выводить где ID =1) накладных расходов меньше ,да и к этому справочнику доступ должен быть мало у кого, а если пользователь может влезать в таблицы то тут уже ничего не поможет :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 16:53 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
ветерочек ИМХО чем проще тем лучше , я бы лучше этот контроль вывел бы на приложение (просто не выводить где ID =1) накладных расходов меньше ,да и к этому справочнику доступ должен быть мало у кого, а если пользователь может влезать в таблицы то тут уже ничего не поможет :) Тогда вам проще в самом деле сделать еще одно поле в расчетной таблице и применить вышеописаный метод получения итоговой суммы, предложенный Романом. Серьезно - не рекомендую делать так, как вы предлагаете - возможности доработки минимальные, а головной боли не оберетесь потом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 17:08 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
spМы ведем у себя 2 поля - "расчет" и "факт" и затем в зависимости что необходимо используем то или иное поле Я так понимаю, что реальное поле "расчет" стоит заводить, если его расчет ресурсоёмкий, иначе обходимся вічислением "на ходу"? Верно? Alkatraz Но возникает другая проблемма - при перерасчете, если новая расчитанная сумма другая, то необходимо стирать все корректировки, или корректировать их на сумму разницы сторого расчета и нового... Думал над этим тоже. Озадачил юзеров ... они в шоке :-) Пока приняли вариант Романа Дыника. От Ваших (Alkatraz) слов возьму простое логирование изменения корректировок .. чтобы потом крайнего легче искать было. Прочитал всех ... теперь сижу и думаю о расчетной сумме... в принципе, она вычисляется просто и быстро. Наверно, больше возни будет в триггерах на таблицу участников, дабы поддерживать актуальность аукцион.сумма :) Пока такое решение: остановлюсь на варианте Романа Добавлю поле аукцион.сумма_коррекции (тут только дельта, изменение этого поля логируем с комментами) в вьюшке, с которой будет приложение работать, выложу три поля расчетная_сумма корректровка итоговаяа_сумма Если есть веские "против" - прошу :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2009, 19:25 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Gordeev_Andry AlkatrazНо возникает другая проблемма - при перерасчете, если новая расчитанная сумма другая, то необходимо стирать все корректировки, или корректировать их на сумму разницы сторого расчета и нового... Думал над этим тоже. Озадачил юзеров ... они в шоке :-) Здесь путаница в схеме документооборота. Есть один поток информации - реальные суммы участников, и из них - реальная сумма аукциона. Второй, независимый от него поток - корректировки, и отфонарная сумма аукциона. И вместе эти стрелки сходятся в некую откорректированную сумму аукциона. Организовать в БД это все тривиально. Но нет ответов по организационному разруливанию двух стрелок, приходящих в один квадрат: Вводятся ли корректировка как готовая сумма аукциона, на которую по-любому нужно выйти, или это просто дельты, вроде фиксированных или процентных скидок отдельным VIP-участникам? Или ситуации бывают и такие и другие? Что делать, если после введения корректировок обновились реальные суммы участников? Другими словами, есть ли на схеме зависимостей стрелка от реальных сумм участников к корректировкам? Забудьте про базы данных и компьютеры, дайте ответ в терминах бумажного делопроизводства 19 века. И вообще, когда я в БД слышу термин "коррекция", то чаще всего это означает некую область, не проработанную на этапе постановки задачи, и причиняющую основную головную боль в процессе эксплуатации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2009, 09:16 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Cane Cat Fisher И вообще, когда я в БД слышу термин "коррекция", то чаще всего это означает некую область, не проработанную на этапе постановки задачи, и причиняющую основную головную боль в процессе эксплуатации. В моем случае коррекции нужны для "вот тут подкрутим копейку, а тут две и выйдем на то, что сверху спустили". В основном, эти копейки вылазят из-за дробных коэффициентов в расчетах и необходимости выйти на фиксированные итоговые суммы. От автоматического "выравнивания" копеек юзеры отказались. Так-что в моем случае вариант Романа мне кажется более оптимальным, чем мои. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2009, 14:19 |
|
||
|
Автоматический расчет и ручная коррекция
|
|||
|---|---|---|---|
|
#18+
Gordeev_Andry, Все это хорошо, но тогда следуют два вывода: 1. Коррекции необходимо переделывать в случае изменения сумм участников. Триггера на модификацию, сброс коррекций, уведомление операторам о статусе аукциона "требует коррекции". 2. Коррекцию, видимо, нужно не просто указывать для аукциона, а привязывать к какому-то участнику. Иначе кто же будет ее платить? Или Вы ее за счет заведения списываете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2009, 08:50 |
|
||
|
|
start [/forum/topic.php?fid=32&gotonew=1&tid=1543250]: |
0ms |
get settings: |
7ms |
get forum list: |
17ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
161ms |
get topic data: |
11ms |
get first new msg: |
5ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 205ms |
| total: | 458ms |
| 0 / 0 |
