Перейти к содержимому
Калькуляторы

Carbon billing 5, обсуждение пишите, кто что думает, хвалите, ругайте, отправляйте пожелания

В 16.06.2020 в 10:28, product manager CB5 сказал:

Для всех, кто ещё не купил себе Carbon Billing 5: мы запускаем акцию, поддержка SLA4-Аутсорсинг в течение месяца, если договор на SLA1, SLA2 или SLA3. Если договор на SLA4 - то выделенный администратор с прямым контактом в Skype, делает все ваши заявки самостоятельно. Можете прочитать подробнее на сайте

Это, наверное хорошо, что есть такие акции. Только вот провайдеры, которые сидят изначально на SLA4 не получают поддержку во время. То есть могут завести заявку вечером, когда у вас уже никто не работает, а что-то ответят по ней уже после обеда по московскому времени. И не важно обычная это заявка, или критическая. За все время контактирования с 5 версией я так и не понял что у них является критической заявкой, а что не критической. Т.к. по всем критическим заявкам ничего в не рабочее время не делается, могут только включить интернет всем и ждать до утра. И не важно что там абоненты заплатить при смене месяца не могут, или в ЛК зайти. Эти задачи техподдержка будет 2-3 дня решать, задавая по вопросу рас в 2-3-4 часа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

11 часов назад, Saab95 сказал:

Это, наверное хорошо, что есть такие акции. Только вот провайдеры, которые сидят изначально на SLA4 не получают поддержку во время. То есть могут завести заявку вечером, когда у вас уже никто не работает, а что-то ответят по ней уже после обеда по московскому времени. И не важно обычная это заявка, или критическая. За все время контактирования с 5 версией я так и не понял что у них является критической заявкой, а что не критической. Т.к. по всем критическим заявкам ничего в не рабочее время не делается, могут только включить интернет всем и ждать до утра. И не важно что там абоненты заплатить при смене месяца не могут, или в ЛК зайти. Эти задачи техподдержка будет 2-3 дня решать, задавая по вопросу рас в 2-3-4 часа.

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

Да, действительно, если проблема решается включением "интернет всем" - то полноценное решение ищется в рабочее время, так как это именно аварийная поддержка. На нашем сайте всегда об этом было написано https://www.carbonsoft.ru/support/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, product manager CB5 сказал:

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

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

Согласитесь, что не всегда галочка дать интернет всем помогает, как будут действовать в таких случаях? Я с такими тоже сталкивался, когда карбон 5 версии в режиме радиуса с циской перестал работать, при этом сервер вывалился с ошибкой. Было сообщено в техподдержку с указанием фактов проблемы, указано что критичная заявка, а так же позвонили по телефону сообщили что заявка заведена и ее номер. На сервере постоянный IPKVM. И что же, сидели смотрели в монитор сервера полтора часа, и только по истечении этого времени, и пары дополнительных звонков, на сервер кто-то зашел, ввел несколько типовых команд, что-то посмотрели, перезапустили службы и ничего не заработало. После этого включили другой сервер с радиусом, который всех пускал и раздавал адреса, что бы хоть как-то работало и пошли спать. А карбон починил сервер только к концу дня, и судя по потребленному объему данных по сети в несколько гигов, то явно что-то перекачивали или переустанавливали.

 

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

 

46 минут назад, Aomi сказал:

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

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

Но минусов еще больше - техподдержка не своевременная, кормят завтраками, большая часть функционала или не работает, или работает с костылями, или с кучей условий. Например одно чего стоит указание суммы стоимости тарифа вручную. Это надо установить сумму, сделать санацию, потом зайти опять в настройки тарифа поправить списанные суммы внизу настроек, потом опять сделать санацию, потом подкорректировать списания приходом или расходом. При этом даже на очень производительном сервере - 8 физических ядер на 3.7ггц, 32гб оперативки, быстрые диски, любые изменения настроек абонента занимают чуть ли не 10 секунд, пока там шестеренки крутятся. Это же абсурд какой-то.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

25 минут назад, Saab95 сказал:

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

