Допустим есть журнал "Реализация". В требуется вывести дополнительные колонки.
Наподобие "Есть расходный ордер", "Возврат", "Перечень номенклатуры документа", "Есть ПКО", "Есть банк" и т.д.
Делать это запросами к куче таблиц надоело.

Хочется завести какой нибудь вспомогательный объект для хранения данных и изменять его подписками на события например.
Подскажите чего нибудь хорошего.

Регистр сведений: измерение - Объект, ресурсы - необходимые значения.

Мне кажется, что лучше написать 1 раз нормальный запрос, в который будет легко добавлять новые данные, чем создавать новые объекты метаданных для этого. Потому как для запонения того же регистра сведений всеравно прийдется делать

При записи того или иного документа делается запись в регистр, какие еще запросы?

Для того, чтобы данные записать в нужном виде их необходимо как-то/откуда-то получить. "Как-то" - это скорей всего с использованием запросов. Ваш Кэп.

Данные в нужном виде это и есть документ Источник события. который, например, по полю Основание = Объект в РС запишет данные о себе. Не надо никаких запросов.

Берем УТ. Вы говорите, что эти данные:

можно взять из источника события, т.е. в данном случае из расходной накладной? Как же...

"Есть расходный ордер" - при записи Источника ордера в нем же есть ссылка на документ Объект? При записи Источника возврата в нем же есть ссылка на документ Объект?....

Я говорю о том, что записи в регистр должен делать не сам Объект, а документы которые связаны с этим Объектом по полю которое определяет связь.

Именно. (Например ПКО вводится на основании РН. Центральным документом сделки будет заказ либо РН если заказ не заполнен).

И я спрашиваю какие есть интересные варианты в каком дополнительном объекте хранить связанную инфу.
Пока только одно предложение.

А, ну я знач не так изначально понял. Тогда, тут только 1 вариант может быть: только регистр сведений. Если сделать как по проще, то выше logist вариант озвучил. Но можно сделать по сложнее, но, по-моему, красивше будет: сделать 2 измерения Объект и НазваниеДопКолонки. Название доп. колонки - это может быть какое-то перечисление либо какой-то справочник. Работать с такой структурой будет сложнее, за то структура хранения данных будет корректнее и без излишек, я считаю.

Vofka, какой тогда тип данных у значения регистра сведений будет? И как оно потом в БД хранится?

А отборы планируется строить по этим колонкам дополнительным?

python, я не знаю конечной цели, мог бы предположить, что на все хватит типа "строка". Если тип должен быть разный, тогда использовать план видов характеристик (по типу как настройки пользователя сделаны).

При пометке на удаление ПКО запись из регистра удалится. А если ПКО 2 штуки - то одна запись должна остаться.



А если вдруг потребуется - то тогда какие объекты использовать?

Тогда 3 измерения: Регистратор, ВладелецСвойства (расходная накладная, в данном случае), Свойство.

А что дает сам факт наличия ПКО? Или возврата?
По-доброму нужно примероно так
Заказ
Отгружено на ... грн
Оплачено на ... грн
Выписано НН на ... грн
Возврат на ... грн

А еще лучше сразу выводить отклонения? нпр "недовыписано НН на ... грн. Тогда юзеру не придется вчитываться в цифры и сравнивать их.
Или не цифры, а колечки, как в УНФ.

Какова все же цель этих реквизита? Тип данных содержания?
Если текстовая метка для журнала - так можно просто регистр сведений, и значение каждой из колонок отдельно для объекта хранить. Придется менять метаданные - это да. Но и код для извлечения и вывода данных будет проще. В принципе - и тип данных может быть разным...
Неопределенный тип данных значения и вид свойства в измерении - 1с создаст несколько полей для хранеия каждого из типов значения, не хорошо это.

Еще вариант - значения хранить в отдельном справочнике, пусть даже текстовые. Тогда и отборы можно будет строить.

нужно нарисовать дерево всех возможных решений, отталкиваясь от центрального документа. Обозвать каждую точку-состояние как-то и описать, чтоб понятно было пользователю (пример "РН-Возврат-РКО"). При совершении события (проведении дока, пометке на удал, снятии пометки на удал,.... ) изменяем точку-состояние, на другую точку-состояние (точки-состояния хранятся не знаю где). В журнале "Реализация" ссылка на точку-состояние.

Думаю, так лучше не делать. Есть пример - РС КонтактнаяИнформация в типовых. Вначале было хорошо, теперь получился этакий монстрик.

Других предложений по объекту хранения данных не будет, logist выдал единственно правильное.
Принять его мешает то, что придется писать запрос по двум таблицам - т. е. данные хранятся неоптимально с точки зрения удобства извлечения.
Но это беда не решения, а постановки задачи.
Строго говоря, это надевание седла на корову - форма списка документа хороша для решения своих задач.
По-моему, лучше использовать форму списка того самого РС, в который все документы сами о себе все запишут.
Если одного РС будет мало - тогда отчет формоспископодобного вида.



Дерево получится, нпр, для статуса документа. Оплату и возврат в одно дерево не запихнешь.

А не лучше ли заменить журнал на обработку?

Почему?

я, наверное, не понимаю, что имеется в виду у вас.

у меня "точка-состояние" - это не событие (оплата или возврат), а комбинация,(или последовательность) событий.

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

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


но нужно предусмотреть вариант частичных оплат, отгрук..

Более сложно выдергивать данные.
Скорее всего, это только начало. Юзерам понравится, начнут еще придумывать
Да и без этого, получится длиннющий РС, по которому будут одновременно топтаться все юзеры

В чем сложность?


Не вижу проблем с этим. За то в обмен не будет излишних данных.

В случае регистра с контактной информацией - его беда в том, что поля называются Поле1, Поле2 ... ПолеN. Регистр этот был бы нормальным если бы поля назывались человекопонтяно либо если бы ресурс был 1, а взамен было 1 дополнительное измерение, которое идентифицировало бы конкретную составляющую адреса. Да, может быть тогда запрос получится не просто "ВЫБРАТЬ * ИЗ Регистр", может быть он будет дольше выполняться, за то в таблице базы данных все данные будут согласованы и не будет мусора. Это мое мнение.

имея дерево состояний нельзя будет, к примеру, просто так пометить на удаление документ, на котором завязаны другие документы. потому-что они будут уровнем ниже в дереве. также нельзя будет ввести просто так РКО, когда будет БВ с таким же движением. так как это тоже будет "перескок" на другую ветку.



ну в общем, да. я не программирую, поэтому не могу подать предметно это все дело. поэтому про зайчиков, что хотят стать ёжиками.

Домовик, я вот о чем.
Состояние,нпр, "оплачен+отгружен+отправленыБухДокументы" может быть достигнуто разными путями - разная последовательность событий. Это уже не дерево, в дереве путь между двумя точками уникален.

ну вообще-то изначалоьно имелось в виду, что "оплачен-отгружен-отправленыБухДокументы" и "отгружен-оплачен-оправленыБУхДокументы" -два разных состояния. состояния сохраняют история событий, но состав событий у них один и тот же.

дерево это ж вид графа. значит просто граф. направленный граф.

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

т. е уже формируются понятия

-событие (может исполняться разными документами)
-состояние (характеризуетс набором событий, направленностью событий , завершенностью/ незавершенностью)


вобщем, логику по которой бухгалтера отслеживают движения документов, можно также программно задать. Не только задавать механизми отслеживания.