Всем привет. Существует такая задача: один сотрудник при подборе не должен видеть часть иерархии справочника Номенклатура. Подскажите, как можно это реализовать?

см. ИспользоватьСписокЭлементов

Если база SQL - можно прямыми запросами отфильтровать.

База файловая..

(1) спасибо, буду пробовать :)

(3) См. (1). Ну, и вопрос: что вы там прячете такого, что этот сотрудник не должен видеть?

Торговая компания. Приходит мерч со стороны поставщика. И для него убираем видимость другой номенклатуры. Плюс он, как выделенная команда, не будет видеть других контрагентов.

(6) Переходите на 8-ку, там это реализовано (если допилить) :)

(7) база нетленка на семерке. А допиливать и на семерке надо.

(8) На семерке, особенно файловой... тебя ждет чудные откровения по поводу (1).
В дальнейшем начинай осваивать прямые запросы для DBF БД :)

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

А как ты собрался еще и запрещать Сторонней организации воспользоваться Сторонним отчетом?

...
В общем как ни крути, но 7-ка это не та платформа, где можно что либо спрятать :)

(9) так какие трудности возникнуть при использовании (1) ? :)
(10) интерфейс с тремя отчетами и все. Сейчас надо придумать, как доп.возможности скрыть.

Доп.возможности не видны из-за интерфейса.

(11) >>> так какие трудности возникнуть при использовании

Слишком большой объём списка Номенклатуры для отображения не есть хорошо.
Время получения этого списка :)

(12) Наивный... Файл- Открыть- Запускай любой отчет, как хочешь :)

+(12) Если ты не скроешь номенклатуру в различных отчетах, то они её все ровно увидят :)

(14) Недостаточно прав для использования Внешнего Отчета.

+(12) Не знаю точно, нету меня среди вас.
Но думается, что стороннюю организацию даже не волнует сама номенклатура, тут скорей всего опасения пользователей, что они чего попортят :)

(14) так что не очень наивный.

(16) Ты не говори Оп, рано или поздно попросят дать :)

(18) Чем важна нетленка, чем вы торгуете?

+ А самое интересное начнётся, когда попросят, тебя, спрятать их номенклатуру из ваших же отчетов :)
+ Я бы на вашем месте организовал бы новую БД (или расмотрел эту возможность) :)

(20) нетленка важна своей схемой.

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

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

Одно юр лицо и несколько баз? Акты сверки как подписываете?

(24) вопрос мне? обычно ручкой

(25)Юмор оценил. Чистый лист подписываете?

(23) Неудобно это. Разграничить можно и в пределах одной базы. А с несколькими базами - надо консолидированные отчёты делать. Если контора большая и может позволить себе содержать штат прогов - то имеет смысл. Если маленькая - то вряд ли.

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

(21) Причем уже  из распечатанных.

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

А если вендор зайдет на склад и увидит складские накладные, прайсы?

(27) удобно поверь. контора очень не маленькая.

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

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

(30)Есть ещё управленческие отчёты что не равно бухгалтерские по клиентам например.

(32) и?

(33)в разрезе номенклатуры.

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

видать контора ТС просто не дошла ещё до КПК и обмена данными с производителями... всё впереди

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

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

(35)Да всё есть просто база одна, интеграция баз геморрой больше чем быстродействие.

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

да что говорить - от типовой ТиС осталось только название и половина процедур из глобальника. остальное всё переписано и поверь в каждой базе для каждой дистрибьюции по-разному

(38) ну ну... ;)

(40) Без обид кучу маленьких SAP не видел.

(38) не озвучишь количество накладных по каждой дистрибьюции в день?

(6) "Приходит мерч со стороны поставщика." и что делает?

+43 Задам вопрос точнее: что мерч делает такого важного, чтобы его в общую базу пускать?

(44) он выполняет свои служебные обязанности. от формирования дебиторок до анализа остатков товара на складах

(39) у нас нет разделения топов по направлениям дистрибуции (у нас - по регионам). ну а в остальном - проблем нет.
Ну а то, что от типовой рожки да ножки - это да....

