Здравствуйте, Other Sam, Вы писали:
>> Сама предметная область и её мат. модель — сильно разные вещи бывают. >> При развитии компьютерных систем все чаще бухгалтеры оперируют не >> проводками, остатками и оборотами, а "документами", "товаром на складе", >> "доходами", "налогами" и другими объектами, специфичными для бизнеса. >>
OS>И правильно делают! Система должна подстраиваться под людей, а не люди OS>под систему! Пофиг какая там мат модель, бухгалтер должен там увидеть OS>то, что он ожидает. Ожидает "документ" — значит должен быть документ.
Именно.
OS>Как это будет устроенно внутри — это для бухгалтера не имеет никакого OS>значения.
Зато для программиста имеет большое значения. Вот об этом я и говорю.
OS>Что хочу сказать? Пользователь прав! В данном случае — бухгалтер прав!
Пользователь всегда прав.
OS>Читайте "Психбольница в руках пациентов" Алана... забыл фамилию.
Купер.
>>> > >>> > OS>Там будет много чего... >>> > OS>Остатки, накладные, акты. Какие-нибудь инвентаризации, списания в >>> > OS>результате порчи, пересортица, недостачи и возмещения. >>> > OS>Вообще там будет несколько срезов. Один по деньгам (он же >> используется в >>> > OS>баллансовых отчетах). Другой срез по кол-ву товаров. Там еще выплывут >>> > OS>всякие партии поставок, сроки годности... >>> > Смешались в кучу кони, люди... >> >> OS>О чем это вы? >> О том что не надо все мешать в одну кучу.
OS>Прелагайте как разделить эти вещи по разным кучам. Я выслушаю.
Вкратце суть: нижний уровень — двойная бухгалтерская запись, выше — документооборот, между ними множество отображения документов в проводки,
сбоку — система справочников, которая хранит контрагентов, товары, номера счетов.
Отображения документов лучше делать каким-нить скриптовым языком, а в идеале текстовым DSL, чтобы менять можно было.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, ronaldo9, Вы писали:
R>>Здравствуйте.
R>>У меня вопрос по проектированию модели данных для складов.
R>>А какое Ваше мнение, господа?
G>А почему не 1С?
Не могу ответить на этот вопрос — не моя зона ответственности. Нужно написать заказное ПО.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>>>В данном случае число лет может быть 3, и 5, и 10. Суть в том, что размер БД должен быть как-то ограничен. G>>Зачем? R>Техническое ограничение. Используется бесплатная версия БД с ограничением на объем 4 Гб.
Забить проводками 4ГБ надо сильно постараться.
Re[3]: Задачка: модель данных для склада с версионностью
Лог всех операций (возможная отмена, перенакатывание и потенциально более высокие кол-во TX) + всевозможные виды, включая, аггрегирование, т.е. сколько ИТОГО на текущий момент времени запроса. (см. CQRS) Еще (лично) я бы подумал об уникальном идентификаторе для каждой операции.
Re: Задачка: модель данных для склада с версионностью
Здравствуйте, ronaldo9, Вы писали:
R>Вероятно, имеет право на жизнь 3 вариант, который является комбинацией 1 и 2 вариантов. В нем мы заводим табличку "базового" состояния складов, которое было до совершения первой неудаленной операции. Тогда, при удалении устаревших операций, мы применяем их к "базовому" состоянию складов. А состояние складов за определенную дату получается путем объединения "базового" состояния и операций до этой даты.
Думаю именно третий вариант. Вам тут насоветовали уже немало, хотя и без особой конкретики. Я думаю вам стоило бы начать с модели домена (предметной области). Например: Есть объект класса "Склад" который ссылается на множество объектов класса "Товар". Каждый объект "Товар" ссылается на цепочку "проводок". В "Проводке" есть дата, источник товара, сколько отгружено, остаток и ссылка на предыдущую "Проводку". Таким образом вы получаете остатки на текущий момент и историю произвольной глубины с возможностью откатиться по любому товару или по всем сразу. Историю можно обрезать и сохранить в архив когда потребуется. В реляционном рпедставлении думаю будут три таблицы: "Склады", "Товары", "Проводки". Ну а всякая статистика уже поверх этого ядра.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, ronaldo9, Вы писали:
R>>Вероятно, имеет право на жизнь 3 вариант, который является комбинацией 1 и 2 вариантов. В нем мы заводим табличку "базового" состояния складов, которое было до совершения первой неудаленной операции. Тогда, при удалении устаревших операций, мы применяем их к "базовому" состоянию складов. А состояние складов за определенную дату получается путем объединения "базового" состояния и операций до этой даты.
А.М>Думаю именно третий вариант.
Если ты так думаешь, то почему в своей модели домена не указал "базовое состояние" ?
А.М>Вам тут насоветовали уже немало, хотя и без особой конкретики.
Ты прямо конкретики рассказал...
А.М>Я думаю вам стоило бы начать с модели домена (предметной области). Например: Есть объект класса "Склад" который ссылается на множество объектов класса "Товар". Каждый объект "Товар" ссылается на цепочку "проводок". В "Проводке" есть дата, источник товара, сколько отгружено, остаток и ссылка на предыдущую "Проводку".Таким образом вы получаете остатки на текущий момент и историю произвольной глубины с возможностью откатиться по любому товару или по всем сразу. Историю можно обрезать и сохранить в архив когда потребуется. В реляционном рпедставлении думаю будут три таблицы: "Склады", "Товары", "Проводки". Ну а всякая статистика уже поверх этого ядра.
Ну и бредятина.
1) у проводки нету ссылки на склад, только на товар, значит чтобы отличать на какой склад пришел товар записи о товарах должны быть разными.
То есть кроссовки на складе 1 это не кроссовки на складе 2. И как тут обороты по всем кроссовкам получить?
2)Остаток хранится прямо в проводке, это значит при изменении проводки, которая была раньше надо пересчитывать все идущие после нее
3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной.
4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть.
Выкини свои книжки по DDD\ООП, изучай ER, РСУБД, olap и ботай бухучет.
Re[3]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>1) у проводки нету ссылки на склад, только на товар, значит чтобы отличать на какой склад пришел товар записи о товарах должны быть разными. G>То есть кроссовки на складе 1 это не кроссовки на складе 2. И как тут обороты по всем кроссовкам получить?
Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах.
G>2)Остаток хранится прямо в проводке, это значит при изменении проводки, которая была раньше надо пересчитывать все идущие после нее
Остаток можно хранить в товаре, но его придется пересчитывать в любом случае, где бы он не хранился. Можно конечно и не хранить,
но тогда придется все время пересчитывать, чтобы узнать остатки.
G>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной.
Добавляем класс/таблицу "Накладная" и ссылки на "проводки".
G>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть.
Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход.
Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты.
Re[2]: Задачка: модель данных для склада с версионностью
Здравствуйте, sereginseregin, Вы писали:
S>Однако, механизм Срезов на порядок усложняет систему: S>- Необходимо на уровне СУБД запретить исправление операций, проводимых датой раньше любого существующего среза. S>- Или пересчитывать все срезы идущие датой после операции
Проблема устраняется, если представить исправление/отмену операции в виде отдельной операции. Обычно в кассовых системах так и делается — выбивается отдельный чек на возврат денег, если отменяется продажа.
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
G>>1) у проводки нету ссылки на склад, только на товар, значит чтобы отличать на какой склад пришел товар записи о товарах должны быть разными. G>>То есть кроссовки на складе 1 это не кроссовки на складе 2. И как тут обороты по всем кроссовкам получить? А.М>Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах.
Нарисуйка er диаграмму, поймешь что все свойства товара должны быть в "метатоваре", а сам товар будет иметь ссылку на склад.
G>>2)Остаток хранится прямо в проводке, это значит при изменении проводки, которая была раньше надо пересчитывать все идущие после нее А.М>Остаток можно хранить в товаре
Нельзя. Нужно за периоды иметь остатки и обороты.
А.М>но его придется пересчитывать в любом случае, где бы он не хранился.
Да, только в твоем случае надо будет пересчитывать все остатки после даты изменения, а это мягко говоря дохорена окажется.
А.М>Можно конечно и не хранить,но тогда придется все время пересчитывать, чтобы узнать остатки.
Можно заставить БД пересчитывать, а самому не париться, но при этом не получится "доменная модель" как ты её описал.
G>>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной. А.М>Добавляем класс/таблицу "Накладная" и ссылки на "проводки".
Именно так получаются самые ужасные бухгалтерские программы — добавлением таблиц на каждую необходимость.
G>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход.
И как эти псевдоотгрузки отличать от обычных отгрузок?
А.М>Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты.
Сделай бухгалтерию на нереляционной БД, мы посмотрим.
Re[5]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, А.М, Вы писали:
А.М>>Здравствуйте, gandjustas, Вы писали:
А.М>>Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах. G>Нарисуйка er диаграмму, поймешь что все свойства товара должны быть в "метатоваре", а сам товар будет иметь ссылку на склад.
Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим.
А.М>>но его придется пересчитывать в любом случае, где бы он не хранился. G>Да, только в твоем случае надо будет пересчитывать все остатки после даты изменения, а это мягко говоря дохорена окажется. А.М>>Можно конечно и не хранить,но тогда придется все время пересчитывать, чтобы узнать остатки. G>Можно заставить БД пересчитывать, а самому не париться, но при этом не получится "доменная модель" как ты её описал.
Но таки пересчитывать придется в любом случае, и мне кажется получение остатков более частая операция чем исправление проводки
сделанной в прошлом году.
G>>>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной. А.М>>Добавляем класс/таблицу "Накладная" и ссылки на "проводки". G>Именно так получаются самые ужасные бухгалтерские программы — добавлением таблиц на каждую необходимость.
А вы что предлагаете? Если необходимость есть, надо добавлять, нет -- не добавлять. Или вы предпочитаете модель водопада?
G>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>И как эти псевдоотгрузки отличать от обычных отгрузок?
По значению поля "Кому отгружаем".
А.М>>Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты. G>Сделай бухгалтерию на нереляционной БД, мы посмотрим.
Почему нет? NoSQL пока может еще и сыроваты, но прогресс не стоит на месте.
Re[6]: Задачка: модель данных для склада с версионностью
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, А.М, Вы писали:
А.М>>>Здравствуйте, gandjustas, Вы писали:
А.М>>>Тут ты прав, надо добавить "метатовар" кроссовки, который будет ссылаться на кроссовки на разных складах. G>>Нарисуйка er диаграмму, поймешь что все свойства товара должны быть в "метатоваре", а сам товар будет иметь ссылку на склад. А.М>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим.
И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель".
А.М>>>но его придется пересчитывать в любом случае, где бы он не хранился. G>>Да, только в твоем случае надо будет пересчитывать все остатки после даты изменения, а это мягко говоря дохорена окажется. А.М>>>Можно конечно и не хранить,но тогда придется все время пересчитывать, чтобы узнать остатки. G>>Можно заставить БД пересчитывать, а самому не париться, но при этом не получится "доменная модель" как ты её описал. А.М>Но таки пересчитывать придется в любом случае, и мне кажется получение остатков более частая операция чем исправление проводки А.М>сделанной в прошлом году.
Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго.
G>>>>3)Оприходование товара обычно осуществляется разнородными партиями по накладной, рано или поздно захотят посмотреть что же было оприходовано по конкретной накладной. А.М>>>Добавляем класс/таблицу "Накладная" и ссылки на "проводки". G>>Именно так получаются самые ужасные бухгалтерские программы — добавлением таблиц на каждую необходимость. А.М>А вы что предлагаете?
Я предлагаю не плодить сложность.
А.М>Если необходимость есть, надо добавлять, нет -- не добавлять.
А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения.
Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом.
А.М>Или вы предпочитаете модель водопада?
А причем тут водопада?
G>>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>По значению поля "Кому отгружаем".
Про частные случаи написал выше.
А.М>>>Реляционные БД -- это только один из способов хранить данные. Есть и другие варианты. G>>Сделай бухгалтерию на нереляционной БД, мы посмотрим. А.М>Почему нет? NoSQL пока может еще и сыроваты, но прогресс не стоит на месте.
Ты поверил в "серебряную пулю NoSQL" ?
Лучше изучай Olap — больше пользы будет.
Задачи учета — это чаще всего задачи многомерного анализа данных. По сути есть две категории атрибутов "меры" (measure) и "измерения" (dimensions).
Меры — это остатки и обороты (может быть как в "деньгах", так и в "количестве"), измерения — все остальное — периоды времени, бухгалтерские счета, документы, контрагенты, товары, категории товаров (может быть иерархические), склады... продолжать можно долго.
Например бухгалтерский баланс — выборка мер по определенным измерениям с агрегацией по ним за период (квартал).
Если заранее не предусмотреть единую схему для измерений, то сложность сопровождения будет расти геометрически от количества измерений. А если еще вводить частные случаи, то агрегация данных по измерениям станет проблематичной.
Всего возможных выборок будет 2^N по количеству измерений. С реляционными субд проще, там можно генерить запросы с нужными выборками, но в РСУБД медленно делается агрегация. Для оптимизации можно делать агрегацию по некоторым измерениям заранее.
Для NoSQL решения, где нельзя сделать произвольную выборку, придется ручками запихивать все выборки.
А в идеале всю эту работу надо возложить на умный Olap.
Re[7]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
... << RSDN@Home 1.2.0 alpha 4 rev. 1474 on Windows 7 6.1.7600.0>>
Здравствуйте, gandjustas, Вы писали:
А.М>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим. G>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель".
Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще.
G>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго.
В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет.
А.М>>Если необходимость есть, надо добавлять, нет -- не добавлять. G>А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения. G>Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом.
Не нравится название "накладная", можно назвать "складская транзакция" из которой уже и будут создаваться документы. Но если ее не создавать, то по какому признаку вы предлагаете выбирать проводки для конкретной накладной, по дате?
А.М>>Или вы предпочитаете модель водопада? G>А причем тут водопада?
Из ваших слов я понял что вы предлагаете изменения в систему после этапа проектирования не вносить. Это модель водопада, хотя в большинстве случаев итеративный подход удобнее.
G>>>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>>По значению поля "Кому отгружаем". G>Про частные случаи написал выше.
А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность?
G>Задачи учета — это чаще всего задачи многомерного анализа данных. По сути есть две категории атрибутов "меры" (measure) и "измерения" (dimensions).
Нет, задача учета -- это именно задача учета, то-есть сохранения информации (в данном случае о движении товара). А задача анализа -- это задача обработки имеющихся данных без их модификации. Тут речь идет именно об учете, а потом берем таблицу проводок и анализируем вдоль и поперек, получаем статистику, генерируем документы и т.д.
G>А в идеале всю эту работу надо возложить на умный Olap.
Вот анализ можно и на умный Olap возложить например, если объемы и сложность анализа этого потребуют.
Re[3]: Задачка: модель данных для склада с версионностью
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
AVK>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
Я тоже так считаю, но топикстартер указал что надо ограничить объем базы, поэтому надо как-то выкручиваться.
Хотя я сделал пример, получилось чуть больше гига на 10 миллионов проводок, вместе с индексированными вьюхами. На SQL Server 2008r2 express, с 10 гб базой хватит на очень долго.
Re[4]: Задачка: модель данных для склада с версионностью
Здравствуйте, gandjustas, Вы писали:
G>>>В любом случае надо иметь записи об остатках на начало периода (поля в той же таблице проводок, возможно помеченные флагом). Регулярно агрегировать данные, которые выходят за пределы периода и записывать их в остатки на начало.
AVK>>В некоторых случаях (на небольшом количестве записей) проще не заниматься агрегацией остатков и оборотов, а рассчитывать их на основании исходных или слегка подготовленных данных. Избавление от всяких точек актуальности в OLTP это большой плюс.
G>Я тоже так считаю
Хм, как тогда понимать выделенное?
G>, но топикстартер указал что надо ограничить объем базы, поэтому надо как-то выкручиваться.
Не понимаю. Зачем для ограничения объема базы добавлять агрегаты? Результат то будет прямо противоположный, срезы по проводкам нередко имеют размер, сходный с размером самих проводок.
... << RSDN@Home 1.2.0 alpha 4 rev. 1474 on Windows 7 6.1.7600.0>>
Здравствуйте, А.М, Вы писали:
А.М>Здравствуйте, gandjustas, Вы писали:
А.М>>>Да. И если говорить про таблицы, то это будет промежуточная таблица "Склад-Товар" обеспечивающая отношение многие ко многим. G>>И зачем промежуточную таблицу держать, если ссылку на склад можно поместить в проводку. И получить в унифицировнанном виде "склад источник" и "склад получатель". А.М>Унификация тут не получается, потому что в общем случае источник и получатель -- это не всегда склад. Зато в случае, если надо указать кроме склада еще, допустим, сектор в котором хранится этот товар, это будет сделать проще.
Получается унификация, если подходить не с точки зрения "доменной модели", а с точки зрения многомерного анализа (читай бухучета).
G>>Ты не путай пересчет, который выполняет база (эффективно и надежно) и пересчет, который пишет человек в коде (медленно и чревато ошибками). Я предлагаю первый вариант, а ты почему-то придерживаешься второго. А.М>В данном случае весь пересчет заключается лишь в сложении двух чисел. Тут конечно тоже можно умудриться сделать медленно и с ошибками, но с таким подходом никакая база не поможет.
Поможет, потому что база задает пересчет декларативно. Ты просто пишешь запрос, который агрегирует данные за период и с помощью пары магических движений получаешь материализованную вьюху. После этого сама база заботится о сложении чисел.
А.М>>>Если необходимость есть, надо добавлять, нет -- не добавлять. G>>А вот тут ты неправ. Например накладные нужны в случае отгрузки товара, а для случаев инвентаризации и переучета никаких накладных не будет, будут другие документы. А ты кроме количества разных сущностей еще и плодишь частные случаи, что в совокупности создает геометрический рост сложности решения. G>>Самое неприятное типы документов меняются быстрее чем средний программист успевает из реализовывать с твоим подходом. А.М>Не нравится название "накладная", можно назвать "складская транзакция" из которой уже и будут создаваться документы. Но если ее не создавать, то по какому признаку вы предлагаете выбирать проводки для конкретной накладной, по дате?
Ты застрял в "доменной модели". Не в названиях дело, а в способах работы и представления в БД.
А.М>>>Или вы предпочитаете модель водопада? G>>А причем тут водопада? А.М>Из ваших слов я понял что вы предлагаете изменения в систему после этапа проектирования не вносить. Это модель водопада, хотя в большинстве случаев итеративный подход удобнее.
G>>>>>>4)Как в твоей схеме будут учитываться списания и недоимки, выявленные после переучета? Движения товара нет, а списания есть. А.М>>>>>Списания и недоимка как псевдоотгрузка, начальное состояние первой проводкой как псевдоприход. G>>>>И как эти псевдоотгрузки отличать от обычных отгрузок? А.М>>>По значению поля "Кому отгружаем". G>>Про частные случаи написал выше. А.М>А можно конкретнее? Как добавление такого вида (направления) отгрузки как "списание" геометрически увеличивает сложность?
Например у тебя есть N выборок, которые анализируют отгрузки, при появлении частного случая (псевдоотргузка) надо поменять все или почти все запросы. При этом еще добавится K запросов для этого частного случая. Если появляется еще один частный случай в этой же плоскости, то надо будет менять часть из N+K запросов и добавить еще M, которые при появлении следующего частного случая...
G>>Задачи учета — это чаще всего задачи многомерного анализа данных. По сути есть две категории атрибутов "меры" (measure) и "измерения" (dimensions). А.М>Нет, задача учета -- это именно задача учета, то-есть сохранения информации (в данном случае о движении товара). А задача анализа -- это задача обработки имеющихся данных без их модификации. Тут речь идет именно об учете, а потом берем таблицу проводок и анализируем вдоль и поперек, получаем статистику, генерируем документы и т.д.
Ну сложность кода анализа будет напрямую зависеть от построения схемы данных.
При этом сама суть учета меняется медленно, 500 лет до нашей эры придумали двойную бухгалтерскую запись и живет она до сих пор, а вот анализ меняется очень быстро, вчера нужно было только баланс, а сегодня — определять потребительскую корзину и строить план закупок.
