Перейти до

Релизы Ubilling


Рекомендованные сообщения

Доброе время суток! Вопросец к DarkSpider ... Вы как то выкладывали скриптик по бекапу, вообщем решил его использовать.

 

Скрипт автобекапа. Потом просто rsync его на внешнее хранилище.


#!/bin/sh

BACKUP_DIR="/var/www/backup"
MAX_AGE=7

SYSTEM_DIRS="/etc /var/www/billing"
MYSQLDUMP="/usr/bin/mysqldump"

##############################################################
DATE=`date +%Y%m%d`

cd $BACKUP_DIR; mkdir $DATE; chmod 740 $DATE; cd $DATE;

tar cf - $SYSTEM_DIRS | gzip > system.tar.gz
chmod 740 system.tar.gz
mkdir sql; chmod 740 sql; cd sql;
/usr/bin/mysqldump --add-drop-database --single-transaction -uroot -psqlpass stg | gzip > mysql.sql.gz

chmod 740 mysql.sql.gz

##############################################################
cd $BACKUP_DIR
for i in *; do
AGE=`echo $DATE-$i|bc`
if [ $AGE -gt 69 ]; then
AGE=`echo $AGE-69|bc`
fi
if [ $AGE -gt $MAX_AGE ]; then
rm -rf $i
fi
done

 

подправил немного пути. но ругается типа:

 

tar: Removing leading `/' from member names

./bck_bil: 31: bc: not found

[: 31: -gt: unexpected operator

[: 31: -gt: unexpected operator

 

что за "bc"? да и "-gt: unexpected operator"

 

ОС Debian squeeze.

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 1,2k
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Да кстати если кому то нужен шаблон для свича то вот  можно воспользоваться такой штукой  шаблоно-генератором

Преувеличиваем? Ничего особенного и нового я не сделал

Ни один единорог не пострадал? =)

Posted Images

tar: Removing leading `/' from member names

 

Это tar ругается, да и не совсем ругается то ...

В архивах хранятся только относительные пути, поэтому tar предупреждает что / в начале пути игнорируется.

 

что за "bc"?

 

не пробовали:

 

apt-get install bc

 

?

 

[: 31: -gt: unexpected operator

[: 31: -gt: unexpected operator

 

Ставьте

 

#!/bin/bash

 

Вначале скрипта.

sh видимо не понимает оператора gt (больше), либо используйте знак ">".

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

felixio_01

 

чем не устраивает консоль?

 

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

 

не пробовали:

 

apt-get install bc

 

я то думал bc какой-то оператор или ещё что-то... всё установил, спасибо за подсказку.

 

#!/bin/bash

 

понял.

 

всё заработало, спасибо.

Ссылка на сообщение
Поделиться на других сайтах
WARNING: attempt to domain_add(netgraph) after domainfinalize()

Откуда в ядре netgraph? mpd что-ли используете для подключения к прову?

 

WARNING: Host declarations are global. They are not limited to the sc

Можно не обращать внимания, всего лишь нотификация о том что сабнеты в одном скоупе ака шаред сабнете. Оставлено для совместимости.

 

Есть очень нехорошие подозрения, что интернет у ваших абонентов пропадает и не подымается при обрывах ppp сессий изза того, что например может дефолтраут уходить в пустоту. Либо потому, что экземпляр НАТа поднят на уже убитом давно интерфейсе.

 

felixio_01

 

я то думал bc какой-то оператор или ещё что-то... всё установил, спасибо за подсказку.

а чего, оно в этих ваших линуксах из коробки не того? :)

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

nightfly

поднимаю ppp через rc.conf + ppp_nat="NO".

 

Проблема не в дефолтрауте, так как ppp поднимается, ifconfig > tun0 - есть IP от сервера провайд.

 

Заметил, что трабла появляется после ребута, такое чувство, что ppp поднимается быстрее ipfw, а тот в свою очередь не видит поднятый tun0.

есть подозрения на mpd, может вкрутить его в ядро?

 

PS

стандартный бекапер не включает в себя последнюю таблицу (weblogs)? truncate table weblogs или примутить кнопку на странице бекапа:

<?php
mysql_query("TRUNCATE TABLE  weblogs");
?>

Ссылка на сообщение
Поделиться на других сайтах
а чего, оно в этих ваших линуксах из коробки не того? :)

 

))))) да вот незнаю, незнаю... Linux'ы они такие-всяко разные ))))

