|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Присоединюсь к топику следующей мыслью. Есть поля документа, которые после "проведения/утверждения/постирования/изменения статуса" можно поменять, есть которые нельзя. Best practice говорит, что удалять физически документ с проводками не стоит. Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна, Еще отдельно несите дебиторов, кредиторов, банк, основные средства, признаки и объекты управленческого учета. Смотрите как устроен SAP = мудрость (после 1С) ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:49 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
LunxСмотрите как устроен SAP = мудрость (после 1С) Весьма бездарно SAP устроен, не надо ля-ля. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 12:58 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
sergey888 Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-) и что делать? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:04 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов LunxСмотрите как устроен SAP = мудрость (после 1С) Весьма бездарно SAP устроен, не надо ля-ля. По теме двух веток у меня зародилась мысль что сергей все таки разработал идеальную систему... Я прямо таки жду презентации - скоро закроются мягкие и сапы - это ли не план Путина!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:04 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
простите за оффтопик - накипело!!! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:07 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
niki4550148По теме двух веток у меня зародилась мысль что сергей все таки разработал идеальную систему В части, обсуждаемой в топике, ее можно улучшить не намного. Про идеальность я не утверждал. Ошибки в известных системах есть и повторять их у себя причин не вижу. На всякий случай комментарии "саперу" и Вам тоже. LunxBest practice говорит, что удалять физически документ с проводками не стоит. Здравая логика говорит, что возможность или невозможность удаления документа никак не связана с наличием или отсутствием у него проводок, а определяется исключительно статусом документа (ну и полномочиями пользователя). LunxМысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета? LunxЕще отдельно несите дебиторов, кредиторов, банк Куда "нести"? Если разнести отдельно - тоже спорная тема, на пустом месте придумать себе задачу сопоставления дебиторов и кредиторов и доблестно ее решать. У меня одно и то же предприятие может быть и дебитором, и кредитором, и банком (реквизиты его вводятся один раз в одном месте, для непонятливых), все взаиморасчеты выполняются как 2 пальца. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:41 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Ivan Durak sergey888Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-) В ОУ даже сложно придумать корректное обоснование необходимости формирования проводок. А уже об их откате и говорить не приходится. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:42 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Ivan Durak sergey888 Вообще в бухгалтерии нет "отката" проводки. Делается сторнирующая проводка. А в оперативном учете есть :-) и что делать? Пример в студию. Вариант с ошибкой оператора не предлагать! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:47 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов [quot Lunx]Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета? А Вы хотите сказать что по видам учета разделять не надо ? Даже если Вы и придумаете еще 10 видов учета - это наоборот удобно. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 13:57 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
PiterBest Сергей Васкецов [quot Lunx]Мысль разносить по разным таблицам разные части учета (бух, налоговый, оперативный) - весьма плодотварна Она бесконечно бредова по сути. Что Вы будете делать при добавлении еще 5-10 видов учета? А Вы хотите сказать что по видам учета разделять не надо ? Я хочу сказать, что не надо разносить по разным таблицам . PiterBestДаже если Вы и придумаете еще 10 видов учета - это наоборот удобно. То есть, добавлять новые таблицы, изменять логику работы системы и писать новые отчеты при добавлении нового учета - это "удобно"? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:00 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Необходимость организации ведения разных таблиц для разных видов учета продиктова требованем к скорости обработки данных. Как пример - дебиторская задолженность. В SAP погашение задолженности например пишется в главную книгу общей суммой, а в книгу дебиторов - с выравниванием по открытым позициям. Для чего это надо. При составлении баланса (главная книга) нужны данные только по обороту, сальдо счета, информация по каждой отдельной позиции - лишняя. При составлении же акта взаиморасчетов - без нее никак. Выражается это в том, что у нас есть SELECT на разные таблицы, в зависимости от контекста и условие стоит не счет=выбранный счет когда Вы все пишите в главную книгу, где счетов мильен, а дебитор=выбранный дебитор где дибиторов - ну сколько бедиторов у компании. Желание свалить все в кучу говорит о том, что человек не занимается оптимизацией скорости выборок. На Ваш вопрос - если поялвяется еще 10 видов учета - да, надо делать 10 новых таблиц и писать функционал на них. Как пример - учет дебиторской задолженности в 1С - один регистр - сводный по суммам, второй по открытым позициям, срокам платежа. В этом смысле 1С растет (причем старается в сторону SAP, вроде). ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:18 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
LunxНа Ваш вопрос - если поялвяется еще 10 видов учета - да, надо делать 10 новых таблиц и писать функционал на них. Как пример - учет дебиторской задолженности в 1С - один регистр - сводный по суммам, второй по открытым позициям, срокам платежа. В этом смысле 1С растет (причем старается в сторону SAP, вроде). Дальнейшее обучение индивидуумов, искалеченных SAP-ом и 1С-ом, буду проводить за деньги. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:23 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
To Бизон: >Вы предлагаете по сути разделит на две базы. Основная рабочая и архивная? Нет :) Посмотрите, как устроены нормальные базы данных (MS, Oracle, Postgres). Таблицы создаются не просто в базе данных, а в одной из схем базы. Зачем схемы - читайте умные книги и пр. Например, для приема, о котором я говорил выше. Насчет проведения. PostgreSQL. В таблице ТаблицаДокументов есть колонка REGISTERED - флажок проведен-нет и колонка ID. Код: 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.
И что тут обсуждать ? Один триггер и 3 функции ? Посему совет Бизону - сначала изучите базовые возможности выбранной Вами СУБД, а потом двигайтесь к цели. А если будете логику на клиенте делать - получите еще одну 1С, только хуже ! ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 14:36 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Если я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:06 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонА как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. 1. Что значит "провели"? Если говорить о бухучете, то никто не мешает проверять и утверждать проводки в конце учетного периода, а не в онлайне. 2. Что мешает разутвердить документ, исправить его и утвердить заново? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:25 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов БизонА как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. 1. Что значит "провели"? Если говорить о бухучете, то никто не мешает проверять и утверждать проводки в конце учетного периода, а не в онлайне. 2. Что мешает разутвердить документ, исправить его и утвердить заново? Чухня. Мешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:33 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонЕсли я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. А деньги уже проплатили за товар? если проплатили, то как будете возвращать переплаченную сумму? Кто подписал договор с этим поставщиком? В таких случаях надо выгонять коммерческого директора, т.к. явно просмартивается сговор с поставщиком, а вы вместо этого пытаетесь автоматизировать процесс отмывания денег. В когда в магазине товар покупаете, то сразу его оплачиваете. Даже если продавец ошибся с ценой, то он не придет к Вам домой чтобы вернуть то, что вы переплатили. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:35 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
LunxМешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом. Ну и в топку этот принцип, если он жить мешает. Если система не умеет корректно проводить изменения задним (передним :)) числом - в топку эту систему. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:35 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Бизон скромное предложение...возьмите за основу самую распространенную практику (см. рис) - надежно - практически безразмерно для расширения - просто в реализации Основные правила, вкратце: - данные учета - таблица(ы) фактов с необходимыми для целей учета и отчетности измерениями. - вся отчетность формируется только по данным учета, забудьте на время что есть какие-то документы и прочие источники данных - документ = источник данных, регистратор событий, фактов - Процедура учета выполняет конвертацию данных документа (или другого источника данных) в структуру данных учета (учетного регистра если нравится) - учет может быть многоуровневый, т.е. учет одного документа формирует таблицу фактов №1, если учет выполнен, на основании учтенных данных может формироваться таблица фактов №2 и т.д. - учет может быть многоплановый, т.е. один и тот же документ может быть отражен параллельно в более чем одной таблице фактов. - Учтенный документ недоступен для изменения, чтобы изменить документ необходимо отменить его учет - Процедура отмены учета отслеживает возможность внесения изменений Появляются новые документы или требуются новые структуры фактов - внесение изменений довольно простая процедура, не требующая останова. По поводу того, удалять или помечать записи учета как недействительные - как нравится. Если не нужно хранить историю - удаляйте, нужно - помечайте. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 15:50 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Сергей Васкецов LunxМешает принцип - согласно которому проведенный документ можно только сторнировать, а не исправлять задним числом. Ну и в топку этот принцип, если он жить мешает. Если система не умеет корректно проводить изменения задним (передним :)) числом - в топку эту систему. А разве сторнирование не является исправлением ошибки? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:01 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
sergey888 БизонЕсли я правильно понял предложенный Вами механизм. Вы предлагаете использовать только одно состояние документа и после его утверждения не менять. Все дальнейшие операции проводить только сторнированием? А как быть например, есть приходная накладная мы приняли товар. Записали. Провели. Через день приходить ее замена ошиблись с ценой. А деньги уже проплатили за товар? если проплатили, то как будете возвращать переплаченную сумму? Кто подписал договор с этим поставщиком? В таких случаях надо выгонять коммерческого директора, т.к. явно просмартивается сговор с поставщиком, а вы вместо этого пытаетесь автоматизировать процесс отмывания денег. В когда в магазине товар покупаете, то сразу его оплачиваете. Даже если продавец ошибся с ценой, то он не придет к Вам домой чтобы вернуть то, что вы переплатили. Не проплатили. А если наоборот он осталься должен. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:04 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
sergey888А разве сторнирование не является исправлением ошибки? :) Методов исправления ошибок много, например, сделать с нуля новую БД и заново все ввести. Сторнирование - это операция изменения чего-то, что менять напрямую нельзя, но очень хочется, она имеет свою дату, отличную от даты сторнируемой операции. Ограничивать сторнирование только лишь исправлением ошибок не стоит. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:14 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
БизонА если наоборот он осталься должен. Разноска платежей вообще-то отдельная операция. И уж тем более в ней нечего делать складским документам. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:15 |
|
Схемы построения учетной системы. Нужна критика.
|
|||
---|---|---|---|
#18+
Предлагаю разобраться на примере конкретной операции. Сидит оператор на складе, ему принесли приходную накладную. Вводит. Нажимает кнопку «ОК». Указанное количество товара соответственно увеличивает остатки на складе товара. Сумма в накладной увеличивает наш долг поставщику. На следующий день поставщик нашел ошибку, не по той цене отгрузил. Присылает замену. А может только в конце месяца. На цену товара плевать всем. Никто ее не контролирует. Работа с поставщиком идет по договору, оплата в конце месяца. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2007, 16:27 |
|
|
start [/forum/topic.php?fid=33&msg=34967839&tid=1548931]: |
0ms |
get settings: |
9ms |
get forum list: |
17ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
235ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 291ms |
total: | 628ms |
0 / 0 |