F_PODOT
Краткое описание :
Перестарались с количеством полей в КомандировкеОписание :
Приказы на командировкиЧто измененно :
Перестарались с количеством полей в Командировке. Речь идет о 4
х полях : "Дата начала", "Дата окончания", "Дата прибытия", "Дата выбытия".
1. На этапе ввода приказа директора и ПЕРВИЧНОЙ выписки командировочного
удостоверения поля "Дата прибытия", "Дата выбытия" - лишние. Они вообще не
нужны, т.к. никто не знает толком когда прибудет, когда "выбудет" сотрудник.
Тем более с таким тонкостями не станет разбираться ген.директор, который
засылает своего сотрудника допустим с понедельника по пятницу на чужой объект.
Раз директор не в курсе с эжтим приходится разбираться секретарю, который
бегает за командированными за уточняющей информацией. Командированнные тоже
заранее могут не знать как они через 2 недели будут возвращаться поездом или
самолетом, а от этого может зависеть КОГДА они прибудут: рано утром или поздно
вечером. Т.е. время в пути ЗАРАНЕЕ не известно.
2. Интерфейс с датами построен неудачно. Сейчас он такой:
"Дата начала" ____А_____ "Дата прибытия" ______Х_____
"Дата выбытия" ____Y_____ "Дата окончания"______Б____
т.к. согласно п.1 изначально поля Х и Y неизвестны, то приходится их заполнять
ПО ДИАГОНАЛИ !!!! поля А и Б
Предлагается построить интерфейс с привычным для славян следованием полей, т.е.
слева-направо:
"Дата начала" ____А_____ "Дата окончания"______Б____
"Дата прибытия" ______Х_____ "Дата выбытия" ____Y_____
!!! Обратите внимание, что даты второй строки лежат как бы внутри отрезка А и
Б, как бы находясь на шкале времени.
3. Есть косяки с заполнением полей ХУАБ. Например:
3.1. создаем приказ. Сегодня 22/03/2016. При этом система ставит A=X=22/03/2016
При вводе Б оператор ошибается и ставит 10/03/2013, система переносит
10/03/2013 в Y и светит его красным.
Меняем Б на правильное значение, например 28/03/2016, но при этом Y остается
красным = 10/03/2013.
3.2.создаем приказ. Сегодня 22/03/2016. При этом система ставит A=X=22/03/2016
При вводе Б оператор ошибается и ставит 28/03/2013, система переносит
28/03/2013 в Y.
Меняем Б на правильное значение, например 29/03/2016, но при этом Y остается
прежним 29/03/2013.
!!! Если командировка многоэтапная, то п.1 и п.2 красиво решается переключением
режима панели по Alt+S, при этом лишние Х и Y скрываются. Пользователи
привыкают к удобной вроде бы работе пока не натыкаются на вариант, описанный в
п.3.2. При этом то, что неожиданно вылезло время в пути интерфейс не
подсказывает и печатная форма с КРИВОЙ информацией несётся на подпись
генеральному.
Исходя из клубка противоречий, который трудно разрешить особенно во всяческих
вариантах 3.1, 3.2 и тому подобных, предлагается дату прибытия и дату выбытия
системой вообще не заполнять, т.е. оставлять пустой. Заполнять эти поля будет
бухгалер кассы ПОСЛЕ сдачи командировочного удостоверения только в тех случаях
когда время в пути присутствует. Да и то, если это бухгалтеру важно для обсчета
данных. Если поле не заполнено, то X считать равным А, а Y считать равным Б.
Как измененно :
1. Изменен порядок полей в интерфейсе на :
"Дата начала" ____А_____ "Дата окончания"______Б____
"Дата прибытия" ______Х_____ "Дата выбытия" ____Y_____
2. При изменении значения A, X автоматически принимает то же значение.
При изменении B, Y принимает то же значение.
3. Добавлена пользовательская настройка:
"Настройки Галактики \ Бухгалтерский контур \ Обработка документов \
Значения полей по умолчанию \ Приказы на командировку \ Дата прибытия, дата
выбытия"
- заполняются вручную (по умолчанию)
- совпадают с датой начала, датой окончания
Настройка позволяет скрыть поля X, Y для выбранных пользователей,
либо для всех (если дни в пути оформляются отдельным этапом).
При этом вся логика работы с этими полями сохраняется. Поля заполняются
автоматически (см. п.2).
Если по какой-то причине их нужно поправить, это можно сделать через внешние
атрибуты.