Вход | Регистрация
    1  2  3   
1С:Предприятие :: 1С:Предприятие 8 общая

Ограничение в табличной части документа 99 999 строк

[catena, 25.10.19 - 11:00]
Ограничение в табличной части документа 99 999 строк
Я
   ProxyInspector
 
24.10.19 - 17:20
1с8.3.9
Надо заполнить оборотный регистр данными.
Неожиданно столкнулся с ограничением на размер табличной части документа в 99 999 строк.
Можно ли это обойти.
И как заполнить регистр большим объемом данных, используя 1с Предприятие 8?
 
 
   Злопчинский
 
101 - 25.10.19 - 02:07
(97) вот тебе тупо конечная задач.
массив данных как у (0).
определить, что является явным признаком (или совокупность признаков) товара(ов), влияющим на объем продаж.
   Bigbro
 
102 - 25.10.19 - 04:34
мне нравится вариант (42)
   НиколаевГ
 
103 - 25.10.19 - 08:01
(97) Маня не умеет в BI :))
   ProxyInspector
 
104 - 25.10.19 - 08:05
15 млн строк это это оборотный регистр Продажи за 1 год. За несколько лет будет 50 млн. И что то меня мучают сомнения, не будет ли тормозить СКД на таких объемах.
   ProxyInspector
 
105 - 25.10.19 - 08:08
Задачка, загрузить данные по продажам крупнейших Федеральных сетей. И сделать аналитический отчет по этим продажам. Интересно справится ли 1С с этой задачей
   НиколаевГ
 
106 - 25.10.19 - 08:08
(104) Будет, инфа 100%.
   НиколаевГ
 
107 - 25.10.19 - 08:09
(105) Не правильный инструмент использовать хочешь ты :))
   ProxyInspector
 
108 - 25.10.19 - 08:11
(107) Чем богаты. 1с наше все. Или все таки надо переходить на Фузину для таких задач :)
   НиколаевГ
 
109 - 25.10.19 - 08:12
(108) Начни с Кликвью :))
   piter3
 
110 - 25.10.19 - 08:44
(105) 1С справиться-то
   Borteg
 
111 - 25.10.19 - 09:42
(88) (85) от чего юзвери мучаться то будут? от отключения итогов на пару минут в самописном регистре, пользоваться которым возможно только после загрузки данных?
   Borteg
 
112 - 25.10.19 - 09:43
(104) не будет, у меня в регистр каждый месяц грузится по 15-20 млн записей. Работает все отлично.
   unenu
 
113 - 25.10.19 - 09:48
(105) такие вещи с полпинка делают в оракле пока пьют коффе,
но так как он в опале то барахтайтесь в 1С денно и ношщьно.
   ДенисЧ
 
114 - 25.10.19 - 09:50
(113) В голом оракле? Или таки с олапом?
   ProxyInspector
 
115 - 25.10.19 - 09:55
(113) Осталось дело за малым. Купить Оракл и Олап
   VladZ
 
116 - 25.10.19 - 10:17
(105) 1с не рассчитана на большие объемы данных. 1С была, есть и будет платформой для автоматизации учета.
   ProxyInspector
 
117 - 25.10.19 - 10:37
(116) Печально. Но учет учету рознь. У нас в управленческой базе несколько млн. документов. И тоже там учет.
Тогда надо писать "1с не рассчитана на большие объемы данных. 1С была, есть и будет платформой для автоматизации учета ЛАРЬКОВ"
   НиколаевГ
 
118 - 25.10.19 - 10:38
(117) При таких объемах учёт и отчеты лучше делать в разных базах :))
   ProxyInspector
 
119 - 25.10.19 - 10:43
(118) А смысл какой?  Оборотный регистр на 50 млн записей занимает пару гигов памяти. Это совсем мало. Из за этого городить новую базу? Или ставить Оракл и Олап. Как то это не солидно. И все это из-за того, что 1С посчитало, что для ларьков нет необходимости иметь табличные части больше 100 тыс строк.
   H A D G E H O G s
 
