Версия для печати темы (https://pro1c.org.ua/index.php?showtopic=8850)

Нажмите сюда для просмотра этой темы в обычном формате

Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7 _ Программирование в 1С Предприятие 7.7 _ Отбор документов в журнале

Автор: Batchir 06.09.12, 14:01

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

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

Автор: awp 06.09.12, 14:09

Цитата
УстановитьОтбор(<?>,);
Синтаксис:
УстановитьОтбор(<ИмяОтбора>,<ЗначениеОтбора>)
Назначение:
Установить отбор журнала.
Параметры:
<ИмяОтбора> - строка с именем отбора (если пусто - отбор отключается);
<ЗначениеОтбора> - значение отбора.
Замечание:
Во всех журналах, кроме журнала подчиненных документов, работает отбор по виду документа. В этом случае синтаксис вызова метода следующий:
УстановитьОтбор(<ВидДокумента>)
Параметры:
<ВидДокумента> - строковое выражение - вид документа отбора.
Метод доступен только в контексте Модуля формы журнала.


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


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

Автор: Ardi 06.09.12, 14:13

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

Автор: Batchir 06.09.12, 14:36

Цитата(awp @ 06.09.12, 15:09) *
УстановитьОтбор("НазваниеОтбора",Значение)


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

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

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

Автор: mister-x 06.09.12, 14:52

Цитата(Batchir @ 06.09.12, 15:36) *
запрещенная группа будет хранится в константах и вдруг её поменяют на другую

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

Автор: Vofka 06.09.12, 14:58

Цитата(mister-x @ 06.09.12, 15:52) *
заборонити таку дію тому, кому це не потрібно - ПриЗаписиКонстанты в глоб. модулі

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

Автор: Batchir 06.09.12, 15:05

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

Автор: mister-x 06.09.12, 15:16

Цитата(Vofka @ 06.09.12, 15:58) *
Вы перед ответом читали бы все посты, а не только последнюю строчку последнего поста.

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

Автор: Ardi 06.09.12, 15:55

Цитата(Batchir @ 06.09.12, 16:05) *
просто закрашивать строки формексом с запретом просмотра.

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

Автор: MATEVI 06.09.12, 21:09

Вот находил когда то такое решение на проклубе
Корявенько но все же.
http://pro1c.org.ua/redirect.php?http://rusfolder.com/32501378

Автор: mister-x 06.09.12, 21:12

Цитата(MATEVI @ 06.09.12, 22:09) *
Вот находил когда то такое решение на инфостарте

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

Автор: MATEVI 06.09.12, 22:41

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

Автор: awp 07.09.12, 7:21

Цитата(Batchir @ 06.09.12, 15:36) *
Разве этим можно установить"Покажи ка мне все документы у которых группа контрагента не равна запрещенной"?


Да.

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

Автор: Batchir 07.09.12, 7:45

Цитата(MATEVI @ 06.09.12, 22:09) http://pro1c.org.ua/index.php?act=findpost&pid=55866
А если формекс не запустится а конфа запустится?
Делается так - вставляем в журнал колонки с типом "текст". Родные журнальные колонки скрываем.
И в текстовые колонки выводим программно инфу с учетом прав.

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

Автор: MATEVI 07.09.12, 7:57

Цитата(Batchir @ 07.09.12, 8:45) *
Там я так понимаю описан алгоритм на установку отбора РАВНО
А мне нужно установить НЕ РАВНО

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

Автор: Batchir 07.09.12, 11:22

Цитата(MATEVI @ 07.09.12, 8:57) *
А какая разница? НЕ Равно это равно наоборот

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

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

Автор: igmig65 07.09.12, 13:30

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

Автор: Batchir 07.09.12, 14:35

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

Автор: Cthulhu 08.09.12, 11:16

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

Автор: Ardi 08.09.12, 17:52

Цитата(Cthulhu @ 08.09.12, 12:16) http://pro1c.org.ua/index.php?act=findpost&pid=55966
(недостаток - "пустые" строки и тормоза);

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

Автор: Cthulhu 08.09.12, 20:13

Цитата(Ardi @ 08.09.12, 17:52) *
Это под SQL или как?

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


Цитата
есть невидимые штатные колонки журнала

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

Автор: MATEVI 08.09.12, 23:03

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

Автор: Cthulhu 08.09.12, 23:19

Цитата(MATEVI @ 08.09.12, 23:03) *
Подолью масла. Для данного решения можно использовать еще и аналог "ОтборЗаказовКонтрагент".
А видимость оно конечно хорошо. Но я думаю как у людей ручки то чешутся, "позырить", что ж это за пустые документы в журнале. smile.gif

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

Автор: mister-x 08.09.12, 23:24

Цитата(MATEVI @ 09.09.12, 0:03) *
Но я думаю как у людей ручки то чешутся, "позырить", что ж это за пустые документы в журнале.

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

Автор: Cthulhu 09.09.12, 10:19

Цитата(mister-x @ 08.09.12, 23:24) *
так, власне, порожніх стрічок не буде.

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

Автор: mister-x 09.09.12, 14:05

Цитата(Cthulhu @ 09.09.12, 11:19) http://pro1c.org.ua/index.php?act=findpost&pid=55987
а любое программное авто-обновление при большом периоде выбоки будет неизбежно подвешивать работу, борьба с каковым подвешиванием неизбезно сделает код формы громоздким и ресурсоемким в сопровождении.

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

Цитата(MATEVI @ 09.09.12, 0:03) *
Но я думаю как у людей ручки то чешутся, "позырить", что ж это за пустые документы в журнале.

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

Автор: Cthulhu 09.09.12, 22:16

Цитата(mister-x @ 09.09.12, 14:05) *
деяку інфу про ті, "сховані" для них документи

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

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

Автор: sava1 10.09.12, 7:09

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


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

Автор: Batchir 10.09.12, 9:45

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

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

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

Автор: Cthulhu 11.09.12, 14:14

Цитата(sava1 @ 10.09.12, 7:09) http://pro1c.org.ua/index.php?act=findpost&pid=56002
Хорошо написанный запрос не намного тормознее штатных методов (или Вы думаете 1с получает данные каким-то другим образом?)

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

Цитата(Batchir @ 10.09.12, 9:45) *
4. В указанных клиентом отчетах наложены дополнительные фильтры.

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

Автор: mister-x 11.09.12, 15:38

Цитата(Cthulhu @ 11.09.12, 15:14) *
если будет вызываться из формул нескольких колонок каждой строки.

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

Автор: sava1 11.09.12, 15:48

Цитата(Cthulhu @ 11.09.12, 15:14) http://pro1c.org.ua/index.php?act=findpost&pid=56126
Как угодно написанный запрос будет нещадно тормозить обновление формы списка - если будет вызываться из формул нескольких колонок каждой строки.


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

Автор: Batchir 12.09.12, 8:58

Цитата(Cthulhu @ 11.09.12, 15:14) *
Если нет - нужно быть готовым к "а как нам с итогом сверить?".


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

Автор: Cthulhu 14.09.12, 9:42

Цитата(mister-x @ 11.09.12, 15:38) http://pro1c.org.ua/index.php?act=findpost&pid=56135
Чтобы вызвать перерисовку журнала (на кой обновление по расписанию?)

ну-ну..
Цитата
Нечего пользоваться кривым решением 1с для 7 - получаем все данные сразу.

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

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

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

Автор: mister-x 14.09.12, 11:58

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

Автор: vadim007 14.09.12, 12:38

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

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

Автор: XBrut 16.09.12, 0:08

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


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

Автор: Cthulhu 16.09.12, 10:56

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

Автор: byshchenko 19.07.20, 11:14

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

Автор: Batchir 20.07.20, 15:10

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

Украинский 1С форум: всё про 1С 8.3, 1С 8.2, 1С 8.1, 1С 8.0, 1С 7.7
https://pro1c.org.ua