BiTel

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

Я щас ковырялся с выборками по воипу и увидел что там цены звонков аля 482.79999
и что с этим делать ?

Я кстати не спешил писать об еще одной баге с округлениями, жду контракта тех поддержки, а то что то даже на баг репорты тоскливо тут ответа от вас ждать....
Вообщем та же пертрушка с округлениями с доводящими абон платами, конкретный пример по январю, доводящая абон плата по модулю IPN
тариф на доводящую абон плату 5717.10, это же значение в npay_add_cost_detail
наработка по IPN (две услуги на модуле) 470.39 + 4677.90
наработка по доводящей абон плате 568.80

вылезла копейка, я выставил абоненту авансом npay_add_cost_detail, а в конце месяца выставил "доплату" на сумму -0.01
круто...
а не выставлять эту копейку нельзя, потом балансы не сойдутся с 1с и прийдется каждый месяц в куче договоров фиктивные платежи городить

а причина проста:

эти два числа округляются до 470.39 и 4677.90 оба в меньшую сторону
а при вычислении доводящей абон платы идет агрегирующая выборка, которая дает сумму в 5148.29620 которая уже округляется в большую сторону

приехали

мне всегда казалось что в любой системе работающей с деньгами либо всегда надо использовать транкейт либо после каждой первичной операции сохранять округленное до копеек число, в часности в таблице contract_acoount, как и в log_session и тп, числа надо хранить с точностью не более 2х знаков

я не прав ?
приму советы как выкручиваться...

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

А у Вас какая версия? Просто в 4.5 уже бОльшая часть подобных вещей переведена в соответствующий формат, исключающий вышеописанное.

Впрочем да, в воипе пока по-старому.

4.5, обновлялся несколько часов назад

P.S. не только в воипе, а и в contract_accounts еще как минимум

contract_accounts не перевели в копейки, т.к. в нее идут приращение при обсчете в оперативных модулей типа DialUP и приращение может быть меньше копейки.

но при выборке для суммирования в contract_balance каждая запись в contract_account приводится к копейкам а только затем суммируется.

звонки в телефонии тоже в копейках, в voip сделаем тоже.

по доводящей абонплате тоже переделать нужно рассчет.

P.S. Копейки не подходят, когда в базе есть записи, приращения которых возможны менее копейки.

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

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

Услуги тарифицируются порционально, разве нет ? Порция для месячной абон платы - месяц, для IPN - месяц (может когда-нибудь реализуете часовую или хотя бы суточную), для диалапа - СЕССИЯ, для телефонии и воипа - звонок.
Порция не может стоит xx рублей и 25.6734 копейки - это абсурд

в contract_account же вообще пишутся месяцный нарабки по услугам, как они то могут стоит доли копеек ?

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

На примере телефонии это просто очень заметно, а в других местах не очень.
Звонок по цене 2 рубля в минуту продолжительностью в 2 минуты не может стоить 3.9999 рубля, согласны ? Наверняка согласны. Тоже самое с диалапом, один в один, в тарифе всегда указано с какой точностью ведутся расчеты и я уверен в природе не бывает тарифов "2 копейки за 5 байтов".

Да в природе не бывает таких тарифов! Но наработка считается с точностью до байта! И при стоимости 1 рубль за мегабайт и наработке в даже в 1 Кбайт стоимость оказанных услуг будет 0,000976563 рубля!
Про звонки понятно! там тарификация секунда от минуты это 1/60, Но при цене мегобайта стоимость 1 килобайта 1/1024, вот почему и идуть не целые копейки! Как Вариант округлять сессию до 100 килобайт!

Да я понимаю что байт может стоить долю копеек, и телефония если она операторская считается посекундно и на операторских тарифах цена секунды будет стоит доли копеек по куче направлений.
Но я говорю что ПОРЦИЯ услуги не может иметь стоимость с долями копеек, это бухгалтерски неверно. В часности звонок в межоператорских расчетах продолжительностью 2-3 секунды округляется по цене в ноль, а уж диалапная сессия в принципе имеет стоимость нормальную в отличии от звонков, и там доли копеек полюбому несущественны.

P.S. хотя не, вру, когда мы (в прошлой жизни) гнали трафик десятками миллионов минут на москву со всего земного шарика, то мы считали ее с точностью до 4го знака, иначе там на коротких звонках были бы просто аховые потери, но это часный случай, никто не будет БГБ использовать для операторского телефонного трафика, месный радиус сервер просто разорвет на куски вместе с компутером через 5 минут работы

С точки зрения бухгалтерии может быть Вы и правы! Но с точки зрения АСР нет. АСР это высокоточная система обсчёта услуг! С моей стороны Вы сами можете для себя найти решения! округляя по трафику или же по вызовам скриптов округлять копейки в соответствующих таблицах баз данных!
Но единственное что и в том и другом случае без потерь не обойтись! Так как если Вы купили 1 мегабайт и продали с округлением то у Вас может получиться в зависимости от округления либо меньше либо больше!

