Добрый день.
Есть задача по приему платежей онлайн.
Пробовали делать один документ и в него дописывать строки по мере поступления платежей. С каждым добавленным платежом документ проводиться всё дольше и дольше, в конце дня вообще 10 минут висит.
Думаю сделать на каждый платеж отдельный документ, отсюда вопрос чем может грозить такое большое количество документов в базе?
Платежей в день 30-50 тыс.

А зачем "по мере поступления"? Проводите один раз в день, ну пусть 10 минут будет проводится, но один раз

(1)Надо чтобы сразу платеж был виден в карточке абонента

Ничем не чревато.
Ограничение ТЧ документа 99 999 строк. Можете, при увеличении клиентов, в это ограничение упереться.

(3) Если делить документы по платежам, тогда в каждом документе будет по 5-6 строк. Но документов таких в день будет 30-50тысяч

Да и пофиг. Хоть по одной строчке в документ пишите. :)

(5) т.е. 18 млн документов в год не повлияют на быстродействие базы?

Делай архивирование как с чеками ккм в ут

(4) у нас за день создаётся 4 млн документов одного вида.
Только к этому документу надо осторожно запрос делать, чтобы базу не уронить.

(6) Не сцы, при учете (8) все нормально будет. :)

Ну, и соответственно, регламенты с БД нормально настроить нужно.

Схлопывайте в конце дня в один док.

(6) Не повлияет.

(12) Если руки не альтернативно расположены.

Можно сделать так: в течении дня доки идут на каждый плдатеж по документу, затем ночью они "скукоживаются" в один документ.

(11) а в конце года - свертку базы, и - по-новой 18млрд доков! :)

еще можно не дописывать строки в документ, а докидывать их в РС и регистрировать сам док в плане обмена. Регламентным заданием раз в минуту проводить этот самый док.

Оппа, конкурс на изобретение велосипеда по ходу открылся. :)

можно дописывать строки в док в режиме "запись" и обновлять движения.

(17)а ты не делал биллинг на 1с ;)

(0) Нормально всё будет.

(14) Ничего, что платежи круглосуточно могут поступать?

(19) :) Тут не та нагрузка. :)

И если отдельными документами делать, то вообще без табличной части - меньше таблиц, хватит шапки.

(23) +1

Бгг, помнится, я похожую ветку уже создавал =)

(16) Не, у меня тоже рег. заданием проводятся определенные доки, наверное буду искать другое решение. На время обработки база "подвисает", юзеры сидят и ждут. Ну или возложить задание только на опр. пользователя м.б.

Возможности платформы: а что, если транзакций/документов ежемесячно - миллионы?

(0) Что значит "прием платежей он-лайн"?

(28) Терминалы по приему платежей видал? Вот что-то вроде :)

(28) Не разумно на 1С строить такие системы..
В 1С только консолидированные данные загонять, итоги и т.д.
Всё же учетная система не для 4 млн/день. Я представляю, какого размера будет RPHOST в ОЗУ и когда система в своп уйдет.
(0) Автор, сколько уже доков в базе? 8.3 сейчас? Какое железо?

(30) Плюсмного. Нужен фронтенд для процессинга, отдельный от 1С.

1 док без табличной части на платеж, по сути будет тоже что и 1 большой док с ТЧ

(30) Зачем рпхосту столько данных? По факту только текущие проводящиеся документы
Вот база, да, может большая быть, но какая разница?

(31) Ага, и написать обмен грамотный с эской.

(31) Нафиг гетерогенность, если 1С эту задачу прохавает на ура.

(35) Не прохавает. Я непосредственно с этим сейчас работаю уже год и вижу, что никак не прохавает.

(33) Он разрастатеся при большом объеме транзакций, видел такое в 1C на LInux + Postgre. Либо железо нужно действительно мощное. Вот я и спрашиваю и автора платформу, БД и железо. Может оно и взлетит

(34) А чего его писать, через внешние источники напрямую к базе фронтенда цепляться и лепить запросы. Ну и если в обратную сторону надо - через XML.

Для чего документ? Не проще все писать в регистр сведений?
1 платеж - одна запись?

(36) Не прохавает задачу ТС?
Не верю (с).

(39) Писать в регистр сведений бизнес-данные не кошерно, т.к. из РС записи могут легким движением руки пользователя как исчезать, так и добавляться

(40) Я пробовал у себя тянуть и обрабатывать (формировать проводки) неагрегированные данные (300к+ записей). Даже при разбивке доков, отключении половины механизмов обработки проведения и подписок - это жуть. Для реального времени такое категорически не годится.