(45) ну и сделать ему предопределенные отчеты, и все...

(47) тогда прийдётся в товарах, клиентах добавлять флажки "товар ТМ такойто" и "клиент покупатель ТМ такой то" а тут ещё и оплаты как то разделять надо... так что...

(0) Реквизит добавь и фильтруй при открытии подбора. Причем реквизит м.б. не только флажок. А ИспользоватьСписокЭлементов() - тормоза те ещё.

(47)у нас он видит что нужно компании, хотя я всегда задаю им вопрос: "мы выгрузили в вашу учетную систему всё что вы просили, получайте отчёты там!"

(48) рездели мне взаиморасчёты по разным дистрибьюциям по каждому клиенту.

(51)банк по документально разносите?

(52) не всегда. часто клиент загоняет просто сумму по конкретной дистрибьюции

(48) Если и придётся - то не флажки, а один-единственный реквизит. Который, кстати, можно и не добавлять - если использовать прямые запросы. (Впрочем, если не использовать прямые запросы - то тоже можно не добавлять).

(53) нет проблем разделю.

+(54) Вообще непонятен этот спор. Разные конторы, разные бизнес-процессы... Кому-то удобнее одно, кому-то - другое.

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

(54) прийдётся ;) пробовали. клиент Пупкин является покупателем трёх ТМ трёх дистрибьюций (из 5) надо получить список клиентов по одной из трёх листрибьюций. как?

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

(56)Как раз есть одна или много?

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

(58) Дык пробовали. И обходились единой базой.

(60) а ещё всё равно на каждую дистрибьюцию выписывается своя накладная.

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

У нас есть слово "Общий прайс" я его не навижу.

(61) вы пробовали а я работаю с ними с 2007 года

(62)а зачем? у нас ни один из поставщиков таких условий не ставил.

(65) Так и я "пробовал" не один год :-)

(66) серьёзно? я прошу прощения а нельзя озвучить самого крупного вендора? и ещё ответь - вы с ним (с вендором) данными обменивайтесь?

(64) у нас в дополнение к "общему прайсу" есть еще и "полный прайс"

(68) с тремя обмениваемся.

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

(69)Там наверное есть чего у Вас нет.

(70) и как вы выгружаете продажи? и долги? мне просто интересно.

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

(68) ОАО "Балтика"

+(70) наврал - с четырьмя.
с одним - csv через ediconnector
с другим репликация систеховская, и через ftp
третьему отправляем xml на сайт (и xls почтой)
четвертому - отправляем dbf (и еженедельно то-ли xls, то-ли csv) почтой.

(71)Склады у Вас одни логистика одна. (73)Определяеться учетной политикой если нет оплаты по документу.

+(74) Как обмениваемся данными? Через их сервер. С их собственным (вернее, разработанным по их заказу) ПО. Оттуда загружаются накладные от них. Туда с КПК поступают данные о заказах розничных точек. Ну и выгружаются данные из "1С" о фактических реализациях. Плюс ко всему этому куча всего прочего.

(73) пропорционально сумме. Долго считается, конечно - робот сейчас аж в 5 утра стартует :-) Но он железный, ему пофиг

(76) а вот и нет - всё разное. и логистика и логика работы

(78) вооо пропорционально. а команда торговых я так понимаю у вас одна на все дистрибьюции?

(78) нет, команд по разному. в центре - три, в филиалах - от двух до одной.
(79) разная логистика? "каждый сам кузнец своего геморроя"©

(75) понятно.... мелочь короче

у меня ежедневный обмен трёх-звенка с четырьмя вендорами, ещё с двумя двухзвенка и остальные - раз в день

пакетs объёмом от 1 до 20-30 метров в dbf, csv

(81) а как они ухитряются взять одну заявку по клиенту? или при загрузке программа сама "сворачивает" заявки до клиента и формирует одну накладную?

(82) Наличие гемоороя не говорит о крупности :-)

(84) о каком геморое ты говоришь?

(83) единая заявка - если заявка приходит по ЭДО. А если с планшетов - то в зависимости от филиала.

(86) у вас разные производители пользуются одним каналом ЭДО, через который пробегают заявки от разных команд ТП? странно... мы об одном и том же говорим вообще?

(82) умные слова типа "трехзвенка-двухзвенка"

(86) разные покупатели пользуются одним каналом ЭДО. Через корорый "пробегают" заявки от клиента. а клиенту, собственно, плевать на наши "команды", "контракты" и т.п.

(82) Хм... Оно как бы какая разница - есть ли слой бизнес-логики или нет оного? При обмене - ключевое слово "протокол".

(89) и это разны диистрибьюции? или разные направления ОДНОГО производителя?

(90) я так понимаю ты работал только с одной листрибьюцией. крупной но одной. так?

(91) Не так.

(91) чойто у тебя с пониманием какие-то проблемы настали....

(92) а если не так, то тогда ты должен знать что у каждого производителя своя логистика, логика и правила

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

(93) поясни как разные производители могут пользоваться одним каналом ЭДО?

(96) ты слово _покупатель_ от слова _производитель_ отличаешь?
И, кстати, edifact вполне позволяет любому числу производителей получать заказы и отчеты в единой форме и по единому протоколу, по единому каналу. почему каждый (даже западный) производитель лепит свою керню - непонятно.
зы. что примечательно, разработчики этих кривых обменов для производителей - гордо называющие себя "интеграторами" - у 2 систем украина (киевская  и львовская конторы)

(94) И пофигу. Есть протоколы обмена данными. С каждым из производителей. Все необходимые сведения - в свойствах, а не в самих справочниках. И - набор обработок, которые собирают данные и обмениваются ими согласно протоколам. Опять же - всё отдельно. Протокол меняется - меняется обработка. А базе это - по барабану (естественно, если вдруг кому потребуются доп. сведения - то они вносятся; но это "вдруг" случается далеко не каждый день, и даже не каждый год).

(97) отличаю не кипятись. но к покупателю приходят разные торговые так ведь? и каждый из них формирует свою заявку.

а про конторы наши одну назову слёту "Софт сервис" (львов) мы с ними тоже плотно работаем

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

кстати программа которую толкает "софт сервис" польская изначально ;)

(99) Ну различаются. И что в этом за проблема? Для каждого - свой блок обмена. О да! Этих блоков получается аж целых четыре! И в каждом - по целой обработке! (Для "Балтики" - аж целых три обработки - правда, ими же и написанные). Жуть!

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

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

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

сделать хоть десять обдменок не проблема. проблема в том что например для ИДС (минвода) необходимы одни доп.данные по покупателю, а SunInBev - совершенно другие. У SunInBev товары и торговые вносятся на уровне вендора а у ИДС - у дистрибьютора. Я молчу про Марс и Нестле. там вообще отдельная песня больше на стон похожая

(104) нет никакого "роста количества реквизитов" (разве что рост количества свойств). а персоналу вообще должно быть пофиг - персонал обрабатывает _заявку_покупателя_, а не _заявку_на_SunInBev_.

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

(106) и что это меняет?

(105) нет роста?

по требованиям ИДС по каждому клиенту выгружается доп информация (порядка 20 полей) которых нет в типовой. Для SIB - пять-шеть полей. Для "Марс" необходимо деление товара на "корма" и "Шоколад". А "Нестле" требует координаты клиента в GPS

реализуй мне всё это свойствами

(104) Ещё раз - нет никакого "роста количества реквизитов". Всё - в свойствах. Основной справочник не трогаем. В документах - да, тут бывает некое разнообразие. Но оно _единообразно_ регулируется (Видимость, Доступность) на основе всё тех же свойств. (А ещё есть классная штука под названием "подчинённый документ"... Но это - отдельная песнь).

(107) то меняет что не зная изнутри ты так уверенно заявления кидаешь.

(109) как разделить какие свойства для какого вендора предназначены?

