Друзья, нужна помощь.
Есть организация. Предоставляет телемаркетинговые услуги населению. Количество абонентов, ну пусть будет до 5 млн.. Сейчас основной учет ведется в самописной биллинговой системе на Оракле. Обсчет абонентов производится раз в месяц (я так понимаю, это основная нагрузка на базу). В целях экономии и уменьшения инерции текущей системы у руководства проскочила мысль перевести биллинг на 1С. Посмотрел по рынку: вроде решения есть.
Собственно вопрос к людям в теме: Сможет ли 1С? Стоит ли вообще двигаться в этом направлении?

Самое первое предложение отказаться от обсчета раз в месяц

тогда будет равномерная нагрузка в течении месяца и затем уже можно переходить

(0) в БП3 сейчас есть абонентские договора, не подходит?

Пффффф.... конечно сможет. Но всё, конечно, зависит от решения и от реализации.

Билдинг вроде в типовых есть. В УНФ точно: https://its.1c.ru/db/updinfo#content:434:1:issogl2_5 Раз есть, значит сможет

что за телемаркетинговые услуги?

>В целях экономии и уменьшения инерции текущей системы

делайте прототип. потом делайте изменение по аналогии с тек. системой. снимайте ключевые метрики

какой смысл в гибкости 1с если она будет обсчитывать текущую базу в два раза меньше? или замедление от количества данных будет по экспоненте? или изменения структуры регистра будет идти сутками

>обсчитывать текущую базу в два раза меньше

больше

Хотя если генерировать счета весь месяц круглосуточно, то надо по 7 000 счетов в час делать. Так то серьезная нагрузка

(6) Предоставление телевидения.
(9) 2 счета в секунду - серьёзная нагрузка разве?

Не взлетит. Очень большое количество записей, очень тормознутый расчет на 1С будет. Работал с примерно такой конторой - считали на ORACLE, а мне в 1С только готовые тарифицированные записи выдавали. По сути готовые счета.

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

В унф есть билинг, конфа небольшая

(9) можно же и параллельно

(9) Счета на услуги выставляются концом месяца. Сформировать и отдать их клиентам нужно максимум числа до 10-го, если это физлица. Иначе оплата сдвигается пропорционально запаздыванию выставления счетов. Юрлицам вообще до пятого числа максимум акты и счета-фактуры выставить.

(10) ну я пока не видел, например, буху, где счет за секунду проведется :) А тут создать и провести за 0.5 секунды. Но параллельность решит, наверное, проблему, если в блокировки или (11) не упрется

(14) Счета нельзя наперед выставлять? Мне ростелеком присылает счет в ПФД который вообще ничем не отличается, кроме даты. Нельзя их сразу 12 штук создать, например, и высылать мне раз в месяц следующий счет?

(10) Это не телемаркетинговые услуги.

(16) Вы знаете заранее объем услуг, которые будут предоставлены до конца месяца?

(14) Совсем не обязательно выставлять строго концом месяца. Нигде таких законов нет. И период услуг не обязательно должен быть равен календарному месяцу с 1 по 30

(17) Ну а как тогда назвать? :)
(16) Нет. Набор каналов, и соответственно стоимость, может меняться.
(14) Не советуешь?

(20) Биллинг.
Организация - провайдер телевидения или оператор кабельного телевидения.
Посмотрите Amdocs Billing.
На 1С тоже попробуйте. Вдруг получится.

(18) ну я бы делал счет, как в прошлом месяце, а при изменении состава услуг пересчитывал бы счет. Не все же 5 млн абонентов каждый месяц что-то подключают и отключают

(0)
Тут вообще значения особого не имеет на 1С или не на 1С.
Главное - с руками какой степени кривизны это будет реализовано.

(21) Цель не просто перейти куданибудь, а именно на 1с, ибо проги то дешевые

(26) Конечно, всё можно сделать и на 1С. Тут главное правильно организовать таблички.

Я бы предложил сделать наборы пакетов. Расчёт вести для пакетов и наборов, а потом тиражировать на абонентов уже рассчитанные данные.

Замутить кластер серверов и параллельность.

(26) стоимость владения в данном случае складывается не только из стоимости лицензии на софт.

надо еще думать как решать вопрос с быстродействием - обидно будет если продавливать 1с можно будет только  частотой проца и быстротой дисков

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

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

в oracle плюс уже в том что сам обсчет можно сделать в самой субд на pl/sql, а в 1с это только на сервере приложения и накладные расходы на обмен с базой данных

(31) Зато в 1С можно легко менять тарифы и алгоритмы, используя дешёвую рабсилу

(31) Но зато добавить новый тариф гораздо затратнее, чем в 1с

(32) PL/SQL "девелоперы" даже дешевле чем программисты 1С, но продуктивность у них плохая