А вот агрегированные 20-25к записей - вполне перемалывает. Минут за 40 (там куча проводок с разбиением по докам).

+(42) Конечно, если задача - тупо складировать записи в плоскую табличку, то вопрос другой, но чот фигня получается, зачем 1С тогда вообще.

(40) "С каждым добавленным платежом документ проводиться всё дольше и дольше, в конце дня вообще 10 минут висит"

Достаточно будет одного сбоя (нехватка памяти) и задача уже не решена. Я уже не говорю, что ТС догадался в арифметической прогрессии добавлять в один док и ещё раз проводить всё заново и старые записи и новые. Маразм..

используйте документ без ТЧ вообще

(41) Ты это издеваешься что ли? Какие права установишь, так и будет. А документ чего нельзя удалить что ли?
У нас по крайней мере так работает.

(45) Нельзя без тч, в одном платеже удет оплата по нескольким услугам одного лицевого счета, поэтому хочу лицевой в шапку, а в тч услуга, поставщик и сумма

(47) Добавь еще ID платежа в шапку и не надо будет ТЧ.

ТС, понятно, что это самописка, понятно, что она с нестандартными подходами и т.д. А зачем вам вообще нужна ТЧ в приеме платежей? Пишите в регистр сведений только поступившую оплату и все. Деньги поступают в кассу? Касса инкассируется/закрывается один раз за смену? Ну тогда при закрытии смены можете собрать и двинуть по регистрам накопления все зарегистрированные платежи.

(47) Все что хотите в ТЧ толкай в поля реквизитов регистра сведений.

(45) Проблема не в ТЧ вообще)
Вообще можно использовать диамическое собержимое ТЧ и очищать его после проведения, ведь главное в регистр занести

(46) Я серьезно. Делюсь опытом из категории "выстрадано и проверено".

Вангую, что через месяц-два-три ТС заипется все это на ручном приводе чинить и начнет лепить фронт-систему промежуточную.

(51) Ну я понял, что у вас "тетя маша" имеет права на регистр. И чего?

(52) Промежуточную сложнее, т.к. в нее нужно сливать еще и данные клиентов оперативно. Это ведь не только платежик записать

(41) (51) так записи в любом регистре с порядком "по регистратору" : будут права на документ - исчезнут; не будут - останутся

(52) Я б решил задачу без доп систем.

(54) Эти данные как раз там и заводятся, а потом уже попадают в 1С.

(55) Я за независимый РС говорю, так же как и arsik

(56) Та ради бога, кивям вон подскажите :)

Делайте один документ на каждый платеж, проблем не будет, проверено...

(49) т.е. ты предлагаешь не задействовать "ресурсы" в регистрах, только измерения?

+(59) Тут только что в соседней ветке про банки и 1С обсуждали, что процессинг - это не для 1С вовсе задача, адинэс - это бэкофис для неспешного перемалывания инфы в нужный вид.

(49) Касса и банк в этой базе не ведутся, они ведутся в БП.
В 00:00 регламентом создается сводный реестр принятых платежей и отправляется в КЦМР(Казахстанский центр межбанковских расчетов), если всё верно то КЦМР переводит деньги поставщикам.
В регистр сведений не пишу т.к необходимо чтобы сразу после оплаты в карточке абонента отразилась эта оплата, а карточка завязана на регистр взаиморасчетов.

(61) Измерением - это может быть УИН, все остальное ресурсы.

(63) Переделай карточку.

документ-регистратор для РС кассир не "закрывает", до конца смены пишет в него. В конце смены на его основании вводить док закрытие смены кассира и все.

(61) можно задействовать - но измерение по виду платежа, скорей всего придется сделать.

(53) Неясно, у кого "у вас". Я тебе уже совокупный опыт нескольких распределенных БД у нескольких разных клиентов передал.
И конечно тот, кто заносит данные, права имеет. Но не на регистр, а на документ. И даже при массовом удалении эти манипуляции останутся в каком-нибудь ЖР пообъектно, в отличие от удаления пары десятка записей из РС (если заранее не приписать еще и альтернативную регистрацию изменений). Но ты, полагаю, исключительно за некие служебные регистры говоришь, куда вручную никто ничего не заносит, верно? И, видимо, пока не сталкивался с манипуляциями с этим регистром теми, у кого на него права есть...

(63) какая разница, как названо - касса или не касса в терминах программы. Это же все-равно кассовая работа. Ну зови это дело "Сводный реестр за смену" - это же сути не изменит

(67)
1) У нас на этот регистр имеют права только система и админ.
2) Все бэкапится.

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