Регистры накопления

[optron]

Игорь, а можно и мне, пожалуйста?

Так то у меня попроще реализовано. База приходов - отдельно, база расходов - отдельно.
Период рассчета остатков - месяц. Ежемесячно остатки переводятся на следующий месяц (закрывается период). Бухи привыкли, что в текущем месяце можно менять всё, что угодно, если же изменения затронули предыдущие периоды, то нужно переформировать остатки за те периоды и далее, вплоть до текущего.

Можно, в принципе, делать и текущие остатки, то бишь, изменять их, согласно изменению прихода - расхода или их удаления, но тогда придется вносить много изменений:

1)Переформировывать остатки за все периоды с начала изменения до текущего
2)При удалении и редактировании прихода или расхода обязательно смотреть на остатки на складе - не получим ли отрицательные.

Выловить изменения при редактировании достаточно просто - при открытии формы прихода - расхода запоминаем цену, кол - во, сумму, при нажатии на ОК - проверяем на изменение.
Удалении записи - действительно ищем в апдейте SELF.Request - ом.

Тут, собственно, беда то другая. Текущие остатки формируются недолго и по реализованною как у меня схеме - за текущий период записей не так уж и много и отрабатывается подсчет остатка достаточно быстро. Сложность возникает тогда, когда мы пытаемся вычислить обороты с середины периода А до середины периода Б, разница между которыми весьма существенна, а в моем случае существуют еще и расходы с 0 датой, но у которых существует всё - таки дата ввода расхода, которую нужно учесть в некоторых отчетах. Еще и улавливание внутренних перемещений. Вот тут - тормоза, так как баз в процессе создания отчета участвует много.

Вариантов убыстрения отчета вижу 2 - вернее, вариант один, а способов решения 2:
1) Действительно, как в 1С формировать накопительную базу приходов - расходов - остатков на каждый внесенный приход - расход, перемещение, но тут траблов несколько -
а) к концу года база достигнет внушительных размеров;
б) Склад то не один. в моем случае их пока 78. Число их непостоянно. Может увеличиваться, может уменьшаться. А интерес представляет кроме определения текущих остатков, также остатки, оборот и перемещение по каждому из складов в любые периоды;
с) При внесении изменений в любой приход или расход следует проделать грандиозные изменения в накопительной базе со сверкой с остатками в закрытых периодах;
2) Ставить текущий остаток в таблицу прихода и расхода отдельной позицией, но траблы те же, кроме пункта а).

[kreator]

У меня такая же беда. Нужно видеть остатки не по одной точке, и не на текущую дату, а на любую. Плюс нужна оборотка, плюс движение товара и денег по клиентам за последние 3 года хотя бы. И ещё куча плюсов. Поэтому, изначально, отказался от системы сохранения остатков. А обдумывание вопроса, как хранить некие остатки, по каким адресатам, по каким торговым точкам, на какие даты, заводит меня в тупик.
Недавно мне рассказали приблизительно, как у уважаемой конторы Диасофт организована база АБС. Есть таблица, в которой храниться все проводки (миллиарды записей), и есть промежуточная таблица с остатками по счетам и т.д. Если пользователь сделал запрос на получение оборотки или остатков по счету то, сначала проверяется промежуточная таблица на наличие результатов этого запроса, если не находиться там ничего, то делается честный оборот по реальной таблице и результат записывается в промежуточную таблицу и в следующий раз обращения в основную таблицу уже не будет при таком же запросе. В общем, что-то в этом есть.

[optron]

У меня такая же беда. Нужно видеть остатки не по одной точке, и не на текущую дату, а на любую. Плюс нужна оборотка, плюс движение товара и денег по клиентам за последние 3 года хотя бы. И ещё куча плюсов. Поэтому, изначально, отказался от системы сохранения остатков. А обдумывание вопроса, как хранить некие остатки, по каким адресатам, по каким торговым точкам, на какие даты, заводит меня в тупик.
Недавно мне рассказали приблизительно, как у уважаемой конторы Диасофт организована база АБС. Есть таблица, в которой храниться все проводки (миллиарды записей), и есть промежуточная таблица с остатками по счетам и т.д. Если пользователь сделал запрос на получение оборотки или остатков по счету то, сначала проверяется промежуточная таблица на наличие результатов этого запроса, если не находиться там ничего, то делается честный оборот по реальной таблице и результат записывается в промежуточную таблицу и в следующий раз обращения в основную таблицу уже не будет при таком же запросе. В общем, что-то в этом есть.