P.S. обновился до нового релиза, буду пробывать подкрутить новую фишку.

 

http://www.opennet.ru/dev/fsbackup/

 

попробуйте, как вариант.

 

да знаем про это штуку, это как бы коородинальное решение ))). мне нужно было только данные билинга бекапить, его базу, конфиги.

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

а чего, оно в этих ваших линуксах из коробки не того? :)

 

В Ubuntu Linux Server имеется. Там вообще немного более расширенный набор по сравнению с Debian, собственно поэтому я его и выбрал.

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

Пожелание для ubilling-а:

 

- api ПриватБанк.

- В списке "Онлайн" сделать метку о "Пользователь отключен/заморожен".

- выплывающее окно (Jquery) на странице Кабинета при получении нового сообщение от Помощи.

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

Назрел такой вопросец:

 

У меня абонплата снимается размазанно (то бишь каждый день). И те абоненты которые не платят, есесно уходят в минус... и этот минус постепенно становиться большИм))) . Далее, когда такого минусованного абонента пополняем, в ubilling ставится капча "Установить счет" и потом зачисляются деньги. Всё как бы понятно. Но! со временем возможно будем вводить карты опалты. как быть в этом случае? т.е. как вот такой абонент ушедший далеко в минус будет оплачивать, тобишь активировать карту оплаты? ведь, при большом минусе все деньги уйдут на погашение этого минуса...

 

и есть ещё небольшая хотелка )))..

 

опять же связанная с размазанным снятием абонплаты (nightfly наверно будет сейчас ругаться ))) ):

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

 

Текущее состояние счета 133.548389, чего должно хватить еще на 1 месяцев пользования услугой

 

хотя у абонента 100 грн-ый тариф. :blink:

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

DarkLan

 

- api ПриватБанк.

В wiki модуля платежных систем постоянно упоминаются если внимательно посмотреть. Еще также можно заметить, что со временем они уходят в открытый доступ и распространяются в комплекте с Ubilling. В частности приватбанк давно есть и успешно работает, точно так же как и оплата кредитками и еще черти-что.

 

- В списке "Онлайн" сделать метку о "Пользователь отключен/заморожен".

А еще "всегда онлайн", "телефон", "мобилку", "Мыло", "пароль" и все остальные существующие поля. И главное забыть после этого о адекватной работе с абонбазами нормального размера.

Думал всегда, что очевидно зачем, в этом модуле постепенно выкусились такие штуки как "LAT", "Онлайн" и прочие поля - для банальной оптимизации скорости выборок.

 

- выплывающее окно (Jquery) на странице Кабинета при получении нового сообщение от Помощи.

Смысл? Если хочется live-чатика для этого есть существующие решения типа kayako или siteheart, которые:

1. предназначены именно для этого

2. елементарно интегрируются куда угодно

 

Но если очень хочется кустарную поделку "под себя" то ценник как всегда обсуждаем.

Ссылка на сообщение
Поделиться на других сайтах
У меня абонплата снимается размазанно (то бишь каждый день).

Ну вы уже понимаете, что я сейчас скажу? :)

 

И те абоненты которые не платят, есесно уходят в минус... и этот минус постепенно становиться большИм)))

И вы конечно же как самый добрый в мире человек считаете это лично своей проблемой....

Закон прост - "no money no honey" © Не потрудился оплатить вовремя - провайдер не должен голодать.

 

Далее, когда такого минусованного абонента пополняем, в ubilling ставится капча "Установить счет"

