Дано: Документ "Реализация товаров и услуг" записывает услуги в регистр накопления "Реализованные товары комитентов", потом по его остаткам заполняется документ "Отчет комитенту о продажах" и при проведении соответственно остатки списываются
Было надо: добавить в Отчет поле "Содержание" из Реализации, ну очень надо было) причем изначально это строка неограниченной длины...
было просто добавлено к РН как измерение! строка с ограничением до 400 (чтобы не сильно нагружать базу) спустя год пришло осознание, что простое враг хорошего и надо это дело исправлять... вопрос как правильнее?)
Первое что приходит мне в голову это справочник с реквизитом неограниченной строкой, ссылку в регистр, в реализации придется искать были ли такие строки раньше и использовать предыдущие ссылки, чтобы все не разрасталось непомерно, в отчете для пользователя доставать строку из справочника, а для регистра в виде ссылки... но что-то меня уже гложат смутные сомнения)

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

(0) А почему изменение?!!!
Реквизитов не хватило?

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

(0) если в отчет О ДВИЖЕНИЯХ - то пихать в реквизит.
если ОТЧЕТ по остаткам - то вам тут жпс наступает - придется измерение.
хотя описание/содержание пихать в измерение (любым способом) - это не то что сильное колдунство - это око сарумана, сплошные орки

(0) Что в поле "Содержание" обычно пишут?

Отдельный РС или тянуть из дока как заметил (1)

(1) хорошо бы, но процедура получения остатков за месяц в отчете комитенту уже отработана и она довольно сложная, а так я как-то должен помечать какие реализации я сейчас задействую в конкретном отчете за конкретный месяц, а задействовать я могу не все и не полностью... короче я за этими остатками вручную не хочу следить, регистр накопления с остатками как раз хорошо справляется...
(2) по реквизитам не получить остатков, если вы про "измерение"
(3) шаблон у бухгалтеров какой-то есть, но набирают каждый раз вручную под каждый случай
(4) да, с остатками все хорошо работает, пока индекс таблицы в SQL позволяет) в файловую уже не загружается...
(5) типа "Услуга чего-то там от того-то, дата публикации, договор, тема,..." короче всю галиматью в одном месте собрали и что-то еще в этом понимают)
(6) а с регистром сведений как?

>"Услуга чего-то там от того-то, дата публикации, договор, тема,..."

Это одинаковое на все строчки/позиции в реализации или у каждой позиции свое?

Если Содержание однозначно берется из реализации, то оставить в этом поле Реализацию.

(9) Или "конкретную строку из ТЧ Реализации"

(8),(9) может быть несколько строк в реализации и с разными номенклатурами и с одинаковой номенклатурой, но разным Содержимым, точно новое измерение, только вот как его хранить...
(10) строку ТЧ как в регистр накопления запихнуть? двумя полями документ и НомерСтроки?

(11) Можно но проще составной ключ строковый уид+индекс строки

Кста судя по контексту нечто вроде рекламного-издательского так?

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

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

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

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

(13) даже не товар, а услуги, но штучные, да, получаются, каждый раз заводить номенклатуру смысла нет, характеристик в БП2 нет жалко, а то б проще все было) может правда подобавлять им отдельных реквизитов, но ведь у них и количество этих реквизитов все время разное...
(14) про md5 понял, а что там с фильтром значений, это как? (15) согласен, как ни крути все равно криво получается)

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

(17) не, искать там они пока не хотели, чисто для отчетов перед комитентами, но конечно лучше исправлять сам учет, заводить и классифицировать дополнительные характеристики услуг, в Бухгалтерии 3.0 характеристики наверное уже реализованы? надо их уже переводить, на более передовой учет, а то как на счетах работают)

(18) гахрена в бухии доп характеристики?

(18) ничего там в бух 3.0 не реализовано. Не переводите пока.

(20) почитал уже, печально
(19) в данном случае БП2 единственная учетная система на предприятии, там и менеджеры что-то вносят и управленцы что-то смотрят, так что бухгалтерии может и не нужно, но реализовать надо)

(21) ТЗ очень туманное. Будут проблемы при реализации. ИМХО. Начни с понятного ТЗ.

(22) ТЗ в первом посте, нужно добавить в отчет комитенту содержание услуги из реализации, содержание вносят вручную, все остальное просто мои мысли) заказчик больше ничего не хочет как обычно, просто "чтобы вот эта информация была вот здесь, а там уже как знаешь")

(0) Замени короткой строкой, до 36 символов.
Либо ссылкой на справочник, где будет любой перечень строк неограниченной длинны :)

(11) Справочник, с табличной частью "Комментарии от писателей" :)

(23) Без проблем.
1. Создаешь обработчик события "При записи" или "перед записью", по Документу "Реализации" (побоку как точно назван док.)
2. Пишешь В некий справочник содержимое комментириев.
3. Измерение, реквизит, Ресурс - делаешь в виде ссылки на новый справочник
4. Через Доп структуру Объекта шлешь этот элемент обратно в Объект, что бы в итоге он попал в обработку проведения и являлся измерением в твоем регистре.
...
В СКД уже выводишь как надо.

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

