Имя: Пароль:
1C
1С v8
Биллинг на 1С за и против
,
0 Heckfy
 
23.05.17
17:07
1. 1С сможет, потому что: 64% (7)
2. 1С не сможет, потому что: 27% (3)
3. Другое 9% (1)
Всего мнений: 11

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

Другое
4 Dzenn
 
гуру
23.05.17
17:10
Пффффф.... конечно сможет. Но всё, конечно, зависит от решения и от реализации.

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

1С сможет, потому что:
6 Волшебник
 
модератор
23.05.17
17:11
что за телемаркетинговые услуги?
7 Господин ПЖ
 
23.05.17
17:15
>В целях экономии и уменьшения инерции текущей системы

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

какой смысл в гибкости 1с если она будет обсчитывать текущую базу в два раза меньше? или замедление от количества данных будет по экспоненте? или изменения структуры регистра будет идти сутками
8 Господин ПЖ
 
23.05.17
17:15
>обсчитывать текущую базу в два раза меньше

больше
9 Fuas4
 
23.05.17
17:16
Хотя если генерировать счета весь месяц круглосуточно, то надо по 7 000 счетов в час делать. Так то серьезная нагрузка
10 Heckfy
 
23.05.17
17:22
(6) Предоставление телевидения.
(9) 2 счета в секунду - серьёзная нагрузка разве?
11 Джинн
 
23.05.17
17:22
Не взлетит. Очень большое количество записей, очень тормознутый расчет на 1С будет. Работал с примерно такой конторой - считали на ORACLE, а мне в 1С только готовые тарифицированные записи выдавали. По сути готовые счета.

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

1С не сможет, потому что:
12 zak555
 
23.05.17
17:24
В унф есть билинг, конфа небольшая
13 Вафель
 
23.05.17
17:24
(9) можно же и параллельно
14 Джинн
 
23.05.17
17:28
(9) Счета на услуги выставляются концом месяца. Сформировать и отдать их клиентам нужно максимум числа до 10-го, если это физлица. Иначе оплата сдвигается пропорционально запаздыванию выставления счетов. Юрлицам вообще до пятого числа максимум акты и счета-фактуры выставить.
15 Fuas4
 
23.05.17
17:28
(10) ну я пока не видел, например, буху, где счет за секунду проведется :) А тут создать и провести за 0.5 секунды. Но параллельность решит, наверное, проблему, если в блокировки или (11) не упрется
16 Fuas4
 
23.05.17
17:30
(14) Счета нельзя наперед выставлять? Мне ростелеком присылает счет в ПФД который вообще ничем не отличается, кроме даты. Нельзя их сразу 12 штук создать, например, и высылать мне раз в месяц следующий счет?
17 Волшебник
 
модератор
23.05.17
17:30
(10) Это не телемаркетинговые услуги.
18 Джинн
 
23.05.17
17:33
(16) Вы знаете заранее объем услуг, которые будут предоставлены до конца месяца?
19 Вафель
 
23.05.17
17:33
(14) Совсем не обязательно выставлять строго концом месяца. Нигде таких законов нет. И период услуг не обязательно должен быть равен календарному месяцу с 1 по 30
20 Heckfy
 
23.05.17
17:34
(17) Ну а как тогда назвать? :)
(16) Нет. Набор каналов, и соответственно стоимость, может меняться.
(14) Не советуешь?
21 Волшебник
 
модератор
23.05.17
17:38
(20) Биллинг.
Организация - провайдер телевидения или оператор кабельного телевидения.
Посмотрите Amdocs Billing.
На 1С тоже попробуйте. Вдруг получится.
22 Fuas4
 
23.05.17
17:38
(18) ну я бы делал счет, как в прошлом месяце, а при изменении состава услуг пересчитывал бы счет. Не все же 5 млн абонентов каждый месяц что-то подключают и отключают
23 pavig
 
23.05.17
17:39
(0)
Тут вообще значения особого не имеет на 1С или не на 1С.
Главное - с руками какой степени кривизны это будет реализовано.

