Как стать автором
Обновить

Комментарии 112

Очень интересная серия статей, с удовольствием прочитал все на одном дыхании.
Спасибо, надеюсь в реальной практике эта информация поможет.
Жаль, но в реальной практике, мне она уже вряд ли поможет, т.к. сменил род деятельности.
Интересно, где можно подробней почитать про TMA?
Думаю позднее на сайте rtit будет более подробное описание.
— В учете отсутствует понятие учетной (опорной валюты);

Добавили признак валюты и таблицы с курсами? :)

— Курсовые поправки и переоценки учитываются системно, т.е. нет необходимости вводить их как дополнительные операции;

Каким образом?

— «Проведение» документов в учет должно быть автоматизировано;

Если проведение документов в учет автоматизировано, то вместо вашей системы может использоваться и 1C и ERP.

Вообщем про отчетность финансовую какая бывает и где интересно, но вот про все остальное…
У нас есть такие приборы! Но мы их вам не покажем!

1. Нет учетной валюты — это нет учетной валюты. Т.е. в настройках такого нет. Финансовые отчеты могут быть сформированы в любой валюте, при этом, курсовые поправки в таких отчетах рассчитаны адекватно валюте отчета как учетной.

2. Поправки действительно вводить не надо. В финансовые отчеты курсовые поправки рассчитываются в соответствии с запрашиваемой валютой отчета.

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

4. Приборы есть, работают, смотрите, если интересно. Закрыты только алгоритмы записи и расчета на подсистемном уровне. Но это и не интересно, главное чтобы входило и выходило то что надо. :)
1. Нет учетной валюты — это нет учетной валюты. Т.е. в настройках такого нет.

А я собственно и не говорил, что она у вас есть. Я сказал что система позволяет оперировать при учете в любой валюте. А результаты в нужную валюту загоняет через таблицу курсов.

2. Поправки действительно вводить не надо. В финансовые отчеты курсовые поправки рассчитываются в соответствии с запрашиваемой валютой отчета.

А этим вы подтверждаете, то что я только что сказал.

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

Есть правило все или ничего. Опять же как правило документы спокойно делятся на классы. На случай если же все плохо, то выделяется специальный класс «другое».

4. Приборы есть, работают, смотрите, если интересно. Закрыты только алгоритмы записи и расчета на подсистемном уровне. Но это и не интересно, главное чтобы входило и выходило то что надо. :)

Вы пришли на ресурс IT-направленности где практически все занимаются одним и тем же «разбираются как это работает внутри и как его заставить делать то что надо» и говорите что это не интересно? Как раз таки в вашей системе интерес представляют алгоритмы записи и расчета. То что вы их скрываете указывает на их легкую повторяемость сторонними людьми.
Очень рекомендую почитать учебники по финансовому учету в части переоценки активов, обязательств, капитала. Для двойной записи нет никакой проблемы в переоценке этого всего. А вот если отказаться от двойной записи и перейти на расчеты, как вы рекомендуете, то начнутся огромные проблемы с камеральными проверками, потому как BS, P&L и Cash Flow не будут биться между собой
Вы даже не представляете сколько я этих учебников прочитал :). Но за совет спасибо :)

Проблема в том, что переоценка вводится дополнительной операцией. Курсовые поправки частный случай переоценок. И проблема эта в области автоматизации этих процессов.
На пользовательском уровне tma-система имеет интерфейс с двойной записью, так что никто от нее не отказывался.

В том и фишка, что отчеты на выходе бьются всегда, поскольку эти переоценки и курсовые поправки рассчитаны в системе и выводятся в отчет в соответствии с запрашиваемой валютой отчета.
Хорошо, представим себе часто встречаемую ситуацию (у меня был далеко не один такой клиент): компания на российском рынке, потэтому все расчеты идут в рублях (требования законодательства), часть поставщиков выставляет счета в евро (точнее в условных единицах) по какому-то своему курсу, руководство рассматриваемой компании тоже хочет видеть отчеты в евро, но уже по своему курсу. Добавим сюда еще то, что зарплата сотрудникам расчитывается в евро (потому что один из собственников сидит в германии и любит сам считать зарплату для русских), но выплачивается в рублях, естестествеено по своему, уже третьему курсу. Как вам удается проводить расчеты курсов, чтобы все отчеты бились между собой? Если есть пример, то вообще будет супер!

ЗЫ не понял какие проблемы создает дополнительная операция, которая может выполняться в отсутствие человека
Да бьются, причем в любой валюте. Можно сделать пример следующим образом. Вы нам несколько операций, а мы видеоролик выложим.
Ну я же описал вроде набор операций. Давайте ещё раз без лишней воды:
1. поставщик прислал акт выполенных работ на 100 евро по курсу 45
2. мы оплатили эти работы на треть рублями с банковского счета, на счете осталось 900 рублей
3. Наш немецкий босс начислил за это отделу (ну или кому-то одному, это не важно) зарплату 200 евро по своему курсу 47 рублей за евро
4. наступил конец месяца и местное российское руководство хочет видеть стандартный комплект отчетов: баланс на конеце месяца, прибыли-убытки и движение денежных средств за месяц. Всю отчетность начальство хочет видеть в евро по курсу 46
Завтра будет ролик, и ссылку дам сюда, в комменты, только с вашего позволения курсы валют будут цбрф. просто операции разнесу по дням
в том то и дело, что учет необходимо вести по корпоративным правилам, а не по цбрф. Курсы цбрф распространяются только на учет платежей в валюте и на переоценку валютных остатков, а в предлагаемом примере все платежи в рублях. Именно поэтому я настаиваю на своих курсах, а не курсах цбрф. По цбрф даже 1С прекрасно все считает, без доп. настроек.
ок ок. будет и цб и свои.
Уточню условие:
Условия задачи
1. Собственник перечисляет на расчетный счет 2400 рублей.
2. Поставщик выставляет счет на 100 евро по курсу 45.
3. Компания оплачивает этот счет на треть рублями с банковского счета.
4. Руководство в Германии начисляет сотрудникам зарплату 200 евро по своему курсу 47 рублей за евро.
5. Российское руководство хочет видеть стандартный комплект отчетов: баланс, прибыли-убытки и движение денежных средств. Всю отчетность начальство хочет видеть в евро по курсу 46.

