powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Автоматический расчет и ручная коррекция
13 сообщений из 13, страница 1 из 1
Автоматический расчет и ручная коррекция
    #35983706
Gordeev_Andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Доброго.

За неимением опыта стою у развилки ... подтолкните, пжлст.

Таблицы:
АУКЦИОН
ID

УЧАСТНИКИ
Аукцион_ID
Сумма

Нужно сделать проводку на ОБЩУЮ сумму участников аукциона.
Расчитывается она просто (select sum(уч.сумма) from участники уч where уч.аукцион_ID = :A)

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


Вариант первый:
Добавляем в АУКЦИОН поля
сумма (перерасчитываем при каждом изменении участников)
ручная_корр. (Если флаг стоит, то сумма была поставлена руками - перерасчет игнорируем. При снятии флага наново расчитываем сумму)
выгружено (теперь изменение участников запрещено)
При каждом изменении/редактировании участников
Смотрим на эти флаги, принимаем решение, добавлять или нет, перерасчитываем общую сумму и т.д.

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

Участников в каждом аукционе ожидается около сотни.

Или есть более красивый вариант?
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35984081
Фотография Роман Дынник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gordeev_Andry
Или есть более красивый вариант?
Правильней второй вариант, но не совсем так...
А примерно вот так:
Код: plaintext
Итоговая сумма = Исходная сумма +ISNULL(Сумма корректировки,  0 )
Т.е. сумма корректировки - это дельта, а не сумма "целиком". Хранится должна дельта. Как вы будете делать это в интерфейсе - ваше дело - можете дельту вводить, можете сумму, а дельту рассчитывать при сохранении.
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35984650
Alkatraz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Роман Дынник,

Соглашусь - так правильнее и практичней. Еще могу добавить, что если перспективы развития таких "корректировок" туманны, то можно вынести их в отдельную таблицу и завести справочник "видов корректировок", где будут указываться причины корректировки. Тогда на одну расчитанную сумму можно вносить много корректировок, разбивая их на причины, с комментариями. Таким образом, расчитанные суммы останутся такими, какими они были расчитанны. Но возникает другая проблемма - при перерасчете, если новая расчитанная сумма другая, то необходимо стирать все корректировки, или корректировать их на сумму разницы сторого расчета и нового...
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35985952
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Мы ведем у себя 2 поля - "расчет" и "факт" и затем в зависимости что необходимо используем то или иное поле
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35985982
ветерочек
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
AlkatrazРоман Дынник,

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

тогда может

УЧАСТНИКИ
Аукцион_ID
Сумма
Тип_ID

ТИПЫСУММ
ID
...(можно и Parent_ID )

где ID =1 Это "нормальная"
2- "подкручена ручками"
3- ....
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35986042
Alkatraz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ветерочек
тогда может

УЧАСТНИКИ
Аукцион_ID
Сумма
Тип_ID

ТИПЫСУММ
ID
...(можно и Parent_ID )

где ID =1 Это "нормальная"
2- "подкручена ручками"
3- ....

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

По моему опыту надо разделять данные генерируемые системой и данные, вводимые пользователями. Таким образом есть гарантия, что расчетные данные на будут затронуты пользовательским вводом.
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35986107
ветерочек
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Alkatrazветерочек
тогда может

УЧАСТНИКИ
Аукцион_ID
Сумма
Тип_ID

ТИПЫСУММ
ID
...(можно и Parent_ID )

где ID =1 Это "нормальная"
2- "подкручена ручками"
3- ....

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

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

ИМХО чем проще тем лучше , я бы лучше этот контроль вывел бы на приложение (просто не выводить где ID =1) накладных расходов меньше ,да и к этому справочнику доступ должен быть мало у кого, а если пользователь может влезать в таблицы то тут уже ничего не поможет :)
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35986182
Alkatraz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ветерочек
ИМХО чем проще тем лучше , я бы лучше этот контроль вывел бы на приложение (просто не выводить где ID =1) накладных расходов меньше ,да и к этому справочнику доступ должен быть мало у кого, а если пользователь может влезать в таблицы то тут уже ничего не поможет :)

