1С Предприятие 7.7. Общий вопрос.

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

Открываем журнал документов - там есть закладки отбора - добавляем доки и реквизиты по которым необходимо прятать
потом при открытии журнала

УстановитьОтбор("НазваниеОтбора",Значение)

В Вашем случаи необходимо выкрутиться по ограничению от противного. Удачи.

1. Нужен общий журнал.
2. Нужно создать графу отбора.
3. При записи документа в поле записывается признак "показывать/не показывать".
4. В журнале запретить менять и отменять отбор.

Разве этим можно установить"Покажи ка мне все документы у которых группа контрагента не равна запрещенной"?

Ardi, мысль понял попробую ...

ДОБАВЛЕНО
... хотя не понятно что делать если скажем запрещенная группа будет хранится в константах и вдруг её поменяют на другую и что делать с уже введенными документами...

заборонити таку дію тому, кому це не потрібно - ПриЗаписиКонстанты в глоб. модулі

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

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

дійсно, звиняйте, запрацювався

А если формекс не запустится а конфа запустится?
Делается так - вставляем в журнал колонки с типом "текст". Родные журнальные колонки скрываем.
И в текстовые колонки выводим программно инфу с учетом прав.

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

а є, можливо, лінк на авторську розробку?

перепутал. проклубе.

Да.

ПокажиКаМнеВсеДокументыУКоторыхГруппаКонтрагентаНеРавнаЗапрещенной();
Синтаксис:
ПокажиКаМнеВсеДокументыУКоторыхГруппаКонтрагентаНеРавнаЗапрещенной()
Назначение:
Установить отбор журнала с ограниченым доступом.
Параметры: 
НЕТ;
Замечание:
Функция имеет только название. Тело необходимо дописать самому и поделится с другими программистами.
Метод доступен только в контексте Модуля формы журнала.

Там я так понимаю описан алгоритм на установку отбора РАВНО
А мне нужно установить НЕ РАВНО


А вот это уже дельное предложение, СПС, пошел пробовать.

А какая разница? НЕ Равно это равно наоборот

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

... в общем-то спасибо, Ardi. Добавил свои колонки и заполнил их текстом в зависимости от условий.

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

Задача решена по методу Ardi. Всех устроило решение. Спасибо.

1) нештатно: 1с++, ТабличноеПоле с соответствующим поставщиком данных
2) штатное, в лоб "запретить просмотр любой информации по документу в любом случае":
2.1) вычисляемые текстовые графы с быстрым вычислением (по функциям формул, возможно с кэшированием в переменных модуля журнала) отображениятогочегонадо/"пустышек" (недостаток - "пустые" строки и тормоза);
2.2) ну в ПриОткрытии в нужных случаях обнулять статус возврата - и так, наверное, понятно.

Это под SQL или как?


Там особо нечему тормозить. Ведь у нас есть невидимые штатные колонки журнала.

да вроде не только.



а они то при чем?..
да нет, вроде не должно особо торомозить. разве что на поиске по первым символам колонки...

Подолью масла. Для данного решения можно использовать еще и аналог "ОтборЗаказовКонтрагент".
А видимость оно конечно хорошо. Но я думаю как у людей ручки то чешутся, "позырить", что ж это за пустые документы в журнале.

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

тоді прийдеться довше побавитись, на формі розмістити таблицю значень і її заповнювати + обробка для відкриття документу при кліці на колонці(ках) - так, власне, порожніх стрічок не буде

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

так, потрібно буде реалізовувати все, що вже реалізовано в платформі

що вірно, то вірно


до речі, якщо в тих користувачів є доступ до повного журналу документів, то вони там побачать деяку інфу про ті, "сховані" для них документи (хоч відкрити їх не зможуть)

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

[добавлено пізніше]
в смысле "сколько угодно из разрешенного", мгм.

1. Почему автообновление - есть еще и Перехватчик (перехватываем событие ПриЗаписи/Проведение)
2. Хорошо написанный запрос не намного тормознее штатных методов (или Вы думаете 1с получает данные каким-то другим образом?)

Да всё уже сделано и забыто, если конечно поговорить(обсудить вообще возможные методы) то можно, а так вполне клиента всё устроило:
1. В общем журнале и журнале кассовых документов, создал копии имеющихся колонок
2. Тексты этих колонок переношу из оригинальных, а если не удовлетворяют условиям, то не заполняю
3. В запрещенных документах при открытии также проверяю возможность просмотра
4. В указанных клиентом отчетах наложены дополнительные фильтры.

На БД клиента я особых тормозов не заметил, списки листаются на глаз одинково.

