""

Дом для SMS.
Или что такое сервис смс-рассылки и как с ним бороться

Вступление
Несмотря на то что СМС пророчат скорую смерть, в связи с приходом WhatsApp’ов и прочих интернет-приложений, она таки еще далековато. Идет не спеша и будет идти еще лет, эдак, 10. И дойдет она только тогда, когда интернет в мобильных устройствах будет у 99% населения земного шара и будет работать без сна и отдыха 7/24/365 (а иногда и 366). Поэтому еще есть смысл об этом говорить, писать и читать.
И речь здесь пойдет о том, как построить такую систему, в которой смскам будет комфортно жить и работать.
Система эта предназначена для работы на уровне агрегатора, коллектора (в хорошем смысле этого слова. Не путать с долговыми коллекторами!).
По сути, даже не важно рассылка чего планируется, SMS или почтовых писем, все подобные системы похожи. Можно брать за основу одну и строить другую, со своими целями и задачами.
В данной статье речь пойдет о тех трудностях, которые обязательно будут встречаться по ходу строительства этого «Дома».

Фундамент

Он, как обычно, состоит из «железа» и некоторого набора несамописного программного обеспечения.
Всем, конечно, хочется подешевле, побыстрее и покачественнее, но, жизнь показывает, можно выбрать из этого списка желаний только два пункта.
Исходя из подешевле и побыстрее спокойно можно взять Linux/Unix сервера, БД MySQL или ее клоны и Perl (который и ставить уже не придется). Для покачественнее надо смотреть уже в сторону Oracl’а.
Серверов надо, как минимум, 3 штуки: БД, ядро системы, интерфейсы (административный, клиентский). Этот минимум лишь позволит системе работать. Если будет все “в одном флаконе”, то не ждите от системы ни стабильности, ни скорости. В идеале, надо, кроме этих 3-х, иметь еще сервер архивов (при хорошем трафике объемы будут не маленькие, держать все устаревшие данные лучше отдельно от оперативной БД), сервер статистики, север мониторинга.
БД сразу съест оперативки гигов эдак 10, не меньше, и диска от 1 Тбайта (причем, SAS или SSD. SATA не подойдет). Это из расчета на 500 тыс СМС/сутки. Ядру же столько диска не надо, разве что на логи, хватит и 200Г, и оперативки раза в 2 меньше чем БД. Если предполагается хранить всю историю рассылок за все время, то надо рассчитывать дисковое место и на эти данные, а это тоже около 200 Гб/год.
“Три звездочки, четыре звездочки, но, лучше конечно, пять звездочек…”. Речь, конечно, не о коньяке, а об отказоустойчивости. Пять 9-ток — необходимый уровень для работы, например, с банковским сектором и с транзакционным трафиком. Иначе — как позволит совесть и кошелек. Вообще, вопрос отказоустойчивости серверов, сетевых шлюзов, выбора площадок и т.п. — это отдельная тема, которая в интернете развита довольно хорошо и которая довольно хорошо опустошает карманы и кошельки. Здесь надо искать компромисс, и у каждого он свой.

Стены, комнаты, коридоры

