ЭкаунтоЛогика 1.0



    Хочу поделиться с уважаемой публикой.

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

    Сказано – сделано: изучил язык программирования, насколько это оказалось в моих слабых бухгалтерских силах, и написал.

    Ниже предлагается синопсис того, что в итоге данной интеллектуальной эпопеи получилось – во всяком случае, того, как это задумывалось. Надеюсь, специалисты в области бухгалтерского софта смогут оценить новизну реализованной в программе методологии – хотя понимаю: это заведомо сложней, чем позубоскалить над усилиями новичка-«программиста».


    «ЭкаунтоЛогика» – конструктор для учета вещей (только не по бухгалтерским правилам, а по естественным, заимствованным у природы).

    Интерфейс зауряден:
    • либо стандартная таблица,
    • либо более наглядные иконки (с отображением свойств текущей иконки в инвертированной табличке слева).



    Каждая вещь либо поступает, либо выбывает (регистрируется соответственно по приходу или по расходу).

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

    Светофор изменил цвет – предположим, с желтого на красный, – это один и тот же светофор или два разных светофора? Вопрос философский: в какой момент вещь изменяется настолько, что превращается в другую вещь? Можно решить так, а можно иначе: соответственно, перенести выбранный метод в программный код. «ЭкаунтоЛогика» решает таким образом, что для нее желтый светофор – это один объект, а красный светофор – другой: таким образом, при загорании на светофоре другой лампочки имеет место расход «желтого» светофора с одновременным приходом «красного» светофора. Следовательно, одно действие (в данном примере – загорание другой лампочки на светофоре) выполняется одновременно с несколькими вещами, причем с одними вещами по расходу, а с другими по приходу.

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



    Перечень действий, выполняемых в «ЭкаунтоЛогике», не совпадает с принятым в традиционной бухгалтерии: не малопонятные «дебет» и «кредит», а осмысленные операции с вещами окружающей реальности:

    добавить (то есть внести в учетную систему, зарегистрировать в ней),
    соединить (несколько вещей в одну),
    изменить (те или иные свойства вещи),
    передать (другому лицу),
    разделить (одну вещь на несколько),
    удалить (вычеркнуть вещь из учетной системы).

    Действия выполняются из типового диалогового окна. Приход и расход в нем присутствуют, однако не выпячиваются, а существует «постольку, поскольку».



    Регистрация первичных данных – первая из двух обязательных сторон учетной программы, а как в «ЭкаунтоЛогике» решена вторая задача – генерация отчетов? При помощи так называемых отчетных папок.

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



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

    В соответствии с нашими установками, на верхнем уровне расположатся папки с названиями.



    Зайдя внутрь какой-либо папки, на втором уровне иерархии мы обнаружим папки с местами хранения, и т.д.

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

    Что такое обязательство – имею в виду не юридическое определение, а суть дела? Те же вещи окружающей нас действительности, которыми кто-то обязывается в пользу другого. Эти вещи существуют не в настоящем, в будущем:
    • бухгалтерская дебиторка – вещи, которыми кто-то обязался в нашу пользу (таким образом, вещь должна к нам поступить);
    • бухгалтерская кредиторка – напротив, вещи, которыми мы обязались в пользу другого (по причине чего вещь должна от нас выбыть).

    Другими словами, обязательства – не особый объект учета, как ошибочно считается в традиционной бухгалтерии, а вещи, регистрируемые будущей датой: так они и учитываются в «ЭкаунтоЛогике».

    Предположим, вещь зарегистрирована 25 ноября с датой совершения 27 ноября.



    Что это означает? Только то, что 27 ноября она должна поступить: обыкновенная вещь – никакое не обязательство.

    Обратите внимание на организацию учета по времени:
    • в отчетах за 24 ноября мы ничего увидим (а что мы можем увидеть, если регистрация осуществлена 25 ноября?),



    • в отчетах за 25 ноября мы увидим будущую вещь – дебиторское обязательство. Указание для действия вероятности позволяет отражать данный еще не состоявшийся объект с коэффициентом (вещь поступит нам с вероятностью 90 %),



    • после даты совершения мы увидим ту же самую вещь в качестве наличной, действительно поступившей (и в этом случае никакого коэффициента вероятности быть не может: вещь или поступила, или не поступила, третьего не дано).



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

    Конечно, регистрировать приходится не только дебиторку, но и кредиторку (с точки зрения экаунтологии, будущее выбытие вещи), и тут намечается некая непривычная счетному работнику сложность. Это в бухгалтерии можно зарегистрировать кредиторку безотносительно тому, чем обладаешь на данный момент, – но только не в «ЭкаунтоЛогике», которая берет пример с реальности. Разве в реальной жизни вещь может выбыть раньше, чем поступила? Не может, немыслимо такое, потому и в «ЭкаунтоЛогике» немыслимо: для регистрации будущего выбытия вещи необходимо сначала зарегистрировать ее поступление, текущее или будущее (предполагаемое).

    При очень, ну очень большом желании можно указать для будущего прихода вероятность 0 %, а для будущего расхода 100 %, тогда строка покажет потенциальное превышение расхода над приходом (лишь до момента наступления даты прихода, естественно).



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

    Что такое доходы и расходы, в бухгалтерском учете прописано не очень понятно – правду говоря, отвратительно. Зато в «ЭкаунтоЛогике» определение формальное: доходы и расходы – числовые характеристики действия.
    Реализованы оба представимых способа вычислений.

    Допустим, произошла усушка, масса вещи уменьшилась с 3 кг до 2 кг. Согласно экаунтологическому подходу, в операции изменения задействовано два объекта:
    • первый объект массой 3 кг (регистрируется по расходу),
    • второй объект массой 2 кг (регистрируется по приходу).

    В соответствии с первым способом исчисления доходов-расходов, расходы составляют 3 кг, а доходы 2 кг. Согласно второму способу расходы составляют 1 кг (3 кг – 2 кг), доходы по понятным причинам отсутствуют. Пусть никого не смущает измерение доходов и расходов массой: при использовании другого измерителя доходы и расходы будут измерены в другой числовой характеристике (количестве, рублях, долларах, евро, тугриках, биткойнах) – в какой только пожелаете.

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



    Предвидя упреки в скудости отчетных форм «ЭкаунтоЛогики», поясню. Программа не предназначена для конструирования отчетов: форма отчетов единственная, тем не менее позволяющая получать в рамках реализованной методологии обороты-сальдо и доходы-расходы по любому пользовательскому разрезу данных. Дальнейшая обработка отчета производится путем экспорта в Excel.

    Мне как разработчику (ну кто о себе доброго слова не скажет?!) методика представляется:
    • гибкой (учетный конструктор – этим все сказано);
    • продуманной и формализованной;
    • прогрессивной (достаточно отсутствия того, что в бухгалтерии называется «закрытием отчетного периода». В «ЭкаунтоЛогике» сальдо подсчитываются на основании простой выборки, без последовательного суммирования по операциям);
    • обеспечивающей совместимость пользователей, ведущих независимый друг от друга учет.

    Последнее является главнейшим качеством программы, ради которого она проектировалась.

    Увы, полная совместимость не реализована в силу необходимости обмена данными через сайт (наподобие электронной почты), чего мне на сегодняшний день не осилить. Поэтому версия 1.0 десктопная: пользователь может зарегистрироваться под разными именами и передавать вещи самому себе, при этом базы данных с различной структурой согласуются между собой. Этим коммуникативные возможности программы исчерпываются… однако же могут быть расширены в следующих версиях. Нет, ну представьте: программка, установив которую на компьютер, можно получать сведения по купленным в магазине товарам непосредственно в личную базу! Дополнительный вид услуг, оказываемых торговыми точками!

    Если у кого-то появилось желание опробовать «ЭкаунтоЛогику» вживую, скачать ее можно отсюда.

    Системные требования: 32-разрядный Microsoft Office и 32-разрядная Windows. Если у вас 64-разрядная Windows, то, скорей всего, придется установить утилиту Microsoft Access Database Engine 2010 (32-разрядную). А при 64-разрядном Microsoft Office все равно не работает: провайдер Microsoft.ACE.OLEDB.12.0 не позволяет. Если кто подскажет, возможно ли решить проблему без замены провайдера, буду признателен.

    Нет, а чего вы хотите от бухгалтера! Никогда раньше не программировал… программа учебная (во всех смыслах слова), сырая и, между прочим, довольно объемная (мне сказали, что 30 тыс. строк кода — это немало)… Посему не обессудьте, «ЭкаунтоЛогика» предлагается для ознакомления с оригинальной учетной методикой – в соответствии с принципом «as is» (что в переводе на русский означает: чем богаты, тем и рады).
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 170

      +4
      Какую задачу решает ваша программа?
        +4
        Обычную учетную. Только не по бухгалтерским правилам, а по естественным — природным.
          +4
          Я не знаю, что такое «обычная учетная», учет — дело очень многоликое. У нас вот тут тоже «обычная учетная задача» на несколько лет разработки и поддержки.

          Чем ваш подход лучше существующих?
            +5
            Вот, чуть ниже, другому пользователю ответил:
            habrahabr.ru/post/244465/#comment_8156115
            Могу добавить: мой подход базируется на научной разработке — изобретенной мной экаунтологии (ну, можно отрицать ее научное значение, но факт остается фактом: только после того, как я привел мысли в порядок, удалось сделать что-то формально работающее). Теперь немного хронологии: чтобы по минимуму освоить C# и накатать на нем 30 тыс. строк (пусть непрофессиональных, а какая разница?), мне понадобилось полгода. А чтобы создать более-менее связную теорию учета, потребовалось около 7 лет непосредственного создания плюс лет 10-15, что называется, подступов к теме. При том что у меня высшее бухгалтерское образование, на сегодня я автор десятков учебников и учебных пособий по бухгалтерскому учету и т.п. Чувствуете разницу в сложности задач? Поэтому то, что вы с налету не поняли новизну моего подхода, не удивительно. Мало кто понимает.
            Лучше других мой подход тем, что заимствует методы учета у природы, а не пытается обслуживать безумие, ошибочно именуемое бухгалтерским и налоговым законодательством.
            А учет — дело многоликое, да. Хотя учитываются, как правило, вещи (хотя бы потому, что наша Вселенная состоит именно из вещей, а остальное, в частности абстракции, являются отношениями между этими вещами). Таким образом, должны существовать общие правила учета вещей — истинная (не бухгалтерская) теория учета.
              –3
              А можно ссылки на ваши публикации в рецензируемых научных журналах?
                +8
                В рецензируемых? Я ж не физик, чтобы в рецензируемых печататься. Вообще, я печатался в бухгалтерских журналах, и достаточно широко (около сотни статей опубликовал, наверное), это было в начале нулевых. Потом перешел на книги, сейчас чаще публикуюсь в Сети.
                С моей библиографией можно ознакомиться здесь.
                  –11
                  А тогда о какой научности можно говорить? Собственные книги — это совсем не то же самое, выпустить книгу может любой, у кого есть какое-то количество денег.

                  И нет, «я потратил семь лет» — это вообще не аргумент, особенно в части сложности задач. Есть учетные системы, которые будут постарше вашей теории учета (и это только в астрономическом времени, в трудозатратах разница будет уже как бы не на порядки).
                    +8
                    В таком случае трудозатраты — тоже не аргумент…
                    выпустить книгу может любой, у кого есть какое-то количество денег

                    Пардон, но я книги не на собственные деньги выпускал (хотя пару раз согрешил, признаюсь)! Книги у меня покупали (а иногда и заказывали) профессиональные издательства. Покупатели, а потом не единожды переиздавали (пара лучших дошла до 10-го издания).
                    Разумеется, это не критерий научности (популярная бухгалтерская мура вообще антинаучна), однако и публикация в рецензируемых журналах — не меньшая мура, насколько мне известно. То есть опубликовался в рецензируемом журнале — и ученый? Вы серьезно?
                      –2
                      Так и я говорю — трудозатраты не аргумент. И отсылка к научности — не аргумент (потому что не выдерживает критики). Так что в итоге мы возвращаемся к началу: к объяснению на простых и понятных аргументах, чем предлагаемая вами методика учета лучше существующих.

                      Только пожалуйста, обратите внимание, что я говорю не о бухгалтерском учете, а о, как вы выражаетесь, «обычном учете».
                        +4
                        Перечисляю:
                        1. Учет обязательств в качестве будущих объектов.
                        2. Отсутствие понятия «закрытие периода».
                        3. Сведение дебета и кредита к приходу и расходу (в некоторых небухгалтерских учетных программах имеется, да).
                        4. Формализация понятий «доходы-расходы».
                        5. Отказ от учета бухгалтерских абстракций (при том, что в большинстве своем они могут быть получены).
                        6. Автоматическое согласование разных баз данных при передаче объектов.

                        Возможно, что-то упустил.
                          –3
                          Ну вот я смотрю на учетную систему, в которой:
                          1. Обязательств нет вообще
                          2. Нет закрытия периода
                          3. Нет дебета и кредита
                          4. Нет доходов и расходов
                          5. Нет бухгалтерских абстракций
                          6. Автоматическое согласование данных с интегрируемыми системами.

                          Что я делаю не так?
                            +2
                            Теперь, пожалуйста, вы мне ссылочку на описание своей системы.
                            А для начала можете пояснить: Петя задолжал Васе такую-то вещь. Каким образом осуществляется учет долга?
                              –10
                              Не скину — NDA. Внутренняя учетная система для ведомства.

                              Никаким: система не учитывает долги; учитывается только актуальное владение и управление имуществом.
                                +2
                                А, не учитывает…
                                Насмешили.
                                В таком случае, идеальной учетной программой является калькулятор: обязательств нет вообще, нет закрытия периода… (далее по тексту). Берите и считайте!
                                  +1
                                  (… а тем временем «в природе» так и есть — в природе никто никому ничего не должен, в природе каждая вещь где-то находится (и имеет какие-то свойства). Долги и обязательства — это введенные обществом абстракции.)

                                  Понимаете ли, я не зря в начале спросил, какую задачу вы решаете.
                                    0
                                    Не вполне понимаю.

                                    Обязательство (долг — синоним) — абстракция только в том смысле слова, что принадлежит будущему. Однако когда это будущее случится, передаваемая вещь окажется вполне реальна. И учитывать ее нужно загодя.
                                    Для сравнения: пощупать наяву резервы или собственный капитал (все — в бухгалтерском смысле слова) никак не получится.

                                    А задачу я все равно решаю учетную (не только учета текущих объектов, как вы в своем ведомстве, но и учета будущих объектов — обязательств).
                                      +1
                                      «когда» и «если» — это как раз то, что является абстракцией, созданной человеком. «Природе» не нужно ничего учитывать загодя.
                                        +1
                                        В таком случае будущее — это абстракция?
                                        Тоже точка зрения, понимаю. Однако я исходил из того, что будущее учитывать необходимо. Как и прошлое, к слову (ведь прошлое — такая же абстракция, как и будущее). Или вы в своем ведомстве только текущие вещи учитываете, без возможности сгенерировать оборотку, скажем, за прошлый месяц?
                                          0
                                          Ну вот в нашей конкретной задаче нет необходимости учитывать будущее — только прошлое и настоящее.
                                            +3
                                            В вашей нет, а в моем учетном конструкторе есть. Не вижу причин для разногласий.
                                              +1
                                              Завершился полный цикл и вы не заметили, как вопрос вернулся на круги своя: сейчас вас спросят, какую задачу решает ваш конструктор.

                                              Наблюдая данную ветку я всё же примерно понял, что у lair такая задача есть — ведомственая, под NDA. А у вас задача есть? Практическая, конкретная задача, а не «в моём конструкторе такая задача есть — учитывать будущее».

                                              Хочу понять, в каких случаях ваша система будет иметь преимущества.
                                                –1
                                                А какую конкретную задачу решает Excel? Конструктор он и есть конструктор.

                                                В свое время я опубликовал Манифест, в котором высказался о сверхзадаче экаунтологии. И на Хабре посты публиковал (Бухгалтерия будущего, к примеру). Все это довольно фантастично и напыщенно, конечно. Можете как угодно к этому относиться, а я… не то чтобы верю, просто мне хочется понять, как должно быть. То, что миллионы моих коллег выполняют в компьютерный век бессмысленную и непродуктивную работу, для меня очевидно.
                                                  +1
                                                  А какую конкретную задачу решает Excel? Конструктор он и есть конструктор.

                                                  Давайте без демагогии? Задача есть? Задача решается проще, лучше, быстрее, чем принятые и привычные методологии учёта? В чём практический выигрыш вашего подхода?

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

                                                  Двойная запись тоже не сразу прижилась, какое будущее ждёт вашу систему — никто не может предвидеть будущее. Но если у вас нет овета на практические вопросы, который неизбежно будут задавать лица, принимающие решения — ну тогда шансы на какое-то использование будут падать.

                                                  У вас ответы есть на эти вопросы? Если есть — пишите новую статью, аргументируйте.
                                                    –1
                                                    Какую демагогию вы усматриваете в вопросе: «Какую конкретную задачу решает Excel?». Есть типы программ, требующих настройки для решения конкретной задачи, моя программка принадлежит этому типу. Полагаю, не сообщил Вам ничего нового.

                                                    Конкретный плюс — возможность создания на основе данной учетной методики всемирной информационной сети. В ссылках, которые я вам указал, написано ясно и подробно. Окупаемость бизнеса меня мало волнует, потому как научно-технический прогресс часто развивается вопреки интересам бизнеса. Прошу прощения за пафос, но меня истина волнует, а не мошна толстосумов.

                                                    Про то, как, по вашему мнению, приживалась двойная запись, с интересом послушаю. Хотя предупреждаю: в этом вопросе я специалист, автор опубликованных трудов.
                                                      +1
                                                      Когда передо мной стоит задача, я могу выбрать Excel, если он мне подходит.

                                                      Вас просят назвать задачу, для решения которой было бы удобно использовать ваше решение. А вы всё уходите от ответа.
                                                        +2
                                                        Потенциальные задачи: инвентарный учет, обязательственный учет, учет доходов и расходов. Программа планируется к использованию для складского учета, домашнего учета. Версия 1.0 рекомендуется для использования в качестве учебного пособия по экаунтологии.
                                                          +1
                                                          Хорошо, поставим вопрос по другому: "… задачу, для решения которой было бы удобнее использовать ваше решение, выбирая между аналогами".
                                                            0
                                                            Во, давно бы так. Представим, что некоторая фирма заинтересовалась вашей разработкой и захотела бы у себя внедрить подобный учёт, то:
                                                            1. Какую практическую пользу она бы получила от использования вашей методики?
                                                            2. Правильно я понимаю, что пришлось бы вести по как минимум двум методикам (вашей и обычной)?
                                                            3. Если есть необходимость вести одновременный учёт по двум методикам, то задумывались ли вы о каком-то автоматическом конверторе из вашего учёта в привычный? Есть намётки, что предложить?
                                                              0
                                                              2. Правильно я понимаю, что пришлось бы вести по как минимум двум методикам (вашей и обычной)?
                                                              И да, и нет. Нет, дублировать по обычной методике не требуется. Да, на выходе придется все равно выдавать отчеты для налоговой (независимо от выбранной методики — это уже ответ на пункт 3).
                                                                0
                                                                Моя система не для фирм, а для индивидуальных пользователей.
                                                                В идеале распространение такое: торговая сеть предлагает новый вид услуг — сообщение о покупках в систему покупателя. Покупатель инсталлирует программку, регистрируется на сайте, и получает данные о произведенных покупках непосредственно в базу. Ну, типа электронной накладной, только при этом пользователь может вести домашний учет, какой захочет.
                                                                Это один из вариантов.
                                                                  0
                                                                  Существенно проще использовать пластик и использовать данные банка, чем уговаривать каждого продавца устанавливать вашу систему.
                                                                    0
                                                                    Пластик — это пластик, а речь идет о софте, об обработке данных. Пластик софту ни в коем случае не противоречит. Провели транзакцию по пластику, так пускай данные сразу попадут в личную учетную базу, в которой уже хранится информация по имуществу, по другим карточкам и банковским счетам и т.п.
                                                                      0
                                                                      Возможно Daemon_Hell имел ввиду, что реализацией и распространением такой системы должен заниматься банк. Это, кстати, очевидно на примере разных дисконтных программ. Т.к. программ много -> карточек много -> не удобно. В тоже время банковская карта всегда с собой, без неё покупку не сделаешь.

                                                                      Т.е. именно банк имеет больше возможностей и удобства для клиентов реализовать потенциал методологии, например, в личном кабинете интернет-банка. (С архитектурной точки зрения. Вопросы согласований с МПС никто не снимает).
                          +19
                          А почему сразу столько хейтерства?

                          Вроде как человек тут не пытается свои теории некому навязывать. Он сделал программу и предлагает ее абсолютно бесплатно. Попробовал — удобно — пользуйся. Нет — ну и нет.

                          Или Вам очень важно работать в программе, основанной обязательно на проверенных научных разработках, заверенных РАН или кем-то еще?
                          Ну тогда SAP / 1C да и кучу всего еще Вам в помощь.

                          Тут же не спутники запускают, а домашнюю бухгалтерию ведут.

                          А по поводу «семи лет» — то, что для одного человека — ерунда, для другого может быть жизнью. Вам никто ничего не навязывает.

                          Будьте добрее.
                            0
                            Хейтерство не к статье и не к тому, что человек самостоятельно изучил ЯП, сделал и бесплатно распространяет программу. Это как раз вызывает уважение и благодарность.
                            Напрягают комментарии. В них автор, с моей предвзятой точки зрения, повышает градус напряжения. Особенно часто встречаются конфликтогены через проявление позиции превосходства.

                            За статью и программу автору большое спасибо.
                              0
                              Как вам сказать… В целом вы правы. Однако жизнь многогранна: как методолог учета я действительно ощущаю превосходство — слишком редко встречаю людей, которые мне ровня в этом отношении. Большинство не в состоянии воспринять довольно простые вещи, которые я объясняю: даже друзья, не говоря уже о незнакомых комментаторах с техническим образованием (никого конкретно не имею в виду, просто на Хабре меня много пинали по разным поводам). Но то, что я профессиональный методолог, не мешает мне быть лохом во многих других отношениях и вообще малосимпатичным субъектом. Например, в качестве программиста я наглый самозванец и неумеха, было бы смешно утверждать что-то иное при моем стаже в программировании. Однако программировать я никого и не поучаю, не по Сеньке шапка. Все люди такие: хороши в одних отношениях и плохи в других, — вы не находите?..

                              Спасибо за статью принимаю (все-таки, помимо того, что я профессиональный методолог, я еще и профессиональный писатель), а за программу воздержусь, до полного прояснения обстоятельств. В конце концов, «ЭкаунтоЛогика» предназначена для демонстрации моей учетной методики: будучи непрофессионалом в программировании, гарантировать ее стабильной работы не могу. Здесь профессиональный программист требуется, а не бухгалтер…
                            +5
                            «Есть теории колеса, которые постарше вот этой вот вашей поделки будут!», — чего вы так неаргументированно взъелись на автора?
                              +3
                              Я не взъелся, я задал простой вопрос «чем лучше». А мне в ответ, вместо простого списка преимуществ, выдали «различия есть, огромные, но увидеть их может только методолог.… мой подход основывается на научной разработке… k лет труда»
                                +4
                                Ну дак прочтите статью, вроде из нее понятно, какими сущностями оперирует программа и сравните с теми, что применяются при учете в обычных бухгалтерских программах.

                                Или не читатель? :)
                                  0
                                  Ответил, читайте выше:
                                  habrahabr.ru/post/244465/#comment_8156309
                                    +3
                                    Найдите прошлые статьи автора на Хабре, он очень подробно разъяснял, почему существующий учет сложен и нелогичен.
                                  0
                                  А тогда о какой научности можно говорить? Собственные книги — это совсем не то же самое, выпустить книгу может любой, у кого есть какое-то количество денег.

                                  Вы бы по ссылке сначала прошли.
                                    0
                                    Been there, done that.
                      +1
                      Супер, особенно как система для «изобретения» в процессе обучения бухгалтерского учета. Ну а после того как обучающийся его изобрел, то можно добавить план счетов и вуаля, получаем толкового бухгалтера.
                        +1
                        Не увидел принципиальных отличий от традиционных учетных программ, простите. приход, расход, объекты как разрезы учета
                          0
                          Различия есть, огромные, но увидеть их может только методолог.
                          Самая кардинальная новация — восприятие обязательств как вещей, регистрируемых будущей датой. Гарантирую, что такого нет нигде (точно ни в одной бухгалтерской программе, т.к. такой естественный способ учета противоречит традиционной двойной записи, в которой обязательства — особый тип объектов). Вообще, у меня реализован отказ от двойной записи (дебета и кредита, которые в бухгалтерии не совсем равнозначны приходу и расходу). Есть другие находки, помельче.
                          А если в целом… Представьте, что вы находитесь на заводе. Вокруг здания, машины, механизмы, тюки с изделиями и проч. — то есть вещи. И никаких тебе вложений, резервов, расчетов, капитала и прочей непонятной бухгалтерской дребедени. Соответственно, вещи и учитываются — в этом отличие моей программы от бухгалтерских.
                            +1
                            двойная запись это частный случай, многие учетные программы прекрасно без нее обходятся
                              0
                              Согласен. Однако покажите мне учетную программу, в которой для принятия к учету обязательства необходимо указать дату совершения операции больше, чем дата регистрации операции.
                                0
                                Я думаю, это придет в голову каждому, кто решил сделать себе программу учета финансов и закладывать регулярные или будущие платежи.
                                Собственно, я в своем учете именно так и сделал.
                                А дебета-кредита тоже нет, есть операция, которая может быть как положительной, так и отрицательной. Просто потому, что это упрощает структуру классов, а делает тоже самое.
                                  0
                                  Верю.
                                  Решения, к которым я пришел, довольно просты. Поэтому цена программки полушка в базарный день. Однако я смог систематизировать возможные решения и изложить на бумаге (не слишком удачно, но тем не менее). Ценна теория, а не программный код.

                                  К слову, а вы можете учитывать в своей программке вещи, а не деньги? Любопытно.
                                    0
                                    А в чем принципиальная разница между деньгами и вещами? Если вести мультивалютный учет — в любом случае добавляется свойство валюта. Можно его и использовать чтобы различать вещи и деньги.
                                      0
                                      В том, что у вещей больше одной учитываемой характеристики (например, помещения учитываются по стоимости и площади).
                                        0
                                        Деньги тоже могут учитываться по нескольким стоимостным характеристикам. Например, купюра в 100 рублей — это 100 рублей, 2 доллара и т.д.
                                          0
                                          Собственная характеристика денег только одна — это сумма. Купюра в сто рублей — это сто рублей. Два доллара — это производная рассчитываемая величина (которая меняется в зависимости от чего угодно).
                                            0
                                            В целом, да. Однако тут имеет значение, это «что угодно» присутствует в системе или нет:
                                            если присутствует, то да, два доллара — расчетная величина,
                                            если нет, то два доллара (в качестве регистрируемого свойства купюры) — характеристика купюры.
                                              0
                                              Купюры как вещи. Не денег.
                                                0
                                                Да, как вещи.
                                                Просто в современной экономике деньги используются в двух ипостасях:
                                                1) в качестве стоимостной характеристики других вещей (вещь стоимостью сто рублей),
                                                2) в качестве объекта учета (в кассе 100 рублей).
                                                  0
                                                  Вот и учитываться деньги могут как вещи, а могут — как деньги (да, я понимаю, что звучит криво, но это данность). В зависимости от целей учета структура учетной системы будет меняться.
                                                    0
                                                    Структура учетной системы едина: есть вещи, а есть их свойства.
                                                    Если учитываем деньги в качестве купюр, то наличность в 100 руб. может обладать числовыми свойствами:
                                                    рублей — 100,
                                                    долларов — 2,
                                                    и т.д.

                                                    Если вы имеете в виду, что вещи могут оцениваться в рублях, то да, могут — как и в любых других своих числовых свойствах.
                                                      0
                                                      >> Структура учетной системы едина: есть вещи, а есть их свойства.
                                                      Знаете, это утверждение верно вообще для любой модели — есть сущности, есть их свойства. Вопрос в том, как именно представляются эти свойства в системе — например, возможна по ним агрегация, или нет? Есть у них история, или нет? Приводит ли изменение одного к изменению другого?
                                                        0
                                                        Агрегация — да, возможна (у меня это отчетные папки, показатели по ним подсчитываются по агрегированным данным).
                                                        История изменений — да, имеется.
                                                        Приводит ли изменение одного к изменению другого?

                                                        Смотря что под этим понимать. У меня любое изменение объекта заключается в расходе одного объекта и приходе другого (связь между ними устанавливается через операцию).
                                                          0
                                                          >> Агрегация — да, возможна (у меня это отчетные папки, показатели по ним подсчитываются по агрегированным данным).
                                                          Вы, похоже, не представляете себе стоимости такой модели (с произвольно агреггируемыми атрибутами) на сотнях тысяч и миллионах учитываемых объектов при группировке по десятку критериев.
                                                            0
                                                            Программа — для индивидуального пользования.

                                                            А то, что вы перечислили — да, не представляю (если правильно вас понял). Меня интересуют теоретические аспекты проблемы.
                                          0
                                          А. Если учитывать все характеристики объекта — то действительно все усложняется. У себя в голове я держал учет в штуках. А уже конкретные характеристики этих штук — отдельно сбоку.
                                            0
                                            К сожалению, для учетной системы как раз учет (релевантных) характеристик объекта — это основная задача. Штуки могут никого и не интересовать (как, например, никого может не интересовать, сколько именно _пакетов_ акций у вас, интересует общая доля в акционерном капитале и/или право голоса).
                                          0
                                          Правильно.
                                          Принципиальная разница в том, что вещи существуют как бы изначально, а деньги выдуманы для экономических нужд (хотя могут представлять собой вещи, но могут и не представлять). Таким образом, вещи естественны, а деньги искусственны.
                                          0
                                          >а вы можете учитывать в своей программке вещи, а не деньги?
                                          это делают все программы складского учета без исключения
                                            0
                                            У вас вроде программа учета финансов, потому и спросил.

                                            Речь идет об универсальном учетном конструкторе, функционирующем по универсальным природным правилам: что-то вроде Excel для учета. А что множество учетных программ решают локальные задача, мне известно. Ну решают. И учитывают одно и то же — вещи. И часто очень похожи друг на друга. А иногда отличаются какими-нибудь находками, умными и полезными. Однако речь не о частностях, а об учетном универсализме.
                                        0
                                        > покажите мне учетную программу, в которой для принятия к учету обязательства необходимо указать дату совершения операции
                                        каждая первая включающая в себя планирование расходов или график поступления денежных средств, например.
                                          0
                                          Мне сложно судить без конкретного примера.
                                          В бухгалтерской литературе концепция обязательства как будущего объекта не изложена. Но если кто-то из программистов до этого самостоятельно додумался, не удивлюсь.

                                          Нужен текст, в котором описывалась бы концепция обязательства. Если мои методы учета кто-то сформулировал раньше меня, я данный факт признаю. А софт- это слишком зыбко: нужно лезть в опции, смотреть базу, как она устроена… Причем наверняка выяснится, что иначе, чем у меня.
                                          0
                                          Просто для справки: все биржевые учетные системы, а также депозитарного учета и регистраторы работают с учетом в будущем времени. Основная площадка на ММВБ работает в режиме Т+2, когда сделка регистрируется сейчас а приход по ней будет учтен через два дня.
                                            0
                                            Наверное. Однако биржевая система не универсальна, это один из множества частных случаев применения учета на практике. Регистрировать что-то будущей датой, ясен пень, не я придумал. Я всего лишь создал (или считаю, что создал — на ваше усмотрение) теорию естественного компьютерного учета. Универсальную. Программа — попытка проверить, работоспособна методика или нет.

                                        +3
                                        Что-то мне это напомнило один комментарий, если я не ошибаюсь, от Milfgard: «сначала было все очень сложно и мы позвали спеца для того, чтобы он выпилил лишний функционал. Но с ростом оборота все эти аналитики оказались нужны и мы опять позвали спеца, чтобы он вернул как было». Это я вот к чему: на какой объем движений рассчитан ваш продукт? Точнее несколько не так: До какого момента роста объемов ваш подход из 6ти действий будет действительно удобней, чем дебет и кредит (вполне понятные, кстати) по нескольким счетам? И да, учитывайте, что полярный подход более привычен всем, за редким исключение: тепло/холодно, есть/нет, дебет/кредит.
                                          0
                                          Шесть действий покрывают все природные явления (все то, что можно сделать с вещами). Строго говоря, изменение объекта единственно по своей природе, а шесть действий — в некотором смысле адаптация к учетным нуждам и упрощение жизни пользователю. Можно было обойтись одним диалоговым окошком изменения объекта (но тогда пользователю было бы сложно с этим окошком работать).

                                          В том, что дебет и кредит понятны, не согласен. Вы, возможно, феномен, а вот мне, обыкновенному студенту, в институте было абсолютно непонятно: дебет — поступление денег, а какого тогда рожна поступление капитала — это кредит?!
                                            +1
                                            Да нет, я не гений) просто вы, как и все, путаете крЕдит и кредИт ) ну или путали в начале своего пути
                                              0
                                              Хм… крЕдит от кредИта я даже в начале пути отличал.
                                                +1
                                                Угу, как в бородатом анекдоте: «дебет слева, кредит справа» ;)
                                                +2
                                                Дебет с кредитом становятся понятны и логичны, как только приходит осознание, что предприятие и его владельцы – разные сущности, и учет ведется именно с точки зрения предприятия.

                                                Тогда поступление капитала означает увеличение обязательств предприятия перед владельцами, и всё становится на свои места.
                                                  0
                                                  Спасибо, с обязательственной теорией баланса я знаком. И со многими другими худо-бедно тоже (к примеру, Помазков их около четырех десятков насчитывал). Однако обсуждение счетных теорий в комментариях к этому посту вряд ли правильно. Могу лишь сказать, что ни одна из существующих балансовых теорий меня не устраивает, в том числе обязательственная (иначе бы я не изобретал собственную теорию — экаунтологию).
                                                  Если желаете услышать мои возражения по поводу обязательственной теории, найдите мою брошюру «Баланс для начинающих», 3-е изд., глава 27 «Обязательственная концепция». В Сети книга валяется, найти несложно.
                                                  0
                                                  Мне кажется что вы зря сравниваете Вашу программу с программой бухгалтерского учета.

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

                                                  добавить (то есть внести в учетную систему, зарегистрировать в ней),
                                                  соединить (несколько вещей в одну),
                                                  изменить (те или иные свойства вещи),
                                                  передать (другому лицу),
                                                  разделить (одну вещь на несколько),
                                                  удалить (вычеркнуть вещь из учетной системы).


                                                  С усушкой вы делаете на 1 действие больше чем обычно, вместо списания разницы вы списываете все, потом приходуете остаток.
                                                  Как тут будет работать партионный учет или учет себестоимости — вообще не понятно, но дело не в этом. Возьмем учет немного сложнее.
                                                  Итак у нас общепит, мы готовим некое блюдо. В простом случае (салат) мы смешали помидор и огурец.
                                                  Соединить огурец и помидор и все (ну если я верно понял вашу систему)

                                                  Но вот нам приходится готовить суп, на каждый ингридиент у нас идет от 1 до 4 (в простом случае) этапов приготовления.

                                                  Этапы к примеру свеклы:
                                                  Купили, почистили (часть притом), отварили (масса изменилась), обжарили с маслом (опять что — то поменялось с массой), бросили в суп.
                                                  Как ваша программа будет описывать каждый этап количественного учета?
                                                  Также мы понимаем что ингридиент свекла может после второй стадии (варки) использоваться в салатах (частично положим ее в винегрет) а частично обжарим.
                                                  Я понимаю что это учетная задача средней сложности. Есть более сложные варианты, к примеру учет на непрерывном производстве и т.п.
                                                    0
                                                    Про салат абсолютно правильно излагаете.

                                                    Пример с супом решается в таком же ключе, посредством выполнения изменения, соединения, разделения:
                                                    почистили — изменение (масса уменьшилась, также можно зафиксировать изменение какого-либо свойства, к примеру: вместо «неочищенная» стала «очищенная»),
                                                    если далее использовали часть вещи — разделение (одну часть — для супа, вторую — для салата),
                                                    отварили — в том же порядке, что первая операция.
                                                    Вот так это и будет описываться, как в жизни происходит. Разумеется, если нет желания регистрировать мельчайшие изменения, можно соединить ингредиенты сразу в суп (ну, еще отходы вычесть придется). Вот именно для учета таких операций программа и предназначена. Непрерывное производство тому не помеха, ведь регистрировать можно с разной степенью временнОй детализации. Если двойная запись с этим кое-как справляется, то естественная методика — тем более (я имею в виду не конкретный софт, написанный непрофессионалом, а методику).
                                                    Партионный учет (если я вас правильно понял) — не проблема, только в посте об этом не говорится. Программа позволяет учитывать вещи как по отдельности, так и кучно (посредством химического объединения), так что сложить вещи в кучу — не проблема. Учет себестоимости — тоже не вижу проблем. Если вещи объединять, то их числовые характеристики автоматически складываются, стоимость тарелки супа будет подсчитана автоматически.

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

                                                    Вообще, немного не так. Сначала разделяю вещь надвое, а потом одну из вещей удаляю. Но действий два, как ни крути, хотя одно из них можно выполнять автоматически. Сейчас у меня так реализована передача: если передаем другому лицу часть вещи, то непосредственно при передаче указываем числовую характеристику, тогда разделение вещи на части происходит автоматически. Надо будет и для удаления то же самое сделать, спасибо за подсказку!
                                            +23
                                            Плюсанул как минимум за упертость в достижении цели. Изучить язык программирования и написать программу ради реализации одной идеи — это достойно уважения.
                                              +4
                                              Спасибо.
                                              Жизнь-то короткая, и достойных целей в ней тоже немного. Зачем размениваться на мелочи?
                                              +1
                                              Конечно, автор молодец, но…

                                              Этому приложению не хватает юзабилити или удобного интерфейса.
                                              Кнопка «Служебное меню» не сразу можно найти. И зачем эта кнопка, если она повторяет все пункты меню?
                                              Горячие клавиши — тоже немного поправить бы — F5 — больше ассоциируется с обновлением данных, а не с отображением папок.
                                              В общем по хорошему надо продумать интерфейс. Но для версии 1.0 сойдет и такой. Это так, на будущее.

                                              А вообще я бы почитал отдельную статью про экаунтологию от автора, в котором он сравнивал бы с существующим подходом (дебет/кредит). И объяснил там все ньюансы, плюсы и минусы и варианты использования (масштабы применения методики экаунтологии).
                                                0
                                                Столько всего понаписано (увы, не всегда удачного), что даже затрудняюсь… Ну вот эти посты можете прочитать:
                                                geektimes.ru/post/186874/
                                                geektimes.ru/post/181077/
                                                Или посмотрите в профиле сайт (тот, который экаунтологический). Хотя, опять-таки, материал не всегда удачный.

                                                За замечания большое спасибо, учту в следующей версии.
                                                  +2
                                                  А вообще если идея такая крутая — то нужно создавать интернет-сервис. А не локальное приложение с локальной базой данных в 1 файле.
                                                  А дальше API и т.д.
                                                    0
                                                    Ага, нужно. Я год назад оборался на Хабре, пытаясь протолкнуть эту идею. Пара человек проявили интерес и мгновенно потеряли. Пришлось делать самому. Пока десктопная версия, а там поглядим… В сравнении с техническим заданием много изменений получилось: то одно с целым не вязалось, то другое — изрядно помучился.
                                                    По крайней мере, ясно, что учитывать таким способом можно.
                                                +1
                                                по естественным, заимствованным у природы
                                                законам, неисполнение обязательств не приводит ни к чему. Просто ничего не происходит и все. А в вашей методике необходимо обновлять свойства вещей (сроки прихода), иначе система перейдет в несогласованное состояние. Нет такого кладовщика Василия, который бы согласился хранить на своем складе некие вещи, объем которых в прошлом изменяется в будущем. Я не понимаю, в чем кроме лени, причины хранить разные сущности (материальные и нематериальные) в одном измерении.
                                                  0
                                                  Дело в том, что природа учитывает не бухгалтерские обязательства (неисполнение которых действительно ни к чему не приводит), а вещи. Грубо говоря, если природа зарегистрировала, что через неделю метеорит упадет кому-то на башку, то метеорит обязательно упадет, будьте уверены. А вы говорите, ни к чему не приводит!
                                                  Аналогичным образом, если у меня регистрируется вещь, она обязательно случится, если только Творец Системы (в данном случае я, как в предыдущем случае Природа) не исправит зарегистрированное ранее. Вы написали:
                                                  А в вашей методике необходимо обновлять свойства вещей (сроки прихода), иначе система перейдет в несогласованное состояние.

                                                  А все ровно наоборот: как зарегистрировал, так и случится. А если выяснилось, что зарегистрировано неправильно, нужно исправить.
                                                  Вы глубоко копнули, но немного недопоняли.

                                                  Что касается кладовщика Василия, полностью согласен: кладовщик будет недоволен (как, впрочем, при любой смене программного обеспечения).

                                                  Я не понимаю, в чем кроме лени, причины хранить разные сущности (материальные и нематериальные) в одном измерении.

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

                                                    Все бы ничего, но эту посылку доставляет Почта России, и дата ее прибытия подчиняется принципу неопределенности. Как регистрировать обязательство Почты России перед нами в объеме одной посылки в вашей программе?
                                                      0
                                                      На начало примера (допустим, 1 декабря) зарегистрирован объект, допустим со свойствами:
                                                      Название = посылка,
                                                      Место = филиал № 1.
                                                      Отправили посылку 2 декабря, предполагаем получить 12 декабря. Регистрируем передачу объекта на почту (дата регистрации 2 декабря, дата совершения 2 декабря):
                                                      Название = посылка,
                                                      Место = почта.
                                                      Теперь регистрируем ожидаемое поступление с почты в головной офис (дата регистрации 2 декабря, дата совершения 12 декабря):
                                                      Название = посылка,
                                                      Место = головной офис.

                                                      Это если учет ведется в одной программе. Если головной офис и филиал — разные лица, то иначе. Долго все варианты рассматривать.
                                                        0
                                                        Я не зря упомянул Почту России. Наступило 12 декабря, посылки нет.
                                                          0
                                                          Тогда придется отодвинуть обязательство (будущий объект) на более позднюю дату.
                                                            +1
                                                            Какую? Откуда ее взять-то, если даже лучшие шаманы лишь разводят руками? И сколько раз придется эту дату передвигать?

                                                            Предлагаю ввести дополнительную сущность — «плюс вечность», как бесконечно далекий момент времени в будущем. В момент возникновения такое «неопределенное» обязательство регистрируется как проводка с датой исполнения в вечности — а в момент исполнения эта дата сдвигается на текущую.
                                                              +1
                                                              Верно! Была такая идея, но потом от нее отказался. Зачем, если можно отодвинуть обязательство на 100 лет?
                                                                +2
                                                                Чтобы не было магических цифер. Работающих бухгалтерских программ полно, чтобы их победить, нужна внутренняя красота, а не внутренние костыли :) Ну и работоспособность, конечно же.
                                                                  0
                                                                  Бритва Оккама.
                                                                  Зачем вводить понятие бесконечности, если есть понятие 100 лет?
                                                                    +2
                                                                    Та же бритва: зачем вводить константу 100, если на оси времени уже присутствует удобная абстракция?..
                                                                      0
                                                                      Да можно теоретически — несложно. Однако противоречит сущности обязательства. Вещь, которую отдадут в бесконечности, черт знает что.
                                                                      На этот случай у меня вероятность погашения обязательства предусмотрена. Таким образом, вещь отдают в конкретный момент, но с некоторой долей вероятия.
                                                                        +1
                                                                        Ну вот, одна сторона уже готова признать, что абстракции протекают. А другая?
                                                                          0
                                                                          Вероятность — крайне неудобная вещь. Просто потому что правильно оценить ее довольно сложно. Вот пример: обязательство запланировано к исполнению через 10 лет. Какова вероятность того, что оно исполнится через 5 лет?

                                                                          Ответ: данных недостаточно! Нужен закон распределения вероятности. Природа обязательства может быть такова, что оно вообще не может исполниться раньше срока — тогда будет ноль. Это может быть нормальное распределение (к примеру, если обязательство исполняется по завершении последней стадии из сотни примерно одинаковых последовательных стадий) — тут нужно знать сигму. А если речь идет про Почту России — тут скорее надо смотреть экспоненциальное распределение (точнее, экспоненциальным будет «положительный» хвост распределения, другая половина устроена куда более сложно).

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

                                                                          Предлагаю достать бритву и вырезать эти вероятности. Задача прогнозирования — на порядок сложнее задачи учета.
                                                                            0
                                                                            Согласен с тем, что вероятность — вещь неудобная. Однако у меня ее применение чисто утилитарное. Тебе должны 100 руб., но отдадут с вероятностью 80 %. Показываем в отчете 80 руб. (при желании, если указать в настройках).
                                                                              0
                                                                              Скажите, а вот «чисто утилитарно» кто будет эти вероятности сочинять? :)
                                                                                0
                                                                                Регистратор — тот, кто учитывает. А какие еще имеются кандидатуры?
                                                                                Однако, не хотите — не учитывайте. Пусть в отчетах отражаются обязательства по номиналу.
                                                                                Да, и почему вы так ехидно спрашиваете? В бухгалтерии вероятности давным-давно используются, для начисления резервов. Вероятности в бухгалтерии — их не я придумал.
                                                                                  0
                                                                                  Но не на каждую же проводку…
                                                                                    0
                                                                                    Не понял, что не на каждую проводку? Вероятность используется для определения суммы резерва при любом его начислении.

                                                                                    У меня, кстати, тоже не на каждую операцию. Указать вероятность можно только для будущих операций (для прошедших или текущих она по умолчанию равняется 100%).
                                                                                0
                                                                                Именно в этом случае, имхо, лучше обойтись только двумя значениями: 0 и 100.
                                                                                Либо я полагаюсь на эти деньги (100%) и поэтому мне их нужно видеть в «доступных» на будущую дату,
                                                                                либо не полагаюсь и тогда 0%.

                                                                                Например, мне нужно совершить покупку на 90 руб., я ставлю вероятность возврата 80% и вижу в учёте, что «получу» 80 руб., ага, значит, всё путём, нужно только вещь подешевле найти. Рублей за 79 :))))
                                                                                Так не пойдёт, либо я смогу купить то, что нужно, либо не смогу.
                                                                                  0
                                                                                  Дихотомия «черное-белое» здесь не прокатит, «полагаюсь — не полагаюсь» — не разговор. А что если не уверен? Кто его знает, получишь деньги или не получишь? Поэтому оценка по вероятности (имеющая место в современном учете, что удивительно) — разумный подход.
                                                                                    0
                                                                                    А если не уверен, ставишь — 0.
                                                                                    Потому что оценить вероятностью числом от 0 до 100 не получится. 85% от 80% в плане уверенности ничем не отличается, а в учёте «лишние» 5 рублей.

                                                                                    Тут можно только качественные категории использовать. Максимум 4-5 бальную шкалу (и даже это от лукавого).

                                                                                    Вероятностный подход может сработать только на больших числах, например, для банков с заёмщиками.
                                                                                    А если у вас 10-15 контрагентов (а у физиков и того меньше), никакого вероятностного подхода быть не может, имхо.
                                                                      0
                                                                      Зачем, если можно отодвинуть обязательство на 100 лет?
                                                                      У меня был разрыв шаблона, когда я увидел дату «конца света» в SAP: 31 декабря 9999 г.
                                                                      Потом ничего, привык относиться к ней как к бесконечности :)
                                                                  0
                                                                  «Все абстракции протекают»: поставщик гарантирует некоторый уровень сервиса, вы в учётной системе фиксируете задекларированный уровень сервиса, а фактический уровень отличается… Отсюда, из протекающей абстракции и идёт беда.
                                                                  Затыкать её другой абстракцией («дата +100 лет» или «дата вечность») — не менее порочный подход.

                                                                  А, ну да: есть ещё пушистые/нечёткие множества: там сразу вводится другая абстракция, которая более устойчива к протеканию. Но и сложнее считается.
                                                                    0
                                                                    Это вот тоже выглядит как усложнение учетной работы — вместо отражения факта (по факту того как он случился!) учетчику придется регулярно (ежедневно с более-менее регулярным учетом чего-то «существенного») проверять наступление таких обязательств…
                                                                    Плюс излишнее шаманство с «добавить вещь-отнять вещь», или «вероятность наступления» в операциях, осуществляемых в уже работающих «традиционных учетных» продуктах одним кликом…
                                                                    Вроде бы Вы (КМК, как человек «уставший» от излишней «накрученности учетов»...) стремитесь упростить и понятия и операции, но почему-то это все равно вытекает в усложнение и условности…
                                                                      0
                                                                      Это вот тоже выглядит как усложнение учетной работы.

                                                                      Не согласен. Никакого усложнения в данном случае нет, хотя упрощения тоже. Регистрировать погашения обязательства в бухгалтерии или проверять в экаунтологии, в чем разница? К тому же можно регистрировать обязательства со сроком погашения в 100 лет, как предлагалось выше, тогда методика приблизится к обычной бухгалтерской.

                                                                      Плюс излишнее шаманство с «добавить вещь-отнять вещь»

                                                                      Будет и у меня одним кликом, дайте время. Только на основе не «спецбухгалтерских», а универсальных опций по работе с учетными базами данных.

                                                                      или «вероятность наступления» в операциях, осуществляемых в уже работающих «традиционных учетных» продуктах одним кликом…

                                                                      Неужели начисление бухгалтерского резерва проще указания на вероятность в моей программе??? Вероятность можно и не отражать, в конце концов.

                                                                      Вроде бы Вы (КМК, как человек «уставший» от излишней «накрученности учетов»...) стремитесь упростить и понятия и операции, но почему-то это все равно вытекает в усложнение и условности…

                                                                      Мой метод более естественный, чем бухгалтерский: во всяком случае, условностей в нем на порядок меньше. Что касается сложности… да, программа сложна. Сложна, как сама жизнь. Программа всего лишь имитирует то, что можно произвести с вещами в реальной жизни.
                                                                        0
                                                                        Программа всего лишь имитирует то, что можно произвести с вещами в реальной жизни.
                                                                        Ну так механизм учёта не должен имитировать реальную жизнь, он должен являться моделью. При этом, наоборот, чем проще модель — тем лучше.
                                                                          0
                                                                          Модель — это и есть некоторым образом имитация, по-моему. А бухгалтерский учет настолько отдалился от реальной жизни, что давно уже существует по принципу: Если я не похож на реальную жизнь, тем хуже для нее.

                                                                          чем проще модель — тем лучше.

                                                                          Согласен. Только простота не должна мешать исполнению функций. Если реальность, которую необходимо отобразить, сложна, тогда модели — хочешь не хочешь — тоже приходится быть сложной.
                                                              +1
                                                              Про Василия дело не в ПО, а в том, что в отчетную дату у него Х вещей на полке, он им рад, он их чувствует и пыль стирает. А завтра вы ему измените сегодня, изменив остаток объема обязательств. Василий лицо материально-ответственное и ему не понравится отвечать за сохранность того, чего он в глаза не видел.
                                                              если у меня регистрируется вещь, она обязательно случится
                                                              это платоновщина, в хорошем смысле. Объем и сроки исполнения обязательств подконтрольны только субъектам управления (поставщикам), кем вы в момент регистрации не являетесь. Поэтому просто плодится энтропия. Нет практического смысла, зарегистрируете вы 1 или 10 яблок, их в дату поставки может быть и 50.
                                                                0
                                                                Будущее всегда предположительно, поэтому регистрация любого обязательства — в некотором роде сказки про белого бычка.
                                                                На самом деле все равно:
                                                                зарегистрировать погашение обязательства и не регистрировать отсутствие погашения, как в бухгалтерии,
                                                                или не регистрировать погашение обязательства и регистрировать отсутствие погашения, как у меня.

                                                                Поставщикам сроки исполнения обязательств тоже неподконтрольны, всегда может образоваться форс-мажор. Это одному Богу подконтрольно.
                                                                +1
                                                                Грубо говоря, если природа зарегистрировала, что через неделю метеорит упадет кому-то на башку, то метеорит обязательно упадет, будьте уверены

                                                                Знаете, это очень спорная аналогия и вы становитесь на весьма скользкий путь, используя её. «Природа зарегистрировала, что через неделю...»

                                                                Кроме того, очень спорны некоторые моменты. Вот вы говорите: «как зарегистрировал — так и случится», «природа учитывает вещи, а не абстракции». Понимаете, ваша [учётная] система — это тоже один из способов описания реальности.

                                                                Более того — из того, что вы описываете вещи, а не некоторые абстракции (вы полагаете, что «дебет» и «кредит» — некие абстракции, верно полагаете), ваша система по-прежнему остаётся такой же абстрактной методологией, как и другая методология, которая оперирует абстракциями типа «кредит» и «дебет».

                                                                Вы говорите «я учитываю вещь» (как сама природа), а на самом деле учитываете «абстракция называемая 'вещь'».
                                                                Любая модель — получается отсекновением, упрощением оригинала. Вот и ваша… Вы же говорили в примере про светофор, который меняет цвет с красного на жёлтый — что его можно по-разному моделировать и описали «а в моей модели принят следующий принцип». Ну хорошо, принят.

                                                                А кроме того, я бы не рекомендовал апеллировать к фразе «как написано в модели — так и станет в реальности» (как зарегистрировал — так и случится), это чистейший воды пример магического мышления, когда думают, что совершая некие ритуальные действия можно повлиять на материальный мир. Разницы между шаманом Ктулху и финансовым шарлатаном из Enron в этом мало: реальность имеет свойство глубоко наплевательски относиться к происходящему в виртуальности.

                                                                В общем я о чём? Ваша модель в чём-то любопытна, явно неординарна — но попробуйте как-то несколько по-иному подбирать аргументацию, возможно тогда ваши идеи будут приниматься с меньшим скепсисом.
                                                                  0
                                                                  В целом согласен.

                                                                  Про шамана Ктулху и финансового шарлатана из Enron — на 100 % согласен. Это вы хорошо сказанули.

                                                                  По поводу скепсиса: я из своих критиков самый большой скептик. Как там у классика,
                                                                  «Уж не жду от жизни ничего я
                                                                  И не жаль мне прошлого ничуть...»
                                                                    0
                                                                    Тогда оттачивайте свою систему, оттачивайте и навыки аргументирования, почему ваша система — достнойная альтернатива существующими. Выше верно восхищались вашему упорству в достижении цели, тоже отметился.
                                                                    Но этого мало, чтобы из изящной игрушки для ума сделать практически годную вещь. Удачи.
                                                              +1
                                                              Вот здорово! Бухгалтерский учёт без придурей. Ну и изучение ЯП до такого достойного уровня вызывает глубокое уважение!

                                                              Я для себя упрощал БУ так:
                                                              1. С помощью отрицательных чисел: у меня -2 яблока = я должен 2 яблока
                                                              Сумма каждой проводки аксиоматически принимается равной нулю, так что sum(Credit) = sum(Debit)
                                                              sum(Credit) — sum(Debit) = 0.
                                                              Какие-то счета удобнее вести, помножив всё уравнение на -1, но это нужно лишь для преставления пользователю.

                                                              А вы учитываете отрицательные значения?

                                                              2. Применения единиц измерения в расширенном физическом смысле.

                                                              Цена это коэффициент преобразования одной величины в другую.
                                                              2 яблока — 1 груша = 0 рублей (баланс операции обмена)
                                                              это можно решить, например, если ввести коэффициенты преобразования яблок и груш в рубли — их цены.

                                                              Таким образом, денежное представление баланса является лишь одним из возможных. Для управленческого учёта можно представлять базу сразу в натуральных единицах. Это как выбор единиц измерения для графиков — кг или граммы. Меняются коэффициенты и числа, но «суть» остаётся той же.
                                                                0
                                                                Цена это коэффициент преобразования одной величины в другую
                                                                Смешно. Начнем с того, что цена бывает покупки и продажи — и они не совпадают, даже если обе имеют смысл. Продолжим тем, что может быть еще и несколько разных валют. И закончим осознанием того факта, что все эти «коэффициенты преобразования» изменяются с течением времени.

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

                                                                  Этот весьма философский пункт я включил именно, чтобы избежать приведения всего «к общему знаменателю» денег в самой БД.

                                                                  Так что ответы на ваш вопрос в такой системе полностью возможны. Решение о группировке и пересчёте принимается в момент составления отчёта, а не записи в БД. Просто бухгалтер не должен просить систему приводить всё к рублям, а оставить «как есть».

                                                                  Более того, валюта в разной форме / счетах — это разные вещи. 100 руб в Сбербанке и 100 руб в ПСБ это разные вещи. Особенно они разные при обвале банка. Транзакция про будущую страховую выплату:

                                                                  — 1 млн 200 тыс единиц «Рубль в банке Рога и Копыта» (произошло вчера)
                                                                  + 700 тыс единиц «Рубль в Сберьбанке» (произойдёт через 3 месяца)

                                                                  Извините, если спутано объясняю, но в своей «методологии» я хотел избежать лишнего приведения всего в деньгам, а по-максимуму сохранять натуральные единицы.
                                                                    0
                                                                    А, в таком случае все правильно. К деньгам все приводить можно лишь в красивых отчетах )
                                                                      0
                                                                      Все правильно. У меня именно так реализовано, по крайней мере в смысле валют.
                                                                      100 руб в Сбербанке и 100 руб в ПСБ это разные вещи.

                                                                      Один в один.
                                                                        0
                                                                        Чесслово, это скорее недостаток. Деньги были придуманы как некая универсальная вещь в обмене. «Доллар он и в Африке доллар».
                                                                        Экономическая теория знает многие недостатки золота, доллара и т.п. — но лучше пока вряд ли что-то придумали.

                                                                        А вы так это отметаете сходу. Что предложите взамен?
                                                                          0
                                                                          Это называется «текущая абстракция» (она же «протекающая» или «дырявая»). Для директора 100 рублей в любом из банков — почти то же самое, что и 100 рублей в сейфе. Но бухгалтеру нужно как минимум знать, какой из банк-клиентов запускать. А еще у денег есть такая вещь, как ликвидность.
                                                                            0
                                                                            Я знаю, что такое протекающая абстракция, но тут речь не о том, что абстракция протекает — а о том, что была удобная абстракция, очень удобная. А вы её прямо под нож искоренили. Ну протекала в некоторых случаях, бывает со всеми.
                                                                            Но это была очень, очень удобная абстракция. А вот так вместе с водой и ребёночка… Есть что предложить взамен?
                                                                            Я же не против, что в каких-то случаях абстракция протекала — но что ваша предлагает взамен? Есть понимание? Можете объяснить?
                                                                              0
                                                                              Предлагаю переменный уровень абстракции. Директор видит суммарные отчеты, бухгалтер — отдельные счета. Ничего нового, именно так и устроены все современные бухгалтерские системы.
                                                                            0
                                                                            Давно известно, что. Труд, без которого не вынешь рыбку из пруда. Теория трудовой стоимости, есть такая. С моей вариацией данной теории можно ознакомиться у меня на экаунтологическом сайте (см. профиль — на сайте колонка справа, называется «Экономические законы природы»).
                                                                              0
                                                                              «Доллар и в Африке доллар», только если мы говорим о физической бумажке.
                                                                              А с того момента, когда вы этот доллар отдали в кассу банка, вы взамен получили обязательство банка по выдаче вам долларовой бумажки (например называется договор банковского вклада — ДБВ).
                                                                              И вот обязательство одного банка, совсем не равно обязательству другого банка. Думаю понятно.

                                                                              Можно на это смотреть как на две валюты: ДБВ_СБЕР и ДБВ_ПСБ.
                                                                          –1
                                                                          Список учётных единиц:
                                                                          доллары, рубли, цена_покупки_руб, цена_продажи_руб,

                                                                          Для представления в разных учётных единицах есть свои коэффициенты.
                                                                          Для наличных денег коэффициент будет 1.
                                                                          В каких хотите единицах, в таких и стройте отчёт.
                                                                          –1
                                                                          С помощью отрицательных чисел
                                                                          Минус 2 яблока -это ноль яблок. Сами потом грузите минус сто ящиков со склада
                                                                            0
                                                                            Зря вы про ноль яблок. Минус два яблока остаются минус двумя яблоками — отрицательные числа человечество не просто так придумало.

                                                                            А вот про склад замечание — очень правильное. Если у меня есть 3т яблок, и одну тонну яблок я должен — то сумма в две тонны красиво выглядит лишь в итоговом отчете, а на складе продолжают лежать три.
                                                                              0
                                                                              Ну да, в итоговом отчёте на конец месяца нужны именно две тонны.
                                                                              А в операционном отчёте на любую конкретную дату, в т.ч. «на сегодня» — отдельно плюс и минус.

                                                                              Разве не так?

                                                                              Причём, большинство вещей может иметь (для транзакционной целостности) лишь положительный баланс. Какие-то (вроде выданных кредитов) — только отрицательный баланс.
                                                                            0
                                                                            1. Отрицательные величины не могут регистрироваться в качестве свойств объекта, но могут в частных случаях присутствовать в отчетах (один из таких случаев рассмотрен в посте).
                                                                            2. Про преобразование не очень понял. А что баланс можно составлять в натуральном выражении — это верно.
                                                                            +1
                                                                            Прочитал, хорошо, но есть момент, по которому всё это ляжет в ящик стола на ближайшие лет сто, в лучшем случае.
                                                                            А всё потому, что чиновникам нужна работа. Если чиновники не будут сочинять кучу постоянно меняющихся бумажек — их уволят. Чиновники этого не хотят, поэтому они будут делать всё, чтобы не уволили их. Соответственно, пока чиновники являются столпом этой системы и пока они диктуют свои правила, программисты (1Сники, признавайтесь) получают огромные выплаты из-за того, что каждый раз приходится обновлять базы и формы большому количеству предприятий. В следствии программистам тоже выгодно, что чиновники занимают свои места.
                                                                            Если руководство страны примет решение заморозить хотя бы на 5 лет формы отчётности — часть компаний разорится, отсюда государство получит меньше налогов и поимеет проблем в виде необходимости в сокращении штата чиновников (ух, как чиновники не любят расставаться со своими креслами), ну и соответственно, наметится некоторая безработица у 1Сников, которым придётся переучиваться на что-нибудь другое, либо соглашаться на более низкую зарплату.

                                                                            Соответственно, пока государство не перестроит подход по управлению собой (не думаю, что такое возможно), все подобные работы будут ложиться в пыльный ящик стола.
                                                                            P.S> извиняюсь за оффтопик, политику и прочее. Накипело.
                                                                              0
                                                                              Причем тут чиновники? Нормальная бухгалтерская программа должна уметь выдавать на выходе отчеты по любым формам, независимо от того, что у нее внутри.
                                                                                +1
                                                                                А кто занимается изменениями форм, введением новых форм и отчётов? Программа, конечно, может и уметь, но про новые формы просто не знать, так как её не обновили.
                                                                                  0
                                                                                  Именно. Поэтому на рынке выживает та программа, которую обновлять проще. И если какая-то желтая программа никак не умрет — это из-за ее гибкости, а не из-за заговора 1C-ников.

                                                                                  Если вдруг сделать программу, которая окажется на порядок лучше 1С — она взлетит, и никакие чиновники ей не помешают. Напротив, они и дадут стимул к сокращению расходов на обновление программы. Ну а 1С-ники переучатся.

                                                                                  Почему же такого до сих пор не случилось? Наверное, потому что нельзя так просто взять и сделать программу, которая была бы лучше 1С. И программа автора не взлетит именно по этой причине, а не из-за чиновников, жадных до работы.
                                                                                0
                                                                                Абсолютно согласен!
                                                                                Выход из этого замкнутого круга только один — сделать такой софт, который начался бы с индивидуального распространения, а потом уничтожил бы саму порочную систему. Ну, как Интернет: его совсем для других нужд изобретали, насколько мне известно, никто такого эффекта не ожидал. Если бы ожидали, прикрыли в зародыше.
                                                                                0
                                                                                Труд и подвижничество, безусловно, заслуживают уважения.

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

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

                                                                                Ну а глобализация этих моделей и построение мегамодели? Типа БухEverNote. Еще более сомнительно. Модель — основа управления. Если субъекты разные, то и модель у каждого своя. У каждого свои цели и свои критерии существенности. Зачем соединять учетные системы? Как тогда от жены прятать заначку? Учетный коммунизм? — Чур меня, проходили уже.

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

                                                                                Ну и нужно попытаться на базе этого подхода сначала домашнюю бухгалтерию сделать. Если получится — можно будет двигаться дальше.
                                                                                  0
                                                                                  Видите ли, я не пытаюсь распространить свои идеи на крупные предприятия и вообще на предприятия. С моей точки зрения, юридические лица — это абсурд, поскольку в реальной экономике существуют лишь люди. Предприятия — это у них в головах, людям в мозги намертво вкомпостировали, чтобы не брыкались при распределении ресурсов по понятиям, а не по труду. Будем считать, что меня интересует исключительно теория. Да и версия 1.0 предназначена, собственно, для использования в качестве учебного пособия по экаунтологии.
                                                                                    0
                                                                                    Тогда непонятно, при чем тут вообще бухгалтерский учет. Индивидууму бухгалтерский учет не нужен в большинстве случаев. Он прекрасно обходится без него. Более простыми экономическими моделями. Рассуждать иначе — профессиональный эгоизм.
                                                                                    Например, одно из требований бухучета — непрерывность. А зачем она всем?

                                                                                    Подумал тут еще о том, зачем в вашей модели знак сальдо заменен понятиями прошлое — будущее. Это излишнее усложнение. В плоскую модель — остатки, спроецированные на настоящее, добавляется время. Ладно бы для прошлого. Для будущего — это чаще всего неразрешимая неопределенность. А платежи с оговоренными графиками оплаты: в два, три приема, регулярные платежи?
                                                                                      0
                                                                                      Бухгалтерский учет тут не при чем. А вот учет очень даже при чем: программа учетная…

                                                                                      Индивидууму бухгалтерский учет не нужен в большинстве случаев. Он прекрасно обходится без него.

                                                                                      Согласен. Попытки внедрить домашнюю бухгалтерию, еще в позапрошлом веке, окончились ничем. Поэтому вести ее намеренно не будут. А если данные начнут поступать в домашние базы, непосредственно из магазинов, почему бы и нет? Применительно ко мне самому: хочу я вести домашний учет личного имущества? Нет, мне в лом. А не против того, чтобы у меня под рукой был список моего личного имущества? Нет, совершенно не против. Полагаю, у других так же.

                                                                                      Например, одно из требований бухучета — непрерывность. А зачем она всем?

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

                                                                                      Подумал тут еще о том, зачем в вашей модели знак сальдо заменен понятиями прошлое — будущее.

                                                                                      Не понимаю вас. Или вы меня не поняли.

                                                                                      А платежи с оговоренными графиками оплаты: в два, три приема, регулярные платежи?

                                                                                      Такая проблема действительно есть. В первой версии придется каждый платеж набивать отдельно. Если дойдет до второй версии, сделаю автоматическую операцию, концепции это не противоречит.
                                                                                        0
                                                                                        Я понял так: Вы храните только положительные — дебетовые сальдо, соответствующие вещам — активам. А если сальдо кредитовое — вместо того, чтобы просто обозначить пассив отрицательным сальдо на этом счете — вы учитываете пассивы — обязательства событиями в будущем — со временем и вероятностью. То есть вместо знака сальдо — время события. Это более сложная и не симметричная модель. Все равно вам потребуется хранить признак «будущее» или «прошлое» у остатка. Чтобы, например, просуммировать только обязательства. Ну и оставьте кредитовые счета, двойную запись, а время учитывайте факультативно.
                                                                                        Вероятность вообще не из той оперы понятие. Чтобы назвать что-то вероятностью, нужно обеспечить повторяемость оцениваемого явления. Вряд ли кто-либо сможет увидеть все варианты возможного будущего, чтобы посчитать долю «благоприятных» событий. Поэтому то, что вы назвали вероятностью — это что-то типа меры уверенности в выполнении обязательства. Эта величина вообще трудно измеримая. Зачем включать ее в модель, оперирующую стоимостью, измеряемую (чаще всего) с двумя знаками после запятой? То есть совсем другим порядком точности.
                                                                                          0
                                                                                          Увы, про сальдо вы не так поняли — видимо, бухгалтерский шаблон сработал. У меня нет счетов в принципе, у меня отдельные объекты. У каждого объекта приход и расход по времени. Если расход не пустой, объект выбыл. Но выбыть объект может будущей датой, к примеру: поступил 1 декабря, выбыл 10 декабря. Если сегодня 2 декабря, то выбытие данного объекта — обязательство. С бухгалтерией ничего общего.

                                                                                          С определением вероятности согласен. Мне она понадобилась для одного: чтобы в отчетах показывать обязательства по уменьшенной стоимости.
                                                                                  0
                                                                                  Как по мне — вы переизобрели MRP.
                                                                                    0
                                                                                    Я с этой концепцией даже не знаком. Вряд ли…
                                                                                      0
                                                                                      Знакомьтесь и удивляйтесь :)
                                                                                      ru.wikipedia.org/wiki/MRP_II
                                                                                        0
                                                                                        Да я уже посмотрел, спасибо. Ничего общего.
                                                                                          0
                                                                                          А я вот наоборот. Много общего увидел.
                                                                                          Вы просто отошли от бухгалтерии в сторону логистики (изобрели свои термины и правила).

                                                                                          Делаем следующие замены:
                                                                                          Вещь -> Материал
                                                                                          Действие -> Движение материала
                                                                                          Обязательство -> Планирование поставок (и платежей в MRP II)
                                                                                          Вероятности -> Оценка рисков (только не пальцем в небо, а с помощью методик)
                                                                                          Генерация отчетов — тут даже переименовывать ничего не надо, оно и так все есть

                                                                                          И получается, что ЭкаунтоЛогика -> Учет и планирование в логистике.
                                                                                            0
                                                                                            Все учетные программы занимаются одним и тем же, только по-разному. Вы сравнили термины, но ни словом не обмолвились о методе. Дело-то именно в методике учета (в том, каким способом осуществляется учет и планирование — в логистике или где угодно)… А то ведь можно подумать, что ваша MRP именно тем и хороша, что вещи называет материалами, операции — движениями, и т.д.
                                                                                            К слову:
                                                                                            • обязательство у меня — не вполне планирование поставок (обязательство как будущий объект может вообще не иметь отношения к поставкам),
                                                                                            • никакие методики оценки вероятности не обеспечат стопроцентного угадывания. К тому же ничто не мешает пользователю моей программы оценить вероятность по известной ему методике, хотя бы по вашей. У меня программа для учета, а не для бизнес-аналитики,
                                                                                            • генерация отчетов — общеупотребительный термин, по-моему.
                                                                                              0
                                                                                              Я бы не хотел сравнивать. Сравнил не просто термины, а термины, применимые в конкретном программном обеспечении, которое реализует вами описанный функционал (причем годов эдак с 70-x). Вы почти в каждом комментарии пишете об особом методе. В чем же заключается ваш метод (достаточно ссылки на публикацию, я сам постараюсь разобраться), и что в нем особого (нового)?

                                                                                              Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке). Обещание жениться к методологии движения материала не применимо :)

                                                                                              По поводу (У меня программа для учета, а не для бизнес-аналитики) вы сами себя загоняете в угол. Любая программа учета — это аналитика. Они собственно для аналитики и создаются. Посмотреть наличие товара на складе на дату, посмотреть движение материалов за интервал времени, посмотреть объемы поставок по контрагентам — все это аналитика. Без этого функционала — ваша программа не будет отличаться от ведения приход/расход кладовщиком в тетрадке, соответственно будет не нужна.

                                                                                              Про генерацию отчетов неправильно изъяснился. Имел ввиду, что все эти отчеты в методологии MRP давно известны (см. предыдущий абзац).
                                                                                                0
                                                                                                В чем же заключается ваш метод (достаточно ссылки на публикацию, я сам постараюсь разобраться), и что в нем особого (нового)?

                                                                                                Дать ссылку на текущий пост? :)
                                                                                                Можете зайти в мой профиль, там указание на целый сайт, посвященный экаунтологии.
                                                                                                Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке).

                                                                                                Насчет живое-неживое спорить не буду, тем более что с MRP не знаком. Возможно, там оно и живое… Что касается дальнейших ваших слов, они свидетельствуют о том, что вы моей методой не владеете. «Либо поставка, либо выполнение работ, либо финансовое»? А вот и нет. У меня обязательство — понятие более широкое, чем юридическое определение: это любой будущий объект (любое событие, которое произойдет в будущем). К примеру, ожидается, что через месяц вещь будет выкинута на свалку. Данное предположение, если его зарегистрировать, тоже обязательство (как это трактуется в юриспруденции, мне известно, можете не объяснять), при этом абсолютно формализованное.

                                                                                                С вашей трактовкой аналитики согласен.

                                                                                                все эти отчеты в методологии MRP давно известны

                                                                                                Оборотно-сальдовые ведомости и в бухгалтерии давно известны, они никак не новации MRP.
                                                                                                О том, что я какие-то новые формы отчетности придумал, ни словом не обмолвился. Нет такого: одно старье.

                                                                                                  0
                                                                                                  Дать ссылку на текущий пост? :)

                                                                                                  Зря вы так… Посмотрите сколько к вам вопросов в комментариях. В данном посте вам не очень удалось описать методологию.
                                                                                                  Прочитал описание вот тут: accountology.ucoz.ru/faq/1-1#1, как по мне — так это больше философские размышления о видении правильного учета, описанные художественным языком. Никакого формализма, никаких правил, приемов и способов… Методологии, практической методологии, как таковой, так и не смог увидеть/понять. Хотя, причина этого может быть в математическом складе ума и попытках структурировать и систематизировать знания.

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

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

                                                                                                    В данном посте вам не очень удалось описать методологию.

                                                                                                    Возможно, не мне судить. Я назвал два главных отличия: учет обязательств в качестве будущих объектов и формализацию доходов-расходов.
                                                                                                    Про доходы-расходы слишком долго, но вот про обязательства. Зарегистрирована вещь с датой прихода 10 апреля. Это обязательство или не обязательство? В зависимости от того, какое сегодня число: если 1 апреля, то обязательство, а если 15 апреля, то нет (тогда данная вещь — прошлая). Никаких других различий в регистрации нет, все зависит от текущей даты.

                                                                                                    И выбытие, списание, делается все тем же видом движения материала (действием по вашей терминологии).

                                                                                                    Ну, значит, здесь наблюдается некоторое пересечение. Но вы поймите, различия нужно искать не в поставленных задачах, которые по определению одинаковы, а в способах решения — методике! Мне все кажется: вы путаете задачи и методы. Вообще, наш разговор напоминает общение глухонемых: вы владеете MRP, но не владеете экаунтологией, я наоборот.

                                                                                                    Никакого формализма, никаких правил, приемов и способов…

                                                                                                    А вы хотите во вводной статье сразу и приемы, и правила, и способы?.. А дальше лениво почитать? Да, по причине экономического образования изложение у меня не математическое. Однако не думаю, что обилие формул сразу приводит к истине, нередко и отдаляет от нее.
                                                                                                      0
                                                                                                      вы владеете MRP, но не владеете экаунтологией, я наоборот.

                                                                                                      Я назвал два главных отличия: учет обязательств в качестве будущих объектов и формализацию доходов-расходов.


                                                                                                      Это отличие от бухгалтерии или от MRP? Я же писал в самом начале

                                                                                                      вы переизобрели MRP


                                                                                                      в том, что касается методологии, а не философском видении.

                                                                                                      А дальше лениво почитать?


                                                                                                      С удовольствием, но не нашел. Киньте, пожалуйста, ссылку на практическую методологию.
                                                                                                        0
                                                                                                        Это отличие от бухгалтерии. Как организован учет в MRP, мне неизвестно.

                                                                                                        С удовольствием, но не нашел.

                                                                                                        Вы прочитали первую вводную статью в разделе «Экаунтология». Вслед за ней идет еще много-много других статей. Либо по ссылкам на правой панели скачайте файлы «Принципиальная схема Мироздания» и «Экономические законы природы». Хотя там, с вашей точки зрения, будет одна вода и никакой практики. Еще могу порекомендовать эту книгу: «Экаунтология: компьютерный учет вместо бухгалтерского». М., 2012. В ней система рассмотрена в подробностях применительно к компьютерным базам данных (хотя, предупрежу сразу, крайне неудачно: программисты сильно возмущаются, когда читают). А вообще, практическая методология реализована в программе, тестируйте ее. Программа для того и написана. Ну в самом-то деле…

                                                                                                          0
                                                                                                          Все понятно, спасибо.
                                                                                                            0
                                                                                                            Да пожалуйста.
                                                                                    0
                                                                                    Тут выше эпичный тред с lair. Не ввязываясь в ценность научной составляющей я присоединюсь к вопросу: в чем ценность этого подхода учета?
                                                                                    Пока сама система похожа на обычный складской учет с функцией «объединения дублей». Или, обычный забалансовый учет. Но, возможно, в концепции есть идея, которая должна получить развитие. Или есть важные отличия, на которые нужно обратить внимание?

                                                                                      0
                                                                                      Мне казалось, я раз десять ответил: и в посте, и в комментариях. Как отнестись к моим ответам, личное дело каждого, но не заметить их — признак слепоты.

                                                                                      Система похожа на складской учет, да. Поскольку решает одни и те же задачи — учет вещей.
                                                                                      0
                                                                                      Никак не уловлю отличий от БУ(

                                                                                      Можете пояснить?

                                                                                      Скажем напишу я сейчас софтинку, которая позволит забивать документы прихода и расхода.
                                                                                      Что именно пришло или ушло выбираю из справочника при заведении(существующее или добавляю новую запись).
                                                                                      Если поставлю дату документа прошлым числом — действие совершенное, будущим — обязательство.
                                                                                      Вот вам упрощенный донельзя БУ(тетрадка кладовщика только с возможностью построения отчетов).
                                                                                        0
                                                                                        Мне казалось, я многократно объяснил. Если не поняли, значит я плохо объясняю. Как умею, лучше вряд ли смогу…

                                                                                        Система, которую вы описали, — это моя система (в чрезвычайно упрощенном представлении, конечно). В бухгалтерии не так: бухгалтер регистрирует обязательство сегодняшним числом, а не будущим: ему совершенно до лампочки, когда предполагается погашение обязательства (разве только для классификации обязательств на кратко- и долгосрочные). Также до лампочки, будет обязательство погашено или нет (если только в целях его списания за баланс в некоторых ситуациях, ну или для поступления денег на счета). А у меня обязательства придется отслеживать, как в жизни: не дай Бог проворонить дату погашения, придут кредиторы и начнут права качать (применительно к моей учетной системе — обязательство превратится в свершившийся факт).
                                                                                          0
                                                                                          Значит у меня в компании используется ваш учет :)
                                                                                          У нас в порядке вещей регистрировать приход будущим числом, а по факту приемки товара уже корректировать его…
                                                                                            0
                                                                                            Если вы не придумываете, это очень круто. Настолько, что с трудом верится…
                                                                                            Хотя учет обязательств — один из аспектов моей системы, существуют другие важные нюансы.

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

                                                                                              Проанализировал нашу систему учета и пришел к выводу что не совсем корректно описал процесс.

                                                                                              Учет у нас существует в двух уровнях:
                                                                                              1. Реальная учетная система(самописная, от собственного департамента разработки), распределенная БД, основные узлы в головной компании и складах, которые позиционируются как собственные поставщики. Вторичные узлы на объектах обслуживания(собственно в магазинах). Именно здесь все происходит естественным образом — автозаказ генерирует документ заказа товара, из него генерируется ожидаемый приход. По факту прихода происходит приемка товара и, в случае расхождения плана и факта, генерируются документы на недовоз\перевоз разницы.

                                                                                              2. Бухгалтерия. Вещь в себе. Поднята на доработанной 1С, через веб-сервис обменивается с основным узлом основной БД. Армия бухгалтеров подгоняет план под факт для отчетности. Генерирует кучи проводок, работают с реальными и синтетическими счетами.
                                                                                                0
                                                                                                Я так и думал, что мы говорим о разных вещах.

                                                                                      Only users with full accounts can post comments. Log in, please.