(24) короткой не получится, а в справочник пока выношу только строкой 512... но думаю прикрутить им типа характеристик и показать им как это классно)
(26) там не СКД, "Отчет комитенту" это прежде всего документ, который тоже делает проводки по регистру (уменьшает остатки), печатная форма для хранения уже вторична)

(27) Тогда Через справочник "Аки наши комментарии"
С реквизитами
1. Документ основание
2. Табличной частью "Комментарии потерпевших" :)

(28) + Док основание, на тот случай, если в Документе изменят комменты :)

+ в Итоге у тебя будет в Регистре не меняемая ссылка. И изменения в документе не повлечет за собой Мего перепроведение всей цепочки доков :)

если у тебя в отчете есть документ, значит и в запросе можешь сделать
ВЫРАЗИТЬ(Документ.Содержание КАК СТРОКА(300))
какой нафиг измерение
ЗАЧЕМ?

В УТ обычно номер строки хранят для связи

вернее КодСтроки

(29) блин, изменения-то я забыл)
(32) да вот ведь, лучше пусть в одном месте будет, а указывать конкретную строку измерением регистра...
(31) остатки без измерений не получить

(34) тебе же остатки только в отчете нужно? вот и "программируй" программист

не, мне хочется посмотреть на этот отчет.
чисто для поржать

(34) в БП Серии есть в регистре? мож всю эту шляпу в серии загнать, расширив строковый реквизит или добавив свой?

(36) я насмотрелся таких отчетов ) капец идиоты

(35) (36) (38) это обычный документ "Отчет комитенту" в БП2, остатки нужны не только чтобы их получать, но и потом уменьшать... это еще один регистратор по регистру
(37) в БП ничего нет как я посмотрю)

(39) ну так сделай справочник "МоиКомменты", его ссылку в ТЧ и в регистр
а не строку

(0) Вариант.

Формализовать жёстко алгоритм формирования текста содержания. Никаких "вручную"! При проведении документов программно генерировать записи регистра сведений "АналитикаУчетаРеализованныхТоваровКомитентов" (Измерения - ключевые поля из которых по алгоритму собирается содержание, ресурс - элемент справочника "КлючиАналитикиУчетаРеализованныхТоваровКомитентов") и элемент справочника "КлючиАналитикиУчетаРеализованныхТоваровКомитентов" (Реквизиты - ключевые поля из которых по алгоритму собирается содержание).
В качестве ключевых полей, по которым формируется Содержание ни в коем случае не должны быть текстовые. Только ссылки (на что угодно - номенклатура, контрагент, комитент, договор, документ реализации, но только не простые типы - не строки, не даты и не числа). Возможно из-за этого понадобиться создавать еще какие-нибудь справочники. У нас, например, есть такие - "Предметы договоров", "Каналы сбыта", "Периоды реализации" (вместо дат реализации).
В регистре накопления "Реализованные товары комитентов" измерение "Содержание" заменить на ссылку "АналитикиУчетаРеализованныхТоваровКомитентов" (тип - СправочникСсылка.КлючиАналитикиУчетаРеализованныхТоваровКомитентов).

Пример данной схемы (включая алгоритмы программного формирования новых записей в РС и новых элементов спрвочника Ключей) можно посмотреть в конфигурации БП 3.0.
РН НДСРаздельныйУчет
РС АналитикаУчетаЗатрат
Справочник КлючиАналитикиУчетаЗатрат

Преимущества схемы: даёт возможность анализировать РН "Реализованные товары комитентов" по любому из ключевых полей (измерений) в РС АналитикаУчетаРеализованныхТоваровКомитентов или в справочнике КлючиАналитикиУчетаРеализованныхТоваровКомитентов.
Уменьшает объем данных за счет того, что новые элементы справочника КлючиАналитикиУчетаРеализованныхТоваровКомитентов не создаются по одинаковым (уже ранее использовавшимся) комбинациям ключевых полей.

Недостатки: Не совсем понятно что делать с текущими остатками. Варианты решения сильно зависят от конкретной схемы ведения учета и того что конкретно у вас там в Содержании (алгоритм генерации текста).

Текущая схема с использованием текста - ересь несусветная. За такое расстреливать надо. ИМХО.

(41) ага, все таки в БП3 это лучше продумано

(42) >> в БП3 это лучше продумано

Не совсем. В БП3 есть некий аналог (технический) предложенной мною схемы. Но этот аналог не имеет никакого отношения к учету товаров комитентов. Этот аналог посвящен раздельному учету НДС А это совершенно другая история.

(43) понятно, это похоже на характеристики в УПП например

(0) А откуда потребовались остатки в разрезе услуг? Может проще услуги шире классифицировать в справочнике с применением папок?

(45) папками классифицировать не возможно, слишком много разрезов получается, не древовидная структура нужна) а просто заводить всё новыми номенклатурами тоже как-то не правильно... на каждую отгрузку по несколько новых номенклатур)

(0) измерение строка(400)...
уралмаш чтоли?
сталкивался с такими писателями уже:
Длина ключа индекса превышает максимально допустимую

(47) до нефтегазовиков конечно еще далеко)