1С сможет, потому что:
26 Вафель
 
23.05.17
17:41
(21) Цель не просто перейти куданибудь, а именно на 1с, ибо проги то дешевые
27 Волшебник
 
модератор
23.05.17
17:44
(26) Конечно, всё можно сделать и на 1С. Тут главное правильно организовать таблички.

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

Замутить кластер серверов и параллельность.
28 Господин ПЖ
 
23.05.17
17:44
(26) стоимость владения в данном случае складывается не только из стоимости лицензии на софт.

надо еще думать как решать вопрос с быстродействием - обидно будет если продавливать 1с можно будет только  частотой проца и быстротой дисков
29 Генератор
 
23.05.17
17:46
а откуда будут браться исходные данные для расчета, и куда будут результаты отдаваться? может узкое место даже не в самом обсчете будет...
30 EugeniaK
 
23.05.17
17:46
Вполне сможет.
Только не типовая конфигурация и самостоятельно сделанная по ту задачу отдельная конфигурация. Но нужно будет решить проблемы параллельной работы нескольких процессов одновременно.

1С сможет, потому что:
31 Генератор
 
23.05.17
17:53
в oracle плюс уже в том что сам обсчет можно сделать в самой субд на pl/sql, а в 1с это только на сервере приложения и накладные расходы на обмен с базой данных
32 Волшебник
 
модератор
23.05.17
17:54
(31) Зато в 1С можно легко менять тарифы и алгоритмы, используя дешёвую рабсилу
33 Вафель
 
23.05.17
17:55
(31) Но зато добавить новый тариф гораздо затратнее, чем в 1с
34 Garykom
 
гуру
23.05.17
17:58
(32) PL/SQL "девелоперы" даже дешевле чем программисты 1С, но продуктивность у них плохая
35 Джинн
 
23.05.17
17:58
(29) Обычно данные из Charging Data Record коммутаторов.

Но есть еще один нюанс - предоплатные услуги. По ним нужно выдавать данные на коммутатор при достижении лимита. Причем если показатели не натуральные, а стоимостные, то тарифицировать их предварительно.
36 Garykom
 
гуру
23.05.17
18:01
Поменял бы базу oracle на postgres, расчеты сделал на хранимках, а сводные данные/отчеты через внешние источники данных получал.

Все внутри самописной конфы 1С сделать конечно можно и даже работать будет, но медленнее сильно.
37 Дарлок
 
23.05.17
18:02
(0) " уменьшения инерции текущей системы" - а можно объяснить, как для групых, что это?
38 Джинн
 
23.05.17
18:02
(36) А смысл менять шило на мыло? PL/SQL всяко кошернее.
39 Господин ПЖ
 
23.05.17
18:02
(37) делают долго
40 Jump
 
23.05.17
18:02
1с не сможет, потому что не предназначена для этого.

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

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

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

1С сможет, потому что:
41 Дарлок
 
23.05.17
18:03
(39) тогда может не все задачи озвучены? или у них каждый месяц тарифы менются?
42 Господин ПЖ
 
23.05.17
18:03
>Управлять биллингом, и обмениваться с ним данными - для этого 1с самое то.

+100500

1С выше этой грязной шняги. Не царское это дело...
43 Garykom
 
гуру
23.05.17
18:04
(38) стоимость лицензий и нет лишней наценки у девелоперов-ораклоидов
44 Господин ПЖ
 
23.05.17
18:04
(41) хз. начальство как обычно вряд ли понимает что делает...
45 Garykom
 
гуру
23.05.17
18:04
(43)+ а sql-запросы писать это извините сча больше половины 1Сников легко ))
46 Генератор
 
23.05.17
18:05
можно и совместить, морду сделать на 1с, и дублировать из нее данные о тех же тарифах во внешнюю базу на oracle, а критичные к производительности операции делать в самом oracle
47 Господин ПЖ
 
23.05.17
18:06
(43) а спецы по постгри - реальные, а не пытающиеся поставить все из коробки "и откинуться на спинку стула" - давно бесплатными стали?
48 Господин ПЖ
 
