Посоветуйте, пожалуйста, книги (можно на английском), сайты в нете, вообще любую инфу по проектированию учетных ситем.
Мы тут пытаемся спроектировать очередную учетную систему (с использованием двойной записи), хочется сделать ее максимально гибкой. Очень большие трудности вызывает отражение двойной записи в реляционной модели.
В общем интересует любая теоретическая и практическая информация связанная с автоматизацией финансового учета.
Здравствуйте Willi, Вы писали:
W>Привет, всем.
W>Посоветуйте, пожалуйста, книги (можно на английском), сайты в нете, вообще любую инфу по проектированию учетных ситем.
W>Мы тут пытаемся спроектировать очередную учетную систему (с использованием двойной записи), хочется сделать ее максимально гибкой. Очень большие трудности вызывает отражение двойной записи в реляционной модели.
А надо? Двойная запись вообще-то, если ее пытаться воспроизвести в ERD, создаст нечто вроде денормализации с дополнительным ограничением целостности, то есть, от чего стоит избавляться.
W>В общем интересует любая теоретическая и практическая информация связанная с автоматизацией финансового учета.
А Баркера вы уже читали?
Он основоположник, один из авторов метода описания сущность-связь. В книжках его я видел разные шаблонные подходы к созданию реляционных моделей (можно сказать — паттерны). Книжки его я видел на тырнете в электронном виде, но с ходу сейчас найти не могу.
Здравствуйте George_Seryakov, мы писали:
GS>А Баркера вы уже читали?
GS>Он основоположник, один из авторов метода описания сущность-связь. В книжках его я видел разные шаблонные подходы к созданию реляционных моделей (можно сказать — паттерны). Книжки его я видел на тырнете в электронном виде, но с ходу сейчас найти не могу.
Здравствуйте George_Seryakov, Вы писали:
GS>Здравствуйте George_Seryakov, мы писали:
GS>>А Баркера вы уже читали?
GS>>Он основоположник, один из авторов метода описания сущность-связь. В книжках его я видел разные шаблонные подходы к созданию реляционных моделей (можно сказать — паттерны). Книжки его я видел на тырнете в электронном виде, но с ходу сейчас найти не могу.
GS>ftp://ftp.opennet.ru/pub/docs/casemeth.zip
Спасибо огромное.
Я так понимаю он пишет о проектировании вообще?
Ну а что ни будь более тесно связанное с учетными системами можешь посоветовать?
Здравствуйте Willi, Вы писали:
GS>>>А Баркера вы уже читали? GS>>ftp://ftp.opennet.ru/pub/docs/casemeth.zip
W>Спасибо огромное.
W>Я так понимаю он пишет о проектировании вообще?
И вообще и, местами, в частности. Чем и интересен.
W>Ну а что ни будь более тесно связанное с учетными системами можешь посоветовать?
Например, покопаться в моделях Oracle Financial. Или еще у IBM была модель банковской деятельности. Посмотреть, как они там двойную запись поддерживают.
Здравствуйте George_Seryakov, Вы писали:
GS>Например, покопаться в моделях Oracle Financial. Или еще у IBM была модель банковской деятельности. Посмотреть, как они там двойную запись поддерживают.
Для меня тема это почти что жизненная :). Если Oracle Financial я еще могу найти то может быть вы могли сузить мне немного рамку поиска по поводу модели IBM? :???:
Здравствуйте Tiger, Вы писали:
T>Здравствуйте George_Seryakov, Вы писали:
GS>>Например, покопаться в моделях Oracle Financial. Или еще у IBM была модель банковской деятельности. Посмотреть, как они там двойную запись поддерживают.
T>Для меня тема это почти что жизненная :). Если Oracle Financial я еще могу найти то может быть вы могли сузить мне немного рамку поиска по поводу модели IBM? :???:
Эта штука, если я не ошибаюсь, называется Financial Services Data Model. Помню, когда я работал банковским технологом в Сбере, IBM-ы пытались продать нам ее. Сначала дали совершенно бесплатно некое подмножество этой модели, так, тысячи три квадратиков. Полная модель стоила десятки тысяч(?)... Или сотни? Десяток старушек — рупь, но надо же и честь знать. Зампредам на мерсы не хватает!
На самом деле я не советую лезть в OF и FSDM, хотя ответы там, безусловно, содержатся. Внимательное чтение Баркера с последующим размышлением может дать куда больше.
Здравствуйте George_Seryakov, Вы писали:
GS>А надо? Двойная запись вообще-то, если ее пытаться воспроизвести в ERD, создаст нечто вроде денормализации с дополнительным ограничением целостности, то есть, от чего стоит избавляться.
Это с чего же "Двойная запись ...создаст нечто вроде денормализации"?
Делаем тупо...
Таблица проводок (Tran)
ID_Tran ID_BbAcct ID_CrAcct TranDate TranSum TranComment
-------------------------------------------------------------------
1 51 50 01.01.2001 2000 Взнос денег из кассы на р.с.
2 50 62 02.01.2001 200 Оплпта по договору наличными.
И где здесь денормализация?
Если заменить бух. счета на некоторые аналитические регистры, то можно добиться очень тонкого аналитического учета...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте George_Seryakov, Вы писали:
GS>>А надо? Двойная запись вообще-то, если ее пытаться воспроизвести в ERD, создаст нечто вроде денормализации с дополнительным ограничением целостности, то есть, от чего стоит избавляться.
VD>Это с чего же "Двойная запись ...создаст нечто вроде денормализации"?
VD>Делаем тупо... VD>
VD>Таблица проводок (Tran)
VD>ID_Tran ID_BbAcct ID_CrAcct TranDate TranSum TranComment
VD>-------------------------------------------------------------------
VD> 1 51 50 01.01.2001 2000 Взнос денег из кассы на р.с.
VD> 2 50 62 02.01.2001 200 Оплпта по договору наличными.
VD>
VD>И где здесь денормализация?
Э, нет. Сначала расскажи, где здесь двойная запись.
Здравствуйте George_Seryakov, Вы писали:
VD>>Таблица проводок (Tran) VD>>И где здесь денормализация?
GS>Э, нет. Сначала расскажи, где здесь двойная запись.
Эх, бюстгалтерия............................
Где моя молодость... Читаю топик и плакаю... дебит... кредит... читаю и плакаю... а ведь аналитику по уму я так и не доделал... читаю и плакаю... но зато язычок встроенный мы таки забацали, на C++ очент похож, пи-код, панимаишь, не то что щас всякие там скрип-инжины... читаю и плакаю...
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте George_Seryakov, Вы писали:
VD>>И где здесь денормализация?
GS>Э, нет. Сначала расскажи, где здесь двойная запись.
А что не так? Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого. Имхо это оно и есть. Просвети если не так, пожалуйста.
Здравствуйте alexm1202, Вы писали:
A>Здравствуйте George_Seryakov, Вы писали:
VD>>>И где здесь денормализация?
GS>>Э, нет. Сначала расскажи, где здесь двойная запись.
A>А что не так? Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого. Имхо это оно и есть. Просвети если не так, пожалуйста.
Покажи мне тогда записи по одному счету и по другому, и где там будет хозоперация, отраженная и там и там в одной и той же сумме.
Итальянцы, которые так придумали делать, писали разные счета на разных листочках, и если один счет (листочек книги) оказывался испорчен (съел сквишъ), то его возможно было восстановить по остальным счетам.
A>BR, Alex.
Здравствуйте George_Seryakov, Вы писали:
GS>>>Э, нет. Сначала расскажи, где здесь двойная запись.
A>>А что не так? Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого. Имхо это оно и есть. Просвети если не так, пожалуйста.
GS>Покажи мне тогда записи по одному счету и по другому, и где там будет хозоперация, отраженная и там и там в одной и той же сумме.
А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
GS>Итальянцы, которые так придумали делать, писали разные счета на разных листочках, и если один счет (листочек книги) оказывался испорчен (съел сквишъ), то его возможно было восстановить по остальным счетам.
И что ты предлагаешь? Завести под каждый счет отдельную табличку на случай утраты данных?
Все это прекрасно, но как говориться в анектдоте — Есть ньюанс!!!!
Во первых товарищь из зала ;) весьма верно подметил про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики. Дальше хуже. (Ну уж я не говорю о тяжеловестности запросов, в смысле оптимальности выполнения и тяжести создания запросов). А вот то-что количество аналитик оказывается жестко фиксированным это плохо, так как по некоторым сведениям если организация начинает наращивать количество аналитик по счетам то их возрастание происходит экспоненцияльно!!!. А писать динамические запросы которые позволят вам менять количество аналитик это получается такоооооой изврат, что самому тошно становиться. Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в классическом варианте плоского журнала проводок. Но вот какой — сие есть тайна!!! По крайне мере пока. Это и заставляет искать хоть что-то (любую информацию). И кстати!!! Еще есть проблема откатов и удалений из журнала проводок. Воооот проблемка. мне начинет казатся, что здесь уже начинает играть роль фундаментальные ограничения баз данных — то что кортежи (записи) должны быть взаимонезависимы. А если мы хотим изменить историю проводок задним числом то получаем что у нес "поедет" все последующая история. За сим "поедет" крыша у кое-кого (програмиста, бухгальера, начальника — по вкусу выбрать :) а также "поедут" доходы в виде зарплат огромных в вечнозеленых единицах и проча, и проча..., и проча... :(. Так что кто чем может просьба помочь (чуть не добавил не корости ради а токому любопытства для!!!) :crash:
Здравствуйте IT, Вы писали:
IT>Здравствуйте George_Seryakov, Вы писали:
IT>Эх, бюстгалтерия............................ IT>Где моя молодость... Читаю топик и плакаю... дебит... кредит... читаю и плакаю... а ведь аналитику по уму я так и не доделал... читаю и плакаю... но зато язычок встроенный мы таки забацали, на C++ очент похож, пи-код, панимаишь, не то что щас всякие там скрип-инжины... читаю и плакаю... IT>
Пять баллов IT !!!
Я и сам не верил что жизнь заставит меня вернуться к этой теме. В свое время так рад был с нее спрыгнуть. Но... никогда не знаешь, где найдешь, где потеряешь.
Здравствуйте alexm1202, Вы писали:
GS>>Покажи мне тогда записи по одному счету и по другому, и где там будет хозоперация, отраженная и там и там в одной и той же сумме.
A>А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>BR, Alex.
Здравствуйте George_Seryakov, Вы писали:
GS>Итальянцы, которые так придумали делать, писали разные счета на разных листочках, и если один счет (листочек книги) оказывался испорчен (съел сквишъ), то его возможно было восстановить по остальным счетам.
Ну, так потому и славятся одними мафиозями.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте George_Seryakov, Вы писали:
A>>А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
GS>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
Не, ну если ты систему эмулящии рабовлодельчиского строя создаешь, то ... Или я до твоей философии недотягиваю.
PS
Мы еще в 1996 г. спроектировали ядро которое позволяло учитывать любые данные на предприятии и центральная таблица прободок была очень похожа на ту которую я приводил (ну, по шире..., ну, по ядренее, ну, счета не напрямую тауда заволились). Короче, чувствую у понутнов доводы кончились... Переходят на философию.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Tiger, Вы писали:
T>Все это прекрасно, но как говориться в анектдоте — Есть ньюанс!!!! T>Во первых товарищь из зала ;) весьма верно подметил про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики. Дальше хуже. (Ну уж я не говорю о тяжеловестности запросов, в смысле оптимальности выполнения и тяжести создания запросов). А вот то-что количество аналитик оказывается жестко фиксированным это плохо, так как по некоторым сведениям если организация начинает наращивать количество аналитик по счетам то их возрастание происходит экспоненцияльно!!!. А писать динамические запросы которые позволят вам менять количество аналитик это получается такоооооой изврат, что самому тошно становиться. Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в классическом варианте плоского журнала проводок. Но вот какой — сие есть тайна!!! По крайне мере пока. Это и заставляет искать хоть что-то (любую информацию). И кстати!!! Еще есть проблема откатов и удалений из журнала проводок. Воооот проблемка. мне начинет казатся, что здесь уже начинает играть роль фундаментальные ограничения баз данных — то что кортежи (записи) должны быть взаимонезависимы. А если мы хотим изменить историю проводок задним числом то получаем что у нес "поедет" все последующая история. За сим "поедет" крыша у кое-кого (програмиста, бухгальера, начальника — по вкусу выбрать :) а также "поедут" доходы в виде зарплат огромных в вечнозеленых единицах и проча, и проча..., и проча... :(. Так что кто чем может просьба помочь (чуть не добавил не корости ради а токому любопытства для!!!) :crash:
Ну, весь этот стон души от недостатка в опыта проектирования. Реляционные БД конечно не венец творения, но и на них можно многое сделать если мозгами покумекать.
Я так понимаю у тебя главное непонимание в том как в приведенном варианте аналитику считать. Да? Тогда продаю часть своих идей образца 1996 года...
Анализируем ошибки... Хотя зачем? Ты и так все верно подметил. Но (!) почему ты считаешь, что аналитические признаки должны быть отделены от дебета и кредита?
Это главная твоя ошибка и большинство ваятелей бухгалтерий (ну, и КИС). Бьюсь об заклад, что смогу переформулировать любую постановку задачи, так чтобы в проводке были только дебетовые и кредитовые аналитические признаки! (подсказка: обычно это делается добавлением промежуточных проводок).
Теперь просто воспользуемся опытом и знаниями из умных книжек... Применим принцип денормализации и получим не одну убогую таблицу, а две (и не убогие). Первая описана выше, но вместо дебетового и кредитового счета введем понятие дебетового и кредитового аналитического признака. В 1996 я назвал их Z-объектами (почему Z? Об этом я скажу потом...). Вторая таблица содержит эти самые аналитические Z-объекты (и их атрибуты).
Z-объект – это минимальный аналитический признак на котором можно подбить микро-баланс, т.е. все операции (проводки) по такому объекту рано или поздно в сумме дадут нуль (от сюда и Z-объект). Так как меньше этой операции в системе не регистрируется, то можно смело оставить в проводке только дебетовый и кредитовый Z-объект. Зато на Z-объекты можно навесить аналитику любого уровня сложности. Самым универсальным способом будет добавить еще одну таблицу которая содержит ссылку на Z-объект и список справочных значений. Примерами Z-объектом могут быть: заказ, расчетный счет (или некоторый минимальный признак на этом счет, если ведется аналитика по р.с.), авансовый отчет и много другое.
Ниже приведена упрощенная ER-схема БД реализующей описанные выше принципы. ftp://ftp.optim.ru/pub/Tests/ZObj/shem1.GIF
Tran – таблица проводок.
ZObj – Z-объекты. (Tran имеет две ссылки на ZObj, так как Z-объекты проходят и по дебету и по кредиту проводки... шо поделаешь та самая двойная запись ;) ).
ZObjType – типы Z-объектов.
Ref – справочники. Здесь представлено упрощенно. Реально это отдельная песня (считайте, что вместо этой таблицы присутствует крутая структура хранящая все справочники учетной системы, а это их инкапсулированное представление).
ExtRef – список дополнительных аналитических признаков. Может быть любой длинны. В реальной учетной системе нужно описать какие и сколько справочных значений можно присвоить к Z-объекту каждого типа.
У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
Если кому интересно, то пишите мы открыты для сотрудничества.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Если нам не помогут, то мы тоже никого не пощадим.