(106) Вот именно так и. Заявка с КПК уходит куда-то там. А затем от производителя - приходит. И что? Какая разница, откуда пришли данные? Есть протоколы обмена. В них всё сказано.

(111) Я группы использую. Может, есть лучший вариант - но меня и этот устраивает.

(112) большая разница. и протокол обмена здесь нипричём

(113) небыло ещё такого что какое то свойство просто забыли заполнить?

или проверка заполнения идёт по именам свойств?

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

(112) Как это - "ни при чём"? Батенька, да Вы когда-нибудь _большую_ софтину писали?
Не, оно конечно, если устроить бардак и всё тащить по всем уровням - оно конечно...
Но не зря ж люди изобретали "модульность", "контракты"...

(0) я скрывал, только не в справочнике, а во всех отчетах и документах.
Т.е черту в справочнике "пользователи" заводился свой список номенклатуры и свой список клиентосов..и во всех отчетах ставилмя принудительно фильтр на него..
Всё на классе перехватчике было реализовано.

Внешне, всё как обычно, черти и не догадывались, что смотрят фильтрованные отчеты и документы.

(115) Дык а проверить заполнение - в лом?

(111) по имени, вестимо. У меня, например, "Артикул"+<НаименованиеПроизводителя>, "Группа"<>, "MML"<>, "Рейтинг"<>,"Условия"<>
(115) было. По башке получили, и заполнили. Хотя при выборе контракта - программа требует заполнить табличку...

(118) см 117.

(121) ага. завтра добавляем новое поле и начинается писанина в коде ;)

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

(122) Так а кто тут бубнёж разводит-то? :-)
Каждый решил задачу своим способом. У меня решение - модульное. Мне оно нравится. Легко вносятся изменения.
Тебе хочется трахаться с постоянными переделками кода? Что ж, тоже неплохо - заказчик на крючке.

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

(126) Код при этом менять - зачем?

(127) проверить по имени свойства заполнено оно или нет. это не изменение кода

модульность в чём?

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

у меня вопрос (127),(124) вы фикси?

(128) Модульность в том, что обмен весь вынесен у меня в обработки. Которые зависят только от протоколов. Данные - сгруппированы в свойствах. Которые, опять же, можно менять, не  залезая в код. Проверка заполнения - перебор в цикле. И смотрим флажок.

(129) Я - ИП. Он же ПБОЮЛ.

(130) и у меня во внешних обработках. при чём тут это? я тебе про свойства элементов справочника в конце а ты мне про внешние обработки.

(131) странно. кто из нас ещё клиента к себе привязал - это спорный вопрос

(129) Ну, хреново ты спроектировал базу, раз приходится всё останавливать. Но это - твоя проблема.

(133) серьёзно? ЛОЛ... ты не сталкивался с изменением требований клиента - дистрибьютора или производителя? ты не сталкивался с разбором проблем юзеров? мда...

(132) Ну так это - взаимоувязано. Протоколы, свойства, обработки.

Насчёт "привязал клиента" - у меня всё документировано. Если клиенту захочется - он может легко и просто сменить меня на более другого программиста. Как найдёт получше меня - так и сменит.

(129) у меня фирма работает 24*7 :-)
А если тебе приходится что-то останавливать - ну, значит у тебя проблемы с проектированием систем.

(134) Сталкивался. "Изменение требований клиента" = "изменение протокола обмена". Было уже несколько раз. Переписывается чуток обработка - и ура! Все продолжают работать! (Причём обработка - внешняя, работа пользователей вообще не останавливается).

(129) и юзеров - днем в ЦБ до 85, ночью живых 3-5, ну и роботы, кудаж без них... Остановка базы на пол-часа - согласуется за день. Дольше - ЧП.

(137) вы как в другом мире живёте. производитель требует чтобы в накладной внизу допечатывался комментарий. надо базу остановить? появился покупатель который работает только с накладными определённой формы (метро например). надо базу останавливать? чо вы чешите. трилите?

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

(139)ЗАЧЕМ??????????
зачем для комментария в печатной форме остаавливать базу?