какая еще бл...дь каптча? :blink:

 

Всё как бы понятно.

не знаю как вам, а я уже запутался

 

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

И это опять же проблемы абонента не соизволившего платить в установленных провайдером рамках. На крайняк для таких есть существующий механизм "самоотмораживания" в ЛК приостанавливающий снятие АП, скажем при уезде в отпуск. В противном случае он должен либо оплатить задолженность той же карточкой, терминалом, приватом, кредиткой, чертом лысым, либо попросить доброго провайдера выровнять счет (помните, что я говорил про 1,612903225806452 гривны в день?, кхе-кхе).

 

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

 

Из логичных - перестать считать каждого абонента своим родственником и другом. Законы товаро-денежных отношений просты - no money no honey, либо если еще проще то "потрудись оплачивать установленные мной сумы денег в установленные мной сроки для того, чтобы получать за них определенные блага". Это ничем не отличается от торговли шкурками мамонтов в позднеледниковый период и полностью нормально, если продающий эти самые шкурки не является благотворительной организацией.

 

опять же связанная с размазанным снятием абонплаты (nightfly наверно будет сейчас ругаться ))) ):

выучили уже, хорошо :D

 

в настоящее время есть что то вроде в профиле пользователя:

Есть и работает в контексте нормальной механики взаиморассчетов используемой 99.8% операторов работающих с Ubilling.

 

хотя у абонента 100 грн-ый тариф. :blink:

Логично. А вы ожидали там увидеть, что "этого должно еще хватить на 1 месяц 10,24844720496894 дней и 8,928000000000002 часов" ой не Бл#, сегодня же февраль(!) тогда "этого должно хватить на 1месяц 12 дней и 7.9873842434 часов".... ой нет же, сейчас еще и високостный год....

 

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

 

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

 

Ой, чойта я все о грустном?

Рекомендую не воспринимать последних несколько абзацев. Это чисто так, мысли в слух, не имеющие более характера рекомендаций. В любом случае если у вас есть конкретные ТЗ для решения ваших насущных проблем с нетривиальным учетом средств - всегда пожалуйста, вплоть до развития и поддержания чисто под вас отдельной ветки биллинга. Как всегда ценник обсуждаем. И да - потом меня будет еб...ть моя совесть. Точнее уже еб...т.

 

ЗЫ Ах, да как я уже говорил в ту сторону миграция идет в 1 опцию - назад нормального пути уже нет.

ЗЫ2 фраза года - "я же говорил" (С)

Ссылка на сообщение
Поделиться на других сайтах
У меня абонплата снимается размазанно (то бишь каждый день).

Ну вы уже понимаете, что я сейчас скажу? :)

 

 

В идеале для наших реалий необходимо конечно немного другое. Необходимо непривязка к первому числу месяца. Т.е. нужно чтобы можно было пополнять абонента в любой день месяца и до любого числа месяца. И этот вопрос вроде поднимался другими участниками сего уважаемого форума. Т.е. допустим пришёл абонент 12 числа пополнил свой счёт, и до 12 числа следующего. Или что тоже очень важно, опять же в связи с нашми реалиями (о которых чуть ниже) пришёл абонент захотелось ему в этот раз не на месяц оплатить, а на 15 дней, или на 45 дней,- пожалуйста без проблем. А ежедневное снятие денежных средств-это как альтернатива того чего нельзя зделать (или я незнаю как? ) в ubilling+stargazer в данное время (искренне надеюсь (вот думаю стоти ли? ))) ) что в будущем этот функционал появиться).

 

 

И те абоненты которые не платят, есесно уходят в минус... и этот минус постепенно становиться большИм)))

И вы конечно же как самый добрый в мире человек считаете это лично своей проблемой....

конечно же нет. Но как говорится "мы думаем о всех и сразу"

 

 

 

Закон прост - "no money no honey" © Не потрудился оплатить вовремя - провайдер не должен голодать.

этот жестокий мир бизнеса...

 

