"Увеличение количества записей в табличных частях"
https://wonderland.v8.1c.ru/blog/uvelichenie-kolichestva-zapisey-v-tablichnykh-chastyakh/

Непосредственно в ТЧ не рванет. А вот косвенно - рванет. Огребли вот прямо совсем недавно.

(52) Переходите на 7.7, там в справочниках вообще не было табличных частей. Документами не пользуйтесь. Вот и исполнится Ваше желание.

А длина номер строки у регистров, подчинённых регистраторам? Тоже будет регулироваться?

(56) там уже предельно 9 знаков

(57) мало...

Это что ж, мне операцию переноса остатков при свёртке базы дробить на 10 документов? А может у меня там остатки по всем субконтам? А может у меня там 8 млрд людей, на считая домашних животных... Срочно расширить до триллиона хотя бы!

(13) Проблема не в длине нумиратора, а в том, что ПолучитьОбъект() грузит всё. Табличная часть это отдельная таблица, просто объект объединяет как правило несколько реляционных таблиц.

(47) Есть документы в БГУ 2.0 распределение затрат, в одном из Центральных аппаратов так намудрили с аналитикой, что предел 100к пройден был в 2018 году (заказчик барин).
Переписать запросы распределения по филиалам в субконто - это на недели 2-3 работы вышло (они эти часы закрыли), там очень много запросов в типовых модулях, распределений и тп. Я честно пытался обойтись малой кровью.
После заполнения документа данные корректируются, НО записи в регистр сведений не позволяют интерактивно вносить изменения, только через открытия доп. упрощенной формы.
Платформа 8.3.27 сохранило бы их бюджет работы прогера на 3 недели.

Не понимаю почему вы так против данного нововведения? Это экономия бюджета заказчиков и ресурсов прогеров с малой кровью.
Ну да, если стажеров к этому нововедению подпустить, то беды будут большие. И в части блокировок при записи, и в части понимая кода клиент-сервер в форме документа/справочника.

(60) Где ПолучитьОбъект() с >100тыс строк там обычно не стажеры работают.
Для УФ клиенту без разницы сколько строк в документе, если только не дай бог оно не выведено в виде дерева.
Чтение по ссылке - там да, могут у людей вызвать проблемы, но EDT уже давно ругается на чтение по ссылке. Да и сам я уже почти никогда этим не пользуюсь в последние 5 лет.

(54) Что именно у вас случилось?

(63) Перестаньте врать

Есть типовая бесшовная интеграция с ДО
Библиотека Интеграции с 1С:Документооборот (БИД) иначе

Там через веб-сервис DMService через xml передаются объекты (справочники и документы) между например ERP и ДО

И да там таймаут веб-сервиса по умолчанию 20 секунд...

Даже сотни или тысячи строк в ТЧ не всегда успевают уложиться, не говоря уже о миллиарде

(65) У кого есть?

(65) Я как нормальный пацан все входящие пакеты складываю в регистр сведений и хранилище. А потом рег.заданием это все обрабатываю. Так можно избежать задвоения создания справочников (если не очень хочется накладывать блокировки по реквизитам), можно все ошибки записывать в этот же РС в другой реквизит, в измерении только GUID, который присваивается в момент записи.
А так, один поток, меньше блокировок по таблицам.
Это все оберегает от постоянных терок в интеграции с разными системами из разряда: мы вам все отправили, почему у вас не создалось. В начале каждый день по 2-3 письма приходило с разбором полетов, как ввел эту систему (с очисткой через 2 дня успешных пакетов и 14 дней с ошибками, это все настраивается в пользовательском режиме), больше за 2 года вообще не обращаются почему так.

(67) Ну норм

(67) Изобрел брокер сообщений?

Проблему в (59) надо как-то решать... Мало цифр

Лично мне нужно очень много цифр. Меня даже ТРИЛЛИОН не устроит, если в десятичной системе.

Хотя с другой стороны мне достаточно одного бита или даже кубита. Это что-то мелкое, но вполне достаточное.

