Возможно вопрос покажется глупым, тем не менее. У меня есть табличная часть с 15 реквизитами. По необходимости для расчетов надо добавить еще порядка 25-30 реквизитов. Судя по субъективным наблюдениям, это уже перебор для одной ТЧ.
Но вынести в отдельную не получается так как эти 25-30 реквизитов должны быть жестко связанны с 5 из первых 15. Попробовал организовать отдельную ТЧ, и "синхронизировать" их между собой. При 500 строчках уже задержки 25-30 сек при любом изменении.
Подскажите пожалуйста, куда копать? Как быть? Плодить слишком много реквизитов ТЧ, или можно как-то не программно "связать" две разных ТЧ?
Но вынести в отдельную не получается так как эти 25-30 реквизитов должны быть жестко связанны с 5 из первых 15. Попробовал организовать отдельную ТЧ, и "синхронизировать" их между собой. При 500 строчках уже задержки 25-30 сек при любом изменении.
Подскажите пожалуйста, куда копать? Как быть? Плодить слишком много реквизитов ТЧ, или можно как-то не программно "связать" две разных ТЧ?
По теме из базы знаний
- Универсальный реестр всех документов, с возможностью вывода данных из табличных частей (для любых конфигураций 1С:8)
- Групповое редактирование реквизитов табличной части и движений документов LITE (управляемая форма)
- Универсальная обработка: Замена и установка реквизитов табличных частей
- Типовые операции в 1С: БГУ 2. Часть 3
- Разбор ошибок заполнения реквизитов формы объекта (мой топ-3)
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(2) sssss_aaaaa_2011, Немного в курсе про регистры. Беда в том, что по сути расчет производится много раз.
ТЧ документа. Расчеты идут по 21 колонке. Делаются при каждом изменении основной части ТЧ (т.е. пока забьётся документ 30-40 раз пересчитает).
Относительно регистров идея наверное хорошая. Но как это всё хранить? И как объединить итого.
Моя мысль была сделать одну большую суперТЧ, и вывести её в форме на 2 таблицы (одна сторона основная, другая чисто для расчетов). Использовать разные таблицы напряжно т.к. порядок в таблице расчетов нужен такой же как и в основной. И постоянная проверка, не поменялось ли чего, не передвинули ли объекты и т.д. на таблице с 500 строками уже очень долго.
Относительно регистров сведений надо бы подумать. Но не представляю как это сделать. Добавить в движения записи по регистрам из данных ТаблицыЗначений в форме документа, и заполнять каждый раз при открытии? Или как?
ТЧ документа? Справочника? Что за расчеты, насколько часто они производятся?
ТЧ документа. Расчеты идут по 21 колонке. Делаются при каждом изменении основной части ТЧ (т.е. пока забьётся документ 30-40 раз пересчитает).
Относительно регистров идея наверное хорошая. Но как это всё хранить? И как объединить итого.
Моя мысль была сделать одну большую суперТЧ, и вывести её в форме на 2 таблицы (одна сторона основная, другая чисто для расчетов). Использовать разные таблицы напряжно т.к. порядок в таблице расчетов нужен такой же как и в основной. И постоянная проверка, не поменялось ли чего, не передвинули ли объекты и т.д. на таблице с 500 строками уже очень долго.
Относительно регистров сведений надо бы подумать. Но не представляю как это сделать. Добавить в движения записи по регистрам из данных ТаблицыЗначений в форме документа, и заполнять каждый раз при открытии? Или как?
(1) BlackMess, не вижу криминала в количестве реквизитов в 30 шт. Как пример, в ЗУП в документе "ТабельУчетаРабочегоВремениОрганизации" в ТЧ "ОтработанноеВремя" реквизитов вообще более 240.
Но все же для выбора решения нужно четкое понимание поставленной задачи.
Но все же для выбора решения нужно четкое понимание поставленной задачи.
(5) TMV, Просто Я 1с-ник самоучка и хотелось бы как-то правильно сделать. Задача стоит такая: в заказе покупателя есть номенклатура, в зависимости от вида номенклатуры подтягивается что-то вроде расчетного листа по ней. В нем стоит материал, стоимость материала 10-11 операций (отдельный реквизит под названия для каждой т.к. операции могут существенно отличатся), вариант схемы расчета (ссылка на справочник), и поле под итоговый расчет. Так как есть группы номенклатуры по которым не все поля могут быть автоматически рассчитаны (допустим нет подходящего материала) необходимо делать проверку этих значений, или добавлять/убирать операции. Вот так как-то и получается. Реализовал сейчас двумя разными ТЧ и при изменении в первой, вторая пересчитывается, т.к. не знаю как отследить изменение порядка, то ПриИзменении строки идет полный пересчет всех строк ТЧ (понимаю что это не очень оптимально, но не знаю как сделать лучше, собственно потому и спрашиваю). Поскольку расчеты даже при изменении порядка остаются такими же, то Я заново заполняю каждую строчку расчета. Пока позиций в счетах было 10-30, это всё хорошо работало, сейчас столкнулся со счетами в 500 позиций, при изменении 1 строчки программа на перезаполнение тратит под 20-40 секунд... соответственно чтобы проставить допустим одну пропущенную операцию (по сути нажать цифру, enter, стрелку вниз 500 раз) уходит под 1,5-2 часа. И это уже очень плохо. Решил что если всё будет в одной ТЧ, то проблема с порядком исчезает, и не надо пересчитывать ВСЕ строки (достаточно только ту, которую поменяли) но такое ощущение что это как-то не правильно.
Есть ли другие варианты? Или Я на верном пути?
Есть ли другие варианты? Или Я на верном пути?
(6) BlackMess, похоже на производственную спецификацию. Сделать можно весьма разными способами, при этом данные лучше разделить на временные/эфемерные (которые нужны только во время расчета) и постоянные/перманентны (которые нужно хранить). Вот эти постоянные нужно засовывать в ТЧ, а остальные по мере необходимости читать, допустим, в таблицу значений/соответствие и хранить, пока жива форма, в которой производятся расчеты. Нарисуйте себе источники данных и их взаимосвязи, после чего определите, что с чем взаимодействует при расчете и куда помещается результат, что является промежуточными итогами, а что окончательными. Ну и от этой схемы рисуйте архитектуру, где не будет повторов - это и есть идеальное решение.
(6) BlackMess,
Но у меня некоторая специфика - расчетов на каждую позицию Номенклатуры мало. Если же таких расчетов окажется много, придется додумывать интерфейс на предмет облегчения поиска нужного расчета из многих похожих ))
Задача стоит такая: в заказе покупателя есть номенклатура, в зависимости от вида номенклатуры подтягивается что-то вроде расчетного листа по ней. В нем стоит материал, стоимость материала 10-11 операций (отдельный реквизит под названия для каждой т.к. операции могут существенно отличатся), вариант схемы расчета (ссылка на справочник), и поле под итоговый расчет. Так как есть группы номенклатуры по которым не все поля могут быть автоматически рассчитаны (допустим нет подходящего материала) необходимо делать проверку этих значений, или добавлять/убирать операции.
Кажется, начинаю понимать. Я в сходной задаче делал по-другому: завел справочник РасчетыСебестоимости, подчиненный Номенклатуре. Его форма элемента приспособлена именно под расчет - там и материал, и все остальное. В строке итогового документа указывается ссылка на подчиненный Номенклатуре расчет. При вводе или при смене Номенклатуры юзер руками указывает на требуемый расчет или заводит новый.
Но у меня некоторая специфика - расчетов на каждую позицию Номенклатуры мало. Если же таких расчетов окажется много, придется додумывать интерфейс на предмет облегчения поиска нужного расчета из многих похожих ))
(23) MaxDavid, Слушай, а это красивое решение. Но к сожалению нет. Расчетов будет по 12-15 вариантов на около 10000 единиц номенклатуры. Думал прицепить прямиком один расчет, и править его, но тогда расчеты где эта позиция еще может участвовать будут уже не верные. Похоже всё верно мне сказали раньше, копать в регистры сведений
(7) Voffka, Эмм... Попробую написать что конкретно в конечном итоге ожидается:
Есть счет. В счете номенклатура. Отдельная вкладка в том же самом счете. В которой выведена в список та же самая номенклатура которая в счете. Только к ней указаны стоимость заготовки и марка материала, и названия и стоимость 5-8 операций. (к каждой номенклатуре). Указано как эти предварительные расценки перевести в итоговую цену (по сути формула). Собственно потом сумма всех колонок (ориентировочная себестоимость) и итоговая цена.
Вроде как всё описал.
Разумеется колонки материала, и операций у каждой позиции свои. Предустановленные не всегда верны, потому их пользователь проверяет, и по необходимости правит. Потому половина из этих колонок может быть как расчетной из программы, а половина может быть данными от пользователя.
Есть счет. В счете номенклатура. Отдельная вкладка в том же самом счете. В которой выведена в список та же самая номенклатура которая в счете. Только к ней указаны стоимость заготовки и марка материала, и названия и стоимость 5-8 операций. (к каждой номенклатуре). Указано как эти предварительные расценки перевести в итоговую цену (по сути формула). Собственно потом сумма всех колонок (ориентировочная себестоимость) и итоговая цена.
Вроде как всё описал.
Разумеется колонки материала, и операций у каждой позиции свои. Предустановленные не всегда верны, потому их пользователь проверяет, и по необходимости правит. Потому половина из этих колонок может быть как расчетной из программы, а половина может быть данными от пользователя.
(13) aka Любитель XML, Не много не понял как это работает. т.е. Я на каждую строку в счете каждого счета должен сделать по записи в регистре, и туда уже записать всё что мне нужно, и потом просто достать и посчитать если надо. Верно Я понимаю?
(14) Voffka, Примеры: Поменялась номенклатура, находим другую, соответствующую ей технологию, и пересчитываем все поля исходя уже из неё. Поменялось количество: другая технология тоже может быть.
Второй момент: Если счет на 500 позиций, если номера строк не будут совпадать, то на поиск нужных данных в расчетах (чтобы проверить) уйдет больше времени.
(14) Voffka, Примеры: Поменялась номенклатура, находим другую, соответствующую ей технологию, и пересчитываем все поля исходя уже из неё. Поменялось количество: другая технология тоже может быть.
Второй момент: Если счет на 500 позиций, если номера строк не будут совпадать, то на поиск нужных данных в расчетах (чтобы проверить) уйдет больше времени.
(18) sssss_aaaaa_2011, На самом деле сделать через регистр сведений кажется заманчивым. Только видимо не совсем понимаю как это работать будет. Чтобы делать записи мне надо каждый раз проводить документ. Разве не так? Знаю что есть независимые, но когда Я сталкивался с ними, не смог разобраться как там не занести новую запись, а "обновить" данные в ней. Подскажите пожалуйста, если это возможно (в смысле "обновить" запись) и с точки зрения методологии нормально, то тогда так и буду делать.
По сути разобраться смогу и сам. Мне бы лишь бы принцип как оно верней :)
По сути разобраться смогу и сам. Мне бы лишь бы принцип как оно верней :)
(18) sssss_aaaaa_2011, Кажется Я понял идею. Записывать документ не надо. Всё происходит в форме (и считается тоже) пока она существует. А при закрытии, мы или отменим изменения и ничего делать не надо. Или обновим запись, собственно документ как раз проведется. Я верно понимаю?
(19) Voffka, Эм. Ваши чувства вас не обманывают. Так и делаю. Я всегда исходил что счет на 10000 позиций забивать в базу просто не рационально. И в принципе всё работало неплохо. Но как сделал загрузку с парсингом себе небольшую... счета стали значительно больше по позициям.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот