ГрАнь-Л,

При проектировании системы автоматизации надо прежде всего определить цели для реализации которых она создается. Далее определиться с предметными областями, в рамках которых планируется ее применение, и бизнес-результатами ее применения.
Если речь идет о системе комплексной автоматизации предприятия, то в качестве предметных областей можно выделять виды учета. А именно, оперативный учет, в том числе производственные, сбытовые, снабженческие подразделения, бухгалтерский учет, налоговый учет, управленческий учет. Каждую из предметных областей с одной стороны можно воспринимать как полностью самодостаточную составляющую системы, с другой необходимо учитывать их взаимную зависимость. Эта зависимость с одной стороны определяется необходимой справочно-нормативной составляющей (справочники организаций, материалов, регистров учета и т.п.), с другой стороны бизнес-объектами, которые должны совместно использоваться в разных предметных областях. Выполнение описанных условий и позволяет добиться как непротиворечивости информации в системе, так возможности использования своих собственных подходов для каждой предметной области.
Далее переходим к определению задач, которые необходимо будет решить для каждой предметной области. Прежде всего классифицируем их. Для классификации можно использовать два основных классификатора (можно не значит обязательно, это обобщенный смысловой вариант):
1. Планирование - Контроль исполнения.
2. Анализ - Ведение учета.
Каждая задача и итоге будет иметь принадлежность к обоим классификаторам.
Пример:
Задача - "Формирование плана закупок при известной потребности в материалах и сырье, установленном перечне поставщиков по каждой позиции и отсутствии необходимости в анализе возможной финансовой ситуации на предприятии".
Принадлежность - Планирование (понятно, что речь идет о составлении плана), ведение учета (потребность известна, в анализе нет необходимости, есть необходимость только в определении что и когда должно быть закуплено, без анализа у кого и своих финансовых возможностей).
Далее определяем взаимосвязь задач между собой и, соответственно, уточняем взаимосвязи между предметными областями.
После проведения такой классификации станет понятно какой набор таблиц и классов с учетом выявленных взаимосвязей понадобится.
Теперь по поводу специфика взаимосвязей между предметными областями.
Для примера возьмем оперативный и бухгалтерский учет.
С одной стороны это взаимосвязь на уровне нормативно-справочной информации - Справочник материалов используется для формирования в системе оперативного учета счетов-фактур (позиции спецификации документа), и одновременно, как аналитический разрез при отражении хозяйственной операции в бухгалтерском учете. С другой стороны - сами счета-фактуры, формируемые в оперативном учете являются аналитическим разрезом для бухгалтерского учета.
При этом отчетность, которая формируется для оперативного учета и для бухгалтерского учета не всегда должна быть полностью идентична. К примеру при обработке платежек может понадобиться учет по дате распоряжения на оплату для оперативного учета и по дате подтверждения банка (банковская выписка) для бухгалтерского учета, ну или разница в датах для ведения бухгалтерского и налогового учета в учете основных средств (расчет амортизации).
Что касается принципов формирования, ну или ведения проводок по регистрам учета.
Оптимальным, на мой взгляд, является следующее решение:
Первичка --> Движок трансформации информации для бух учета (налогового) учета --> Проводки.
При использовании такого подхода, сохраняется независимость составляющих системы, и при этом поддерживается как непротиворечивость информации, так и гибкость по настройке ее преобразования.
Что касается использования информации для аналитических целей. Имеются ввиду задачи связанные только с анализом накопленной информации. На основе какой информации формировать отчетность? На мой взгляд тут все зависит от того за какой именно период необходимо сформировть отчетность. Если речь идет о периоде превышающем три месяца (при прядке в ведении бухучета - месяц), то лучше при наличии такой возможности использовать информацию бухучета, в остальных случаях, либо при отсутствии такой возможности - оперативная информация по первичке. Причина простая - лучше формировать отчеты на основе десять раз проверенных данных.

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

iscrafm,

авторПо крайней мере это никоим образом не является аксиомой.
Об аксиомах речь не шла в принципе. Я просто немножко поделился своими взглядами на некоторые вещи... ведь форумы именно для этого и существуют.
авторв области учетных и аналитических систем поле для поиска новых решений еще очень большое, рано говорить о "велосипедах".
С технической точки зрения - да. Именно так все и есть, более того, все меняется и меняется быстро, появляются новые технологии, новые решения на базе этих технологий, но если смотреть с точки зрения бизнеса, то техническая красота не играет первостепенной роли. Важно, чтобы решение давало результат с максимальной долей вероятности. Хотя... вот к вопросу об аксиомах... не так давно обнаружил довольно интересное решение которое как раз не велосипед. Ну да ладно... поживем - увидим что из этого вырастет.
авторА на счет "долго и муторно" и перессоритесь... нужно смотреть.
Создание любого решения с нуля, если речь идет о том, что это не поделка для конкурса "очумелые ручки" всегда требует времени и, с учетом последующего тестирования с отловом багов - муторно.
Кроме того речь шла о комплексной системе. Такие вещи за месяц не делаются, это очень серьезная задача.
По-поводу перессориться... ну да, в самом оптимистичном варианте, вот точно не аксиома :)

iscrafm,

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

iscrafm,

авторподелитесь? тоже интересуюсь интересными решениями.
Вот не из вредности и тому подобного. Там пока рано о чем-то говорить. Правда рано, но по смыслу очень интересно. Надо просто немного подождать и там все видно будет.

iscrafm,

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

По поводу остального... ну ведь речь идет не об использовании конструктора в котором уже многое реализовано в виде компонент. Речь о разработке с нуля. А тут просто технологический цикл разработки, не родят девять женщин одного ребенка за месяц... даже если очень захотят :)

iscrafm,

авторесли программировать каждую форму, механизмы взаимодействия с СУБД, систему формирования отчетности, то конечно. Я просто такой вариант не рассматривал. Навряд-ли в наше время кто-то берется за такую работу с такого чистого листа, с компилятором в кармане. Разве что энтузиасты которые занимаются разработкой ради самого процесса разработки.
На самом деле берутся, при чем не только энтузиасты, насколько я знаю, и в некоторых случаях, для заказчика, это реальный способ решить вопрос.
А мой пост изначально и был написан, исходя из того, что Топикстартер именно разработку с нуля ради решения вопроса с лоскутной автоматизацией и задумал (там первый пост вполне однозначен) :)
При чем не очень понимая за что берется во-первых, и не понимая в чем разница между аналитической и учетной системами во-вторых :)

iscrafm,

Ага, точно консенсус :)