BiTel

Добрый день!

Не знаю от куда начать, начну с этого форума:
Задача: абонент заказал 25 однотипных точек подключения с 28.01.2016. Ежемесячная стоимость одной точки - 3420.00р, рассчитывается пропорционально периода. Заводим точки в договор, как 25 отдельных услуг модуля NPay. Смотрим наработку: 11032.26. Эта сумма получилась как ROUND(3420.00 / 31 * 4 * 25, 2). Вроде бы правильно. Но теперь делаем счета в модуле бухгалтерии. Там, по требованиям бухгалтерии наработка "распадается" через NPAY_SERVICES_EXT, и опа, получаем 25 услуг по цене 441.29 и общую сумму наработки 11032.25. Согласен, мелочь, но бухгалтерия рвет и мечет. И что делать. Ну ладно, этот счет я скорректирую руками, а дальше? Все счета ведь не напроверяешься. И бухгалтерия вроде права. Математика математикой, но в бухгалтерии денежная математика и 2 цифры после запятой, и думается, что формула выше должна быть вида ROUND(СУММА_МЕСЯЦА/ДНИ_МЕСЯЦА * ДНИ_УСЛУГИ, 2) и считаться по каждой (даже однотипной) услуге отдельно.

Это проблема старая.. С одной стороны хотят чтобы биллинг считал точно, с другой - чтобы писал в каком-нибудь отчете детализацию с округлением до копеек. Если взять части и каждую округлить до копеек, то сумма не получится такая же . Наработку по услуге храним мы с точностью до 5-го знака, а при выводе в счете у вас округляет до 2-го. Хотя с другой стороны я понимаю проблему бухгалтерии. Особенно это хорошо проявляется если есть много каких-нибудь сессии или звонков и выводить стоимость каждого из них с точностью до 2-го знака.

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

Заказал детализацию звонков у своего сотового оператора, там с точносью до 4-го знака все показано. Может вам абонки в счете тоже показывать до 5-го знака?

Я то не против, но в данном случае последнее слово за бухгалтерией А они категорически против.

Тогда не показывать? Писать количество услуг и общую сумму ?

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

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

Но надо что-то делать, надо.

Таки нет? Ничего не будем делать?

Пишите в хд