При вводе данных пользовались базовыми документами tma-системы. Это простые проводки.

Вот ролик www.youtube.com/watch?v=Om2cO7LIi8k&feature=youtu.be

Ролик отличный! Одно только замечание — у вас получилось три разных евро-валюты, хотя в условиях задачи евро-валюта была одна, она только в рубли переводилась по-разному в разных случаях. Поэтому в конце ролика у вас получился не баланс в евро, а баланс в рублях, умноженный на курс 46, а это не верно.

Требовалось получить именно управленческий баланс с валютой учета евро, в частности должы были получиться обязательства перед поставщиком 66,67 евро и обязательства перед сотрудниками 200 евро.

Ваш конечный баланс выглядит не так, поэтому я, на месте клиента, его не принял бы в качестве решения поставленной задачи.
так я не вполне понял, если «Всю отчетность начальство хочет видеть в евро по курсу 46», то чем вас не устраивает «в конце ролика у вас получился не баланс в евро, а баланс в рублях, умноженный на курс 46»?

хотели увидеть по фейковому курсу — по нему и увидели. Если бы выбрали настоящую валюту Евро с курсом от ЦБ — то и получили бы соответствующий результат.
вы уж определитесь с пожеланиями
Нет никаких фейковых курсов, курсы настоящие. Один зафиксирован в договоре с поставщиком, второй в корпоративной учетной политике по зарплате, третий в учетной политике для регионального филиала. Никакого фейка, всё законно и допустимо с точки зрения аудита.
Тогда просто в документе надо при переводе денег поставщику (если валюта перевода отличается от валюты взаиморасчетов) надо указать по какому курсу переводим.
Мы вводили данные по базовым документам, там такой функции нет. Такое поле добавить 5 сек. Если сильно надо, то можно добавить и перезаписать ролик.
А разве это не базовый функционал показывать в документе оплаты какую сумму задолженности мы закрываем?
Нет. это не базовый функционал. Система модульная. Можно создать в считанные минуты любой первичный документ. Это будет отдельная программа. Потом его поля можно привязать к финансовому модулю (инструментально). Тоже займет минуту. То что вы видели это базовые документы, их можно использовать в качестве шаблонов, к примеру, или вообще не использовать.
В любом случае, я вам благодарен за задачу, возможно надо эту возможность и в базовый документ занести.
Но главное все таки не в этом. Я могу ввести все что угодно в разных валютах, а потом смотреть сбалансированную триаду относительно не просто разных валют но и разных источников курсов. Вот этого никто не сможет. В примере это видно.
Поговорите с 1С-никами, они вам на УПП могут подобное тоже за несколько минут собрать. Окошки, конечно, будут выглядеть иначе, но суть того, что отчетность можно пересчитать в другую валюту — этот функционал там есть уже много лет.
В SAP это настраивается дольше, не 5 минут, но тоже есть. Правда там всё довольно сильно привязано к IFRS/GAAP и выглядит иначе (как с точки зрения процесса ввода данных, так и с точки зрения отчетности), но тоже есть.

Так что насчет никто не сможет — тут вы, скорее всего, погорячились.
Нет не погорячился. Любая 1с начинается с определения учетной валюты. Финансовые отчеты могут быть сформированы только в ней. Опять же потому что поправки относительно ее начислены.
Ни одна система не может сформировать фин отчеты свободно в разных валютах. и кстати проблема как раз в двойной записи.
Конвертануть отчет по курсу это не проблема, но тогда поправки не будут соответствовать валюте отчета как учетной.
Тут Вы не правы, при всем уважении к Вашим знаниям.
Даже уж не знаю как объяснить другими словами то. Зачем нужны фин отчеты в разных валютах?

Хотя… если не следовать принципам МСФО о непрерывности учета, сопоставимости, понятности, и т.д. тогда нет никаких преград для смены валют на лету. Но нужен ли потребителям такой учёт? Есть ли польза от такого учета?
Ну я тоже не знаю как объяснить. Возможность смены валют это лишь признак. Но на практике люди пользуются.
Признак того, что система сама учитывает курсовые поправки и переоценки без доп начислений.
Если Вы такой приверженец бумажной бухгалтерии и формального бухгалтерского учета, и не можете понять что есть другие пользователи учета, которых существующая ситуация не устраивает, то мне действительно не объяснить суть того что мы разрабатывали несколько лет, а сейчас это работает в реальных инструментах.
Как мне объяснить, что существующая система неспособна обеспечить контроль над бизнесом в масштабе реального времени и ценности. Это огромный недостаток. Все эти статьи вскрывают недостатки, а система не претендует на конкуренцию с бумажной бухгалтерией.
Вы тут много написали комментариев, но все они сводятся к тому, что все типа и так нормально и существующие системы и базисные принципы просто супер.
Я бизнесом занимаюсь 15 лет. Круг моего общение бизнесмены и бизнес. И разработками я начал заниматься не ради развлечения, а потому как проблемы не позволяли нормально управлять моим бизнесом.
Сейчас на описываемой методологии и продуктах работают десятки реальных предприятий от малых до великих и меня искренне радует, что для собственников и руководителей бизнес стал прозрачным, внезависимости от терминов, определений и учебников.
А что такое «контроль над бизнесом в масштабе реального времени»? Бывают контроли в нереальном времени или как? Например, что такое амортизация в реальном времени? Или себестоимость? Или зарплата с налогами?
:). Это же просто.
Когда расчетное финансовое состояние (баланс) соответствует реальному постоянно, или хотя бы на конец каждого дня.
> Ролик отличный! Одно только замечание — у вас получилось три разных евро-валюты

С финансовой точки зрения, если одну и ту же валюту считают по разным курсам, то это по сути transaction fee и должен учитываться отдельно.