Далее, когда такого минусованного абонента пополняем, в ubilling ставится капча "Установить счет"

какая еще бл...дь каптча?

сори, ну может не так обозвал, читай как radio button "Установить счет"

 

 

Всё как бы понятно.

не знаю как вам, а я уже запутался

 

да неможет быть, я верю в Вас!

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

И это опять же проблемы абонента не соизволившего платить в установленных провайдером рамках. На крайняк для таких есть существующий механизм "самоотмораживания" в ЛК приостанавливающий снятие АП, скажем при уезде в отпуск. В противном случае он должен либо оплатить задолженность той же карточкой, терминалом, приватом, кредиткой, чертом лысым, либо попросить доброго провайдера выровнять счет (помните, что я говорил про 1,612903225806452 гривны в день?, кхе-кхе).

 

Такой принцип у нас используется в цифровом КТВ (предоставляем услуги аналогового и цифрового кабельного ТВ). Но! этот принцип был с самого начала, и абонент уже так сказать наученный и знает нужно первого числа оплатить зомбоящик. (подозреваю возгласы типа: "no money no honey" © и "я же говорил" (С) )

 

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

 

вполне приемлемое решение, только как?

 

Из логичных - перестать считать каждого абонента своим родственником и другом. Законы товаро-денежных отношений просты - no money no honey, либо если еще проще то "потрудись оплачивать установленные мной сумы денег в установленные мной сроки для того, чтобы получать за них определенные блага". Это ничем не отличается от торговли шкурками мамонтов в позднеледниковый период и полностью нормально, если продающий эти самые шкурки не является благотворительной организацией.

 

жжёшь однако )))).

 

 

опять же связанная с размазанным снятием абонплаты (nightfly наверно будет сейчас ругаться ))) ):

выучили уже, хорошо

ну так, разговор поднимался не раз, и знаю Вашу реакцию на это. ))

 

 

 

хотя у абонента 100 грн-ый тариф.

Логично. А вы ожидали там увидеть, что "этого должно еще хватить на 1 месяц 10,24844720496894 дней и 8,928000000000002 часов" ой не Бл#, сегодня же февраль(!) тогда "этого должно хватить на 1месяц 12 дней и 7.9873842434 часов".... ой нет же, сейчас еще и високостный год....

 

нет, в от здесь к стати, ожидал увидеть "этого должно хватить на столько то дней", без месяцев и часов и т.п. просто столько то дней (5, 10, 35, 43 и т.п.)

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

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

 

предидущий билинг (если помните TI) вполне так работал довольно долго по принципу:

 

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

 

и как бы нормально.... проблем не было... Там, право сказать, не использовался принцип ежедневного снятия абонплаты. Но опять же повторюсь (см выше), ежедневное снятие абонплаты - это альтернатива. Но в остальном, всё тоже о чём я говорил.

 

 

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

 

тарифных сеток больше да филалов несколько.

 

Ой, чойта я все о грустном?

Рекомендую не воспринимать последних несколько абзацев. Это чисто так, мысли в слух, не имеющие более характера рекомендаций. В любом случае если у вас есть конкретные ТЗ для решения ваших насущных проблем с нетривиальным учетом средств - всегда пожалуйста, вплоть до развития и поддержания чисто под вас отдельной ветки биллинга. Как всегда ценник обсуждаем. И да - потом меня будет еб...ть моя совесть. Точнее уже еб...т.

 

я прекрасно понимаю что ubilling+stargazer это open source и универсального продукта тоже не бывает и что Вы каждую "хотелку" не можете (возможно не хотите) выполнить. Но! ))) форум для того и нужен чтобы высказывать свои мнения, обсуждать их и в конце концов зделать мир лучше ))))) и данный продукт в частности (я даже галочку поставил в " Я хотел бы помочь сделать Ubilling лучше" ). А по поводу ТЗ, я к сожелению финансовые вопросы не решаю (на мне только техническая сторона фирмы), но могу на них влиять. И конечно же в бюджет нашей небольшой фирмы ограничен. Так что постараюсь достать денег и уже разговор будет на другом уровне.

