iscrafmв основном архитектура систем мало чем отличается от обычной схемы:
первичный документ (регистрация факта)-> разноска (проведение, учет и т.п.) -> различные регистры учета. Никакого "теоретического словоблудия", достаточно простая и масшабируемая схема.
В принципе Вы кратко и полно отразили обычный "геморрой" большинства систем. В "УС Land" конечно стержневой является данная цепочка, но для понимания её продублирую заменив часть слов другими:

первичный документ (регистрация факта) -> разноска (проведение, учет и т.п.) фиксация операции -> различные регистры учета и ВСЁ!!! Нет ни каких расчётных действий !

"До кучи" приведу альтернативный механизм формирования документов: справочник товаров склада -> подбор товаров -> порождение первичного документа .

Перечислю справочники , которые в системе "УС" воспринимаются, как "справочники товаров", но используются по разному в разных режимах (несут разную смысловую нагрузку). Для пользователя - "всё едино":

1. Wares - уже представил. Оперативный справочник товаров с кучей одноименных позиций.
2. ArcWares - архив Wares. Куда "сливаются" закончившиеся товары пакетно или по условию. Инфа используется "только для чтения". Решает задачи "переполнения" мусорной инфой основного справочника.
3. Stores - справочник товаров на складах. Пользователю доступны только ненулевые остатки в режимах "расхода". Кроме этого содержит "цены продажи" конкретной торговой точки.
4. Assormin - справочник ассортиментов... Типичный виртуальный объект системы == поведение которого не регламентируется и не контролируется системой, а характеристики и стиль использования определяется пользователем для отражения специфичных бизнес процессов . В картинке карточки товара - последняя строка. Сейчас в основном используется две модели поведения данного объекта :

I. Ассортимент - это товар, измеряемый в штуках и суммах. Как правило (определяется в настройке программ) одноимённые товары принадлежат одному ассортименту. Тогда используя (работая) ассортимент "даётся задание" программе подобрать соответствующий товар.

II. Ассортимент - правило для изготовления продукции. Здесь нет требований "соответствия наименований" и разноимённые товары могут относиться к одному ассортименту, например (масло сливочное, спрей, жир фритюрный).

АССОРТИМЕНТ используется в оперативных режимах: складская логистика, спецификация (индивидуальный прайс и мена) для покупателей, все виды автозаказов, система торговли "по каталогам", контур производства, КПК и тому подобное. Т.е. когда пытаются работать, в том числе с "несуществующим" товаром. Для демо приведу скрин справочника ассортиментов и его реквизиты.

iscrafmАндрей Ж.Но у меня не РСУБД , т.е. "академически" ВСЁ НЕПРАВИЛЬНО. это я уже понял. А как решаются банальные ошибки, типа исправления наименования номенклатуры? Методом правки во всех записях где оно встречается?
Все объекты, ссылающиеся на "товар" содержат ссылку лишь на "код товара" (объекта) следовательно любые изменения НАИМЕНОВАНИЯ (любых других ревизитов) автоматически "изменяются" при простотре данных объектах.

Например: Детализация отгрузки ссылается на товар и при изменении реквизитов товара "имя" - смениться наименование, "фасовка" - измениться количество коробов... Прочие же реквизиты (цена, ставки налогов, кол-во штук) остануться неизменны.

Но так как в ряде (фирм) случаев и настроек изменение имени товара может привести к изменению структуры ассортиментов, то данная операция ЗАПРЕЩАЕТСЯ.

FinSoftОх, Андрей, лучше бы Вы не рассказывали о своей системе такие подробности. Успехов!
ЧТО ЗДЕСЬ "СМУЩАЕТ" ??? Сегодня курсы экстрасенсов пропустил :)

iscrafmпервичный документ (регистрация факта) -> разноска (проведение, учет и т.п.) фиксация операции -> различные регистры учета и ВСЁ!!! Нет ни каких расчётных действий !

печально. Хотя, для мини-программ с мини-данными, которые не подразумевают никаких настроек правил ведения учета, а просто фиксируют происходящие события вполне приемлемый вариант. Но если копнуть, то стадия "геморроя" получается более запущенная.[/quot]
А Вас не затруднит "копнуть" ! Что-то пока проблем подход "просто фиксация", затем при необходимость "анализ" в том числе по методам lifo/fifo/среднее никогда не вызывал!! Но скорее всего не знаю каких-то "подводных камней" - просвятите плиз!

iscrafmмда... чем дальше в лес, тем больше дров. Чуть выше говорили о том, что хранение данных не подчиняется реляционным правилам. Теперь внезапно оказывается, что все же подчиняется. Тяжело понять о чем речь, к сожалению. Есть все же какие-то общепринятые термины, предлагаю их использовать.
"А это крокодил Федя. Расстояние от голову до хвоста 5 метров, а от хвоста до головы 3 метра! Почему так? - Наш крокодил, как хотим, так и меряем".

