|
|
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
На данном форуме уже поднимался вопрос, как вести учет в нескольких валютах, по подразделениям. Например Структура таблицы бухгалтерских проводок не дает покоя !!!! Литература Но я так и не могу понять, как лучше вести учет в ситуации, когда надо вести мультивалютный учет по нескольким структурам центров затрат. Т.е. существует не один тип плоскостей учета, а несколько. А если кол-во типов плоскостей динамичное? Что такое "несколько структур центров затрат". Это, например, деление по региональному признаку и деление по отраслевому признаку. Предположим, что такое деление необходимо только для агрегирования данных по узлам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 10:02 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
По сути два вопроса. 1) про валюту. Можно в таблице Проводка (или Полупроводка, если используется этот вариант, кстати, когда бухгалтер реально видит полупроводку, то этот термин проблем не вызывает.) иметь два поля: Валюта_операции, Валюта_баланса, и на каждую операцию создавать столько строк, сколько нужно валют баланса. Как вы будете пересчитывать валюты - это определяется законодательством и учетной политикой. Например, одно из типичных заблуждений - отражение в учете разниц по договорам, номинированым в "валюте по курсу ЦБ", но операции по которым выполняются в рублях, как реальных курсовых разниц с поледующщим налогообложением. 2) про аналтику - см. топики. Или попробуйте сформулировать проблему конкретней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 11:05 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
По валюте все и так понятно. Непонятно как раз по второму вопросу. Допустим, ведем учет начислений по сотрудникам. В организации существует несколько логических делений на группы. Скажем первое деление по регионам, второе деление по должностям (например, все HR менеджеры всех регионов собранны в одну группу), третье деление по проф. уровню (т.е. аналог звания, скажем, военного). Предполагается, что хранить надо произвольное число таких структур. Это предположение основано на том, что необходимо вести одновременный учет не одной компании, а нескольких и заранее знать о всех структурных делениях всех компаний мы не можем. Все это разбиение на структуры необходимо для того, чтобы в дальнейшем подсчитать затраты на персонал с разных точек зрения. Зачем это нужно, я думаю понятно. Я пояснил вопрос? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 11:36 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
valmondПредполагается, что хранить надо произвольное число таких структур. Произвольное - это 20, 2000 ? Если 20, то годится структура Код: plaintext Если 2000, увы только, Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 16:50 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Наверное тут речь идет об аналоге системы "субконто" принятой в 1С. Т.е. что-то в виде измерений аналитики. В 1С кол-во субконто вроде бы задается на этапе создания базы и не меняется.Эдакий план в плане счетов. И в идеале предлагается изобрести систему, такую, чтобы количество измерений аналитики могло быть произвольным. И чтоб это все работало быстро. Я правильно все понял? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 17:00 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
gardenmanНаверное тут речь идет об аналоге системы "субконто" принятой в 1С. Т.е. что-то в виде измерений аналитики. В 1С кол-во субконто вроде бы задается на этапе создания базы и не меняется.Эдакий план в плане счетов. И в идеале предлагается изобрести систему, такую, чтобы количество измерений аналитики могло быть произвольным. И чтоб это все работало быстро. Я правильно все понял? Почти правильно. Т.е. правильно все за исключением вопроса производительности. Хочу этот вопрос пока оставить. Есть же несколько вариантов решения производительности. измерения аналитики это не стандартная задача? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 17:05 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
слушайте gardenman он хорошо про плоскости учета расскажет и, к стати, где-то тут скрипт БД приводил Что такое "несколько структур центров затрат". а это уже больше про план счетов. Т.е. как обычно План счетов->Счета->Проводки ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 17:22 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
funikovyuriслушайте gardenman он хорошо про плоскости учета расскажет и, к стати, где-то тут скрипт БД приводил Знаю, я с этого и начал. Но там все относилось к одному типу плоскостей. Или валюты, или регионы...а надо одновременно. funikovyuri Что такое "несколько структур центров затрат". а это уже больше про план счетов. Т.е. как обычно План счетов->Счета->Проводки К сожалению не нашел ничего путного на тему плана счетов. Из постов gardenman -а видно, что аналитика на счета завязанна, но что-то не соображается ничего :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 17:28 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Если говорить о плане счетов - то его действительно легко представить в виде дерева. Но вот если говорить о субконто - это не дерево - это все-же измерения, и работать с ними надо как-то по-другому. У меня пока на эту тему мыслей не было. Я - пас... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 17:40 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
gardenmanЕсли говорить о плане счетов - то его действительно легко представить в виде дерева. Но вот если говорить о субконто - это не дерево - это все-же измерения, и работать с ними надо как-то по-другому. У меня пока на эту тему мыслей не было. Я - пас... Так по хорошему в какую сторону надо думать? в сторону плана счетов (т.е. по сути получится несколько планов счетов, каждый для своей комбинации типов плоскостей, так?) или все же в сторону субконто? Или выделить из типов плоскостей какие-то (например валют, которая есть в любом случае) и сделать как в Вашем примере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 17:58 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
valmond угу - я бы думал в сторону нескольких планов счетов. А плоскость учета формируется на основании валюты проводок, а не валюты самих счетов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 18:22 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Понимаете, я автоматизировал банк. А чтобы дать ответ на ваш вопрос, и предложить решение, за которое потом мне не было бы стыдно - мне нужно сначала досконально изучить вашу задачу. А это - не реально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 18:28 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
gardenmanПонимаете.... А это - не реально. Да....понимаю, конечно. Попробую перефразировать немного...может станет чуть понятнее и появятся какие-то мысли...(кстати можно писать все мысли, что есть...не виду смысла стыдить кого-то за что-то...было бы совсем простое решение, то или сам бы догадался или вы бы тут сразу сказали что да как). Общая задача - расчет заработной платы. компания логически делится на регионы и на центры затрат. Зарплату получают как в рублях так и в usd, налоги платят в рублях. В итоге хочется понять сколько было затраченно (и на что) для каждого региона и для каждого центра затрат в каждой валюте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 18:35 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
в принципе в RS-Balance была возможность наворота произвольного количества разрезов на счет. Если правильно помню, там были таблицы Проводки Проводки_Аналитики где каждая проводка могла быть детализирована массой проводок аналитики (по каждому разрезу), (т.е. запись в "проводки" можно было бы считать агрегирующей для записей разрезов, но, на деле, разница между суммой аналитических проводок по разрезу и (полной) суммой проводки в "проводки" рассматривалась как проводка по "неизвестному объекту" данного разреза (чем обеспечивалось совпадение сумм проводок, считаемым по всем разрезам, и возможность постепенного уточнения "неопределенной" части разрезов) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 19:04 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Давно никуда не встревал, тоже встряну Вот примерная "рыба" озвученных автором хотелок Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 20:49 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Блин, кириллицы не видать, почему? /*RDBMS: FIREBIRD/INTERBASE*/ SET SQL DIALECT 3; CREATE DATABASE "D:\DATA\IBDATA\TEMP2.GDB" USER "SYSDBA" PASSWORD "masterkey" PAGE_SIZE 4096; /* Справочник счетов(регистров учета)("древесный") */ CREATE TABLE Acc( ID BIGINT DEFAULT 0 NOT NULL, /* ID-регистра(счета) */ PARENT BIGINT DEFAULT 0 NOT NULL, /* ID-родителя регистра(счета) */ SIGN VARCHAR(16), /* SIGN: Типа: '19.НДС18%'...'41.МЛЯ.МЛЯ'*/ AccYype CHAR(1), /* 'А', 'П', ... */ /* ...мля-мля-мля...*/ NAME VARCHAR(128), PRIMARY KEY(ID), CONSTRAINT PARENT_Acc FOREIGN KEY(PARENT) REFERENCES Acc(ID) ); /* Справочник объектов учета("древесный") */ CREATE TABLE Object( ID BIGINT DEFAULT 0 NOT NULL, /* ID-объекта учета */ PARENT BIGINT DEFAULT 0 NOT NULL, /* ID-родителя объекта учета */ /* ...мля-мля-мля...*/ NAME VARCHAR(128), PRIMARY KEY(ID), CONSTRAINT PARENT_Obj FOREIGN KEY(PARENT) REFERENCES Object(ID) ); /* Справочник множеств "субконто" ("древесный") */ /* Ссылка на ID,-ссылка на единичн.элемент или на папку(поддерево) */ CREATE TABLE ObjLink( ID BIGINT DEFAULT 0 NOT NULL, /* ID-объекта учета */ PARENT BIGINT DEFAULT 0 NOT NULL, /* ID-родителя объекта учета */ /* ...мля-мля-мля...*/ NAME VARCHAR(128), PRIMARY KEY(ID), CONSTRAINT PARENT_ObjLink FOREIGN KEY(PARENT) REFERENCES ObjLink(ID), CONSTRAINT PARENT_Objects FOREIGN KEY(ID) REFERENCES Object(ID) ); /* Таблица операций(проводок) */ CREATE TABLE OPERS( /*-------------------------Корпо-консолидация:-------------*/ /* --- мля-мля-мля ---*/ /*-------------------------Приклад:------------------------*/ OP_DOC_ID BIGINT DEFAULT 0 NOT NULL, /* Документ-родитель проводки */ OP_ID BIGINT DEFAULT 0 NOT NULL, /* ID-проводки */ OP_DATE DATE DEFAULT 'NOW' NOT NULL,/* Дата операции */ OP_ACC_D INTEGER DEFAULT 0 NOT NULL, /* Счет(регистр) по дебету*/ OP_OBJ_D BIGINT DEFAULT 0 NOT NULL, /* Объект учета по дебету */ OP_ACC_K INTEGER DEFAULT 0 NOT NULL, /* Счет(регистр) по кредиту */ OP_OBJ_K BIGINT DEFAULT 0 NOT NULL, /* Объект учета по кредиту */ OP_KOL DOUBLE PRECISION DEFAULT 0.0 NOT NULL, /* Количество */ OP_SUM DOUBLE PRECISION DEFAULT 0.0 NOT NULL, /* Сумма */ MONEY_ID INTEGER DEFAULT 1 NOT NULL, /*Валюта */ MONEY_RATE DOUBLE PRECISION DEFAULT 1.0 NOT NULL, /*Курс на дату OP_DATE*/ /*-------------------------System:-------------------------*/ OP_DT_CRE TIMESTAMP DEFAULT CURRENT_TIMESTAMP,/*Дата и время создания*/ OP_DT_EDI TIMESTAMP DEFAULT CURRENT_TIMESTAMP,/*Дата и время модификации*/ CREATOR_ID INTEGER DEFAULT 0 NOT NULL, /*Пользователь-создатель*/ EDITOR_ID INTEGER DEFAULT 0 NOT NULL, /*Пользователь-модификатор*/ PRIMARY KEY(OP_ID), /*Немного деклараций от дурака*/ CONSTRAINT PARENT_ACC_D FOREIGN KEY(OP_ACC_D) REFERENCES ACC(ID), CONSTRAINT PARENT_ACC_K FOREIGN KEY(OP_ACC_K) REFERENCES ACC(ID), CONSTRAINT PARENT_JBJ_D FOREIGN KEY(OP_OBJ_D) REFERENCES ObjLink(ID), CONSTRAINT PARENT_JBJ_K FOREIGN KEY(OP_OBJ_K) REFERENCES ObjLink(ID) ); /* OP_ACC_D, OP_ACC_k - ссылка на регистр(счет) OP_OBJ_D, OP_OBJ_K - ссылка на запись(это может быть и "папка" в таблице расшифровки "субконто") в ObjLink,дальше расшифровка в Object ИМЕЕМ: проводка может хранить произвольное количество субконто, каждый из которых может иметь произвольное колич.уровней иерархии... */ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 20:50 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.05.2005, 20:54 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Глянул по этой ссылке на эту Арбинаду, ну не прикольнула она меня ни чем! Опять лобовое решение, опять "этот", тот же перечень полей, надо 10 аналитик,значит вдолбим в таблицу при создании эти 10 полей. А ещели я к примеру хочу, чтобы в одной проводке была 1 аналитика, а в соседней проводке 21, а через одну, - 121 !? И чтобы по каждой из них уровней было от 2 и по "самое не балуйся"? Пусть уж коллективная творческая мысль дальше ввысь стремится! А то не интересно как то.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 03:03 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Самое универсальное решение - держать аналитику в виде списка analitika={a1='a',a2='b',a21='21'} в теле основной проводки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 13:06 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Сахават Юсифов пишет: > Самое универсальное решение - держать аналитику в виде списка > analitika={a1='a',a2='b',a21='21'} в теле основной проводки. Любопытная мысль. Можно развить идею до списка в XML - современные сервера позволяют разворачивать это в наборы записей. Только вот вопрос, а что с производительностью, когда пойдет выборка по аналитикам, а счет проводок идет на миллионы? Posted via ActualForum NNTP Server 1.2 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 13:42 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Все решается. Одна допольнителная функция для регулярных выражений и создается нужный разрез для отчета. Дальше сам отчет. Насчет 1000.... записей - плохая организация данных. (Детский подход навеянный примитивизмами типа нормализации и т.д.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 13:47 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
valmondОбщая задача - расчет заработной платы. компания логически делится на регионы и на центры затрат. Зарплату получают как в рублях так и в usd, налоги платят в рублях. В итоге хочется понять сколько было затраченно (и на что) для каждого региона и для каждого центра затрат в каждой валюте Если вернутся к моему вопросу, то кажется я поставил слишком общую задачу. В моем случае получается всего две аналитики. Валюта суммы и принадлежность суммы к элементу логического деления. Т.е. получаются валютная плоскость и плоскость логического деления. Как для валюты существует основная плоскость (рубли), так и для логического деления сущетсвует плоскость обособленных подразделений и если применить технику. которую описал gardenman (т.е. отражение всех движений в основных плоскостях), то все вроде как решается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 14:07 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Сахават Юсифов пишет: > Самое универсальное решение - держать аналитику в виде списка > analitika={a1='a',a2='b',a21='21'} в теле основной проводки. Любопытная мысль. Можно развить идею до списка в XML - современные сервера позволяют разворачивать это в наборы записей. Только вот вопрос, а что с производительностью, когда пойдет выборка по аналитикам, а счет проводок идет на миллионы? Реализация планируется на MS SQL 2000. Может конечно мне не хватает опта работы с xml в sql, но что-то мне подсказывается, что групповые операции по аналитикам через xml будут очень очень медленные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 14:09 |
|
||
|
Плоскости учета
|
|||
|---|---|---|---|
|
#18+
valmond Александр Гoлдун Сахават Юсифов пишет: > Самое универсальное решение - держать аналитику в виде списка > analitika={a1='a',a2='b',a21='21'} в теле основной проводки. Любопытная мысль. Можно развить идею до списка в XML - современные сервера позволяют разворачивать это в наборы записей. Только вот вопрос, а что с производительностью, когда пойдет выборка по аналитикам, а счет проводок идет на миллионы? Реализация планируется на MS SQL 2000. Может конечно мне не хватает опта работы с xml в sql, но что-то мне подсказывается, что групповые операции по аналитикам через xml будут очень очень медленные. Ваша задача сама по себе ничего дополнительного не требует. Стандартная зарплата. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 15.05.2005, 14:18 |
|
||
|
|

start [/forum/topic.php?fid=32&startmsg=33063954&tid=1545304]: |
0ms |
get settings: |
10ms |
get forum list: |
21ms |
check forum access: |
5ms |
check topic access: |
5ms |
track hit: |
196ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
82ms |
get tp. blocked users: |
2ms |
| others: | 241ms |
| total: | 577ms |

| 0 / 0 |