Песня "Блокчейн"
https://suno.com/song/c7f07cad-ba8d-4e1b-8b23-b24c7100705e
MP3 https://disk.yandex.ru/d/wa63_LpoyR38ig

Полный текст песни

[Intro]
А что если...
Просто подумай, прикинь...

[Solo]

Это не кринж, реальная тема,
Просто мысль пришла внезапно,
Мысль глобальная, интегральная...

[Solo]    

А что если...
Весь мир представлен в одной строке?
И все наши жизни и мечты по сути число?

[Verse 1]
Прикинь, если всё живое и каждый след на земле
Будет засекречен в цифровой глубине?
И в этой бездне, в этой длинной строке
найдутся все люди:
живые и мёртвые,
все чёткие и стрёмные,
сущие и будущие...

    [Chorus]
    Просто тыкни в число и вот они...
    Ты понял о чём я, бро?
    И я, и он, и мы, и ты...
    Вместе мы
    свёрнутЫ!

[Solo]

[Verse 2]
По сути все наши мечты, и все тупняки,
Все блатняки и все чуваки,
Войдут в это число, в один бит.
Или кубит.

[Solo]

    [Chorus]
    Просто тыкни в число и вот они все...
    Ты понял о чём я, бро?
    И я, и он, и мы, и ты...
    Вместе мы
    свёрнутЫ!

[Solo]
    
[End]

(65) А чего не через JSON?
Сам текст JSON  раза в 3 меньше по объему аналогичных данных XML, плюс XML тяжелее обрабатывается и парсится.

(39) кому-то и миллиарда не хватит, придумает какую-то ситуацию. Согласен с Волшебником, считаю проблему надуманной.

(74) лайк, чо 👍

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

(76) Ну и чо? Пишите данные в регистр

В регистре уже давно МИЛЛИАРД дан, но мне мало. См (71)

(76) И что? хотите сказать что прям одним документом на все предприятие начисляют? Вообще-то предприятие делится на подразделения, и никто и никогда не начисляет по всему предприятию сразу. Это просто организационно нереально. Я работал на ОЧЕНЬ крупном предприятии, как раз таки с ЗУП КОРП, везде начисления идут исключительно по подразделениям, максимальная ТЧ документа начисления была около 5000 строк.

(76) И как расчетчик это сморит? Или он тупо верит программе?

Будем смотреть, как все будет виснуть и кряхтеть... Или свистеть и летать :)

(81) ПолучитьОбъект() надо будет теперь использовать с большой опаской.

(80) зачем смотреть на строки документа, заполненного автоматически, даже если их всего 1000, то что в них увидишь полезного?

(83) Тю, 1000 строк начисление-сотрудник - это столько в довольно среднем предприятии. Там все полезное, иначе расчетчик профнепригоден. Например, там есть детальный расчет со всеми показателями. Кстати, ТЧ с показателями - это примерно x3 к ТЧ с начислениями, а то и больше.

Вопрос другой. Какой умник придумал ограничение на 100 тыс строк для табличной части. Вот ему бы руки оторвать.

(86) Работал с документами по 10000 строк еще в 8.0. Другой вопрос. Какой умник такие документы открывает на редактирование? Висит все жутко.
Руки бы ему оторвать...

(82)

Думаешь 1С доработает функцию ?

ПолучитьОбъект(СОпаской = Истина)

(88) Скорее воткнут коллекцию реквизитов и/или ТЧ.

"Какой умник придумал ограничение на 100 тыс строк для табличной части. Вот ему бы руки оторвать." Лимит ввели во времена, когда excel не более 32 000 строк на листе поддерживал. И не жаловались.

(82) "ПолучитьОбъект() "
  Это для Управляемых форм и Тонкого клиента. Так известно, что Тонкий клиент это больше для ларьков, а для больших документов не подходит.

(91) Так других форм и клиентов уже  нету.