Распределяем пространство на зоны…
Какими коридорами пойдет СМС, войдя в дом? Прежде чем попасть к боссу-оператору (читать — абоненту-получателю), оно должно пройти следующие инстанции:
Добро пожаловать!
Или посторонним вход воспрещён!
Открываем дверь — коннект, пришел клиент с СМСками.
Основным протоколом до сих пор остается SMPP, версии 3.4, хотя уже давно существует 5-я. Но, независимо от версии, есть большая проблема с безопасностью — логины и пароли идут в открытом виде. Т.е., при желании, можно без особого труда их добыть из сетевого трафика со всеми вытекающими…Поэтому надо позаботиться и об этом, завернув SMPP-трафик в какой-нибудь зашифрованный туннель. Вариантов масса, на любой вкус (гуглим, выбираем).
Не все клиенты поддерживают туннели, поэтому приходится оставлять и прямое соединение.
Кроме SMPP, существуют и другие варианты для клиентов — HTTP, SOAP и пр. Они уже сами по себе могут быть с поддержкой SSL, но тут нет стандартов. Каждый агрегатор придумывает свой формат обмена данными, как правило, не совместимый с остальными, что клиентам, конечно, не нравится. Хотя, с другой стороны, если вдруг захотят перейти к другому поставщику, то столкнутся с проблемой поиска программиста, который писал и/или будет писать клиентскую часть под другой формат. Такая заподлянка )
Далее — авторизация. Тут ничего интересного нет, кроме одной рекомендации. Многие проверяют баланс счета клиента и не пускают если баланс пуст. Мое мнение — пускать всегда и пусть клиент заливает свои смски в базу. Просто не надо отправлять их дальше пока не заплатит, если работает по предоплате (об этом потом будет подробнее). Таким образом вы покажете, что всегда рады видеть клиента и процесс проще продолжить, когда уже все подготовлено. После приема такого трафика можно известить клиента об отсутствии необходимых денег путем отправки ему статусов сообщений с соответствующим кодом ошибки.
Если есть время, желание и навыки работы с различным ПО, то стоит обратить внимание на вопрос интеграции потусторонних программ с нашей платформой. Тем более, что на данный момент уже существуют модули, например 1С, позволяющие отправлять сообщения через различных агрегаторов.

Считалочка.
Или раз, два, три, четыре, пять.

Каждое поступившее сообщение должно, естественно, иметь уникальный идентификатор. Используются для этого, как правило, цифровые, хотя можно и буквенно-цифровые.
Часто, в качестве такого идентификатора, берут значение auto_increment при вставке в БД. Это простой вариант, но не лучший.
А лучший — это генерация своего ID средствами скрипта-приемника. Что это дает? Во-первых, появляется возможность записывать смски в БД пачками, а не по одной на запрос — скорость увеличивается в разы. Во-вторых, если настроена репликация баз по схеме мастер-мастер, то, скорее всего, идентификаторы будут идти через 1 и более, в зависимости от количества реплик (как-то некрасиво). В-третьих, идентификатор может нести больше информации чем просто порядковый номер, что бывает иногда полезно…
Я, в свое время, использовал 20-ти значный ID в составе которого было UNIX-время, порядковый номер в секунде (сразу видна скорость приема), идентификатор процесса принимающего скрипта и порядковый номер экземпляра системы, в случае использования дублирующих приемников.

Разборки.
Или что мы знаем об SMS.