Вот пришел я в кабак. Европеец, не готов к заоблачным московским ценам и нажрал на 5 тыщ рублей. Ок, столько рублей нет, хочу рассчитаться в евро. А кабак говорит. Евро считаем по курс 35.

Что это такое? Это стоимость перерасчета. Не в мою сторону. Transaction fee, оно и есть.
Пересмотрел ролик ещё раз и понял что же меня так напрягло с самого его начала. Вы купили товар, еще не оплатили его, не продали, а уже появились расходы в P&L. Это и не кассовый метод и не метод начисления, это совсем новый для меня метод учета! Наконец-то я понял в чём новизна ващей системы.
Прошу простить меня за мою невнимательность, если бы я сразу это разглядел, то вопросы бы у меня были совсем другими.
Там нет товара и близко. Там начисляются расходы.
А эти расходы относятся к какому периоду? Эти расходы как-то связаны с получением доходов в будущем? В ролике я не увидел никаких полей, где бы это всё указывалось. Эти поля конечно можно добавить в будущем, но тогда и сама система станет совсем другой. А пока, по представленному примеру, вопрос обоснованности включения этого счета поставщика в прибыли-убытки остается открытым
Это не имеет никакого значения. Просто начислены какие-то расходы. Поля были. При создание документа было указано поле Статья ДР — Административные расходы.
Что значит какие-то расходы? Разве для управления компанией не нужно какие именно это расходы? Вот менеджер, который принимает решение о дальнейшей судьбе компании, открывает финансовый отчет и что он там должен увидеть? Общую сумму убытка или всё таки структуру доходов и расходов?
Если нужна структура, то должна она как-то коррелировать с первичными данными или нет? И если она не коррелирует с первичными операциями, то соит ли менеджеру доверять такой отчетности?
Вы в комментариях только первый предложения читаете, так же как и статье, так же как и в статьях Соколова.

> При создание документа было указано поле Статья ДР — Административные расходы.

А как правильно читать, если у вас в отчете о прибылях и убытках все статьи называются «чистая прибыль ....»? Прибыль должна быть итогом, а не статьями, не правда ли? Как в «реальном времени» принимать решения менеджеру, когда в первых предложениях и словах не показано самое главное? Это было про отчёт.

Теперь вернемся к документу, где была указана статья «Административные расходы». Вот я менеджер, я увидел этот документ в системе (его ввела длинноногая блондинка оператор, специально нанятая для ввода первички), как мне узнать правильно ли он отнесен на административные расходы? В магазинах и на рынке не продаются товары и услуги с названием «административные расходы». Значит кто-то отнес к этой статье что-то. Но правильно ли человек это сделал? В системе я не вижу что это за расход был в реальности, правильно ли он отнесен, в том ли периоде, в той ли сумме. И чтобы разобраться с этим, мне, как менеджеру, надо вне системы что-то где-то искать. Почему нельзя в самой системе сразу указать:
1. что это был за расход
2. по каким документам поставщика он пришёл (чтобы можно было проверить правильность ввода самой операции в систему)
3. как этот расход классифицирован для отчетности
В вашем примере я увидел только третий пункт, который без первого имеет крайне малую ценность.
Когда компания совсем маленькая или ты индивидуальный предприниматель, то таких проблем нет, всё в одной голове. А когда компания большая, то проблемы будут в полный рост, потому как один и тот же расход может по-разному классифицироваться в разное время и для разных целей
Базовое tma приложение служит основой для построения программ. Это написано на сайте. Принцип разработки в tmaplatform модульный. Все, что вы пишете, это различного рода программы. Я уже писал об этом в комментариях.
Пример сделан, чтобы показать работы без учетной валюты, хотя задаче не совсем под это подходит.
Если надо, чтобы по виду документа определялась статья это не проблема. Вы сейчас докапываетесь до екселя, образно говоря, что в нем нет готовой под ваши задачи таблички.
Как многие пользователи, я пытаюсь понять подходит мне это решение или нет. Отсюда вопросы, отсюда примеры.
Раз пошли сравнения с екселем, значит потребуется много доработок, а мне, как заказчику, придётся изобретать методологию ведения учета, хотя я расчитывал на уже готовую или на объяснения почему готовой быть не может (хотя многие их продают).

Может меня название с толку сбило, в названии речь идет об учете вообще, а вы только про свою систему рассказываете.

В любом случае, спасибо за ваши ответы.
Не обижайтесь.
В статьях сделана первая попытка изложить некую новую методологию, новый подход к предмету счетоводства и формированию финансовых отчетов. Для этого уточняются некоторые существующие термины и определяются недостатки существующей системы знаний.
Речь не идет о готовых решениях, к примеру, для ресторанного бизнеса или универсальное ERP торговля или производство. То, о чем идет речь, может выступать ядром во всех этих системах и давать значительные преимущества по качеству информации и затрачиваемым ресурсам.
Тут не идет речи ни о каких принятых форматах учета, скорее это основы бух учета, где нет никаких практических принципов.

Что же до готовых продуктов, то на базе этих технологий мы построили систему состоящую из ряда программ и технологий. Эта система позволяет заимствовать данные существующей электронной первичной документации из любых источников, трансформировать их в формат tma и получать масштабируемые до документа финансовые отчеты.
Мы назвали это предложение автоматизация счетоводства и формирования триады финансовых отчетов.
На протяжении трех лет, параллельно систематизации информации и разработками, мы разгребали этой системой данные различных по размерам и индустрии холдингов. В результате бизнес для собственника становился прозрачным и управляемым. От сюда и вышло данное предложение, поскольку предприятий, где с финансовым учетом в интересах собственника бизнеса все нормально я не встречал на практике.
А что до различных готовых решений, то имея в основе описываемый финансовый модуль (базовое приложение), и создавая их в среде tmaplatform, их разработки и изменение приобретает совсем другое качество. Понятная архитектура, скорость разработки, возможность любых доработок и переработок — это именно то, что надо для учетных систем, поскольку все очень быстро меняется в жизни.