а совесть, она такая... очень опасная... нет нет и нагнуть может :D

 

ЗЫ Ах, да как я уже говорил в ту сторону миграция идет в 1 опцию - назад нормального пути уже нет.

 

PS: если не ошибаюсь у киевстара (на дух их не перевариваю, ничего личного, просто осадок от их подрядчиков нехороший остался- оптику нашу порезали), тоже списание денежных средств ежедневное, не?

хотите сказать они это зря зделали?

 

ЗЫ2 фраза года - "я же говорил" (С)

учту конечно.

 

По поводу реалий. У нас городишко то небольшой около 30 тыс насел, может больше. Этажек тоже не так много. И на это хилинький городишко аж четыре крупных провайдера не считая нас (хотя мы являемся не большим провайдером) и УкрТелекома. Конкуренция жёсткая, поэтому диктовать "как хотите приходите первого числа и платите за инет и типа не еб....т" не катит. Или типа проштрафил абон несколько дней после начала месяца, и пришёл платить позже... ему ведь не объяснишь что типа ты опоздал абонплата будет взята за полный месяц и не еб...т. он просто развернётся и уйдёт к другому прову, благо выбор большой. так как бы вот так.

 

 

ЗЫЫ: ого сколько накалякал, сам в шоке

Ссылка на сообщение
Поделиться на других сайтах
А ежедневное снятие денежных средств-это как альтернатива того чего нельзя зделать (или я незнаю как? ) в ubilling+stargazer в данное время (искренне надеюсь (вот думаю стоти ли? ))) ) что в будущем этот функционал появиться).

Не угадали, у снятия АП есть еще много вариантов :)

 

сори, ну может не так обозвал, читай как radio button "Установить счет"

Какое бл...дь еще "установить счет"?

Для выравнивания счета радио "Корректировка сальдо" - не светится в оплатах, не портит финотчет, светится в логе и имеет инкрементный характер.

 

вполне приемлемое решение, только как?

Впилить +1 условие в модуль creditor кабинета пользователя.

 

ну так, разговор поднимался не раз, и знаю Вашу реакцию на это. ))

так я скоро еще начну в агонии биться и слюной капать :D

 

нет, в от здесь к стати, ожидал увидеть "этого должно хватить на столько то дней", без месяцев и часов и т.п. просто столько то дней (5, 10, 35, 43 и т.п.)

бррр, я месяцов то по порядку не знаю а вы от меня таких умных штук ожидаете :)

Ссылка на сообщение
Поделиться на других сайтах
предидущий билинг (если помните TI) вполне так работал довольно долго по принципу:

Да, помню такой - есть штатный конвертер, в среднем 2 миграции в месяц. Кому надо налетай - сотка за конверт АБ любого размера :)

 

и как бы нормально.... проблем не было... Там, право сказать, не использовался принцип ежедневного снятия абонплаты. Но опять же повторюсь (см выше), ежедневное снятие абонплаты - это альтернатива. Но в остальном, всё тоже о чём я говорил.

Ну во-первых я так понимаю fullfee есть для управления уровнем вашей "честностью". Во вторых с ним всеравно получаются адовые дроби и непонятки. Как избавиться от ада и содомии я уже объяснял - потратить около 10 секунд при регистрации абонента и забыть навсегда о неровных цифрах.

 

тарифных сеток больше да филалов несколько.

ну у вас и нервишки.

 

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

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

 

PS: если не ошибаюсь у киевстара (на дух их не перевариваю, ничего личного, просто осадок от их подрядчиков нехороший остался- оптику нашу порезали), тоже списание денежных средств ежедневное, не? хотите сказать они это зря зделали?

Да, посуточное + пускает в инет без оплаты в минус на сумму тарифа.