Объясните, зачем в бухгалтерии учет сессий? Чем недостаточно просто наработка договора по какой-то услуге в месяц? ПОРЦИЯ - звучит гордо, но слишком неопределенно.

Я написал "бухгалтерски неверно", а не в "бухгалтерии неверено" )
Если вы считаете что суммы по диалапу должны быть с долями копеек, пусть будет так, если вы реализуете почасовую тарификацию IPN то пусть тоже будет с долями копеек. Важно то что бы вы понимали что везде где данный тарификатора сводятся к бухлагтерским данным доли копеек должны исчезнуть. В часности в contract_account долям копеек делать нечего однозначно, это наработки по услугам ЗА МЕСЯЦ. Соответсвенно когда одна услуга расчитывает от наработке по другой услуге всегда должны использоваться данные уже округленные до копеек. Иначе говоря нельзя делать выборки типа round(sum(x)), если так делать то будут вылазить фантомы вроде доводящей абон платы.

На счет порций, я вроде объяснил свою точку зрения, а именно что речь идет о том что деталировки по услугам будт отличаться по сумме от наработок так как деталировка выводит сессии/звонки/дни округляя суммы за эти "порции" услуг, а биллинг округление ведет не по этим же саммым "порциям" а по наработке целиком. Ну опять же пример деводящей абон платы: если x = y + z то round(x) не всегда равно round(y) + round(z)

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

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

Для таких ситуаций обычно реализуют скрытую константу которая добавляется перед округлением, опять же это только в телефонии смысл имело когда продается 2-3 миллиона минут при цене 0.2 цента за минуту с посекундной тарификацией (это абсолютно реальные цифры для транзитного оператора телефонии). Но на транзитной телефонии никто никогда не делает деталировок по услугам.

Для любой другой услуги нет таких дешовых "сессий". У вас есть диалап сессии где критична цена сессии с точностью до копейки? не верю.

И вы не правы на счет того что АРС это таррификатор, это не так. Таррификатор это лишь часть АРС и он может работать с любой точностью, но к АРС в целом так же применяются требования по ведению бухгалтерского учета по обсчитываемым услугам, и на стыке между таррификатором и бухгалтерской частью должна быть четкая грань, бухгалтерские алгоритмы не имеют права лазить в данные таррификатора напрямую, если эти данные необходимы, то они должны быть продублированны с округлением с некоторой агрегацией.

например, таррифкатор может таррифицировать каждый flow отдельно и сохранять стоимость с точностью до 10 знака после запятой, но для бухгалтерии эти данные должны быть агрегированы, например, по часам и стоимости сведены к копейкам, и все бухгалтерские алгоритмы должны пользоваться уже этими агрегированныйми данными с целочисленной арифметикой (в копеках)

Преминительно к телефонии, если интерисует возможность таррифицировать по правилам транзитного оператора, единственный вариант это согранять в логе сессий две стоимости, одну округленную другую с точностью до 5-6 знака, а в настройках услуги, например в концигурации модуля VoIP/Phone, указывать какую стоимость модуль будет использовать для ведения наработок по этой услуге
Для клиенских тарифов услуги будут использовать округленную до копеек стоимость звонков, а услуга операторского трафика будет использовать точную сумму и округлять только итогововую сумму за месяц.

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

А для доводящей абонплаты опять же просто нужно сначала округлить, т.к. для суммирования в contract_balance наработки из contract_account округляются до 2го знака. Вы все равно в хелпдеск опишите, там и разберемся с конретным примером.

Звонки в телефонии уже округлили до 2го знака, т.к. иначе в детализации у клиентов не сходится сумма по копейкам с суммой аработки. С VoiceIP и DialUP(VPN) пока непонятно..

С DialUP суммой та же проблема что и с contract_account - нужно приращивать ее по ходу обсчета.

договор на ТП щас в оформлении у нас, доступ в ХД есть но я там нифига сделать пока не могу, даже счет выписать, так что я щас продублирую на почту проблему

по проблеме я еще круче ситуацию нашел, чистый ТП, без всяких извратов, услуга с 1 числа месяца, ТП тоже, договор тоже, и при этом наработка по услугам абон платы не совпадает с ТП, это просто смех

вы не поверите, но в наработку попала +1 копейка

я уверен таких проблем будет миллион, латаныем дыр проблема не уберется никогда, она будет вылазить то там то там

прикладываю скрины, за эту копейку по госконтракту меня завтра порвут на британский флаг, и уверяю вас, что объяснения о высокоточной АРС вычисляющей замесяц абонку на 1 копейку больше чем указано в тарифе за месяц начальство не устроит

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