120 - 25.10.19 - 10:43
(116) Расчитана
   ДенисЧ
 
121 - 25.10.19 - 10:43
А большие объёмы у вас это сколько? А то видел базку в 1.5 ТБ. И ничего, крутилась.
   Maniac
 
122 - 25.10.19 - 10:54
(105) а теперь ответь на главный вопрос - какой дибил будет листать этот отчет?

Я уже написал что такую информацию визуально не состоянии переварить человек. Поэтому ты не договариваешь задачу.
Нужно конкретно знать условия фильров продаж. И ихз применить на этапе загрузки.

Иными словами я бы сразу импортировал и обрабатывал ТОЛЬКО то что нужно
   НиколаевГ
 
123 - 25.10.19 - 10:55
(119) А смысл такой, что в типовых тормозить будет одновременная работа учёта и отчетности. В самописке, конечно, можно сделать нормальную архитектуру, но не все на это способны.
   Maniac
 
124 - 25.10.19 - 10:57
(119) ограничение в 100 000 строк есть, но тут уже 20 раз повторяли что ты можешь делать не 1 а много документов.
   НиколаевГ
 
125 - 25.10.19 - 10:57
(120) Платформа или типовые :))?
   Maniac
 
126 - 25.10.19 - 10:58
Как то раз делал на восьмерке базу для анализа - в которую выгружал обороты продаж и срезы остатков. Конфигурация исключительно была заточена для получения определенных аналитических данных и создавала планы продаж и закупок.
Основная база была вообще на семерке.
   НиколаевГ
 
127 - 25.10.19 - 10:58
(122) Почитай хоть про BI системы, не позорься.
   Maniac
 
128 - 25.10.19 - 11:00
(127) сьешь конфетку
   НиколаевГ
 
129 - 25.10.19 - 11:04
(128) Не хочешь? Ну продолжай писать наивную чепуху, тогда.
   Maniac
 
130 - 25.10.19 - 11:05
(129) чепуху тут пишешь пока ты. с нулем полезной информации. ровно НОЛЬ
 
 Рекламное место пустует
   НиколаевГ
 
131 - 25.10.19 - 11:07
(130) Ну, сочувствую тебе, что сказать ещё.
   Maniac
 
132 - 25.10.19 - 11:10
Чтобы мы имеем

Большое количество файлов по 500 000. В них обороты продаж.

Какие проблемы будут при импорте в 1С

1) Раз это продажи, то наверняка там есть как МИНИМУМ - номенклатура, партнер, склад. А это справочники в 1С.
Поэтому первостепенно появится неизбежно первая составляющая - синхронизация.
Сопоставление текстовых данных файла с ссылками справочника.

Если он начнет искать все построчно - то будет тормозить.
Если будет обрабатывать 500 000 в запросах - тоже будет тормозить.

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

2) Запись в 1С в оборотный регистр продаж - по сравнению с пунктом 1) менее тормозная вещь. Никаких проблем - загружает и записывает данные по 99 999 строк в оболротный регистр.

3) Получение ответов из 1С - будет сильно тормозить, так как планируется от 15 и далее по нарастащей миллионов записей.
Хорошие серваки от полумиллиона рублей.

4) Предположим менеджер выкатил отчет из 1С в который попало 200 000 строк из 15 000 000. Что он собирается с этим делать? Листать? да ну нафиг.
   Maniac
 
133 - 25.10.19 - 11:11
(131) себе сочувстсвуй недалекий.
   Мэс33
 
134 - 25.10.19 - 11:13
(48) реально ржу о таких комментов )))
Вот "упорные" ребята
   ДенисЧ
 
135 - 25.10.19 - 11:14
   Maniac
 
136 - 25.10.19 - 11:14
Я ьы выделил из перечисленного 1) и 4).
Так как то что в (0) это детский лепет по сравнению с тем что имопртируемые данные для 1С нужно синхронизировать для начала, прежде чем даже в документы запихивать. и ограничение в 99 999 строк это вообще тут никакой роли не играет.
   НиколаевГ
 
