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

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

Рекомендую начать с системы документооборота и многовалютного "движка" учетных регистров.

Корнем учетной иерархи системы пусть будет ДОКУМЕНТ . Документ - это не обязательно некая бумажная сущность, скорее - это некое подтвержденное бизнес-событие.

Далее идут операции , имеем разветвление:
Документ -> Список Операций. Т.е. набираем документ и выбираем операцию из списка возможных для данного документа.

И только затем (в проектировании и разработке) начинаются прикладные области: бухгалтерия налоговая, аналитический учет, всевозможные оптимизированные АРМ-ы кладовщиков, операторов, кассиров, менеджеров и т.д.

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

Предлагаю еще усложнить малость задачу (потом спасибо себе неоднократно скажешь). В более усложненной версии сцепки "Документ -> Список Операций" присутствует понятие "состояние документа". Например, расходная накладная может иметь следующие состояния:
- черновик , документ в процессе набивки, сохраняем его и после к нему неоднократно возвращаемся;
- готов , работа оператора над документом завершена, можно создавать твердые копии, посылать по факсу, мылу и т.д.;
- выполнен , товар РЕАЛЬНО ушел со склада, в одной из организаций, где пользовали мою систему, складские документы в это состояние мог перевести только мат. ответственное лицо, отпускавшее/принимавшее мат. ценности;
- проведен , бухгалтер предприятия выбирает ВЫПОЛНЕННЫЕ документы и проводит их у себя;
- закрыт , директор предприятия имеет право закрыть документ, чтобы спать по ночам спокойно и не видеть снов про разворованную кассу и растасканный склад;

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

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

В общем, успехов.

P.S. Не во всех распространенных на рынке системах использована парадигма состояний документа, что является, на мой взгляд, их сильным недостатком (меньшая гибкость в плане подстраивания под конкретные бизнес-процессы предприятия-пользователя), ибо это заставляет либо подстраивать бизнес-процессы под учетную систему, либо... тратить большие деньги на практически полную переделку стандартных конфигураций для обеспечения той самой гибкости.

2 Hibernate

я бы пошел еще чуть дальше: каждой операции сопоставил бы набор проводок, которые будут описывать то, в каком учете и по каким счетам этот документ должен "засветиться" при выполнении данной операции.

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

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

- карточки товаров:
На каждый товар заводится т.н. КАРТОЧКА с указанием остатков на текущий период (денежное и численное выражение), наименование, категория (ну, например, для алмазосодержащих/драгметаллосодержащих и проч);

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

Еще раз рекомендую присмотреться к партионному учету, реализовать схемы FIFO, LIFO, максимальных цен, минимальных цен, средневзвешенных, а так же возможность ручного "расписывания" партий.

- справочник категорий (все предусмотреть довольно трудно заранее, поэтому предлагаю слегка потрахаться, но реализовать Many:Many к предыдущей категории);
Справочник категорий лучше сделать иерархическим, а еще лучше - изначально спроектировать возможность заводить произвольное число справочников категорий ( даже если вначале будет использоваться только 1).

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

2 vdimas:
Все что вы описывали, я видел лишь в одной программе. Можно узнать, как называется программа, над которой работали вы?

Она ни как не называется, исполняемый файл был "acc" назван.

Система клиент-сервер под MS SQL писанный мной в 1999 и обновленный в 2000-м. После этого я перешел на трехзвенки. :)

Вряд ли вы ты ее видел, она стоит всего у 3-х фирм, ввиду того, что наш клиент практически неплатежеспособен (по реалиям Севастополя, где "мальчики" подгоняют за 100-300 баков настройки под 1С, которые копят и улучшают годами)...

Последние 3 года работал только на буржуев... Хотя, очень жаль...