Боюсь, что я не очень внимательно прочитал все постинги, и примера книги у меня нет(написать, что ли?). Но у меня возникло впечатление, что народ, в основном, идет от бухучета. На самом деле надо делать склад (или другую фичу), а потом его привязывать к бухучету. Тогда задача становится гораздо проще. Конвертер от нормальных данных к бухучету (в российской действительности) написать гораздо проще. Мои "склады" говорят с кладовщиками на их языке, а бухи получают данные на своем языке.
==========
Вот только, что я до сих пор не решил оптимально - места хранения. Тут бы лучше подходила иеврхическа БД, а на реляционных приходится извращаться.

Базовые структуры складской БД.

Основные (имеют естественные первичные ключи)
Таблица текущих остатков
Таблица движения материальных ценностей
Таблица оплат
Таблица заказов

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

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

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

Да никакого ноу-хау. Разве-что в таблице движения уж никак не нужен ID. А вот конкретные поля - это уже не типовые вещи. Для разных случаев нужно по разному организовывать.

Ключ

ПК (первичный ключ) документа
ПК товара

Прочие поля

Цена
Количество со знаком
...

=======
А уж ПК документов и товаров могут быть разные. Для документов это может быть и ID, и Дата+Номер+Вид движения+ID контрагента+ID обработчика документа.

Для ПК товаров вообще куча вариантов. Для склада готовой продукции молокозавода одно, для мелко-оптовой торговли - другое. На молокозаводе наименований немного, можно польный справочник продукции огранизовать. А на мелкоптовом складе половина видов товаров два-три раза проскакивают - легче непосредственно таблицу движения заполнять.
=======
Пожалуй, единственное, что я могу сказать точно и определенно, что в таблице движения нужно хранить количество со знаком и отпускную/приходную цену.

Если под макркером движения понимается тип движения, то лучше его пихать в таблицу документов.

Типы движения

Покупка
Продажа
Внутреннее перемещение
Недостача
Излишек
Естественные потери
Форс-мажорная порча
Безвоздмезная передача
Безвоздмезный прием
Взнос в уставной фонд
Прием/передача на ответсвтенное хранение
Прием/передача в/из переработку
Выдача в подотчет
===============
Че-то еще кажется забыл

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

Первоначальная идея создателей двойной бухгалтерии была остроумна и свежа – любая денежная сумма отражается в журналах дважды: один раз указывая на конкретные деньги (актив), другой раз на источник финансирования (пассив). И все было хорошо. И были прекрасно отработаны механизмы. Но с развитием систем учета перед бухгалтерией стали ставить все новые и новые задачи. Одна из них – количественный учет материальных ценностей. Бухгалтерия вышла из этого положения придумав счета аналитического учета. Но это настолько загромоздило бухучет, что учет движения товаров стали выносить на отдельные рабочие места, а собственно бухгалтерия получала от этих рабочих мест только сводные проводки.

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

Даже принцип ведения учета у них иной, чем у бухгалтеров. Например. По какой-то причине неправильно был оформлен приход партии товара – количество и сумма были указано больше, чем пришло на самом деле. Причем это было обнаружено после закрытия учетного периода. Бухгалтерия делает сторнирующую исправительную проводку текущим периодом. И у нее все правильно и хорошо. Если так же сделает склад, то получится, что в прошлом периоде у них товар был, а в следующем - пропал. Но ведь так быть не может! На складе исправления делаются в том периоде, в котором сделана ошибка. Это очень важно для управленческого учета.
Вот, расписался, еще и управленческий учет приплел, который тоже является отдельным понятием и который бухгалтерия делает очень плохо. На самом деле на любом предприятии существует как минимум три вида учета: бухгалтерский, складской и управленческий. Только вот обычно их пытаются свалить в одну кучу и навесить на бухгалтерию.
Чето надоело мне писать.

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

Брать ли бухучет за основу – не брать. Складской учет, с его карточками, на тысячи лет постарше бухучета будет.

Бухгалтерские программы так громоздки, потому, что для ввода одной операции нужно сделать несколько проводок. Если идти по пути от склада, то по одной введенной операции для бухгалтерии формируется несколько проводок. И еще, хотя уже и совсем лень писать. Бухучет в условиях России давно превратился в механизм для вычисления налогов. В связи с этим он так запутан, непрозрачен и громоздок.