137 - 25.10.19 - 11:17
А Маня такой-же упёртый, как фузиновцы. Они бы сработались, однозначно :))
   K1RSAN
 
138 - 25.10.19 - 11:18
(137) У фузины одна беда - там только склад есть, и тот кривой. А так - хоть 100тыщминьенок загружай.
   НиколаевГ
 
139 - 25.10.19 - 11:22
(138) У фузины интеграция с каким-то бесплатным БиАем, фузину выкидываем, БиАй оставляем - профит :))
   Maniac
 
140 - 25.10.19 - 11:26
чтобы сделал я

1) потоковое чтение и деление файлов на более мелкие файлы по 99 999 строк (резка файлов)
2) подгрузка файла в ТЗ 1С, с единым запросом который синхронизирует записи и выдает результат в ТЗ
3) создание доп документа (своего, а не типового) для проведения по регистру продаж 1С. Загрузка в него ТЗ и проведение.

Также немалую роль играет какая конфигурация 1С. так как в УТ11 регистра продаж нет, там есть выручка и себестоимость. И это ужасный регистр, потому что там пара десятков измерений. И может оказаться что в импортируемых данных просто даже дофига чего нет из того что там нужно.
А также то что номенклатура и партнеры - в этом регистре это еще справочники но не номенклатура и партнера, и ключи аналитик....
А это значит что база еще больше засрется.
   ProxyInspector
 
141 - 25.10.19 - 11:27
(132) Ясно, что отчеты НЕ будут содержать много строк. там будут соответствующие отборы и группировки.
   Maniac
 
142 - 25.10.19 - 11:28
Хотя вот в УТ11 есть типовой Ввод остатков и там есть загрузка продаж - табличные части Оптовые продажи и Розничные продажи.
   Maniac
 
143 - 25.10.19 - 11:31
Все эти данные грузятся в какую то типовую? Просто любая типовая даст тормоза. они все в том или ином виде содержат грабли которые придется дополнять, заполнять, создавать.
   ProxyInspector
 
144 - 25.10.19 - 11:32
По факту для Exell 500 тыс.строк имеем 
1. Чтение файла 40 сек
2. Сопоставление/Создание справочников 5 мин
3. Проведение 2 мин.
  Это без оптимизации по скорости. С учетом того, что это делается 1 раз в месяц, то можно и не оптимизировать. Оптимизация скорости даст ускорение 3-4 раза.
   ProxyInspector
 
145 - 25.10.19 - 11:33
(143) Конечно это не типовая конфигурация. И тормозов там нет на уровне 20-50 тысяч документов в день
   Maniac
 
146 - 25.10.19 - 11:34
Ну если так) то Успехов) Смысла чего то тут дальше обсуждать нет
   ProxyInspector
 
147 - 25.10.19 - 11:37
Интересные идеи были высказаны. Осталось только реализовать и посмотреть быстродействие отчетов на СКД для большого объема данных
   Злопчинский
 
148 - 25.10.19 - 13:57
(147) то есть разрезу в которых крутить данные будут - уже известны?
   ProxyInspector
 
149 - 25.10.19 - 17:42
Разрезы известны.
    ТорговаяСеть, ФрматТорговойСети, Поставщик, ГруппаТоваров, ПодгруппаТоваров, Товар
    Себестоимость, Количество, Стоимость
    Периодичность
   НиколаевГ
 
150 - 25.10.19 - 19:14
(149) Вот просится тут BI, просится :))
   Злопчинский
 
151 - 25.10.19 - 20:54
(150) ну так я два раза товарищу сказал. он видимо непривычные слова услышал и пропустил мимо ушей.
   ProxyInspector
 
152 - 15.11.19 - 13:31
Короче медленно но верно работа идет.
Реализовал табличную часть через регистр Сведений.
Документ с количеством строк в табличной части = 700 тыс. строк  работает довольно шустро.
       Для 700 тыс строк. Размер Exell файла 20 Мб, Количество ячеек порядка 10 млн.