23.05.17
18:06
>а sql-запросы писать это извините сча больше половины 1Сников легко ))

поржал
49 Джинн
 
23.05.17
18:08
(45) Ох уж эти мне сказочки, ох уж эти мне сказочники (с)
50 Генератор
 
23.05.17
18:10
(48) больше выбешивал после 1с old синтаксис запросов на oracle с условиями join-ов в выражениях where со всякими (+)
51 Джинн
 
23.05.17
18:10
(49) + О курсорах я думаю даже не догадывается 99% одноэсников.
52 Garykom
 
гуру
23.05.17
18:14
(51) Может и не догадываются но постоянно используют и пишут их каждый раз "... = Новый Запрос(..."
53 Heckfy
 
23.05.17
18:15
(37) (39) (41) (44)
Ну, тарифы меняются достаточно часто. Не то что бы каждый месяц. Но, опять, акции всякие достаточно часто. И сидит кучка разработчиков, которые всё это очень медленно реализовывает.
54 Garykom
 
гуру
23.05.17
18:15
(52)+ неявно
55 Волшебник
 
модератор
23.05.17
18:17
(51) Курсор — это такая палочка мигающая. Это все знают.
56 Генератор
 
23.05.17
18:18
а курсор в цикле там обычное дело, сужу по пакетам что довелось увидеть
57 Дарлок
 
23.05.17
18:20
(53) а данные для расчета откуда берутся?
58 Джинн
 
23.05.17
18:21
(55) И ведь не поспоришь :)

(52) Это не совсем то. Или совсем не то - как посмотреть.
59 Господин ПЖ
 
23.05.17
18:21
(53) ну может софтина такая - что вменяемо описать эти скидки и прочее нельзя, подняв все на уровень настроек. вот и перепиливают "ядро" каждый раз

а может разрабы такие... меня как-то пытались заставить заниматься софтом в котором интерфейс был декларативный как УФ, но описывался РУКАМИ в xml. через месяц я уже был на новой работе
60 Джинн
 
23.05.17
18:22
(56) Если процедурная обработка, а не банальная выборка, то без курсоров сложно обойтись.
61 Heckfy
 
23.05.17
18:24
(57) Онлайн ничего не собирается. Есть забитые в базу тарифы, услуги. Ну и соответственно расчет ведется исходя из того, какими услугами абонент пользуется.
62 Джинн
 
23.05.17
18:25
(53) Маркетологи иногда такого наворотят, что задолбаешься писать. Так что не факт, что он в носу ковыряются.
63 Heckfy
 
23.05.17
18:27
(59) (62) Все может быть. Так низко не погружались. Но, вроде все акции от маркетологов вменяемые приходят на реализацию.
64 Garykom
 
гуру
23.05.17
18:30
Может все намного проще через NoSQL (например CouchDB) и принцип map|reduce?

Суть что тут нет фактически кросс-запросов и сводных выборок, простая параллельная-асинхронная обработка кучи клиентов.
65 Garykom
 
гуру
23.05.17
18:31
В смысле начисления одному клиенту никоим образом не зависят от начислений для других.
66 Господин ПЖ
 
23.05.17
18:32
>Маркетологи иногда такого наворотят, что задолбаешься писать

мда... кто знает ценообразование аптечное тот в цирке не смеется...
67 Garykom
 
гуру
23.05.17
18:33
68 Heckfy
 
23.05.17
18:34
(59) Но с софтиной что то не ладное - это точно.
Из последнего:
Не смогли реализовать нумерацию листов счетов фактур при МАССОВОЙ печати в разрезе каждой счет фактуры. Говорят, или вообще без нумерации или нумерация листов при печати каждой сф отдельно. Но, тогда, если запустить массовую печать, нумеруются все листы сквозняком.
Взяли на подумать. Пока вариантов никаких не видят.
69 Garykom
 
гуру
23.05.17
18:34
(66) Как раз аптечное ценообразование очень логичное, это блин все прочие фигней страдают с усреднениями наценки ))
70 Джинн
 