Реляционные принципы в разработке для меня не являются догмами, а в первую очередь выступает удобство пользования и программирования. Кроме этого РСУБД накладывают некий ограничитель на общую архитектуру БД приложения, а "плоские таблицы" и навигационный метод доступа не даёт таких, пусть даже "формальных" ограничений.

В начале говорилось о "справочнике товаров", где его понятие и архитектура хранения данных противоречат требованию "нормализации", но это не значит, что его "не чту". Например "стержневая" таблица для отчётов HISTORY (+ самая "слабая" "БД"):

codWares Уникальная ссылка на таблицу Wares (ArcWares)
codStores код склада, если операции затрагивает склад
codOper код операции
codDoc код породившего документа, к какой БД по контексту
client код клиента или склада при м/с операции
tipDoc тип документа породившего операцию

// прочие атрибуты меняются при изменении операции/документа
dat дата операции
qtyAll количество, если нужно
sales цена, если нужна
sum сумма операции
tax_n ставка налога НДС в операции
tax_s ставка другого налога в операции

ViPRosFinSoftОх, Андрей, лучше бы Вы не рассказывали о своей системе такие подробности. Успехов!
Присоединяюсь, с определенной долей печали
Лучше без скринов и деталей :)
И когда говорим о Понятиях, то лучше о каким-то образом формализованных в системе
РМД, ДБВ, Оракл и т.д. ут совершенно не при чем

Народ!!! Что-то Вас не понимаю? Если считаете нечто гав..м прошу прямым текстом описать это и желательно обосновать! Иначе данное воспринимается, как отсутствие аргументов, а в психологии "ругань - это главный признак слабости"?

Ох, Андрей, лучше бы Вы не рассказывали о своей системе такие подробности. Успехов! (+) Присоединяюсь, с определенной долей печали
Картинки не нравятся - "на вкус и на цвет"... Логика системы ущербна - обоснуйте! Задачи лучше можно решить - подскажите! Не "въехали" во "что-то" - спросите!

Лучше без скринов и деталей :) Неоднократно декларировал мой подход к демонстрации продукта и "охмурения" заказчика - ПРАВДА И НИЧЕГО КРОМЕ ПРАВДЫ. Здесь делаю описание свойств системы. Какой смысл пытаться обмануть специалистов?

И когда говорим о Понятиях, то лучше о каким-то образом формализованных в системе
РМД, ДБВ, Оракл и т.д. ут совершенно не при чем
Извините за тон :-( Но в этот сумбурный поток сознания вообще "не въехал"

ViPRosИ если есть какая-та Архитектура, то сначала надо приводить ее
т о же самое с "модель", "механизм",...
Извините - поругался, но появились разумные и конкретные соображения...

Для понимания "архитектуры" (модели, механизма) в первую очередь нужно понимание и знание базовых элементов из которых строится "архитектурное сооружение" (модели, механизмы). Реакция пока демонстрирует "не восприятие" (не думаю, что непонимание) базовых элементов. Кроме этого уже отмечал, что это обсуждение со спецами которым не нужно врать, что в неком "абстрактном здание" всё путём... Их в первую очередь интересует из чего оно построено?

ViPRosточто кто - то чего то называет "справочник" ничего не означает
Что бы этот "справочник" появился на самом деле, надо что бы пользователь(внедренец, моделщьик, конечный пользователь ...) имел возможность оперировать с какими-то поведенческими аспектами, пространством состояний и т.д.
Наконец - то начал понимать о чем пытаетесь мне "втолковать"!

Программы "законченное универсальное решение" для микробизнеса, которое оперирует терминалогией понятной "абстрактному пользователю" и "у меня" если говориться "отгрузочная накладная", то это абсолютно конкретный тип документа, а не "объект появившийся в системе в результате моделирования конечным пользователем поведенческих аспектов модели во всех её пространствах состояний" - как я "загнул"???

ViPRos"Товар", "ОС" и т.д. не прогерские понятия
как ты их хранишь всем побоку
но если хранение данных осуществялется особым (надежность, проиводительность, место,...) образом, то лучше поговорить об этом "образе" без "Товар", "ОС" и т.д.
воще не вали все в одну кучу
Всё ok! Если бы решил обсудить "прогерские понятия", то разместился в "разработке ИС", где иногда тусуюсь. Но здесь "обсуждается" учётка для малого предприятия, где "товар, ос, ПКО, НДС, накладная" имеют более важное значение.

Кроме этого все вы прерасно понимаете, что с "прогерских понятий" здесь полный ахтунг!

ViPRosчем попусту говоить и писать приведи подсхемы БД или концептальные схемы
разберемся что там как и на что годится
По "товарам" уже подробно написал. Технической документации по ГОСТ нема. Картинки рисовать в Visio конечно можно, но если возникнет нужда в объяснении нюанса, сложно описываемого словами.