Система ввода и обработки платежей за услуги фиксированной телефонной связи Вячеслав Рагузин, начальник цеха информационных технологий ЗАО "Самарасвязьинформ" Итак, что мы имеем? Достаточно прочно стоящую на ногах, динамично развивающуюся телефонную компанию «Самарасвязьинформ», с практически 20 000 абонентов проводной телефонии. Долгие и тщательные поиски недорогой во всех отношениях АСР привели нас в компанию «Крафт-С» неслучайно. Учет абонентских данных, оказанных услуг и платежей абонентов производился в старом добром ДОСе на «самописном» программном обеспечении. Предстоящий переход на повременный учет стоимости телефонных разговоров поставил окончательную, жирную точку на всем имеющемся. Идеи, лежащие в основе построения АСР «ABACS» компании «Крафт-С», привлекли сразу: дружелюбный интерфейс, простота и гибкость настроек, тем не менее, не ограничивающие возможности АСР. Совпали наши ожидания в требованиях и цене используемой СУБД, функциональности АСР, территориально-близкое расположение производителя и группы поддержки, наличие сертификата и что немаловажно – производитель сам использует АСР собственной разработки для схожей деятельности. Процесс переноса данных из старого программного обеспечения и ввода начальных настроек прошел достаточно гладко. Проверили правильность расчетов и возможности печати расчетных документов – все работает быстро и безотказно. Некоторые сложности, возникающие при внедрении АСР, намеренно опущены, поскольку хотелось бы остановиться на проблемах, которые по праву можно назвать «подводными камнями» и подозревать о которых ранее мы просто не могли. Связаны они не со скрытыми недоработками АСР. Речь пойдет о самом простом (как кажется) и самом доработанном (как принято считать) механизме – о вводе информации о платежах, точнее – об особенностях регистрации и обработки платежей потребителей услуг фиксированной телефонной связи. Предъявлять претензии разработчику системы было бы достаточно глупо – АСР имеет мощный и в то же время простой в использовании конструктор создания диалогов для ввода платежей. Система дает возможность строить диалоги для пользователей почти на все случаи жизни. Более того, каждый созданный диалог автоматически привязывается к разнообразным отчетам. Оператор принимает квитанцию, находит нужного абонента, нажимает на кнопку «ввести платеж», вводит сумму, далее волшебная кнопка «Провести» решает все проблемы дебиторской задолженности абонента. Казалось бы, что может быть проще? Тонкость заключается в особенности используемого механизма приема платежей абонентов. Руководство компании, не желая связываться с проблемами и расходами на создание своей сети пунктов приема платежей, возложила эту обязанность на отделения почтамта и Сбербанка, заключив с ними соответствующие договора. По условиям соглашения деньги, принимаемые от абонентов, перечисляются в течение трех банковских дней на расчетный счет организации, а квитанции абонентов, упакованные в бандероли, приносят курьеры в течение пяти рабочих дней прямо в расчетный отдел. Приходит конец рабочего дня – подводим итоги. Часто не сходится – ввели в АСР квитанций на одну сумму, но сами квитанции доказывают другую величину платежей. Начинаем искать ошибку и понимаем, что проверять придется по порядку все введенные платежи, поскольку ошибочный обязательно окажется или самым последним, или в лучшем случае предпоследним. Если в среднем, в зависимости от интерфейса АСР и аппаратного обеспечения, один оператор за один 8-ми часовой рабочий день может ввести до 2000 квитанций, то на поиск ошибки можно потратить уйму времени. Проанализировав сложившуюся ситуацию, приходим к выводу, что существующий механизм ввода платежей, когда каждый платеж вводится поодиночке, удобен лишь для небольшого объема документов, например, для ввода платежей абонентов, являющихся юридическими лицами, количество которых, как правило, меньше, чем абонентов физических лиц. Возникла идея создать в АСР специализированный диалог, названный в последствии «Пакетным вводом платежей», полностью повторяющий порядок действий операторов при работе с большим объемом платежных документов, поступающих в виде бандеролей. Диалог пакетного ввода квитанций обеспечивает не только удобство и скорость ввода информации, но и возможность быстрого поиска и исправления ошибки. Обычно заголовок бандероли содержит информацию о дате перечисления денежных средств, их количестве, информацию об источнике перечисления (банк, почтамт и т.п.). Таким образом, оператор, распаковывая бандероль, может заполнить заголовок. Внутри бандероль состоит из реестров объединяющих квитанции по пунктам приема платежей, которые несут информацию о номере пункта приема платежей и общей суммы перечисления. Реестр объединяет пачки оплаченных квитанций за каждый день. Таким образом, вводя в диалог ввода платежей несколько дополнительных элементов: заголовок для бандероли; номер пункта приема платежей, автоматическое суммирование с сортировкой, и преобразуя его в отдельную сессию для каждой бандероли, значительно уменьшаем вероятность возникновения ошибки. Кроме того, благодаря двум строкам автоматического суммирования в диалоге (одна строка по бандероли в целом, вторая строка зависит от режима сортировки: либо по номеру пункта приема платежей, либо по реестру), оператор замечает ошибку значительно раньше путем контроля промежуточных сумм, а поиск ошибки при вводе квитанций выполняется существенно реже. Впоследствии в этот же диалог была добавлена возможность ввода информации со сканера штрих-кодов, которые печатались на квитанциях абонентов. В итоге, при количестве абонентов в 20 тысяч, в компании «Самарасвязьинформ» всего 4 сотрудника, занятых вводом информации о платежах, при этом, эти же люди обслуживают звонки абонентов, контролируют состояние дебиторской задолженности и составляют статистическую отчетность, без нарушения распорядка 8-ми часового рабочего дня. Диалог «Пакетного ввода квитанций» впоследствии позволил решить и еще одну задачу. В связи с те, что Сбербанк переходит на так называемую «безбумажную» технологию, информация о платежах абонентов передается в виде файла. Структура данных внутри файла отражает информацию из той же самой бандероли, а посему в диалог была добавлена возможность автоматической загрузки данных из файла. Понятно, что скорость ввода информации о платежах увеличилась в несколько раз. Однако появились и новые проблемы, связанные с идентификацией абонента, от которого поступил платеж. Операторы, работающие в банке, не имеют абонентской базы данных и поэтому вводят информацию (номер телефона, номер лицевого счета абонента и ФИО) со слов плательщика, а соответственно существует вероятность ошибки. Поэтому в диалог были добавлены механизмы и инструменты, позволяющие, во-первых, выявлять полное и частичное соответствие данных об абоненте, во-вторых, исправлять ошибочные данные. Следующим этапом развития механизма ввода информации о платежах, явилось решение руководства компании по созданию собственной сети пунктов приема платежей. Не будем вдаваться в обсуждение экономической целесообразности этого решения, по отношению к существовавшему механизму. Скажем так, основной причиной послужило решение о сокращении сроков поступления денежных средств за оказанные услуги. Вместе с тем появилась острая необходимость в соединении специализированных устройств с АСР, фиксирующих кассовые операции и выдающих подтверждение о поступлении платежа абоненту. Кроме того, необходимо было создать и соответствующие специфические механизмы работы кассиров. В качестве упомянутых устройств были выбраны фискальные регистраторы. С созданием механизмов работы кассира дело обстояло сложнее (имеется в виду исправление ошибки) но, как известно – неразрешимых задач не существует. Достоинства режима работы с регистратором неоспоримы: во-первых, нет необходимости в массовой печати квитанций абонентам физическим лицам; во-вторых, исключаются затраты на доставку этих документов, поскольку абонент всегда может узнать точную сумму начислений в кассе; в-третьих, время прохождения информации о платежах абонентов ничтожно мало, а сами средства сразу же оказываются в кассе предприятия. Хочу отметить, что процесс создания отмеченной выше системы обработки платежей был не столь легким и скорым. Весьма вероятно, что она еще не закончена и в дальнейшем могут появиться новые задачи. Однако в итоге обе стороны (и компания «Самарасвязьинформ», и разработчик ЗАО «Крафт-С») остались в «плюсе» – разработчик получил практичное техническое задание для совершенствования системы расчетов и полигон для эксплуатации АСР в реальных условиях, а предприятие связи получило специально адаптированную под свои задачи систему. Я не исключаю, что способов решения проблем, обозначенных в статье, может быть несколько, и та же обработка платежей может быть реализована иначе, и не хуже. Однако вполне возможно, что для компаний, еще не сделавших выбор АСР, будет полезен и наш опыт. Опубликовано: 11.03.2005 Впервые статья была опубликована в журнале "Биллинг. Компьютерная телефония" № 6 2004