23.05.17
18:43
(68) Посчитать сколько строк влезет на лист (а значит нумеровать их) иногда не так просто. 1С тоже делит их  по сути эмпирическим путем. Посмотрите печать той же ТОРГ-12.
71 Господин ПЖ
 
23.05.17
18:45
(68) а как они их вообще печатают?

может банально надо поискать более продвинутый "report generator"
72 Господин ПЖ
 
23.05.17
18:46
и вообще это имхо задачи бэкофиса...

может там с архитектурой (или архитектором) проблемы - надо разделять уже на фронт и бэк, а они пытаются все вместе держать
73 Garykom
 
гуру
23.05.17
18:47
(71) попробуй в запросе пронумеровать по порядку каждый раз с 1 внутри группировки
74 Heckfy
 
23.05.17
18:49
Ребят, не нужно сейчас в обсуждение того, что есть сейчас уходить.
Сейчас стоит вопрос о смене биллинговой системы, либо кардинальной реорганизации. Интересует компетентное мнение, есть ли смысл смотреть в сторону 1С?
75 Джинн
 
23.05.17
18:51
(74) Нет смысла.
76 Heckfy
 
23.05.17
18:52
Друзья, я поехал в пробке постою. Так что на все возникшие вопросы смогу ответить чуть позже. :)
77 Garykom
 
гуру
23.05.17
18:52
(74) Если найдешь ЗУП на 5 миллионов сотрудников в 1 базе )
78 Дарлок
 
23.05.17
18:52
(61) вполне можно сделать. Но оптимизировать придется
79 piter3
 
23.05.17
18:52
(74) Неа.
80 Господин ПЖ
 
23.05.17
18:53
(73) а зачем нумеровать листы в запросе?
81 Garykom
 
гуру
23.05.17
18:54
(80) Подозреваю у них вся логика абсолютно на сервере, включая формирование счет-фактур.
Для печати выдаются уже готовые данные которые просто в шаблон вставляются.
82 Дарлок
 
23.05.17
18:55
(74) задача нетипичная для 1С и 24часовой доступ к системе будет сложно организовать ))
83 piter3
 
23.05.17
18:58
(82) Ну да за копейки и fultime :)
84 Garykom
 
гуру
23.05.17
19:01
Кста что то я парю, можно же поделить клиентов (раз данные не пересекаются) по "пулам" - небольшим отдельным базам с 1000 клиентов в каждой.

Всего 5 тысяч отдельных баз 1С на хорошем таком кластере из пары сотен серверов.
85 Garykom
 
гуру
23.05.17
19:03
(84) Конфа будет через РИБ обновляться, причем только конфа, данные никуда не ходят.
Кучу правда допом придется для обслуживания понаписать но в результате

1С сможет, потому что:
86 Генератор
 
23.05.17
19:03
(84) они не пересекаются пока отчеты не захотят сформировать общие
87 Маленький Мук
 
23.05.17
19:05
Не взлетит, даже если расчет первых 2-3 месяцев устроит по времени, через полгода год база распухнет и все встанет раком. Личный опыт работы в двух компаниях провайдерах, и проект от франча в страховой компании говорит что 1С с большими объемами не дружит. Не веришь сделай примитивную тестовую базу с документами начисления и оплаты с одним регистром накопления, потом нафигачь туда данных обработкой за год. Даже без расчета на проведение документов может уйти столько времени что вопрос работы биллинга на 1С у тебя сразу будет закрыт

1С не сможет, потому что:
88 Garykom
 
гуру
23.05.17
19:05
(86) Да согласен между ними по РИБ будут ходить общие данные и НСИ к примеру тарифы/акции и т.д.

А обратно уходить сводные отчеты, которые на уровне выше снова объединяются/суммируются примерно как в Консолидации.
89 Дарлок
 
23.05.17
19:05
(84)зачем этот ужас с РИБ? Тупо можно считать пакетами .
90 Garykom
 
