За/Против добавления времени опер. (Бывш.Ремонт-перемещение)

[Simple]

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

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

Может стоит изменить правило проверки на менее строгое? Не только ">", но и ">="?

[Michael]

Согласен, действительно неудобно. Проверим по алгоритмам, если конфликта не возникает, то уберем эту блокировку.
_________________
Любой путь начинается с первого шага

[Simple]

В принципе, можно даже алгоритмы не менять, а сделать "datetime" вместо "date".
Ну и не только в "Ремонте", во многих операциях такое - например, поступление на склад, списание со склада...
Если в одном отделе ведётся учет - ещё можно выкручиваться, а вот если учет идёт и по Складу(поступление, списание, хранение) и по ИТ (установка, "установлено в работу"), и это разные люди - вот тогда может быть конфликт интересов.

[Michael]

"datetime" вместо "date" - как раз потребует смены алгоритмов. Во-первых, это надо во всех таблицах менять. Т.е. не только в ремонтах, а и в приходе, расходе и т.д. Во вторых, все запросы с использованием этих таблиц тоже надо менять. Потому что если сейчас запись от 31.05.2011 попадает в диапазон 01.05.2011-31.05.2011, то после добавления времени она из него выходит и придется ко всем датам в фильтрах добавлять в конец 23:59:59, или брать следующий день и ставить знак "<".

И, главное, на мой взгляд, из-за добавления времени теряется удобство. Придется следить, чтобы время обязательно попадало между временами других действий и для этого надо будет делать больше мышедвижений. Если просто все в реалтайме вносить, то да, разницы нет. А вот если задним числом что-то надо добавить, то уже надо следить за временем создаваемой записи. Поэтому добавление времени я не очень одобряю. Хотя время в ремонтах у нас уже запланировано, обещал кому-то.
_________________
Любой путь начинается с первого шага

[Simple]

SELECT * BETWEEN datetime datetime прекрасно работает.
Наоборот, удобство не теряется, а появляется. И логика правильной работы появляется.
По умолчанию, =now(), ну а в случае необходимости - проще поменять время в поле на полчаса назад, чем ставить вчерашнюю дату для события, что может потянуть далеко идущие проблемы, в случае больших оборотов или просто неприятных совпадений в случае проблем.

Пример задачи:

01.06.2011 Сломался принтер1.
01.06.2011 Принтер1 перемещается на склад.
01.06.2011 Принтер1 со склада уезжает в ремонт.
02.06.2011 Принтер1 с ремонта приезжает на склад.
02.06.2011 Принтер1 со склада перемещается на рабочее место.

В вашем случае - как раскидать события в 2-х днях реальности? Поставите, что принтер на склад ушёл 1, а в ремонт 2? С ремонта 3, а на место 4? А если 2-го в нём картридж заменили, а 4 переставили в другое крыло, так так там принтер сломался?

[Michael]

[Simple]

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

В вашем примере за всё отвечает один человек. А в реальности?
Техник ИТ обследовал устройство, признал его "Шломаласо", и относит на место хранения.
Хорошо для вас, но хреново в реальности, если отдел ИТ и склад - это одно помещение.
Когда устройство помещается на место хранения - за него несёт ответственность кладовщик.
Решение о ремонте, кто/когда/где принимает нач.ахо или нач.ит - так как может быть надо не ремонтировать, а списывать, а если ремонтировать - то, например, может быть уже выбрана смена на этот месяц и надо ждать - то есть те вопросы, которые техник, притащивший принтер - просто не ведает. Именно поэтому надо разделять этапы.

Вы планируете развивать программку - всё равно вам придётся вводить время. Так может это сделать сейчас, пока функционал не расползся?

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

[Michael]

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

Но тогда вылезают следующие моменты с учетом рабочего времени. Сейчас алгоритм относительно прост и считает пробег принтера (и каждого картриджа) в целых днях. На основании этого пробега считается вся остальная статистика. Если появляется время, то нужно считать пробег уже в часах и минутах. Начиная от начала рабочего дня, возможно, исключая обед, и до конца дня. Т.е. если принтер чинили два часа в течение дня, то эти два часа попадут в ремонт и в прогнозе расхода учитываться не будут. Вроде бы просто, надо добавить в свойства филиала два параметра (для обеда - еще два). Но, ведь теоретически это время может в какой-то момент измениться. Т.е. весь филиал работал с 10 до 18, а стал работать с 9 до 21. И просто изменить эти параметры будет нельзя, т.к. поедет вся статистика. Значит, надо вводить историю рабочего времени.

И еще вопросы:
1. А если в пределах филиала разное рабочее время на разных рабочих местах?

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

Мне все это видится так, что надо добавлять все эти календари рабочего времени, выходных и праздников и т.п. Дорабатывать алгоритмы, интерфейс и отчеты (везде используются SQL-запросы). По-хорошему, сохранять возможность не использовать время (кому-то так наверняка удобнее), а значит везде учитывать два варианта - со временем и без. Это очень много писанины. Да, наверное, мы это со временем сделаем, но точно не в этом году. Просто есть более приоритетные вещи.
_________________
Любой путь начинается с первого шага

[Simple]

[Simple]

Переименовал тему, так, по-моему - будет точнее.

[Neptus]

[Simple]

Расход по картриджам надо вести с учетом каждого принтера, например, есть 2 принтера HP LJ 2055, на одном картридж расходуется за месяц, на другом - за 6 месяцев, тип картриджа - одинаковый.

В то время, когда я ещё не познакомился с этой программой ( ), я учет вел в эксельке, и прогноз у меня считался по каждому принтеру в виде "Среднее время время работы картриджа". А оно определялось просто:
"Время существования принтера / количество смен картриджа"
Соответственно, прогноз гласил "Дата последней установки + ср. время работы = предпологаемая дата смены картриджа".