vop

А закон по закону? :)

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

Там же не спрашивают, можно или нельзя... Там спрашивают, где есть. :)

Любой storage service, или vps. Тот же hetzner. Поддерижвает дофига чего, включая ftp и ftps. Для хранения бакапов за пределами своей территории - криптуйте их.

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

При припейде не может быть "неудачной" попытки списания. На то он и припейд, что предоставляется только "уже оплаченная" услуга. А описанная мною схема совершенно спокойно реализует и припейд, и постоплату, и начисление 1-го числа. Она даже учитывает возможность устанавливать разную стоимость услуги в разные дни (была такая мода - делать на праздники дешевый, со скидкой, или бесплатный интернет). Все зависит от желания собственника бизнеса и типа предоставленных услуг. PS У моего провайдера кабельного тв в условиях оплаты стоит строгое предупреждение, что оплачивать нужно точную сумму месячной абонплаты. Ни меньше, ни больше, иначе оплата не будет зачислена. :) У них тоже биллинг свой. :)

Как раз, наоборот, это чистая схема с предоплатой. Сколько заплатил - столько и работаешь. Услуга не только непрерывная, но и отключаемая. Это и позволяет ее контролировать балансом. А вот если снижаешь лимит блокировки, то и появляется база постоплаты. Риск "невозврата" долга за обещанный платеж в обмен на экскоммуникацию клиента, проживающего по фиксированному адресу адресу - пренебрежительно мизерная утрата, что бы о ней напрягаться. :) Ежели клиент извернется, и подошлет тёщу вместо себя, чтобы восстановить услугу, то оплата нового подключения (нового лица) будет заметно больше, нежели неоплаченные пару дней обещанного платежа.

Я знаю. Лень поправить. :)

И еще чуток. Я бы вообще отдал ведение лицевых счетов нафиг каким-нибудь банкам или платежным системам. Ну т.е. вообще с концами. Если бы, например, система изменяемой блокировки в банковском пластике работала нормально, то было бы замечательно. Тогда работа биллинга вообще упростилась бы до простой схемы. Биллинг регулярно повышал бы сумму блокировки на размер предоставленных услуг, а по окончанию месяца просто проводил бы батч на наработанную сумму. И что там у клиента, как он пополняет свой счет в платежной системе, какие он там беркт кредиты - никого не волнует. :) Кстати, балансовая система широко применяется во многих странах при учете обычных коммунальных услуг. Например, в Китае по коммунальному пластику, или в Японии на серверах учета. Вода, газ, свет - закончилось, автоматом отрубилось, сбегал в ближайший терминал, или залез на банковский сервер, или вообще через WeChat денежек закинул - хлоп, водичка и пошла... :)

Работая второй десяток лет могу только сказать, что мало кто слушает какие-либо разумные доводы. Что засело в голове, то и долдонят, порой даже не могут объяснить, зачем "им так хочется". :) Но вы же знаете, как все это должно работать! :) Но раз вы советуете что-то описать, могу кратенько, тезисно. 1. Услуга интернета - это услуга НЕПРЕРЫВНОГО и РАВНОМЕРНОГО характера. Она предоставляется не разово и поштучно, как другой товар, а постоянно, увеличивая свою стоимость в постепенно возврастающем темпе (поминутно, почасово, посуточно). 2. Учет непрерывной услуги должен вестись таким же равномерным балансовым способом. Баланс услуги составляется из двух составных частей: - статическая составняая часть - остаток на счету абонента; -динамическая часть - сумма предоставленных неоплаченных услуг на данный момент. Для простоты, бонусные программы тут не будем учитывать, ибо они так же могут быть частью баланса. 3. Вся суть учета состоит в мониторинге состояния баланса относительно установленого лимита (предела предоставления услуги). По умолчанию лимит равен самой минимальной отрицательной величине учета. Например -0.01 рупь. При балансе = 0 вроде денег нет, но нет и "долга", поэтому услуга должна предоставляться. При желании, как вариант, может быть введена кредитная система методом снижения лимита. Например, при установке лимита в -20, клиент может "кредитоваться" на 20 рупей. 4. "Списание" абонплаты проводится в самый удобный момент в 00:01 первого числа каждого месяца. "Списание" заключается в занесении суммы уже предоставленных услуг за прошедший месяц в историю операций текущего счета. При этом, состояние счета уменьшается на абонплату, размер динамической части баланса увеличивается на ту же сумму за счет перевода предоставляемых услуг в статус "оплаченных", которые исключаются из мониторинга. В результате, баланс не изменяется в момент "списание", и предоставление услуг никак не зависит от этого момента списания. В этом и заключается посуточный непрерывный балансовый учет. 5. Поведение системы в момент снижения величины баланса ниже установленного лимита (-0.01) может отличаться в зависимости от "пожеланий начальства". Например, можно блокировать доступ, но продолжать считать стоимость услуги, увеличивая ее каждый день. Можно заморозить доступ, прекратив увеличения суммы услуги. А можно считать до конца месяца, заморозив услугу с начала нового месяца. Ну или еще что, не суть важно. Задача абонента - следить за своим балансом (а не за остатком на счету), и вовремя его пополнять, что бы услуга не отрубилась. Если вдруг прошляпил, то он может воспользоваться временным доступом, что называют "обещанным платежом", при котором доступ может быть открыт на какое-то определенное время, либо снижением лимита на определенный уровень. Но это уже другая история. Описанная схема работает на столько железобетонно, что ни разу не пришлось менять ее за очень много лет. Какие-то "забаганки" (капризы) клиентов легко подключаются к существующей схеме. Например, захотелось очень клиенту, что бы некоторые услуги "начислялись" сразу же 1-го числа (это касается услуг, которые нельзя поминутно блокировать - например, domains), то всего-лишь изменяется способ начисления динамической части баланса - не поминутно, не посуточно, а единоразово с 1-го числа. При этом, балнсовая система не меняется. Вот как-то так. Что тут не понятного или загадочного - скзать сложно. Да и изобретать тоже, как по мне, нечего.

Как все сложно... Я думал, что форматы начисления абонплаты уже обсуждены много лет назад. Неужели билингописатели до сих пор не освоили балансовую схему учета абонплаты? :)

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

Что бы не зависеть от версий шелла или системДы, не проще ли в самом скрипте указывать и шелл, какой использовать, и вывод, куда редиректить?

Если один рутер научить кушать маршруты второго, то чем icmp redirect не решение? Если, конечно, у видны с этим нет проблем? :)

Стёб или издевательство? :)