Да, на счет звонков, я вспомнил как решать проблему фантомных x.99999, вы тарифицируете в джава коде оперируя переменными с большой точностью, а в базе у вас float(10,5), так вот когда вы просто пишете в базу число xx.99999999999999 оно у вас транкейтится, а надо писать
"insert .... values (..., round(<variable>, 5), ...)" и фантомные периоды исчезнут.
И так надо делать везде где вы пишите в базу вычисляемые значения с плавающей точкой, в принципе можно везде округлять до ~10 знака, с запасом так сказать, что бы потом не править код когда захочется вместо float(10,5) сделать float(10,6), вообщем главное захватить последнюю цифру в числах с периодом.

P.S. не просмотрите предыдущий пост мой со кринами, а то вторая страница топика пошла, вдруг не заметите

При вставке MySQL не обрезает а округляет. По абонплатам ошибка воспроизвелась, исправляем.


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

Если бы mysql округляла то наверно вы бы не получали при звонке в 2 минуты, по цене 2 рубля стоимость 3.9999 ?


Значит вы пользуетесь числами с низкой точностью, не знаю, но факт фантомов которые характерны компьюторной операции деления чисел с плавающей точкой на лицо.


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

P.S. по абонке жду новостей, спасибо, пойду пока узнаю у юриста когда он подпишет договор на тп

Со звонками я уже написал, что сделать попробовать. По абонкам - разбираюсь.

Я ответил Для меня это вариант конечно, хотя для меня лично и round при выборке пропрет так как по каждому договору у меня звонков то там 1000 штук максимум будет и эти фантомы просто не доберут до копейки. Но я за истину тут борюсь

мускул округляет ...земените SELECT на UPDATE и мускул сам округлит до размера поля ...

кстати... может быть вырастить версию BGB под постгрес? на больших нагрузках MySQL как-то совсем не айс. не промышленное решение.

_________________
================================
ООО "Подряд" является зарегистрированным пользователем данного аддикта.

Если кто-то даст реальный тест, показывающий значительный скачок производительности постгресса по сравнению с MySQL на простых конкурирующих UPDATE/SELECT по первичному ключу (собственно у нас 90% выборок простые), мы сразу начнем копать в ту сторону.
До тех пор особого смыслу в смене СУБД не вижу.. Ну назвал ее кто-то "промышленной". Во времена выбора нами СУБД у них даже нативной версии под Windows не было.. И объем документации по сравнению с MySQL просто на порядок уступает.

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

Если на оракл, то тогда логику всю надо переносить туда

По поводу копейки: Пока придумал в тарифном плане задавать до какого знака округлять стоимость звонка. В базе хранить 5 знаков.

По поводу оракла: Тесты, тесты нужны ) Причем на близких к нашим (множество простых запросов) условиях. Пробовали мы и оракл. Пролетел, насколько помню. Еще и ставить его замучаешься, кучу кнопок тыкать и настраивать потом. На сервере, куда доступ только по ССШ и никакой графики нет в помине - вообще сказка. Правда, потом RPM нашли вроде..

это такая можа сейчас при словах "база данных" сразу вспоминать оракл? можно конечно и по воробъям крупнокалиберным спецбоеприпасом стрелять но, простите, зачем? для биллинга использующего простейшие запросы вполне хватает мускула, ну разве что вариант с переездом на постгрес еще как то можно обсудить (там спец. формат полей для IP адресов и т.д. и т.п.), а оракл ... IMHO, но это слишком, а если учесть его стоимость (про это что-то все как-то забывают) то можно вообще сказать - "в сад!"(с)

Вот тут вопрос сравнения производительности обсасывали

а переводить СУБД бгбиллинга на оракул, ИМО несерьезно. Постгре таки бесплатный, в отличие от оракула, желающего деньгу за свои решения. Да и выигрыш оракул перед Постгрес дает ИМО только при полномасштабном использовании Oracle PL/SQL. Которому, к слову, команда разработчиков из Беркли, нашла достойное применение и в СУБД PostgreSQL, обозвав его PL/pgSQL.


MySQL же изначально задумывался как легковесный, быстрый SQL демон для слабонагруженных приложений. что то вроде SQLite.
основная область его применения - слабонагруженные вебприложения.

_________________
================================
ООО "Подряд" является зарегистрированным пользователем данного аддикта.

MySQL это M$ Exel

И Еще Одно Преимущество PostgreSQL перед MySQL => у PostgreSQL есть AUTO[VACUUM, ANALYZE, garbage collector]. еще бы автобекап сделали - можно было бы ваще не париться

_________________
================================
ООО "Подряд" является зарегистрированным пользователем данного аддикта.