Есть что - то, но при изменении любой записи в приходе или расходе все записи в промежуточной таблице, начиная с этой даты придется удалять?

[Игорь Столяров]

В общем, что-то в этом есть.

Годы идут, а Diasoft все юзает старую банковскую идею.
Да, все правильно. Но при одном условии - требуется жесткое и полное закрытие изменений первичных документов за период.
Например как в банке закрывается операционный день. Внести изменение в "вчера" - это большая проблема.
При вскрытии закрытого периода выполняется целый комплекс операций, в т.ч. удаление всех сохраненных
расчетов в т.н. промежуточных таблицах, перерасчет остатков по счетам, балансов и т.д. и т.п.

[kreator]

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

[Игорь Столяров]

непонятно, что нужно будет бухгалтеру или менеджеру по продажам завтра

Тоже верно. Как я написал ранее, здесь вопрос решается через индексированные таблицы оборотов.
Например, мы храним полный оборот (приход/расход) по каждому товару за день по всем накладным и аналогично суммы оборота за день по каждому клиенту.
Соответственно при запросе на остаток на дату - мы можем быстро обработать эту таблицу (максимум 365 записей за год)
и получить остаток товара на любую дату. При более сложном запросе - например оборот товара по конкретному клиенту, мы из этой таблицы
можем получить список дней в которых вообще был оборот нужного товара и список дней в котором были накладные у нужного клиента.
На пересечении множества этих дней - получаем список дат для и обрабатываем первичные документы только за эти дни,
а не тупо весь массив накладных за год и т.д. В принципе, это то что делает оператор SELECT в SQL БД ...

[FinSoft]

Если требуются итоги за произвольный период, а не помесячно, то это уже не бухгалтерия, а оперативный учет. Дробить документы по месячным базам становится неудобно. В свое время этот вопрос подробно анализировался и я пришел к такой схеме, расскажу кратко.
Все складские документы, влияющие на движение товаров на складах, содержатся в 3 таблицах. Первая - шапки документов, вторая - строки документов, третья - архив строк документов. Третья таблица сделана из соображения, что вторая растет довольно быстро, а поддерживать всегда проще небольшие объемы данных. Поэтому в таблице строк обычно держится в пределах 300-500мб, а далее переливаем в архивную таблицу. Оперативная и архивная таблицы всегда открыты и отчеты обе используют. Рано или поздно базу все равно режут по разным причинам, объемы данных остаются всегда в разумных пределах (с запасом лет на 10 работы).
Теперь, наверно, самая тонкая вещь. В складских документах значения даты и времени дублируются в строки. В результате мы получаем готовый ключ по товару, дате и времени, который можем использовать для быстрого отбора всех движений по заданному товару за произвольный период.
В общем случае расчет движений по товару на складе происходит так. Читаем ближайшие к началу запрошенного периода остатки (обычно один previous и один get), затем выбираем по ключу все движения товара с даты, следующей за остатками и по конец периода. Для каждой прочитанной записи подтягиваем соответствующую шапку документа для проверки статуса, склада и т.п. Полностью попадаем в индекс и получаем итог мгновенно. Если запрошен расчет по нескольким товарам, то подобная операция делается для каждого товара из списка. Точнее, если память не изменяет, так делается, когда список товаров не превышает 100, иначе считываем все движения товаров за период от ближайших остатков и фильтруем нужные товары.

[kreator]

