Суть такова.
Формируется Предложение", т.е. чего хотят покупатели, заносит данные один пользователь.
Далее человек 10 прорабатывают позиции ТЧ (где купить, цена и т.д.).
Думал сначала, чтобы ТЧ была регистром сведений (по аналогии с документом "ОперацияБух"), но проскользнула мысль, чтобы всё таки работать с ТЧ самого документа.
Могут ли эти 10 пользователи изменять и записывать изменения одновременно в один документ.
В основном каждый будет работать со своими строками, определять возможность изменения будет происходить по реквизиту ТЧ "Пользователь".

"Могут ли эти 10 пользователи изменять и записывать изменения одновременно в один документ. "
Нет.

сделеай документ "Заказ". Пусть каждый должит свой, а потом на основании списка заказов делай документ

*должит= долбит

(0) Шапка то одна на всех

(1) Если воспользоваться блокировками?
(4) Шапку не трогаем, только ТЧ докумнета.

(5)Еще вариант, сделать обработку с копией документа по полям.
Создается пустой док, каждый выбирает его себе в обработку и заполняет таб часть. Потом пр необходимости нажимает кнопку "Записать" и все добавляется в документ без его открытия

(5) Ими до тебя уже воспользовались. Почитай про оптимистические и пессимистические блокировки.

А открытый один раз первым пользователем док блокируется для всех остальных юзверей

(5) как ты будешь записывать документ без шапки?

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

(9) Ее будет заполнять старший менеджер.

(0) первоначальная мысль была верна. Возвращайся.
(11) и как здесь было сказано, сам док редактирует старший менеджер. Запись строк можно реализовать в момент окончания редактирования строки РС.

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

(11) А ты кто?

ТС сказал что 10 человек будут редактировать ТЧ и каждый записывать свой кусок, на что я ему возразил, что у документа есть еще шапка и при записи ТЧ будет записана и шапка. Тут ты появляешься со своим комментарием. Я рад за старшего менеджера, но мы вроде бы блокировки обсуждаем

(0) Зачем редактировать нескольким? 1Ска блокирует редактируемые объекты. И это, на мой взгляд, правильно.  Предлагаю изменить бизнес-логику: внесли документ "Предложение" - раскидали позиции по менеджерам. Менеджер уже работает с другим документом. Пусть это будет "ПредложениеПоМенеджерам". Здесь должна быть ссылка на исходный документ, номенклатура. В этом документе менеджер "делает свои грязные дела". Потом инфа сводно загружается в первый документ.

(16) По нажатию кнопки "ГОТОВО" доки "Предложения по менеджерам" освобождаются, вроде флажок в доке "свободный", чтобы базу не раздувать зря.

(17) Можно и так.  А можно и не "освобождать". Пусть будет в качестве доп.контроля. В этом доп.документе можно хранить несколько вариантов. К примеру, поставщик первый может привести эту хрень по цене такой-то к такому-то сроку, а поставщик такой-то - вот на таких условиях. Поставил галку на выбранного поставщика - эти данные перейдут в док "Предложение". Первый поставщик "потерялся" - оперативно меняем его на второго путем перестановки "галки".

(12) Первоначальную мысль оставлю.
(16) Пока буду действовать так:
1. Документ "Предложение" будет вводить Контент-менеджер
2. Менеджеры будут редактировать строки в обработке, которая ТЧ будет брать из первоначального документа "Предложение", с доступность строк по пользователю-менеджеру, запись изменений будет стекаться в первоначальный документ "Предложение".

Если это не прокатит, вернусь к первой мысли.

(0) По шапке вопроса вспомнил мультик Простоквашино, где они писали письмо)

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

(20) при внесении данных шапки можно проверять заполненность реквизитов. Элементарно.

(0) "Думал сначала, чтобы ТЧ была регистром сведений"(0)
+1

Как вариант: формируется документ - заполняются только реквизиты шапки; ТЧ заполняется из регистра непосредственно перед проведением/перепроведением документа. Проведение -
только если это реально нужно, например, чтобы "зафиксировать" промежуточный результат; получить отчеты; сформировать документы "по основанию" и т.д.

документ записывается целиком в единой транзакции, изменить такое поведение штатно НЕЛЬЗЯ.

теперь о причинах такого поведения, пример
док - 1, в нем 2 строки
А-2шт
Б-5шт

предположим его открыло для редактирования 2 менеджера (при этом создается копия обьекта в памяти), первый меняет и записывает

А-3шт (он меняет только эту строку)
Б-5шт

теперь второй менеджер меняет вторую строку из обьекта В ПАМЯТИ и записывает

А-2шт (эта строка до ее изменения первым менеджером)
Б-10шт

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

(20) я всегда, когда меня просят разъяснить, почему Вася ввёл документ, Петя его испортил, а Витя доломал - отвечаю: сотрудники создали письмо из Простоквашино.

(15) Это был сарказм, если что

(24) Значит Строки нужно однозначно подписывать на разных менеджеров.

(27) толку то? сущность от этого на слои не разделится. каждый манагер будет тягать к себе ВСЮ ТЧ.

(24) Запись можно и построчно, зачем перезаписывать А, при внесении изменений только Б.

(29) "зачем перезаписывать А" - а у вас никто и не спросит, привет от Платформы 1с.
"Запись можно и построчно" - нельзя.

(24)(27) Они и предполагаются на разных менеджеров, + ко всему у строки будет "уникальный идентификатор строки".

(28) Взял менеджер(отдали менеджеру) строку - подписали строку Этим менеджером, и всё, остальные в эту строку не могут зайти.