гуру
23.05.17
19:08
(89) Для улучшения распараллеливания обработки и ускорения сводов.

Всех клиентов нумеруем по порядку от 1 до 5 лямов, далее делаем 5 баз верхнего уровня которые отвечают за своды по 1 ляму, далее ниже следующий уровень по 100 тысяч к примеру ну и остановимся на нужном уровне где уже каждого клиента по очереди считаем из небольшого числа.
91 Джинн
 
23.05.17
19:10
(90) Проще нанять одного нормального PL/SQL-девелопера, чем городить убогую конструкцию из говна и палок.
92 Генератор
 
23.05.17
19:12
они с этими РИБами еще больше хлопот поимеют, выяснять почему обмен с конкретной 400-й базой не прошел по новой акции, и администрировать список баз у каждого конкретного менеджера
93 Garykom
 
гуру
23.05.17
19:15
(91) (92) Абсолютно согласен, пытаться сделать "это" на 1С не имеет практического смысла ))

Вопрос то был "Сможет ли 1С?"
94 Генератор
 
23.05.17
19:19
Я уже предлагал: морду на 1с а сам биллинг в oracle. Записали например в 1с новую акцию - регл задание в плане обмена увидело и отправило в oracle. Формы меняй в 1с хоть через день.  Отчеты и печатные формы делай в 1с какие хочешь, хоть в скд запросом из внешнего источника данных, лучше всяких reports.
95 Garykom
 
гуру
23.05.17
19:21
(94) И каким образом получится на 1С к примеру за пару дней вывести на печать 5 миллионов пакетов документов (счет-фактур и т.д.)?
96 Garykom
 
гуру
23.05.17
19:22
(95)+ Без РИБ
97 NorthWind
 
23.05.17
19:24
(58) не то. Вот выборка результатов запроса похожа больше.
98 NorthWind
 
23.05.17
19:27
(74) мне кажется, нет. Положите вы лошадку, не вывезет.

1С не сможет, потому что:
99 Джинн
 
23.05.17
19:30
(97) Да, аналог полный. Только она на клиенте (в широком смысле этого слова), а в SQL она на самом сервере.

Придется снизить цифру в 99% - оказывается некоторые знают чуть больше обычного SELECT :)
100 sapphire
 
23.05.17
19:44
(87) Это лишь значит,что вы не умеете их готовить.
101 sapphire
 
23.05.17
19:44
При грамотном ландшафте и коде вполне может.

1С сможет, потому что:
102 NorthWind
 
23.05.17
19:46
(99) В терминах процедурного расширения SQL - верно. Но надо заметить, что некоторые технологии, например ADO, трактуют это понятие немного шире, и там есть клиентские и серверные курсоры.
ЗЫ: я пришел из программирования в Oracle :)
103 NorthWind
 
23.05.17
19:52
(101) может, и можно, но наверняка будет столкновение с трудностями, которых можно было бы избежать, имея прямой доступ до SQL и его процедурного расширения без дополнительных прослоек.
104 ГеннадийУО
 
23.05.17
19:52
(74) 1С потянет конечно, но стоимость разработки чтобы потянуло не будет дешевым однозначно. А так для примера - сейчас у меня крутится база с 58 млн. записей в регистре накопления, не типовая конечно, тормозов особых нет...
105 sapphire
 
23.05.17
20:00
(103) Все зависит от реализации,компетентности специалистов и железа.Oracle database server всего лишь СУБД. Так и с 1с. При грамотном построении решения, грамотном развертывании взлетит вполне.

Думаю,контора совсем не бедная раз только 50 лямов на бумагу тратит ежемесячно
106 Волшебник
 
модератор
23.05.17
20:37
(104) Да, тут особый случай и тут понадобятся мозги, которые не будут дешёвыми.

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

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

Типовая конфигурация точно не подойдёт. Придётся писать свою с нуля.
107 Волшебник
 
модератор
23.05.17
20:38
(105) 5 млн абонентов * 500 руб средняя цена = 2,5 млрд выручки