Ребята, всё хорошо. Но вот мне надо знать такую информацию:
Период: с 01.06.2010 по 31.05.2013.
Юр. лицо: ЮЛ-1.
Торговая точка: Магазин №1.
Надо знать - остаток на начало периода, на конец периода, приход, расход за период в разрезе юридического лица и торговой точки (в торговой точке товар может принадлежать нескольким юрлицам, одно юрлицо может владеть товаром на нескольких торговых точках).
А следующим шагом, нужно получить ещё разрез - с какого склада была отгрузка, и какое юрлицо отгружало.

[optron]

Ребята, всё хорошо. Но вот мне надо знать такую информацию:
Период: с 01.06.2010 по 31.05.2013.
Юр. лицо: ЮЛ-1.
Торговая точка: Магазин №1.
Надо знать - остаток на начало периода, на конец периода, приход, расход за период в разрезе юридического лица и торговой точки (в торговой точке товар может принадлежать нескольким юрлицам, одно юрлицо может владеть товаром на нескольких торговых точках).
А следующим шагом, нужно получить ещё разрез - с какого склада была отгрузка, и какое юрлицо отгружало.

Я дам Вам парабеллум)))

[optron]

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

[Игорь Столяров]

Надо знать - остаток на начало периода ...

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

Добавляем в этот же список индекс (товар, торговая точка, день) - легко получаем тоже самое по торговой точке.
Добавляем в этот же список индекс (товар, предприятие, день) - легко получаем тоже самое по предприятию.

и т.д. Связь улавливаешь ?

[FinSoft]

Надо знать - остаток на начало периода ...

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

Добавляем в этот же список индекс (товар, торговая точка, день, предприятие) - легко получаем тоже самое по торговой точке.
Добавляем в этот же список индекс (товар, предприятие, день, торговая точка) - легко получаем тоже самое по предприятию.

и т.д. Связь улавливаешь ?

Примерно так. Можно делать таблицу с оборотами за больший или произвольный период. Например, за месяц. Внутри месяца посчитать и так быстро (сейчас компы за секунду десятки тысяч записей обрабатывают).

[kreator]

Да, конечно. Можно придумать промежуточную таблицу с оборотами или остатками, с продвинутой логикой. Но я посчитал, что это трудоёмко и непрозрачно, и отказался от этой затеи. Легче вложится в железо или оптимизировать SQL запросы. Объёмы операций пока позволяют не напрягаться по этому поводу. Но это пока.
А вот Вам ещё повод для обсуждения. В 1С появилась возможность вести учёт товара в разрезе его каких-нибудь свойств. Ну, например, рубашка обязательно должна иметь размер и цвет. Невозможно отпустить рубашку не задав размер и цвет. И остатки рубашек я могу получить в разрезе размера и цвета. Может ничего хитрого и нет, но, говорят, что таблица свойств - это отдельная таблица, т.е. не надо вводить каждый раз информацию о рубашке (6 размеров и 10 цветов - 60 наименований). Как вам?

[Игорь Столяров]

Как вам?

Ну во первых каждая рубашка имеет свой артикул (и штрих-код). И в розничных магазинах давно не замарачиваются
с тем, к чему пришита этикетка с этими данными. Если же говорить о сельских магазинах, где за бедностью у прилавка
стоят товароведы способные квалифицированно (!) определить фасон и цвет изделия легкой промышленности - то
в данном случая мы всего лишь имеем группу товаров "Рубашка" и непосредственно самих товаров в этой группе,
которые наследуют наименование родительской группы и имеют свои некоторые уникальные характеристики
(размер, цвет и т.д.). Вот и все. Учет остатков и данные в чеке (накладной) ведутся по конечному товару.
Другой вопрос в том, что информацию о товаре можно получить только через его группу. Прикольно. Но специфично.

[kreator]

Игорь. Вот мне сказали, что не так. Через дерево (группу) давно всё реализовано. Якобы есть дополнительная таблица для этого. И мне представляется работа через дополнительную таблицу (таблицы) логичной, визуально наглядной. Нежели как-то внутри преобразовывать в группу (или наоборот раскидывать товар внутрь группы).