Возникла задачка, хранить статусы каждой позиции товара в заказе. Статусы нештатные.
Например,
товар принят для обработки в заказе (Принят).
Товар заказан у поставщика (Заказан)
Товар готов к отправке (Готов)
Товар отгружен, заказ закрыт (Отгружен)
...
Вопрос пока теоретический. Склоняюсь к варианту регистра сведений, в котором Измерения: заказ, номенклатура. Ресурс: цена, количество, статус.

(0) учет по сериям/хар-кам ведется?
т.е. может быть в одном заказе одна номенклатура в 2х строках с разными сериями к примеру?

просто я с таким встречался...

+ (1) а как отображаться статус будет?
по идее +колонка в ТЧ - но все равно РС лучше, чтобы весь док не перезаписывать при изменении статуса всего одной позиции.

как это все мило будет листаться при скролинге

// к варианту регистра сведений, в котором Измерения: заказ, номенклатура. Ресурс: цена, количество, статус.

А регистраторы в этом регистре будут?

(1) Учет по сериям и характеристикам не ведётся. Точнее серии есть, но они заполняются в табличной части потом отдельно. (2) Статус будет потом передаваться на сайт в личный кабинет покупателя. Но это уже второй шаг. Я хочу сначала добиться оптимального хранения оперативной информации. Я отказался от хранения в документе, чтобы не перезаписывать.
(3) Просмотр не предусматривается. При желании можно включить фильтр по отдельному заказу.
(4) Пока рассматриваю вариант без регистратора

(3) про ПриПолученииДанных() для ТабПоля ни разу не слышал?...

(6) Поясни мысль. В СП я потом посмотрю.

(5)
// (4) Пока рассматриваю вариант без регистратора

Я к тому, что статус должен кто-то устанавливать и затем кто-то должен будет этим статусом пользоваться. Без указания в задаче входа и выхода бесполезно искать черную кошку в темноте

(7) это я в ответ на замечание "Agent ООЗ" что отображение статуса в ТЧ дока якобы будет тормозить при скроллинге...

но это как я уже понял и не требуется.

(8) Я понял про регистратор. Согласен.
Есть еще вопрос: В табличной части заказа покупателя могут быть две одинаковых позиции номенклатуры. Так заполняется заказ на сайте.
Есть ли у табличной строки документа внутренний идентификатор, чтобы потом по нему отделить одну номенклатуру от другой?  Номер строки может измениться, если пользователь сменит порядок строк.

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

(0) ну и если заранее известно что товар поступил, делать регламентное которое бы обновляло статусы автоматически.

(11) обороты по регистру не нужны. В табличную часть документов ничего добавлять не хочу, чтобы не было лишних завязок на перезапись.
(12) регламентное задание будет для считывания заказов и формирования Заказов покупателя. Но это пока не входит в сабж.

(10) кол-во и цена, может скидка еще...
на а про серии и хар-ки я сразу сказал.

(14) Скорее всего цена, т.к. одинаковая номенклатура возникает из-за разных цен отгрузки от разных поставщиков. Я её положу в измерение, а количество в ресурсы. В регистре еще будут идентификаторы заказа и номенклатуры на сайте.

(6) и каким образом оформление строк убыстряет доступ к данным из другой таблицы. 1с сама по себе тормоз, которых поискать нужно.

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

(17) Разверни маленько.

регистр сведений со статусом доступности товара по времени

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

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

(21) Отправка данных в личный кабинет проводится после сверки оператором, поэтому промежуточный регистр с готовой информацией предпочтителен. Возможно, после полной автоматизации всех процессов и можно отказаться от этого, но пока не полностью сформирован набор статусов, которые Заказчик хочет видеть на сайте.

(17)+1:
товар принят для обработки в заказе (Принят) - заказ проведен
Товар заказан у поставщика (Заказан) - по регистру РазмещениеЗаказовПокупателей
Товар готов к отправке (Готов)-есть в наличии и зарезервирован  под заказ(если не предполагается какая-то обработка товара)
Товар отгружен, заказ закрыт (Отгружен)- нет остатков по заказу покупателя.

(0) РН Заказы покупателей. Добавить реквизит Статус.

(24) Если не трудно, сформулируй перечень возможных статусов. Открыт, Закрыт. Понятен. Есть варианты: Отправлен поставщику, Подтвержден поставщиком, Отказ, Готов к отгрузке. Что-то еще?

Из УТ 11

Согласован
НеСогласован
КОтгрузке
Кобеспечению
Закрыт

(26) Спасибо

(10) > В табличной части заказа покупателя могут быть две одинаковых позиции номенклатуры. Так заполняется заказ на сайте.

От этого лучше избавиться. Потом принесет много проблем.

>Есть ли у табличной строки документа внутренний идентификатор, чтобы потом по нему отделить одну номенклатуру от другой?

Есть только номер строки. Прочие идентификаторы нужно добавлять самостоятельно.