Согласитесь, что не всегда галочка дать интернет всем помогает, как будут действовать в таких случаях? Я с такими тоже сталкивался, когда карбон 5 версии в режиме радиуса с циской перестал работать, при этом сервер вывалился с ошибкой. Было сообщено в техподдержку с указанием фактов проблемы, указано что критичная заявка, а так же позвонили по телефону сообщили что заявка заведена и ее номер. На сервере постоянный IPKVM. И что же, сидели смотрели в монитор сервера полтора часа, и только по истечении этого времени, и пары дополнительных звонков, на сервер кто-то зашел, ввел несколько типовых команд, что-то посмотрели, перезапустили службы и ничего не заработало. После этого включили другой сервер с радиусом, который всех пускал и раздавал адреса, что бы хоть как-то работало и пошли спать. А карбон починил сервер только к концу дня, и судя по потребленному объему данных по сети в несколько гигов, то явно что-то перекачивали или переустанавливали.

 

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

 

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

Но минусов еще больше - техподдержка не своевременная, кормят завтраками, большая часть функционала или не работает, или работает с костылями, или с кучей условий. Например одно чего стоит указание суммы стоимости тарифа вручную. Это надо установить сумму, сделать санацию, потом зайти опять в настройки тарифа поправить списанные суммы внизу настроек, потом опять сделать санацию, потом подкорректировать списания приходом или расходом. При этом даже на очень производительном сервере - 8 физических ядер на 3.7ггц, 32гб оперативки, быстрые диски, любые изменения настроек абонента занимают чуть ли не 10 секунд, пока там шестеренки крутятся. Это же абсурд какой-то.

При проблеме авторизации - соглашусь, интернет всем дать просто не получится, поэтому такие проблемы решаются до устранения. Описанная Вами ситуация звучит совершенно неприемлемо. Тут надо учитывать все детали и разбираться в ситуации - что именно и почему произошло, почему инженер долго не подключался, почему не помогли и тд. Если инженер не может сам подключиться по какой-то причине или не недостаточно опытен в решении какого-то конкретного вопроса - он может подключить любого сотрудника компании, включая инженеров, разработчиков и руководителей.

Скажите, пожалуйста, номер задачи - будем работать над тем чтобы подобные ситуации не происходили.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

https://demo5.carbonsoft.ru/rest_api/v2/

 

502 Bad Gateway

nginx/1.0.15

 

ну почините уже

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Последнее время у Карбона видимо все сотрудники в отпуск ушли, исправно работает лишь отдел выставления счетов.

Техподдержка работает по принципу:

1. Создается заявка в 15-16 и т.п. часов по Московскому времени, ну или в любое другое время до конца дня, например в 21 час вечера.

2. На следующий день, часов так в 15 по Московскому времени приходит некий уточняющий вопрос, без ответа на который можно все равно посмотреть или как-то разобраться в проблеме, что бы задать уже какие-то более наводящие на решение вопроса проблемы.

3. Приходит стандартный ответ - продолжим завтра.

4. Завтра, как и в лучших традициях английского чаепития, ответ следует после 15 часов по Московскому времени.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

29 минут назад, Saab95 сказал:

4. Завтра, как и в лучших традициях английского чаепития, ответ следует после 15 часов по Московскому времени.

так многие работают.

это следствие ввода норматива , что ответ по такой категории вопроса должен быть дан в течении 24 часов, помноженный на нежелание работать

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 час назад, LostSoul сказал:

так многие работают.

Но всё же не все, есть хороший пример от ланбилинга, там отвечают за пару часов.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 03.07.2020 в 11:19, Saab95 сказал:

Последнее время у Карбона видимо все сотрудники в отпуск ушли, исправно работает лишь отдел выставления счетов.

Техподдержка работает по принципу:

1. Создается заявка в 15-16 и т.п. часов по Московскому времени, ну или в любое другое время до конца дня, например в 21 час вечера.

2. На следующий день, часов так в 15 по Московскому времени приходит некий уточняющий вопрос, без ответа на который можно все равно посмотреть или как-то разобраться в проблеме, что бы задать уже какие-то более наводящие на решение вопроса проблемы.

3. Приходит стандартный ответ - продолжим завтра.

4. Завтра, как и в лучших традициях английского чаепития, ответ следует после 15 часов по Московскому времени.


