Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
На мой взгляд, бухгалтерия всё-таки предназначена для регистрации не вещей, но хозяйственных операций методом записи бухгалтерских проводок. Как объекты бухгалтерские операции и проводки можно замечательно представить: одна операция — один объект; одна проводка — один объект. А все вот эти вещи: товары, сотрудники и т.п. нужны лишь для аналитического учёта и являются по сути лишь дополнительным реквизитами бухгалтерских проводок.
Т.е. если бы бухгалтер вёл учёт методом записи в тетрадку (либо информационную систему) проводок без аналитики — ничего бы страшного не случилось, у него бы прекрасно получилось сдать баланс или декларацию, т.к. в большинстве своём они содержат лишь суммовые выражения. Разумеется, это не относится к вышеупомянутым Вами основным средствам (оборудованию, объектам строительства и т.п.), где вёдется именно пообъектный учёт
Т.е. если бы бухгалтер вёл учёт методом записи в тетрадку (либо информационную систему) проводок без аналитики — ничего бы страшного не случилось, у него бы прекрасно получилось сдать баланс или декларацию, т.к. в большинстве своём они содержат лишь суммовые выражения. Разумеется, это не относится к вышеупомянутым Вами основным средствам (оборудованию, объектам строительства и т.п.), где вёдется именно пообъектный учёт
Проводка — связь между двумя участвующими в хозяйственной деятельности вещами. Например, при обмене: обменяли вещь 1 на вещь 2 — все вместе проводка, она нужна для того, чтобы впоследствии можно было определить, какую вещь на какую обменяли. Но учитываются все-таки вещи. Сами посудите, до чего предприятию есть дело, до реальных ценностей или каких-то абстрактных хозяйственных операций? До чего есть дело, то и учитывается.
Вашу позицию я понимаю, но с ней не согласен.
Вашу позицию я понимаю, но с ней не согласен.
Менеджеру по продажам, кладовщику есть дело до того, что продали и отгрузили со склада. Для бухгалтера это лишь абстрактный товар с себестоимостью, ставкой НДС и полученной выручкой.
Например, у нас на одном из предприятий в бухгалтерии не ведётся количественный учёт для товаров, реализуемых в рознице. Есть абстрактные «Товар со ставкой НДС 10%» и «Товар со ставкой НДС 18%». И суммы остатков на складах. Для бухгалтерского учёта этого достаточно
Например, у нас на одном из предприятий в бухгалтерии не ведётся количественный учёт для товаров, реализуемых в рознице. Есть абстрактные «Товар со ставкой НДС 10%» и «Товар со ставкой НДС 18%». И суммы остатков на складах. Для бухгалтерского учёта этого достаточно
Менеджера, кладовщика и бухгалтера заставляют выполнять ту работу, которая необходима владельцам предприятия. Владельцам есть дело до хозяйственных операций только с той точки зрения, чтобы заполучить больше ценностей. Поэтому первичное побуждение к учету дают ценности, они и учитываются (не важно, каким способом). Понятие хозяйственных операций возникает позднее как нечто вторичное, служащее учету ценностей. Мне казалось, это очевидно.
1. Неверно, во многих учетных программах есть разделение объектов по стоимости, в основном через дополнительную аналитику партий объекта. (Например сч. 41, аналитики Номенклатура, Склад, Партии), партия — это сохранение даты поступления объекта и других его свойств, в.т.ч. стоимости
2. «Не должно быть регистрации» — это совсем непродуманное высказывание, что-бы что-то учитывать, нужно это зарегистрировать. Обязательства имеют не только сроки выполнения, но и момент их возникновения — именно он и регистрируется. Кроме того в учете есть возможность указывать дату/сроки выполнения и способы расчета — например амортизацию.
3. Работники вообще не в тему. В бух. учете они отлично регистрируются как отдельные объекты — сотрудники организации, имют кучу нужных для учета параметров вроде табельного номера. Кроме того имеется обязательные в учете операции с объектами — прием/увольнение на/с работы.
4. Два поля подойдут если изменение цены было один раз, что вряд ли бывает на практике. Для учета каждого изменения нужно каждое изменение сохранить… Для бух. учета это необходимо для точного расчета себестоимости.
2. «Не должно быть регистрации» — это совсем непродуманное высказывание, что-бы что-то учитывать, нужно это зарегистрировать. Обязательства имеют не только сроки выполнения, но и момент их возникновения — именно он и регистрируется. Кроме того в учете есть возможность указывать дату/сроки выполнения и способы расчета — например амортизацию.
3. Работники вообще не в тему. В бух. учете они отлично регистрируются как отдельные объекты — сотрудники организации, имют кучу нужных для учета параметров вроде табельного номера. Кроме того имеется обязательные в учете операции с объектами — прием/увольнение на/с работы.
4. Два поля подойдут если изменение цены было один раз, что вряд ли бывает на практике. Для учета каждого изменения нужно каждое изменение сохранить… Для бух. учета это необходимо для точного расчета себестоимости.
1. Прежде всего, я не бухгалтерском софте говорю, а о бухгалтерской методологии. В софте может быть много хитрых штучек, которых методология вроде как не предполагает.
Во-вторых, если даже в рамках партии учитывать стоимость поступления объектов, нет гарантии, что на складе эти объекты не свалены в кучу. Строго говоря, необходима идентификация каждого реального объекта (партии), в т.ч. на складе. Когда бухгалтеры забудут, что такое ФИФО и ЛИФО, тогда я скажу, что проблема решена.
2. Момент возникновения обязательства и момент его предполагаемого погашения — разные моменты. По-хорошему, они оба должны быть зарегистрированы, допустим так: 21 августа предполагается, что такой-то объект поступит 30 августа. Действующая методология так регистрировать не умеет (хотя в софте это сделать несложно, наверное).
3. Табельные номера работники имеют, конечно. Однако я веду речь о системном учете — бухгалтерском. Может, просветите, какими проводками оформляется прием/увольнение работника, а то я подзабыл?
4. А что мешает сохранять каждое изменение при двух полях? Изменилось свойство объекта (у нас — по полю второй стоимости), ну и регистрируйте себе на здоровье.
Во-вторых, если даже в рамках партии учитывать стоимость поступления объектов, нет гарантии, что на складе эти объекты не свалены в кучу. Строго говоря, необходима идентификация каждого реального объекта (партии), в т.ч. на складе. Когда бухгалтеры забудут, что такое ФИФО и ЛИФО, тогда я скажу, что проблема решена.
2. Момент возникновения обязательства и момент его предполагаемого погашения — разные моменты. По-хорошему, они оба должны быть зарегистрированы, допустим так: 21 августа предполагается, что такой-то объект поступит 30 августа. Действующая методология так регистрировать не умеет (хотя в софте это сделать несложно, наверное).
3. Табельные номера работники имеют, конечно. Однако я веду речь о системном учете — бухгалтерском. Может, просветите, какими проводками оформляется прием/увольнение работника, а то я подзабыл?
4. А что мешает сохранять каждое изменение при двух полях? Изменилось свойство объекта (у нас — по полю второй стоимости), ну и регистрируйте себе на здоровье.
1. Софт нужен лишь для автоматизации бух. учета. Вести аналитику бухгалтерских операций можно и на бумажке, просто сильно неудобно.
Неважно что есть на складе, в рамках бух. учета на складе будут учитываться объекты, сгруппированные по стоимости (или партии или по любой другой нужной аналитике)
ФИФО, ЛИФО не забудут никогда, т.к. это и есть виды возможностей учета разной стоимости одного и того же вида товаров.
2. Повторюсь — софт — это способ автоматизации и не является чем-то самостоятельным по учету.
3. Прием/увольнение нужно не для содержимого проводки, а для проверки нужно ли её вообще создавать. Иначе говоря без приема на работу не может быть проводки по 70му счету, т.к. нет оформленного сотрудника.
4. Каждое запомненное состояние изменения поля и есть регистрация этого изменения. Каждое изменение цены или стоимости происходит не просто так, а по факту какой-то бухгалтерской операции — поступление товара с новой ценой, переоценка товара на складе при инвентаризации, поступление доп. расходов и т.п. — поэтому удобнее привязывать каждое изменение поля цены к какой-либо конкретной операции.
Бухгалтерии в чистом виде — только синтетический количественно-суммовой учет — практически не встречается в реальной жизни, бухгалтеру всегда нужны дополнительные сведения — аналитика — для последующей сдачи налоговой/бухгалтерской/статистической отчетности, для отчета перед руководителем, да даже для банальной проверки заполнения первичных документов.
Неважно что есть на складе, в рамках бух. учета на складе будут учитываться объекты, сгруппированные по стоимости (или партии или по любой другой нужной аналитике)
ФИФО, ЛИФО не забудут никогда, т.к. это и есть виды возможностей учета разной стоимости одного и того же вида товаров.
2. Повторюсь — софт — это способ автоматизации и не является чем-то самостоятельным по учету.
3. Прием/увольнение нужно не для содержимого проводки, а для проверки нужно ли её вообще создавать. Иначе говоря без приема на работу не может быть проводки по 70му счету, т.к. нет оформленного сотрудника.
4. Каждое запомненное состояние изменения поля и есть регистрация этого изменения. Каждое изменение цены или стоимости происходит не просто так, а по факту какой-то бухгалтерской операции — поступление товара с новой ценой, переоценка товара на складе при инвентаризации, поступление доп. расходов и т.п. — поэтому удобнее привязывать каждое изменение поля цены к какой-либо конкретной операции.
Бухгалтерии в чистом виде — только синтетический количественно-суммовой учет — практически не встречается в реальной жизни, бухгалтеру всегда нужны дополнительные сведения — аналитика — для последующей сдачи налоговой/бухгалтерской/статистической отчетности, для отчета перед руководителем, да даже для банальной проверки заполнения первичных документов.
1. Если вести учет объектов, сгруппированных по стоимости, то всегда будешь знать, из какой партии отгрузил товар. В этом случае оценка по выбытии (ФИФО, ЛИФО и проч.) не нужны. Захотел отгрузить дешевый товар — вытащил из партии и отгрузил, захотел отгрузить дорогой товар — то же самое. Ну какие здесь могут быть ФИФО, ЛИФО, сами посудите?
2. Софт, конечно, способ автоматизации. Но он нередко усовершенствует законодательно установленную методологию. А речь здесь, повторяюсь, о методологии.
3. Разумеется, без работника некому будет начислять зарплату. Но речь опять-таки не об этом, а о том, что никакими проводками прием на работу и увольнение сотрудника не регистрируется. Зачем отрицать очевидное?
4.
Именно так.
А я разве возражаю?
Вы не понимаете суть моего предложения: все регистрируется, как Вы обрисовали, только изменение стоимости объекта должно регистрироваться в качестве изменения одного из свойств того же объекта, а не в качестве другого объекта учета. Нет в реальности никакого второго объекта учета (стоимостного регулятива), есть свойство объекта, которое изменяется и подлежит регистрации в таком качестве.
Что такое аналитика, мне известно.
2. Софт, конечно, способ автоматизации. Но он нередко усовершенствует законодательно установленную методологию. А речь здесь, повторяюсь, о методологии.
3. Разумеется, без работника некому будет начислять зарплату. Но речь опять-таки не об этом, а о том, что никакими проводками прием на работу и увольнение сотрудника не регистрируется. Зачем отрицать очевидное?
4.
Каждое запомненное состояние изменения поля и есть регистрация этого изменения.
Именно так.
Каждое изменение цены или стоимости происходит не просто так, а по факту какой-то бухгалтерской операции… поэтому удобнее привязывать каждое изменение поля цены к какой-либо конкретной операции.
А я разве возражаю?
Вы не понимаете суть моего предложения: все регистрируется, как Вы обрисовали, только изменение стоимости объекта должно регистрироваться в качестве изменения одного из свойств того же объекта, а не в качестве другого объекта учета. Нет в реальности никакого второго объекта учета (стоимостного регулятива), есть свойство объекта, которое изменяется и подлежит регистрации в таком качестве.
Что такое аналитика, мне известно.
1. Одно от другого в жизни неотделимо, иначе Вы будете говорить о «сферическом бухучете в вакууме». Это мало кому интересно. Софт ведь реализует теоретическую методологию в практическую учетную систему. В которой, кстати, проводки уже не в «абсолюте», и чем дальше развиваются софт и методология тем больше. (Начинает казаться, что в той же 1С уже больше документов НЕ формирующих проводок, нежели формирующих, хотя точной статистики у меня нет). Насчет ФИФО-ЛИФО, у Вас есть предложения, которые исключают эти подходы, и будут работать у любого хоз.субъекта? (Если что — я еще не прочитал Ваших трудов по Вашим ссылкам, возможно, где-то Вы это уже описывали, тогда уместной будет еще одна ссылка и/или цитата… :))
2. Нужна ли такая регистрация? Неочевидно, сомнительно и может вести к «распуханию» учета (21-го мы ожидали поступление объекта 30-го, 22-го мы стали ожидать уже 29-го и т.п… На каждое наше «ожидание» создавать новый документ/хоз.операцию? Вы серьезно??)
3. См.п.1 — проводки не в «абсолюте». На прием работника есть соответствующий документ, который регистрирует событие, но не формирует проводок! Магия? Нет, всё проще, просто потратьте немного времени на знакомство с практикой ведения учета на предприятии. Вы обнаружите, что бух.учет — это не главный и не единственный вид учета… И даже не главная цель деятельности предприятия, а всего лишь… инструмент (один из). Да, неидеальный и потому каждый его «затачивает» под себя. :)
4. См.п. 2 — кому нужны эти тонны изменений?
В заключение, мой ответ на последний вопрос топика: нет, (пока) не нахожу. Несмотря на то, что понятие «объекта» в бух.учете и «страдает» некоторыми, отмеченными Вами недостатками и допускает определенные условности, без этого понятия еще не реализована система учета, позволяющая в «боевых условиях» решать те же задачи, что и действующая столь же эффективно, оперативно, детально и др… ))
ЗЫ: Извините, что влез в Вашу дискуссию. )
2. Нужна ли такая регистрация? Неочевидно, сомнительно и может вести к «распуханию» учета (21-го мы ожидали поступление объекта 30-го, 22-го мы стали ожидать уже 29-го и т.п… На каждое наше «ожидание» создавать новый документ/хоз.операцию? Вы серьезно??)
3. См.п.1 — проводки не в «абсолюте». На прием работника есть соответствующий документ, который регистрирует событие, но не формирует проводок! Магия? Нет, всё проще, просто потратьте немного времени на знакомство с практикой ведения учета на предприятии. Вы обнаружите, что бух.учет — это не главный и не единственный вид учета… И даже не главная цель деятельности предприятия, а всего лишь… инструмент (один из). Да, неидеальный и потому каждый его «затачивает» под себя. :)
4. См.п. 2 — кому нужны эти тонны изменений?
В заключение, мой ответ на последний вопрос топика: нет, (пока) не нахожу. Несмотря на то, что понятие «объекта» в бух.учете и «страдает» некоторыми, отмеченными Вами недостатками и допускает определенные условности, без этого понятия еще не реализована система учета, позволяющая в «боевых условиях» решать те же задачи, что и действующая столь же эффективно, оперативно, детально и др… ))
ЗЫ: Извините, что влез в Вашу дискуссию. )
1. Для устранения ФИФО-ЛИФО достаточно вести складской и бухгалтерский учет по партиям, в которых находятся идентичные по всем параметрам (в т.ч. по стоимости) объекты.
2. Обязательства и так регистрируются. А то, что не регистрируется предполагаемая дата погашения, — серьезный недостаток. Деления на кратко- и долгосрочные объекты явно недостаточно.
3. Да, бухгалтерский учет — не единственный вид учета. Но я веду речь именно о бухгалтерском учете, чего непонятного?
4. Сейчас для учета переломный момент: компьютеризация. Она диктует свои правила, которые давно были бы озвучены и претворены в жизнь, если бы не сопротивление миллионов бухгалтеров, которых компьютеризация может лишить работы. Но это сопротивление рано или поздно будет подавлено, как было подавлено сопротивление, к примеру, луддитов. Бухгалтеры — те же луддиты, только они компьютеры не ломают, а используют старые способы регистрации, чтобы работу сохранить. А программисты им по мере возможности способствуют, из тех же соображений. Впрочем, методология учета — довольно сложная наука, ее немногие понимают. А если учитывать социальные последствия, к которым может привести изменение правил учета… Придется еще обождать, видимо, хотя до идеального компьютерного учета рукой подать.
2. Обязательства и так регистрируются. А то, что не регистрируется предполагаемая дата погашения, — серьезный недостаток. Деления на кратко- и долгосрочные объекты явно недостаточно.
3. Да, бухгалтерский учет — не единственный вид учета. Но я веду речь именно о бухгалтерском учете, чего непонятного?
4. Сейчас для учета переломный момент: компьютеризация. Она диктует свои правила, которые давно были бы озвучены и претворены в жизнь, если бы не сопротивление миллионов бухгалтеров, которых компьютеризация может лишить работы. Но это сопротивление рано или поздно будет подавлено, как было подавлено сопротивление, к примеру, луддитов. Бухгалтеры — те же луддиты, только они компьютеры не ломают, а используют старые способы регистрации, чтобы работу сохранить. А программисты им по мере возможности способствуют, из тех же соображений. Впрочем, методология учета — довольно сложная наука, ее немногие понимают. А если учитывать социальные последствия, к которым может привести изменение правил учета… Придется еще обождать, видимо, хотя до идеального компьютерного учета рукой подать.
1. Достаточно ли? Кто и как при таком учете будет решать, из какой партии и по какой стоимости отправить партию ТМЦ покупателю? Не пострадает ли от этого достоверность учета (не менее, чем она страдает при ФИФО-ЛИФО)? Пример: пекарня печет хлеб. На складе куча партий муки, сахара, масла, молока и др. ингридиентов от разных поставщиков по разным ценам. Как определить бухгалтеру, сколько будет стоить буханка сегодняшнего хлеба?
2. Для кого недостаток, для кого — избыточное и бессмысленное усложение учета. Наши предположения о предполагаемой дате погашения могут меняться по 100 раз в день, в зависимости от погоды, работы правительства, гороскопов, уровня отношений с контрагентом и т.д…
3. Бух.учет в теории и на практике — два весьма различных объекта. Может это и плохо, но увы — это факт.
4. Этот «переломный момент» длится уже не первый десяток лет и окончание этого «момента» не в этом и не в следующем году. Готов поспорить. :)
4а. Соображения бухгалтеров и программистов не ограничиваются тем, что Вы предположили. А довольно сложную науку — «методологию (бух.)учета» развивать (желательно, не усложняя) нужно, в этом Вы абсолютно правы! И, всё может быть, возможно именно Вы тот Галилей от бух.учета, чьи слова «есть бух.учет без баланса и проводки без объектов!» будут повторять потомки… ))
2. Для кого недостаток, для кого — избыточное и бессмысленное усложение учета. Наши предположения о предполагаемой дате погашения могут меняться по 100 раз в день, в зависимости от погоды, работы правительства, гороскопов, уровня отношений с контрагентом и т.д…
3. Бух.учет в теории и на практике — два весьма различных объекта. Может это и плохо, но увы — это факт.
4. Этот «переломный момент» длится уже не первый десяток лет и окончание этого «момента» не в этом и не в следующем году. Готов поспорить. :)
4а. Соображения бухгалтеров и программистов не ограничиваются тем, что Вы предположили. А довольно сложную науку — «методологию (бух.)учета» развивать (желательно, не усложняя) нужно, в этом Вы абсолютно правы! И, всё может быть, возможно именно Вы тот Галилей от бух.учета, чьи слова «есть бух.учет без баланса и проводки без объектов!» будут повторять потомки… ))
1. Хозяин пусть и решает. Только не посредством выбора учетной политики, а посредством выдачи соответствующих указаний пекарю. А учет пусть слепо регистрирует, что есть, как учету и дОлжно.
2. Не хочешь, не регистрируй. Вопрос в том, чтобы дать в руки бухгалтеру корректные методы, которые позволяли бы это, при необходимости. Сейчас такие методы отсутствуют (на уровне законодательной регламентации по крайней мере).
3. А я не о фактах, а о том, как дОлжно.
4. Как сказать… В девяностых бухгалтеры активно сопротивлялись внедрению компьютеров. Сейчас уже нет, самое время поправить методологию.
4а. Про «проводки без объектов» Вы мне не приписывайте, Галилей такого не говорил. :)
2. Не хочешь, не регистрируй. Вопрос в том, чтобы дать в руки бухгалтеру корректные методы, которые позволяли бы это, при необходимости. Сейчас такие методы отсутствуют (на уровне законодательной регламентации по крайней мере).
3. А я не о фактах, а о том, как дОлжно.
4. Как сказать… В девяностых бухгалтеры активно сопротивлялись внедрению компьютеров. Сейчас уже нет, самое время поправить методологию.
4а. Про «проводки без объектов» Вы мне не приписывайте, Галилей такого не говорил. :)
Проблема в том что вы придумали какого-то сферический бухгалтерский учет, придумали к нему ограничения и накладываете их на реальную жизнь.
Красота реального бух. учета в том организация самостоятельно определяет параметры аналитического учета для любых объектов учета и может их учитывать на бумажке или в программе учета.
Ограничения бух. учета имеются в синтетике — плане счетов, да и то частично — никто не помешает заводить субсчета. Ну и готовые формулы расчета амортизации для некоторых объектов.
1. Именно так в жизни и происходит, руководитель вместе с гл. бухом решают как они будут расчитывать себестоимость и прописывают себе в учетную политику. Могут прописать ФИФО/ЛИФО/Среднему, могут вручную выбирать партии. Причем могут делать это как на бумажке, так и в какой-либо программе. Так что никаких ограничений бух учет по этому пункту не имеет.
2. Возникновение обязательства и его сроки это взаимосвязанные события и логично регистрировать их по дате первого наступившего из двух событий — что всегда будет дата возникновения. Так же бух. учет никак не запрещает в момент возникновения записать параметры обязательства для упрощения дальнейших расчетов по погашению.
3. Про проводки я ничего не говорил. Я говорил что для бух. учета важно учитывать операции приема на работу, чтобы проводки по зарплате учитывали актуальных сотрудников. Объясняю как это учитываются в бух. учете — 1) если на соот. бумажке ведется список актуальных сотрудников — туда добавляется новая строка с сотрудником или вычеркивается старая 2) если в соот. программе — вызывается соот. операция
Бух. учет не запрещает учитывать любым способом любые дополнительные данные, особенно те которые нужны для проводок.
4. Нет никакого просто изменения поля, ничего само по себе не происходит, не может товар лежащий на складе просто так поменять цену, нужно основание. Обычное изменение поля с ценой, без оснований — не является достаточным для отражения в бух. учете, нужен именно новый объект учета…
Красота реального бух. учета в том организация самостоятельно определяет параметры аналитического учета для любых объектов учета и может их учитывать на бумажке или в программе учета.
Ограничения бух. учета имеются в синтетике — плане счетов, да и то частично — никто не помешает заводить субсчета. Ну и готовые формулы расчета амортизации для некоторых объектов.
1. Именно так в жизни и происходит, руководитель вместе с гл. бухом решают как они будут расчитывать себестоимость и прописывают себе в учетную политику. Могут прописать ФИФО/ЛИФО/Среднему, могут вручную выбирать партии. Причем могут делать это как на бумажке, так и в какой-либо программе. Так что никаких ограничений бух учет по этому пункту не имеет.
2. Возникновение обязательства и его сроки это взаимосвязанные события и логично регистрировать их по дате первого наступившего из двух событий — что всегда будет дата возникновения. Так же бух. учет никак не запрещает в момент возникновения записать параметры обязательства для упрощения дальнейших расчетов по погашению.
3. Про проводки я ничего не говорил. Я говорил что для бух. учета важно учитывать операции приема на работу, чтобы проводки по зарплате учитывали актуальных сотрудников. Объясняю как это учитываются в бух. учете — 1) если на соот. бумажке ведется список актуальных сотрудников — туда добавляется новая строка с сотрудником или вычеркивается старая 2) если в соот. программе — вызывается соот. операция
Бух. учет не запрещает учитывать любым способом любые дополнительные данные, особенно те которые нужны для проводок.
4. Нет никакого просто изменения поля, ничего само по себе не происходит, не может товар лежащий на складе просто так поменять цену, нужно основание. Обычное изменение поля с ценой, без оснований — не является достаточным для отражения в бух. учете, нужен именно новый объект учета…
Для Вас красота учета, для меня — уродство. Се ля ви.
Объяснять теорию мне не нужно, она мной изучена. :)
1. По-моему, Вы не вполне понимаете, для чего нужны ФИФО-ЛИФО. Это средство условно принять, какой объект выбыл, при невозможности определить фактически. При пообъектном учете (который Вы называете учетом по партиям) никакого ФИФО-ЛИФО не нужно в принципе: какой объект выбыл, тот и записывай.
2. Да, верно, дата возникновения раньше. Но логичней все-таки регистрировать обе даты. Бухгалтерский учет этого не запрещает, но и не предписывает. В софте это не составляет труда, собственно, хотя подобная практика отсутствует или мало распространена.
3. Как ведутся базы, бумажные или электронные, мне известно. Но я говорю именно о проводках: единая методология учета всех значимых предметов хозяйственной деятельности отсутствует. Об этом речь, черт подери.
4. Тут Вы точно не ухватываете суть и приписываете мне то, чего я не утверждаю. Есть объект (то, что на счете учитывается), а есть свойства (аналитика). Изменение стоимости объекта — это свойство, так его и нужно учитывать.
Давайте на примере амортизации. Сейчас учитывается так:
А нужно так:
Понятней объяснить не могу. Если Вы по-прежнему не поняли, сдаюсь.
Объяснять теорию мне не нужно, она мной изучена. :)
1. По-моему, Вы не вполне понимаете, для чего нужны ФИФО-ЛИФО. Это средство условно принять, какой объект выбыл, при невозможности определить фактически. При пообъектном учете (который Вы называете учетом по партиям) никакого ФИФО-ЛИФО не нужно в принципе: какой объект выбыл, тот и записывай.
2. Да, верно, дата возникновения раньше. Но логичней все-таки регистрировать обе даты. Бухгалтерский учет этого не запрещает, но и не предписывает. В софте это не составляет труда, собственно, хотя подобная практика отсутствует или мало распространена.
3. Как ведутся базы, бумажные или электронные, мне известно. Но я говорю именно о проводках: единая методология учета всех значимых предметов хозяйственной деятельности отсутствует. Об этом речь, черт подери.
4. Тут Вы точно не ухватываете суть и приписываете мне то, чего я не утверждаю. Есть объект (то, что на счете учитывается), а есть свойства (аналитика). Изменение стоимости объекта — это свойство, так его и нужно учитывать.
Давайте на примере амортизации. Сейчас учитывается так:
А нужно так:
Понятней объяснить не могу. Если Вы по-прежнему не поняли, сдаюсь.
Видимо не совсем поняли теорию.
1. Что-то у вас перепуталось. Партия товара не идентифицирует конкретный объект на складе, она нужна только для сохранения аналитики (чаще всего стоимости) товара. Иначе говоря, придя на склад вы не сможете разделить лежащий кучей одинаковый товар по цене поставщика, может быть совершенно одинаковый товар, но взятый у разных поставщиков с разной стоимостью.
Соответственно при списании товара со склада нужно определиться с порядком выбора списываемой партии — именно этот порядок указывается в учетной политике и может быть ФИФО, ЛИФО, по-среднему или с выбором партии вручную.
Тем не менее, какую вы партию бы не выбрали, со склада возмут первый попавшийся товар в нужном количестве.
Вопрос учета на складе товара с точностью до свойств отдельного объекта применяется редко и только в управленческом учете, для бухгалтерского учета это не имеет значения, т.к. см. выше.
2. Обе даты и регистрируются, и это стандартная практика в программах учета, учитывается срок и параметры амортизации.
3. Единая методология есть, но описана она достаточно формально, что позволяет широко варьировать точность и сложность учета для разных организаций. Например малые организации часто учитывают товар очень обще — например «кровать», «дверь», точнее им не нужно, а некоторые с точностью до цвета/серии/сроков — и все эти варианты можно отразить в обычной проводке с помощью аналитик.
Если же уточнять методологию с точностью до правил указания аналитики — она будет негибкой и неприемлимой для некоторых организаций.
4. Бухгалтерские регистры построены таким образом чтобы итог по счету (включая отбор по аналитке) должен быть всегда расчитан, поэтому в первой ваше табличке нужно добавить итог: — 85 рублей, иначе говоря вы всегда знаете остаточную стоимость.
Вторая же табличка для бух. учета бесполезна, т.к. из неё нельзя понять какая была амортизация за какой-либо период или может было дооборудование.
Надеюсь понятно объяснил бесполезность вашей идеи с полем :)
1. Что-то у вас перепуталось. Партия товара не идентифицирует конкретный объект на складе, она нужна только для сохранения аналитики (чаще всего стоимости) товара. Иначе говоря, придя на склад вы не сможете разделить лежащий кучей одинаковый товар по цене поставщика, может быть совершенно одинаковый товар, но взятый у разных поставщиков с разной стоимостью.
Соответственно при списании товара со склада нужно определиться с порядком выбора списываемой партии — именно этот порядок указывается в учетной политике и может быть ФИФО, ЛИФО, по-среднему или с выбором партии вручную.
Тем не менее, какую вы партию бы не выбрали, со склада возмут первый попавшийся товар в нужном количестве.
Вопрос учета на складе товара с точностью до свойств отдельного объекта применяется редко и только в управленческом учете, для бухгалтерского учета это не имеет значения, т.к. см. выше.
2. Обе даты и регистрируются, и это стандартная практика в программах учета, учитывается срок и параметры амортизации.
3. Единая методология есть, но описана она достаточно формально, что позволяет широко варьировать точность и сложность учета для разных организаций. Например малые организации часто учитывают товар очень обще — например «кровать», «дверь», точнее им не нужно, а некоторые с точностью до цвета/серии/сроков — и все эти варианты можно отразить в обычной проводке с помощью аналитик.
Если же уточнять методологию с точностью до правил указания аналитики — она будет негибкой и неприемлимой для некоторых организаций.
4. Бухгалтерские регистры построены таким образом чтобы итог по счету (включая отбор по аналитке) должен быть всегда расчитан, поэтому в первой ваше табличке нужно добавить итог: — 85 рублей, иначе говоря вы всегда знаете остаточную стоимость.
Вторая же табличка для бух. учета бесполезна, т.к. из неё нельзя понять какая была амортизация за какой-либо период или может было дооборудование.
Надеюсь понятно объяснил бесполезность вашей идеи с полем :)
1. Объясняете правильно.
Когда на складе товар будет лежать не кучей, а соответственно тому, как он учитывается, тогда необходимость в ФИФО-ЛИФО отпадет.
2. При чем здесь амортизация? Речь об обязательствах — о дате предполагаемого погашения. Насколько мне известно, эти даты обычно не указываются, если только приблизительно (краткосрочные-долгосрочные), и то не всегда.
3. Я не аналитике говорю — о единой теории учета. Это не детально прописанная аналитика, а совсем другое.
4. Итог только в балансе, а в качестве сальдо по объектам фигурирует то, что указано.
Амортизация нужна для расчета остаточной стоимости, а не наоборот.
Предлагаю закончить, мы с Вами на разных языках разговариваем. Караул устал. :)
Когда на складе товар будет лежать не кучей, а соответственно тому, как он учитывается, тогда необходимость в ФИФО-ЛИФО отпадет.
2. При чем здесь амортизация? Речь об обязательствах — о дате предполагаемого погашения. Насколько мне известно, эти даты обычно не указываются, если только приблизительно (краткосрочные-долгосрочные), и то не всегда.
3. Я не аналитике говорю — о единой теории учета. Это не детально прописанная аналитика, а совсем другое.
4. Итог только в балансе, а в качестве сальдо по объектам фигурирует то, что указано.
Амортизация нужна для расчета остаточной стоимости, а не наоборот.
Предлагаю закончить, мы с Вами на разных языках разговариваем. Караул устал. :)
1. Хранение товара на складе в разрезе тех свойств которые он физически не имеет (цена, поставщик и т.п.) очень редко используется из-за больших затрат на объем места, программ учета и занятость кладовщиков. Помимо того что для хранения эти свойства не важны, они так же не важны для учета, ибо используете ли вы четкое разделение товара по свойствам или выберите ФИФО или среднее — итоговая себестоимость от этого не измениться. ФИФО/ЛИФО определяет лишь момент списания.
Иначе говоря какой метод списания не выбран, после продажи всего купленного товара себестоимость его будет одна и таже.
С другой стороны в бух. учете не важны именно физические (вес, объем, внешний вид).
Подытожим, если используются методы ФИФО/ЛИФО — себестоимость расчитывается достаточно легко, не требует дополнительных затрат на хранение/кладовщиков/складской учет и логически понятна и бухгалтерам и кладовщикам, если же использовать разделение по свойствам и физическим и учетным, то это потребует больших затрат на место, доп. сотрудников, будет нелогична и непонятна и для бухгалтеров и для кладовщиков, а главное — результат расчета себестоимости в итоге будет одинаков.
Или можно попробовать аналогию — отсортировать массив конечно можно и перебором, но лучше оптмизировать и использовать более подходящие алгоритмы.
2. Например учет расходы будущих периодов имеет и дату возниковения и сроки и амортизацию.
3. Изначально вы говорили что работники в бух. учете не регистрируются, это неверно, т.к. в бух. учете (не проводках) всегда есть записи о приеме на работу и в проводках имется зарегистрированный в учете объект — сотрудник.
Единая методология учета объектов в бух. учете есть, просто, если я правильно понимаю, вам кажется что логичнее было-бы учитывать по-другому, даже несмотря на то что ваш вариант менее удобен, судя по другим пунктам.
4. Сальдо — это разница между дебетом и кредитом, в вашей первой табличке оно отсутствует, хотя в бух. учете имеется всегда.
Баланс — это итог по всем счетам бух. учета и он тут не причем.
Таким образом вы просто не поняли как работает учет объектов в бухгалтерском учете, поэтому и пытаетесь придумать что-то новое, хотя оно уже в нем есть.
Амортизация нужна еще и для ежемесячной/ежеквартальной отчетности, поэтому если вы не будете хранить амортизацию отдельно — не сможете сдать отчетность — итог ведения бух. учета. А вот остаточную стоимость хранить нет смысла — она есть всегда, т.к. равна сальдо по соответствующей аналитике.
По поводу разных языков, дело в том что последний десяток лет я как раз работаю стыкуя программы учета с самим бух. учетом и вижу что вы не точно понимая объект критики пытатесь посоветовать что-то в этом поменять и этим можете смутить людей которые не в курсе бух. учета. Поэтому я пытаюсь донести до вас эту мысль, по-разному её формулируя.
Кроме того, меня абсолютно не напрягает спор без перехода на личности, поэтому всегда готов продолжить :)
Иначе говоря какой метод списания не выбран, после продажи всего купленного товара себестоимость его будет одна и таже.
С другой стороны в бух. учете не важны именно физические (вес, объем, внешний вид).
Подытожим, если используются методы ФИФО/ЛИФО — себестоимость расчитывается достаточно легко, не требует дополнительных затрат на хранение/кладовщиков/складской учет и логически понятна и бухгалтерам и кладовщикам, если же использовать разделение по свойствам и физическим и учетным, то это потребует больших затрат на место, доп. сотрудников, будет нелогична и непонятна и для бухгалтеров и для кладовщиков, а главное — результат расчета себестоимости в итоге будет одинаков.
Или можно попробовать аналогию — отсортировать массив конечно можно и перебором, но лучше оптмизировать и использовать более подходящие алгоритмы.
2. Например учет расходы будущих периодов имеет и дату возниковения и сроки и амортизацию.
3. Изначально вы говорили что работники в бух. учете не регистрируются, это неверно, т.к. в бух. учете (не проводках) всегда есть записи о приеме на работу и в проводках имется зарегистрированный в учете объект — сотрудник.
Единая методология учета объектов в бух. учете есть, просто, если я правильно понимаю, вам кажется что логичнее было-бы учитывать по-другому, даже несмотря на то что ваш вариант менее удобен, судя по другим пунктам.
4. Сальдо — это разница между дебетом и кредитом, в вашей первой табличке оно отсутствует, хотя в бух. учете имеется всегда.
Баланс — это итог по всем счетам бух. учета и он тут не причем.
Таким образом вы просто не поняли как работает учет объектов в бухгалтерском учете, поэтому и пытаетесь придумать что-то новое, хотя оно уже в нем есть.
Амортизация нужна еще и для ежемесячной/ежеквартальной отчетности, поэтому если вы не будете хранить амортизацию отдельно — не сможете сдать отчетность — итог ведения бух. учета. А вот остаточную стоимость хранить нет смысла — она есть всегда, т.к. равна сальдо по соответствующей аналитике.
По поводу разных языков, дело в том что последний десяток лет я как раз работаю стыкуя программы учета с самим бух. учетом и вижу что вы не точно понимая объект критики пытатесь посоветовать что-то в этом поменять и этим можете смутить людей которые не в курсе бух. учета. Поэтому я пытаюсь донести до вас эту мысль, по-разному её формулируя.
Кроме того, меня абсолютно не напрягает спор без перехода на личности, поэтому всегда готов продолжить :)
1. То, что Вы говорите о ФИФО-ЛИФО с практической стороны, совершенно правильно, а вот с теоретической — у Вас какое-то странное недопонимание, для чего эта штука вообще придумана. Тут вопрос действительно сложный. Но если принять существующие хозяйственные реалии как должное, все нормуль.
2. В десятый раз повторяю: я об обязательствах. Каждое обязательство имеет как дату возникновения (допустим, 21 августа), так и предполагаемую дату погашения (допустим, 30 сентября). Данное обязательство будет отражено как краткосрочное, тогда как надо бы указывать: 30 сентября. И это ничего, что дата может меняться. Важно наличие методов, применять которые можно по необходимости.
3. Записи о приеме на работу и увольнении с работы — это не бухгалтерский учет (хотя тоже учет), т.к. данные записи не регламентируются бухгалтерским законодательством и не отражаются в бухгалтерских проводках.
Единой методологии учета всех объектов не существует: я о методологии говорю, а не о бухгалтерском софте. «1С: Бухгалтерия» — это не методология, методология это двойная запись. Это надо понимать.
4. Разница между дебетом и кредитом не имеется всегда, ее нужно исчислять. А в моей второй табличке она уже исчислена в виде остаточной стоимости.
Ладно, наш спор становится смешным. Тому, что Вы автоматизатор с опытом, безусловно верю. Это очень печально, когда специалист-практик не замечает ни недостатков системы, с которой работает, ни громадного потенциала, который в данной системе мог быть реализован.
До свидания.
2. В десятый раз повторяю: я об обязательствах. Каждое обязательство имеет как дату возникновения (допустим, 21 августа), так и предполагаемую дату погашения (допустим, 30 сентября). Данное обязательство будет отражено как краткосрочное, тогда как надо бы указывать: 30 сентября. И это ничего, что дата может меняться. Важно наличие методов, применять которые можно по необходимости.
3. Записи о приеме на работу и увольнении с работы — это не бухгалтерский учет (хотя тоже учет), т.к. данные записи не регламентируются бухгалтерским законодательством и не отражаются в бухгалтерских проводках.
Единой методологии учета всех объектов не существует: я о методологии говорю, а не о бухгалтерском софте. «1С: Бухгалтерия» — это не методология, методология это двойная запись. Это надо понимать.
4. Разница между дебетом и кредитом не имеется всегда, ее нужно исчислять. А в моей второй табличке она уже исчислена в виде остаточной стоимости.
Ладно, наш спор становится смешным. Тому, что Вы автоматизатор с опытом, безусловно верю. Это очень печально, когда специалист-практик не замечает ни недостатков системы, с которой работает, ни громадного потенциала, который в данной системе мог быть реализован.
До свидания.
Теории нет без практики. С бух. учетом работают люди и все те «недостатки» которые вы заметили нужны людям для удобства их работы.
Вашу же идею для формализации всего и вся можно будет применить только при появлении искусственного интеллекта, который будет заниматься учетом самостоятельно.
Вашу же идею для формализации всего и вся можно будет применить только при появлении искусственного интеллекта, который будет заниматься учетом самостоятельно.
В точку! Я действительно исхожу не из удобства работы людей (которые в большинстве своем являются лишними в производственной цепочке), а из идеальной методологии, которая сама диктует правила. Меня общечеловеческие идеалы интересуют, а не чтобы у какой-то бухгалтерши оставалось время на балабольство.
Замечу ещё по поводу работников.
База по сквозному учету работников, так сказать от производителя до потребления существует, правда, в материальном виде — это трудовая книжка.
Беря в руки трудовую, вы видите всю его историю как «арендуемого орудия труда» (ваш термин) :)
Там и изменения свойств (оплата, должность) и наложение дополнительных (взыскания, поощрения).
Поскольку эту базу сейчас активно хотят убрать из обращения, нужна электронная замена. Ведь вряд ли данные из ПФР будут предоставляться работодателям.
P.S. А ещё я всё-таки не понял, как в Вашей модели, вы предлагает регистрировать людей? Что-то вроде 11 счета, только для людей? :)
(понимаю, что в Вашей методологии счетов нет, как и двойной записи, но всё же)
База по сквозному учету работников, так сказать от производителя до потребления существует, правда, в материальном виде — это трудовая книжка.
Беря в руки трудовую, вы видите всю его историю как «арендуемого орудия труда» (ваш термин) :)
Там и изменения свойств (оплата, должность) и наложение дополнительных (взыскания, поощрения).
Поскольку эту базу сейчас активно хотят убрать из обращения, нужна электронная замена. Ведь вряд ли данные из ПФР будут предоставляться работодателям.
P.S. А ещё я всё-таки не понял, как в Вашей модели, вы предлагает регистрировать людей? Что-то вроде 11 счета, только для людей? :)
(понимаю, что в Вашей методологии счетов нет, как и двойной записи, но всё же)
Люди — такие же вещи, как и все прочие. Только одушевленные.
Моя система предполагает их регистрацию в таком порядке. Пользователь регистрируется обычным образом, одновременно создается запись в рабочей базе, где появляется объект Имя_Пользователя. С ним можно выполнять те же операции, что и с другими объектами, но с некоторой спецификой. В частности, пользователь не может удалить сам себя в качестве объекта или переименовать, также при объединении-разделении объектов один из получаемых на выходе объектов всегда Имя_Пользователя.
P.S. Вопрос немного не по теме. В следующий раз, если будете спрашивать, пожалуйста, используйте соответствующий пост. Читатели же не следят за нашей перепиской в разных постах. :)
Моя система предполагает их регистрацию в таком порядке. Пользователь регистрируется обычным образом, одновременно создается запись в рабочей базе, где появляется объект Имя_Пользователя. С ним можно выполнять те же операции, что и с другими объектами, но с некоторой спецификой. В частности, пользователь не может удалить сам себя в качестве объекта или переименовать, также при объединении-разделении объектов один из получаемых на выходе объектов всегда Имя_Пользователя.
P.S. Вопрос немного не по теме. В следующий раз, если будете спрашивать, пожалуйста, используйте соответствующий пост. Читатели же не следят за нашей перепиской в разных постах. :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Релевантно ли понятие объекта бухгалтерского учета?