Я подразумеваю что клиент в системе выплачивает ЗП менеджерам и прочим как контрагентам с помощью документов ПКО и РКО(удержания). Так вот что бы никто кроме тех кому можно не могли смотреть эти документы (ну и доступные отчеты) всё это скорее всего и делалось.

А каким бором предопределенные процедуры (одна - вообще формы документа) - к форме журнала???


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


С выделением сводной цифры по запрещенным в отдельный показатель? Если нет - нужно быть готовым к "а как нам с итогом сверить?".

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

Чтобы вызвать перерисовку журнала (на кой обновление по расписанию?)



Нечего пользоваться кривым решением 1с для 7 - получаем все данные сразу.
Для сведения - получение остатков в Спр.Номенклатура параметризованным запросом быстрее штатного 1с-кого как минимум раз в 5 (доходило и до 30)

Тому кому нужно это делать - у того отображается всё, остальным знать об этом не нужно.

Немного странн, что Вы при ответе на (процитированное Вами) замечание об использовании штатной формы списка документов (журнала) - вдруг начинаете пытаться разъъяснять методики, используемые в обработке, предназначенной для отображения списка документов, статичнол выбираемых по каким-то критериям. Ну да ладно. Имеемая Вами ввиду обработка не лишена недостатков, часто делающих её применение неоправданным. Например:
1) скорость выполнения запроса по периоду отображения журнала зависит от периода и существенно замедляет открытие формы журнала (модификация в виде начального отображения формы с развлекающими пользователя "бантиками" в то время, как выполняется запрос - с отложенным на секунду после открытия (по обработке ожидания) выполнением запроса и (пере)формированием отображаемого списка - не сильно спасает);
2) при изменении интервала журнала - упомянутый Вами запрос тоже нужно выполнять, верно, и это тоже не быстро, и тоже - см.п.1;
3) кэш нужно обновлять, что тоже тормоз, привносящий существенный дискомфорт в ощущения пользователя (помимо вышеупомянутых обстоятельств) - проверено на практике.


ну-ну..

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


Для сведения - сначала неплохо было бы рассказать, что Вы имеете ввиду при использовании термина "параметризированный запрос".
Если это т.н. "прямые хапросы" (с использованием сторонних разработок - 1с++ или 1sqlite - то использование сторонних разработом мной уже упоминалось изначально, с оговорками, поэтому полемический задор в процитированном мне немного странен. помимо ранее упомянутого, пожалуй, стоило бы иметь ввиду тот факт, что использование таких сторонних решений существенно повышает стоимость сопровождения (поелику сужает перечень специалистов до владеющих использованием таких решений на достаточно высоком уровне, а также существенно увеличивает трудоемкость разработки внесения изменений).
А так, во всем остальном - нет, меня не надо убеждать в выигрышности прямых запросов, я их и сам с удовольствием использую.

стандартно (в стандартному журналі документів) ж також виконується запит до бази даних, для отримання необхідної інфо; не виключено, що цей запит більш оптимізований ніж запит на мові запитів 1С але все ж затримка буде, хоч менш відчутна (або майже не відчутна)

Мне нравится ваш стиль.

чуть не поперхнулся.
А как насчёт спрятать журнал с ордерами из меню?
Если надо сверить зарплату - это прекрасно можно сделать в отчете с зажатыми фильтрами.
P.S.
Хотя дискуссия бесспорно представляет научный интерес

с ПЕО и РКО немного труднее - если отбор то по двум значениям (корсчет(иначе, например, и подотчет вылезет) и субконто-рекв.неопр(!)типа). Или добавлять спец.реквизит с флагом отбора, править "ПриХаписи()" в ПКО/РКО для его установки...
а в общем и целом, нефиг манагерам в кассовые журналы вообще ходить. я лично им такое отрубаю везде, и выдаю отчет "Менеджер: Список Кассовых Ордеров" (по фильтру доступных реквизитов с учетом доп.допусков(справочничек такой завел дополнительный, оч.удобно, но то таке, лирика) за указанный период), с выдачей "прочей кассы" отдельной строкой (для остатка в кассе, нужно для сдачи кассы), и - через расшифровку+обработкаячейкитаблицы - с вводом новых КО строго по регламенту, с автоустановкой в них "регламентных" реквизитов. менеджера "на уровне подкорки" в курсе, что отчет "формируется" и не нервничают при "паузах" (ну ещё развлекаю их при этом "бантиками" на форме и строкой состояния).

Batchir, Можете написать в личку примеры этого,хочу себе сделать

byshchenko, Боюсь что это сделать невозможно
8 лет прошло с тех пор))) я то и 7.7 не помню как выглядит