Извините, сегодня мы не смогли решить Вашу задачу, продолжим завтра.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Устрою небольшой разнос )))

 

1) Входящий остаток 1000, расход 333.33, остаток 666.66. Это как ? В разных таблицах по разному, то нормальные поля децимал, то длинные целые....

2) Детализация по расходу. Если сложить дневные суммы, то не сходятся с итогом

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

4) -A PREROUTING -p udp -m udp --dport 1812 -m addrtype --dst-type LOCAL -m limit --limit 30/sec --limit-burst 30 -j ACCEPT
-A PREROUTING -p udp -m udp --dport 1812 -j DROP

И это для системы, гордо заявляющей поддержку онлайн до 1.5М абонентов, но на подступе режем сразу пакеты ???

6) Интересно, как будет раскрываться и загружаться дерево абонентов на 1.5М абонентов...

6) В принципе фаервол - это какой-то ад со всякими редиректами.

7) Структура таблицы на 150 полей на все случаи жизни. при необходимости добавим еще сколько надо. Гениально !!!

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

9) И да - база у всех крэшится при хард-ресете (питание и всё такое) или только в редких случаях не везёт, как нам ?

 

Собирал не специально, что было буквально за неделю плотного знакомства, поэтому 10го пункта нет. Хотя если бы ещё подумал - нашел бы ещё 5-6.

Стоит задуматься...

 

10) Нашел. Девайс давно в дауне, а сесси у абонентов показывает что есть

11) При схеме DHCP вообще непонятно получил абонент адрес или нет.

12) Какие-то постоянные синхронизации с оборудованием и ТВ-порталом. Схема не жизнеспособная для большого кол-ва абонентов

 

Изменено пользователем barguzin2

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 hours ago, barguzin2 said:

1) Входящий остаток 1000, расход 333.33, остаток 666.66. Это как ? В разных таблицах по разному, то нормальные поля децимал, то длинные целые....
 

Такое есть в очень многих биллингах из-за идеологической ошибки просчитывать целочисленные величины (копейки, минуты, байты) не целочисленной арифметикой (плаваающей).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

18 часов назад, barguzin2 сказал:

1) Входящий остаток 1000, расход 333.33, остаток 666.66. Это как ? В разных таблицах по разному, то нормальные поля децимал, то длинные целые....

Там вообще полная ерунда с этими суммами. Более того, бывает что 2 раза списывает за одно и то же.

 

18 часов назад, barguzin2 сказал:

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

Вы еще не пробовали заблокировать абонента и разблокировать, после у него в 50 процентах случаев появятся некие суммы в списаниях, которые вообще удалить никаким образом нельзя. При этом разработчики говорят что это глюк веб интерфейса, а на самом деле ничего такого нет. Только вот и абонент в ЛК видит, что с него больше денег списали и доступ блокируется=)

 

18 часов назад, barguzin2 сказал:

4) -A PREROUTING -p udp -m udp --dport 1812 -m addrtype --dst-type LOCAL -m limit --limit 30/sec --limit-burst 30 -j ACCEPT
-A PREROUTING -p udp -m udp --dport 1812 -j DROP

Просто надо уйти от их схемы и делать свою, как у них это называется "кастом схема". Все их готовые шаблоны рай мазохиста.

 

18 часов назад, barguzin2 сказал:

6) Интересно, как будет раскрываться и загружаться дерево абонентов на 1.5М абонентов...

Там в списке может быть всего 250 абонентов. Вот и представьте вы хотите работать с абонентами, а посмотреть всех не можете, т.к. в список больше не влезает. На резонный вопрос сделать другую схему меню, например на весь экран список, что бы показывало всех - нет, разработчики так сделать не могут.

 

18 часов назад, barguzin2 сказал:

7) Структура таблицы на 150 полей на все случаи жизни. при необходимости добавим еще сколько надо. Гениально !!!

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

 

18 часов назад, barguzin2 сказал:

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

Более того, если стоит списание посуточно, абоненту достаточно один день оплатить, как включатся все услуги, а когда день пройдет - они не выключаются.

 

18 часов назад, barguzin2 сказал:

9) И да - база у всех крэшится при хард-ресете (питание и всё такое) или только в редких случаях не везёт, как нам ?

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 часов назад, Saab95 сказал:

