|
округление сумм
|
||
|---|---|---|
Участник
Откуда: Монголо-Татарская Республика, г. Чойбалсан
Сообщения: 96 |
||
| 12.07.2004, 09:47 |
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
Код: plaintext Код: plaintext Код: plaintext По поводу моих расчетов Есть справочники: Услуги Объекты Типы льгот Услуга настраивается пользователем + указывают на какой объект она распространяется + указывают какая льгота действует на данную услугу При расчете ->Курсор услуг -> Курсор объектов подпадающих под данную услугу ............... -> Курсор прописанных в данном объекте ............... -> Курсор Всех льгот действующих на данную услугу и имеет ли прописанный такую льготу ................ Это конечно все в краце Сама суть понятна??? Может предложите какаото другой агоритм ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2004, 16:58 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
в каких случаях - я использовал алгоритм который после вычисленией с максимальной точностью делает проверку итоговой суммы (точной) и сравнивает ее с итогом_ через_округленные_ значения. Полученную погрешность - тупо пишет в первую или в последнею строку (колонку), так - чтобы пересчет округленных значений выдывал правильную сумму. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2004, 17:11 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
Кажется, на SQL.RU кто-то приводил превосходный способ ускорения подобных масс-обработок. А может, еще где. Берусь повторить, потому что это должен знать каждый ;-) Дело в том, что, как правило, такого рода расчеты начинают делать по каждому лицевому счету. В самом деле, что может казаться естественнее: сделать цикл по всем счетам, внутри цикла для каждого счета выполнить запрос(ы), выбирающий(е) всякие коэффициенты, рассчитать сумму, сохранить результат по этому счету за этот период, и так далее. Пусть у нас 100 счетов, и нужно выполнить 3 запроса, чтобы последовательно посчитать суммы, например, за газ, воду и электричество, затем сложить их и получить общую сумму. Ну, очень грубый пример. Получим 1 запрос на выборку счетов, возвращающий 100 записей; 100*3=300 запросов, возвращающих промежуточные суммы, каждый по одной записи, и 100 запросов на запись итогов (insert). А ведь можно считать и по-другому: выполнять по одному запросу для расчета каждой промежуточной суммы, но сразу по всем счетам. Тогда мы будем иметь 3 запроса, возвращающих каждый по 100 записей, 1 запрос на запись 100 записей (в первый раз, за газ, например) и 3 запроса по 100 записей на изменение этих записей (за воду, за электричество и вычисляющий общую сумму) - тоже грубо - ведь, например, общую сумму можно вычислять вместе с заполнением последней промежуточной суммы, да и вообще сделать insert ... select ... ;-) Что быстрее: много маленьких запросов или немного больших? Если на практике все сложнее, и по разным счетам разный порядок расчета, все равно можно выделить группы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2004, 18:12 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
Прошу прощения, забыл указать, что мой предыдущий пост - это ответ на побочно всплывший вопрос о том, почему у одних считается быстро, а у других долго, а не по основной теме округления ;-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2004, 18:18 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
Общего решения проблемы округления в таком виде нет. Мы тоже столкнулись с такой проблемой. Приходит уголь по ЖД квитанциям. Сумма ЖД квитанции - это ROUND(Количество * Цена,2). Прикол в том, что в с/фактуре квитанций много, а марка угля одна. И в фактуре это выглядит так ROUND(SUM(Количество)*Цена, 2). Пришлось написать отдельную функцию, которая вычисляла сумму фактуры с учетом необходимой группировки. Ну и разьяснительная работа - подобрал пример, где расхождение большое, и предложил написать свой вариант, как надо. После нескольких дней безуспешных попыток собственно и родилась такая функция. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2004, 19:59 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
у меня начисления происходят по схеме, которую прблизительно описал Urri - за один проход считается один компонент начислений для группы лицевых счетов (я использую группы по 2500 - вычисленно эмпирически). Хотя есть моменты, когда открывается тупой курсор и идет перебор лицевых счетов - когда производится сворачивание начисленных сумм и объемов в пределах неизменности параметров. Пробовал сначала одним запросом - курсор оказался быстрее, за счет ненадобности построения достаточно большой внутренней временной таблицы. если допустить, что у нас есть перечень услуг с нормами расход услуги на единицу людей и ценой этой услуги, что все лицевые счета всегда пользуются следующими услугами, то алгоритм начислений выглядит вот так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. Аналогичным образом считается льгота, только в качестве услуги используется регистрация льгот, а в качестве опорной суммы - проведенные ранее начисления. Добавляя по вкусу разные дополнительные таблицы связи (не забывая при этом о периоде наличия связи) между ЛС и услугой, ЛС и графиком подачи воды, ЛС и показаниями счетчика - можно изменять начисленную сумму. 2Ork Как показано выше, я провожу начисления за известный месяц, поэтому предварительно рассчитать недостающие показания счетчиков проблемы не представляет. на текущий момент представляет проблему то, что это происходит достаточно медленно :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 09.07.2004, 20:45 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
Можно еще перейти к более мелким единицам измерения. Например, считать не в кубометрах, а литрах. Пусть считают литры с точностью до двух знаков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.07.2004, 11:56 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
2DIGITALPRO усе счиатем? ну тогда возможно это и нормальная скорость... можно попробовать оптимизировать запросы... может методу чуть поменять... а дайте как свою структуру таблиц, с кратким описанием... авторУ таких организаций нет сервака, уних только 1 комп, 1 Руководитель, 1 Бух., 1-2 сантехника плотника электрика ну если техника на селероны 500 то думаю скорость должна быть приемлимой... авторУслуга настраивается пользователем типа справочник услуг, а потом в соответствии с кодом выбирается алгоритм? в таком случая я для себя не решил... у меня по началу была вода и стоки... просто таблица начислений с полем кубов воды, начисления и кубов стоков и его начисления (грубо так если что) потом стали всякую фигню вводить, горячие стоки, поливы, прочие водоснабжния и я пожалел что не вынес это в несколько услуг... типа добавил стороку в таблицу, и в месяц вместо одной строки начислений была бы строка на воду, стоки, гор.стоки, полив и т.д. но сбор данных в одну таблицу был бы потормозней... если в вас так как я понял, то это и есть сущесвенная разница в скорости... у меня проход только один раз... берется строка, запускается триггер, из него процедурка, она все высчитывает, и берется другая строка... 2Urri по теме перевобор согласен... сам проводил сравнение... пример... есть процедурка, она берет дом, и находит всех товарищей и товарищей у кого есть канализация... плюс всякая мелочовка в подсчетах... по началу я написал две селекта и был доволен... но в масштабах всего города при 45тыщ ЛС было около 2млн запросов к таблице начислений... сделал общйи селект на весь дом, берется строчка, если есть канализация, то х++, сложил чего нужно куму нужно и так по всему дому... итого в два раза стало меньше дурного дерганья винта... 2locky авторКак показано выше, я провожу начисления за известный месяц, поэтому предварительно рассчитать недостающие показания счетчиков проблемы не представляет. на текущий момент представляет проблему то, что это происходит достаточно медленно :-( а у нас до сих пор плановая экономика... закрытие месяца по начислениям в конце 20х чисел... ибо так хочется плановому отделу... а то что еще не все заплатили - это фигня... кубы по водомерам мы узнаем тока из квитанций, оплату в большенстве случаев вводим после того как месяц по начислениям уже закрыт... короче ситуация когда приходит товарищ, платит все по водомеру, а у него долг - это обычная практика... 2Cat2 а цена то на куб! куб стоит 73 коп... литр 0.73/1000... хотя как вариант точности самого водопотребления подходит... но для льгот кубы не важны... им деньги нужны... Мы - это наши желания. Зигмунд Фрейд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2004, 09:47 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
Ork Yason На самом деле, это чисто административная проблема. Пусть начальник издаст приказ, что бы бухи ститали воду с точностью до одной миллионной куба, а не до одной сотой. Начальнику пофиг. Подмахнет неглядя. Он же может издать приказ, что при внутрениих расчетах потребление считать в литрах, а цену установить в размере 73 коп. за 1000 литров. Так же главбух может подготовить приказ по учетной политике, при которой ошибки округления относятся на внереализационные прибыли (убытки). Мой совет. С этой проблемой надо выходить на руководство. И аргументировано доказывать свою правоту. Математического решения НЕТ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2004, 21:02 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
ну, у нас тоже значительная часть сведений поступает после того, как проведены начисления. но это не проблема - всегда можно сделать перерасчет. А вот как касаются оплаты к начислениям - выше моего понимания (точнее, в пределах понимания, но не для этой ситуации). У меня раздельно закрывается движение по дебету (начисления, перерасчеты) и отдельно по кредиту (оплаты и т.д.). Движение по кредиту не может быть закрыто ранее 1-го числа, т.к. отчеты по поступлению оплаты сверяются с банковскими выписками по дням за месяц. Начисления у нас проводятся где-то 3-4 числа. Можно было бы и 1-го, но 2-3 поступают данные о горячей воде. С целью свести к минимуму перерасчеты начисления проводятся только после получения этих сведений. Показания по водомеру у нас вводятся как оператором (после приема по телефону) так и импортируются из тех же квитанций ЕРЦ. Ежели у товарища есть должок - говорит показания, девочка щелкает мышкой и товарищу пересчитывается. Обычно уходит довольный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.07.2004, 21:11 |
|
||
|
округление сумм
|
|||
|---|---|---|---|
|
#18+
2Cat2 я согласен что административная трабла... но сие не моя организация... моих все устаривает... а вот в УТСЗН сидят не пробиваемые бабыги... 2locky авторА вот как касаются оплаты к начислениям - выше моего понимания да это же элементарно! там показания счетчиков... авторЕжели у товарища есть должок - говорит показания, девочка щелкает мышкой и товарищу пересчитывается. Обычно уходит довольный. та ну, это так быстро и не интересно... у нас нужно контроллера вызвать на дом, он собственноручно проверит, а потом тока даст добро на перерасчет... и это при том что контроллеров не хватает... короче, это цирк ;) я им это твержу третий год, а они мне про то что тут так всегда было и так и надо... Мы - это наши желания. Зигмунд Фрейд ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.07.2004, 09:06 |
|
||
|
|
start [/forum/topic.php?fid=32&msg=32600796&tid=1546368]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
169ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
| others: | 263ms |
| total: | 528ms |
| 0 / 0 |