Вам спасибо за комментарии. Можете обращаться отвечу на любые вопросы.
«недостатки существующей системы знаний» — именно с этим я и пытался разобраться. А в результате, что я получил:
1. в чем вы видите проблемы двойной записи — я так и не понял, но возникло четкое ощущение, что именно на двойной записи ваш учет и построен
2. почему ERP системы не могут формировать финансовые отчеты каждый день — этого я тоже не понял. В моей практике я постоянно вижу как эти отчеты формируются каждый день по многу раз. Детализация данных там только выше, потому что счетов учета не 4, а значительно больше
3. почему вы связали успех ваших клиентов с вашей программой, а не с введением финансовой дисциплины, например? для меня это тоже не очевидно

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

Я уже предлагал Вам посмотреть на вопросы автоматизации учета не с точки зрения как это делается в бухгалтерии, а как это можно сделать в реляционных базах данных. Но если нет такой возможности, то надо принимать тот факт, что курсовых поправок и переоценок начислять не надо, они в отчетах рассчитываются относительно валюты отчета как учетной. В реальной практике курсовые поправки — это головная боль у финансистов. именно они причина невозможности учета каждый день. Не понимаю что вы там видели в вашей практике, наверное моновалютный учет на такое способен, но опять же в одной системе себестоимости.
1. Недостатка я в статье как раз и не увидел. Там есть куча заявлений о том, что двойная запись чего-то не может, но это не так. Двойная запись — это инструмент позволяющий отражать ЛЮБЫЕ финансовые операции. Двойная запись — это всего лишь форма отражения закона сохранения. Если вы его отрицаете, то я прошу примести пример, подтверждающий ваши слова, а не так голословно утверждать, как это сделано в вашей статье. Допускаю, что вам может не нравится двойная запись в каких-то случаях, но не надо бездоказательно утверждать, что она чего-то не может.
2. Курсовые поправки и переоценки бывают двух типов: первые связаны с тем, что даты (а значит и курсы) открытия и закрытия задолженности могут различаться, в таких случаях курсовая разница рассчитывается в момент отражения операции и не нуждается в дополнительных действиях со стороны пользователя, второй тип курсовых разниц — это переоценка валютных счетов и обязательств, данная операция может выполнятся системой автоматически и тоже не требует участия пользователя. Но все эти переоценки — это условность, на которую идут исходя из принципов учета: понятность, сравнимость, потому что как иначе сравнить 150 долларов и 100 евро не приводя их к одной валюте? Именно поэтому вся финансовая отчетность и строится в одной валюте — чтобы можно было соотносить доходы и расходы, чтобы можно было сравнивать разные периоды между собой. Если нет валюты отчетности, то сравнить данные невозможно. Нет возможности сравнивать, нет управления.
3. «Потому что как люди работали, так и продолжили работать» — если эту фразу понимать буквально, то выходит, что как люди не пользовались вашей системой, так и не пользуются дальше. Но подозреваю, что это не так. А если это не так, то работа людей в чём-то изменилась. А малые изменения (особенно если в проблемной области) могут приводить к огромным изменениям в деятельности фирмы. Например, разница между «вносить все документы в систему» и «вносить почти все документы в систему» в финансовом учете может быть как разница между прибылью и убытком.

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

ЗЫ в моей практике курсовые поправки создавали головную боль только в одном случае: поправки надо вносить сейчас, а курсы будут определены только через год. Самый обычный 1С с двойной записью эту проблему отлично решал, а ваша система такие задачи умеет решать?
1.
>Единственным реальным существенным недостатком всемогущей двойной записи является ее неспособность учитывать изменение стоимости во времени.
И это действительно так.
2. Можно начислять и программно, но в реалии это и есть самый большой тормоз реально автоматизации счетоводства.
Учетная валюта возникает в tma системе в финансовых отчетах, а не в самом учете. И она может быть любой. Это не какое-то практическое преимущество, а снятие ограничений.
3. Простите, но это доводы. Почему то до внедрения системы у них ничего не получалось, хотя систем ERP класса было много.

Если процесс действительно автоматизирован, то люди перестают играть ключевую роль. К примеру, Генри Форд, когда поставил конвейер для сборки машин смог заменить профессионалов на дешевую рабочую силу.
А Ваши заявления лишь подтверждают суть топика. Сегодня бух (фин) учет не автоматизирован, поскольку до сих пор на 100% зависит от людей.
Если программа учета сделает бизнес прозрачным для собственника и позволить увеличить качество принимаемых решений, то как она не несет ценности для бизнеса?

Ну и наконец, осознайте, что в нашу систему курсовых поправок вносить не надо! Они рассчитываются при генерации отчетов относительно запрашиваемой валюты отчетов.
1. Так в чем это неспособность то? Почему и SAP, и 1С, и OEBS нормально учитывают изменение стоимости, а вы говорите, что они этого не делают? Что именно мешает двойной записи отразить изменение стоимости?
2. и SAP, и 1С, и OEBS автоматически рассчитывают курсовые разницы. Ничего дополнительно вносить не надо в систему (ну кроме новых курсов). Где тут тормоз учета?
3. Не получится могло по многим причинам, например, понадеялись на чудо-программу, а чудо само по себе не случилось. А чаще бывает ещё смешнее — автору внедрения говорят, что всё хорошо (чтоб не обижать), а другим внедренцам жалуются на него.

Пример с Генри Фордом может быть крайне не удачным по одной простой причине: «вы можете выбрать машину любого цвета, при условии, что это чёрный». Если так же подходить к управленческому учёту — один отчёт для всех, на все случаи жизни, тогда да, он сможет строится совсем автоматически. Только можно ли будет его использовать для управления компанией?

Расскажите как именно программа повышает прозрачность бизнеса для собственника. И я вам, со стороны клиента, покажу как от программы спрятать данные.
1. Сама по себе система не учитывает. Надо вводить корректировки.
2. Автоматически вносятся корректировки. Там много проблем с целостностью базы данных и взаимосвязью между корректировками и суммами на которые введены корректировки. Плюс практически не возможно учесть, к примеру изменение котировки акций, не будешь ведь вводить корректировку (даже программно) каждую секунду.
3.…

