Не совсем понял, что должен будет делать скрипт? Он поможет избежать ручной передачи от администратора менеджеру? не совсем понятно каким образом. [offtop]Вообще со скриптами у меня проблема, я до мат части еще не добрался, проф. деятельность не связана с программированием, поэтому в вопросе скриптов помочь не смогу автору[/offtop]
Не совсем понял, что должен будет делать скрипт? Он поможет избежать ручной передачи от администратора менеджеру? не совсем понятно каким образом. [offtop]Вообще со скриптами у меня проблема, я до мат части еще не добрался, проф. деятельность не связана с программированием, поэтому в вопросе скриптов помочь не смогу автору[/offtop]Kashimirush
Он поможет избежать ручной передачи от администратора менеджеру?
Именно! Этот скрипт будет автоматически выполняться с некоторой заданной периодичностью (через механизм триггеров) - можно на выбор:
* каждые 1 / 5 / 10 / 15 / 30 минут * или каждые 1 / 2 / 4 / 6 / 8 / 12 часов * или каждый день (в определенный час) * или каждую неделю (в определенный день)
Выбор - за заказчиком.
Предполагается, что такой скрипт делает примерно следующее: [vba]
Код
1. Читает все имеющиеся номера сделок и менеджеров в массив "Общий список сделок" 2. Из "Общего списка сделок" создает "Список менеджеров" (уникальные значения) 3. В цикле по менеджерам из этого списка: a. Зачитывает "центральный" список сделок менеджера (т.е. список сделок из файла "Общий реестр", относящихся к этому менеджеру) - "Список Ц" b. Проверяет "Cписок Ц" на уникальность его элементов - если есть неуникальные, то ? <подумать что делать> c. Открывает "периферийный" файл менеджера (файл типа "Вася") d. Зачитывает "периферийный" список сделок менеджера (т.е. список сделок из файла типа "Вася", относящихся к этому менеджеру, т.е. к "Васе") - "Список М" e. Проверяет "Cписок М" на уникальность его элементов - если есть неуникальные, то ? <подумать что делать> f. Сравнивает элементы "Cписка Ц" и "Списка М" и удаляет все совпадения из обоих списков - в результате в "Списке Ц" остаются (если что-то остается) номера сделок, не встречающиеся в "Списке М" (т.е. новые сделки), и наоборот - в "Списке М" остаются (если что-то остается) номера сделок, не встречающиеся в "Списке Ц" (т.е. номера сделок, либо удаленные из "Общего реестра", либо чужие сделки, ранее назначенные на текущего менеджера ошибочно и затем переданные другому менеджеру). ВАЖНО: совпадения "удаляются" из списков только в оперативной памяти во время работы скрипта, конечно, не из рабочих листов файлов! g. Оставшиеся номера "Списка Ц" (если есть) добавляются в конец таблицы "периферийного" файла менеджера - это новые сделки, еще не переданные менеджеру на обработку. h. Оставшиеся номера "Списка М" (если есть) проверяются по "Общему списку сделок": i. Если номер не найден совсем, то в таблице "периферийного" файла менеджера делается пометка (в специальной колонке, например, слева от номера сделки) "Удален" ii. Если номер найден у другого менеджера, то в таблице "периферийного" файла менеджера делается пометка (в специальной колонке) "Чужой" 4. Всё! Скрипт засыпает до следующего запуска.
[/vba] Скрипт будет жить и запускаться в центральном файле "Общий реестр". Там же будет настроен соответствующий триггер. В менеджерских же периферийных файлах никакие скрипты пока не просматриваются...
При сравнении элементов списков Ц и М номера сделок на листах физически смогут располагаться в любом порядке - хоть в прямом, хоть в обратном, хоть вперемешку, хоть через строчку. А это значит, что никаких ограничений на физическую сортировку центрального и периферийных списков на рабочих листах не будет, что приятно! Менеджер сможет отсортировать свой список как ему удобно, при этом новые, переданные ему, номера сделок будут в первый момент добавлены в конец его списка, после чего он также сможет их расположить как ему удобно.
Он поможет избежать ручной передачи от администратора менеджеру?
Именно! Этот скрипт будет автоматически выполняться с некоторой заданной периодичностью (через механизм триггеров) - можно на выбор:
* каждые 1 / 5 / 10 / 15 / 30 минут * или каждые 1 / 2 / 4 / 6 / 8 / 12 часов * или каждый день (в определенный час) * или каждую неделю (в определенный день)
Выбор - за заказчиком.
Предполагается, что такой скрипт делает примерно следующее: [vba]
Код
1. Читает все имеющиеся номера сделок и менеджеров в массив "Общий список сделок" 2. Из "Общего списка сделок" создает "Список менеджеров" (уникальные значения) 3. В цикле по менеджерам из этого списка: a. Зачитывает "центральный" список сделок менеджера (т.е. список сделок из файла "Общий реестр", относящихся к этому менеджеру) - "Список Ц" b. Проверяет "Cписок Ц" на уникальность его элементов - если есть неуникальные, то ? <подумать что делать> c. Открывает "периферийный" файл менеджера (файл типа "Вася") d. Зачитывает "периферийный" список сделок менеджера (т.е. список сделок из файла типа "Вася", относящихся к этому менеджеру, т.е. к "Васе") - "Список М" e. Проверяет "Cписок М" на уникальность его элементов - если есть неуникальные, то ? <подумать что делать> f. Сравнивает элементы "Cписка Ц" и "Списка М" и удаляет все совпадения из обоих списков - в результате в "Списке Ц" остаются (если что-то остается) номера сделок, не встречающиеся в "Списке М" (т.е. новые сделки), и наоборот - в "Списке М" остаются (если что-то остается) номера сделок, не встречающиеся в "Списке Ц" (т.е. номера сделок, либо удаленные из "Общего реестра", либо чужие сделки, ранее назначенные на текущего менеджера ошибочно и затем переданные другому менеджеру). ВАЖНО: совпадения "удаляются" из списков только в оперативной памяти во время работы скрипта, конечно, не из рабочих листов файлов! g. Оставшиеся номера "Списка Ц" (если есть) добавляются в конец таблицы "периферийного" файла менеджера - это новые сделки, еще не переданные менеджеру на обработку. h. Оставшиеся номера "Списка М" (если есть) проверяются по "Общему списку сделок": i. Если номер не найден совсем, то в таблице "периферийного" файла менеджера делается пометка (в специальной колонке, например, слева от номера сделки) "Удален" ii. Если номер найден у другого менеджера, то в таблице "периферийного" файла менеджера делается пометка (в специальной колонке) "Чужой" 4. Всё! Скрипт засыпает до следующего запуска.
[/vba] Скрипт будет жить и запускаться в центральном файле "Общий реестр". Там же будет настроен соответствующий триггер. В менеджерских же периферийных файлах никакие скрипты пока не просматриваются...
При сравнении элементов списков Ц и М номера сделок на листах физически смогут располагаться в любом порядке - хоть в прямом, хоть в обратном, хоть вперемешку, хоть через строчку. А это значит, что никаких ограничений на физическую сортировку центрального и периферийных списков на рабочих листах не будет, что приятно! Менеджер сможет отсортировать свой список как ему удобно, при этом новые, переданные ему, номера сделок будут в первый момент добавлены в конец его списка, после чего он также сможет их расположить как ему удобно.Gustav
Gustav, В таком случае предполагается, что хозяин "общего реестра", должен будет обслуживать скрипт - при изменении менеджерского состава, удалять/добавлять ID ит.д. ? Или можно сослаться, как-то, на диапазон IDшников, который присутствует в тех. листе для упрощения функций IMPORTRANGE. Чтобы сократить необходимость лезть в скрипт.
Gustav, В таком случае предполагается, что хозяин "общего реестра", должен будет обслуживать скрипт - при изменении менеджерского состава, удалять/добавлять ID ит.д. ? Или можно сослаться, как-то, на диапазон IDшников, который присутствует в тех. листе для упрощения функций IMPORTRANGE. Чтобы сократить необходимость лезть в скрипт.Kashimirush
Работа, работа, перейди на Федота...
Сообщение отредактировал Kashimirush - Пятница, 06.12.2019, 08:12
Начинают завидовать, копировать или записывать клиентов другого менеджера
Провел диверсионный анализ своего решения. При достаточной "продвинутости" менеджера он сможет найти ключ "Общего реестра" и достать данные. Похоже для безопасной передачи данных, без скрипта всё же не обойтись.
Начинают завидовать, копировать или записывать клиентов другого менеджера
Провел диверсионный анализ своего решения. При достаточной "продвинутости" менеджера он сможет найти ключ "Общего реестра" и достать данные. Похоже для безопасной передачи данных, без скрипта всё же не обойтись.Kashimirush
При достаточной "продвинутости" менеджера он сможет найти ключ "Общего реестра" и достать данные.
Можно попробовать схему с промежуточным табличным файлом. Т.е. данные к Васе будут идти не напрямую из общего реестра, а через "промежуточный слой" (файл) - назовем его InterLayer. По слоям и потокам данных (направление задано буковкой "V") выглядеть это может примерно так.
Файл "Общий реестр" - у Васи нет доступа к этому файлу (от слова "совсем") | V | Файл "Вася InterLayer" - ("Вася Промежуточный Слой") - у Васи также совсем нет доступа к этому файлу. Файл содержит лист "Тех.лист" с формулой IMPORTRANGE, вытаскивающей Васины данные из "Общего реестра" (т.е. тот самый "Тех.лист", который в текущей реализации находится в файле "Вася"). | V | Файл "Вася" - файл также содержит лист "Тех.лист" с формулой IMPORTRANGE, но уже более простой, без QUERY или иной фильтрации - всё уже отфильтровано на промежуточном слое и приходят только Васины записи: [vba]
[/vba] Вася является редактором этого файла (иначе как же он будет вводить свои рабочие данные). Вася видит Id этого промежуточного файла и благодаря тому, что владельцем был открыт доступ к тех.листу, Вася может через IMPORTRANGE также прочитать и другие листы этого файла. Беда только в том, что других листов в этом файле нет и читать больше нечего.
Если же Вася каким-то образом узнает id исходного файла "Общий реестр", то это будет для него бесполезная информация - поскольку (см.выше) доступа к этому файлу у него нет. Попытка ввода любого IMPORTRANGE к исходному файлу "Общий реестр" от лица Васи будет обречена на неудачу.
НО (!) если Вася однажды уговорит (споИт, застигнет врасплох и т.п.) владельца файла "Вася" ввести и подтвердить IMPORTRANGE к "Общему реестру" от своего владельческого (админского) имени, то доступ к любой части этого файла получит и редактор Вася - не прямой, так чтобы самому прямо зайти в файл, но через любой введенный затем Васей IMPORTRANGE можно будет просмотреть любой лист файла. Но опять-таки если знать точные имена этих листов. Через скрипт же узнать эти имена не получится - по причине отсутствия общего доступа к файлу (скрипт остановится с ошибкой).
При достаточной "продвинутости" менеджера он сможет найти ключ "Общего реестра" и достать данные.
Можно попробовать схему с промежуточным табличным файлом. Т.е. данные к Васе будут идти не напрямую из общего реестра, а через "промежуточный слой" (файл) - назовем его InterLayer. По слоям и потокам данных (направление задано буковкой "V") выглядеть это может примерно так.
Файл "Общий реестр" - у Васи нет доступа к этому файлу (от слова "совсем") | V | Файл "Вася InterLayer" - ("Вася Промежуточный Слой") - у Васи также совсем нет доступа к этому файлу. Файл содержит лист "Тех.лист" с формулой IMPORTRANGE, вытаскивающей Васины данные из "Общего реестра" (т.е. тот самый "Тех.лист", который в текущей реализации находится в файле "Вася"). | V | Файл "Вася" - файл также содержит лист "Тех.лист" с формулой IMPORTRANGE, но уже более простой, без QUERY или иной фильтрации - всё уже отфильтровано на промежуточном слое и приходят только Васины записи: [vba]
[/vba] Вася является редактором этого файла (иначе как же он будет вводить свои рабочие данные). Вася видит Id этого промежуточного файла и благодаря тому, что владельцем был открыт доступ к тех.листу, Вася может через IMPORTRANGE также прочитать и другие листы этого файла. Беда только в том, что других листов в этом файле нет и читать больше нечего.
Если же Вася каким-то образом узнает id исходного файла "Общий реестр", то это будет для него бесполезная информация - поскольку (см.выше) доступа к этому файлу у него нет. Попытка ввода любого IMPORTRANGE к исходному файлу "Общий реестр" от лица Васи будет обречена на неудачу.
НО (!) если Вася однажды уговорит (споИт, застигнет врасплох и т.п.) владельца файла "Вася" ввести и подтвердить IMPORTRANGE к "Общему реестру" от своего владельческого (админского) имени, то доступ к любой части этого файла получит и редактор Вася - не прямой, так чтобы самому прямо зайти в файл, но через любой введенный затем Васей IMPORTRANGE можно будет просмотреть любой лист файла. Но опять-таки если знать точные имена этих листов. Через скрипт же узнать эти имена не получится - по причине отсутствия общего доступа к файлу (скрипт остановится с ошибкой).Gustav
Можно попробовать схему с промежуточным табличным файлом.
Любопытно, данная схема подразумевает 7 файлов для организации из 3х менеджеров, я правильно понимаю? В таком случае защита обеспечивается, а администратору придется иметь схему организации связи между таблицами , чтобы не спиться. Дождемся, что скажет автор топика, какая защита ему нужна, и как он готов администрировать все это дело, и не отпала ли задача вообще на данный момент)
Можно попробовать схему с промежуточным табличным файлом.
Любопытно, данная схема подразумевает 7 файлов для организации из 3х менеджеров, я правильно понимаю? В таком случае защита обеспечивается, а администратору придется иметь схему организации связи между таблицами , чтобы не спиться. Дождемся, что скажет автор топика, какая защита ему нужна, и как он готов администрировать все это дело, и не отпала ли задача вообще на данный момент) Kashimirush
Вход
Регистрация
Напомнить пароль
Автосумма
Часто используемые
ВПР
ЕСЛИ
СУММЕСЛИ
Финансовые
Логические
Текстовые
Даты и времени 
Ссылки и массивы 
Математические
Другие функции
Проверка свойств и значений
Баз данных
Математические
Обработки массивов
Обработки строк
Преобразования типов данных 
Загрузки данных
Работы с файлами
Обработки системных параметров
Обработки цвета
Работы с датами и временем
Преобразования в системы счисления
Финансовые
