какие два кабинета автоматически получает каждый пользователь в core после регистрации

Какие два кабинета автоматически получает каждый пользователь в core после регистрации

Кратко: чтобы зайти в личный кабинет ученика, вам необходимо зарегистрироваться в CORE.

Автоматически вы попадете в личный кабинет учителя. Для того, чтобы попасть в кабинет ученика в правом верхнем углу экрана нажмите на значок с вашим именем. В выпавшем списке выберите «Режим «Учусь»».

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

После авторизации мы попадаем в личный кабинет. Каждый пользователь CORE имеет два кабинета:

Как понять, в каком кабинете вы находитесь? Посмотрите на окошко в правом верхнем углу. Под вашим именем будет написан статус – «Обучаю» или «Учусь». Если вы в личном кабинете учителя, кликните на окошко и в выпавшем списке выберите «Режим «Учусь»».

Хотите изменить имя или фамилию, указанные при регистрации?

Кликните на вкладку «Личный кабинет», а затем в центре экрана выберите
вкладку «Профиль и безопасность».

Хотите подключить номер телефона к аккаунту CORE?
Нажмите на вкладку «Личный кабинет», а затем выберите вкладку «Профиль и безопасность».

Рядом с пунктом «номер телефона» нажмите «изменить», введите номер мобильного телефона. Далее — нажмите «сохранить».Если номер необходимо изменить, повторите действия, указав корректный номер телефона.

Итак, мы находимся в личном кабинете ученика. Не стоит бояться что-то случайно удалить: перед удалением система обязательно запросит у вас подтверждение.

На панели сверху мы видим две основные вкладки:

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

Если вы не закончили урок, то увидите кнопку «Продолжить прохождение».

Кликните на неё, чтобы продолжить проходить урок. Кнопка «Продолжить прохождение» будет отображаться до тех пор, пока вы не нажмете внутри урока на кнопку «Завершить урок».

Если урок завершен, то на карточке будут отображены две кнопки:

Источник

Какие два кабинета автоматически получает каждый пользователь в core после регистрации

После того как урок был опубликован, им можно поделиться двумя способами:

1. Через ссылку: скопируйте ссылку для учеников и отправьте ее им.
Внимание! При отправке ссылки на конструктор из адресной строки браузера урок отображаться не будет.

2. Через код: слева от ссылки на урок-версию для учеников есть код урока. Это уникальный код урока, который легче передать ученикам, в отличие от URL-ссылки. Скопируйте код урока и отправьте его ученикам.

После того как ученик откроет урок, ему будет доступен режим, в котором можно только проходить материал, то есть изучать и решать задания. О том, как войти в урок ученикам — читайте в инструкции «Вход в CORE и личный кабинет ученика».

Обратите внимание: после того как урок опубликован, доступа к правке урока не будет.

Вы можете поделиться уроком с другими учителями: то есть дать им доступ к редактируемой версии урока. Учитель добавит урок к себе в личный кабинет и сможет работать в нем. Обратите внимание: вы не будете видеть изменения, который внесет другой учитель. О том, как добавить к себе чужой урок, читайте в инструкции «Как поделиться уроком и добавить его к себе».

Внимание! При отправке ссылки на конструктор из адресной строки браузера урок отображаться не будет.

Вы можете вносить изменение в урок уже после его публикации. Необходимость в переопубликации урока возникает только при активации режима «Рандомизация» и изменении элементов теста («тест», «заполни пробелы», «вопрос с автопроверкой», «классификация», «открытый вопрос», «диалоговой режим»), а именно:

Однако если изменения вносятся в сам вопрос в любом из заданий, или в описание к нему, то переопубликация не нужна.

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

Источник

Какие два кабинета автоматически получает каждый пользователь в core после регистрации

Коротко: перейдите по ссылке, которую прислал учитель. Если учитель прислал код, то зайдите на сайт urok.io и введите код в специальное окно.

Дальше введите свои данные в окне авторизации (они должны быть полными и верными, иначе учитель не сможет опознать вас) и вуаля, урок открыт!

