Есть Форма документа. На ней лежит Многострочная часть этого документа.
Добавил колонку в которой хочу отображать данные соответствующие строкам документа из внешнего источника . Хранить данные (на время редактирования) в этой самой Многострочной части 1С 7.7 не позволяет. Храню их в массиве. Пользователь может изменять эти данные. Я вызываю соответствующий диалог в ПриНачалеРедактированияСтроки для нужной мне колонки. Сохраняю в массив. Все красиво. Как быть с удалением строк, вставкой и т.д. - мне надо отлавливать соответствующие события и вставлять и удалять элементы массива или есть более интересные решения ?
Массив заполняю и сохраняю соответственно при открытии и сохранении документа.
Можно добавить еще один атрибут в Табличную Часть и его использовать, но не хотелось бы структуру базы сильно изменять - она и так пухнет, а таких колонок может быть несколько с разнородными данными.
Мне бы идею- в какую сторону копать :)
ТЗ+ТП
ТЧ->ТЗ при открытии
ТЗ->ТЧ при записи
ТЧ на Форме <> ТЧ Документа
ИМХО, как показать в ТЧ на Форме ТС знает, а вот где хранить весь этот хлам - нет.
Ну... если хранить в 7ке, то можно в Справочнике, в Реквизит засунуть Документ, НомерСтроки,идРеквизита (можно Перечисление сделать) и значение неопределенного вида или как будет удобнее.
При галке Сортировка на Документ`е, должно быть шустро. Получается не периодический аналог регистра Сведений 8ки.
Контролировать тоже особенно не надо, в ПриЗаписи удаляем все по ключу Документ и записываем то что есть...
Тормозить не должно, но это смотря сколько строк в документе и сколько разных реквизитов, mssql или 1sqlite поможет.
Если хранить во внешней базе, то примерно такая же структура таблицы нарисовывается.
Цитата: Djelf от 09 декабря 2024, 14:59...
Контролировать тоже особенно не надо, в ПриЗаписи удаляем все по ключу Документ и записываем то что есть...
...
При таком варианте при записи удалили из справочника "все по ключу Документ" - а где мы берем "то что есть" ?
Я бы хотел увидеть некий вариант виртуального атрибута табличной части - который живет только во время жизни формы, а до и после этой "жизни" хранение данных обеспечиваю я :)
Цитата: trad от 09 декабря 2024, 14:39ТЗ+ТП
ТЧ->ТЗ при открытии
ТЗ->ТЧ при записи
Пока это самый рабочий вариант, но придется переписывать логику всех существующих форм на работу с ТЗ вместо ТЧ.
Вот только что переделывал учет прослеживаемости под такую схему: вместо "1 строка - 1 РНПТ" делал "1 строка - ТЗ РНПТ". И тоже ломал голову. Пришел, если упрощённо, к такому:
Добавил новый реквизит табличной части - идентификатор строки в ТЗ (IdСтрокиВТЗ) Число(5.0) , она же ключ, пользователю недоступен. Общую ТЗ с нужными данными по документу - можно хранить в шапке в неограниченной строке ОбщаяТЗСтрокой=ЗначениеВСтрокуВнутр(ОбщаяТЗ), но может лучше как Djelf советует - в справочник засунуть, а может в строке табличной части - здесь MWW_Ruza так хранил марки ЕГАИС (https://forum.dorex.pro/index.php?topic=199.0). При вводе данных, если в редактируемой строке их ещё не было - присваиваешь реквизиту IdСтрокиВТЗ первый свободной номер (хоть перебором от 1 - всё равно это быстро). При редактировании существующих данных (то есть если для строки IdСтрокиВТЗ<>0) выводишь кусок ТЗ по ключу IdСтрокиВТЗ.
Контроль удаления строк с данными - в ПриЗаписи() анализируешь и удаляешь из общей ТЗ те строки, где указаны IdСтрокиВТЗ, которых в документе нет.
Контроль при копировании - обязательно зануляешь IdСтрокиВТЗ при копировании строк:
Процедура ПриРедактированииНовойСтроки()
IdСтрокиВТЗ=0;//вдруг копировали - обязательно надо занулить!
КонецПроцедурыа также в ВводНового - если документ копируется и ТЗ данных должна быть нулевая.
Контроль удаления строк - не нужен, мы ПриЗаписи почистим ТЗ;
Контроль изменения номеров строк и сортировки строк - не нужен, IdСтрокиВТЗ не привязан к номеру строки документа.
IdСтрокиВТЗ можно конечно и ГУИДом Строка(36) сделать, а не Числом(5.0), но это лишнее усложнение, как по мне.
Визуально на форме я делал текстовую колонку с идентификатором ТекстIdСтрокиВТЗ с формулой типа
?(IdСтрокиВТЗ=0,"","есть данные")ну и в модуле
Процедура ПриНачалеРедактированияСтроки()
Если Форма.АктивныйЭлемент()="ТекстIdСтрокиВТЗ " Тогда
глВызовОбработкиРедактированиеНужныхДанных(Контекст);
КонецЕсли;
КонецПроцедуры
Это в чистой 1С.
Если использовать ТП, возможно получится красивее.
Цитата: Харлампий Дымба от 10 декабря 2024, 02:13..
Добавил новый реквизит табличной части - идентификатор строки в ТЗ (IdСтрокиВТЗ) Число(5.0) , она же ключ, пользователю недоступен.
..
спасибо за идею. осталось придумать получения уникальности IdСтрокиВТЗ при одновременной работе нескольких десятков пользователей.
Цитата: vk_barnaul от 10 декабря 2024, 04:29сталось придумать получения уникальности IdСтрокиВТЗ
Я понял. Я, наверное, спутанно назвал - IdСтрокиВТЗ.
Суть переменной - это Id строки табличной части документа, используется как ключ к ОбщейТЗ этого документа.
ОбщаяТЗ - отдельная таблица значений в каждом документе.
В ОбщейТЗ есть колонка "IdСтроки" - чтобы знать к какой строке документа эти данные относятся, ну и колонки с собственно данными. При этом если к строке документа нужно несколько строк данных (в моём случае это ГТД), то в ОбшейТЗ может быть несколько строк с одинаковым IdСтроки.
IdСтроки уникально в пределах табличной части документа - с документом работает один пользователь.
ОбщиеТЗ можно, например, разложить построчно в справочнике (вариант Djelfа) с ключом СсылкаНаДокумент.
Уникальность IdСтроки в целом не нужна. Её надо обеспечить только в рамках документа - в табличной части документа не должно быть строк с одинаковым IdСтроки.
Ну и, как я сказал, если размер таблицы не проблема и хочется уникальности в целом - можно для IdСтроки использовать ГУИД.
#5 "здесь MWW_Ruza так хранил марки ЕГАИС"
Ну, на самом деле - хранение марок и 7.7, тема достаточно нетривиальна...
В разных документах - храню по разному, но, это лишь ссылки на них - сами они хранятся в справочники "Марки", подчиненном справочнику "СпрF2".
А вот тут, идет особенность, может ошибка, а может и не ошибка, х.з., с самого начала, когда появилась потребность хранить марки в базе.
Были не очень понятны "масштабы трагедии" :-) - объем этих справочников за несколько лет работы. Было опасение, что распухнут до неимоверных размеров... Хранить во внешней базе? Можно конечно, но, стоит ли? Поэтому решил организовать "внешнюю базу" внутри основной базы 1С - "разорвав" ссылочную целостность на уровне справочника СпрF2. Т.е., он живет сам по себе, и ссылок на него в документах нет. Есть в документах текстовые поля, которые содержат наименования справок F2. При оперециях в документах, СпрF2 ищу по наименованиям (они уникальны, и контролируется их уникальность при записи). Лучше было-бы конечно по коду, там уникальность можно было-бы контролировать на уровне платформы, но длина номеров СпрF2 не лезет в код по длине...
Зато, это дает возможность "чистить" этот справочник регламентной процедурой периодически, от проданных и уже не актуальных позиций справок и подчиненных им марок. Ссылок нет - если статус "Продана" или "Списана", то можно и удалить, ее номер останется в документе на всякий случай (при необходимости - по нему можно будет и перезапросить справку, и марки по ней).
Поэтому во входящих ТТН я храню только номер справки F2, по нему можно найти элемент справочника и подчиненные ему марки. Хранить их в документе ТТН нет необходимости.
А вот в документах "Инвентаризация ЕГАИС регистр 1" - пришлось извращаться... Тут, хочешь не хочешь, нужно еще хранить список марок, фактически имеющихся в наличии - отсканированных при "живой" инвентаризации.
Стал вопрос - "ГДЕ?"... Ну, учитывая, что их не так уж и много будет по каждой справке, это все-таки розничные магазинчики, принял решение сделать у них код числовым и не очень длинным - ограничился 8. Хотя, это тоже с большим запасом. Тогда, методом "ВСтрокуСРазделителями()", даже при самых худших раскладах больше сотни марок поместится в максимально допустимую длину строки для реквизита ТЧ документа - 999. Что более чем достаточно.
Конечно, для крупных оптовых контор, этого может и не хватить, но их на 7.7 и не автоматизируют, или тут надо применять другие способы. Да хоть тот-же принцип, как у меня в приходных - хранить реквизит "отсканировано, есть в наличии" в справочнике марок, а в документе только ссылку на элемент владелец - СправкуF2.
Но, мне как-то не было смысла с этим заморачиваться, сделал как сделал :-)
#8 Тогда, методом "ВСтрокуСРазделителями()", даже при самых худших раскладах больше сотни марок поместится в максимально допустимую длину строки для реквизита ТЧ документа - 999.
Хотя, перечитав сейчас что написал - а ведь можно еще увеличить количество марок в каждой строке, если серии кодов сделать не во всем справочнике, а в пределах подцинения... Тогда они будут короче, и соответственно больше влезет.
Но, у меня просто нет таких задачь...
Цитата: MWW_Ruza от 10 декабря 2024, 15:00#8 Тогда, методом "ВСтрокуСРазделителями()", даже при самых худших раскладах больше сотни марок поместится в максимально допустимую длину строки для реквизита ТЧ документа - 999.
Ой нет, так не надо... База помрет очень быстро >:(
Да, согласен, если таких документов много будет.
Но, тут, случай единичный... Инвентаризацию помарочную пользователей не заставишь делать... В лучшем случае - раз в год, да и то, "по обещанию" :-). Да и ценности этот документ особой не представляет - сформировали, отправили в ЕГАИС, ХМЛ сохранили, и забыли про него... Поэтому, не страшно.
А вот для документов "ходовых", тех-же ТТН_ЕГАИС, так делать не стоит.