|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
Подскажите пожалуйста, в какую сторону копать и что почитать? Много лет работает система расчета управленческого учета. Начиналось все с простого: "а сделай-ка нам, чтобы считалось вот так: ..." Вкратце работает все так: - есть таблицы фактов (отгрузки продукции), разбитых по годам. В каждой примерно по 10млн записей. - приходит табличка с расходами на клиентов. Например, на клиента Иванова в октябре 2012г было потрачено 100тыс.руб (реклама, подарки, связь и т.п.). А на Петрова в апреле того же года всего 1тыс.руб. Или на продукцию группы "А" Московского региона было истрачено 1млн.руб. В этой таблице примерно 100тыс.записей. - глядя на факты, нужно распределить расходы пропорционально отгрузкам. Сейчас фактически все факты за всю историю сливаются в одну мега-таблицу, в которой потом распределяются расходы пропорционально отгрузкам. Например, в таблице расходов есть строка (грубо): "март, 2012. Продукция группы "А" Московского региона. 1млн.руб." Т.е. мы отбираем в фактах отгрузки за март 2012г продукцию группы "А". И распределяем этот миллион на всех отобранных клиентов. Чем больше у него была отгрузка этой продукции в марте, тем бОльшая сумма на него "вешается". Считается все это от 4 часов до суток и даже больше. Очень сильно кажется, что процесс организован не очень правильно. Где бы почитать, как это все правильно реализуется? Гуголь выдает только общие тексты по типу школьных рефератов: "управленческий учет нужен для.... Он помогает решить....... С помощью него можно......." Модератор: Тема перенесена из форума "Microsoft SQL Server". ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 16:48 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987, читайте про финансовый учет или про бухгалтерский. только не наш, а западный. если вопросы больше технического плана - Adempiere or iDempiere и смотрим как там реализовано. там все достаточно просто и в то же время грамотно. то, что у вас - это не управленческий учет, а ужас, летящий на крыльях ночи стандартная картина для самописок а процесс организован неправильно не из-за 4 часов могу поспорить на ящик кваса, что путем несложных манипуляций некоторая часть сотрудников может "округлить" в свою сторону показатели, и это сейчас никто не отслеживает ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 17:12 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
интересно, какое отношение к обсуждаемому вопросу имеет какая-то " Adempiere or iDempiere ", это что уже стало образцом технической реализации? Тем более "самописка", если уж говорите о стандартной картине ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 17:47 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987, вопрос относится к организации на уровне используемой СУБД, непонятно почему модераторы перенесли его из профильной для таких вопросов ветки. Или используется не MS SQL? Чтобы на такие вопросы были ответы приведите хоть немного информации о структуре приложения и БД: какие основные таблицы, как организован описываемый процесс распределения... и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 17:52 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmинтересно, какое отношение к обсуждаемому вопросу имеет какая-то " Adempiere or iDempiere ", это что уже стало образцом технической реализации? Тем более "самописка", если уж говорите о стандартной картине там все сделано достаточно похоже на оебс, а он в свою очередь похож на большинство других систем (в части GL) то есть фактически такое решение (с некоторыми вариациями) является стандартом де-факто для финансового учета и я не знаю других возможностей легко посмотреть пример нормальной реализации учета ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 18:05 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
s_ustinoviscrafmинтересно, какое отношение к обсуждаемому вопросу имеет какая-то " Adempiere or iDempiere ", это что уже стало образцом технической реализации? Тем более "самописка", если уж говорите о стандартной картине там все сделано достаточно похоже на оебс, а он в свою очередь похож на большинство других систем (в части GL) то есть фактически такое решение (с некоторыми вариациями) является стандартом де-факто для финансового учета и я не знаю других возможностей легко посмотреть пример нормальной реализации учета как можно назвать нормальной то, с чем постоянные мучения у пользователей и десятилетние внедрения... У ТС, судя по всему, банальные проблемы с организацией БД и расчета распределения ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 18:19 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmкак можно назвать нормальной то, с чем постоянные мучения у пользователей и десятилетние внедрения... У ТС, судя по всему, банальные проблемы с организацией БД и расчета распределения когда "блондинко" рассказывает всем, что у них плохой админ, так как сделал так, что "такие прикольные програмки из интернета больше не ставятся" - вы ей поверите? :)) а банальные проблемы с организацией БД как раз и возникают, когда люди начинают придумывать велосипед в области методологии учета и схемы базы, вместо того, чтобы воспользоваться готовыми проверенными решениями. я говорю не про те случаи, когда человек ПОНИМАЕТ, как работает обычный функционал, и знает, как его можно улучшить (изменить) для его целей. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 19:03 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
s_ustinoviscrafmкак можно назвать нормальной то, с чем постоянные мучения у пользователей и десятилетние внедрения... У ТС, судя по всему, банальные проблемы с организацией БД и расчета распределения когда "блондинко" рассказывает всем, что у них плохой админ, так как сделал так, что "такие прикольные програмки из интернета больше не ставятся" - вы ей поверите? :)) а банальные проблемы с организацией БД как раз и возникают, когда люди начинают придумывать велосипед в области методологии учета и схемы базы, вместо того, чтобы воспользоваться готовыми проверенными решениями. я говорю не про те случаи, когда человек ПОНИМАЕТ, как работает обычный функционал, и знает, как его можно улучшить (изменить) для его целей. я конечно может и "блондинко" по Вашему, но образованная в плане организации учета "блондинко" :) А придумывают различные схемы БД по банальной причине: если нужно решить конкретную задачу, то нужно решать эту конкретную задачу, а не тянуть кладовку со всякой рухлядью на "всякий пожарный". Вспомнил случай, по случаю, когда для того, чтобы типа "правильно" посчитать накладные расходы на закупку организовывалось распределение в зависимости от объема, веса и еще множества параметров. При этом товар, в принципе, однотипный. В результате получилась выгода в 1000руб, но на разработку было потрачено 50 000 руб... Мораль всего этого известна давно: не нужно делать лишних движений, которые в результате принесут копейку. И еще добавят возни с учетом. У ТС явно проблема с БД и организацией расчета. Т.е. от этого и нужно исходить, прежде всего, а не влезать в дебри. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 20:08 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmМораль всего этого известна давно: не нужно делать лишних движений, которые в результате принесут копейку. И еще добавят возни с учетом. У ТС явно проблема с БД и организацией расчета. Т.е. от этого и нужно исходить, прежде всего, а не влезать в дебри. Внимание, вопрос - а были бы у ТС проблемы с базой и организацией расчёта, если бы в его организации не изобретали велосипед, а вырезали бы готовый кусок из более менее нормальной ERP? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 20:20 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
s_ustinoviscrafmМораль всего этого известна давно: не нужно делать лишних движений, которые в результате принесут копейку. И еще добавят возни с учетом. У ТС явно проблема с БД и организацией расчета. Т.е. от этого и нужно исходить, прежде всего, а не влезать в дебри. Внимание, вопрос - а были бы у ТС проблемы с базой и организацией расчёта, если бы в его организации не изобретали велосипед, а вырезали бы готовый кусок из более менее нормальной ERP? возможно. Только скорее всего на более раннем этапе, а не тогда, когда накопилось миллионы записей ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 20:46 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmЧтобы на такие вопросы были ответы приведите хоть немного информации о структуре приложения и БД: какие основные таблицы, как организован описываемый процесс распределения... и т.п. да, реализовано все на MSSQL 2000 структура таблиц примерно такая: - т.фактов ДатаКлиентКодПродукцияКодКол-воВесСумма - справочник клиентов КодНазваниеМенеджерТипКлиента - справочник продукции КодНазваниеВидПродукцииТипПродукции - список разносок ГодМесяцВидПродукцииТипПродукцииМенеджерТипКлиентаКодКлиентаСуммаРасходов В списке разносок ГодМесяц - обязательное поле. Это за какой период начислены расходы (поле СуммаРасходов. Оно тоже обязательное). ВидПродукции, ТипПродукции, Менеджер и др. - необязательные поля. Т.е. какие-то могут быть заполнены, какие-то нет. Например, если заполнен ТипКлиента и ВидПродукции (остальные пустые), то отбираем все отгрузки (все факты) в период ГодМесяц по всем клиентам, имеющим заданный ТипКлиента, и по всей продукции нужного ВидаПродукции. Эти факты копируются в отдельную таблицу примерно такого вида (похожа на т.фактов, плюс поле расходов): ДатаКлиентКодПродукцияКодКол-воВесСуммаСуммаРасходов Допустим, мы отобрали отгрузки за 2012.03.01-2012.03.31 на клиента Иванова, Петрова и Сидорова. И задали расходов на них на 50тыс.руб. Иванов отгрузился на 100тыс.руб Петров на 200тыс.руб а Сидоров на 300тыс.руб Тогда нашу сумму расходов мы распределяем пропорционально их отгрузкам. На Иванова повесим 1/6 часть (8333руб). На Петрова 2/6 (16667руб). И на Сидорова 3/6 (25тыс.руб). для зануд: я знаю, что 2/6 = 1/3, а 3/6 = 1/2 И вот таким образом считаем все 100 тыс. разносок. Почему-то мне кажется, что это не совсем верный подход и можно сделать как-то проще. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 20:56 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
как считаете понятно (все просто), а физически как это организовано? Хранимая процедура? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 21:07 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmХранимая процедура? да ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 21:20 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987iscrafmХранимая процедура? да там в ней случайно перебором в курсоре не выполнятся распределение? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 22:21 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
Почему-то мне кажется, что это не совсем верный подход и можно сделать как-то проще. Мне кажется проще не получится. Если Вы торгуете песком с карьера то распределение затрат пропорционально отгрузкам правильный метод. Но если у Вас разновидность ассортимент превышает скажем больше 20 (скажем 20 брендов) то распределение уже не прямо пропорциональное а должно быть весовое. Но как определить вес бренда. Выход один, указание затрат(расходов) привязанных точно к покупателю. Тогда и распределять ни чего не надо. Если такой возможности нет то выводить эти затраты отдельной статьёй и не смешивать со всем остальным. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 22:33 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmтам в ней случайно перебором в курсоре не выполнятся распределение? нет, не курсором. Там куча сложных запросов, которые вщм-то можно доработать и ускорить. Но проблема не в этом. Суть пересчета разносок - это перезаливание 90% фактов из рабочих т.фактов в одну большую таблицу. Потом там происходят распределения сумм. Вот мне кажется, что перезаливание данные из одних таблиц в одну другую - это как-то не очень правильно. Но что именно там неправильно и как сделать правильно, в голову не приходит. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 22:56 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987, Если у вас нет толкового постановщика - наймите консультанта. Подобные вопросы по фотографии не решаются, т.к. 100% есть масса тонкостей о которых вы или не знаете, или умалчиваете. В общем вам повезет если человек сможет хотя б за месяц грамотно составить ТЗ. Но лично я в этом очень сомневаюсь. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 23:10 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987Суть пересчета разносок - это перезаливание 90% фактов из рабочих т.фактов в одну большую таблицу. Потом там происходят распределения сумм. Вот мне кажется, что перезаливание данные из одних таблиц в одну другую - это как-то не очень правильно. Но что именно там неправильно и как сделать правильно, в голову не приходит. попробуйте разделить эту большую таблицу на секции. Правда MSSQL2000 устарел уже прилично, но такое делали. Поищите в инете по ключу "partitions MS SQL 2000", на этом форуме тоже была информация по этому поводу, как имитировать секции. Т.е. не ворошите всю таблицу при каждом обновлении фактов. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.07.2013, 23:49 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmпопробуйте разделить эту большую таблицу на секции. не-не, я не о том. Вот, например, не правильней ли было бы в рабочие т.фактов добавить поле СуммаРасходов. И вместо Код: sql 1. 2. 3.
выполнять Код: sql 1. 2.
нормально ли копировать 90% фактов из кучи таблиц в другую таблицу, где потом их пересчитывать? Как вообще обычно такие задачи решаются? Я понимаю, что все индивидуально. Но, может, есть какие-то обобщения, что "чаще делают вот так"? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 10:18 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987нормально ли копировать 90% фактов из кучи таблиц в другую таблицу, где потом их пересчитывать? Как вообще обычно такие задачи решаются? Я понимаю, что все индивидуально. Но, может, есть какие-то обобщения, что "чаще делают вот так"? нормально. Это ваше "хранилище", таблицы фактов - "первичные документы". Документы "проводите" (выполняете из них выборку значимых данных и трансформируете в требуемый формат) и в хранилище обрабатываете. На основании данных хранилища строите все отчеты. Так "обычно такие задачи решаются", в целом. Т.е. смотрите что не так в структуре и организации процесса. Такие долгие расчеты по данным за месяц конечно указывают то, что в этом пробой. Говоря о секционировании данных я имел ввиду именно это... Может там индексируется при вставке и т.п. Что из себя представляют факты, их происхождение? Загружаются откуда-то тоже? p.s. вообще вопрос чисто из раздела MS SQL. Нужно просто сразу сказать какая СУБД. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 11:26 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987, все зависит от того, что именно вы дальше с данными делаете. Если не нужна детализация до документа, то надо сначала "сжать" (агрегировать) таблицу продаж, потом "сжать" таблицу расходов, а потом совместить их. Скорее всего результирующая таблица будет не 10 миллионов, а несколько десятков тысяч. И искать надо по ключевым словам "OLAP" и "ETL" - это не учет, а анализ. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 11:28 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
iscrafmТакие долгие расчеты по данным за месяц конечно указывают то, что в этом пробой. Говоря о секционировании данных я имел ввиду именно это... Может там индексируется при вставке и т.п. Что из себя представляют факты, их происхождение? Загружаются откуда-то тоже? p.s. вообще вопрос чисто из раздела MS SQL. Нужно просто сразу сказать какая СУБД. СУБД указал - MSSQL 2000 :) долгие расчеты не за месяц, а за несколько лет. Индексы строятся после вставки всех фактов. s_ustinovнуб987, все зависит от того, что именно вы дальше с данными делаете. Если не нужна детализация до документа, то надо сначала "сжать" (агрегировать) таблицу продаж, потом "сжать" таблицу расходов, а потом совместить их. Скорее всего результирующая таблица будет не 10 миллионов, а несколько десятков тысяч. детализация нужна именно до документа и даже больше - до единицы продукции в накладной. s_ustinovИ искать надо по ключевым словам "OLAP" и "ETL" - это не учет, а анализ. либо я вас не понял, либо еще что-то. Но ведь моя задача - это и не учет, и не анализ. Это расчеты. Но раз такие задачи примерно так и решаются, тогда ладно. Просто казалось не очень правильным лопатить тонны данных. Это примерно как перетащить вручную вагон кирпичей к "вон тому дереву", чтобы потом среди них найти десяток бракованных. А затем всю кучу тащить к другому дереву и там уже строить дом. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 12:10 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
нуб987s_ustinovнуб987, все зависит от того, что именно вы дальше с данными делаете. Если не нужна детализация до документа, то надо сначала "сжать" (агрегировать) таблицу продаж, потом "сжать" таблицу расходов, а потом совместить их. Скорее всего результирующая таблица будет не 10 миллионов, а несколько десятков тысяч. детализация нужна именно до документа и даже больше - до единицы продукции в накладной. если до строки продаж - то делаем еще одну таблицу "ID" "Sales Line ID" "Amount" - то есть привязывать сумму расходов к строке продаж. и в таблице будет столько же строк, как и в таблице продаж. если же надо сохранять информацию и о документе расходов, то тогда надо добавить поле "Document Expenses ID" - и в табличке будет в несколько раз больше строк - то есть сотни миллионов записей нуб987s_ustinovИ искать надо по ключевым словам "OLAP" и "ETL" - это не учет, а анализ. либо я вас не понял, либо еще что-то. Но ведь моя задача - это и не учет, и не анализ. Это расчеты. Но раз такие задачи примерно так и решаются, тогда ладно. Просто казалось не очень правильным лопатить тонны данных. Это примерно как перетащить вручную вагон кирпичей к "вон тому дереву", чтобы потом среди них найти десяток бракованных. А затем всю кучу тащить к другому дереву и там уже строить дом. такие расчеты не должны занимать столько времени. все же 10 миллионов - это не миллиарды. у вас проблемы с алгоритмами. подобные вопросы подробно рассматриваются при обсуждении хранилищ данных и BI olap и тп почитайте про ETL and OLAP - там как раз обсуждаются вещи, которые вы делаете. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 12:30 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
что такое факты? Это собранные, по сути, отчеты о продажах с "точек"? Много ли в них информации, которая не нужна для долгосрочного хранения? 10%, остающейся в этих таблицах, это она? Каким образом материализуется информация в таблицах фактов? и т.д. и т.п. Если вся база и есть это самое "хранилище", а первичная информация генерируется "где-то" и прямого доступа нет, то возможно перенос данных внутри и лишний. Т.е. вариантов на самом деле много, в зависимости от ответов на озвученные вопросы. ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 12:37 |
|
реализация управленческого учета
|
|||
---|---|---|---|
#18+
s_ustinovесли же надо сохранять информацию и о документе расходов, то тогда надо добавить поле "Document Expenses ID" - и в табличке будет в несколько раз больше строк - то есть сотни миллионов записей так.... Т.е. не копировать кучу фактов из 10-ка т.фактов в одну большую, а сделать "справочник привязки": в каждой т.фактов есть поле id на каждую запись, в таблице разносок так же есть поле id. И вместо Код: sql 1. 2. 3.
будет Код: sql 1. 2. 3.
т.е. каждую разноску "разбрасываем" по фактам. Получается, на одном факте может "висеть" несколько разносок. Например, разноска "Расход 50тыр. Менеджер Петров" должна быть раскидана на отгрузки всех клиентов, у которых менеджер Петров. При этом разноска "Расход 100тыр. Продукция Гвозди" так же может распределиться на какие-то отгрузки менеджера Петрова, т.к. части его клиентов могли отгружаться гвозди. Таким образом на одних и тех же фактах будут висеть расходы по менеджеру Петрову и по продукции "Гвозди". И вот когда построили справочник привязки, можно довольно простым update'ом раскидать сумму расходов пропорционально отгрузкам по каждому факту: чем бОльшая сумма отгрузки на факте, тем бОльшая часть привязанных к нему расходов вешается на него. так? ... |
|||
:
Нравится:
Не нравится:
|
|||
09.07.2013, 13:46 |
|
|
start [/forum/moderation_log.php?user_name=Skye]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
49ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
57ms |
get tp. blocked users: |
1ms |
others: | 735ms |
total: | 906ms |
0 / 0 |