Есть примеры, когда пользователи пользуются документами 100к строк как документами: т.е. глазками по ТЧ ходят и редактируют что-то ручками, проводят/распроводят, восстанавливают последовательности? А если это просто для того чтоб загрузить, рассчитать и записать в регистр так это уже и не документ получается, а просто форма + запись в регистр.
Вообще не понимаю этой гонки снятия ограничений. Ну снимут ограничение в ТЧ - в других местах все рухнет.

1с приводит пример для расчета ЗП. Такое вообще бывает 20к сотрудников в одном подразделении у одного юр. лица? (я конечно наверное тот еще ларечник, но интересно)

(93) > Ну снимут ограничение в ТЧ - в других местах все рухнет.
Ты думаешь, что разработчики платформы не подумали об этом?

(93)

Не бывает, такое чисто организационно невозможно.
Я видел что-то около 1000 в одном цехе. И то старались разделить, потому что сам процесс начисления это не просто заполнил и провел. Это всевозможные корректировки, и проводит их не один человек, расчетчиков у нас было человек 8, насколько я помню.

1млн на ближайшие 10 лет большинству бы хватило и не сильно напрягло бы платформу. А >1млн ТЧ без переработки других механизмов платформы будет вызывать только лишние подвисания, вымывания кэшей и переполнения памяти.

(96) Так было же максимум 100 тыс.

(96) Я думаю кто хотел миллиард, тот готов. Очевидно что работа с такими доками будет непростая.

(97) 65535 строк

(79) Хочешь сказать в 1С тупые внедренцы которые не догадались что можно делить документ на несколько и такие же тупые разработчики которые повелись на поводу внедренцев?

(80) За что купил, за то и продал

Из сабжа
"В качестве примера можно привести табличную часть Показатели документа НачислениеЗарплаты. В крупных организациях в одном подразделении может быть большое количество сотрудников, и число строк указанной табличной части может превысить текущее ограничение."

Ну и по факту, никто не заставляет во всех документах увеличивать дефолтное значение количество строк

(97) (99) Один про Фому, другой про Ерёму

(100) Я хочу сказать что пример с расчетом зарплаты притянут за уши.

По нетрезвому разумению даже при эксплуатации бесправного цифрораба количество строк в документе примерно 16 часов * 3600 секунд/5 секунд проверки и чтения строки = 11520. Если работу разделить на несколько дней, то к началу следующей смены раб успешно забудет что он вчера напроверял.

(105) Свёртка остатков базы - не притянут за уши.
Нужен миллион строк.

(107) Именно что притянут, из-за желание сделать всё в одном докумкенте, хотя ничего особо не мешает сделать десятком или сотней

(107) Так это в регистре. В документе не нужен

(107) Вы там что по молекулам остатки на складе считаете?

Как я вижу ситуацию: некий заказчик (очевидно крупный) продавил решение. Ну вот нужно ему это и всё. Как говорится: вынь да положь!

1С эти требования выполнила. Это говорит о том, что заказчик не просто крупный, а Ооооочень крупный.

Мы можем долго гадать, что там за задачи у этого крупного заказчика. Может угадаем, а может и нет....

В общем, факт свершился. Есть плюсы, есть минусы.

Со своей стороны скажу так: нам для некоторых задач ограничение в 99 999 мешало, но и миллиарда нам не нужно.

Зачем табличная часть на 1 млрд записей. Регистр сведений на 1 млрд записей в 1С работает с очень большим скрипом. Зачем ларькам 1 млрд записей?

(110) например фиксация цен с кучей видов цен. Вполне легко перевалить за лимит.
А так партии. Некоторые фиксирует оборотным регистром типа продажи, чтобы в старую базу не лазить.

(0) Всё относительно. Для РЖД может быть и хватит, а для Роскосмоса нет. Нельзя сделать инвентаризацию всех известных  звёзд.

(0) Полезная штука. Ранее приходилось работать через регистр сведений, но не сразу дошел до указанного подхода.
Решение востребованное в первую очередь для биллинга и, считаю, что это шаг в сторону крупных клиентов. Круто!

