|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичБыл бы просто счастлив ! Тем не менее, "проводки" (правда только некие "основные") Вы храните не в "отдельной таблице", то есть "в основном" со мной согласны. Но нарываетесь именно Вы, а я Вас смешивать ни с чем не буду. Если будете и дальше нарываться, то сами себя смешаете. Ладно, не будем ругаться. 1. Независимая основная проводка. Это естественная проводка. Напр.,получили от поставщика материал - д10,к60. 2. Вторичная автопроводка. (Разбивают основную или начисляются на их основе) Выделили НДС. д19,к60. При этом могут появиться подспудные субъекты , по которым надо вести учет. Количество проводок и субъектов могут варироваться. 3. Вторичная зависимая автопроводка. При оплате - д60,к51 появляется вторичная проводка к68,д19 в зависимости от 2 (зависит от другог первичного документа). При этом могут появиться подспудные субъекты , по которым надо вести учет. Количество проводок и субъектов могут варироваться. 4. Зависимая основная проводка. д10,к60(субъект1) и д60(субъект2),к51 ->д60(субъект1),к60(субъект2) Основная проводка базируется на первичных документах. Генерация вторичных и зависимых просто. Основная проблема - подспудные субъекты. Решается путем приписки счетов к субъектам. Напр, счет 19 - приписан "Мы", а 68 - "Налоговая инспекция ... уезда". Для ведения активных инвентарных счетов (материалы, товар, ГП, ...) в целях аналитического учета хватает независимой основной проводки. А для синтетического учета нужны все проводки. Зачем держать Основную независимую проводку в теле операции? 1. Упрощается генерация ОНП. (Обычно зависит от типа документа и типа субъектов). Где-то 100% , а где-то выбор из субсчетов. 2. Упрощается получения смешаннай отчетности типа, "Там-то, на счете таком то, во насколько всякой херни." Почему не надо держать другие проводки в теле операции? 1. Усложняется получения отчетности типа, "Там-то, на счете таком то, во насколько всякой херни." 2. Усложняется стыковка операций. 3. В тех случаях, когда нет первичных документов (износ ОС, зарплата), приходится ввести псевдодокументы. ..... n. Невозможно отделить синтетический учет от аналитической. n+1!!! Невозможно отделить аналитический учет от синтетической (ИП - я просто закрываю таблицу проводок и убираю поля д,к из тела операции). Конечно, всу эту хреновину можно сунуть в какие-нибудь XML поля и спокойно работать. Раньше нелзя было, а самому парсить было неохота. Сейчас можно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2006, 14:42 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Понятно. Сильное влияние БУ на проектные решения, о чем я и говорил. Для "аналитического учета" не нужно никаких проводок в принципе, даже "основных". Но для этого именно в операциях должны присутсвовать все данные. В частности, для "аналитического учета" по поставщикам, или, как Вы сказали "для ведения", но не 10-го, а активно-пассивного (или пассивного, если использовать 61) 60-го не достаточно Вашей "основной проводки". Получается не целостная картина. Далее: зачет налогов - это тоже операция, которая порождается автоматически при выполнении некоторых условий (конечно, не просто в связи с оплатой, но эта Ваша неточность не принципиальна), и используется в аналитических отчетах безо всяких проводок. И по этой операции делаются проводки, как и по операции оприходования. "Почему не надо держать другие проводки в теле операции ?" - мне кажется не корректной постановкой вопроса. Правильнее объяснить себе почему суммы налога нет в операции, почему вообще нет операции зачета налога, и т.п. Понять пункты 1,2,3,n,n+1 Вашего объяснения я не смог. У меня никогда не возникало проблем "стыковки операций", операцию начислений износа я считаю полноправной, а не псевдо (это в БУ документа нет, но в БД он есть, и совершенно стандартный, как и ТТН, например), я против прилагательных к слову "учет", но "синтетический" и "аналитический" учеты (то есть то, что под ними традиционно понимается) намного лучше сосуществуют при размещении "проводок" в операциях, и т.д. Мне кажется Ваши решения концептуально не ориентированы на корпоративный уровень. И еще раз повторю - надеюсь, что от проводок удастся избавиться полностью. P.S. Насколько я понимаю, все что Вы наработали - все в одиночку. Это впечатляет. Я бы не смог. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2006, 19:43 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичПонятно. Сильное влияние БУ на проектные решения, о чем я и говорил. Для "аналитического учета" не нужно никаких проводок в принципе, даже "основных". 1. Вы не работали с бухами. Им мало того, "что на складе чего то в таком то количестве на такую то сумму" - "на каком счете", "с какого счета" и т.д. - объязательно. 2. Частенко склады (обычно виртуалбные) - смешанные. Чернышев Андрей Леонидович Но для этого именно в операциях должны присутсвовать все данные. В частности, для "аналитического учета" по поставщикам, или, как Вы сказали "для ведения", но не 10-го, а активно-пассивного (или пассивного, если использовать 61) 60-го не достаточно Вашей "основной проводки". Получается не целостная картина. Я же написал - полная аналитика + ОНП достаточна для получения смешанной отчетности (ситетика+аналитика) по не расчтено-распределительным, компенсационным счетам. Чернышев Андрей Леонидович Далее: зачет налогов - это тоже операция, которая порождается автоматически при выполнении некоторых условий (конечно, не просто в связи с оплатой, но эта Ваша неточность не принципиальна), и используется в аналитических отчетах безо всяких проводок. И по этой операции делаются проводки, как и по операции оприходования.??? Это был именно пример. Чернышев Андрей Леонидович "Почему не надо держать другие проводки в теле операции ?" - мне кажется не корректной постановкой вопроса. Правильнее объяснить себе почему суммы налога нет в операции, почему вообще нет операции зачета налога, и т.п. Если пойти по пути "операций", то "Бухгалтерия" никогда не напищете. Чернышев Андрей Леонидович Понять пункты 1,2,3,n,n+1 Вашего объяснения я не смог. Это и есть влияние БД и отчетных систем, как вы изволили заметить. Чернышев Андрей Леонидович У меня никогда не возникало проблем "стыковки операций", операцию начислений износа я считаю полноправной, а не псевдо (это в БУ документа нет, но в БД он есть, и совершенно стандартный, как и ТТН, например), Все операции (документы) ЖЦ объекта стыкуются. Износ (не только) - самое слабое место в бухучете(нашем). Неестественное. Которая приводит к появлению компеннсмрующих счетов. Что в свою очередь перечеркивает все попытки совместить аналитический и синтетический учет. Чернышев Андрей Леонидович я против прилагательных к слову "учет", но "синтетический" и "аналитический" учеты (то есть то, что под ними традиционно понимается) намного лучше сосуществуют при размещении "проводок" в операциях, и т.д. Синтетический учет - хорошо продуманная вещь. Дает свободу бухгалтеру. И намного информатинее, чем смешанный. В принципе это и есть "бухгалтерский учет". А аналитический - инвентарный. Чернышев Андрей Леонидович Мне кажется Ваши решения концептуально не ориентированы на корпоративный уровень. Я и не жду, что кто-нибудь скажет - Сахават - человек. Букашка - да. Это мы умеем. [/quot] Чернышев Андрей Леонидович И еще раз повторю - надеюсь, что от проводок удастся избавиться полностью. Проводка - свобода маневра. Реструктуризация!!! Избавившисть от нее избавитесь от сути бухучета. Хорошо это или плохо - вам судит. Чернышев Андрей Леонидович P.S. Насколько я понимаю, все что Вы наработали - все в одиночку. Это впечатляет. Я бы не смог. Попробуйте. Не так все сложно. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.08.2006, 21:41 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Я работаю с "бухами" много лет. Они образованные люди, и понимают (постепенно), что в результате операций изменяются вполне объективные учетные величины, а не "счета". Государство, в целях стандартизации, унификации (для облегчения контроля за подданными) просто "сказало": вот эту величину вы должны обозначать цифрами 4 и 0. А потом оно "подумало" и "сказало": а теперь, подданные, эту величину вы должны обозначать цифрами 4 и 3. Зря Вы так беспокоитесь о "счетах". Продвинутые "бухи" о них уже давно не беспокоятся. "Проводки" автоматически делаются и делаются... И "бухи" любые свои (то есть государственные) отчеты получают. Что значит "я же написал" ? У Вас одна составляющая "долга" перед поставщиком хранится в операции, а другая в проводке. Это не целостно, и не допустимо, если Вы строите корпоративную систему. А если некую "бухгалтерскую", то тут я ничего не могу сказать - это просто не интересно. И все равно приводит к проблемам типа "смешанной отчетности"... Что значит "это был именно пример" ? У Вас есть операция зачета НДС (а не проводка) или нет ? Операции (факты) не "стыкуются" а "регистрируются". Поскольку все "участники" операции (в том числе и у Вас ?) идентифицированы, никаких проблем со "стыковкой" просто не может быть. "Износ" не слобое место. Слабое место "балансовая стоимость". А самое "слабое место" - неспособность (может быть и умышленная) чиновников определить эффективные объекты налогообложения. Глупее "прибыли" вряд ли можно придумать. Ведь она зависит от себестоимости, и государство начинает вольно или невольно "управлять" себестоимостью продукции. Налог на добавленную стоимость тоже "элегантно" выглядит при наличии налога на прибыль - ведь добавленная стоимость состоит в том числе из прибыли. А если учесть, что стоимость продукции состоит только из стоимости труда (а вовсе не из "износа", "стоимости сырья" и т.п.), то ... лучше не расстраиваться... НО ! Государство - это объективная реальность. И его существование благодаря налогам - тоже. НДС - не "бухгалтерская выдумка" и должен присутствовать в объективных операциях, а не просто в "бухгалтерских проводках". Теперь я практически уверен, что Вы заблуждаетесь в сути учета, раз говорите, что приписанные к зарегистрированной операции, и ничего не изменяющие по сути, значки К 60 Д 10 это "свобода маневра" и "реструктуризация". "Бухгалтерский учет", мне кажется, завел Вас в тупик, и перечеркнул Ваши "попытки совместить аналитический и синтетический учет". Зачем же мне пробовать создавать столь сложные системы в одиночку, если в коллективе все получается быстрее и качественнее... ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2006, 20:34 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей Леонидович Я работаю с "бухами" много лет. Они образованные люди, и понимают (постепенно), что в результате операций изменяются вполне объективные учетные величины, а не "счета". Государство, в целях стандартизации, унификации (для облегчения контроля за подданными) просто "сказало": вот эту величину вы должны обозначать цифрами 4 и 0. А потом оно "подумало" и "сказало": а теперь, подданные, эту величину вы должны обозначать цифрами 4 и 3. Зря Вы так беспокоитесь о "счетах". Продвинутые "бухи" о них уже давно не беспокоятся. "Проводки" автоматически делаются и делаются... И "бухи" любые свои (то есть государственные) отчеты получают. Когда-нибудь вы поймете красоту синтетического учета и свободу "образованного буха" в контексте оной. Государство(дебильные законы об НДС и прибыли,...) и бухучет не совместимы. Налоговый учет должен естественно (по сути и по форме) интегрироваться в бухучет. Для этого должные отменяться все налоги с оборота. Налог должен быть либо на потребленте, либо на имущество, либо на рост стоимости бизнеса. В БУХУЧЕТЕ НИЧЕГО НЕ ДОЛЖНО РАССЧИТЫВАТЬСЯ СЛОЖНЫМ ПУТЕМ. Чернышев Андрей Леонидович Что значит "я же написал" ? У Вас одна составляющая "долга" перед поставщиком хранится в операции, а другая в проводке. Это не целостно, и не допустимо, если Вы строите корпоративную систему. А если некую "бухгалтерскую", то тут я ничего не могу сказать - это просто не интересно. И все равно приводит к проблемам типа "смешанной отчетности"... То, что храниться в "теле операции" дублируется в "проводках". "Проводки" полны синтетически, "тела" - аналитически с избыком в сторону синтетики. Чернышев Андрей Леонидович Что значит "это был именно пример" ? У Вас есть операция зачета НДС (а не проводка) или нет ? У меня вообще нет оперций. Есть документы и проводки на основе оных. Чернышев Андрей Леонидович Операции (факты) не "стыкуются" а "регистрируются". Поскольку все "участники" операции (в том числе и у Вас ?) идентифицированы, никаких проблем со "стыковкой" просто не может быть. Все сложности возникают во время откатов или "справок-сторнировок". Чернышев Андрей Леонидович "Износ" не слобое место. Слабое место "балансовая стоимость". А самое "слабое место" - неспособность (может быть и умышленная) чиновников определить эффективные объекты налогообложения. Глупее "прибыли" вряд ли можно придумать. Ведь она зависит от себестоимости, и государство начинает вольно или невольно "управлять" себестоимостью продукции. Налог на добавленную стоимость тоже "элегантно" выглядит при наличии налога на прибыль - ведь добавленная стоимость состоит в том числе из прибыли. А если учесть, что стоимость продукции состоит только из стоимости труда (а вовсе не из "износа", "стоимости сырья" и т.п.), то ... лучше не расстраиваться... НО ! Государство - это объективная реальность. И его существование благодаря налогам - тоже. НДС - не "бухгалтерская выдумка" и должен присутствовать в объективных операциях, а не просто в "бухгалтерских проводках". Я написал - "износ(не только) слабое место". Вообще, слабое сесто бухучета - "себестоимость, прибыль". Эти вещи расчетные, что противоестественно для бухучета. "себестоимость, прибыль" - абсолютная туфта для более-менее сложного бизнеса. Должна быть "стоимость бизнеса". Чернышев Андрей Леонидович Теперь я практически уверен, что Вы заблуждаетесь в сути учета, раз говорите, что приписанные к зарегистрированной операции, и ничего не изменяющие по сути, значки К 60 Д 10 это "свобода маневра" и "реструктуризация". "Бухгалтерский учет", мне кажется, завел Вас в тупик, и перечеркнул Ваши "попытки совместить аналитический и синтетический учет". На счет значков - как хотите. Реформацию баланса никто не отменял. Один период может характеризироваться разными структурами и валютами баланса. Следующий период начинается с УТВЕРЖДЕННОГО баланса, что откладывает сильную тень на "математику" бухучета. Чернышев Андрей Леонидович Зачем же мне пробовать создавать столь сложные системы в одиночку, если в коллективе все получается быстрее и качественнее... Дай бог! Коллектив, так коллектив. Деньга то все равно в рознь и сомооценка и "реальная оценка" и возраст, и Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.08.2006, 22:56 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичУверяю Вас, ModelR, затраты минимальны, только огромное сопротивление. За три приема добрался до того, что бухгалтеры больше не смогут делать бухгалтерские проводки (полный автомат), и больше не будут описывать типовые проводки (этого удалось давно, и это очень важно). Возможно последним шагом будет полный отказ от "проводок". Чтобы закончить "конкретику": дата и сумма, конечно, из операции. Да, в операции могут быть "бухгалтерские", "управленческие", "налоговые" даты и суммы - это не меняет сути дела (к тому же ВСЕ эти прилагательные к учету, как мы помним, субъективны). Что же остается "своего" в "проводке" ? Кредитуемый и дебетуемый "счета" ? Это ради них люди сооружают "отдельные таблицы", и "тащат" туда даты, суммы, и что-то еще из объективных операций (тоже ведь денормализация - дублирование)? Несложный анализ показывает, что это плохое архитектурное решение. Думаю, что важной причиной недостатков "корпоративных систем" является подверженность проектировщиков влиянию прилагательных "бухгалтерский", "управленческий", "производственный" и др. к концепции "учета". То же самое можно сказать и о "планировании". Парадоксально, но многие специализированные "учетные системы" (платформы), например, 1с, плохо приспособлены даже для бухгатерского (!) учета именно по той причине, о которой я сказал.Да нет тут никакой Америки. Все это уже проходили: убрать бухгалтеров на фиг - вся их деятельность регламентирована, осталось только запрограммировать. Увы, факт что одни и те же документы могут иметь разную интерпретацию. Уже упомянутый НДС - брать или не брать его к зачету на основании данной счета-фактуры (у Вас тут подчистка! Да это клякса, грузчики грязными руками.. Или адрес написан не полностью, Или дата январская а форма=то пршлогодняя будем звонить поставщику - дату менять или форму. и т.д. ) ? Кто отвечает за это решение? - бухгалтер. А как это связано с количеством на складе? - никак. Поэтому вопрос где-то филофсофский. Или мы верим в то, что можно добиться должного качества первички и полной автоматизации, или нет и заранее идем на возможность рассогласования (стремясь конечно свести его к минимуму) бухгалтерской интерпретации с оперативной. На сегодня реально работающие системы построены по пессимистическому варианту. Типа строки документа - это одна таблица, а складские операции, бухгалтерские операции по этим строкам - еще две таблицы. Уровнь дублирования очень высок, да. Но система гораздо живучее. Например, можно разрешить править документ, при этом прибить складские но сохранить бух. записи. После поправки провести заново по складу, а по бух. оформить сторнировку/ допроводку. Если же речь о том, чтобы эти три комплекта записей физически свести в единственную сущность и назвать ее операцией, то это скорее вопрос конкретной СУБД - где что эффективнее. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 10:47 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
ModelRНа сегодня реально работающие системы построены по пессимистическому варианту. Типа строки документа - это одна таблица, а складские операции, бухгалтерские операции по этим строкам - еще две таблицы. Уровнь дублирования очень высок, да. Но система гораздо живучее. Например, можно разрешить править документ, при этом прибить складские но сохранить бух. записи. После поправки провести заново по складу, а по бух. оформить сторнировку/ допроводку. Дело даже не в пессимизме. Чернышев все пытается выдать за какое-то ноу-хау разноску проводок "на лету" по записям операций. Вариант безусловно имеет право на жизнь, но в строго оговоренных условиях. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 12:13 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
ModelR Чернышев Андрей ЛеонидовичУверяю Вас, ModelR, затраты минимальны, только огромное сопротивление. За три приема добрался до того, что бухгалтеры больше не смогут делать бухгалтерские проводки (полный автомат), и больше не будут описывать типовые проводки (этого удалось давно, и это очень важно). Возможно последним шагом будет полный отказ от "проводок". Чтобы закончить "конкретику": дата и сумма, конечно, из операции. Да, в операции могут быть "бухгалтерские", "управленческие", "налоговые" даты и суммы - это не меняет сути дела (к тому же ВСЕ эти прилагательные к учету, как мы помним, субъективны). Что же остается "своего" в "проводке" ? Кредитуемый и дебетуемый "счета" ? Это ради них люди сооружают "отдельные таблицы", и "тащат" туда даты, суммы, и что-то еще из объективных операций (тоже ведь денормализация - дублирование)? Несложный анализ показывает, что это плохое архитектурное решение. Думаю, что важной причиной недостатков "корпоративных систем" является подверженность проектировщиков влиянию прилагательных "бухгалтерский", "управленческий", "производственный" и др. к концепции "учета". То же самое можно сказать и о "планировании". Парадоксально, но многие специализированные "учетные системы" (платформы), например, 1с, плохо приспособлены даже для бухгатерского (!) учета именно по той причине, о которой я сказал.Да нет тут никакой Америки. Все это уже проходили: убрать бухгалтеров на фиг - вся их деятельность регламентирована, осталось только запрограммировать. Увы, факт что одни и те же документы могут иметь разную интерпретацию. ... На сегодня реально работающие системы построены по пессимистическому варианту. .... Присоединяюсь. Более того, жизнь показывает, что определить все "операции" изначально раз и навсегда - утопия... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 17:31 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Ой, я под "левым" ником!!! Ну, да ладно... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 17:32 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Итак, проводки дублируют операции, которые у Вас, каким-то загадочным образом "не полны синтетически". Будто-бы в "проводках" (Ваших) есть нечто, чего нет в "операциях" (Ваших), что делает их (проводки) "полными". Что там есть неизвестно. Как могут значки "Кр" и "Дб" обеспечить "полноту", "красоту" и "свободу" Вы объяснить не можете, но я начинаю подозревать, что проводки у Вас вручную делаются (для "красоты" и "свободы"). Операций у Вас нет. Замечательно. При этом "основные проводки" хранятся в "теле операции", которой нет. Теперь видимо так: "основные проводки" хранятся в "теле документа", а "дополнительные" в "отдельной таблице". Хорошо. У Вас есть сумма НДС в "документе", а не в "отдельной проводке" ? У Вас есть "документ" зачета НДС, а не "отдельная проводка" ? Никаких сложностей даже теоретически не может быть при "откатах", если система строится на учете объективного движения, а не на основе "бухучета". Про "сильную тень на "математику" бухучета" мне трудно понять, ведь "математика бухучета" настолько тривиальна, что: 1) на нее сложно навести какую-либо тень; 2) проводки просто бессмысленно отделять от объективных операций. Большое спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 20:43 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Удивительно, ModelR, слышать такие странные (это точнее, чем пессимистические) мысли от человека, занимающегося, в той или иной степени, автоматизацией учета. Если что-то не так, то специалист (это и не бухгалтер, и не программист, конечно же) просто не введет (например) дату поступления счета, и зачет не сделается. Или введет, а потом исправит свою ошибку, и зачет автоматически отсторнируется. И проводки здесь совершенно не при чем. Непонятно о каких трудностях Вы толкуете. Все операции, ###, давно раз и навсегда определены - не знать этого просто неприлично. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 20:54 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Обругали меня: "Правильно - ни при чем." ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 20:58 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей Леонидович Все операции, ###, давно раз и навсегда определены - не знать этого просто неприлично. Простите, у Вас большой опыт УПРАВЛЕНИЯ предприятием? По мне так - неприлично когда теоретик, не имеющий ПРАКТИЧЕСКОГО опыта начинает поучать других... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 21:59 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
iscrafm Чернышев все пытается выдать за какое-то ноу-хау разноску проводок "на лету" по записям операций. Вариант безусловно имеет право на жизнь, но в строго оговоренных условиях. Следствия из мыслей господина Чернышева поглобальней, на мой взгляд. В скольких таблицах хранить, какие производные понятия и расчеты хранить, а какие считать онлайн – это дело прикладно важное, но десятое. Дублирование плохо только тогда, когда им заведуют люди, во всех остальных случаях оно вводится (чаще по глупости, конечно, и сложности охвата комплексной модели) для ускорения, так как не место же на диске и в памяти экономим. Если имеется целостная модель данных, в которой однозначно известно, что из чего выводится и как, где все места объективных противоречий (типа того, что считать «фактом» учета – к примеру, факт материального складского учета, или факт учета операции бухгалтером после проверки принимаемости бумажной СФ налоговой, или оба сразу, но при определенных условиях, в определенном порядке) сняты, то все стыкуется, и автоотматывается, сторнируется, перематывается на произвольную глубину. Короче, само по себе дублирование безобидно, если известно, что это за дублирование (не только программисту, его введшему). А в будущем – будет полезно, когда СУБД научатся произвольной длины транзакции произвольного содержания туда-сюда отматывать по надобности. ModelR Уже упомянутый НДС - брать или не брать его к зачету на основании данной счета-фактуры (у Вас тут подчистка! Да это клякса, грузчики грязными руками.. Или адрес написан не полностью, Или дата январская а форма=то пршлогодняя будем звонить поставщику - дату менять или форму. и т.д. ) ? Кто отвечает за это решение? - бухгалтер. А как это связано с количеством на складе? - никак. Поэтому вопрос где-то филофсофский. Какие проблемы, можно же и деятельность ручного «бухгалтера», заканчивающуюся «утверждением» всей предыдущей истории по данному «факту» вплоть до полного его пересмотра, считать «операцией». То есть я присоединяюсь к "вопрос философский", правильней сказать - организационный - как принято, как можно нагнуть конкретную организацию, в каких условиях она находится (к примеру, если организация не считает копейки, и вопрос имеет место только при крупных суммах НДС, то все документально не подтвержденное, не считается "фактом", а значит, никакого другого "факта", кроме факта бухгалтерского учета и нету). Более серьезные "философские вопросы" возникают, когда имеется несколько противоречивых взглядов (у разных субъектов, подсистем ИС) на один и тот же "факт". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.08.2006, 23:01 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичВсе операции, ###, давно раз и навсегда определены - не знать этого просто неприлично. Возникновение налогооблагаемой базы по НДС и восстеновление его за последние пару лет менялись в деталях несколько раз, причем коренным образом. Даже в казавшееся столь незыблемым ПБУ 6/01в конце прошлого года были внесены изменения, причем в самую существеннуб часть, а именно, в тот раздел, который описывает условия, при которых актив принимается к учету в качестве основного средства. Как реально учитывать ПБУ 18/02, похоже, сам МИНФИН не знает. А у Вас все определено раз и навсегда? LOL. В общем, идея Ваша понятна стала, все без исключения данные для всех учетов держите в самом документе. Все проблемы "негибкости" учета решаете по факту возникновения таковых. Еще напишу следующее: 1. В проводках не только синтетический учет. А в случае множества учетов в одной системе в одной рабочей БД - даже и не столько. В принципе, абсолютно все можно реализовать на основании плана счетов с подсчетом и контролем остатка по счетам, даже склад можно сделать без складов, поэтому, можно всегда идти от обратной задачи, то есть, изначально вводить все в проводках. Но так ведь никто не делает. Не задумывались, почему? Дело не просто в большом объеме вводимой информации. Дело в нецелесообразности иметь всю информацию для учета в первичных документах (что бы ни называлось первичным документом). Как раз это и будет избыточностью. Например, параметры складского учета задаются не для конкретной номенклатуры, а для группы ТМЦ. Но никто рядом с номенклатурой в документах не вводит дополнительно ее группу. Потому что ее всегда можно получить из номенклатурного справочника. Для параметров учета, которые могут неняться со временем, настраиваются различные "схемы", например, бессмысленно вводить счет хранения в каждом документе склада. но, по идее, для одной и той же номенклатуры/группы ТМЦ он может меняться. Что, делать поле в документе? Глупо. Поддерживать версионность всех без исключения полей во всех без исключения справочниках? Не менее глупо. Остается простое решение - счет хранения использовать в проводках, а обороты по нему считать по проводкам со всей необходимой аналитикой. Вот вам пример, когда целесообразно аналитику иметь только в проводках, и не иметь ее в документе (на самом деле, есть более хитрая реализация задачи учета версионности счета хранения). Еще пример - аналитика по местонахождениям, видам деятельности и пользователям основных средств (хотя, как правило, этой аналитики на порядок меньше). 2. Плюс от дублирования информации в проводках в требуемой части - перенос сальдированного остатка по счетам в объеме всей требующейся аналитики, если используется только входящее сальдо. Вам же, если Вы это захотите сделать, придется делать документ (операцию). Например, переоценка валютных счетов как у Вас происходит. Или у Вас нет таких операций? А еще, запросы отдельно к документу и отдельно к его проводкам не будут коррелировать, что позволяет реально снизить конкуренцию за блокировки таблиц в "нагруженных" системах. 3. У Вас документы имеют статус(ы)? Как, например, определить, что в УУ событие совершилось, а в БУ/НУ еще нет? Я, например, утверждаю документ, и только после этого можно утвердить проводки. Разутверждение - наоборот. Если в УУ событие отражено корректно, а в БУ некорректно (например, с ошибкой), то достаточно разутвердить только проводки, а сам документ не трогается. Потому вся цепочка документов остается. Или у Вас не бывает ошибок, которые обнаруживаются "потом"? Или у Вас нет цепочек документов? 4. Начальство скажет примерно следующее "Начиная с 1 января следующего года начинаем вести дополнительно учет по МСФО". А еще через год - "У нас появляется отделение в Эфиопии, поэтому будем вести учет и по ЭСФО, причем, для всего концерна, а не только для филиалов в Эфиопии". Полезете добавлять пачками поля в документ? А еще, если необходимо иметь отчетность в валюте N зарубежных филиалов, у всех стран которых различная валюта, будете делать N валют/сумм в документе? А такие вопросы в правильно спроектированных масштабируемых и настраиваемых системах решаются "на раз-два-три". 5. При использовании репликации во многих случаях для учета деятельности достаточно реплицировать проводку по документу, а не сам документ. При десятке тысяч документов даже между десятком филиалов траффик наэкономите значительно больше, чем стоит еще один диск и слот памяти. В общем, я бы Ваше решение охарактеризовал как "наколенное". Если оно Вас и Ваших заказчиков устраивает - и слава богу. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 11:00 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичЕсли что-то не так, то специалист (это и не бухгалтер, и не программист, конечно же) просто не введет (например) дату поступления счета, и зачет не сделается. Или введет, а потом исправит свою ошибку, и зачет автоматически отсторнируется. Не понял. Специалист, отслеживающий законодательство, судебную практику и точку зрения своей инспекции по НДС, и отвечающий за правильное решение по конкретной СФ и есть бухгалтер. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 11:26 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Хорошо, ModelR, Вы правы - это бухгалтер. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 19:00 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Не сочиняйте, iscrafm, про "попытку выдать". И про "строго оговоренные ситуации". Если Вы под каждую "ситуацию" делаете "систему бухучета", то понятно откуда 100 проектов. Но подозреваю, что Вы так не делаете. А просто сочиняете, не обращая внимания на мои объяснения про объективные операции и "бухгалтерские проводки". Я Вас, ###, совершенно не поучаю. А только сообщил об ошибке в Ваших рассуждениях. Серьезной ошибке. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 19:06 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Да, Сергей Васкецов, раз и навсегда. Вы путаете объективные операции движения (в том числе и налогов) с тем, что сам МИНФИН не знает. А по Вашему "гибкость" - это учесть в другом "учете" (другой системе) то, что не предусмотрено в этом "учете" (этой системе), так как этот "учет" "негибкий", а тот "гибкий" ? п.1. Заблуждение про "счета хранения", и про "аналитики в проводках". Откуда в Вашей "проводке" возьмется "вся необходимая аналитика" ? Зачем хранить "счета хранения" в "каждом документе склада" ?? Вы правильно поняли суть того, что я объяснял, как мне показалось, но смотрите на реализацию этой сути, находясь под грузом своих представлений, предопределенных "бухгалтерским подходом". п.2. Дублирование даты и суммы бесполезно, остаются только К и Д, а Вы отвлеченно говорите "в требуемой части". Есть переоценка, и нет проблем. Что значит "не будет коррелировать" ? Для этого нужно перетащить в "проводку" не только то, что Вы называете "аналитиками" (в операции это есть, так как нужно вовсе не бухгалтеру), но и вообще все, что может потребоваться бухгалтеру. Или в Вашей "гибкой системе" бухгалтеру нельзя увидеть в "балансовых отчетах с аналитиками", например, примечание из ТТН ? Что за конкуренция в нагруженных системах ? Похоже у Вас есть проблемы еще и с используемыми СУБД. п.3. Представьте себе, что у Вас один У (чтобы не разбираться, что делается когда в УУ не корректно, в НУ/БУ корректно). И что Вы хотите сказать ? Очевидно же, что "проводки" делаются только по "утвержденным документам". Очевидно же, что "проводки" можно отменить, не "разутверждая" документ. п.4. Никуда я не полезу. Такие вопросы в правильно спроектированных системах решаются на "раз-два-три". п.5. Ничто не мешает "реплицировать проводку" куда угодно. Непонятно, что за проблему Вы придумали. Безусловно, о Вас и Ваших клиентах, так же как и обо всех остальных и их клиентах, можно сказать то же самое - "и слава богу". ... |
|||
:
Нравится:
Не нравится:
|
|||
22.08.2006, 19:28 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичЯ Вас, ###, совершенно не поучаю. А только сообщил об ошибке в Ваших рассуждениях. Серьезной ошибке. Любезный, Вы либо опубликуйте свой "самый полный и нерасширяемый, определенный раз и навсегда" список операций, либо прекратите пороть чушь! ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 06:24 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Чернышев Андрей ЛеонидовичА просто сочиняете, не обращая внимания на мои объяснения про объективные операции и "бухгалтерские проводки". У Вас завышенная самооценка, если Вы считаете свои посты объяснением. Не обратили внимания, что Вас почему-то просят до сих пор все объясниться? ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 10:48 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
Это другое дело, iscrafm и ###. Приятно, что начали говорить по существу. Эти ваши соображения помогут лучше понять суть "операций" и "проводок", и наверняка помогут mr.vetal. А с общеизвестным (а не моим) "списком операций" он и сам ознакомится, когда захочет. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.08.2006, 20:57 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
А мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2006, 15:26 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
LightNetА мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике. Да, действительно, статья тематическая, в правильном направлении мыслит товарищ ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2006, 16:27 |
|
чтоб не изобретать велосипед спрошу у людей
|
|||
---|---|---|---|
#18+
LightNetА мне вот по теме статья понравилась. Там, как мне кажется, говорится то, что Чернышев Андрей Леонидович м.б. недоговорил в данном топике. И где Вы там увидели то, о чем не договоривает Чернышев А.Л.? Там показана типовая структура основных таблиц главной книги. Реально, процентов 99% систем там и строятся. Эта статья под разными авторами не первый год бродит по просторам интернета. ... |
|||
:
Нравится:
Не нравится:
|
|||
24.08.2006, 16:55 |
|
|
start [/forum/topic.php?fid=32&startmsg=33930286&tid=1540139]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
174ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
58ms |
get tp. blocked users: |
1ms |
others: | 234ms |
total: | 515ms |
0 / 0 |