Budget: 600 UAH Deadline: 1 day
Good day . Ready to fulfill your task. Let’s suggest you a little to subordinate your tz – it will significantly reduce its cost and the volume of work with the same result for you. Ready to start today. Please call us and we will discuss details.
17 years of experience.
Certificate of 1C.
Contact in the profile.
PS: We give all our customers a currency rate download module from the internet.
Budget: 15000 UAH Deadline: 14 days
Hello to you.I will take your task for 15,000 UAH within 2 weeks (the result I expect to get earlier, but the deadline I take with the stock).I am a FOP (EN, 3 group, without VAT).I accept payments exclusively on the FOP account.At the same time, the task can be carried out through the Site with the indication that the payment is carried out through the Site.This can be useful in the light of the possibility of leaving one-to-one reviews.I can accept the payment as from Yuri.The face and the physique.the face.If you need a contract, we can sign a contract, and then the payment will be based on the acts of the work performed.If the contract is not required, then the payment on account offers (which can be paid both from the account and from a bank card or at any bank department).I show the result remotely (on the test basis), and after receiving money from you, I update three of your bases and give them to you.I am guaranteed for my work:
If after receiving the result you find any errors in what I did, then I fix them free of charge (this risk is included in the cost and motivates me to do everything quality from the first time).More detail about me and the interaction with me can be read on my website: http://hj.net.ua/synergies.html
Alina Bondarenko
Winning proposal- Projects 21
- Rating -
- Rating 571
Budget: 550 UAH Deadline: 1 day
Good day ! Ready to help with your task. The rate is indicated for an hour, this work will take 2-4 hours. In order to correctly evaluate this work, you need to communicate personally. Write to LS, we will be happy to help. We are also in Dnepr, a personal meeting is possible.
Budget: 1200 UAH Deadline: 2 days
Hello to you. There are ideas about how to fulfill your task. Let’s discuss the details.
Proposals are currently absent
Proposals concealed
-
Serhii Rilsky 14 November 2020Доброе утро. Есть несколько вопросов:
- какая у вас конфигурация (название и версия);
- с какой целью вы хотите заменять названия документов.
-
Yury Petrov
14 November 2020