(29) Обычно данные из Charging Data Record коммутаторов.

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

Поменял бы базу oracle на postgres, расчеты сделал на хранимках, а сводные данные/отчеты через внешние источники данных получал.

Все внутри самописной конфы 1С сделать конечно можно и даже работать будет, но медленнее сильно.

(0) " уменьшения инерции текущей системы" - а можно объяснить, как для групых, что это?

(36) А смысл менять шило на мыло? PL/SQL всяко кошернее.

(37) делают долго

1с не сможет, потому что не предназначена для этого.

1с это учетная система - позволяет пользователям работать с учетом.
Ключевое слово - пользователям.

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

Управлять биллингом, и обмениваться с ним данными - для этого 1с самое то.

(39) тогда может не все задачи озвучены? или у них каждый месяц тарифы менются?

>Управлять биллингом, и обмениваться с ним данными - для этого 1с самое то.

+100500

1С выше этой грязной шняги. Не царское это дело...

(38) стоимость лицензий и нет лишней наценки у девелоперов-ораклоидов

(41) хз. начальство как обычно вряд ли понимает что делает...

(43)+ а sql-запросы писать это извините сча больше половины 1Сников легко ))

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

(43) а спецы по постгри - реальные, а не пытающиеся поставить все из коробки "и откинуться на спинку стула" - давно бесплатными стали?

>а sql-запросы писать это извините сча больше половины 1Сников легко ))

поржал

(45) Ох уж эти мне сказочки, ох уж эти мне сказочники (с)

(48) больше выбешивал после 1с old синтаксис запросов на oracle с условиями join-ов в выражениях where со всякими (+)

(49) + О курсорах я думаю даже не догадывается 99% одноэсников.

(51) Может и не догадываются но постоянно используют и пишут их каждый раз "... = Новый Запрос(..."

(37) (39) (41) (44)
Ну, тарифы меняются достаточно часто. Не то что бы каждый месяц. Но, опять, акции всякие достаточно часто. И сидит кучка разработчиков, которые всё это очень медленно реализовывает.

(52)+ неявно

(51) Курсор — это такая палочка мигающая. Это все знают.

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

(53) а данные для расчета откуда берутся?

(55) И ведь не поспоришь :)

(52) Это не совсем то. Или совсем не то - как посмотреть.

(53) ну может софтина такая - что вменяемо описать эти скидки и прочее нельзя, подняв все на уровень настроек. вот и перепиливают "ядро" каждый раз

а может разрабы такие... меня как-то пытались заставить заниматься софтом в котором интерфейс был декларативный как УФ, но описывался РУКАМИ в xml. через месяц я уже был на новой работе

(56) Если процедурная обработка, а не банальная выборка, то без курсоров сложно обойтись.

(57) Онлайн ничего не собирается. Есть забитые в базу тарифы, услуги. Ну и соответственно расчет ведется исходя из того, какими услугами абонент пользуется.

(53) Маркетологи иногда такого наворотят, что задолбаешься писать. Так что не факт, что он в носу ковыряются.

(59) (62) Все может быть. Так низко не погружались. Но, вроде все акции от маркетологов вменяемые приходят на реализацию.

Может все намного проще через NoSQL (например CouchDB) и принцип map|reduce?

Суть что тут нет фактически кросс-запросов и сводных выборок, простая параллельная-асинхронная обработка кучи клиентов.

В смысле начисления одному клиенту никоим образом не зависят от начислений для других.

>Маркетологи иногда такого наворотят, что задолбаешься писать

мда... кто знает ценообразование аптечное тот в цирке не смеется...

(64)+ http://guide.couchdb.org/draft/recipes.html

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

(66) Как раз аптечное ценообразование очень логичное, это блин все прочие фигней страдают с усреднениями наценки ))

(68) Посчитать сколько строк влезет на лист (а значит нумеровать их) иногда не так просто. 1С тоже делит их  по сути эмпирическим путем. Посмотрите печать той же ТОРГ-12.

(68) а как они их вообще печатают?

может банально надо поискать более продвинутый "report generator"

и вообще это имхо задачи бэкофиса...

может там с архитектурой (или архитектором) проблемы - надо разделять уже на фронт и бэк, а они пытаются все вместе держать

(71) попробуй в запросе пронумеровать по порядку каждый раз с 1 внутри группировки

Ребят, не нужно сейчас в обсуждение того, что есть сейчас уходить.
Сейчас стоит вопрос о смене биллинговой системы, либо кардинальной реорганизации. Интересует компетентное мнение, есть ли смысл смотреть в сторону 1С?

(74) Нет смысла.

Друзья, я поехал в пробке постою. Так что на все возникшие вопросы смогу ответить чуть позже. :)

(74) Если найдешь ЗУП на 5 миллионов сотрудников в 1 базе )