Пользователь сделал заказ - пусть этот заказ остаётся как есть. Но, на его основании создаются документы "ПроработкаЗаказа" по количеству менеджеров. И каждый работает со своей частью.
Просто, научить программу работать с одним документом с нескольких рабочих мест - не проблема. Просто, мы будем всё время перезаписывать весь документ полностью, а это время и машинные ресурсы, а также, после записи нужно всем остальным разослать сообщение о том, что документ поменялся и его нужно перечитать. И, если два пользователя одновременно правят одну и ту же строку - что делать ? Можно, конечно, показывать цветом строки, которые уже кто-то правил или даже правит в данный момент, но это всё очень и очень далеко от стандартного функционала обычного документа.

(31) (32) если вы уже вынесли ТЧ в РС, тогда ок.

(24) "Баба Яга - против".

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

Несмотря на мнение, навязанное методистами 1С через ограничение платформы, иногда возникает реальная необходимость решать этот вопрос, реализовать иную методику "одновременной" работы с одним документом нескольких пользователей.

(24) Нельзя в рамках методологии 1С, которая намертво увязала шапку с табличной частью. Это, по большей части, верно, и избавляет одним махом от многих гемморойных проблем. Однако, если представить один док как набор нескольких, то мы имеем возможность редактировать ТЧ одного дока по блокам, разбросанным по нескольким Докам по версии 1С.

(33) 2 пользователя не будут править одну и ту же строку.

(35) От того что "иногда возникает реальная необходимость" строка документа не становится самостоятельной сущностью. В 1С. Может где-то не в нашей галактике. И документ редактируется и сохраняется как единый объект. И все, что описано в (24) нужно принять или уходить из 1С на SQL, Excel...

(37) у юзера Пупкина открыта ТЧ, пусть даже отбором только его строки. но фактически в клиенте 1с на его профиле будет болтаться весь объект документ + его тч целиком.
версия от 11:05.

юзер Дупкин, открывает ТЧ и редактирует свои строки. и жмет записать. в 11:10.

в зависимости от настройки блокировок будет -
а) блокировка при открытии - юзер Дупкин не сможет записать.
б) блокировка при записи:
юзер Дупкин запишет свои изменения своих строк. породилась версия от 11:10.
юзер Пупкин доделал свою работу и нажал запись.
версия от 11:05 с изменениями Пупкина херит версию от 11:10.
Дупкин идет бить табло Пупкину. в 11:20.
после драки Пупкин и Дупкин идут бить табло автору.

(39) Дельно! Что же, ничего другого не остаётся, как Физически делить строчную часть дока в РС...

У строки документа есть идентификатор - это Ид.документа+НомерСтроки - по этой паре строку можно однозначно найти.
Теперь, если мы в какой-то форме открываем одну строку документа, то мы читаем документ из базы (и даже не открываем его) - теперь, при записи, мы блокируем документ, потом читаем документ полностью, сравниваем значения строк с теми, которые были до изменения (их тоже нужно будет хранить) и, если всё совпало, то переносим изменённые значения в документ, записываем его и снимаем блокировку.
И одновременно так могут работать сразу несколько пользователей.

(38) (не в тему)

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

Другими словами, менеджер при подборе позиций в документ, должен был иметь возможность оперативно видеть ситуацию, когда эту-же позицию другой менеджер вносит в свой документ.

Цель задачи: избежать вероятность одновременной выписки одной и той-же позиции товара несколькими менеджерами сверх складского остатка.

Задача была решена (арм; вместо тч документа -
регистры сведений; регистр накопления для резервирования).

"У строки документа есть идентификатор - это Ид.документа+НомерСтроки - по этой паре строку можно однозначно найти. "
Нет. Строки можно менять местами.

(43) Не Ид.документа+НомерСтроки, а Ид.документа+Менеджер.ссылка . Меняйте строки местами сколько хотите.

(42) Всё таки склоняюсь к РС.

(45) давно пора. И административно будет чётче и понятнее.

(43) Типовое решение: "КлючСтроки"/"КлючСвязи". Погугли.

Упс :) Вместо "Погугли" - читать "Погуглите" :)

Совет "Погугли" -не столько (не только) для vicof, а для других, кому интересно.

Делал такое, через обработку. Обработка загружает содержимое документа, пользователь редактирует и по нажатию "Записать" документ редактируется и записывается программно. Придётся реализовать блокировки строк (чтобы не лезли в одну строку) и документа в целом (на случай, если "Записать" нажмут одновременно).

(45) Правильное решение - на основании одного документа - дополнительные по документу на каждого менеджера. Тогда и понятно будет, и не нужно будет в регистре продумывать возможность отслеживания работы с несколькими документами сразу, особенно, если в заказе что-то поменяют.
Опять же - каждый менеджер будет отчитываться за свой документ - будет с кого спросить, если что-то не так.
P.S. и бизнес-процесс рисуется по формированию всего этого достаточно быстро.

(0)Если не хотите плодить документы,то может так:
1 В заявке проставляются во всех строчках прописываются менеджеры и больше её как документ не блокируют.
2. Для менеджеров - обработка забирает в табличную часть только свои строчки и наполняет содержимым.
3. По окончании обработки - запись в документ строчек,обязательно в попытке.И требовать от менеджера добиться записи.

Но это достаточно теоретическая схема. По жизни и количество/состав строк могут менять в документе, менеджеров

(41) "И одновременно так могут работать сразу несколько пользователей."
Не смогут.

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

все-же сабж можно реализовать и в 1с...

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