А знать нам надо не мало. Прежде чем отправить смс абоненту надо определить следующее:
• Страну, регион, оператора, временную зону получателя.
Это все узнаем по номеру абонента. Для этого надо запастись базой DEF-кодов (https://www.rossvyaz.ru/docs/articles/DEF-9x.html), базой миграции номеров между операторами (MNP, www.zniis.ru/bdpn/check), данными по регионам и часовым поясам. Кроме того, информация в этих базах обновляется несколько раз в сутки — это тоже надо учесть при разработке системы.
Знать какой часовой пояс необходимо для отправки абоненту СМС в его время бодрствования. Вряд ли кому-то понравится если сообщение о какой-нибудь акции придет часа в 3 ночи по местному времени.
• Тип трафика. Основных 3 типа:
• Балк — массовые рассылки рекламного характера. Такой трафик характеризуется низким процентом дошедших до адресатов СМС. Не критичен к скорости прохождения сообщений, но зато важно учитывать часовой пояс абонента.
• Транзакционный — коды подтверждений финансовых операций и другие подобные сообщения. Полная противоположность балк-трафику. Сообщения должны доходить быстро и надежно, и не важно 3 часа ночи или 9 вечера.
• Общий — все остальное. По характеристикам — нечто среднее между первыми двумя типами.
• Тестовый. Это особый тип трафика. Полезен, как правило, для новеньких клиентов, которые настраивают свою систему. Или если нам самим надо провести анализ работы системы, при этом не тратя деньги на отправку реальных СМС.

Тип трафика, в последнее время, определяется шаблонами текста сообщений, которые заранее согласовываются с клиентом и оператором. Это наиболее надежный способ определения, который, к тому же, позволяет избежать спам-рассылок (преследуется и жестоко наказывается). Можно, конечно, договориться с клиентом и распределять типы трафика, например, по учетным записям в системе, или по именам отправителей, но далеко не все клиенты соблюдают договоренности.
Возможно, клиенту запрещено использовать какой-то тип трафика, поэтому нет смысла тратить силы и время процессоров на дальнейшую обработку.
• Количество частей (сегментов), из которых состоит сообщение.
Спецификация SMS позволяет отправлять только 160 символов в 7-ми битной кодировке GSM 03.38 или 70 символов в юникоде UCS-2. Более длинные СМС разбиваются перед отправкой на несколько частей и, затем, собираются в телефоне абонента в единое сообщение. Также надо учитывать, что если СМС длиннее одной части, то кол-во символов в каждой части будет уже 153 (7 bit GSM) / 67 (UCS-2).
Тарификация везде и всюду осуществляется именно посегментно.
• Корректность текста сообщения.
По сути, это проверка на запрещенные слова и на спам.
Спам-фильтр — это непростая и отдельная тема, поэтому пока только Черный Список отдельных слов и фраз.
Этот список должен применяться к конкретному клиенту и/или для всех. Должен содержать как конкретные слова/фразы, так и шаблоны, например, в виде регулярных выражений.
Также надо учитывать, что некоторые хитрецы составляют слова из смеси цифр, латинских и кириллических символов, чтобы обойти этот фильтр. Если видим «микс», то сразу рубим, иначе можно схватить штраф от оператора. С такими клиентами лучше не связываться. Как показывает практика, головной боли от них больше чем денег.
• Дубликат.
Если вдруг случилось какое-то несчастье, и клиент начал нещадно долбить наш приемничек одними и теми же смсками, то можно все это честно пропустить, доставить тыщу смс абоненту, отчитаться об этом и списать кругленькую сумму со счета клиента. Но вряд ли кто-то обрадуется.
Поэтому так делать не будем, а сделаем настроечку, привязав ее к аккаунту клиента, типу трафика, шаблону текста (если есть) и к имени отправителя. И будем оперативно проверять сколько таких СМС уже приняли за сутки и сколько еще можно принять. Остальное аккуратно складываем в БД, можно в отдельную таблицу чтоб не мусорить, и ждем что скажет на это клиент и решить дальнейшую судьбу этих дублей.
• Группа рассылки.
Часто возникает необходимость группировать партию СМСок и присваивать этой группе название. Как правило, это надо клиенту, у которого нет своего интерфейса, но который очень любопытный и ему надо знать как можно больше.
Если клиент забыл или не захотел указывать при отправке идентификатор группы (а протокол SMPP в принципе это не поддерживает), то можно попытаться сгруппировать сообщения самостоятельно.
Группа сообщений характеризуется одинаковым или схожим текстом, одинаковым, для всех сообщений, именем отправителя и небольшим промежутком времени, в течение которого клиент передает трафик на сервер. По этим 3-м признакам можно, с вероятностью 99%, правильно сгруппировать СМСки.
• Подстановки.
Еще одна приятная для клиента возможность. Правда, для ее реализации, сам клиент должен составить некоторые соответствия.
Например, если составить таблицу соответствия номера абонента и его ФИО, то клиент может добавить в текст СМС тег , а наша дружественная система заменит этот тег на конкретный текст ФИО. Тем самым клиенту не надо париться и генерить для каждого сообщения свой текст.
Ну вот и встретили СМСку. Что дальше?

Ждемс.
Или до первой звезды нельзя.

Далеко не всегда СМС уходят навстречу абоненту сразу, и чайку не попив. Надо уметь их задерживать по разным причинам. Вот некоторые из них:
• СМС отправлено с учетом часового пояса абонента. Если у абонента ночь и он сладко спит, то не стоит его будить — надо дождаться утра.
• День Рождения еще не скоро, а поздравительное СМС уже пришло к нам. Конечно мы не знаем когда у абонента День Рождения — об этом нам сообщает клиент в каком-нибудь параметре протокола (кроме SMPP).
• Клиент нажал у себя в ПО на кнопочку, а потом сказал “Ой…”. Если трафик приличный, то будет время нажать на кнопку “Пауза”, которая любезно предоставлена разработчиками нашего ПО в виде команды в протоколе и/или в виде кнопки в Личном Кабинете. Весь трафик этого клиента тут же останавливается и ждет дальнейших указаний.

Перекресток.
Или правила дорожного движения.

Прокладываем оптимальный маршрут. И делаем это непосредственно перед отправкой СМС оператору.
Заранее это делать не стоит, поскольку ситуация может меняться довольно быстро и часто. Бывают сетевые проблемы. Бывают большие очереди (под Новый Год, например). Бывает сбой оборудования у оператора/агрегатора. Или просто их сисадмин сошел с ума и обрезал все провода…
Задача эта уже ложится на модуль передатчика.
Надо позаботиться о том, чтобы у СМС была возможность достигнуть цели несколькими путями. Это особенно важно для транзакционного трафика. Но прежде надо узнать еще кое-чего.
• Имя отправителя.
Имена отправителей, на момент написания статьи, должны проходить регистрацию у оператора и у агрегаторов, которые подключаются к этому оператору. А это значит, что если Имя прошло регистрацию только у одного оператора, то к другому можно и не пытаться отправлять СМС с таким же Именем — абоненту ничего не дойдет.
Кроме того, за каждое Имя надо платить каждому оператору отдельно.
Также, иногда, приходится подменять одно имя другим.
• Стоимость.
Ее стоит определять непосредственно перед отправкой в сторону абонента.
Бывают такие ситуации, когда клиент решает распланировать все рассылки на год вперед (и это еще не предел). А за год может произойти все что угодно. В частности, может подешеветь нефть прямо повлияв на стоимость SMS и, если уже все посчитали, придется пересчитывать.
Стоимость, на данный момент, рассчитывается за отправленные СМС. Хотя несколько лет назад, расчет велся по доставленным сообщениям.
Стоимость также может определять маршрут. Если клиент жадный и хочет все подешевле, то выбрав дорогой маршрут можно уйти в серьезный минус.
Итак. У нас есть несколько соединений (каналов, шлюзов) с разными операторами/агрегаторами и есть СМС, которые уже пора отправлять.
По сути, выбор канала — это комплексная задача, в которой надо учитывать все параметры СМС и самого шлюза.
Естественно, не стоит отправлять в загруженный канал транзакционные СМС.
Нельзя отправлять СМС с именем отправителя, которое не прописано. Либо надо менять имя, либо выбирать канал где оно одобрено.
Если отправили СМС, но не получили из канала ответ о его получении — не спешите отправлять снова. Сначала надо узнать причины (не забываем писать логи). Возможно сообщение было успешно получено оператором и уже дошло до абонента.
Если отправили СМС, но не получили отчет о доставке, то, в зависимости от настроек клиента-отправителя на нашей платформе и типа трафика, надо попытаться отправить по другому доступному пути. Тут надо понимать, что отчет о доставке может прийти позже — возможно абонент просто едет в метро и его аппарат просто не может принять СМС.
Также надо предусмотреть возможность переотправки администратором в ручном режиме через другой канал.
При повторной отправке есть два неприятных момента. Во-первых стоимость сообщения увеличивается кратно количеству попыток. Кто возьмет на себя эти расходы — вопрос политический, но это должно гибко настраиваться на уровне системы. Во-вторых, абонент может получить несколько одинаковых СМС когда выйдет из метро.

Письма счастья.
Или судьба SMS.

Каждый клиент желает знать где находится СМС. И чем быстрее он это узнает — тем лучше для всех.
Задачка, на первый взгляд, несложная — получаем статус от оператора и передаем его клиенту, предварительно записав в БД. Но тут сталкиваемся с рядом проблем.
Часть статусов может по дороге потеряться. Связано это, в частности, с тем, что везде используется протокол SMPP и, практически, никто не повторяет передачу статусов если не было получено подтверждение о приеме (deliver_resp). Т.е. по разным причинам мы не получили статус и больше его не получим.
Может быть недоступным длительное время абонент, и если время, в течение которого идут попытки доставить СМС, достаточно большое, то статус мы увидим не скоро (если вообще увидим).
Бывает такое, когда сообщение состоит из множества частей, а память телефона уже заполнена и влезает, по факту, только часть большого сообщения. В этом случае мы получаем несколько статусов “доставлено” и остальные “ошибка доставки”.
Что делать? Можно “пнуть” оператора/агрегатора, чтобы пошли нам навстречу и дослали недостающие статусы. Это лучший вариант для учета, но не лучший для скорости и требует ручного вмешательства.
Можно собирать статистику “надежных” абонентов и устанавливать статусы самостоятельно. Т.е. если за продолжительное время абоненту отправлялись СМС, и в течение этого времени абонент их успешно получал, то, с большой вероятностью, он получит СМС и в этот раз. Это не лучший вариант для статистики, но лучший для скорости обработки и для клиента.
После получения статуса надо определить к какому сообщению он принадлежит. Для этого, на этапе отправки СМС, мы сохраняем идентификатор, полученный от оператора. Этот же идентификатор будет передан вместе со статусом.
Использовать наш ID здесь не получится (привет от SMPP), а так хотелось бы… Этот факт портит нам жизнь и скорострельность системы, ибо на запись “лишних” данных тоже уходят драгоценные ресурсы. Как вариант, можно использовать что-то вроде memcache, сохранять там связку наш_ID-их_ID, а после получения статуса эти данные просто удалять. Для истории и поиска глюков, лучше еще записывать в лог.
Разработчики SMPP, видимо поняв что они натворили, решили как-то сгладить свою вину и ничего лучше асинхронного режима не придумали. Поэтому, воспользовавшись такой возможностью, мы поднимаем еще один коннект на прием. В итоге можем одновременно и отправлять сообщения и получать по ним статусы. Ура, товарищи!
Немного порадовавшись мы понимаем, что радовались рано. Если тупо пулять СМС оператору, не глядя на количество отчетов о доставке, можно не заметить проблему и нарваться на массовую переотправку сообщений. Дело в том, что приняв СМС, оператор их аккуратно складывает в буфер, и не факт что тут же отправит абоненту. Если мы перестали получать статусы, или процент доставленных СМС резко упал, то стоит приостановить отправку до выяснения причин.
А вот с клиентами лучше так не поступать. Если не получили от него подтверждение приема отчета о доставке, то надо не полениться и отправить его еще раза 2-3. Если клиент упорно не хочет отчитываться о получении, то либо отчеты ему не нужны, либо у него техпроблемы. В любом случае надо приостановить передачу отчетов и поинтересоваться о причине такой ситуации.
Кроме финальных статусов, которые уже никогда не изменятся, неплохо было бы информировать клиента о промежуточных статусах, показывая текущую стадию обработки, местонахождение СМС. Никто не мешает, кроме стандартных отчетов, посылать свои. Далеко не всем клиентам это надо, поэтому выводим такую возможность в настройки и, по умолчанию, отключаем.
После того как получили очередной статус от оператора сразу добавляем его в агрегированную статистику, чтобы потом не тратить силы и время на сбор статы по всем СМСкам за какой-то интервал времени.
Особое мнение.
Я люблю хранимые процедуры в БД. Если ими грамотно пользоваться, то можно значительно упростить жизнь себе и другим соседям-программистам. Не секрет, что в MySQL такой вид программирования слабо развит, в отличие от Оракла, например. Ведется много споров по этому вопросу, но мое мнение такое: если вы не любите кошек, то вы просто не умеете их готовить.
По-хорошему, основную логику работы системы надо вынести в БД. Принял от клиента СМС-ку, записал ее в табличку базы и всё. Дальше за дело берутся процедурки внутри БД, вычисляют характеристики СМС, определяют маршрут, стоимость, проверяют на спам, фильтруют по спискам (черным, белым, серым, фиолетовым…). Тут же можно сразу заняться сбором статистики, используя триггеры. Результат всех манипуляций записывается в таблицу, из которой уже забираются данные для передачи боссу — сотовому оператору. В итоге, внешне-скриптовая писанина сводится к созданию приемника и передатчика, кои пишутся довольно просто (есть хороший стабильный модуль на Perl’е). Вся система, при этом, приобретает хорошую масштабируемость, что немаловажно если захочется нарастить мощность.
Кладовка
Или склад для клада
Если дела пойдут хорошо, то за год уже накопится приличный объем информации, которая в основной работе уже не нужна, но в которой надо будет иногда покопаться и что-то найти. Причем, по возможности, быстро.
Искать придется по любым параметрам, которые есть у СМС. Группировать и суммировать по большим периодам. Анализировать трафик по направлениям, операторам, словам в текстах, и т.д. и т.п.
Архив, по-хорошему, надо держать на отдельном сервере, чтобы не делить ресурсы с рабочими модулями системы.
Агрегировать данные или хранить их в «чистом» виде – это совсем другая история, не для этой статьи. На этот вопрос лучше ответят специалисты, работающие с поисковыми системами.
БИЛЛИНГ
Минимум что надо нам знать, это сколько нам должен клиент, и сколько мы должны операторам/агрегаторам.
Объемы, обычно, не маленькие, но точность от этого страдать не должна. Поэтому все поля, хранящие денежные цифры, должны иметь, как минимум, 4 знака после запятой (вроде уже писал об этом, но повтор не будет лишним). Также не забываем о том, что в MySQL для этого подходит только тип DECIMAL. Остальные типы содержат недопустимые погрешности, от которых будет кому-то грустно.
От чего зависит стоимость сообщения, точнее одного сегмента:
· страна
· оператор
· имя отправителя
· объем трафика (обычно за месяц)
· тип трафика (транзакционный, балк, прочее)
· шаблон сообщения (иногда одно и то же что и тип трафика)
Условия могут использоваться как все сразу, выборочно, так и отдельно.
Т.к. далеко не все видят будущее, поэтому мало кто знает какое количество и по каким ценам получится по итогам месяца. В связи с этим, надо готовиться к пересчету месячного трафика в начале каждого месяца. Такие расчеты обязательно будут между нами и оператором, и выборочно между нами и клиентом.
Удобнее считать, конечно же, по агрегированной статистике, т.к. эти данные будут содержать только нужную информацию, объем которой относительно небольшой. Агрегировать данные надо по всем параметрам, от которых зависит цена.
Справочник по ценам, в обязательном порядке, должен иметь историю изменений. Причем совершенно не обязательно для этого создавать отдельную таблицу, достаточно добавить поле для даты начала действия цены. Благодаря этому вы всегда можете пересчитать суммы задним числом за любой период времени.

Система расчета баланса клиента

В связи с пересчетами возникает необходимость корректировать баланс клиента, что лучше делать отдельными записями, а не просто перезаписью конкретного числа.
Вообще, баланс – это несколько таблиц, а не одно поле. Если баланс будет хранится в БД в виде одного числа, то, в случае возникновения вопросов типа «почему тут 10 а не 25», концов днем с огнем не сыщешь.
Поэтому создаем таблицу где будут храниться все изменения баланса (финансовые события), кроме расхода по трафику, и при каждой записи также будем хранить состояние баланса до и после финсобытия.
Рядышком создаем табличку с перечнем возможных финсобытий, т.к. этот список не фиксированный и будет периодически изменяться. Вот краткий список того, что точно в нем будет:
· Пополнение счета, платеж
o Банковский перевод
o Электронный платеж
· Расход по трафику
· Корректировка, ежемесячный пересчет
· Списание за платное имя
· Бонус, пополнение баланса для тестовых СМС
Расход по трафику складываем в свою табличку, группируем данные, как минимум, по дням и по аккаунтам. Можно также разбить еще по именам отправителя, по именованным рассылкам и т.п., но это уже скажется на производительности. Нам надо быстро суммировать все данные за текущий день чтобы понять имеет право клиент отправить очередное сообщение или уже его денежки закончились.
Как Вы, наверное, догадались, суммировать расходы и доходы за прошедшие дни надо 1 раз в сутки, ибо они уже не изменятся и нет смысла тратить на это вычислительные ресурсы при каждом запросе текущего баланса.
Здесь, вроде, всё.
Сигнализация
Дом, напичканный всякой всячиной, настоятельно рекомендуется защитить охранной сигнализацией чтобы знать, что происходит если вас нет дома.
Мы тоже поставим датчики на все «двери» и «окна». Это важно, если мы хотим, чтобы наш сервис был на высоком уровне.
Есть множество уже готовых программных комплексов для мониторинга, об этом на Хабре, в частности, уже много чего понаписано. Надо лишь грамотно написать и внедрить «датчики», которые, кстати, можно и нужно определить еще на стадии проектирования системы.
Кроме собственной системы проверять стоит и самих операторов, ибо они тоже грешат, у них тоже бывают «глюки», кривые настройки, которые мешают прохождению трафика. Как вариант, можно использовать модем(ы), вставить в него симку и смотреть как доходят СМС и с какой скоростью. А заодно проверяем правильность отчетов о доставке. С помощью модема можно сэмулировать поломку абонентского аппарата и посмотреть на реакцию оператора, иногда она забавная…
Разумеется, система мониторинга должна работать четко и стабильно и иметь уровень безотказной работы не менее 99,999%. Иначе смысла в ней нет, если она будет ломаться чаще чем сама платформа.
Бумажки
В любой системе, работающей с деньгами и людьми, необходимо формировать всякого рода договоры, отчеты, акты, счета и т.п.
Можно использовать для этого любое стороннее ПО, если лень писать свое (а писать придется мнооггооо…). Но, так или иначе, формировать циферки придется своими силами, т.к. внешние программки ничего не знают о нашей системе и едва ли когда-нибудь узнают.
Что нас тут ждет:
· Точность цен фактическая – 3-4 знака после запятой. В документах – не более 2-х. То, что округляется и не попадает в документы, хоть и меньше копейки, но по итогам года может создать большую проблему.
· Если клиент платит сразу несколькими способами (нал, безнал, Webmoney…), то счет-фактуру, например, надо формировать только на суммы, поступившие через банковский перевод. Кроме того, в счет-фактуре должна быть цифра реального расхода денег, пришедших по безналу, а не всей суммы платежа. Поэтому итоговые расходы надо делить между платежами, их типами, и уже на основании этой информации формировать документы.
· Периодически надо изменять логику работы и дополнять уже подписанные с клиентами договоры приложениями и дополнительными соглашениями, т.к. операторы постоянно меняют цены и другие условия. Также выходят новые законы, которые также отражаются на логике и на взаимоотношениях с клиентами.
Я не бухгалтер, поэтому не отслеживаю изменения в правилах создания документов. В процессе проектирования обязательно проконсультируйтесь со специалистами в этой области чтобы учесть все текущие нововведения.

За статью отдельное спасибо Алексею Зиновьеву. Компания Тера смс (terasms.ru)

Original source: habrahabr.ru (comments, light).