Там вообще полная ерунда с этими суммами. Более того, бывает что 2 раза списывает за одно и то же.

 

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

 

Более того, если стоит списание посуточно, абоненту достаточно один день оплатить, как включатся все услуги, а когда день пройдет - они не выключаются.

 

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

 

 

Блин, да кто вообще тогда этим угробищем пользуется? И кто-то еще и деньги за это платил?? И продолжает платить??? Жесть какая-то же ))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 06.07.2020 в 19:04, barguzin2 сказал:

Устрою небольшой разнос )))

 

1) Входящий остаток 1000, расход 333.33, остаток 666.66. Это как ? В разных таблицах по разному, то нормальные поля децимал, то длинные целые....

2) Детализация по расходу. Если сложить дневные суммы, то не сходятся с итогом

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

4) -A PREROUTING -p udp -m udp --dport 1812 -m addrtype --dst-type LOCAL -m limit --limit 30/sec --limit-burst 30 -j ACCEPT
-A PREROUTING -p udp -m udp --dport 1812 -j DROP

И это для системы, гордо заявляющей поддержку онлайн до 1.5М абонентов, но на подступе режем сразу пакеты ???

6) Интересно, как будет раскрываться и загружаться дерево абонентов на 1.5М абонентов...

6) В принципе фаервол - это какой-то ад со всякими редиректами.

7) Структура таблицы на 150 полей на все случаи жизни. при необходимости добавим еще сколько надо. Гениально !!!

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

9) И да - база у всех крэшится при хард-ресете (питание и всё такое) или только в редких случаях не везёт, как нам ?

 

Собирал не специально, что было буквально за неделю плотного знакомства, поэтому 10го пункта нет. Хотя если бы ещё подумал - нашел бы ещё 5-6.

Стоит задуматься...

 

10) Нашел. Девайс давно в дауне, а сесси у абонентов показывает что есть

11) При схеме DHCP вообще непонятно получил абонент адрес или нет.

12) Какие-то постоянные синхронизации с оборудованием и ТВ-порталом. Схема не жизнеспособная для большого кол-ва абонентов

 

 

Хороший обзор, видно что Вы действительно посвятили немало времени теме нашего биллинга. Однако, не всё так плохо как может показаться на первый взгляд.

 

1) Это общая проблема языков программирования, на которую можно найти много мнений. Выберите Вы integer, decimal или float для учета денег - в любом случае столкнётесь с проблемой того хранения данных в современных компьютерах в двоичном виде. Тут дали неплохое объяснение почему многие выбирают именно целые числа для внетреннего учета денег.

2) Ну, это неправда.

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

4) Все верно, учет 1.5м абонентов. Вы сейчас говорите об авторизации. Правила оставили во избежание флуда от неисправных устройств. В принципе, Вы можете убрать это через хуки.

На 1.5м абонентов для авторизации Вам вероятно потребуется поставить несколько десятков серверов провижена.

5) Так же быстро как с 1 абонентом. Дерево не грузится всё целиком когда Вы подгружаете страницу. Если открыть ветвь дерева, загрузите все вложенные папки и до 300 первых абонентов.

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

7) При развитии функционала конечно будет расти и база. Пока я не вижу какого-либо аргумента почему 150 полей в базе - это плохо.

8) Услуга "белый IP" блокируется. Если услуга действительно не может быть удалённо отключена (тут я обычно привожу пример  одного их наших клиентов, который в Carbon Billing 5 ведёт учёт абонентских плат за домофон) - настройте так чтобы списания продолжались.

9) Да, была такая проблема, года 3 назад решили.

10) Если говорим про авторизацию по RADIUS - сессия "умирает" для биллинга если 20 минут не поступал аккаунтинг (можно настроить, если 20 минут - много). Встречали проблемы когда оборудование продолжало считать сессию живой и отправлять аккаунтинг, когда конечное устройство уже давно выключили из сети, но это проблема не биллинга.

11) Настройте схему DHCP+Radius, например это можно сделать в стандартной схеме Cisco-IPoE.

12) Синхронизации есть с любым оборудованием. Синхронизатор решает сетевые проблемы - если на одной из сторон упал канал связи.

 

 

 