А названия менять, что бы и просто в списке не понятно было что за документ. Это как дополнение, готовы отказаться от этого -
Serhii Rilsky 14 November 2020Может быть вам стоит перейти на УНФ базовую. Там уже реализован механизм блокировки (правда без редактируемых сообщений).
-
Sergey Nazarenko 14 November 2020Здравствуйте, Юрий.
А не проще ли сделать, чтобы пользователи вообще не видели запрещенных им документов? Зачем весь этот "маскарад"? -
Yury Petrov
14 November 2020
Проще конечно ограничить определённую категорию документов но нужно ведь не это) если убрать доступ чисто к примеру к справочникам номенклатуры то тогда вся она видна не будет. А нам необходимо что бы доступ остался к документам за определенный период
-
Sergey Nazarenko 14 November 2020Подождите. При чем тут номенклатура к документам? Не путайте все в одну кашу.
Можно ограничить доступ к документам (чтоб эти документы пользователь видел, а эти нет). И с номенклатурой можно так же поступить - чтобы эту номенклатуру видел, а эту нет.
В том числе можно и по периоду доступ ограничить. Чтоб старых документов они и не видели.
Делается это элементарно - с помощью механизма РЛС (если я правильно все помню, то в 8.1 он уже был).Кстати, еще один вопрос - а почему на такой древней версии работаете? На 8.3 обновиться не думали?
-
Yury Petrov
14 November 2020
Каким образом будет ограничиваться доступ? По типу документов? И как быть в том случае если доступ к этому типу документов нужен, но не ко всем а к тем которые были созданы в течении последнего месяца. На 8.1 с 2010года необходимости обновляться не было полностью устраивала нас
-
Sergey Nazarenko 14 November 2020"Каким образом будет ограничиваться доступ?"
В 1С есть такое понятие как RLS (Record Level Security). С ее помощью, для каждой роли, которую нужно ограничить (т.е. ограничивать можно не всех пользователей, а только пользователей с определенной ролью)... для каждого объекта (в нашем случае документа), доступ к которому нужно ограничить... прописывается "запрос-ограничение".
В Вашем случае, запрос может накладываться по дате. Что-то вроде "ГДЕ Дата >= ПРИБАВИТЬПЕРИОД(&ТекущаяДата, -31, ДЕНЬ)".
Где ТекущаяДата - это ПараметрСеанса (который тоже нужно будет добавить и устанавливать при запуске приложения).Все. И теперь пользователи с этой ролью просто физически не будут видеть документы старше 31 дня.
А реализовать то, что Вы изначально просите (с маскарадом названий документов) - во-первых трудозатратно (т.к. не очень понятно как это вообще можно реализовать), а во-вторых ненадежно, т.к. пользователь может наугад открывать какие попало документы и таким образом найти нужный ему. -
Yury Petrov
14 November 2020
Хорошо, Сергей. Делайте вашу ставку если интересно будет этим заняться. Обсудим все дополнительно по телефону если нужно будет.
-
Sergey Nazarenko 14 November 2020Я делаю ставку только после того, как у меня на руках будет цена. А для получения цены мне нужно более подробно изучить задачу.
Для этого мне от Вас понадобится:
- Файл Вашей конфигурации. Или даже лучше, если такое возможно, выгрузка базы с похожими на Ваши (но не обязательно настоящими) демо-данными для разработки.
- Более подробное описание того, каким ролям, какие документы и точно по каким критериям ограничивать? Например, "Нужно добавить роль Стажер, у которого должен быть доступ только к документам ЗаказПокупателя (и к связанным с ним справочникам - только просмотр). При этом документы, старше 31 дня ему доступны быть не должны."- Вам результат в каком виде нужен? Файл конфигурации с изменениями подойдет? Или нужно будет обновить все Ваши три базы и сдать "под ключ"?
P.S.
Вот. Нашел статью про РЛС. В ней говорится, что РЛС появилась в 8.1 (так что Вам такое решение очень даже подойдет).
http://e-1c.ru/index.php/node/207 -
Sergey Nazarenko 14 November 2020Еще один уточняющий вопрос.
"доступ к этому типу документов нужен, но не ко всем а к тем которые были созданы в течении последнего месяца"
Имеется в виду ограничение по дате документа? Или если мы сегодня вводим документ трехгодичной давности, то во-первых, нам должны позволить такое сделать, а во-вторых, этот документ должен быть доступен (т.к. создан сегодня, хоть и древней датой)?
-
Sergey Nazarenko 15 November 2020Здравствуйте, Юрий.
Читая обсуждение задачи (в том числе с другими исполнителями), а также постановку задачи, у меня все больше закрадываются сомнения в том, что я правильно уловил суть Вашей проблемы, т.к. формулировку "чтобы пользователи не видели документы" можно понимать по разному.Поэтому задаю ключевой вопрос:
Вам нужно чтобы ограниченные пользователи "не знали" о существовании более ранних документов?
Или просто, чтобы эти документы "не путались у них под ногами"? -
Sergey Nazarenko 15 November 2020чтобы ограниченные пользователи "не знали" о существовании более ранних документов?
Я имел в виду "чтобы пользователи не знали о существовании документов в закрытом периоде"
-
Sergey Nazarenko 15 November 2020По поводу настройки ограничений.
Настройки ограничений должный задаваться конкретному пользователю отдельно свои. В карточке пользователя Конфигуратор – Администрирование – Пользователи = Конкретный пользователь
В указанное окно мы никакие поля добавлять не можем (это чисто платформенное окно).
Если настройки нужно делать для каждого пользователя, то для этого нужно добавлять какие-то поля в структуру данных конфигурации.
Например, в справочник Пользователи.
Или добавить специальный регистр сведений с настройкой периодов отображения документов.
Тут надо еще подумать, как лучше.
Но важно, чтобы Вы понимали, что в указанное окно настройки пользователей, открываемое в конфигураторе, мы никаких настроек добавлять не можем (кроме ролей в список доступных пользователю ролей, но об этом дальше). -
Yury Petrov
15 November 2020
"кроме ролей в список доступных пользователю ролей" значит создание дублирующей роли будет оптимальным решение. Но тогда вопрос где и как мы будем задавать период для этой роли?
-
Sergey Nazarenko 15 November 2020Период для этой роли будем задавать в карточке Пользователя (в режиме Предприятие). Технически, будет это реквизит в справочнике Пользователи или отдельный регистр сведений - не важно. С точки зрения пользователя-администратора - это будет где-то в карточке Пользователя.
Я больше к регистру сведений склоняюсь, но еще подумаю как лучше. -
Yury Petrov
15 November 2020
Не будет ли пользователь иметь доступ к этой настройке, и возможность ее редактировать самостоятельно?
-
Sergey Nazarenko 15 November 2020Естественно, что нет. Доступ к настройке будет только у Администратора (ПолныеПрава).
А у роли ПолныеПраваСОграничением будут права только на программное чтение таблицы настроек периодов (т.е. он их даже посмотреть не сможет - развче что запросом каким-то выковырять, чтобы увидеть). Но изменять настройки у него возможности не будет.
-
Sergey Nazarenko 15 November 2020По поводу настройки периода.
иметь возможность указывать это период от и до
Если так сделать, то нужно будет регулярно (с той частотой, с которой этот период изменяется) для каждого ограничиваемого пользователя вручную указывать этот период.
Вы точно уверенны, что хотите именно этого, а не например "чтобы каждому пользователю можно было указать глубину периода, за который он видит документы" (например, только документы за последние 30 дней)?
-
Yury Petrov
15 November 2020
Я так понимаю вы ознакомились с обновлённой информацией, я не совсем понимаю о чем вы говорите. Мне допустим надо что бы пользователь не видел документы за март 2019 года. Я себя представляю это так: указываю дату начала ограничения 01.03.2019 и дату окончания 31.03.2019 как бы и все, за этот период документы не должны быть видны. Что касательно последних 30-60 дней и тд. Я понимаю что идёт смещение во времени и дату нужно будет редактировать. Каждый день, по событию изменения даты.
-
Sergey Nazarenko 15 November 2020Да. Я ознакомился с дополнением к задаче и приложенными файлами.
Я не совсем правильно понял. Мне показалось, что Вы хотите указывать период дат, в котором пользователю доступны документы. А получается, что у Вас обратная задача - "скрыть какой-то конкретный период".
Кстати, сразу следующий вопрос, уже с новой точки зрения: Такой "скрытый" период может быть только один? Или их может быть несколько (например, март 2019, сентябрь 2019 и "с 13.01.2020 по 21.05.2020")? -
Yury Petrov
15 November 2020
Да периода достаточно одного, если нам необходимо будет ограничить март и август допустим мы будем делать ограничение с марта по август
-
Sergey Nazarenko 15 November 2020Понял.
А что по первым двум вопросам: Ключевой вопрос и По поводу настройки ограничений. -
Sergey Nazarenko 15 November 2020По поводу ролей.
Если речь идет о том, чтобы документы не были доступны никакими способами (ограниченные пользователи "не знали" о существовании документов за пределами позволенного им периода), то...Реализовывать эту задачу разумнее всего через РЛС. Так и надежнее (т.к. "спрятанные" документы будут недоступны пользователю никакими способами, включая запросы и отчеты), и технически проще.
Но РЛС вешается не к пользователю, а на какие-то роли.
Причем, если пользователю будет назначено две роли, одна из которых дает доступ к указанным документам, а другая роль пытается с помощью РЛС этот доступ ограничить, то сработает принцип "если одна из ролей позволяет, тогда пользователю позволено" и РЛС работать НЕ будет.
Следовательно, чтобы РЛС работал, ограниченным пользователям должна быть назначена роль, в которой настроена РЛС, и не должно быть назначено других ролей, дающих доступ к указанным объектам.
В предоставленной Вами тестовой базе - у всех пользователей ПолныеПрава.
Если в Ваших Живых базах тоже у всех пользователей ПолныеПрава, то логично ограничение вешать на эту роль. Хотя, как на мой взгляд, крайне странно и не логично - роль ПолныеПрава, у которой права НЕ полные.
Если ограничивать нужно пользователей, которым не назначена роль ПолныеПрава, а назначена роль Пользователь, тогда логично РЛС вешать на роль Пользователь. Правда, в этом случае, всем таким пользователям нужно будет настраивать доступные периоды. Хотя эту необходимость можно какой-то дополнительной галочкой в свойствах пользователя отключать (это так - раздумья на тему).
Если же это будут совершенно новые пользователи, у которых доступ должен быть ограничен строго указанными документами (и используемыми в них ссылками), тогда логично добавить новую роль (или новые роли), которые назначить этим пользователям вместо роли Пользователь.
Тут нужно обсудить как Вам лучше.
Но в этом случае, мы получим необходимость в будущем поддерживать эту роль в случае дальнейших доработок конфигурации.
Под "поддерживать эту роль" я подразумеваю "каждый раз при внесении в конфигурацию изменений, которые затрагивают роли, анализировать необходимость внесения изменений и в нашу(и) роль(и), и вносить их, если это необходимо".
В-общем, нужно больше информации о том, каким образом Вы раздаете своим пользователям роли, и как Вы видите развитие своей политики раздачи ролей пользователям? -
Yury Petrov
15 November 2020
Значит сделать дублирующую роль, аналогичную «Полные права» но назвать ее «Полные права_ограниченные» и для неё реализовать оговариваем функционал.
-
Sergey Nazarenko 15 November 2020По поводу поставки результата.
Я правильно понимаю, что Вы предоставите три dt-шки Ваших Живых баз? И во время того, как я буду у себя обновлять в них конфигурацию, в Ваших базах никто работать не будет. А когда Вы получите от меня обновленные dt-шки, то самостоятельно развернете их у себя?
Или, может, чтобы сократить время "простоя" баз, лучше пустить меня удаленно на Ваши машины, чтобы я обновил конфигурацию прямо на Живых базах? Естественно, бекап "До" и бекап "После" - в обязательном порядке :)
-
Yury Petrov
15 November 2020
Мы остановим работу полностью, предоставим три dt для правки. Обратно хотим получить этиже исправленные dt. Процес заливки произведем сами.
Current freelance projects in the category Enterprise Resource Planning (ERP)
-
25 USD
30-minute Technical Consultation for Automation Project
16 proposals 4 August
-
Not specified
Need to parse the website.
Online Stores & E-commerce 61 proposals 4 August
-
447 USD
Development of a parametric 3D template (master model) for an entrance metal door in SOLIDWORKS.
3D Modeling 7 proposals 4 August
-
22 USD
Integration of Prom.ua with BAS Small Business
Client Management & CRM 10 proposals 4 August
-
22 USD
A simple and quick program for a car service in Microsoft Excel 2007+ (Windows, Ukrainian) needs to be created.
28 proposals 3 August