Тогда вам проще в самом деле сделать еще одно поле в расчетной таблице и применить вышеописаный метод получения итоговой суммы, предложенный Романом.

Серьезно - не рекомендую делать так, как вы предлагаете - возможности доработки минимальные, а головной боли не оберетесь потом.
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35986628
Gordeev_Andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
spМы ведем у себя 2 поля - "расчет" и "факт" и затем в зависимости что необходимо используем то или иное поле
Я так понимаю, что реальное поле "расчет" стоит заводить, если его расчет ресурсоёмкий, иначе обходимся вічислением "на ходу"? Верно?

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

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

Пока такое решение:
остановлюсь на варианте Романа
Добавлю поле аукцион.сумма_коррекции (тут только дельта, изменение этого поля логируем с комментами)
в вьюшке, с которой будет приложение работать, выложу три поля
расчетная_сумма
корректровка
итоговаяа_сумма

Если есть веские "против" - прошу :)
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35987198
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gordeev_Andry

AlkatrazНо возникает другая проблемма - при перерасчете, если новая расчитанная сумма другая, то необходимо стирать все корректировки, или корректировать их на сумму разницы сторого расчета и нового...
Думал над этим тоже. Озадачил юзеров ... они в шоке :-)

Здесь путаница в схеме документооборота.

Есть один поток информации - реальные суммы участников, и из них - реальная сумма аукциона. Второй, независимый от него поток - корректировки, и отфонарная сумма аукциона. И вместе эти стрелки сходятся в некую откорректированную сумму аукциона.

Организовать в БД это все тривиально. Но нет ответов по организационному разруливанию двух стрелок, приходящих в один квадрат:

Вводятся ли корректировка как готовая сумма аукциона, на которую по-любому нужно выйти, или это просто дельты, вроде фиксированных или процентных скидок отдельным VIP-участникам? Или ситуации бывают и такие и другие?

Что делать, если после введения корректировок обновились реальные суммы участников? Другими словами, есть ли на схеме зависимостей стрелка от реальных сумм участников к корректировкам? Забудьте про базы данных и компьютеры, дайте ответ в терминах бумажного делопроизводства 19 века.

И вообще, когда я в БД слышу термин "коррекция", то чаще всего это означает некую область, не проработанную на этапе постановки задачи, и причиняющую основную головную боль в процессе эксплуатации.
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35988191
Gordeev_Andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Cane Cat Fisher
И вообще, когда я в БД слышу термин "коррекция", то чаще всего это означает некую область, не проработанную на этапе постановки задачи, и причиняющую основную головную боль в процессе эксплуатации.
В моем случае коррекции нужны для
"вот тут подкрутим копейку, а тут две и выйдем на то, что сверху спустили".

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

От автоматического "выравнивания" копеек юзеры отказались.

Так-что в моем случае вариант Романа мне кажется более оптимальным, чем мои.
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35990648
Cane Cat Fisher
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Gordeev_Andry,

Все это хорошо, но тогда следуют два вывода:

1. Коррекции необходимо переделывать в случае изменения сумм участников. Триггера на модификацию, сброс коррекций, уведомление операторам о статусе аукциона "требует коррекции".

2. Коррекцию, видимо, нужно не просто указывать для аукциона, а привязывать к какому-то участнику. Иначе кто же будет ее платить? Или Вы ее за счет заведения списываете?
...
Рейтинг: 0 / 0
Автоматический расчет и ручная коррекция
    #35990743
Gordeev_Andry
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Спасибо за участие :)
Корректироваться, действительно, будут суммы по участникам.

А вот о "автосбросе" корректировок при изм. сумм нужно задуматься.
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Автоматический расчет и ручная коррекция
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]