В 07.07.2020 в 03:24, vop сказал:

Такое есть в очень многих биллингах из-за идеологической ошибки просчитывать целочисленные величины (копейки, минуты, байты) не целочисленной арифметикой (плаваающей). 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2. Очень даже правда. Поверьте, там везде 6.45

blob.thumb.png.ab712cc7f8f6ea311f37a24cd2858031.png

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2 часа назад, product manager CB5 сказал:

Это общая проблема языков программирования

Это общая проблема криворуких студентов, которых по дешевке набирают на галеры разработку.

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

float может использовать только дурачок.

integer использовать можно, если нет альтернатив (decimal).

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

 

2 часа назад, product manager CB5 сказал:

Пока я не вижу какого-либо аргумента почему 150 полей в базе - это плохо.

Это не плохо, для современных БД разреженная таблица обычно проблем не составляет.

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

Не удивлюсь, если они еще и столбцы вида FIELD1...n используют, типа «пусть будет, вдруг потом пригодится костылей повставлять».

 

2 часа назад, product manager CB5 сказал:

Если говорим про авторизацию по RADIUS - сессия "умирает" для биллинга если 20 минут не поступал аккаунтинг

А про stop-пакеты биллинг ничего не знает? Сессии закрываются только по таймауту?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

23 минуты назад, barguzin2 сказал:

2. Очень даже правда. Поверьте, там везде 6.45

blob.thumb.png.ab712cc7f8f6ea311f37a24cd2858031.png

Феерично.

Ладно, когда в оборотке приходится сводить баланс решением системы уравнений — методики давно отработаны в банках.

Но накопление ошибок округления при суммировании — это фейл.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

22 минуты назад, barguzin2 сказал:

2. Очень даже правда. Поверьте, там везде 6.45

blob.thumb.png.ab712cc7f8f6ea311f37a24cd2858031.png

 

 

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

2. Да, именно об этом я и говорил в первому пункте - при делении 200 на 31 и округлении получается 6.45. В реальности биллинг посчитал корректно - обратитесь к базе, проводки будут на 645000001 или вроде тогою

 

9. База автоматический поднимается из теневой копии. Если при некорректном завершении работы сервера было повреждение ФС - тогда потребуется восстановление из бекапа.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 минуту назад, product manager CB5 сказал:

2. Да, именно об этом я и говорил в первому пункте - при делении 200 на 31 и округлении получается 6.45.

Именно так и поступают студенты-идиоты.

Посмотрите реализацию в нормальных биллингах.

В нормальных биллингах эти накопленные 5 копеек распределились бы по списаниям — либо равномерно, либо бы прибавились к последнему списанию.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

10 минут назад, alibek сказал:

Это общая проблема криворуких студентов, которых по дешевке набирают на галеры разработку.

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

float может использовать только дурачок.

integer использовать можно, если нет альтернатив (decimal).

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

 

Это не плохо, для современных БД разреженная таблица обычно проблем не составляет.

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

Не удивлюсь, если они еще и столбцы вида FIELD1...n используют, типа «пусть будет, вдруг потом пригодится костылей повставлять».

 

А про stop-пакеты биллинг ничего не знает? Сессии закрываются только по таймауту?

Как раз Integer и используется. Так же есть и архитектор продукта - архитектура базы растёт ведь не просто так, а под новый функционал.

 

Безусловно биллинг знает про Stop пакеты и получив их, отражает в системе абонента как более не авторизованного.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я говорю что не сходится, вы говорите неправда и пытаетесь в чём то убедить. А тут ведь всё наглядно. Зачем тогда выводить дневные суммы вообще, если они посчитаны "примерно".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

5 минут назад, barguzin2 сказал:

Я говорю что не сходится, вы говорите неправда и пытаетесь в чём то убедить. А тут ведь всё наглядно. Зачем тогда выводить дневные суммы вообще, если они посчитаны "примерно".

Посчитаны они как раз верно. Проблема только в отображении в веб-интерфейсе.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2) Детализация по расходу. Если сложить дневные суммы, то не сходятся с итогом

 

Ещё раз повторю тогда (1 в 1). Что здесь неправда? Я привёл скрин. Проблема с отображением... Ну так исправьте, в чём вопрос то....

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.