_модstells21. Я сделал как у них в журнале, как они привыкли ( в смысле пользователи работающие с бумажным журналом)

Автоматизировать бумажный журнал ? Без вставки, удаления, корректировки и записи только последовательно ? Ну ну
:) Задачи конечно бывают разные... но не в этом случае. Но в общем, я крайне против перевода счетов на калькулятор. Тем более, это не переход со "старой" системы на "новую".. Это фактически новая, впервые создаваемая система. И потому, никто ни к чему не привык.
Есть простой принцип (ИМХО из опыта): Если программисты хреновые - грузим БД логикой по полной, оставляя программисту минимум напряжения мозга.. Иначе, база может быть проще.
У нас первый вариант :(
Конечно, первично - прототипом представления информации (и её ввода) является бумажный журнал. Но, если есть БД, и эта БД нормально организована то, понятно что существуют справочники, зависимости и т.д.
То, что есть в 1С не совсем табличная форма.. Хотя, и там как правило, используются формы.
Я согласен, что система, и приложения в частности, не должны усложняться.
Не хочу не кого задеть.. но честно говоря ERP система основанная на XLS файлах.. немного смущает :)
-------------------------
Как я и говорил, тема "форма или таблица" не так однозначна.. судя по постам :)
Я делаю вывод - международного или еще какого либо стандарта нет. Есть корпоративные, и знания (возможно убеждения) полученные в ВУЗах, курсах и опыте, а так же, различных не официальных источниках как то книги, чьи-то изыскания в этой области и рекомендации . Вот последнее меня и интересует.

В данном проекте я архитектор (аналитик, АБД, проектировщик, менеджер), просто фирма не софтверная а чистое производство (большое) и практики характерной для коллективной разработки ИС, где бы четко существовала иерархия (аналитики, проектировщики, постановщики, программисты , тестировщики и т.д) нет.
исключаю возгласы по поводу ERP.. Да, это не сравнится с брендами в этой области, да несколько упрощенная схема.. Но ERP характеризуется не качеством или сложностью а назначением и организацией.. Кризис, мать его.. вот и делаем .
Наверно, сложность возникает (и будут еще) в связи не совсем качественным ТЗ, не все там проработано.. Ресурсы ограничены, как людские так и по времени..

Ребята, коллеги, меня не надо убеждать.. :)
Я совершенно с вами согласен.
И я не вчера закончил ВУЗ.. т.е. не настолько прямолинеен.
Имеется, как мне кажется достаточный, многолетний опыт программиста-разработчика.
И когда я планирую интерфейс, то естественно учитываются многие факторы, как то:
Функционал,
Удобство,
«интуитивность»,
Информативность
Минимизация нагрузки на оператора по вводу/корректировки данных
Цветовая схема
Расположение элементов
Минимизация возможных ошибок ввода/корректировки
«Привычность» (общепринятый GUI (на примере Windows), сложивщийся механизм работы пользователя (выполнение своих операций, возможно не автоматизированных).
Целевое назначение
Ну и т.д…..
хотя проще сказать можно: учитывается эргономика, функционал …. :)
И это все реализовать - отдельная головная боль.. Думаю, с этим наверно многие могут согласиться.
Но есть обратная сторона – когда все же требуется реализовать логику приложения…
А тут уж приходится искать компромисс, ну а кто сказал что сложный по сути продукт должен быть «для домохозяек»? (известного персонажа в расчет не берем).
И пожалуй, мне гораздо важней, как тут верно заметили, что бы система не была навязана и не доставляла мучений, что бы она была нужна и естественно заменила устаревшую технологию..
Это насчет как оно должно быть :) (а как бывает – все мы знаем).
Просто, садится и писать «стандарт» с нуля – нет времени. Вот и хотелось ознакомится с источниками.. Я не помню авторов, а так сам бы нашел.

iscrafmstells2,
побродите по ссылкам ...
Спасибо, буду разбираться

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

то разработка нетабличной формы может говорить о закостенелости мЫшления постановщика задачи.
Вы не совсем правы.. :)
Аналитик не настаивает на форме и не отрицает таблицу..
В данном случае, табличная форма выполняет роль просмотра, т.к. в ней должны отображаться данные не тоько из одной таблицы а так же, отображаться данные полученные системной из внежних источником (контролеры). Следовательно, коль ввод и корректировка данных ведется посредством процедур (ну а как иначе в этом случае) то использовать форму ввода пожалуй единственный выход. К тому же, обеспечить минимизацию ошибок ввода можно. Ну и.. мы выносим операцию ввода/корректировки в отдельный функционал что и следует логике.
Простой пример:
Вы – напарник коллеги в смене, перед Вами рабочее место где на ¼ экрана сетка с массивом числовых данных, часть из них может обновиться автоматически.
Настал момент и надо ввести данные. Коллега начал вводить от отвлекся, отошел. Вам приспичило откорректировать другие данные – Вы начинаете редактировать «свои» данные, сохраняете. Да, система что-то там вроде как говорила.. А в это время, ваши данные ложатся «на стол» диспетчеру который должен принять решение. Решение основано на тех данных что предоставил ваш АРМ (точнее, тех данных, что возможно отредактированы или внесены вашим АРМом)…
Вопрос, насколько будет удобно работать за таким АРМом? К тому же, ввод/корректировка данных есть единичная операция, выполняемая пару раз в смену (не суть, но это не потоковый ввод). Просто, сегодня программист, за неимением опыта, еще не представляет тех нюансов с которыми столкнется, даже в плане программирования. Несмотря на то, что казалось бы табличная форма проще – это обманчиво. Так как требуется обеспечить контроль ввода, указания ошибки и т.д. Реализовать это в gride (C#) несколько сложней, чем в модальной форме.
В общем, понятно что можно сделать всё абсолютно.. и я не спорю. Можно сделать режим представления и редактирования как угодно, все зависит от квалификации программиста (и согласитесь, как следствие – человеко-часов).
Я так же не думаю, что стоит забывать или отказываться от «старых» систем, те технологии не ориентировались на монстрообразные компьютеры и полностью просчитывались исходя из требований «оператор-машина», и весьма не плохо проработанные. Все надо в меру… :)

stells2
Я так же не думаю, что стоит забывать или отказываться от «старых» систем
следует читеть как что не стоит забывать

iscrafmstells2,
На ровном месте столько проблем...
да нет никаких проблем. :) Всё решилось само собой, и человек сам решил что форма ввода в данном случае более подходит.. Решилось как только приложение попало в "работу"..
Эх.. Глядя на посты (в том числе и мои), все о чем угодно только не по сути.. Видать это всегда так :)
---------------------------
немного заинтересовало "выбрать нормальную среду.." что имелось ввиду?
У нас нормальная среда - VS, система - asm/(c/c++ - *nix)/java. СУБД - Oracle.
Клиенты на C#. Или, имелось ввиду что-то иное? Нет, WEB технологии не используются.

спасибо всем, приятно что столько людей готовы пообщаться... :)