Дальше вообще все не в тему. Я говорил про автоматизацию и ценность и независимость от человеческого фактора.

Если данные представлены в триаде отчетов, где значения баланса проверяются в живую, а управленческая детальная отчетность это своего рода детализация данных финансовых отчетов, то попробуйте чейнибудь спрятать. Можно лишь обманывать в значениях инвентаризаций, но это можно проверить.
Проблемы в том, что дополнительные начисления производятся на сумму в учете. Это значит, что при изменении этой самой суммы надо производить переначиления, т.е. все должно быть связано.
Раньше мы решали этот вопрос путем того, что все поправки начислялись процедурой закрытия базы. Если вдруг нужно было откорректировать данные, то базу надо было открывать, а эта процедура удаляла все дополнительные начисления. Ну и снова при закрытии все начисления снова производились но уже на откорректированные суммы. Это было 4 года назад. И в реально практике было еще пару кнопок для проверки целостности данных, потому как все это порождало кучу всяких ошибок. Не подошло. пришлось дальше решать.
Фраза «дополнительные начисления производятся на сумму в учете» разорвала мне мозг в клочья. Как может быть в учете сумма без валюты учета? Если валюта учета есть, то никакие расчеты потом не нужны, всё считается в момент фиксации операции, а если валюты учета нет, то возникает сразу куча проблем, например, непрерывность учета, сегодня эта операция в отчеты попала в одном виде, а через месяц в другом (потому что правила расчета показателей, например курсы валют, могли измениться).
Именно поэтому и ввели понятие «валюта учета», чтобы не было проблем с интерпретацией показателей. А когда валюта учета есть, то никакие расчеты «потом» не нужны, в проводках уже лежат окончательные данные для отчетов, и задача отчетов только собрать эти проводки в какие-то группы
Даже обычный ПК может производить миллионы арифметических операций в секунду. Основное время тратится на запрос данных к базе. Поэтому считать проще и быстрее. Но это очень часто рвет мозг, поскольку кажется, что это не так.
Перефразирую: дополнительное начисление (к примеру курсовая поправка) начисляется относительно суммы, уже записанной в учет.
что в международных правилах учета (IAS, GAAP), что в отечественных российских (да и на украине тоже) любое начисление — это отражение какой-то хозяйственной операции. Поэтому очень интересно какие именно дополнительные операции возникают.

С курсовыми разницами понятно — изменяется курс какой-то дополнительной валюты (например, валюты задолженности) относительно валюты учета. Но тогда в учете должна быть фиксирована валюта учета и тогда никакие доп. расчеты для построения отчетов не требуются, потому как все расчеты уже проведены на этапе фиксации операции в учете (иначе будут разрывы в отчетности).

Какие еще доп. начисления у вас могут быть? А если их нет, то зачем тогда доп. расчеты «потом»?
там в топике есть вторая картинка, там вроде бы нормально все показано.
Дополнительными операциями я назвал начисление курсовых поправок и переоценок, поскольку этих финансово-хозяйственных операций в принципе не происходит.
Как не происходит? Для переоценки нужен приказ, нужна комиссия, которая проведет анализ, определит новую стоимость, подтвердить адекватность этой стоимости. Тут хозяйственная операция на лицо.
Изменение стоимости происходит и без участия комиссии. Т.е. цена меняется и без ее решения в реалии.
А вот в учете в существующих системах это отражается только после начисления.
Изменение стоимости это факт, но не операция бизнеса.
так и в учете должно происходить. стоимость изменилась и без дополнительных начислений это должно быть учтено.
если стоимость меняется сама без комиссии, то есть серьезные сомнения в том, можно ли доверять данным такой системы (речь не идет о курсовых разницах, которые достаточно жестко регламентированы во всём мире)
тут разговор не ведется о регламентном учете.
а какая разница чем регламентируется учёт: государством или компанией? Приказ об учетной политике он и есть приказ
Если ввести параллельный план счетов для переоценок и прочих исторических поправок (свой для каждой условной валюты или разреза), то автоматическое движение на его счетах будет сугубо техническим, и не будет затрагивать материальную и прочие ответственности должностных лиц, хотя будет привязано к тем же первичным документам что и стандартные проводки.
А в отчетах — агрегировать данные по разным планам счетов.
Да, именно так делается в SAP и MS Dinamics AX.
Но это не решает задачи в целом.
Вот только аудиторы очень не любят параллельные планы счетов. Если удастся уговорить их, то отлично!
Это комментатор немного неправильно выразился. Не параллельный план счетов, а дополнительные счета для учета поправок в разных валютах учета.
С терминологией я не знаком — я говорил про суть.
Введение пары дополнительных счетов, обороты по которым не влияют на обороты стандартных счетов, — эквивалентно параллельному плану счетов.
А им вообще незачем знать как это внутри устроено.
Вы же не спорите с аудиторами на тему естественный или суррогатный ключ использовать в таблицах?

А реализация именно на проводках дает возможность использовать существующие механизмы, а не писать дублирующие.
Отличная серия статей!
Бухгалтерские науки нуждаются в серьезных реформах.
То что я видел в некоторых фирмах, отнюдь не маленьких это просто караул.

Вы делаете отличную работу!
Согласно всем канонам современных методов учета, ответ, конечно же, 50.
Но ведь есть здравый смысл! Если бы у вас на складе не было в наличии этой единицы, вы бы купили ее у поставщика за 120 и продали за 150 с наценкой 30. Следовательно, 20 рублей дохода вы получили не от продажи, а от того, что эта единица просто лежала у вас на складе. Другими словами это переоценка, которую двойная запись не умеет учитывать, а все каноны построены с учетом ее недостатка.


А ведь абсолютно верно.

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

И в Income stmt. это транзакция продажи распадется на доходы от оперативной деятельности и доходы от финансовой деятельности.

