Имя: Пароль:
1C
1C 7.7
v7: Редактирование документа разными пользователями одновременно
0 Худой
 
29.08.09
09:01
Опишу, для чего это нужно.
Есть документ. В нем различное кол-во записей(до 900 записей)
За определенные записи в этом документе отвечают определенные пользователи.
Проблема в том, что одновременно с документом не могут работать несколько пользователей. Приходится ждать, пока его закроет пользователь после изменения.
Есть ли механизм обхода такой ситуации?
1 Гефест
 
29.08.09
09:04
Разбей его на несколько документов
2 Худой
 
29.08.09
09:09
(1)Не подходит.
3 penta
 
29.08.09
09:12
а какая отраслевая специфика решения с такой потребностью ?
4 Худой
 
29.08.09
09:12
Уточню задачу.
Пользователь что то заказывает. Создает документ с перечнем номенклатуры. Его не должно волновать, кто будет отвечать за носки, кто за столы, а кто за конфеты.
Поэтому он пишет одну большую заявку. Потом, отвечающие за определенные позиции в этой заявке, дорабатывают ее. Каждый свои позиции.
5 penta
 
29.08.09
09:15
я бы рассмотрел варианты:
- вместо табличной части используется регистр сведений
- использовать документы-строки, как бухгалтерские операции
6 Худой
 
29.08.09
09:18
(5)Дело в том, что там очень много другой аналитики в строках табличной части. Поэтому регистр сведений, я думаю, не подходит для такого случая.
По поводу "использовать документы-строки" не совсем понял
7 NcSteel
 
29.08.09
09:21
(6) На основании общего документа создавай пачку документов, которые действуют как "Корректировка Зказа Покупателя"
8 Фокусник
 
29.08.09
09:22
(6) "Поэтому регистр сведений, я думаю, не подходит для такого случая."

Можно вынести только нужные колонки в РС и редактируя их визуально в документе делать движения в РСе
9 Aleksey_3
 
29.08.09
09:22
(6) Каждая строка отдельный документ. Т.е. по сути выписка в БП в 8-ке, или в комплексной 7-ке - Авансовый отчет
Т.е. шапка документа - это обработка, а строки документа - это отдельные документы. В обработке "отбираются" в строки нужные документы и каждый пользователь работает со своей строкой - документом
10 Худой
 
29.08.09
09:36
(9)Опть. "Каждая строка отдельный документ" Это же сколько надо будет документов создавать!
11 Худой
 
29.08.09
09:36
(8)Все же, не совсем понимаю механизма с РС
12 Aleksey_3
 
29.08.09
09:38
(10) В типовой так и сделано, чтобы несколько пользователей могли работать с отдельными строками документами. И ничего, нормально.
13 Худой
 
29.08.09
09:41
(12)Выходит, 900 документов с повторяющейся шапкой, вместо 900 строк в одном документе и одной шапкой
14 Aleksey_3
 
29.08.09
09:50
(13) С шапкой, но без ТЧ
Или РС, если не нравиться документ
15 Худой
 
29.08.09
09:58
(14)И цену, и количество и прочее сразу в РС?
Тяжко.
16 NcSteel
 
29.08.09
10:05
Зачем 900 строк 900 документов. Создавая количество документов по вхождению групп ответственности. ТО есть 900 строк - 5 групп товаров - 5 пользователей ответственных - 5 документов
17 Худой
 
29.08.09
10:10
(16)Так. Это уже, вообще, бардак будет.
Все же меняется. И ответственные и перевод из группы в другую группу.
В общем, так не пойдет.
18 NcSteel
 
29.08.09
10:34
(17) Бардак зависит от того как вы это организуете. Что то с механизмом Корректировок Заказов Покупателей у меня бардака не было, а это почти тоже самое.
19 Худой
 
29.08.09
10:40
(18)Повторюсь. Группы ответственности и вхождения номенклатуры в группы товаров могут изменяться.
20 Фокусник
 
29.08.09
10:52
(19) регистр сведений:
измерение одно УИД (строка, УникальныйИдентификатор).
ресурсы - нужные колонки документа.

в ТЧ документа новый реквизит УИД. Устанавливать при вводе новой строки.

Для движений документа брать данные из РС.

Подумать над тем, что документ может быть заполнен, но в последствии НЕ сохранен, а также если строки документа будут удалены, то в РС это тоже нужно корректно отразить.


ИМХО, вполне рабочий вариант, а главное с минимумом доработок (если конфигурация уже существует)
21 NcSteel
 
29.08.09
10:59
(19) "Глаза боятся , руки делают"
22 Худой
 
29.08.09
11:09
(20)Слабо представляю реализацию.
Корректировать може любой ответственный любую запись. Причина в том, что один может отсутствовать(отпуск, командировка и т.д.) за него может править другой, не отвечающий за данную группу.
23 Megas
 
29.08.09
11:12
(0) Всё не читал! Но
Делай обработку... у передавай то что надо пользователю из документа... обработал свои данные по правам положенные.. нажал записать ! Документ перезаписался !

Попал в цель? =)
24 Худой
 
29.08.09
11:13
(23)Нет. Не попал. Была мысля, поначалу. Но это громоздко и не всегда работают правила "по ответственным". В (22) уже пример описывал
25 Фокусник
 
29.08.09
11:14
(22) еще один РС для прав доступа.
В нем указано кто какие ресурсы может редактировать.

