Недавно осенило. Но скорее всего это уже давно используют умные люди.
Вот и хочется это выяснить.

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

Управленческий учет. В частности складской. Тут тоже умные люди используют реестр, где идет перемещение объекта учета (товара) с одного склада на другой.
Автосалон взял у владельца автомобиль, причем под реализацию. Если просто переместить объект учета (авто) с одного склада (физлицо) на другой склад (какой-то конкретный склад), то мы не можем получить полную картину. Точнее мы можем узнать сколько автомобилей на складе, но и только.
Хотелось бы знать сколько авто с этого склада можно продать, сколько авто взято для ремонта, сколько авто нам не принадлежит.

А если для этого использовать план счетов, но не бухгалтерский, а управленческий. Есть такой план счетов? Кто-нибудь это использует?
Я бы сделал так:

Ввел следующие счета:

1. На продажу
2. В ремноте
3. Под реализацию
4. Продавец
5. Покупатель

Тогда всё можно разрулить проводками

1. Дб Под реализацию (аналитический счет склад) - Кр Продавец: взяли авто подреализацию
2. Дб В ремонте (аналитический счет мастерская) - Кр Под реализацию: авто было неисправное и подлежит ремонту перед продажей
3. Дб На продажу (аналитический счет шоурум) - Кр В ремонте: выставили на продажу
4. Дб Покупатель (аналитический счет физлицо) - Кр На продажу: продали

Кадровый учет. Я бы ввел тоже счета

1. Штатное расписание. Субсчета соответствуют должностям, например, программист
2. Прием на работу
3. Отпуск
4. Увольнение

И проводки

1. Дб Штатное расписание (субсчет программист) - Кр Прием на работу
2. Дб Отпуск - Кр Штатное расписание
3. Дб Штатное расписание - Кр Отпуск
4. Дб Увольнение - Кр Штатное расписание

Или как то так

Интересно выслушать мнения.

--------------------
Не учи отца и баста!

LSV,

Значит я на правильном пути. А есть кто это использует?

Naf,

Насчет одной таблицы я не говорил. Но структура одинаковая и все алгоритмы и механизмы тоже.
Хотя я бы всё-таки в одну таблицу запихнул.

Naf,

Не понял вопроса. Двойная запись она уже есть, я пример показал. Если имеется ввиду, что нужен учет и тот и этот, то будет две проводки, каждая по своему плану счетов

Old Nick,

Хотя если мы все-таки ведем бухучет и управленческий в одной системе, то лучше сделать так, чтобы управленческий был детализацией (аналитической) бухучета.

А тут я рассматриваю ситуацию, когда управленческий учет в самописной системе, а бухучет в 1С.

NafOld NickNaf,

Не понял вопроса. Двойная запись она уже есть, я пример показал. Если имеется ввиду, что нужен учет и тот и этот, то будет две проводки, каждая по своему плану счетовЭто я вас не понял: проводка как бы подразумевает что есть Дебет и Кредит, вы их будете по разным таблицам рассовывать? Если да, то это обычный Шаблон: Ресурсы накопления

Нет, дебет и кредит в одной таблице. Это два поля одной таблицы

Naf,

Потому что двойной учет. Празложении на состовляющие наиболее частая проблема потеря половинки

Naf,

Тогда поясню. Перемещение материала с одного склада на другой в бухучете делает такой проводкой

Дб 10 (аналитический счет 1 склад) - Кр 10 (аналитический счет 2 склад)

--------------------
Не учи отца и баста!

Naf,

Счета выстраиваются иерархически. Поэтому в поле Дебет или Кредит вписывает листовой узел дерева

Я упростил схему для понимания. Она на самом деле более сложная.

guest_20040621,

Аргументируйте!

_мод,

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

guest_20040621,

Я давно подозревал, что Ваш уровень квалификации не очень, теперь убедился. Вы пытаетесь казаться умным и грамотным, то таковым Вас сочтут только новички в программировании. Увы...

NeboOld Nick,

Вы правильно, в верном направлении мыслите:)
Тут я бы посоветовал, делать как Вы, но считать это определённым уровнем абстракции, для удобства не бухгалтеров.
То есть изначательно я бы отталкивался от плана счетов. Тогда не будет логических ошибок.
Поскольку в бухгалтерии всё предельно точно. Отталкиваться от корреспонденций между счетами.
И добавить аналитики в проводки. Всё достаточно просто.

И кстати на экране для пользователя Вы можете "убрать бухгалтерию".
Но сердцем учёта будет ясная и понятная бухгалтерская модель.
Для учёта финансов и количества.

Именно это я и имел ввиду. Структура такая нужна именно для программиста. Пользователям ее показывать не стоит.

Использовать аналитику в бухуучете для управленческого учета самое правильное решение. Но не все фирмы нуждаются в бхучете. Хотя, наверное, в любом случае это правильное решение. Упрощение практически всегда ведет к усложнению.

Хотели как лучше (проще), получилось как всегда (сложнее) (с) Черномырдин

guest_20040621,

Ладно, погорячился, беру свои слова обратно. Бывает у меня иногда такое.

guest_20040621> Аргументируйте!

Что аргументировать? Ладно бы, какой-нибудь первоклассник это написал, но вы-то представляете разницу между планом счетов, жизненными циклами сущностей, экземпляров сущностей и процессами?

Я вообще-то не смешиваю между собой учет объектов учета, любой, и бизнес-процессы. Для этих двух вещей использую разные движки. Для бизнес-процессов BPMS, а для учета учетный движок (интересно, есть ли для него аббревиатура англоязычная или хотя бы наша)

_мод,

не обязательно для едной структуры документов использовать EAV, мне удалось сделать единую структуру без него. И, поверьте, это не добавление полей на все случаи жизни. Имеются ввиду оперативные документы.

_мод,

Зачем настраивать документы? Они стандартные по госту. Приходный ордер, Требование-накладная, Счет-фактура. Что тут настраивать?