И нет. Какраз там такой подход оправдан. Как и Option82. Почему так - можете попробовать догадаться самостоятельно :)

 

 

По поводу реалий. У нас городишко то небольшой около 30 тыс насел, может больше. Этажек тоже не так много. И на это хилинький городишко аж четыре крупных провайдера не считая нас (хотя мы являемся не большим провайдером) и УкрТелекома. Конкуренция жёсткая, поэтому диктовать "как хотите приходите первого числа и платите за инет и типа не еб....т" не катит. Или типа проштрафил абон несколько дней после начала месяца, и пришёл платить позже... ему ведь не объяснишь что типа ты опоздал абонплата будет взята за полный месяц и не еб...т. он просто развернётся и уйдёт к другому прову, благо выбор большой. так как бы вот так.

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

 

- Подключился 15 числа? Нет проблем, оплати 50 грн за пол месяца и сиди себе в интернете. 1 "Фиктивный платеж" чтобы отображалась оплата в кабинете.

- Не успел оплатить до первого? Вот тебе кредитовалка в кабинете на "Х" дней - хочешь платная, хочешь бесплатная.

- Уезжаешь в отпуск и не хочешь увидеть через 2 месяца на счету -200 грн? Вот тебе замораживалка.

- Не умеешь пользоваться замораживалкой? Улыбчивые девочки на кассе сделают тебе по приходу "коректировку сальдо" на 100 грн(а че, логично все - услуга как таковая то не предоставлялась) + оплату которую ты принес еще на 100 грн.

 

Ну да, попервых выглядит страшно, и закрадываются какие-то наивные страхи за девочек - но когда приходится оперировать только целочисленными суммами в пределах полностью прозрачных и понятных сум 0, 50, -50, 100, -100 это на практике не вызывает никакого дискомфорта.

 

В финале вы просто понимаете откуда берутся эти цифры и какими они должны быть. Это и есть настоящее удовлетворение :)

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

...

сори, ну может не так обозвал, читай как radio button "Установить счет"

Какое бл...дь еще "установить счет"?

Для выравнивания счета радио "Корректировка сальдо" - не светится в оплатах, не портит финотчет, светится в логе и имеет инкрементный характер.

...

Яке, бл...ть, сало? :)

Ссылка на сообщение
Поделиться на других сайтах
Какое бл...дь еще "установить счет"?

Для выравнивания счета радио "Корректировка сальдо" - не светится в оплатах, не портит финотчет, светится в логе и имеет инкрементный характер.

 

чем плох "установить счет"?

 

Впилить +1 условие в модуль creditor кабинета пользователя.

есть такая директива? или будет? что то не соображу.

 

бррр, я месяцов то по порядку не знаю а вы от меня таких умных штук ожидаете :)

 

да ладно прибедняться... :D

Ссылка на сообщение
Поделиться на других сайтах
чем плох "установить счет"?

Он пишется в "реестр оплат", потом задолбетесь вникать почему у вас касса не сходится и кто кому чего понаустанавливал. Чтобы такого не допускать и есть "Коректировка саласальдо".

 

есть такая директива? или будет? что то не соображу.

Нету, напишете - будет :)

 

Там 1 if (...) {... } else {... }

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

 

)))) пока не жалуемся.

 

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

а автоматизация разве не способствует упорядочеванию (во какое слово)

 

Да, посуточное + пускает в инет без оплаты в минус на сумму тарифа.

И нет. Какраз там такой подход оправдан. Как и Option82. Почему так - можете попробовать догадаться самостоятельно :)

 

Option82 это вообще отдельная тема... )))))

 

 

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

 

я в Вас не сомнавался ни на сек!

Ссылка на сообщение
Поделиться на других сайтах
Он пишется в "реестр оплат", потом задолбетесь вникать почему у вас касса не сходится и кто кому чего понаустанавливал. Чтобы такого не допускать и есть "Коректировка саласальдо".

 

ок, понял, спасибо за разъяснения

 

Нету, напишете - будет :)

 