(141) а как ты туда что то добавишь? а если это не комментарий к документу а нечто другое - например текущий долг клиента?

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

(143) мы попрежнему про 7.7 говорим?

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

(144) конечно.

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

(139) Не надо ничего останавливать. Hint: "внешние печатные формы".

(145) все формы накладных во внешних xml? а долг то как расчитать без кодинга?

(148) ну нет спасибо. извращайтесь сами. по каждой дистрибьюции минимум 8 форм накладных

(150) Дружище, да 1Сник ли ты? Если 1Сник - то прекрасно знаешь, что внешняя печатная форма принципиально ничем не отличается от встроенной.

(151) нет конечно. откуда мне знать это. я тебе про фому а ты мне про ерёму. надо в печатную форму вывести ТЕКУЩИЦ ДОЛГ ПО КОНТРАГЕНТУ - получи его не правя код в базе данных

(147)
            ЗагрузитьВнешнююКомпоненту("RWidjets.dll");
            рс=СоздатьОбъект("ODBCRecordset");
                        рс.УстановитьТекстовыйПараметр("ВыбПользователь",глПользователь);
            ТЗ = рс.ВыполнитьИнструкцию("Select  $спрРоли.Роль [Роль $Справочник.Роли] from  $Справочник.РолиСотрудников спрРоли (nolock) where   спрРоли.ParentExt=:ВыбПользователь",ТЗ);
            СЗ=СоздатьОбъект("СписокЗначений");
            ТЗ.Выгрузить(СЗ);
            Объект = СоздатьОбъект("Общие.МенюДополнительныхВозможностей");
            Объект.СоздатьМеню(,СЗ);

(152) и в чем у тебя возникают проблемы? :-)

(154) ты получишь долг без правки кода в базе?

(153) хрень какая то

(155) естественно.

(157) ну давай. покажи как... ;)

только не на ТА а именно на момент печати документа

(158) тебе рассказать про функцию CформироватьПозициюДокумента() ?

(159) в печатной форме?????? расскажи

(160) а какая разница?

(161) ну так напиши что будет стоять в ячейке таблицы?

(160) ты меня пугаешь....

(163)то, что у печформы есть код - ты в курсе? :-)

(164) в курсе. и что?

(165) НУ и напиши в таблице ПечОстаток, а в коде перед выводом секции запрос на момент печати (хоть черый, хоть прямой). И все, собственно...

у меня такое ощущение что спорят тупоконечники и остроконечники

я делал схему не под себя а по требованию и пожеланию клиента. Точка.

(168) и делал ее, похоже, самым идиотским способом из возможных.

+(169) вряд ли у тебя клиент выдвигает требования - где должен быть расчет задолженности.

(169) тебя это успокоит? да я идиот.

Такое ощущение, что Стрелок просто троллит.
Он же не первый год работает. И не дятел вроде бы.
Внешние печатные формы, внешние обработки, внешние компоненты - 1Сник не использует ничего из этого? Не верю! (и даже на Станиславского ссылаться не буду).

(172) кодить и программировать - немножко разные занятия...

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

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

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

(174) Да всё понятно. Пришёл. Клиент поставил задачу. Под эту задачу ты спроектировал базу (базы). Без фанатизма, без особого обдумывания - просто чтобы решить текущую задачу.
Потом задача чуток изменилась. Потом - ещё чуток. А перепроектировать - тебе было в лом. В результате - сидишь теперь на криво спроектированной базе. Да, "текучку" - решаешь. Ибо не дурак. А на рефакторинг - так за него же не заплатят. А времени (теперь уже) убить придётся немало.

(176) это ты за него так решил? печатная форма - частный случай

(177) за 6 лет задачи не просто чуток изменились - они в корне поменялись а работу фирмы останавливать нельзя. Скажу так - от первоначальных баз в момент когда я взял клиента не осталось вообще ничего. обновление (рефакторинг - слово то какое) идёт постоянно. по мере необходимости.