PS документ редактировать одновременно НЕЛЬЗЯ. Так что выкручиваться так или иначе всё равно придется ;)
26 Худой
 
29.08.09
11:16
Кстати, я так обрабатываю документы, внося в заявки цены. Поначалу записывал, не глядя, открыт документ пользователем или нет. В результате, пользователь отваливался без возможности записать внесенные данные. Пришлось переделывать обработку.
27 Коллайдер
 
29.08.09
11:17
Редактировать один документ несколько юзеров одновременно - МОГУТ.
Достаточно трудоемко реализуемый режим. И в 7 и в 8...

зы делал пару раз - геморойно
28 Megas
 
29.08.09
11:20
Ок тогда так!
Опять же
Обработка  =  Все реквизиты как в документе! И все строки кто хочит тот и редактирует но ты меняеш только изменённые даннын!

Ты сохраняеш "старые" Значения и после обработки данных пользователем и до записи
проверка , а не изменились ли эти строки (которые обрабатывал пользователь) уже кем нибудь другим? Если изменились то даёш предупреждоение! Строки изменены уже др пользователем  и тд..
29 Коллайдер
 
29.08.09
11:25
(28) примерно так, но -
- группы товаров жестко разделены, чтобы не было ситуации (28)
- не обработка, а форма нового незаписанного дока - тогда поведение неотличимо...
30 Худой
 
29.08.09
13:04
(29)Нет. У меня группы товаров жестко не распределены. Любой может изменить строку, не принадлежащую к его группе товаров.
31 Megas
 
29.08.09
13:14
(30) Тебе уже написали всё
(28) (29) ...
32 Худой
 
29.08.09
13:25
(31)Ок. "Меняешь только измененные данные".
Как быть, если эти измененные данные у нескольких человек?
33 Wehrmacht
 
29.08.09
13:31
(0) А если просто каждый будет просто создавать свой, скажем "Заказ покупателя". К документам прилепить статусы ("В работе", "Подтвержден"). А потом на основании всего это лепить один, скажем, док. "Счет на оплату"? Помоему изначальная задача бредовая. Как 5 пользователей потом проверят документ из 900 строк?! 5 одноуровневых ответственных за один документ -- это несколько странно.
34 Худой
 
29.08.09
13:35
(33)Ничего странного. Они "проваливаются" в документ из отчетов. Нечего им перебирать в журнале эти документы. Ни к чему.
35 IamAlexy
 
29.08.09
13:40
(0) а разве не для этого в типовых сделаны 2 вида документа "заказ покупателя" и "заказ поставщику" ???

и по одному заказу покупателя можно делать столько заказов поставщику - сколько снабженцев работает над сделкой...

в чем проблема то ?

зачем изобретать велосипед с квадратными колесами когда уже все давно на круглых ездют?

или лавры гения покоя не дают?
36 Фокусник
 
29.08.09
13:42
(34) я за РС, а там как хотите. (править данные в документе - не удачный подход, концов потом не найдете ;))
37 МихаилМ
 
29.08.09
13:48
то (0)
один документ - одно действие.
один создал общий заказ, на основании этого дока сгенерировать - подзаказы по
направлениям , далее возможно опять объединение в общий документ.
При таком подходе четко фиксируются действия и разграничение доступа соответственно ответственность работников, прозрачность и прочее.
Аргументы о росте бд - не интересны  тк по-нормальному должны быть опер.база
аналитическая и архивная (бд отчетов  -по вкусу).
38 Wehrmacht
 
29.08.09
13:50
(34) Бедная 8-ка, каждый норовит надругаться =(
39 Худой
 
29.08.09
13:56
(35) Посмотрел в УТ "Заказ покупателя". То, что ты предлагаешь, как типовую, не катит в постановке. А вот, на этом же документе, обнаружил операцию "Изменить". Кажется, на этим можно поработать. Создается копия документа и там галочками помечаются записи, которые нужно в документ добавить или изменить. Вопросов много. Надо посмотреть этот механизм.
40 PR
 
29.08.09
13:58
Многопользовательская работа в 1С возможна только с записанными данными.
Следовательно предполагается обновление данных на экране у пользователя, через промежуток времени и/или по событиям.
Вопрос решить нужно только один, требуется ли блокировать строку от изменения другими пользователями, если кто-то ее уже редактирует?
41 Худой
 
29.08.09
14:01
(40)В принципе, достаточно блокировать строку от изменения другими пользователем. Если бы я писал на ORACLE, то блокировал бы, именно, строку.
42 Худой
 
29.08.09
14:05
(+39)Вот, только там, при операции "Изменить", документ тоже блокируется. Поэтому в другой сессии не позволяет сделать эту операцию. Но, мне сдается, что блокировку можно убрать.
43 PR
 
29.08.09
14:05
(41) Что значит "В принципе, достаточно блокировать строку от изменения другими пользователем"?
А что можно еще? Либо блокировать либо нет, логично?
44 Худой
 
29.08.09
14:10
(43)Я к тому, что штатно блокируется ВЕСЬ документ, а не строка, которая корректируется.
45 Фокусник
 
29.08.09
14:15
(44) конфа типовая?
46 Худой
 
29.08.09
14:19
(45)конфа типовая. Добавлен документ, с которым нужно работать сразу нескольким пользователям. Создает его один человек, а потом с ним работают ответственные по направлениям
47 PR
 
29.08.09
14:20
(44) Кто говорит про какие-то типовые вещи?
Я бы вообще на регистре сведений делал с эмуляцией формы документа, иначе все сложно получается.
48 PR
 
29.08.09
14:20
+(47) При изменении записей в регистре сведений ессно перезаписывается документ.
49 Худой
 
29.08.09
14:25
(48)А не проще будет сделать, как я уже описал в (39)? Правда, почему то, с созданием копии документа, блокируется, все же, сам документ. Но, возможно, это в обработке блокировка прописана.
Ну и потом, этой копией "накрывать" изменениями исходный документ.
50 PR
 
29.08.09
14:36
(49) И что делать, если и ты и кто-то еще поменяли строку 8?
И при этом кто-то еще удалил строку 6, а кто-то строку 8?
51 Худой
 
29.08.09
14:42
(50)Тут я согласен. Нужна определенная защита от таких ситуаций. Но, все равно, вероятность того, что они постоянно будут ждать, пока кто то освободит документ, будет несравненно меньше.
52 PR
 
29.08.09
14:45
(51) Ты предлагаешь сделать лучше, но не так, как требуется :))
53 Худой
 