Век живи, блин, век учись.
Хм, не совсем понял постановку вопроса. Товар купленный по 100, продаю по 150, 50 — доход. То что на текущий момент (еслиб склад был пуст) товар стоит 120 и доход будет 30 это немного другое.
На складе вполне может лежать:
1. Товар А, январь, куплен 100р
2. Товар А, февраль, куплен 120р
3. Товары А, март, проданы 150
Доход: 80р.
Все логично, или?
Я вопроса не ставил (:

Все как бы правильно.
Но вот нюанс.
Навар с январского товара 50. Навар с февральского 30. Все правильно.
Денег на счету стало на 80 больше.

Однако, что это за прибыль? Товар на складе это инвестиция. Длинная позиция в А.
Поэтому навар на продаже это 30+30.
Навар на инвестиции: 20

Итого те же 80. Но это разные статьи доходов.

Как при торговле акциями. Есть заработок на изменении курса, а есть заработок на спреде. Это разные вещи.
Предыдущий коммент неплохо объясняет. Но…
Себестоимость можно считать по-разному. Лучше если система сможет позволять работать с различными вариантами.
А в примере нет правильного варианта, а есть два варианта себестоимости.
В данном случае всё абсолютно не верно!

Любая коммерческая организация живет ради получения прибыли!!!
А прибыль, как известно, это разница между доходами и расходами. Поэтому каждая компания стремится продать по-дороже, а купить по-дешвле. Именно на этом базируются вся система скидок и индивидуальных условий договоров.
Ваша же логика оценки всего по текущей рыночной стоимости ставит вообще полный крест на бизнесе как явлении и вообще убивает всю прибыль.

Народ, очнитесь! Достаньте здравый смысл и внимательно посмотрите еще раз на то, что такое бизнес, что такое учет и зачем обе этих вещи нужны
Ну в данном случае доходом будет наценка, а вопрос от какой себестоимости она рассчитывается.
Странно, вы говорите, что прочитали кучу учебников по финансовому учету, а с понятием доход как-то путаетесь. Доход это все полученные средства, с учетом всех наценок и скидок. Наценка — это не доход, это просто наценка.
Предлагаю не спорить по поводу терминов. Выручка, доход, прибыль, финансовый учет, управленческий учет, расходы, издержки и пр.
В том комменте я подразумевал не выручку, а именно доход (прибыль) profit, если изволите. Кто-то может пытаться в учебнике устанавливать конкретику, но в целом ее нет.
Доход и прибыль это основополагающие понятия финансового учета. И это два совсем разных понятия. Очень надеюсь, что в своей статье не вносили вот таких собственных смыслов в обще употребительные термины, а то вообще чёрти что выходит.

Желаю вам, чтобы вашим клиентам было так же пофиг на финансовые термины и их смысл, как и вам самим
Да, Вы правы. Я согласен. Принцип двойной записи так же является основой финансового учета.
Мне пришлось много времени потратить чтобы вылезти из стереотипов. Возможны перекосы в другую сторону. :)
Предлагаю провести такую аналогию: двойная запись (проводки) — это структура хранения данных, программы, которые обрабатывают проводки — это алгоритмы. Дальше давайте применим опыт и измышления Никлауса Вирта на тему алгоритмов и структур данных, что из них важнее и что чем управляет. У меня после этого выходит, что при аккуратной организации плана счетов и продуманного журнала хоз. операций, места для всяких расчетов уже практически не остается, почти все отчеты собираются просто остатками на счетах.
Расчеты будут нужны только для того, чтобы протащить к продажам аналитику закупок, но и то, расчеты нужны только в случае экономии места на дисках. Если ограничений по хранению данных нет, то и для получения отчетов в аналитике закупок расчеты не потребуются.
Много вы видели аккуратной организации?
В больших компаниях видел много. Правда я туда попадал на проекты, когда эта «аккуратность» вводилась в компании. А что и как обстоит в других компаниях, с которыми я не сталкивался по работе, о тех могу судить только по слухам, а слухи крайне противоречивы и не надёжны
Одним из основных признанных недостатков двойной записи обозначают ее применимость только в крупном бизнесе. Там есть ресурсы, чтобы добиться этой аккуратности.
Двойная запись наоборот сильно облегчает ручной труд бухгалтера, в том числе и в мелких компаниях. Вопрос лишь в том как организован процесс сбора/подготовки документов и насколько оптимален план счетов, который выбрал себе бухгалтер
А что Вы скажете о том недостатке, который описан в статье.
Неспособность учитывать изменение стоимости во времени?
На мой взгляд это недостаток системы, в которой ведется учет, а не двойной записи. Посмотрите на любой банк в мире, они ведут учет в двойной записи миллионов счетов во всяких разных валютах, котировки по которым меняются непрерывно и никаких недостатков в учете не видно.
Вопрос в том, что учитывать и как. Если нужно учитывать изменение котировок, значит появляются хоз операции переоценки и двойная запись ничем не мешает. А вот когда финдиректор подписался под отчетностью, а отчетность потом система пересчитала — это офигенно большой недостаток!
Именно для борьбы с этими недостатками и был придуман аудиторский след. Да, ваше решение может упростить некоторые задачи формирования отчетности, но оно не решает массы других фундаментальных требований учета, без которых полученная отчетность не имеет никакой ценности (ведь в любой момент она может изменить стоимость активов)
Недостаток как раз от двойной записи. А решение этого недостатка внешнее. А это порождает в свою очередь другой недостаток, а именно, данные в учете не соответствуют действительным значениям. В статье есть рисунок с примером.
Банки на белом коне, согласен. Они молодцы и в смысле повседневности, и в смысле многовалютности. Но такие решения очень сложны и дорого стоят, чтобы это работало в реальном бизнесе ниже крупного.
Попробуйте присмотреться к проблеме изнутри. Двойная запись появилась с появлением бумажного носителя информации (не будем брать в учет инков с узелками). Технология бумагопечатанья стала прорывом и для учета. Сейчас мы имеем дело с новым носителем информации, где городская библиотека может поместиться в пол квадратных сантиметра. А возможности оперирования с данными несравнимы с тем, что можно сделать на бумаге. Вы действительно думаете что базисный способ учета не должен быть пересмотрен при таком прорыве в информационных технологиях?
Двойная запись появилась не с появлением бумаги, а для исключения ошибок, как в вашем примере:
1. заплатили за товар 100 рублей
2. продали этот товар за 150 рублей
3. получили прибыль 30 рублей
Для ЦИК-а это может и нормальная математика, но для любого человека считающего свои деньги, такая картина вызовет только одно чувство — «меня нае… ли!!!»