1. Импорт данных с предварительной обработкой - несколько минут
2. Сохранение документа 10 сек
3. Проведение документа по оборотному регистру 10 сек

   1С жива на данных объемах, а вот Exell при импорте умирает на уровне 500 тыс строк. Приходится читать частями
   ProxyInspector
 
153 - 15.11.19 - 13:33
Ожидаемое количество строк оборотного регистра за три года работы федеральных сетей - 300 млн. записей
Здесь и встает вопрос чем этот регистр Анализировать.
Что-то внутреннее чувство мне говорит, что СКД здесь не справится
   RomanYS
 
154 - 15.11.19 - 13:34
(152) кстати, а как быстро 1С читает эксель через табличный документ не проверял на таких объемах?
   ProxyInspector
 
155 - 15.11.19 - 13:39
Для 700 тыс строк. 
  Если читать через 
        // Массив типа COMSafeArray

        Массив = Лист.Range( Лист.Cells(НачСтрока, 1), Лист.Cells(КонСтрока, КолвоКолонок) ).Value;
  тогда несколько минут
  если построчно, то раз в 10 медленнее
  если через АДО, то раза в два быстрее
   RomanYS
 
156 - 15.11.19 - 13:41
(155) а средствами 1С через 
ТабДок.Прочитать(имяФайлаЭксель);
?
   ProxyInspector
 
157 - 15.11.19 - 13:42
COMSafeArray умирает при количестве 500 тыс. строк и количестве колонок 25
Приходится читать частями
   ProxyInspector
 
158 - 15.11.19 - 13:44
(156) А так я даже на пробовал. А так можно для .xlxs  ?
   unregistered
 
159 - 15.11.19 - 13:44
(153) Как раз для оборотных регистров в 1С были придуманы агрегаты.
Насколько вам подойдёт этот механизм - зависит от того что конкретно вы там собралисб анализировать.
   ProxyInspector
 
160 - 15.11.19 - 13:54
Простейший оборотный регистр.
  Измерения:
     ТорговаяСеть, Клиент, МагазинТорговойСети, Производитель, ВидПродукции ТипПродукции, НаименованиеТовара
  Ресурсы
     Себестоимость, Количество, Сумма
   RomanYS
 
161 - 15.11.19 - 13:57
(158) давно уже. Интересно насколько это быстро работает на больших объемах
   H A D G E H O G s
 
162 - 15.11.19 - 14:11
Ограничение на 99k строк то не случайны.
При открытии документа они все читаются в память сервера 1С.
   H A D G E H O G s
 
163 - 15.11.19 - 14:12
(152) динамический список с отбором?
   ProxyInspector
 
164 - 15.11.19 - 14:13
(161) Посмотрел я ТабДок.Прочитать(имяФайлаЭксель)
 Все не так просто. Там оказалось, что файла формата *.xlxb
 Такой формат 1с еще читать не научилось
   ProxyInspector
 
165 - 15.11.19 - 14:16
(163) Все не так просто. УФ на подобных документах умирает. У меня была попытка на УФ создать документ 30 тыс. строк. Там было очень печально.
  Здесь толстый клиент. Вопросов по созданию и работы с документом на 700 тыс. строк нет. Вполне комфортно
   H A D G E H O G s
 
166 - 15.11.19 - 14:17
(165) "УФ на подобных документах умирает."

Вы просто не умеете их готовить.
 
 Рекламное место пустует
   ProxyInspector
 
167 - 15.11.19 - 14:18
(163) Отборы в табличной части документа на 700 тыс. строк работают великолепно. Никаких задержек. Для толстого клиента разницы между 700 строк и 700 тыс строк не замечено
   ProxyInspector
 
168 - 15.11.19 - 14:20
(166) Не надо.
   Ваш рецепт работы с большими документами на УФ мне известен: "Разделите документ в 40 тыс строк на тысячу документов в 40 строк"
   H A D G E H O G s
 
169 - 15.11.19 - 14:24
(168) Это не мой рецепт.
   ProxyInspector
 