(177) зато "много часов закрывает".
хотя рефакторинг порой делать ой как лениво....

(177) да с чего ты взял что база криво спроектирована?

(178) А не надо останавливать работу фирмы. В том и прикол.

(179) о ещё один провидец... я не по часам работаю ;)

(180) Да ты ж в этой ветке всё подробно расписал!

Согнали всех монстров в одну ветку. Интересно, сколько метров суммарная длина у обсуждающих?

(181) б л я вот ты упёртый. откуда ты знаешь особенности работы моего клиента? откуда ты знаешь как онт работает и его требования?

(183) что я расписал такое что характеризует базу как "кривую"?

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

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

(178) ну дай другой пример...
я ж тебе показал - как делается в пользовательском режиме добавление новых отчетов пользователям в меню.
Точно так же я могу тебе показать, как формируется пакет документов. Формирование бизнес-процессов. Аналог восстановления последовательности в разделенном режиме. проверка и пересчет итогов в разделенном режиме. Обрезка базы в разделенном режиме. Автооткрытие периода. И т.п.
И все это - без остановки работы.
(185) ты хочешь сказать, что клиент требует, чтоб базу останавливали почаще да наподольше?

(184) если встанет - низколетящие дирижабли сбивать можно!

(188) Я на этом фундаментальном знании деньги зарабатываю.
Впрочем, если тебе деньги не нужны - твои проблемы.

(190) А почему "если", а не "когда"?

(192) А чой-то ничего не возбуждает последнее время...
"кнопка СделатьВсё" салореальна, а остальное - мелкомасштабно :-(

(192) Ну это ж открытый форум... А за сбивание летательных аппаратов - уголовная ответственность может быть. Вне зависимости от того, чем сбивали...

(193) Мне вообще программировать запретили - и так все работает. Тоска.

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

(193) "салореальна" - это надо запомнить! :-)

(197) подразумевалось "малореальна"....
хотя "салореально" - это что-то хохлонаркотическое...

(198) Но слово получилось замечательное!

(186) ну как же, всем известно, что любая база, если она не типовая - априори кривая и неоптимальная

(200) не так немного

тут аксиома из трёх тезисов :

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

(201) Уже то, что ты писал насчёт "останавливать" - говорит о том, что база криво спроектирована. Возможностей создать базу, работающую 24*7 - есть много. Но их ты не использовал.

(202) а как же типовые которые априори не могут быть кривыми?

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

(147) Стрелок-ты точно 1Сник? Не видел что такое внешние печатные формы? в свою конфу ниразу не добалял подчистему для выбора и хранения печатных форм7
(149) а что мешает расчет сделать в ВНЕШНЕЙ ПЕЧАТНОЙ ФОРМЕ?

(178) Делали внешние обработки в которых хранились алгоритмы расчетов - как раз для отладки и оперативного внесения изменений-потом конечно старались это в конфу внедрить

(206) Т.е. вызывается внешняя обработка
, в нгей функция которя в параметре возвращает ТЗ с одной строкой и кучей колонок с результатами расчетов

(203) Типовые как раз "кривые" - ибо стараются быть универсальными, а это зачастую неэффективно. Поэтому их и затачивают под нужды конкретного предприятия (если у этого предприятия есть деньги, чтобы под него конфу заточили).
@Садовников как-то показывал свои конфигурации - там от "1С" остались только заголовки. Внутри всё перелопачено - зато работало так, что "1С" остаётся разве что нервно курить за кулисами.

Всем привет. Существует такая задача: один сотрудник не должен видеть часть иерархии справочника Номенклатура. Подскажите, как можно это реализовать?

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

(209) штатный примитв - написать

ИспользоватьРодителя(Группа,0) в форме списка - усё, за пределы данной группы ничего не увидит.. вообще.

А если сделать решение типа РБД, то есть для каждого из "чужих" менеджеров просто выгрузить часть базы с его данными, а остальные - будут жить в центральной.
Просто - фильтровать - не очень гуманно, да и файловую базу "пользователь" может забрать домой на посмотреть.