Там 1 if (...) {... } else {... }

 

как всегда всё гениальное просто....

Ссылка на сообщение
Поделиться на других сайтах
а автоматизация разве не способствует упорядочеванию (во какое слово)

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

 

Option82 это вообще отдельная тема... )))))

Да. Отдельная. А почему так догадываться оставлю вам. Оно там полностью обосновано и логично.

 

я в Вас не сомнавался ни на сек!

Поделитесь уверенностью - мой психиатр говорит что вроде как ее, не хватает :)

Ссылка на сообщение
Поделиться на других сайтах
Гость
Эта тема закрыта для публикации сообщений.
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент

    • Від ppv
      Потрібно було витерти одну мережу, всі абоненти з неї були перенесені в іншу. Але світить що 6 IP зайняті, хоча вона повністю вільна.
       
      ID    Мережа/CID           RВсього IP        Використано IP ▾           Вільно IPСервіс
      6      172.16.70.0/23        506                    6                                       500
       
      Підкажіть як правильно це підчистити щоб видалити мережу.
    • Від ppv
      Проглянув FAQ і Ubilling Wiki. Зацікавило питання чи є в Ubilling якась реалізація reCAPTCHA, чи потрібно додавати руцями, (для прикладу для форми подачі заявок чи для кабінету користувача)?
       
    • Від sanyadnepr
      Приветствую всех.
      Подскажите пожалуйста где копнуть и нет ли проблемы со стороны протокола взаимодействия сити24 или возможно не учтена необходимая проверка в модуле сити24 в Ubilling, пока писал понял что похоже в проверке payID, но это не точно.  
      Недавно обнаружилось с сити24 начали прилетать дубликаты платежей, в целом платежей мало, два одинаковых запроса Pay с одинаковым transactionID и payID в одну секунду одному платежному ID при этом биллинг "думает" примерно чуть больше минуты и отвечает одним ответом <result>0</result>, сити24 утверждает что ответ они не получили и по протоколу дальше повторяет запросы дублем, биллинг ответ и так по кругу, сити24 спрашивает каким образом с одинаковым payID от сити24 билл продолжает обрабатывать запросы и пополнять абоненту счет раз в 5 минут примерно, на одну и туже сумму, ведь этот payID уже был обработан предполагают сити24 согласно протоколу.
      Конечно есть вопрос к сити24 зачем они дублем присылают два запроса, но они отвечают что эта ситуация учтена в протоколе и проблема на стороне биллинга, потому что он пополняет счет по уже обработанному одинаковому payID.
      При этом transactionID в дублях одинаковый, но с каждым новым дублем разный.
      Если зафаерволить запросы от сити24, но оставить возможность отвечать то после блокировки билл отправляет 2-3 минуты 6 ответов <account>0001</account>  <result>0</result>.
      После снятия блокировки, дубли и платежи нескольких проблемных абонентов прилетают так же по кругу, при этом и с некоторыми новыми пополнениями происходит аналогичная ситуация.
      В openpayz в платежах transactionID и не видно payID.
    • Від nightfly
      Ubilling 1.4.3 rev 9058 The Bladewood Grove
       
      Зміни в структурі БД. alter.ini: нові опції OPHANIMFLOW_ENABLED та OPHANIMFLOW_URLS котрі вмикають та керують інтеграцією з OphanimFlow. alter:ini: нова опція PHOTOSTORAGE_POSTPROCESSING, що вмикає післяобробку зображень при завантаженні в Сховище зображень. alter:ini: нова опція PHOTOSTORAGE_WATERMARK, що вмикає розміщення вотермарки на всіх зображеннях, що завантажуються. alter:ini: нова опція PHOTOSTORAGE_RECOMPRESS, що вмикає зміну компрессії завантажених зображень. alter:ini: нова опція PHOTOSTORAGE_AUTORESIZE, що вмикає автоматичне та лагідне масштабування зображень конячих розмірів. alter:ini: нова опція PHOTOSTORAGE_DRAWIMGINFO, що вмикає вдруковування в зображення відлагоджувальної інформації. alter.ini: нова опція ONDEMAND_CHARTS, що вмикає відкладене завантаження графіків завантаження користувацької смуги. userstats.ini: нова опція OPHANIM_ENABLED, що вмикає інтеграцію OphanimFlow в кабінеті користувача. Модуль Заздрість: тепер авторизаційні дані пристроїв, не відображаються в списку пристроїв. Модуль “Заздрість”: при створенні та редагуванні пристроїв, для полів “пароль” та “enable пароль” тепер використовуються інпути паролів. Модуль “Заздрість”: заздрісним пристроям додано нове поле “Порт”. Тепер в скриптах можна використовувати, відповідний макрос {PORT}. Модуль “Статистика трафіку користувача”: проведено радикальний рефакторинг. Модуль “Статистика трафіку користувача”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Статистика трафіку користувача”: виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Модуль “Статистика трафіку користувача”: додано можливість відображення графіків за останню годину з OphanimFlow. Модуль “Користувачі”: додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Модуль “Сховище зображень”: тепер додатково перевіряє завантажувані зображення на тему їх валідності. Модуль “Фінансові операції”: виправлено відображення суми платежів користувача. Remote API: новий виклик ophanimtraff, який просто бере і синхронізує локальну БД з віддаленими джерелами OphanimFlow. Remote API: виклик userbynum тепер також опційно містить поле з “Платіжним ID” користувача. Глобально: у всіх полях вводу паролів, окрім форми входу, тепер відображається елемент керування “показати/приховати” пароль. Кабінет користувача: в модулі “Трафік” додано опційну можливість, відображення трафіку отриманого з OphanimFlow. Кабінет користувача: в модулі “Трафік” виправлено проблему невірного відображення залишку коштів на кінець місяця, при використанні Ішимури. Кабінет користувача: в модулі “Відеоспостереження” для NVR WolfRecorder замінено розділювач попередньо заповнених даних авторизації. OpenPayz: додано frontend portmonemulti, для отримання платежів від різних контрагентів. Інформацію по контрагентам бере з біллінгу, також використовую розширену інформацію контрагента. Платіжна система в контрагенті мусить бути створена, як PORTMONE 1984tech: додано функціонал генерації RPZ для isc-bind, спасибі @misterromanbush  
      Повний чейнджлог
      Оновлена демка
       

    • Від mac
      Здається, після оновлення PHP 7.4 до PHP 8.2 feesharvester припинив працювати:
       
      /usr/local/bin/curl "http://127.0.0.1/billing/?module=remoteapi&key={SERIAL}&action=feesharvester" <br /> <b>Fatal error</b>: Uncaught TypeError: Unsupported operand types: string - string in {UBPATH}/billing/api/libs/api.fundsflow.php:570 Stack trace: #0 {UBPATH}/billing/modules/remoteapi/feesharvester.php(22): FundsFlow-&gt;harvestFees('2024-01') ...  
      Невеличке розслідування врешті з'ясувало, що це через наявність пробілу у деяких логінах абонентів. Як так сталося? Тому що інколи був неуважно додан трейлінг пробіл до номеру будинка і цей пробіл потрапив до логіну абоненту. Логін абоненту неможливо змінити ніяким чином штатними засобами. Я не розглядаю створення нового абонента для усунення помілки.

      Був обран такий шлях вирішення проблеми. Заміну функції php explode() знайшов у мережі. Мабуть це станеться в нагоді:

       
      diff api.fundsflow.php.bak api.fundsflow.php.new 559c559 < $eachfee = explode(' ', $eachline); --- > $eachfee = preg_split("~(?<!\\\\)(?:\\\\{2})*'[^'\\\\]*(?:\\\\.[^'\\\\]*)*'(*SKIP)(*F)|\s+~s" , $eachline);  

×
×
  • Створити нове...