(61) вполне можно сделать. Но оптимизировать придется

(74) Неа.

(73) а зачем нумеровать листы в запросе?

(80) Подозреваю у них вся логика абсолютно на сервере, включая формирование счет-фактур.
Для печати выдаются уже готовые данные которые просто в шаблон вставляются.

(74) задача нетипичная для 1С и 24часовой доступ к системе будет сложно организовать ))

(82) Ну да за копейки и fultime :)

Кста что то я парю, можно же поделить клиентов (раз данные не пересекаются) по "пулам" - небольшим отдельным базам с 1000 клиентов в каждой.

Всего 5 тысяч отдельных баз 1С на хорошем таком кластере из пары сотен серверов.

(84) Конфа будет через РИБ обновляться, причем только конфа, данные никуда не ходят.
Кучу правда допом придется для обслуживания понаписать но в результате

(84) они не пересекаются пока отчеты не захотят сформировать общие

Не взлетит, даже если расчет первых 2-3 месяцев устроит по времени, через полгода год база распухнет и все встанет раком. Личный опыт работы в двух компаниях провайдерах, и проект от франча в страховой компании говорит что 1С с большими объемами не дружит. Не веришь сделай примитивную тестовую базу с документами начисления и оплаты с одним регистром накопления, потом нафигачь туда данных обработкой за год. Даже без расчета на проведение документов может уйти столько времени что вопрос работы биллинга на 1С у тебя сразу будет закрыт

(86) Да согласен между ними по РИБ будут ходить общие данные и НСИ к примеру тарифы/акции и т.д.

А обратно уходить сводные отчеты, которые на уровне выше снова объединяются/суммируются примерно как в Консолидации.

(84)зачем этот ужас с РИБ? Тупо можно считать пакетами .

(89) Для улучшения распараллеливания обработки и ускорения сводов.

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

(90) Проще нанять одного нормального PL/SQL-девелопера, чем городить убогую конструкцию из говна и палок.

они с этими РИБами еще больше хлопот поимеют, выяснять почему обмен с конкретной 400-й базой не прошел по новой акции, и администрировать список баз у каждого конкретного менеджера

(91) (92) Абсолютно согласен, пытаться сделать "это" на 1С не имеет практического смысла ))

Вопрос то был "Сможет ли 1С?"

Я уже предлагал: морду на 1с а сам биллинг в oracle. Записали например в 1с новую акцию - регл задание в плане обмена увидело и отправило в oracle. Формы меняй в 1с хоть через день.  Отчеты и печатные формы делай в 1с какие хочешь, хоть в скд запросом из внешнего источника данных, лучше всяких reports.

(94) И каким образом получится на 1С к примеру за пару дней вывести на печать 5 миллионов пакетов документов (счет-фактур и т.д.)?

(95)+ Без РИБ

(58) не то. Вот выборка результатов запроса похожа больше.

(74) мне кажется, нет. Положите вы лошадку, не вывезет.

(97) Да, аналог полный. Только она на клиенте (в широком смысле этого слова), а в SQL она на самом сервере.

Придется снизить цифру в 99% - оказывается некоторые знают чуть больше обычного SELECT :)

(87) Это лишь значит,что вы не умеете их готовить.

При грамотном ландшафте и коде вполне может.

(99) В терминах процедурного расширения SQL - верно. Но надо заметить, что некоторые технологии, например ADO, трактуют это понятие немного шире, и там есть клиентские и серверные курсоры.
ЗЫ: я пришел из программирования в Oracle :)

(101) может, и можно, но наверняка будет столкновение с трудностями, которых можно было бы избежать, имея прямой доступ до SQL и его процедурного расширения без дополнительных прослоек.

(74) 1С потянет конечно, но стоимость разработки чтобы потянуло не будет дешевым однозначно. А так для примера - сейчас у меня крутится база с 58 млн. записей в регистре накопления, не типовая конечно, тормозов особых нет...

(103) Все зависит от реализации,компетентности специалистов и железа.Oracle database server всего лишь СУБД. Так и с 1с. При грамотном построении решения, грамотном развертывании взлетит вполне.

Думаю,контора совсем не бедная раз только 50 лямов на бумагу тратит ежемесячно

(104) Да, тут особый случай и тут понадобятся мозги, которые не будут дешёвыми.

(0) Если всё работает на Oracle, пусть работает дальше.

А если есть экономический эффект от перехода на 1С, то имейте в виду, что расчёт, скорее всего, будет более долгим, но более гибким, а время (производительность) зависит от программистов, архитекторов и инфраструктуры.

Типовая конфигурация точно не подойдёт. Придётся писать свою с нуля.

(105) 5 млн абонентов * 500 руб средняя цена = 2,5 млрд выручки