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

Документ открывать и вручную не будут. Просто хранилище.

9999 вроде

(2) После 9999 нумерация не работает, а записать можно строк и больше

Для 1С 7.7 существует ограничение на количество строк в табличной части документа равное 9999. Максимальное количество строк (проводок) в операции равно 99999.

Важно заметить что для DBF версии 1С 7.7 превышение количества некритично. Строки будут хранится и обрабатываться платформой нормально, но все строки выше заданного ограничение получат номер 0. Для SQL версии это ограничение уже критично, в связи с более жестким контролем за структурой хранимых данных со стороны SQL-сервера.

Кстати, вы спокойно сможете работать с базой 1С DBF формата в которой есть документы с количеством строк в табличной части более 9999, но вот при попытке загрузить базу в SQL вы получите сообщение об ошибке, и не сможете выполнить загрузку пока не приведете количество строк в документах базы DBF к количеству менее 9999.

даже если хранилище - дели на части обозримые, 100-200 строк.

Хранилище которое делает движение?

(6) это, елы-палы, закорма родины!! там всегда движуха!! мы туда сыпем, а оттуда олигархи нашу прибаочную стоимость изымают

(0) Сколько угодно.
Но помню, что проведение больших документов тормозило тем больше, чем больше в них было строк. Экспериментальным путём было установлено, что критической точкой является примерно 3000 строк - сверх этого проведение тормозило настолько, что становилось нецелесообразным делать такие документы и проводить их, если их можно разделить на более мелкие. Поэтому я разбивала такие хранилища на части, по три тысячи строчек.

Ладно, упростим задачу: документ при проведении не будет двигать регистры и проводки. Ничего не будет делать.

(9) А зачем он тогда нужен?

(10)+1

(10) Для хранения.
В последующем документы такого вида будут проводится. И я их буду разбивать.
Этот документ надо сделать большим и не проводить. Логику разбиения документов мне сейчас прописывать некогда. Сроки горят.

(10,11) а он будет РЕГИСТРАТОРОМ чего-то. он просто будет ХРАНИТЬ то что требуется. Независимо от того, проведен он или нет. вполне нормальное решение. А то задрал этот 1Совский подход, когда в результате распроведения дока и повторного проведения могут быть утеряны существенные данные.
.
самый простой пример: существенные данные - ГТД в счф. В ТиСе при перепроведении дока - это может запросто поменяться (когда народ задним числом вовсю работает). Скольо раз было - исправляешь сетке документ - отсылаешь - опана - не устраивает! дайте счф с теми же ГТД, которые были в первоначальном доке!

Может быть и в будущем проводиться эти доки не будут, на их основании будут делать документы с маленькой ТЧ (и немного для других целей) и они будут проводиться

...поэтому делаем просто - при пчеати СЧФ формируется док-регистратор, который хранит ГТД, которые пошли в СЧФ (откуда он их берет - из регистра партий, ЕСЛИ НЕТ ДОКА-РЕГИСТРАТОРА). Если ВДРУГ повторное проведение - для списания ГТД берутся именно те ГТД, которые зафиксированы в доке-регистраторе. Если нет возможности списать те ГТД, которые в доке-регистрторе - тогда выдаемАЛЯРМ и списываем другие доступные.

(9) Справочник?

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

в скл варианте - 65536

(4) SQL пофиг на Ваши номера.

Все-таки, я извратился и запихал в документ больше 180 000 строк.
Пока полёт нормальный))

99999 ровно

(20)  ???

(20) добром это не кончится)

(23) Я больше так не буду, в следующем квартале буду разбивать на несколько документов, тем более со следующего квартала они начнут проводиться по регистрам.

(0) параметры базы озвучьте.
(9) ДБФ база. До 100к входит, но вот при таком количестве строк тормозить начинает нереально и к тому же глючит. Дробили по 20-30к - и проводятся адекватно и практически не тормозит.
Есть побочный негативный эффект: при ТИИ можно не дождаться результата из-за постоянной записи в журнал регистрации об ошибках нумерации строк после 9999. На SSD процесс тестирования менее болезненный, но всё равно мучительно долгий - несколько часов при количечтве строк с номером сверх 9999 порядка 1 000 000

(0) При больших объемах нужно помнить важное правило:
"Безграничен только космос!"

(0) мнится мне, что ты туда алк.декларацию пихаешь? :-)))

(0) если док будет проводиться (без привязки номера строки) - то у меня на дбф те же результаты были, что и в (25), в итоге - отказался от >9999, и при заполнении документов прописал алгоритм дробления на доки по 9999 строк. Правда это было не про алкогольную деклу..

В 2000 скуле до 32 767 строк, дальше на ТиИ будут ошибки валиться и номер строки в документах не будет показывать

(27) Только корректировку по ней )))

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

(31) То была разовая задача.

(32)Разовую задачу решают разовыми методами. Например разбитием на несколько документов и связки с общим, если уж сильно хочется

Не замерял максимум, но 99999 нх не предел, пока максимума не достигал, хотя иногда двигал к закрытию незакрытые регистры, а там цифири не хилые проскакивают.

Народ!
Не поверите.
У меня была база посетителей.
Там регистрировались входы и выходы из магазина.
Так вот когда счетчик посетителей глючил в документ сыпалось че попало.
Причем строк в нем собиралось немеренно.
Органичений я незаметил вот только там були строки и с отрицательными номерами!

(35) :) это видимо те кто вышел но не входил...ищите портал