Двойная запись как раз и не позволяет возникнуть таким ошибкам. Подобные ошибки технически не могут возникнуть, когда есть двойная запись, а когда её нет, то аудиторам придётся проверять за вами каждую проводку и каждую операцию. Добавим сюда, что час работы аудитора стоит дороже часа работы программиста или внедренца (потому что аудиторы несут и финансовую и уголовную ответственность за свои заключения), и что тогда остается собственнику компании — платить лишние деньги за аудит, но сидеть на модной системе, или использовать устаревшую двойную запись (а ей, говорят, уже 500 с лишним лет) и платить аудиторам в рамках обще рыночных традиций?
1. заплатили за товар 100 рублей
2. продали этот товар за 150 рублей
3. получили прибыль 30 рублей
4. переоценка товаров 20 рублей.
Во всех финансовых учебниках написано, что прибыль это разница между доходами и расходами. В данном примере доходы: 150 рублей (продали товар), расходы: 100 рублей (купили товар), значит прибыль будет 150-100=50 рублей. как у вас получается 30?

Что такое «переоценка»? Это статья P&L, статья баланса, что это?
В суммовом выражении это статья P&L, в накопленном статья баланса.
Скажу, что разработано новое устройство формы счетоводства и способ записи данных в базу счетов учета применяемый в нем. В патентной заявке изобретение опирается на существующие формы счетоводства и принцип двойной записи.
Через пол года материалы будут опубликованы и станут достоянием общественности.
Любая инновация не может быть устроена так, чтобы иметь недостатки по отношению к уже существующему уровню решения.
Основное и самое великолепное свойство двойной записи — это сбалансированность счетов. В новом устройстве счета так же сбалансированы.
Это как процессор для обработки данных. Наружу можно дать бухгалтерам привычный им план счетов и привычные им таблички с дебетами и кредитами. Только с одним преимуществом, переоценки и курсовые поправки будут учитываться без дополнительных проводок (начислений), а именно внутрисистемно.
Официальный учет еще долго будет существовать так как есть. Он же по правилам ведется. Но есть владельцы бизнеса и топ менеджмент, которые реально не получают от учета удовлетворительных для них результатов. Делайте выводы.
Как это владельцы и топ менеджмент не получают от учета удовлетворительных результатов? Цель существования МСФО (он же IFRS) как раз для того, чтобы предоставлять адекватную финансовую информацию для управления деятельностью предприятия.
Нет цель стандартов более широкая, но главное чтобы внешним сторонам можно было сравнивать несравнимые бизнесы. В целях управления и владельческого контроля не совсем подходит, поскольку там нужна специфика в формах.
МСФО не ограничивает формы, а только определяет принципы учета, чтоб как раз финансисты (и не только они) могли понимать что творится в компании.
И отличие внешних сторон от внутренних тут только в уровне детализации данных, а не их сути.
Еще вопрос по поводу оптимальности плана счетов.
В tma-системе всего четыре счета и это обозначается как оптимальная структура для электронного варианта.
Что подразумеваете Вы под оптимальным планом счетов?
Оптимальный план счетов, это такой план счетов, который позволяет без расчетов получить всю необходимую для управления предприятием финансовую отчетность. Как такое можно сделать на 4-х счетах — я не представляю, потому как даже в пробном балансе 6 (шесть) разделов, а не 4.
Самое быстрое решение получится если будет всего один счет.
Вернее всего одна таблица в базе данных, в которой будет поле с указанием той статьи для отчетов (номер счета по плану). Но если рассмотреть в рамках различных аналитик. К примеру, деньгам нужно место учета денег, а долгам этого поля не нужно. Разобрав эту таблицу таким образом, чтобы все поля аналитик при каждой записи были заполнены, вы получите четыре таблицы, которые мы назвали деньги, ценности, долги и убыток. Для tma-системы это основные элементы финансовой отчетности и плана счетов.
В привычной для вас практике такими основными элементами являются активы, обязательства, капитал, доходы, расходы (это тоже со школьной скамьи). Но данное деление идет исторически согласно требований финансового менеджмента к формированию основных показателей. К примеру, нужна рентабельность активов, значит его надо собирать как основной элемент.
Возьмем активы. там собрались деньги, ценности и положительные долги.
с точки зрения математики и баз данных. Это не совместимые элементы
Дебиторская и кредиторская задолженность — положительные и отрицательные долги. Если рассматривать с точки зрения цифр это лишь положительные и отрицательные цифры. зачем их растаскивать по разным таблицам. при запросе можно растащить.
Наоборот в обычной бухгалтерии приходится делать дополнительные проводки между счетом деб задолженности и кред задолженности.
Доходы и расходы. с точки зрения цифр — это положительные и отрицательные цифирки их тоже не надо растаскивать по разным элементам.
Вот так и получается, что с точки зрения баз данных и компьютеров оптимальным будет иметь всего четыре таблицы (счета)
ой!
Давайте пойдем издалека. Какие задачи и проблемы должна решать финансовая программа? Наиболее естественный (с моей точки зрения) ответ на этот вопрос — программа должна решать финансовые задачи и проблемы. Именно поэтому логично строить систему в финансовых терминах, а не в терминах таблиц.
А с финансовой точки зрения дебиторка и кредиторка — это разные понятия. Программист, конечно, может решить что и то и другое долги, только с разными знаками, поэтому давайте их держать в одном месте. Отлично, сделали как хочет программист.
А потом, когда программист уже давно свалил с проекта, получив бабло, выясняется куча интересных моментов, например:
— дебиторкой занимаются одни люди, например, отдел продаж, а кредиторкой другие, например отдел закупок
— оборачиваемость дебиторки любая компания стремится повысить как можно больше, а оборачиваемость кредиторки снизить, т.е. от клиентов нам деньги нужны как можно скорее, а поставщикам будем платить как можно позднее
— дебиторка или кредиторка (возможно и обе) могут быть не только «товарными», но и финансовыми (например, векселя). причем эти векселя могут быть совсем не симметричны, например, мы их можем принимать, но никому не выдаем. аналитики дебиторки и кредиторки становится разной.
— дебиторка может вестись в филиалах, а кредиторка в центральном офисе, для случая централизованых закупок. требования к отчетности по дебиторке и кредиторке в этом случае тоже становятся разными, как и требуемая аналитика
— и т.д.