Если учитель прислал ссылку на урок (например, такую: https://coreapp.ai/app/player/lesson/5e778344bd6ed9bbdb651a2e/2), скопируйте и вставьте ее в адресную строку браузера.

В случае, если учитель прислал код урока (например, такой: OEUV), введите в адресную строку браузера адрес «urok.io». Откроется страница с полем для ввода текста, в которое нужно ввести код урока, который вы получили и нажать на кнопку «Перейти в урок».

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

Если регистрация на платформе CORE уже есть, то выберете «Войти со своим аккаунтом», укажите свой e-mail и пароль. Дальше нажмите на кнопку «Войти».

Если до этого на платформе не регистрировались, но решили это сделать, выберете «Создать аккаунт и войти».

Здесь нужно будет указать свой e-mail, придумать пароль, ввести свою фамилию и имя. Ознакомьтесь с пользовательским соглашением и кликнете на кнопку «Зарегистрироваться и войти». Для того чтобы подтвердить почту, нужно будет зайти в свой почтовый ящик. Там будет ждать письмо с инструкциями.

Если аккаунта на платформе CORE нет, но он и не нужен — не беда, выберете «Войти без регистрации». Здесь понадобится ввести свое имя и фамилию (обязательно записываем правильно!). Дальше нажимаем на кнопку «Начать урок».

Однако мы рекомендуем проходить регистрацию. Ведь если есть аккаунт, то все уроки, которые будет посылать учитель, сохранятся в личном кабинете. А если нет аккаунта, то и личного кабинета тоже нет!

Источник

Авторизация в ASP.NET Core MVC

В статье описаны паттерны и приемы авторизации в ASP.NET Core MVC. Подчеркну, что рассматривается только авторизация (проверка прав пользователя) а не аутентификация, поэтому в статье не будет использования ASP.NET Identity, протоколов аутентификации и т.п. Будет много примеров серверного кода, небольшой экскурс вглубь исходников Core MVC, и тестовый проект (ссылка в конце статьи). Приглашаю интересующихся под кат.

Claims

Принципы авторизации и аутентификации в ASP.NET Core MVC не изменились по сравнению с предыдущей версией фреймворка, отличаясь лишь в деталях. Одним из относительно новых понятий является claim-based авторизация, с нее мы и начнем наше путешествие. Что же такое claim? Это пара строк «ключ-значение», в качестве ключа может выступать «FirstName», «EmailAddress» и т.п. Таким образом, claim можно трактовать как свойство пользователя, как строку с данными, или даже как некоторое утверждение вида «у пользователя есть что-то«. Знакомая многим разработчикам одномерная role-based модель органично содержится в многомерной claim-based модели: роль (утверждение вида «у пользователя есть роль X«) представляет собой один из claim и содержится в списке преопределенных System.Security.Claims.ClaimTypes. Не возбраняется создавать и свои claim.

Следующее важное понятие — identity. Это единое утверждение, содержащее набор claim. Так, identity можно трактовать как цельный документ (паспорт, водительские права и др.), в этом случае claim — строка в паспорте (дата рождения, фамилия. ). В Core MVC используется класс System.Security.Claims.ClaimsIdentity.

Еще на уровень выше находится понятие principal, обозначающее самого пользователя. Как в реальной жизни у человека может быть на руках несколько документов одновременно, так и в Core MVC — principal может содержать несколько ассоциированных с пользователем identity. Всем известное свойство HttpContext.User в Core MVC имеет тип System.Security.Claims.ClaimsPrincipal. Естественно, через principal можно получить все claim каждого identity. Набор из более чем одного identity может использоваться для разграничения доступа к различным разделам сайта/сервиса.

На диаграмме указаны лишь некоторые свойства и методы классов из пространства имен System.Security.Claims.

Зачем это все нужно? При claim-based авторизации, мы явно указываем, что пользователю необходимо иметь нужный claim (свойство пользователя) для доступа к ресурсу. В простейшем случае, проверяется сам факт наличия определенного claim, хотя возможны и куда более сложные комбинации (задаваемые при помощи policy, requirements, permissions — мы подробно рассмотрим эти понятия ниже). Пример из реальной жизни: для управления легковым авто, у человека должны быть водительские права (identity) с открытой категорией B (claim).

Подготовительные работы

Здесь и далее на протяжении статьи, мы будем настраивать доступ для различных страниц веб-сайта. Для запуска представленного кода, достаточно создать в Visual Studio 2015 новое приложение типа «ASP.NET Core Web Application», задать шаблон Web Application и тип аутентификации «No Authentication».

При использовании аутентификации «Individual User Accounts» был бы сгенерирован код для хранения и загрузки пользователей в БД посредством ASP.NET Identity, EF Core и localdb. Что является совершенно избыточным в рамках данной статьи, даже несмотря на наличие легковесного EntityFrameworkCore.InMemory решения для тестирования. Более того, нам в принципе не потребуется библиотека аутентификации ASP.NET Identity. Получение principal для авторизации можно самостоятельно эмулировать in-memory, а сериализация principal в cookie возможна стандартными средствами Core MVC. Это всё, что нужно для нашего тестирования.

Для эмуляции хранилища пользователей достаточно открыть Startup.cs и зарегистрировать сервисы-заглушки во встроенном DI-контейнере:

Кстати, мы всего лишь проделали ту же работу, что проделал бы вызов AddEntityFrameworkStores :

Начнем с авторизации пользователя на сайте: на GET /Home/Login нарисуем форму-заглушку, добавим кнопку для отправки пустой формы на сервер. На POST /Home/Login вручную создадим principal, identity и claim (в реальном приложении эти данные были бы получены из БД). Вызов HttpContext.Authentication.SignInAsync сериализует principal и поместит его в зашифрованный cookie, который в свою очередь будет прикреплен к ответу веб-сервера и сохранен на стороне клиента:

Включим cookie-аутентификацию в методе Startup.Configure(app):

Этот код с небольшими модификациями будет основой для всех последующих примеров.

Атрибут Authorize и политики доступа

Атрибут [Authorize] никуда не делся из MVC. По-прежнему, при маркировке controller/action этим атрибутом — доступ внутрь получит только авторизованный пользователь. Вещи становятся интереснее, если дополнительно указать название политики (policy) — некоторого требования к claim пользователя:

Политики создаются в уже известном нам методе Startup.ConfigureServices :

Такая политика устанавливает, что попасть на страницу About сможет только авторизованный пользователь с claim-ом «age», при этом значение claim не учитывается. В следующем разделе, мы перейдем к примерам посложнее (наконец-то!), а сейчас разберемся, как это работает внутри?

[Authorize] — атрибут маркерный, сам по себе логики не содержащий. Нужен он лишь для того, чтобы указать MVC, к каким controller/action следует подключить AuthorizeFilter — один из встроенных фильтров Core MVC. Концепция фильтров та же, что и в предыдущих версиях фреймворка: фильтры выполняются последовательно, и позволяют выполнить код до и после обращения к controller/action. Важное отличие от middleware: фильтры имеют доступ к специфичному для MVC контексту (и выполняются, естественно, после всех middleware). Впрочем, грань между filter и middleware весьма расплывчата, так как вызов middleware возможно встроить в цепочку фильтров при помощи атрибута [MiddlewareFilter].

Вернемся к авторизации и AuthorizeFilter. Самое интересное происходит в его методе OnAuthorizationAsync:

Надеюсь, приведенные ссылки на исходный код дали вам представление об внутреннем устройстве фильтров в Core MVC.

Настройки политик доступа

Requirement — не более чем DTO для передачи параметров в соответствующий handler, который в свою очередь имеет доступ к HttpContext.User и волен налагать любые проверки на principal и содержащиеся в нем identity/claim. Более того, handler может получать внешние зависимости через встроенный в Core MVC DI-контейнер:

Регистрируем сам handler в Startup.ConfigureServices(), и он готов к использованию:

Resource-based авторизация

Как уже говорилось ранее, policy-based авторизация выполняется Core MVC в filter pipeline, т.е. ДО вызова защищаемого action. Успех авторизации при этом зависит только от пользователя — либо он обладает нужными claim, либо нет. А что, если необходимо учесть также защищаемый ресурс и его свойства, получить какие данные из внешних источников? Пример из жизни: защищаем action вида GET /Orders/ , считывающий по id строку с заказом из БД. Пусть наличие у пользователя прав на конкретный заказ мы сможем определить только после получения этого заказа из БД. Это автоматически делает непригодными рассмотренные ранее аспектно-ориентированные сценарии на основе фильтров MVC, выполняемых перед тем, как пользовательский код получает управление. К счастью, в Core MVC есть способы провести авторизацию вручную.

Затем создадим новую политику и handler:

Наконец, проверяем пользователя + ресурс на соответствие нужной политике внутри action (заметьте, атрибут [Authorize] больше не нужен):

У метода IAuthorizationService.AuthorizeAsync есть перегрузка, принимающая список из requirement — вместо названия политики:

Что позволяет еще более гибко настраивать права доступа. Для демонстрации, используем преопределенный OperationAuthorizationRequirement (да, этот пример перекочевал в статью прямо с docs.microsoft.com):

что позволит вытворять следующие вещи:

В методе HandleRequirementAsync(context, requirement, resource) соответствующего handler — нужно лишь проверить права соответственно операции, указанной в requirement.Name и не забыть вызвать context.Fail() если пользователь провалил авторизацию:

Handler будет вызван столько раз, сколько requirement вы передали в AuthorizeAsync и проверит каждый requirement по-отдельности. Для единовременной проверки всех прав на операции за один вызов handler — передавайте список операций внутри requirement, например так:

На этом обзор возможностей resource-based авторизации закончен, и самое время покрыть наши handler-ы тестами:

Авторизация в Razor-разметке

Выполняемая непосредственно в разметке проверка прав пользователя может быть полезна для скрытия элементов UI, к которым пользователь не должен иметь доступ. Конечно же, во view можно передать все необходимые флаги через ViewModel (при прочих равных я за этот вариант), либо обратиться напрямую к principal через HttpContext.User:

С другой стороны, мы можем использовать подход из предыдущего раздела: получить реализацию IAuthorizationService через DI (да, прямо во view) и проверить пользователя на соответствие требованиям нужной политики:

Permission-based авторизация. Свой фильтр авторизации

Декларативное перечисление всех запрашиваемых операций (в первую очередь из числа CRUD) при авторизации пользователя, такое как:

… имеет смысл, если в вашем проекте построена система персональных разрешений (permissions): имеется некий набор из большого числа высокоуровневых операций бизнес-логики, есть пользователи (либо группы пользователей), которым были в ручном режиме выданы права на конкретные операции с конкретным ресурсом. К примеру, у Васи есть права «драить палубу», «спать в кубрике», а Петя может «крутить штурвал». Хорош или плох такой паттерн — тема для отдельной статьи (лично я от него не в восторге). Очевидная проблема данного подхода: список операций легко разрастается до нескольких сотен даже не в самой большой системе.

Ситуация упрощается, если для авторизации нет нужды учитывать конкретный экземпляр защищаемого ресурса, и наша система обладает достаточной гранулярностью, чтобы просто навесить на весь метод атрибут со списком проверяемых операций, вместо сотен вызовов AuthorizeAsync в защищаемом коде. Однако, использование авторизации на основе политик [Authorize(Policy = «foo-policy»)] приведет к комбинаторному взрыву числа политик в приложении. Почему бы не использовать старую добрую role-based авторизацию? В примере кода ниже, пользователю необходимо быть членом всех указанных ролей для получения доступа к FooController:

Начнем с создания enum для операций, requirement и handler для проверки пользователя:

К счастью, в Core MVC эти проблемы легко разрешимы при помощи атрибута [TypeFilter]:

Мы получили полностью работающее, но безобразно выглядящее решение. Для того, чтобы скрыть детали реализации нашего фильтра от вызывающего кода, нам и пригодится атрибут [AuthorizePermission] :

Дополнительные материалы для чтения по теме (также приветствуются ваши ссылки для включения в список):

Источник

Как в 1С настроить сервис 1С:Кабинет сотрудника

С версии 3.1.14.166 программы «1С:Зарплата и управление персоналом 8» (ред. 3) реализован новый сервис «1С:Кабинет сотрудника». Этот сервис позволяет сотрудникам в любой момент в любом месте, где есть интернет, посмотреть сведения о зарплате, получить справку о заработке, получить расчетные листки, оформить заявление на отпуск, командировку и многое другое.

Бухгалтерии и кадрам сервис позволяет сократить время, которое уходит на предоставление расчетных листков, согласование отпусков, получение справок и других документов. Сотрудникам не нужно ходить в бухгалтерию и кадры, а последним отвлекаться от своих дел.

Сервис пока недоступен пользователям базовой версии.

В версии КОРП ранее уже была предусмотрена аналогичная функциональность » Самообслуживание «. Теперь есть и альтернативная возможность. При выборе того или иного варианта следует учитывать ключевые различия (помимо стоимости):

Подключение и настройка сервиса 1C:Кабинет сотрудника

Подключение к сервису

Подключение настраивается пользователем с полными правами. Настройка вызывается по кнопке Подключить на начальной странице, либо по ссылке Сервис 1С:Кабинет сотрудника в разделах Кадры или Зарплата.

Для работы с сервисом в базе должна быть подключена интернет-поддержка. Если она еще не была подключена, это предлагается сделать здесь же по кнопке Подключить.

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

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

В случае успешного подключения появится этап 5, в котором будет указана ссылка на сервис (если форма подключения была случайно закрыта до перехода по ссылке, то открыть ее можно по ссылке Сервис 1С:Кабинет сотрудника в разделах Кадры или Зарплата).

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

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

Теперь можно продолжить работу в сервисе – ознакомиться с его возможностями и создать кабинеты для сотрудников, если они были выбраны на этапе 3 помощника подключения.

Публикация кабинетов

Если на этапе 3 сотрудники выбраны не были, то после подключения их можно указать в форме, открывающейся по ссылке Сервис 1С:Кабинет сотрудника в разделах Кадры или Зарплата.

Для этого в открывшейся форме нужно перейти по ссылке Изменить настройку публикации.

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

По кнопке Обновить публикацию информация по выбранным сотрудникам передается в сервис.

Обращаем внимание, что для публикации в сервисе ответственного, подключившего сервис, в числе сотрудников, его позиция также должна быть выбрана здесь для публикации.

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

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

Адресация заявок

Для корректной адресации заявок сотрудников из сервиса необходимо указать исполнителей задач в разделе Администрирование – Органайзер – Бизнес-процессы и задачи – Роли и исполнители задач.

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

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

Расписание обмена

По умолчанию автоматический обмен информацией между приложением и сервисом выполняется каждые 10 минут. Изменить расписание или запустить обмен вручную можно из раздела Администрирование – Обслуживание – Регламентные операции – Регламентные и фоновые задания – регламентное задание Обмен с сервисом «1С:Кабинет сотрудника».

Создание кабинетов в сервисе 1C:Кабинет сотрудника

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

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

Необходимо отметить флажками сотрудников, для которых нужно создать кабинеты, после чего нажать Выполнить – Создать кабинеты. Нажатие на кнопку с пиктограммой над списком сотрудников приводит к отображению сотрудников только с таким статусом. Например, можно отобрать только тех, кому приглашение не отправлялось, проставить все отметки и направить приглашения только им.

После создания кабинетов сотрудникам необходимо отсюда же разослать приглашения на почту и/или по СМС. Сотрудники получат инструкцию по подключению, текст которой задан в форме по кнопке с шестеренкой (при необходимости его можно изменить). После подключения сотрудник получит доступ к своему кабинету, что отобразится соответствующей пиктограммой – зеленым человечком.

По кнопке с шестеренкой можно включить автоматическое создание кабинетов и/или рассылку приглашений. Тогда после публикации сотрудников в сервисе кабинеты для них будут созданы автоматически. А после создания кабинетов автоматически будут отправлены приглашения.

Возможности кабинета в сервисе 1C:Кабинет сотрудника

Просмотр расчетных листков

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

Публикация листков производится расчетчиком или любым другим пользователем, профилем которого предусмотрена роль Публикация расчетных листков.

Пользователю с полным правами для этого достаточно перейти по ссылке Сервис 1С:Кабинет сотрудника в разделах Кадры или Зарплата, в открывшейся форме выбрать месяц и нажать Опубликовать.

Здесь же по ссылке Расширенные возможности публикации расчетных листков (или Публикация расчетных листков в разделе Зарплата – эта ссылка доступна пользователю без полных прав) можно выполнить более точечную публикацию листков.

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

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

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

Регистрация и просмотр отсутствий

Сотрудник может заявить о своем отсутствии, чтобы согласовать его со своим руководителем и/или кадровой службой, а также чтобы информировать об этом остальных сотрудников.

Если зарегистрированное сотрудником отсутствие требует согласования руководителем (сотрудник отметил флажок Требует согласования или это отпуск), то сначала оно появляется в задачах руководителя.

Если руководитель согласовывает отсутствие, то пользователю, назначенному ответственным за согласование отсутствий или за заявления на отпуск, будет создана соответствующая задача в программе в разделе Главное – Сервис – Мои задачи.

На основании этой информации пользователь может ввести в программу соответствующий документ, регистрирующий отсутствие. После этого задачу нужно отметить как выполненную, чтобы сотрудник увидел это в своём кабинете.

По некоторым видам отсутствий доступа кнопка Отказать – по ней можно отказаться согласовать заявление сотрудника. Тогда сотрудник увидит отказ в своём кабинете.

Если по какому-то заявлению не предусмотрен отказ, то задачу можно отменить по кнопке Отменено и сообщить об этом сотруднику.

Информация о согласованных отсутствиях других сотрудников доступна для просмотра в области Все отсутствия. В ней предусмотрен отбор по периоду.

Информация по отпускам

В разделе Отпуск сотрудник может просматривать информацию по остатку отпуска, а также запросить более подробную справку об отпусках. Также он может подать заявление на отпуск – точно так же, как и из рассмотренного выше раздела Отсутствия.

При заказе сотрудником справки, пользователю, назначенному ответственным за справки об остатках отпусков, будет создана соответствующая задача в программе в разделе Главное – Сервис – Мои задачи. К задаче автоматически прикрепляется запрошенная сотрудником справка. Достаточно нажать Выполнено, и справка уйдёт в кабинет сотрудника. Если по какой-то причине справка сформировалась неправильно, то по пиктограмме слева от неё её можно удалить и приложить новую взамен.

Сотрудник увидит запрошенную справку в разделах Отпуск и Справки своего кабинета.

Заказ справок

В разделе Справки сотрудник может запросить и другие справки.

При заказе сотрудником справки, пользователю, назначенному ответственным за справки соответствующего вида, будет создана соответствующая задача в программе в разделе Главное – Сервис – Мои задачи.

При заказе справки с места работы к задаче автоматически прикрепляется справка по реализованной в программе форме. Достаточно нажать Выполнено, и справка уйдёт в кабинет сотрудника.

Если требуется передать справку по другой форме (например, по приложенному сотрудником образцу), то по пиктограмме слева от неё её нужно удалить и приложить требуемую взамен.

При заказе 2-НДФЛ к задаче автоматически создается и прикрепляется соответствующий документ программы. Необходимо его открыть, заполнить и провести. После этого достаточно нажать Выполнено, и справка уйдёт в кабинет сотрудника.

Подача заявлений на вычеты

Пользователю, назначенному ответственным за налоговые вычеты, будет создана соответствующая задача в программе в разделе Главное – Сервис – Мои задачи. При этой задаче пользователь увидит приложенные сотрудником файлы, и на их основании должен ввести в программу соответствующий документ (заявление на вычет, уведомление о праве на вычеты).

После регистрации в программе такого документа задачу нужно отметить как выполненную, чтобы сотрудник увидел это в своём кабинете.

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

Информация о структуре компании

В разделе «Компания» сотрудники могут ознакомиться со структурой компании, со списком её сотрудников.

Изменение личных данных

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

Пользователю, назначенному ответственным за изменение личных данных, будет создана соответствующая задача в программе в разделе Главное – Сервис – Мои задачи. При этой задаче пользователь увидит измененную сотрудником информацию, и может ввести соответствующие изменения в программу. После этого задачу нужно отметить как выполненную, чтобы сотрудник увидел это в своём кабинете.

Для руководителей

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

Источник