(116) Роскосмос не занимается звёздами.

(117) Врун

(119) дятел

(120) докажешь?

(121) сначала докажи свои предьявы

(122) Давай в личку tg@staswiz

(115) А пробовали открыть Установку цен номенклатуры, например в УТ11, где  хотя бы 50 000 строк? Попробуйте, уверен, что повторять не захотите.

(124) там тз, а не табличная часть.

(124) А зачем тебе документ "Установка цен номенклатуры" на 50 000 строк. Создай 1000 документов по 50 строк и все будет летать. Так мне ответили местные "гуру" лет десять назад.

(112)

+1

(126) Да согласен. Речь скорее всего не про открытие таких табличных частей на просмотр и редактирование, а на хранение в них данных.
Да раньше приходилось делать через отдельный регистр Сведений (просто больше кода)
Сейчас тенденция хранить вместе с объектом(например дополнительные реквизиты) и табличные части для этого идеально подходят.

(125) там даже не ТЗ, там дерево строится.
И строится оно крайне неоптимально

(0) Просто прогнулись под очень крупного заказчика. А если бы смысл был, то и раньше сделали, т.к. в ЗУПе уперлись в ограничение, которое решили логичным переходом на регистры. И вопрос, сколько этот чудо документ в ярд записей будет открываться\проводиться? А можно же еще несколько таких табчастей в документе..

(130) Проверим когда выйдет 8.3.27

(130) Сделают динамическое чтение с сервера СУБД по аналогии с динсписком и будет открываться мгновенно.

(132) Согласен, а иначе и не взлетит 146%

(132) Открываются то они мгновенно, но фильтрации и поиск там еще тот тормоз.

(134) Это печально

(129) Разбирались, в чём именно неоптимальность?

(131) Вышла
https://v8.1c.ru/platforma/news/novoe-v-platforme-8-3-27/
https://infostart.ru/journal/news/mir-1s/vyshla-novaya-versiya-tekhnologicheskoy-platformy-1s-predpriyatie-8-3-27_2363428/

(137) Добавили возможность совершать видеозвонки в тонком клиенте в операционных системах Linux и macOS. Раньше в этих операционных системах видеозвонки можно было совершать только в веб-клиенте;

Это какой то треш. Очень нужна функция в 1С, ага.

(138) Вообще-то нужна, чтобы не пользоваться скайпом/Тимсом и прочей хней

(139) Чтобы созваниваться внутри офиса?

Почитал. Интересно.

(140)А как ты по телефону продемонстрируешь что у тебя на экране?

(142) камерой телефона и видеозвонком?

(137) Полезная вещь:
"Полный поисковый индекс, используемый при рефакторинге, строится теперь заранее, в отдельном фоновом потоке при запуске конфигуратора, благодаря чему ускоряются операции поиска ссылок, переименования и удаления объектов конфигурации; ранее поисковый индекс начинал строиться непосредственно при начале этих операций"

(143) Камера и видеозвонок идет по мессенджеру компании или доступным для просмотра мессенджерам?

(0) для авиапрома годится

Круто

Вообще, миллиард байт – это гигабайт (и именно он).
Строка ТЧ по любому больше одного байта.
Получается, один документ может весить несколько десятков гигабайт.
Ну да, ну да...

(1) да хрен с ним, рванет или нет.
пни меня, если пропущу ветку вроде "виснет при открытии документа с 837042123 строками". тупо поржать и увидеть того, кому эта "революционная фича" пригодилась

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

(0) след. шаг сделать ссылочными сами строки  табличной части ? Чтобы в типовыхконфигурациях не изобретать на прикладном  уровне.

(150) ТЧ при закрытии производственных счетов с кучей аналитики на субконто.
Начисление з\п с кучей видов начисление. Условно их 50 штук, 2тыс сотрудников только заполнит.

(152) "2тыс сотрудников только заполнит." - все сотрудники числятся в одном подразделении? Зачем столько в один документ запихивать? Потом в случае правок гемора много.