29.08.09
14:47
(52)Я пробую решить проблему. Спрашиваю совета.
54 Megas
 
29.08.09
15:15
(50) Пипец... помоему писалось уже...
Пишеш сообщение..

"Пользователь такой то не согласен с вами и уже изменил строку! Набейте ему лицо!"

Что мешает при открытии документа сделать копию его Таблицы ? и при записи сравнить поменялось ли?
55 Худой
 
29.08.09
15:28
(54)А что будет являться критерием сравнения - поменялось ли?
И как ты собираешься отлавливать изменение строки, чтобы написать "Пользователь такой то не согласен с вами и уже изменил строку!"?
56 Megas
 
29.08.09
15:44
(55) Я же сказал при запуске своей обработки или что у тебя там...
1) сохраняеш ТАБЛИЦУ из Документа !
2)в ТЗ которая копия того что ты сохранил из документа редактируеш !
3) в таблице которая сохранена выбираеш строки которые ты поменял и сравниваеш их с исходным документом.. если они отличаются то пипец!
57 Худой
 
29.08.09
16:15
(56)Ну и что делать с этим самым пипец?
Кто то, за это время, поменял местами строки, добавид другие или, вообще, удалил документ.
58 Худой
 
29.08.09
16:53
Тишина
59 Megas
 
29.08.09
16:56
(57) Это тебе виднее  .. что у вас там по регламенту?
Кто разбирается в таких ситуациях?
PS Строки лучше не удалять и не двигать =)
60 Фокусник
 
29.08.09
17:31
(57) документ в топку (раз не типовой), нужен РС + обработка.
Делал разработку как раз для таких целей: в т.ч.редактирование разными пользователями одновременно, с разными правами доступа, откат изменений, просмотр истории и т.д.
61 Злобный Фей
 
29.08.09
18:09
+1 за РС.
62 Худой
 
29.08.09
19:18
В общем, в топку, пока не буду его. В типовой документа с такими функциями нет. Заказ покупателя и Заказ поставщику, мягко говоря, совсем не то. Буду, для начала, с копией документа пробовать. С РС, по моему, слишком много заморочек и контроляю
63 Serg_1960
 
29.08.09
19:57
Автор сам себя загоняет в угол. Нормальный пример подсказали: заказ покупателя на преславутые "900 строк" и каждому ответственному по документу корректировки заказа покупателя. Их ведь не 900 человек :(
64 Худой
 
30.08.09
05:23
(63)Если бы все было так железно связано, я бы не задавал вопроса. Эти пресловутые 900 строк вносит пользователь, который не знает, да и не обязан знать по каким группам разбили для себя снабженцы эту номенклатуру. Ему нужно только, чтобы доставили в определенный срок, для его работы материалы. Эти материалы он заносит в документ на поставку. Когда в отделе снабжения было 4-5 человек и пользователей 30-40 проблем с тем, что документ будет корректироваться одним из 4-5 снабженцев, практически, не было. Все работало, как часики.
Теперь, когда пользователей за 300-400 и в отделе снабжения, который разбирает эти документы, 15-20 человек, вероятность того, что данные будут просматриваться/корректироваться разными сотрудниками отдела снабжения возросла прилично.
Итак, Serg_1960 предлагает вносить данные по каждой группе отдельно. В таком случае, пользователь должен знать что в какой группе находится и ни в коем случае не вносить в документ номенклатуру с разных групп. Ясно, что это повлечет сильное увеличение количества документов. Групп, примерно, 120-150. Хорошо. Это проглотим. Заставим/загнем пользователя заносить для каждой группы отдельный документ.
Идем дальше. Группы, вполне вероятно, могут менять свое содержание. Ну решили снабженцы разбить одну сложную группу на две-три группы и поделить между двумя сотрудниками. Или объединить несколько групп в одну. Так оно реально и бывает.
Как быть с уже введенными документами? А как быть с тем огромным количеством документов, специально разбитым, ради того, чтобы они были по своим группам? Как объяснять начальнику цеха, что "...вот, Иван Иванович, извольте подписать целую кипу документов(предположительно в 120-130раз больше) на месяц, вместо одного? И это на каждое подразделение. Да у него ручка задымится.
Перефразирую выражение в (63) "каждому ответственному по документу" в более веселое, прочитанное где то в инете - "Каждому начальнику по чайнику". Дальше больше. В документе аналитика не только по материалам и их группам, но и по другим разрезам. Это тоже надо будет дробить.
В общем, такой подход, по моему, не катит.
65 Aleksey_3
 
30.08.09
08:43
Ты физически представляешь 300-400 пользователей который будут работать в огромном документе (900 строк), и при этом не будут ошибаться (ой я не ту позицию удалил/откорректировал?). А если пользователь "передумает" заказывать эту позицию, как он определить удалили ли он заказ или нет. И как он вообще определяет, а чей этот заказ. Самая главная ошибка у тебя - нет зоны перехода ответственности, т.е. ошибка есть, а человек, который отвечает за эту ошибку - нет.
66 Худой
 
30.08.09
09:51
Представляю, вполне. Эти 300-400 пользователей находятся в 13 филиалах. То биш в журнале разделены по организациям и работают только со своими документами. Этот уровень без вопросов. Пользователь для себя создает документ "Заявка" и до 900 записей.
67 IamAlexy
 
30.08.09
10:19
(66) и что мешает автоматизировать создание документа "заказ поставщику" из твоей "заявки покупателя"

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

вчем проблема то ?
68 IamAlexy
 
30.08.09
10:21
+(66) ппц.. 66 постов какой то чуши..

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

и пытаться придумать костыли на заведомо ущербную логику, заведомо дурацкое решение - тупость.
69 МихаилМ
 
30.08.09
10:31
то (68)
Пожалуйста будте более коректными.
я видел как три бухлтерши заполняют один бумажный документ - шахматку.
В россии возможно все . и "заведомо дурацкое решение" может быть лучшим.
и не соответствовать при этом каким-либо представлениям, стандартам.
это свиду мы европейцы - а внутри ...
70 Либерал
 
30.08.09
10:34
(68) +100
(0) на 70 постов этой ерунды правильный ответ 7 и 63

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

"корректировка заказа покупателя", подумайте еще раз над этим
или вы всегда, не глядя ,под любую задачу свои колеса разной формы навешиваете на типовые?))
71 IamAlexy
 
30.08.09
10:37
(68) представляете... сидит гоголь на дереве и др.чит...

это я к тому что раз вы "видели" это не значит что так и нужно и что так и правильно...

опять же - шахматка это отчет... :)
72 Фауст
 
30.08.09
11:06
Автор ты типичный мазохист, вместо того чтобы использовать то что отлично работает в типовой и специально предназначено для решения именно этой задачи, ты выдумываешь ерунду всякую, только лишь потому что тебе лень думать, и ты счего то решил что у тебя какой то уникальный случай учета, все уже давно перетерто и решено, открой наконец руководство пользователя, ознакомся.
73 IamAlexy
 
30.08.09
11:19
(72) ты что.. он же открыл документ "заказ покупателя" и сразу понял что это нето... (39)

зато нашел кнопку "изменить"
74 Худой
 
30.08.09
11:52
Так, ребята. Не надо ругаться и брызгать слюной. Ну, не годится это.
Если ветка бесит "тупостью" обходите ее стороной. А так, просто полаяться, можете дома с женами или с любовницами.
Наверное, вы привыкли дело иметь с торговлей.
Тут производственное предприятие.
(70) "еще раз: зачем редактировать первоначальный документ?" Отвечаю -
"Первоначальным" документ становится тогда, когда он будет проведен. То есть с его позициями согласились все стороны. До этого события, в документ могут заглядывать и "поправлять" кто нибудь из отдела снабжения. Фактически, это еще черновик. И черновиком он может быть довольно долгое время. Сотрудники отдела снабжения владеют определенной информацией от поставщиков и прочее...
Итак, после всех этих утрясок пользователь "закрывает" документ проведением. подписывает его и он уже идет в работу. Создаются всякие отчетности(не только для отдела снабжения). Естественно, если после закрытия документа будут изменения, они вносятся ТОЛЬКО корректирующим документом.
Повторюсь. Схема работает, вполне. Я уже это писал.
Дальше уже будет идти общая постановка. И это не вопрос текущей ветки.
Я просто попросил помочь с техническими вопросами по корректировке документа.
Если есть дельные советы, буду признателен.
75 Фокусник
 
30.08.09
12:01
(74)

""Первоначальным" документ становится тогда, когда он будет проведен... До этого события, в документ могут заглядывать и "поправлять" кто нибудь из отдела снабжения. Фактически, это еще черновик. " (74)



"Они "проваливаются" в документ из отчетов. Нечего им перебирать в журнале эти документы" (34)


Т.е. в отчеты он попадает будучи НЕ проведенным?
Понятно. Ваше право использовать инструмент не по назначению. Продолжайте в том же духе ;)
76 Худой
 
30.08.09
12:14
(75)Да. Именно, из отчетов. Внимательно читаешь, молодец. Но надо еще и думать. Отчеты существуют и для того, чтобы оперативно видеть ситуацию еще по не проведенным документам. Чего тут удивительного. Чем, например, реестр документов(журнал), который видят пользователи не отчет? Но там видны и проведенные и не проведенные документы. Думаю, в этом направлении наезжать не стоит.
Повторюсь еще раз. Дело этой ветки не постановка учета, а то, что написано в заголовке.
77 IamAlexy
 
30.08.09
13:06
(74) а вот как раз для этого понятия
"заявка" и "заказ" отделены от понятия "реализация" и "поступление"
78 Худой
 
30.08.09
13:25
(77)Согласен. В той идее или постановке, что реализована фирмой 1С. Но до заказа поставщику(в моем случае - "Передача лотов на торги", ..., "Спецификация к договору на поставку") еще далеко. Не надо думать, что стандартные конфы от 1С правильность в последней инстанции.
79 Фокусник
 
30.08.09
13:43
(76) "Отчеты существуют и для того, чтобы оперативно видеть ситуацию еще по не проведенным документам. ... Чем, например, реестр документов(журнал), который видят пользователи не отчет?"

реестр - это не оперативный отчет ;)
80 Худой
 
30.08.09
13:47
Мда..Уже, выходит, не к чему придираться. Есть желание поупражняться в словоблудии?
Можно по существу?
81 Фокусник
 
30.08.09
13:48
(80) по существу (мое мнение) было про РС, дальше, действительно словоблудие ;)
82 Худой
 
30.08.09
13:59
Насчет РС я, действительно, решил подумать. Это более капитальные изменения, чем редактирование копии документа. По крайней мере, мне так думается. Надеюсь, редактированием через копии обойтись.
83 Киборг
 
30.08.09
14:02
Мне кажется, что всем участникам форума выгодно обсуждать такие темы в направлении типового решения проблемы. То есть чтобы, когда встанет задача многопользовательской обработки других документов (в других) конфигурациях, можно было бы быть уже подготовленным к ней.

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

Может быть имеет смысл рассмотреть вариант редактирования копии документа:
- Вместо открытия формы нужного документа открывается форма нового документа, являющегося копией исходного. Функциональность такого документа совпадает с функциональностью исходного, но в ее алгоритмах обработки надо учесть, что это все-таки новый/другой документ;
- При сохранении такого документа вносятся изменения в исходный документ, а не в текущий. Тут остается вопрос, какое поведение программы ожидает заказчик/пользователь (или какое поведение программы желательно с точки зрения здравого смысла), когда в момент записи обнаруживается, что исходный документ изменился, вплоть до удаления.
84 IamAlexy
 
30.08.09
14:03
(80) по существу тебе сказали.
за основу берутся типовые "заказ покупателя"
добавляются статусы "согласован/несогласован"
и дополнительный документ "согласование поставки"

соответственно манагре заполняет 900 строк заявки.
у заявки статус несогласован.
заявка проводится и регистр накоплений "НеСогласованныеЗаявки"
заявка
номенклатура
количество на согласование

далее
сотрудник отдела снабжения в документе "согласование поставки"
исходя из записанных правил "что он может согласовывать" в регистре сведений - заполняет документ тем что типа правильно
и этот документ делает расход по регистру "НеСогласованныеЗаявки"

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


и блин чего тут огород городить то????
85 Худой
 
30.08.09
14:12
(83) Трезвая мысль.
(84) Ты все пробуешь предложить постановку, которую совершенно не знаешь. Отсюда и заклинания, типа, "чего тут огород городить то????" То, что ты прописал, совершенно не подходит по постановке.
86 IamAlexy
 
30.08.09
14:14
(85) в (0) и (4) не постановка задачи ?
87 Худой
 
30.08.09
14:17
(86) Я попробовал объяснить там "Для чего это нужно". И все. Это не постановка.
В процессе обсуждения, все больше склоняюсь к тому, что вносить изменения через копию документа.
88 IamAlexy
 
30.08.09
14:22
(87) и где (84) противоречит твоим попыткам объяснить задачу в (0) и (4)?

есть универсальное правило - "одно событие/сущность =  один объект в базе"

у  тебя есть
1. заказ покупателя который манагер заполняет - одна сущность по стути.
2. есть обработка этого заказа снабженцем - отдельное событие/сущность
3. согласование всего заказа - отдельное событие.

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

идиотия с "множественным созданием копий из которых потом данные переносятся в оригинал дописывая табличную часть" - ну ппц.. окровенный же бред..
89 IamAlexy
 
30.08.09
14:23
+(88) при этой схеме, у тебя хоть 900 человек пусть обрабатывают заявку из 900 строк...

никто никому не помешает и по каждому сохранится в базе статистика.

причем регулировать "кто что может обрабатывать" можно посредством периодического регистра сведений с одним измерением "номенклатурная группа" и реквизитом "пользователь"
90 Мебиус
 
30.08.09
14:25
Решали похожую задачу.

Два документа в первом вся номенклатура.
Основной пользователь заносит информацию в него затем.

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

Используется промежуточный регистр сведений.    

Отечественные редактируют  свои документы и утверждают их.

Основной пользователь видит статус обработано/нет  в начальной заявке.

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

Основной пользователь проверяет и утверждает заявку.

Финиш.


В чем проблема то?
91 Худой
 
30.08.09
14:28
(88)Я не буду описывать движение документов и последовательность действий, которые происходят в отличии от твоего описания.
Вот еще, по ходу вопрос. Где лучше хранить данные по определенной номенклатуре, которая требует дополнительного уточнения/рассмотрения на предмет ее правильности и прочего?
Сейчас я тупо пробегаю по документам и выдаю отчет. Вроде, нормально работает. Но, хотелось бы пошустрее. Например, через регистр.
(90)Для чего, зачем "Два документа"?
92 Мебиус
 
30.08.09
14:34
(91)
Один документ - начальная заявка
второй документ для ответственных по номенклатуре

еще уточнение -
в общую заявку вносится не номенклатура а текстовое наименование

затем уже ответственные   непосредственно проставляют напротив каждой позиции реальную номенклатуру. Зачем - Для того чтобы не плодить номенклатуру в базе.
93 Мебиус
 
30.08.09
14:38
(92)
+ потому что покупатель на этапе начального формирования не знает как у нас
"правильно" называется номенклатура. И в базе необходимо хранить данные о о том как эта же номенклатура "называется" у покупателя. В конечном же итоге мы должны будем формировать ком. предложение  именно в наименованиях заказчика.

ЗЫ - (0) типичная задача автоматизации тендеров конкурсов по закупкам для гос. контор.
94 Худой
 
30.08.09
14:40
(92)Тоже идея. Видно, что человек, действительно, работал а не давал советы.
В общем, у меня по другому. И пользователь, действительно, не плодит номенклатуру.
Пользователь выбирает существующую номенклатуру. Если ее нет или не нашел, то, как ты написал "в заявку вносится не номенклатура а текстовое наименование", причем, подробное описание. Он же лучше знает свое хозяйство и оборудование, чем снабженец. Мне кажется, так более правильно. Зачем кому то еще проставлять из номенклатуры еще раз, если пользоваетель ее нормально нашел?
95 IamAlexy
 
30.08.09
14:45
(91)

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

гыыы.. а зачем тогда вообще ветку то создал ?

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

так ?
96 Мебиус
 
30.08.09
14:47
(94)
Вопрос разделения ответственности, если основной пользователь сам сможет проставить корректно номенклатуру  то можно сразу проставлять вместо текста правильную номенклатуру.    

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

В нашем случае мы использовали промежуточный РС можно в принципе без него, вопрос вкуса.
97 Худой
 
30.08.09
14:47
(95)v8: Редактирование документа разными пользователями одновременно.
Есть еще что нибудь сказать по существу?
98 IamAlexy
 
30.08.09
14:50
(97) по существу все сказано в (84) и (88)
99 Худой
 
30.08.09
14:52
(96) Я думаю, пользователь вполне нормально может работать со справочником и выбирать из него номенклатуру.
В моем случае все хранится в самом документе - и номенклатура и желаемое название, как хочет пользователь и даже выбранная номенклатура с описанием дополнения. Никаких дополнительных РС для этого не делал.
Мне думается, так проще.
(98)Спасибо.
100 IamAlexy
 
30.08.09
14:54
(99) успехов...

этож надо же.. вся база и водном документе....
101 Худой
 
30.08.09
15:06
(100)Насчет всей базы, это ты поторопился. По одному филиалу(самому крупномы, конечно) за квартал получилось 880 документов. Это, не считая еще корректировок. Всего 13 филиалов. Вот и считай, если есть желание, сколько документов в общем выходит.
102 Худой
 
30.08.09
15:15
(96) А как насчет вопроса в (91)? У вас нет проблемы по дополнительному уточнению/рассмотрению заявленной номенклатуры?
103 Злопчинский
 
30.08.09
15:15
кг/ам
104 Злопчинский
 
30.08.09
15:17
по сути задача сведена к тупому листанию записной книжки и черкания зачеркания - при этом то что зачеркнуто другим ответственным может быть перезачеркнуто. у автора - в консерватории бардак.
105 Худой
 
30.08.09
15:25
(104)До определенного этапа, так оно и есть. Я уже писал об этом.
Суть этой, конкретной задачи,  состоит в том, чтобы как можно быстрее эти записи "записной книжки и черкания зачеркания" превратились в проведенный документ.
106 Злобный Фей
 
30.08.09
15:36
До сих пор не понятно, чем не устраивает вариант РС с ресурсами = колонкам документа + обработка в виде формы документа. В данном случае вообще не обязательно создавать документ до момента его утверждения. Или же создавать с пустой ТЧ для фиксации реквизитов шапки. После утверждения - заполнять ТЧ разово готовыми данными из РС и проводить.
107 Худой
 
30.08.09
15:41
(106)Повторяю. Дело в реализации. Тут предлагают не изобретать велосипеда. Система работает. Хочу меньшими изменениями обойтись
108 Злобный Фей
 
30.08.09
15:46
(107) Ничего сложного в реализации. Плюс весь твой специфический функционал будет сбоку от типового дока. Очень сомневаюсь, что существует вариант проще.
109 Худой
 
30.08.09
15:55
Функционал и так сейчас сбоку от типовой конфы. Система работает. Насчет реализации редактирования думаю.
110 Фауст
 
30.08.09
16:00
Знакомая логика, делать не по правильному, а так чтобы меньшими изменениями обойтись, так и скажи что лень тебе. Но и тут делать копию документа это бред, и удаление гланд через задний проход, ты уш сделай тогда произвольную форму документа, через нее и редактируй.
А по существу тебе товарищь IamAlexy все правильно сказал
111 Худой
 
30.08.09
16:13
Лень. Лень делать "по правильному".
112 IamAlexy
 
30.08.09
16:42
(111) а нафиг советов спрашиваешь? :)
113 Худой
 
30.08.09
16:56
Я совет про редактирование документа несколькими пользователями одновременно.
Был у нас, как то, программер от франчей. Кодировал, мама дорогая. Я не успевал говорить, как он набрасывал код. Весь в сертификатах от 1С упакованный. Наверное, все "правильно" научили делать.
В общем, со временем было тяжело. Надо было внедрять стандартную конфу. По ходу и функционал дорабатывать. Вот он нафигачил регистров и прочего. Показал как все работает. Хорошо, хватило у меня ума потратить на это дело два выходных. Разобрался. Оказывается, можно было обойтись штатными средствами. Определенные настройки справочников и заведение аналитики. Все заработало без изменения конфигурации. Внешние отчеты вполне устроили. Бухи пользуются больше года без проблем.
Если бы он написал свое "правильное", как учат в 1С, на каждый новый чих пришлось бы платить бабло за изменение.
114 Torquader
 
30.08.09
18:50
Редактирование документа несколькими людьми одновременно неправильно логически.
За один документ должен отвечать только один человек.
Если нет - то пишите обработки, которые позволяют редактировать строки документа в виде каких-то сторонних таблиц - пользователи и не заметят, что работают с одним документом.
115 Злопчинский
 
30.08.09
18:54
(113) а фигли вы хотели? говорили: сделайте чтобы - он и делал.. вы ж, скорее всего, не ставили вопрос типа "как решить такую-то задачу"...
116 Злопчинский
 
30.08.09
18:55
ради интереса один раз ходил на собеседование во франч - совершенно аналогичная ситуация - поставили задачу типа как делать будете? сказал а фигли тут делать? потрачу час на обучение как это сделать штатными методами и пойду дальше.. нет, неправильно! надо сделать отдельным документом...
117 Худой
 
30.08.09
19:03
(114)Согласен - "неправильно логически". Если пользователь решает, что документ не должен правиться никем, он его проводит. И все. Если это черновик, он его не проводит.
(115)Да все ему ставили. Он с бухами несколько дней общался по постановке. Кодит быстро. Думает быстро, но не задумывается.
118 Злопчинский
 
30.08.09
19:04
(117) > Он с бухами несколько дней общался по постановке. Кодит быстро. Думает быстро, но не задумывается.
+ 100!
119 Torquader
 
30.08.09
19:23
Иногда проще накодировать кучу нового, чем обучить юзеров работе со старым.
Потом, задача обучения - это не работа программиста.
А вам нужен был всего-лишь консультант.
120 IamAlexy
 
30.08.09
19:32
(111) вот этим быдлокодер от специалиста и отличается...
121 mezoni
 
30.08.09
20:19
В случае, если необходимо редактировать документ при следующих обстоятельствах:
1) Необходимость внесения изменений несколькими пользователями.
2) Документ обрабатывается "роботом", т.е. обработкой в фоновом режиме.
Могу предложить следующий рекомендации для решения поставленной задачи.
1) Форма документа открывается в режиме только для просмотра.
2) Создаются дополнительные формы для внесения возможных изменений в документ.

Также возможно вместо реальных табличных частей в форме документа отображать данные так, как вам необходимо.
Пример:
В документе "Заказ покупателя" имеется табличная часть "Товары" следующего вида.
Номенклатура, Кол-во, Цена, Сумма, Дата запроса, Статус.

В форме документа отображаются от двух до пяти табличных частей, в зависимости от статусов строк.
Товары - все товары
Не подтверждено, К обеспечению, К отгрузке, Отгружено.

Действия на каждой табличной частью обрабатываются своими обработчиками в зависимости от логики работы.

Сохранять изменения можно при каждом изменении или одной кнопкой на все изменения, например "Применить".

Изменения сохраняются просто.
Документ блокируется и сохраняется. Затем документ перечитывается и обновляется отображение (заполняются запросами табличные части).
122 mezoni
 
30.08.09
20:29
P.S.
Не совсем правильно описал про сохранение изменений.
Сохраняется не сам объект открытый в форме.
Запросом выбираете ссылку на документ для изменения.
Получаете из ссылки объект, проверяете возможность внесения изменений (документ мог измениться пока он редактировался), вносите изменения и записываете объект.
123 Serg_1960
 
30.08.09
22:03
(замечание не в тему) То, чем занят автор, в типовых версия практически отсутствует - это обязательная "составляющая" документооборота - процедуры согласования, подписания, утверждения, возврата на доработку и т.д. - то, без чего, собственно, понятие "документооборот" становится выхолощенным, пустым звуком. Оно и понятно :( Если сами документы еще как-то можно загнать в типовые рамки типовой конфы - то их "хождение по мукам" в некоторых конторах индивидуально и за этими "пертрубациями" стоит политика тех или иных "сильных мира сего".
124 МуМу
 
30.08.09
23:46
Много заблуждений в этой ветке. Советую почитать на тему того как подобные вопросы решаются с помощью блокировочных механизмов или версионных. А общее направление конечно же дробить и за счет этого максимально паралллелить обработку изменений. Не партесь насчет того что будет 900 документов вместо 1-го поверьте - если вы померяете правильно разницу в нагрузке, вы найдете ее ничтожной.  А вот разницу в параллельности выполнения на многопроцессорных серверах СУБД ощутите очень скоро.
125 МуМу
 
30.08.09
23:52
Для пониамния автору ответов на свои же вопросы подкину пару идей.
1) Сколько одновременно конкурирующих строк открывают редактирование(в пределах временного интеравла редактирования)?
2)Сколько одновременно блокировок в еденицу времени(например 5 мин. в момент пикового доступа) открывают пользователи?
3)Есть ли узкие места в объектах блокировок, какова частота их использования?(например проверка остатков по одной номенклатуре(тара,упаковка) или проверка бюджета в разрезе субконто)
..
126 МуМу
 
30.08.09
23:55
Есть примеры компании в который подобные процессы "документооборота","согласования" работают на 1200 одновременно работающих пользователей.
127 IamAlexy
 
31.08.09
00:06
система электронного документооброрта как правило немного отличается от системы обработки заказов...
128 Худой
 
31.08.09
06:42
(120)Ты все никак не уймешься? Тебе же сказали - СПАСИБО.
Куда смотрят модераторы?
129 Худой
 
31.08.09
07:03
(121) У меня так и есть. Документы обрабатываются роботом. Вернее, некоторые их атрибуты. Поначалу были конфликты с открытыми для редактирования документами. Решили этот вопрос. Никто даже и не замечает.
(123)Замечание получилось почти в тему, в свете того, что ветку уволокли немного в сторону)))
(124)Все правильно. Тут дело в том, что, при начале внедрения, пользователи, допускают ошибки. Специалист из отдела снабжения из отчета видит, что имеет место ошиба. Проваливается туда и правит. Не цифры, а только то, что касается его. И, так как в этом документе есть записи, компетенция которых касается нескольких человек из отдела снабжения, получается редактирование несколькими пользователями. Дело временное. Я просто хочу, чтобы сейчас, когда есть возможность, сообща исправлять ошибки. Потом этот механизм, практически, не будет подниматься. Пользователь, в принципе, в любой момент, проведением документа может закрыть его от редактирования другими. Поэтому дробление документов на вижу смысла. По какому принципу дробить? Пользователь должен знать группы? Знать в чьей компетенции та или иная запись? А это же все меняется.
Со временем, специалист, практически не будет открывать и корректировать документ. Есть идея просто посылать на почту или каким то другим способом пользователю сообщение о причине "неприятия" к учету документа.
130 Asirius
 
31.08.09
09:43
(0) Можно извернуться так:
1. Добавляем во все ТЧ реквизит GUID для отслеживания движений строк документов.
2. При открытии создаем открываем форму нового документа, записываем туда по метаданным все реквизиты, храним в памяти прочитанную копию.
3. При записи имеем три версии документа: ВерсияБД, ВерсияПриОткрытии, ВерсияПослеРедактирования. На а далее, как при обновлении в 8-ке конфигураций, сравниваем, эти три версии. GUID по строкам позволяет отследить добавление/удаление/перемещение строк. В слючае коллизий, когда один реквизит изменен и в БД и пользователем - выводим вопрос на экран на усмотрение пользователя.
Остается только решить проблемы с реквизитами типа итогов.
131 Киборг
 
31.08.09
12:35
(130) Давай для разнообразия представим поведение пользователя в случае 900 коллизий на:
1-5 вопросе, 6-20, 21-900 :)

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

Если провести аналогии с "реальным" делопроизводством, то документ одновременно корректироваться несколькими людьми не может, а вот набор документов - вполне, значит надо провести необходимое и достаточное разбиение исходного документа на набор и запрограмиировать работу с исходным документом, как с набором.
132 andrewalexk
 
31.08.09
13:00
:)
я запутался...
худого убедили уже что 1 документ не может редактироваться разными пользователями одновременно?
133 Киборг
 
31.08.09
13:38
(132) а вот я не знаю...
Есть какие-то условия форума для обсуждения альтернативных мнений, если автора темы уже убедили? :)
134 wirg
 
31.08.09
13:49
помойму полный бред, но я бы предложил тогда делать заказы и на их основании каждый пользователь создает реализации со своими типами номенклатуры. Хотя очень странная схема, обычно оператор забивает одну накладную сам и ему не нужны другие. Скорее всего у вас нет четкой политики на предприятии, кто и за что отвечает. Или может вы просто не очень знаете конфигурацию, обратитесь в фирму франчайзи и вместе с ними придумайте нормальную схему.
135 Худой
 
31.08.09
16:35
(132)А чего тут убеждать? Действительно, штатно в конфигурациях "1 документ не может редактироваться разными пользователями одновременно". Как правило, такое и не требуется. Просил совета по реализации этого механизма. Тут по ходу узнали много чего хорошего друг о друге.
В общем так. Возможность корректировки не проведенного документа оставляю. Если пользователь, создавший документ, не хочет чтобы его редактировали другие, то он его проводит. Если снабженца или снабженцев не устраивает документ, то формируется к нему причина отказа, со ссылкой на документ.
(134)По поводу бреда, да еще полного, я бы не торопился. И оставьте советы франчей для себя. Не хочется их учить за наши же деньги.
136 Immortal
 
31.08.09
16:44
(113)а откуда сведения как учат в 1с?
по теме: для подготовки документа следует использовать спецрегистр- кэш, либо любые другие объекты, позволяющие блокировать записи. Про работу нескольких пользователей с документом -этот объект не предназначен для этого.