170 - 15.11.19 - 14:25
Когда я на УФ делал документ в 40 тыс строк. Это был чистый документ без всяких обработок. Открывался с трудом. А при попытке начать редактировать любую строку табличной части задумывался на несколько секунд. После этого опыта мы отказались от использования УФ в своей учетной системе, так как не было видно ни единой возможности победить большие документы.
   H A D G E H O G s
 
171 - 15.11.19 - 14:27
(170) Вы просто охерительные ребята.
   H A D G E H O G s
 
172 - 15.11.19 - 14:27
(170) Это эпик
   H A D G E H O G s
 
173 - 15.11.19 - 14:30
Вот такие "спецы" уводят ИС организации, которая им ничего плохого не сделала в трэшанину вольных вызовов сервера с Толстого клиента и обычных форм.
Конфа хоть самописка?
   ProxyInspector
 
174 - 15.11.19 - 14:36
(173) Значит вы подтверждаете свои рекомендации по поводу разбиения документа на части. По моему это были вы в нашем споре по возможности работы в УТ11 при большом количестве номенклатуры
   unenu
 
175 - 15.11.19 - 14:39
рак - лебедь - щука
   H A D G E H O G s
 
176 - 15.11.19 - 14:40
(174) Да если тормозило редактирование ТЧ (в чем я сомневаюсь, тормозит редактировать ТЗ, но не ТЧ) - всегда можно запилить РС и динамический список, но никак не пускать конфу на кривую дорожку ухода от всей типовой ветки развития.

Как там дела с маркировками? Вас пока не коснулось?
   ProxyInspector
 
177 - 15.11.19 - 14:45
(176) Тормозило как раз редактирование ТЧ. И тормозило даже без перехода не сервер. А с переходом просто умирало.
Маркировка не коснулась. Но если доживем до маркировки, то это не будет типовая конфигурация. На типовых конфигурациях работать могут только ларьки
   ambrozii-fadeevich-s
 
178 - 15.11.19 - 14:49
Корректировка регистров (или свое по аналогии) отлично справляется с такого рода задачами. Спор ни о чем на 2 страницы. Про агрегаты тут выше тоже верно упоминали, хотя и не обязательно.

Но можно другим способом решить: Core i7 поставить на сервак, и обязательно сам сервер и всю серверную освятить.
   ProxyInspector
 
179 - 15.11.19 - 14:52
(178) Про агрегаты я не понял. Слово красивое Агрегаты
   ProxyInspector
 
180 - 15.11.19 - 14:53
(178) На УФ есть корректировка регистров? Что то я очень сильно сомневаюсь.
   RomanYS
 
181 - 15.11.19 - 14:54
(180) В смысле? В большинстве типовых есть
   ambrozii-fadeevich-s
 
182 - 15.11.19 - 15:06
(179) https://its.1c.ru/db/pubessence#content:144:hdoc
но не факт, что в данном примере это вот прямо обязательно нужно использовать.

(180) Рукалицо. Конечно есть.
   ProxyInspector
 
183 - 15.11.19 - 16:03
Посмотрел я эти Агрегаты. Как и все новые фишки, эта фишка сделана через зад. Мне очень понравилось
"Если в информационную базу постоянно вводится много новых данных, перестроение нужно выполнять регулярно. Например, раз в сутки".
Как я понял, эти агрегаты имеют смысл только для периодичности, отличной от стандартной для регистра оборотов. В моем случае этой необходимости нет.
   GANR
 
184 - 15.11.19 - 16:10
(0) На кой? Не надо в ТЧ хранить - просто воспользоваться документом Корректировка регистров. Последний во всех типовых присутствует.
   тарам пам пам
 
185 - 15.11.19 - 16:13
(183) эта "новая фишка" присутсвует в платформе с версии 8.2, т. е. лет десять уже.
   ptiz
 
186 - 15.11.19 - 16:28
Грузить сразу в оборотный РН. Это если нужны сводные итоги. А то и в РС независимый можно. Непонятно, что тут обсуждать на 200 постов.
   ProxyInspector
 