Поэтому объединение дебиторки и кредиторки в одну кучу требует очень серьезного просчета последствий от этого объединения. И скорее всего эти последствия определенным образом ограничат применение вашей системы в строго определенных рамках. Кстати, у вас эти ограничения прописаны в явном виде или клиент узнает о них только в момент/после внедрения системы?

Теперь перейдем к вопросу техники. С чего это вдруг с точки зрения базы данных оптимально держать разнородные (по объему своих свойств) объекты в одной таблице? С чего это оптимально разным отделам лазить в одну и ту же таблицу, натыкаясь на конфликты и блокировки, при большом объеме операций?
Почему вообще журнал проводок должен раскидываться по разным таблицам? Или у вам нет такой отдельной сущности, как журнал проводок, он же главная книга в западной терминологии?
:). Не ну реально улыбнуло. Не в обиду плз.
Представьте, что вы разрабатывая процессор думаете о конкретных бизнес задачах.
Постарайтесь вы уже отойти от стереотипов и понять что вы живете в компьютерном веке, а не в бумажном!
С таким подходом программисты получают задание сделать мемориал (как он же был в бумажном виде), главную книгу (тоже было), разбить счета как это полагалось на бумаге, ведь туда будут ползать разные отделы! Но этой перезаписи в компьютере не надо! Это было надо на бумаге!
Попробуйте немного разобраться в том, как работают реляционные базы данных, потом уже с этим подходам порешать задачи бухгалтерии и учета, которых вы действительно хорошо разбираетесь.
Тут я думаю наш разговор зашел в тупик, но людям будет очень полезно прочитать эти комментарии.
Кстати, вы в живую видели как ведется учет на бумаге? Там не было главной книги, там были журналы, ордера, шахматка. Главная книга появилась как раз тогда, когда учет начали вести на компьютерах.

Про реляционные базы данных не совсем понял в чем именно надо поразбираться. Не могли бы вы как-то сузить и очертить ту область, где у меня совсем уж большие пробелы?
Главная книга была еще в новолитовской форме счетоводства, пять веков назад.
Шахматная форма счетоводства — это изобретение прошлого веко. Всего в истории было чуть больше 10 форм. На эту тему лучше почитать раздел занимательная бухгалтерия статьи Соколова Я.В.
Кстати в конце позапрошлого века русский бухгалтер Есерский предложил тройную русскую форму счетоводства, которая была признана во всем мире, наряду с логисмографией и прочими формами. Его устремлением было найти способ учета, при котором будет возможность контролировать успешность бизнеса в масштабе реального времени. Он это сделал, правда при этом лишился учета долгов. У него было три счета: Деньги, ценности, капитал.
В статьях Соколова есть один минус, он подробно описывает всякие журналы и мемориалы, но почти ничего не пишет про главную книгу. А там, где он хоть какое-то внимание ей уделяет, например, в описании американской системы счетоводства, главная книга вдруг становится журналом.
Поэтому рассматривать его статьи могу только так, как он их называет сам — «занимательные».
вообще-то это был самый авторитетный человек из бухгалтерской науки и не только по России.
Разве авторитетность может помешать человеку писать занимательные статьи для начинающих? :-)
опечатка: не новолитовская, а новоитальянская. сорри
Что касается наценки. Безотносительно учений по финансам. Вы подумайте. Вы купили, привезли, сохранили, положили на полку, доставили потребителю. Наценка — это ваш доход за все услуги, которые вы оказали в процессе перепродажи.
Если вам удобнее мыслить стереотипами из учебников, то я спорить не буду.
> В данном случае всё абсолютно не верно!

Ок. Ждем срыва покрова.

> Любая коммерческая организация живет ради получения прибыли!!!

Да ну? Я конечно понимаю, что то что вы сказали истина, но не могу связать это со статьей.
А причём тут статья? я отвечал на комментарий. То, что я в отдельных местах не соглачен/не понимаю автора статьи, я с ним отдельно обсуждаю
Похоже мы друг друга не поняли. Ну и пусть.
фигня какая-то

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

про тавар на складе — то же самое. На складе есть не 100 или 150 рублей, а товар и цена покупки никак не должна влиять на прибыль = разница двух зафиксированных в результате сделок цифр и никакие возможности на нее влиять не должны.

Если же хочется получить какие-то дополнительные отчеты, то это совершенно другое дело и к бухучеты не имеет отношение.
1. Вы попали в точку. Учет должен быть в фактических единицах (натуральном выражении единиц учета). Да вот только согласно принципа двойной записи учет должен быть в единой учетной валюте, иначе суммы по дебету не будут равны суммам по кредиту. Другими словами данные в учете не будут сбалансированы. Это и есть то противоречие, которое решено в tma-системе.
2. У Вас очень правильный ход мыслей!
3. Бух учет от фин учета в контексте данного материала отличается заинтересованными лицами и формами, но по базисным принципам это одно и тоже.
> — Возможность расчета отчетов в различных вариантах себестоимости.

Такая опция приведет к замедлению отчетов о себестоимости при больших объемах данных в отчетах.

В принципе, учитывая концептуальное стремление автора все расчитывать на лету, для больших объемов данных основная задача «учет в реальном времени» будет возможен только при условии наличия большого количества кофе )
готовы выходить на Украину? готов сам немного шишек набить, главное — результат :)
НЛО прилетело и опубликовало эту надпись здесь
Да именно так, но это только малая часть системных изменений. Гоу в личку.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий