Сообствеенно сабж. Берем документ. Жмем меню действие (меню там где файл) ввести на основании или ALT+F9 и создаем документ на основании, проводим,  возвращаемся и правим наш док основание

Вот нужно запретить делать это из документа, а оставить это в журнале и по ПКМ мышки из журнала

Возможно ли это?

(20) - реализация при записи и проведении контролирует соответствие Заявке с УЧЕТОМ других выписанных документов к Заявке

""Возвращаемся и правим наш док основание...""

а что, в Нашем документе отсутствует Проц ПриОткрытии()?
если подчиненный док записан, проведен, - надо посмотреть в этой проце, есть-ли подчиненные доки этого вида. Если есть - давайдосвидания..

задача-то вроде не сложная..

(17): а ты промоделируй эту ситуацию, и попробуй в коде реализации сделать следующее:
1) Для <РеквДокОснование> - собрать ассортимент с ценами (.ВыгрузитьТабличнуюЧасть() + .Свернуть())
2) Для ВыбДок=СоздатьОбъект("Документ") + ВыбДок.НайтиДокумент() сделать то же самое
3) и потом сравнить ТЗ-шки пп.1 и 2.
о результатах сообщи. ;)

(22) Она не срабатывает, мы же док не закрываем

(23) На момент реализации будет одинаково, так как заявка записана и её содержимое совпадает с тем что в базе

Как-то так:
В ПриОткрытии()
Если ЕстьПодчиненный()=1 Тогда
Форма.ТолькоПросмотр(1);
КонецЕсли;

Ну и например в глобальник функцию, что то вроде (пишу без проверки)
Функция ЕстьПодчиненный(Конт) Экспорт
Док = СоздатьОбъект("Документ");
Если Док.ВыбратьПодчиненныеДокументы(,,Конт)=1 Тогда
   Возврат 1;
Иначе
   Возврат 0;
КонецФункции

(26) Если ЕстьПодчиненный(Контекст)=1 Тогда

Код в (13) не сработал ибо ДокОснование.Блокировка(1) возвращает 0

(25): я то спрашивал не про предположения, есичо... ты проверь...

(26) При открытии у меня и так контролится. Речь идет о случае ввода на основании из формы документа. Т.е. создали документ провели его по кнопке на форме, далее вводим на основании, например горячей клавишей ALT+F9, проводим док основании и возвращаемся к в наш документ. Т.е. НЕ открываем заново, ибо он у нас открыт, а сразу попадаем в наш документ

(29) По твоему разница откуда возьмется?

(24)т.е шарят по ТЧ? тогда есть при начале редактированияСтроки() или там..
есть другая предопределенная ПриНачалеВыбораЗначения(), придется усложнить проверку выборкой подчиненных доков перед выбором или после выбора реквизита..
конечно, решение это системы ЧЖ, но уж если очень нужно - можно и таким способом

(30) Сделай глобальную переменную типа
Перем ВвелиДокОснование;

В процедуре ВводНаОсновании() присваивай ей 1. В процедуре при закрытии обнуляй. Так будешь знать есть ли открытые и незаписанные документы

Разобрался. (13) работает, это я с возвратом накосячил

Если при вызове метода параметр <ВклВыкл> задан, то возвращается результат выполнения метода блокировки. Число: 1 - успешно; 0 - не получилось.

Т.е. как раз 0 и возвращал, т.е. не удалось заблокировать

Всё спасибо, проблема решена, осталось накодить решение

(31): проверить трудно?..

(35) Ну мне просто интересно как ты обоснуешь откуда возьмется разница,

(36): да мне как-то похрен что тебе интересно. я тебе дал направление для проверки факта неизменности документа-основания с момента, кода его подчиненный документ (в т.ч. новый) был открыт. направление в виде доволно нетрудоемкой проверки - а действительно, что оно там, неужели что-то даст?.. ты вместо того, чтобы проверить и (если подойдет) использовать - начинаешь самоутверждаться.
тебе ехать или шашечки?.. требе разжевать все?..
прим: да даже не создатьобъект, а даже ВремДок=<РеквДокОснование>.ТекущийДокумент(). коду проверки строк семь.. но лень, лучше ведь поспорить о том, чего не проверил, верно?.. )))

(37) Да я буду утверждать что эта проверка ничего не даст для данной задачи

(38): уточню: в (17) вопрос про измененную (с момента открытия) ТЧ документа-основания. "для данной задачи" - в смысле для определения факта изменения ТЧ документа-основания после того, как подч.документ был открыт/создан "эта проверка ничего не даст" по-твоему???

(39) Изменена она может быть на законном основании. Цель ни в том чтобы ТЧ реализации совпадала на 100% с ТЧ заявки. А чтобы в ТЧ реализации попало то что в заявки (ассортимент, цены), чтобы с момента создания реализации (даже если ее еще не записали и она висит в памяти) никто не мог исправить заявку. Т.е. заблокировать заявку от изменения ни после того как реализацию проведут, а сразу как только ввели на основании, но еще не записали

И как то немного не оптимально для этого дергать по сети базу, запрашивая ТЧ документа основания

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

(40): Ты как-то запутался в смысловом ряду... давай по пунктам.
1) в подчиненной реализации - элементарная проверка с данными из ТЧ документа-основания (заявки) в ПриЗаписи (это уже вроде говорилось).
2) запрет изменения документа-основания с уже выписанными реализациями - упомянуто мной в (14), а последующие запись и проведение рас-проведенных ренализаций (при подтверждении сохранения изменений заявки) - приведут к проверке п.1.
3) (sic!) ты в (16)+(17), данных мне в ответ на (14), привел ситуацию, для разрешения которой нужно именно (39), именно для этого я тебе дал направление для "попробовать", на каковое ты начал топырить пальцы в смысле "не работает".
теперь понятнее?.. или все равно "оно не работате" мигрирующее в слив типа "а оно мне не надо", ммм?..

Заявки проведенные - ВООБЩЕ запретить изменять. Проведено = недоступно для изменения.

(42) Глобально вопрос стоит как не дать ввести на основании из документа основания

(44) Еще раз прочти сабж внимательно, что значит проведенные? Вот он сидит бъет заявку, периодически проводит, чтобы в резерв упало к нему, дальше жмет ALT+F5 не выходя из документа и ... как советы в (42 помогут?)

(46) > Вот он сидит бъет заявку, периодически проводит, чтобы в резерв упало к нему,
- надо в консерватории поправить. Работа "с голоса" по оформлению заявок - систему надо перетачивать, "периодически проводит" - корявое решение, используется бо штатное.
.
пока заявка ПОЛНОСТЬЮ НЕ "ОФОРМЛЕНА" (как это определить другой вопрос) - ввод доков на основании - запретить на!

а Модифицированность() не сработает?

(43) Не работает
1. Проверка не корректна, ибо могут быть изменения в реализации, а не в заявки. А они допустимы
2. Запрещено, что не мешает сабжу, ибо пока реализация в памяти структура подчиненности пустая
3. В данном моем примере не работает, ибо на момент проведения реализации заявка "в памяти" может и не отличаться от того что записано в БД

(47) Как отследить момент ПОЛНОСТЬЮ "ОФОРМЛЕНА" от Частично "ОФОРМЛЕНА"

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

(50) Заведи СТАТУС документа ("Закрыт/Открыт" например, если совсем просто)
"Полностью" оформлена - юзер ОСОЗНАННО меняет статус документа на "Закрыт" (документ при этом должен быть проведен, причем до "закрытия" может быть перепроведен многократно - это чтобы зафиксировать резерв.
Если статус "Закрыт" - только тогда можно ввести РНК на основании. Все. Никакой запары с проверками состояний.
Откатить с "Закрыт" на "Открыт" может только мегаответственный работник с соответствующим правом.

(49): проверка изменений ТЧ документа-основания (сидящего в реквизите данного документа) после того, как форма данного документа была открыта (открыт существующий.создан новый) "не работает"?.. враньё.
1. Хоть сто порций. Все корректно - если знаешь что с чем сверять (по озвученным тобой параметрам "а потом менеджеры недоумевают" - вполне в силах среднеразвитого ума сообразить и накодить такую проверку).
2. Мешает. Проверка в п.3 даст факт изменения, выполненного с момента открытия.
3. Работает. Открой/создай подчиненный, потом открой и измени ТЧ заявки, потом по кнопке выполни код (блин, да шо ж тебе разжевывать все надо-то. неужто и правда одинэсники как БЖ говорила?):
ВремТЗ=СоздатьОбъект("ТаблицаЗначений"); ДокументОснование.ВыгрузитьТабличнуюЧасть(ВремТЗ);
// "отрезать" флаг "неотрицательный", глюкаво мигрирующий в ТЗ таким методом:
ВремТЗ.УстановитьПараметрыКолонки("Кво","Число"); ВремТЗ.УстановитьПараметрыКолонки("СуммаСНДС","Число");
ВремДок=ДокументОснование.ТекущийДокумент();
ВремДок.ВыбратьСтроки(); Пока ВремДок.ПолучитьСтроку()=1 Цикл
   ВремТЗ.НоваяСтрока(); ВремТЗ.ПолучитьСтрокуПоНомеру(ВремТЗ.КоличествоСтрок());
   ВремТЗ.ТМЦ=ВремДок.ТМЦ; ВремТЗ.Ед=ВремДок.Ед; ВремТЗ.Кво=-ВремДок.Кво; ВремТЗ.СуммаСНДС=-ВремДок.СуммаСНДС;
КонецЦикла; ВремТЗ.Свернуть("ТМЦ,Ед","Кво,СуммаСНДС");
Для тВыб=-ВремТЗ.КоличествоСтрок() По -1 Цикл ВремТЗ.ПолучитьСтрокуПоНомеру(-тВыб); Если (ВремТЗ.Кво=0)
И(ВремТЗ.СуммаСНДС=0) Тогда ВремТЗ.УдалитьСтроку(ВремТЗ.НомерСтроки) КонецЕсли; КонецЦикла;
Если ВремТЗ.КоличествоСтрок()<>0 Тогда
   // тут можно пропарсить таблицу ФАКТИЧЕСКИХ отклонений тов.состава и даже
   // обработать как надо и поорать на операттора, но для проверки хватит и этого:
   ВремТЗ.ВыбратьСтроку();
КонецЕсли;

(52) мдя, вместо 2-х строчек когда проверки на блокировку городить огород с гонянием по сети базы?

(53): а ты не гоняй. в (52) не гоняется более чем ты гоняешь и так и этак.
по сути-то, по разжеванному до самое некуда - есть чо?.. или "оно не работает"?..

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

(54) И много данных гоняется в (13) А по времени думаешь твой код быстрее и оптимальнее?

Еще раз этот код где выполняется в реализации при записи? Ну так изменения могут быть санкционированные, или на момент проведения реализации изменений вообще может не быть

В заявки? На момент внесения изменений в ТЧ заявки реализации в базе может и не быть. Она висит "в памяти" у оператора.
При записи ... ну можно и при записи и поискать структуру подчинености, только к этому времени НЕТ ЭТАЛОННА, т.е. не счем сравнивать

(55): не намного меньше. оптимальнее потому что гибче (вплоть до "частичного" запрета на изменение - но єто да, думать надо, а ты, похоже, не привык...)
Ну так санкционированность и корректность - проверяй хоть до всирачки, никто не мешает.
Нет, не "в заявки". в реализации. которая "висит в памяти у оператора". и в которой можно(!) проверить (и отработать как надо!) изменения, внесенные в заявку после(!) открытия реализации "в памяти у оператора".
не тупи.

(56) Тогда можем получить такую фигню

Менеджер делает заявку проставляет все статусы проводит, но не закрывает её

Операционист проводит реализацию. Все твои проверки покажут что изменений нет, и всё хорошо

Менеджер находясь в заявки (она же у нее открыта) исправляет её (например исправляет контрагента)

В результате имеем минуса резервов в реализации (ведь заявку исправили на другого контрагента)

Т.е. проверка нужна при записи заявки. Нужно найти реализацию по структуре подчиненности и проверить ключевые реквизиты шапки и ТЧ

Вариант 2.

Менеджер делает заявку проставляет все статусы проводит, но не закрывает её

Операционист вводит на основании реализацию. Но тоже не проводит ее

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

После этого девочка проводит реализацию

В результате минусов не будет, просто в резерве будет висеть товар, плюс товар уедет не тому клиенту

А виновата программа потому что дала


Т.е. здесь уже нужна проверка при записи реализации

(59) делов то... проверяй, а не заблокирована ли заявка-основание...

Таким образом вместо того чтобы вставить 3 строчки кода в процедуру ввод нового в документе реализация ты предлагаешь

А. при записи заявки искать подчиненые и сравнивать реквизиты
Б. при записи реализации сравнивать реквизиты док основания и реализации


Да считай меня ленивым но мне лень писать простыню кода в 2-х документах там где можно обойтись тремя строчками в одном (!) документе

(60) См (34). Проблема давно решена, просто Cthulhu хочет что-то доказать.

я б ваще не так делал.
1. обертка-обработка для "длительного" приема заявок с "горячим" резервированием.
2. для каждой подобранной номенклатуры - отдельный однострочный документ заявка (на склад или какая надо) - с "прозрачной" записью и "прозрачным" проведением + блокировка каждого такого документа.
3. по факту окончания "приема заявки" (финиш обработки п.1) - консолидация п.2 в один документ "заявка покупателя".

(63) Ну это если разово. А у меня деревья ввода на основании ... могут быть минимум на 3-4 листа

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

------->Заявка - финальная стадия, тут только то что он зарезервировал, на этой стадии согласовываются цены и т.п.
-------->Реализация - то что уехало клиенту
---------> Заявка на поставку. То что хотел клиент в сделки, но у нас небыло (заявка), типа клиент готов подождать до следующей отгрузки

Далее на основании Заявка на поставку вводится сделка и по кругу

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

(63) при чем здесь разово? это типа для ГОРЯЧЕГО РЕЗЕРВИРОВАНИЯ. и ввод на основании возможен только после того как сформирована и автоматически проведена консолидированная итоговая заявка.

(64) Сделка - понятно. в ТиС это штатная схема работы по заявкам (заявка покупателя с видом резервирования "резервирование из текущего остатка" ИЛИ!! заявка на поставку с автораспределением поступившего товара под эту заявку.)
.
то есть две сехемы - заявка на поставку с частичными отгрузками по факту поступления товра. или заявка которая бъется чисто на заявку на склад и отгрузка в ноль, и вторая - чистая заявка на поставвку.
.
вторая схема больее прозрачна для менеджеров.
.
тому кто писал ТИС - яйца оторвать за неудобства.. ;-)

У нас вообще статус есть - "прием заявки завершен". Т.е в сборку может быть передана по бизнес-процессу только "завершенная приемом" заявка (правда, таких мало - "на ручном приеме" сидят только трое или четверо, работающих с дальними регионами по телефону - остальные заявки с КПК или EDI). Да и работу выстроили, уровень первичного дефицита ниже  полпроцента.

(67) Ну от типовой там ничего не осталось. А реализована вторая схема

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

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

(57): ты слепой?.. в (43) п.2 хреново видно?.. уж0сна...

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

(69) угу, она прозрачнее.
Хотя у меня вполне себе работала и первая схема четко - и еревься подчинености на 20-30 литстов - в порядке вещйе были. а отслеживалось на спецмониторе
http://infostart.ru/upload/iblock/df2/monitor00.jpg
.
манагеры генерили заявки на поставку (больше манагеры вообщем по заявке и не работали). что есть - резервиловась сразу и в отбор. чего нет - закуп заказывал, по факту прихода - оператор сидит зырит в спецмонитор - и выписывает отгрузки по факту появленяи в заявке неотгруженного товара.

(72) Писатель?

"2) запрет изменения документа-основания с уже выписанными реализациями - упомянуто мной в (14), а последующие запись и проведение рас-проведенных ренализаций (при подтверждении сохранения изменений заявки) - приведут к проверке п.1. "

Как я запрещу изменения у открытого дока, если девочка ввела реализацию????

(59): ты слепой?.. в (43) п.3 хреново видно? уж0сна.

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

(75): "Операционист проводит реализацию.  ... Менеджер находясь в заявки (она же у нее открыта) исправляет её (например исправляет контрагента)" - и в ПриЗаписи проверка на наличие (и т.п). и что не так???

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

(77) Я не могу стоять у каждого менеджера за списной. А каждый менеджер думает что он просто в обязан "обмануть" систему, а потом стоять с невинными глазками и говорить. "Ну программа же дала"

Люди на полном серъезе говорили, а покажите что я это внесла изменения и скажите ЗАЧЕМ я это сделала"

(57) > Менеджер делает заявку проставляет все статусы проводит, но не закрывает её
после проведения становится доступна только кнопка "закрыть", документ - только для просмотра.
.
после этого девочка проводит реализацию и все зашибись.
.
манагер в првоеденной заявке может изменить что либо только путем выписки корректировочной заявки на основании - а она будет пустая, так как товар отгружен.
.
и тут, если надо что-то исправить ПОСЛЕ РЕАЛИЗАЦИИ - вступает в действие СПЕЦРЕГЛАМЕНТ.

(80) мне доказывали, что "это делала не я, потому, что мне это не надо. а ваш монитор и ваш лог все врет"

(79) И чё? Если ты прочтешь что я тебе выше писал ты поймешь, что глупость пишешь, ибо это и реализовано будет. Для чего твой пост? Чтобы потолочь воду в ступе?

(80) для оперативной торговли - следует обрубить все действия которые могут привести к вводу и исправлению документов в НЕОПЕРАТИВНОМ режиме. и все, на 99% проблемы такие как ты озвучил - закрыты. 1% остается на то что действительно надо изменить по НЕЗАВИСЯЩИМ ОТ МЕНЕДЖЕРА причинам.

+(82) Это, кстати, говорила та девочка, которая ввела в комплексной третий пол (кроме мужского и женского)- "по соглашению сторон".

(84) + при  такой схеме работы даже штатная ТИСа работает себе очень даже заипись

(81) Эх, для тех кто нечетает, но имеет очень важное мнение повторяю

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

(85) в струе толерантности! ;-)

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

(82) Ну таких посылаем лесом, благо шефам в этом случае достаточно лога.

(87) ну и трахайся со своим заказчиком если он тебе определяет КАК делать. я таких сразу посылаю нах. ибо пусть он мне говорит ЧТО ЕМУ НАДО (горячее резервирование при приеме по телефону например), а я уже делаю так, чтобы это ложилось в штатную типовую схему наиболее близко и не пораждало дополнительных проблем.

(89) Ну в данном случае я фикси, и мне шефы ставят задачу и как они говорят "мне пофиг как это будет технически реализовано, но надо что было вот так"

(91) Фикси

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

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

(95) О каких извращений идет речь, вполне нормальная желание.

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

и буду спокойно смотреть как ве заткнется - они же вот так зхотели ;-)
.
поэтому, устраиваясь на работу я ВСЕГДА оговораиваю: мне говорят ЧТО НАДО, но не говорят КАК ЭТО ДЕЛАТЬ. Если кто-то говорит "как это делать" - пусть возьмет и сам сделает, ибо я сомневаюсь что они знают функционал конфиги лучше меня.
.
вообщем, проблем не было.
вообщем, что делал - оказывалось удобнее и проще и прозрачнее, чем предлагали...
.
типичная хотелка бухов: сделайте мне поле я сюда сумму вобью. спрашиваб. ПОЛЕ - сделаю. Сумму - введете. ДАЛЬШЕ ЧТО? ну оно.. там сложит.. КТО СЛОЖИТ? ОТКУДА ОНО ЗНАЕТ ЧТО НАДО "СЛОЖИТЬ".. ну тол есть оттягиваюсь на полную катушку...

(97) угу, поддерживаю.

(97) Так проблема решается проверкой на блокировку

А так ну пусть будет не заявка и реализация, а реализация и счет-фактура/ПКО

поэтому, обычно с ГБ я ругаюсь всегда ;-)
пару раз работалось с ГБ продуктивно весьма. исключительно и именно тогда, когда они говорили что надо, я делал и показывал как что и почему....
но это редко такие ГБ/бухи. квалификация повсемест но падает.

(100) "все не читал, но херня какая-то" .. ;-)

(100) да какая нафик разница? У всех доументов есть прорядок движения. т.е. техпроцесс. вот от него и надо плясать.
(101) поработав ГБ некоторое время, хорошо нахожу с ГБ общий язык....

(103) Есть тех процес, но в данном случае проще предотвратить ошибку, чем исправлять ее

Когда у вас 2 человека вы по горбу дали и он понял. Когда у вас 60 и постоянно новенькие ...Рука устанет по горбу бить

Начинается, а я это не слышал, а лично мне не говорили, но ведь программа дала, значит так можно

(105) надо сделать так чтобы у них не было поползновений и возможнсоти сделать криво. вот и все.

(107) В дырочку, вот об этом и (0)

Т.е. есть проблема решил спросить как ее закрыть, закрыл ее  еще в (13) посте. Дальше пошел флуд на тему кто умнее

(105) у меня в центральной базе (оперативной) 75 (до 80). пллюс филиалы.
а техпроцесс (когда из каждого состояния документа можно только двигаться вперед) - просто не дает возможности сделать что-то не так.
А когда "не так" сделать нельзя - это и есть соблюдение техпроцесса.

(110) Ну я тоже думал что у меня так, но вот нашли менеджеры способ обхода

(111)Это ты им оставил дырку. в которую они и пролезли.
т.е. неправильно спроектированный техпроцесс, который был неверно реализован.

(112) Всё невозможно сразу предусмотреть. Ибо думаешь что работать будут люди, а не деле ...

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

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

(114) Я не спорю есть и сотрудники, а есть и вредители

(115) у меня тоже "бывшая типовая" :-)

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

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

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