187 - 15.11.19 - 16:37
(186) Там же надо обработать первичные данные, привязать К контрагнетам, магазинам, возможно исправить ошибки. Поэтому табличная часть достаточно удобная. Видно, что проблем с такими большими документами нет.
  Сейчас остался вопрос с возможностью СКД работать с большим оборотным регистром.
  В четверг узнаем. Для начала на 100 млн. записях
   Сияющий в темноте
 
188 - 15.11.19 - 23:31
Проблема управляемых форм-хождение на сервер без лишнего повода.
   Сияющий в темноте
 
189 - 15.11.19 - 23:31
Можно,кучу оставить на сервере,а показывать только видимую часть.
   Ralph
 
190 - 16.11.19 - 07:23
я думаю, что автору надо переходить на фузину!
   ProxyInspector
 
191 - 09.01.20 - 10:04
Фузина, как сообщали разработчики, с этим справиться не может. Вернее может, если к ней прикрутить внешнюю BI базу для хоанения данных и внешнюю приблуду для построения отчетов.
   ProxyInspector
 
192 - 09.01.20 - 10:08
1С с подобной задачей справилась со скрипом. Напомню постановку задачи. Имеются данные по продажам Федеральных Торговых Сетей типа Перекресток, Пятерочка, Карусель, Ашан, Дикси в виде файлов Exell. Общий количество строк в районе 100 млн. Надо все это затащить в оборотный регистр и сделать Анализ с помощью отчета на СКД.
   1Сергей
 
193 - 09.01.20 - 10:10
(192) очень типичная задача, ага. Каждый одинесник рано или поздно с ней сталкивается
   ProxyInspector
 
194 - 09.01.20 - 10:18
Сначала нарвался на ограничение в 99 9999 строк для табличной части документов. Разарботчики 1С почему-то посчитали, что для ларьков больше и не надо. В форме документа платформа дает возможность заполнить документ как минимум в несколько млн строк, но при сохранении говорит, что сохранить может только 99 999. Пришлось делать РегистСведений для хранения табличной части документа. При открытии табличная часть восстанавливается из регистра сведений. При проведении данные берутся из этого регистра.
  При таком подходе можно вполне комфортно работать с документами по 200-300 тыс строк, и чуть менее комфортно с документами по 1 млн строк.
  Типичные параметры при работе с документами в 1 млн. строк:
1. Время открытия - 30 сек
2. Время сохранения - 2-4 мин
3. Время проведения по одному регистру 4-5 мин
   ProxyInspector
 
195 - 09.01.20 - 10:23
Вторая проблема была чтение документов EXELL размеров в 1 млн строк. Построчно читать такие файлы не реально, поэтому такие файлы читаются кусками по областям исходного документа. Здесь возникло ограничение 100 тыс строк. Если больше, то Exell не мог прочитать такие области. Но частями по 100 тыс строк читал без проблем. Типичныое время чтения файла размером 1 млн строк:
1. Примерно 1 мин
   ProxyInspector
 
196 - 09.01.20 - 10:27
Програмное заполнение табличной части в 1млн строк. Здесь проблем не возникло. Типичное время 2-4 мин
Обработка табличной части. Все великолепно. Отборы, установка реквизитов. Время в районе 30 сек.
   1Сергей
 
197 - 09.01.20 - 10:28
(194) (195)
1. Для чего человеку оперировать документом в миллионы строк? тут не в ларьках дело
2. Это проблема не 1С, ексель сам не может работать с такими объёмами
Такое ощущение, что вы пытаетесь в гараже адронный коллайдер запустить
   ProxyInspector
 
198 - 09.01.20 - 10:29
Проведение. По одному оборотному регистру 1 млн строк - 4-5 мин.
   ProxyInspector
 
199 - 09.01.20 - 10:30
(197) Нормально работает EXELL c документам 1 млн строк. Время открытия  в районе 10 сек, а всякие отборы на лету.
   1Сергей
 
200 - 09.01.20 - 10:30
(198) зачем
  1  2  3   

Список тем форума
Рекламное место пустует  Рекламное место пустует
Компьютер — устройство разработанное для ускорения и автоматизации человеческих ошибок.
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.