Посоветуйте, пожалуйста, книги (можно на английском), сайты в нете, вообще любую инфу по проектированию учетных ситем.
Мы тут пытаемся спроектировать очередную учетную систему (с использованием двойной записи), хочется сделать ее максимально гибкой. Очень большие трудности вызывает отражение двойной записи в реляционной модели.
В общем интересует любая теоретическая и практическая информация связанная с автоматизацией финансового учета.
Здравствуйте 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
Если кому интересно, то пишите мы открыты для сотрудничества.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
Влад, у тебя же там ничего про веб-сервисы. В сад... и срочно затачивать концепцию под веб-сервисы
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте George_Seryakov, Вы писали:
A>>А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
GS>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
Здравствуйте Tiger, Вы писали:
T>ЭЭЭЭЭЭЭЭЭЭЭ!!!!! Господа шорошие Олл!!!!
Ты чего орешь? К чему столько эмоций?
T>Во первых товарищь из зала весьма верно подметил про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики.
А тебе не кажется, что путем дальнейшей нормализации такую таблицу можно привести к набору таблиц, выглядещему более элегантно? Кроме того тут тебе параллельно предлагают тоже очень неплохое решение (вынесение аналитики в план счетов).
T>Дальше хуже. (Ну уж я не говорю о тяжеловестности запросов, в смысле оптимальности выполнения и тяжести создания запросов). А вот то-что количество аналитик оказывается жестко фиксированным это плохо, так как по некоторым сведениям если организация начинает наращивать количество аналитик по счетам то их возрастание происходит экспоненцияльно!!!.
Не должно быть оно фиксированным, оно должно изменяться в ходе работы с системой.
T>А писать динамические запросы которые позволят вам менять количество аналитик это получается такоооооой изврат, что самому тошно становиться.
Поясни, что ты имеешь в виду?
T>Есть некое шестое^2 чувство что просто структура таблиц должна быть совсем не такой как в классическом варианте плоского журнала проводок. Но вот какой — сие есть тайна!!! По крайне мере пока. Это и заставляет искать хоть что-то (любую информацию).
Может быть, стоит начать с Дейта? Или чего-нибудь подобного?
T>И кстати!!! Еще есть проблема откатов и удалений из журнала проводок. Воооот проблемка. мне начинет казатся, что здесь уже начинает играть роль фундаментальные ограничения баз данных — то что кортежи (записи) должны быть взаимонезависимы. А если мы хотим изменить историю проводок задним числом то получаем что у нес "поедет" все последующая история.
Какая история? Куда поедет? Тебе тут уже написали про материализованные представления.
Здравствуйте VladD2, Вы писали:
VD>Я так понимаю у тебя главное непонимание в том как в приведенном варианте аналитику считать. Да? Тогда продаю часть своих идей образца 1996 года...
VD>...
VD>ExtRef – список дополнительных аналитических признаков. Может быть любой длинны. В реальной учетной системе нужно описать какие и сколько справочных значений можно присвоить к Z-объекту каждого типа.
Нечто подобное приходило и в мою голову.
Была идея хранить аналитические признаки в одной таблице, что-то вроде
id
entry_id
analytic_value_id
т.е. если какому-то счету, участвующему в проводке, соответствует N аналитических признаков, то в этой таблице появляется N записей. Это дает неограниченное количество аналитических признаков, но работать с такой таблицей крайне не удобно. Т.е. получалось что SQL запросы с группировкой нужно формировать динамически, что не есть хорошо.
VD>Анализируем ошибки... Хотя зачем? Ты и так все верно подметил. Но (!) почему ты считаешь, что аналитические признаки должны быть отделены от дебета и кредита?
Что имеется ввиду под неотделимостью??? Например можно создать справочник (таблицу) аналитик и сопоставлять id баолансового счета id аналитики. Эо называется неотделимостью?
VD>Это главная твоя ошибка и большинство ваятелей бухгалтерий (ну, и КИС). Бьюсь об заклад, что смогу переформулировать любую постановку задачи, так чтобы в проводке были только дебетовые и кредитовые аналитические признаки! (подсказка: обычно это делается добавлением промежуточных проводок).
Интересная мысль — надо ее повертеть. (Тут могут быть проблемы с целостносью данных)
VD>Теперь просто воспользуемся опытом и знаниями из умных книжек...
А вот и интересно спросить КАКИХ книжек (учитывая что с Дейтом все в порядке ИМХО). Вот как раз и интересна специализированные книжки по данной теме. Я просто абсолютно убежден что таковые должны быть (уж на буржуйском точно)
Применим принцип денормализации и получим не одну убогую таблицу, а две (и не убогие). Первая описана выше, но вместо дебетового и кредитового счета введем понятие дебетового и кредитового аналитического признака. В 1996 я назвал их Z-объектами (почему Z? Об этом я скажу потом...). Вторая таблица содержит эти самые аналитические Z-объекты (и их атрибуты).
VD>Z-объект – это минимальный аналитический признак на котором можно подбить микро-баланс, т.е. все операции (проводки) по такому объекту рано или поздно в сумме дадут нуль (от сюда и Z-объект). Так как меньше этой операции в системе не регистрируется, то можно смело оставить в проводке только дебетовый и кредитовый Z-объект. Зато на Z-объекты можно навесить аналитику любого уровня сложности. Самым универсальным способом будет добавить еще одну таблицу которая содержит ссылку на Z-объект и список справочных значений. Примерами Z-объектом могут быть: заказ, расчетный счет (или некоторый минимальный признак на этом счет, если ведется аналитика по р.с.), авансовый отчет и много другое.
VD>Ниже приведена упрощенная ER-схема БД реализующей описанные выше принципы. VD>ftp://ftp.optim.ru/pub/Tests/ZObj/shem1.GIF VD>Tran – таблица проводок. VD>ZObj – Z-объекты. (Tran имеет две ссылки на ZObj, так как Z-объекты проходят и по дебету и по кредиту проводки... шо поделаешь та самая двойная запись ;) ). VD>ZObjType – типы Z-объектов. VD>Ref – справочники. Здесь представлено упрощенно. Реально это отдельная песня (считайте, что вместо этой таблицы присутствует крутая структура хранящая все справочники учетной системы, а это их инкапсулированное представление). VD>ExtRef – список дополнительных аналитических признаков. Может быть любой длинны. В реальной учетной системе нужно описать какие и сколько справочных значений можно присвоить к Z-объекту каждого типа.
VD>У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
VD>Если кому интересно, то пишите мы открыты для сотрудничества.
Подытоживая предложенное:
1) Большое спасибо
2) Идеи интересные, надо их смоделировать. Сейчас, с наскоку не могу ничего сказать. Надо над ними помидитировать и посоветоваться с духом компьютера ;)
3) По поводу сотрудничества идея интересная, тоже надо обдумать как. Так как большой этап уже сделан
4) Вопрос с откатами и удалениями....
Здравствуйте IT, Вы писали:
IT>Здравствуйте VladD2, Вы писали:
VD>>У меня есть желание создать конструктор который позволит собирать учетные приложения визуально. Основу этого конструктора представляет несколько доработанная схема представленная выше. Подробнее о планах и идеях можно прочесть здесь: http://www.optim.ru/Software/rus/ascConcept/ascconcept.asp
IT>Влад, у тебя же там ничего про веб-сервисы. В сад... и срочно затачивать концепцию под веб-сервисы
А-га. И конвертацию всего что под руку попало в XML.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Willi, Вы писали:
W>Нечто подобное приходило и в мою голову. W>Была идея хранить аналитические признаки в одной таблице, что-то вроде
W>id W>entry_id W>analytic_value_id
W>т.е. если какому-то счету, участвующему в проводке, соответствует N аналитических признаков, то в этой таблице появляется N записей. Это дает неограниченное количество аналитических признаков, но работать с такой таблицей крайне не удобно. Т.е. получалось что SQL запросы с группировкой нужно формировать динамически, что не есть хорошо.
1. Уменьшили количество id.
2. Несколько более хитро формировали запросы. Вообще это тема для отдельной (и довольно большой) статьи. Главное для решения этой проблемы сломать сложившиеся стереотипы и смотреть на аналитические признаки как на список полиморфных отрибутов. Т.е. z-объект — это объект некоторого класса, а справочные значения — это набор атрибутов определяемый классом z-объекта. Далее все становится довольно просто. Наша задача заключается в отборе z-объект в сответсвтвии с ограничениями накладываемыми на тип и значения атрибутов и последующем суммировании (агрегировании) результатов. Т.е. взгляд на учет шиворот-навыворот (в ОО-стиле). Правда тут приходится отходить от канонов реляционных СУБД и отрабатывать логику полиморфизма на среднем слое (или на триггерах).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Tiger, Вы писали:
VD>>Анализируем ошибки... Хотя зачем? Ты и так все верно подметил. Но (!) почему ты считаешь, что аналитические признаки должны быть отделены от дебета и кредита? T>Что имеется ввиду под неотделимостью???
В "единственном" решении аналитические признаки были перечислены внутри проводки, т.е. они не были привязаны к дебету или кредиту, а являлись отдельными признаками (признаками проводки). Это и приводило к негибкости и отсутствию нормальной мат.модели.
T>Например можно создать справочник (таблицу) аналитик и сопоставлять id баолансового счета id аналитики. Эо называется неотделимостью?
В моей концепции есть понятие минимального аналитического признака (Z-объекта) группирующего вокруг себя необходимые аналитические признаки. Бухгалтерский счет это всего лишь один из них. Причем фиксированный (постоянно существующий). Я бы задал его как отдельное поле в таблице Z-объектов.
VD>>Это главная твоя ошибка и большинство ваятелей бухгалтерий (ну, и КИС). Бьюсь об заклад, что смогу переформулировать любую постановку задачи, так чтобы в проводке были только дебетовые и кредитовые аналитические признаки! (подсказка: обычно это делается добавлением промежуточных проводок).
T>Интересная мысль — надо ее повертеть. (Тут могут быть проблемы с целостносью данных)
Нет. Здесь проблем с целостностью не возникает. Проблемы с ней возникают во второй части марлизонского балета... когда приходится создавать универсальный список аналитики. Там придется пописать бизнес логики (вернее даже не бизнес, а прикладной), но это с лихвой окупается (за счет немереной гибкости). Вообще главное в моей концепции смотреть на проводки не как на документы (!), а как на минимальные транзакции из которых складывается граф учета на предприятии. Документы же формируются на базе Z-объектов проводок и атрибутов Z-объектов (хотя первичные документы типа платежки или кассового ордера один к одному отражаются на проводку).
VD>>Теперь просто воспользуемся опытом и знаниями из умных книжек... T>А вот и интересно спросить КАКИХ книжек (учитывая что с Дейтом все в порядке ИМХО). Вот как раз и интересна специализированные книжки по данной теме. Я просто абсолютно убежден что таковые должны быть (уж на буржуйском точно)
Книжки по основам БД? Да их море. Почти везде разбираются вопросы нормализации данных и построения эффективных решений. Ну, а книжек по проектированию учетных решений, да еще таких чтобы били действительно полезны я не встречал...
T>4) Вопрос с откатами и удалениями....
Это чисто технический вопрос. Его можно даже (частично) решать средствами некоторых СУБД (например, Oracle 9i поддерживает партишоны которые видны только определенному кругу людей. В конце моделирования все изменения можно откатить или принять. Можно организовывать лог отката, и т.п. Но по своей практике скажу, что лучше потратить время на проработку учетной схемы, отдача будет бОльшая.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте VladD2, Вы писали:
VD>Здравствуйте Willi, Вы писали:
W>>Нечто подобное приходило и в мою голову. W>>Была идея хранить аналитические признаки в одной таблице, что-то вроде
W>>id W>>entry_id W>>analytic_value_id
W>>т.е. если какому-то счету, участвующему в проводке, соответствует N аналитических признаков, то в этой таблице появляется N записей. Это дает неограниченное количество аналитических признаков, но работать с такой таблицей крайне не удобно. Т.е. получалось что SQL запросы с группировкой нужно формировать динамически, что не есть хорошо.
VD>1. Уменьшили количество id. VD>2. Несколько более хитро формировали запросы. Вообще это тема для отдельной (и довольно большой) статьи. Главное для решения этой проблемы сломать сложившиеся стереотипы и смотреть на аналитические признаки как на список полиморфных отрибутов. Т.е. z-объект — это объект некоторого класса, а справочные значения — это набор атрибутов определяемый классом z-объекта. Далее все становится довольно просто. Наша задача заключается в отборе z-объект в сответсвтвии с ограничениями накладываемыми на тип и значения атрибутов и последующем суммировании (агрегировании) результатов. Т.е. взгляд на учет шиворот-навыворот (в ОО-стиле). Правда тут приходится отходить от канонов реляционных СУБД и отрабатывать логику полиморфизма на среднем слое (или на триггерах).
Все это конечно очень здорово (без всякой иронии).
Но вот простой пример, я хочу получить баланс, причем не просто по счетам, но и с группировкой по аналитикам. Что-то вроде:
Товары на складе 1000
Продукты питания 200
Вобла 50
Пиво "Lowenbrau" 150
Одежда 400
Джинсы 250
Майки 150
Обувь 400
Кроссовки 200
Ласты на каблуках 200
Здесь
"Товары на складе" — это счет,
"Продукты питания", "Одежда", "Обувь" — аналитики типа "Вид товара"
все остальное — аналитики типа "Товар"
SELECT
SUM( entry_volume )
...
GROUP BY
account_id,
analytic_0_id
analytic_1_id
...
analytic_N_id
мы тут же получем нужный нам результат.
Но такая таблица будет наполовину или даже больше (зависит от N) пустой, да и вообще криво как-то смотрится.
Но если значения аналитик хранить так как я писал раньше
tblEntries
----------
entry_id
entry_volume
account_id
tblEntryAnalytics
----------
id
entry_id
analytic_id
то я ума не приложу как тут итоговые запросы строить.
Здравствуйте VladD2, Вы писали:
VD>Книжки по основам БД? Да их море. Почти везде разбираются вопросы нормализации данных и построения эффективных решений. Ну, а книжек по проектированию учетных решений, да еще таких чтобы били действительно полезны я не встречал...
Влад, а может, посоветушь наиболее толковые книжечки по БД, окромя Дейта, конечно же. А то я одной из частей своего тела чую, что маловато у меня знаний для решения задач подобного рода.
Здравствуйте alexm1202, Вы писали:
A>Здравствуйте George_Seryakov, Вы писали:
A>>>А почему должны быть "записи"? Имхо, достаточно одной, в которой мы бы видели счет, с которого берем средства, счет, на который их относим, сумму и время проведения операции. Все это было в той табличке, с которой начался разговор.
GS>>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>Так тебе шашечки или ехать?
Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
A>BR, Alex.
Здравствуйте Willi, Вы писали:
VD>>Книжки по основам БД? Да их море. Почти везде разбираются вопросы нормализации данных и построения эффективных решений. Ну, а книжек по проектированию учетных решений, да еще таких чтобы били действительно полезны я не встречал...
W>Влад, а может, посоветушь наиболее толковые книжечки по БД, окромя Дейта, конечно же. А то я одной из частей своего тела чую, что маловато у меня знаний для решения задач подобного рода.
Здравствуйте George_Seryakov, Вы писали:
GS>>>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>>Так тебе шашечки или ехать?
GS>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
GS>А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
Я так понимаю, что вопрос риторический и ты намекаешь на то, что люди, принимающие участие в обсуждении слабо знакомы с реляционной теорией и принципами проектирования реляционных БД? Если так, то ты не мог бы пояснить, как ты пришел к такому заключению?
Здравствуйте alexm1202, Вы писали:
A>Здравствуйте George_Seryakov, Вы писали:
GS>>>>Достаточно для учета, недостаточно для рабского воспоизведения принципа двойной записи.
A>>>Так тебе шашечки или ехать?
GS>>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
A>А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
Да ты его сам обосновал. "По одному счету и по другому счету". Или кто там определение двойной записи приводил?
GS>>А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
A>Я так понимаю, что вопрос риторический и ты намекаешь на то, что люди, принимающие участие в обсуждении слабо знакомы с реляционной теорией и принципами проектирования реляционных БД? Если так, то ты не мог бы пояснить, как ты пришел к такому заключению?
Нет-нет, я никого не оцениваю. Причем ответы на эти вопросы я и сам не знаю, с трудом первые три могу сообразить, но какая из третьих — уже не догоняю. Но зато знаю, где посмотреть про это. Баркера надо читать! Ну, или спросить у тех, кто знает.
Здравствуйте George_Seryakov, Вы писали:
GS>>>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
A>>А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
GS>Да ты его сам обосновал. "По одному счету и по другому счету". Или кто там определение двойной записи приводил?
Я приводил. И я ей-богу не догоняю, о чем ты говоришь. Давай еще раз. Принцип двойной записи гласит: "Если средства где-то появились, то значит где-то они исчезли. И наоборот." Следовательно, фиксируя приход/расход средств на каком-либо счете мы обязаны указать корреспондирующий счет, с/на который эти средства расходуются/приходуются. Если не отвлекаться на детали, в которых, как известно, дьявол :) то для реализации этого принципа подходит такая табличка:
create table operation
(operid int not null,
credit int not null,
debit int not null,
opersum money not null,
operdate datetime not null,
constraint pk_operation primary key (operid))
Я не вижу здесь нарушения 1-3НФ, НФБК, 4-5НФ, как и не вижу возможностей для возникновения каких-либо аномалий обновления, что в свою очередь свидетельствовало бы о нарушении каких-то НФ. Если я не прав, пожалуйста, поправь меня. В противном случае поясни, что ты имеешь в виду под "намеренной денормализацией"? Я эти слова понимаю как осознанный отход от какой-то из перечисленных НФ, сделанный по каким-то соображениям (производительности, например).
GS>>>>Ни того ни другого, к счастью. Но меня начинает забавлять дискуссия, развернувшаяся вокруг такого, в общем-то, тривиального утверждения, что двойной учет — это намеренная денормализация.
A>Я приводил. И я ей-богу не догоняю, о чем ты говоришь. Давай еще раз. Принцип двойной записи гласит: "Если средства где-то появились, то значит где-то они исчезли. И наоборот."
"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A> не прав, пожалуйста, поправь меня. В противном случае поясни, что ты имеешь в виду под "намеренной денормализацией"? Я эти слова понимаю как осознанный отход от какой-то из перечисленных НФ, сделанный по каким-то соображениям (производительности, например).
Что в двух местах. Намеренная денормализация, сделанная по соображениям контроля и восстановления целостности.
Т.е. журнал транзакций двойной записью не является.
Здравствуйте George_Seryakov, Вы писали:
GS>А кто помнит, сколько есть нормальных форм? Может перечислить? Привести примеры? Показать типичные (для форм данной нормальности) нарушения целостности?
Ты путаешь понятия нормализации/нормальной формы и целостности данных. В не полностью нормализованных таблицах всего лишь происходит дублирование данных которое в конце концов может привести к нарушению целостности, но все же это не одно и тоже.
А про то, что можно делать учетные системы с прилично нормализованными таблицами и в тоже время использовать принцып двойной записи я тебе уже показал рашьше. Если с чем-то не согласен, так сформулируй с тем, а так получается разговор с глухим.
PS
100% нормализация вещь вообще зачастую избыточная...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте George_Seryakov, Вы писали:
A>>А ты не мог бы обосновать это тривиальное утверждение, если тебе не трудно?
GS>Да ты его сам обосновал. "По одному счету и по другому счету". Или кто там определение двойной записи приводил?
Извини, но это демагогия. Тебе вопрос задали (причем не просто так), а ты...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте George_Seryakov, Вы писали:
A>>Я приводил. И я ей-богу не догоняю, о чем ты говоришь. Давай еще раз. Принцип двойной записи гласит: "Если средства где-то появились, то значит где-то они исчезли. И наоборот."
GS>"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
Мои.
GS>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
Буду спорить :) Про два места совсем неясно. Если мы можем отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже, то я не понимаю как это противоречит приведенному определению? Кредит и дебит при этом действительно будут разными местами :) но эти места — два разных атрибута одного кортежа.
Здравствуйте alexm1202, Вы писали:
GS>>"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
A>Мои.
GS>>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A>Буду спорить Про два места совсем неясно. Если мы можем отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже, то я не понимаю как это противоречит приведенному определению? Кредит и дебит при этом действительно будут разными местами но эти места — два разных атрибута одного кортежа.
А то, что сделана оговорка "в одной и той же сумме" тебя не наводит на мысли? Зачем она нужна если ты свел две записи (смысле бухучета) к одному кортежу (или записи в смысле БД)?
Давай так: вот ссылка на бухгалтерский учебник в которой явно говорится (и показывается на примерах), что двойная запись требует двух записей: http://www.ait.spb.ru/buh_aud/buh004.html. Попробуй найти и представить текст, в котом столь же явно говорилось бы, что для двойной записи хватило бы "отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже". Найдешь — сравним источники.
Здравствуйте George_Seryakov, Вы писали:
GS>>>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A>>Буду спорить :) Про два места совсем неясно. Если мы можем отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже, то я не понимаю как это противоречит приведенному определению? Кредит и дебит при этом действительно будут разными местами :) но эти места — два разных атрибута одного кортежа.
GS>А то, что сделана оговорка "в одной и той же сумме" тебя не наводит на мысли? Зачем она нужна если ты свел две записи (смысле бухучета) к одному кортежу (или записи в смысле БД)?
:) Я склонен списать эту оговорку на издержки докомпьютерного учета. У нас же вроде бы разговор идет о проектировании учетной системы, базирующейся на системе управления БД. Предположительно, реляционной. В этом контексте использование такого приема обеспечения "контроля и восстановления целостности" :) как дублирование информации в разных таблицах, мне кажется излишним. Поэтому на эту оговорку, имхо, просто не нужно обращать внимание.
GS>Давай так: вот ссылка на бухгалтерский учебник в которой явно говорится (и показывается на примерах), что двойная запись требует двух записей: http://www.ait.spb.ru/buh_aud/buh004.html. Попробуй найти и представить текст, в котом столь же явно говорилось бы, что для двойной записи хватило бы "отразить операцию по дебету одного счета и кредиту другого не только одновременно, но и в одном кортеже". Найдешь — сравним источники.
Вообще-то на страничке, которую ты привел я нашел аж три способа фиксирования проводок: 1)табличка, отражающая суммы по дебету и кредиту какого-то счета, при этом сумма вносится в дебетовую часть таблички одного счета и в кредитовую — другого (то, о чем ты говоришь, как я понял), 2) запись вида:
Д51
К50 5000р.
— т.е. все-таки объединение в одном кортеже суммы, номера дебетуемого счета и номера кредитуемого счета :) , 3)в конце страницы вообще приведена форма стандартного журнала регистрации хозопераций, довольно точно совпадающая по структуре с таблицей, приведенной мной пару писем назад. При этом я не нашел в тексте указаний на то, что одна из этих форм записи является "более правильной", чем другие. Как мне кажется, напрашивается вывод о том, что главное в принципе двойной записи это все-таки требование того, чтобы деньги не возникали ниоткуда и не исчезали в никуда, чтобы любая операция фиксировалась с участием как минимум двух счетов. Требование же, которое ты выдвигаешь на передний план, о том, что операция обязательно должна физически оформляться в виде двух отдельных записей, мне представляется просто техническим приемом, призванным облегчить ведение учета на бумаге. При переводе учета на машину это требование, имхо, можно опустить.
Здравствуйте alexm1202, Вы писали:
GS>>А то, что сделана оговорка "в одной и той же сумме" тебя не наводит на мысли? Зачем она нужна если ты свел две записи (смысле бухучета) к одному кортежу (или записи в смысле БД)?
A> Я склонен списать эту оговорку на издержки докомпьютерного учета. У нас же вроде бы разговор идет о проектировании учетной системы, базирующейся на системе управления БД.
Первоначальный вопрос был о трудностях реализации в модели данных двойного учета, т.е. о переводе докомпьютерного учета в компьютерный.
A>Требование же, которое ты выдвигаешь на передний план, о том, что операция обязательно должна физически оформляться в виде двух отдельных записей, мне представляется просто техническим приемом, призванным облегчить ведение учета на бумаге.
Именно так. Намеренная денормализация.
A>При переводе учета на машину это требование, имхо, можно опустить.
Здравствуйте alexm1202, Вы писали:
A>...Требование же, которое ты выдвигаешь на передний план, о том, что операция обязательно должна физически оформляться в виде двух отдельных записей, мне представляется просто техническим приемом, призванным облегчить ведение учета на бумаге. При переводе учета на машину это требование, имхо, можно опустить.
Да не требование это... это попытка воспринимать слова формально, т.е. не по смыслу, а по звучанию. С точки зрения алгоритмов учета разделение информации об одной проводке является ошибкой приводящей (рано или поздно) к несоответствию в учете. Математически проводка — это вектор, а весь учет можно представить в виде матрицы. Это и делают большинство бухгалтеров при ручном учете. Посмотри на журнал операций и шахматную ведомость.
PS
Формальное понимание – это непонимание.
PPS
Начал писать завернутый ответ, но получается почти статья. Через некоторое время выдам ее на гора. Заодно объясню как используя обычные реляционные механизмы строить гибкие системы учета. Может найдутся единомышленники...
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Будь добр. Сформулируй, что является неправильным в предложенной тебе системе записи проводок в одной таблице. Причем не уходя в сторону. И попробуй привести пример который нельзя учесть в данной схеме. Или который приведет к неправильным результатам.
Напомню еще раз твою фразу которая и породила весь спор:
GS>А надо? Двойная запись вообще-то, если ее пытаться воспроизвести в ERD, создаст нечто вроде денормализации с дополнительным ограничением целостности, то есть, от чего стоит избавляться.
Тебе объяснили, что ты не прав, и что двойная запись прекрасно описывается в терминах и средствами реляционных БД. И что создание нормализации есть вего лишь неправильное проектирование. Мы не претендуем, на то что решение предлагемое нами единственное и наиболее оптимальное, но все же оно удовлетворяет самым строгим требованиям нормализации и при это позволяет эфективно хранить информацию о проводках отвечая всем требовниям двойной записи.
Да! Очень хочется услышать все таки осмысленные аргументы против, т.е. доказательства, а не жанглирования словами.
PS
Такие споры очень полезны, так как позволяют отточить аргуменатацию и сделать более продуманную модель. Так что главное не перейти на личности и не скатиться к демогогии.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте Willi, Вы писали:
W>Влад, а может, посоветушь наиболее толковые книжечки по БД, окромя Дейта, конечно же. А то я одной из частей своего тела чую, что маловато у меня знаний для решения задач подобного рода.
Я бы и рад, но вот толку от моих советов бцдет мало. Я последний раз книжки по БД читал году в 96-м.
Могу дать тлько пару советов:
Если есть пробелы в обшей логике или логике предикатов, то есть смысл найти что-нибудь в этой области. Подойдут даже учебники.
Перед созданием сложных (агрегирующих) запросов нужно сформулировать задачу в виде потабличных "срезов".
Здравствуйте George_Seryakov, Вы писали:
GS>"Каждая хозоперация подлежит отражению в одной и той же сумме одновременно по дебету одного счета и кредиту другого." Твои слова?
GS>Это значит, что где-то есть один счет и другой счет. У них есть кредит с дебетом. И вот в кредите одного и дебите другого (в двух разных местах!) хозоперация и отражается, причем в одной и той же сумме. Про два места ясно? Спорить будешь?
A>> не прав, пожалуйста, поправь меня. В противном случае поясни, что ты имеешь в виду под "намеренной денормализацией"? Я эти слова понимаю как осознанный отход от какой-то из перечисленных НФ, сделанный по каким-то соображениям (производительности, например).
GS>Что в двух местах. Намеренная денормализация, сделанная по соображениям контроля и восстановления целостности.
GS> Т.е. журнал транзакций двойной записью не является.
W>Посо1етуйте, пожалуйста, книги (можно на английском), сайты в нете, вообще любую инфу по проектированию учетных ситем.
Z cjdtneЗдравствуйте Willi, Вы писали:
Я советую посмотреть 1С версии 7.5 и выше — не снаружи — а изнутри, т.е. их конфигуратор и словарь данных. Концепция — железная, как не крути — прийдешь к тому же имхо..
Веру-ю-у! В авиацию, в научную революци-ю-у, в механизацию сельского хозяйства, в космос и невесомость! Веру-ю-у! Ибо это объективно-о! (Шукшин)
Господа, мой опыт проектирования небольшой (около 10 систем учета), но мне ВСЕГДА было достаточно данных по движению объекта учета т.е. <откуда поступил> , <куда поступил> , и описание самого <объекта учета>.
а двойная запись необходима лишь при РУЧНОМ методе .
<Обектами учета> -- могут МЦ, дениги,товары, и т.д. (все что учитываем)
<откуда поступил> и <куда поступил> -- могут бать cклады, касса , счета и т.д. (все, относительно чего учитываем)
Если нам не помогут, то мы тоже никого не пощадим.
В сад... и срочно затачивать концепцию под веб-сервисы 
весьма верно подметил про аналитики. Т.е. единственное решение (ИМХО конечно) это сделать плоскую таблицу (id_проводки, дебет, кредит, сумма, аналитика1, ... аналитикаN) НО таблица получается громоздкой. В ней всяких пустот образуется немерянно так как разные счета имеют разные аналитики. 
