Егоров АлександрOld Nick,
поясните мысль? Не очень понятно зачем тут бухгалтерская основа.

Вопрос можно сформулировать иначе.
Кто пытался уйти от интерфейсов ориентированных на документы(Excel - лучший грид всех времен и народов), к интерфейсам ориентированным на задачи.Или еще проще - как сделать интерфейс внятным и понятным?
Вопрос сложный и одназначных вариантов никто не даст. Тут уже давали примеры интерфейса Dynamicx, у MS есть рекомендации на тему RoleTailored UX c весьма здравыми идеями User Experience Guidelines for Microsoft Dynamics NAV 2009 .
Реализовывать это программно удобно с помощью идей ASP.Net MVC(контроллеры/акции).

Petro123дело не интерфейсе, а в :
предмет и объект автоматизации.
У разного класса ПО они разные.
То-то и оно,что задачи разные, а интерфейсы одинаковые.Образец для подражания - 1С.

Предметы и объекты пользователям совершенно индиффирентны.

Petro123, причем здесь документы,когда автор спрашивает,как сделать удобной и понятной работу с программой? Когда оперируют категориями документов, тогда и появляются требования к кандидатам при приеме на роботу об обязательном знании 1С.

iscrafmне нужно никаких специальных условий... Лично я, когда сам систему проектирую, всегда таким образом поступаю и другим советую. Главное четкую логику и интерфейс удобный проработать. А от форм "первички" работать, как Вы говорите, "нуегонафик". Форма первички - это твердая копия соответствующего формата определенного этапа бизнес-процесса, не более. Форм первички масса на один и тот же процесс.
И в чем заключается удобство интерфейса из примера?

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


1. Выполняется обследование и анализ деятельности организации/предприятия
2. Строятся диаграммы всех бизнес-процессов, которые будут автоматизированы и заказчик подписывается под этим
3. Затем по каждому бизнес-процессу расписывается подробно каждая его операция в виде диаграммы последовательностей, а также визуальные формы для каждой операции.
Первые три пункта делают бизнес-аналитики и на выходе получается модель анализа бизнеса.

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

В дело вступают ведущие программисты
5. Необходимо разработать подробное ТЗ для кодировщиков по созданию дополнительных сущностей и по реализации каждой операции из каждого бизнес-процесса.

В таком случае заранее будет известна трудоёмкость, заранее известно время, качество будет на очень высоком уровне и за каждый этап будет отвечать тот, кто его делал. И будет полная документация, а также этап бизнес анализа и собственно автоматизацию могут выполнить совершенно разные организации.
А дальше садятся программисты и ваяют формы,которые только им одним и понятны.

П-ЛOld NickЗа отступление от ТЗ очень строго наказывать, потому что в ТЗ уже нарисован внешний вид формы и каждая кнопка и поведение по нажатию на кнопку.
Вы считаете можно заранее наперед нарисовать для новой системы безошибочный внешний вид форм ?
Нет, не считаю.Рисовать их тоже целая наука. По этой науке,правая колонка на форме icrafrm должна быть слева, тк мы читаем справа налево и будет более привычное движение зрачков.
В описании Old Nick совершенно не учтен тот факт, что подписывает руководство, которое давно уже не сидит за клавиатурой.

Old NickДа, абсолютно точно уверен. Потому что форма рисуется для конкретной операции, в которой заранее известно, какие данные будут показаны и/или какие данные нужно будет ввести и логика действия операции уже полностью прорисована в диаграмме последовательностей. И в любом случае внешний вид формы прорабатывается до кодирования, потому как кодирование должно занимать 5-10% времени. Кодирование в данном случае есть лишь перевод кода из одного формата в другой с некоторой степенью детализации. Первый формат это диаграмма последовательностей, а второй код на C# или Delphi.

Эту уверенность лучше подтвердить наглядными экранами.

Old NickЭтот вопрос можно сравнить с заданием для токаря выточить поршень. Оставим внешний вид поршня на усмотрение токаря.
Когда я ковырялся в коде MFC, именно такие ассоциации меня и посещали - токарь на большом военном заводе, тачает горшки на случай ядерного взрыва, по разнорядке с верху. Болванки всех версий одного калибра и полностью совместимы, но попробуй что-нибудь под себя заточить, легче застрелиться. MS - завод по клепанию форм и нас к этому приучает. IPhone по железу и функционалу ничего из себя особенного не представляет, но только на это подавляющее большинство внимание не обращает

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

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


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

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