(++) Протокол замечаний п. 4.2

[pilugino]

Также, в окнах накладных, в фильтре «Состояние» по умолчанию необходимо ставить значение «К работе».

[korvin]

«Состояние» по умолчанию «к работе» сделать нельзя, поскольку это нарушит правило построения интерфейсов. Т.к. с точки зрения пользователя собранные накладные будут пропадать, и пользователи (все 14) будут регулярно обращаться к нам с жалобами, что «программа не работает». Пользователь должен видеть, что накладная им успешно отобрана.

[pilugino]

Состояние по умолчанию «К работе» необходимо для того, чтобы пользователь, когда заходил в приходные/расходные документы, видел только те документы, по которым необходимо работать. К тому же, в какой-то момент, собранных документов будет огромное количество, и выводить их полный объем – сильно грузить систему.

[korvin]

Но собранные им накладные будут исчезать, и все 14 пользователей будут постоянно ругаться, что Ваша система не работает, и "исчезают накладные". Будет бунт пользователей. И они будут правы. Т.к. нельзя нарушать безнаказанно основные принципы построения интерфейса!

А вопрос удобства решается просто - сортировкой и фильтрами.
По умолчанию пользователь будет видеть только накладные за 2 последних дня. И по умолчанию сортироваться будут по собранности - вначале несобранные, потом собранные. Этого будет достаточно?

[pilugino]

Ситуация следующая: замечания писали именно кладовщики! Требование было видеть только накладные в состоянии "К работе". Далее, когда накладная собрана, окно накладной в этот момент открыто и в этом окне видно, что состояние накладной поменялось на "Собрана", далее кладовщик закрывает окно накладной и снова видит список накладных, имеющих состояние "К работе". Если им нужно посмотреть собранные накладные, меняют фильтр и смотрят.

[korvin]

Так грид не работает.
Как только документ сменит свое состояние, то запись исчезнет из DataSet, и любая попытка обратиться к ней вызовет ошибку.
Документ "к работе" это sql запрос с условием "doc_state=1".
После ее сбора doc_state=3. В исходном sql-запросе с "doc_state=1" ее уже нет.
Можно только сделать обработчик ошибки - который скажет, что мол ошибка - накладная изменилась.
В результате кладовщики будут на нас ругаться, что программа не работает.

[pilugino]

Вы имеете ввиду, что если у нас в списке будут отображаться накладные, отобранные при помощи фильтра, с состоянием "К работе", и когда мы ее соберем, вылезет ошибка?

[korvin]

да, ошибка вылезет "Record changed or deleted by another user".

[pilugino]

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

А причем тут ошибка

да, ошибка вылезет "Record changed or deleted by another user".

, совершенно непонятно.

[korvin]

по ходу сбора накладной соотв. запись обновляется. т.е. dataSet.RefreshRecord.
Тот факт, что накладная собрана, определяется на сервере, и проставляется соотв. статус.
Следовательно, при очередном dataSet.RefreshRecord запись не находится. Т.к. сервер понял, что накладная собрана, и изменил ее статус. А выставленный фильтр "К работе" не позволяет увидеть накладные в ином статусе.

На примере: запрос - select * from doc where doc_state=1
накладная с ID=1234 попадает под этот фильтр, т.к. у нее doc_state=1
Но, по мере сбора, она собирается, и сервер ставит doc_state=3
Соотв запрос select * from doc where doc_state=1 and id=1234 вернет пустой ответ, и будет ошибка.

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

Нам кажется правильнее 1-й вариант, т.к. интуитивней понятней пользователю.

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

[pilugino]

Сергей, проверили, на всякий случай, действительно вылетает ошибка. По нашему (отдел ИТ) мнению, в данной ситуации, целесообразно тогда выбрать 2-ой вариант и сделать обработку ошибки, в которой указать, что накладная собрана.

[korvin]

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

[korvin]

Сделано!