Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 170
Какую задачу решает ваша программа?
Обычную учетную. Только не по бухгалтерским правилам, а по естественным — природным.
Я не знаю, что такое «обычная учетная», учет — дело очень многоликое. У нас вот тут тоже «обычная учетная задача» на несколько лет разработки и поддержки.
Чем ваш подход лучше существующих?
Чем ваш подход лучше существующих?
Вот, чуть ниже, другому пользователю ответил:
habrahabr.ru/post/244465/#comment_8156115
Могу добавить: мой подход базируется на научной разработке — изобретенной мной экаунтологии (ну, можно отрицать ее научное значение, но факт остается фактом: только после того, как я привел мысли в порядок, удалось сделать что-то формально работающее). Теперь немного хронологии: чтобы по минимуму освоить C# и накатать на нем 30 тыс. строк (пусть непрофессиональных, а какая разница?), мне понадобилось полгода. А чтобы создать более-менее связную теорию учета, потребовалось около 7 лет непосредственного создания плюс лет 10-15, что называется, подступов к теме. При том что у меня высшее бухгалтерское образование, на сегодня я автор десятков учебников и учебных пособий по бухгалтерскому учету и т.п. Чувствуете разницу в сложности задач? Поэтому то, что вы с налету не поняли новизну моего подхода, не удивительно. Мало кто понимает.
Лучше других мой подход тем, что заимствует методы учета у природы, а не пытается обслуживать безумие, ошибочно именуемое бухгалтерским и налоговым законодательством.
А учет — дело многоликое, да. Хотя учитываются, как правило, вещи (хотя бы потому, что наша Вселенная состоит именно из вещей, а остальное, в частности абстракции, являются отношениями между этими вещами). Таким образом, должны существовать общие правила учета вещей — истинная (не бухгалтерская) теория учета.
habrahabr.ru/post/244465/#comment_8156115
Могу добавить: мой подход базируется на научной разработке — изобретенной мной экаунтологии (ну, можно отрицать ее научное значение, но факт остается фактом: только после того, как я привел мысли в порядок, удалось сделать что-то формально работающее). Теперь немного хронологии: чтобы по минимуму освоить C# и накатать на нем 30 тыс. строк (пусть непрофессиональных, а какая разница?), мне понадобилось полгода. А чтобы создать более-менее связную теорию учета, потребовалось около 7 лет непосредственного создания плюс лет 10-15, что называется, подступов к теме. При том что у меня высшее бухгалтерское образование, на сегодня я автор десятков учебников и учебных пособий по бухгалтерскому учету и т.п. Чувствуете разницу в сложности задач? Поэтому то, что вы с налету не поняли новизну моего подхода, не удивительно. Мало кто понимает.
Лучше других мой подход тем, что заимствует методы учета у природы, а не пытается обслуживать безумие, ошибочно именуемое бухгалтерским и налоговым законодательством.
А учет — дело многоликое, да. Хотя учитываются, как правило, вещи (хотя бы потому, что наша Вселенная состоит именно из вещей, а остальное, в частности абстракции, являются отношениями между этими вещами). Таким образом, должны существовать общие правила учета вещей — истинная (не бухгалтерская) теория учета.
А можно ссылки на ваши публикации в рецензируемых научных журналах?
В рецензируемых? Я ж не физик, чтобы в рецензируемых печататься. Вообще, я печатался в бухгалтерских журналах, и достаточно широко (около сотни статей опубликовал, наверное), это было в начале нулевых. Потом перешел на книги, сейчас чаще публикуюсь в Сети.
С моей библиографией можно ознакомиться здесь.
С моей библиографией можно ознакомиться здесь.
А тогда о какой научности можно говорить? Собственные книги — это совсем не то же самое, выпустить книгу может любой, у кого есть какое-то количество денег.
И нет, «я потратил семь лет» — это вообще не аргумент, особенно в части сложности задач. Есть учетные системы, которые будут постарше вашей теории учета (и это только в астрономическом времени, в трудозатратах разница будет уже как бы не на порядки).
И нет, «я потратил семь лет» — это вообще не аргумент, особенно в части сложности задач. Есть учетные системы, которые будут постарше вашей теории учета (и это только в астрономическом времени, в трудозатратах разница будет уже как бы не на порядки).
В таком случае трудозатраты — тоже не аргумент…
Пардон, но я книги не на собственные деньги выпускал (хотя пару раз согрешил, признаюсь)! Книги у меня покупали (а иногда и заказывали) профессиональные издательства. Покупатели, а потом не единожды переиздавали (пара лучших дошла до 10-го издания).
Разумеется, это не критерий научности (популярная бухгалтерская мура вообще антинаучна), однако и публикация в рецензируемых журналах — не меньшая мура, насколько мне известно. То есть опубликовался в рецензируемом журнале — и ученый? Вы серьезно?
выпустить книгу может любой, у кого есть какое-то количество денег
Пардон, но я книги не на собственные деньги выпускал (хотя пару раз согрешил, признаюсь)! Книги у меня покупали (а иногда и заказывали) профессиональные издательства. Покупатели, а потом не единожды переиздавали (пара лучших дошла до 10-го издания).
Разумеется, это не критерий научности (популярная бухгалтерская мура вообще антинаучна), однако и публикация в рецензируемых журналах — не меньшая мура, насколько мне известно. То есть опубликовался в рецензируемом журнале — и ученый? Вы серьезно?
Так и я говорю — трудозатраты не аргумент. И отсылка к научности — не аргумент (потому что не выдерживает критики). Так что в итоге мы возвращаемся к началу: к объяснению на простых и понятных аргументах, чем предлагаемая вами методика учета лучше существующих.
Только пожалуйста, обратите внимание, что я говорю не о бухгалтерском учете, а о, как вы выражаетесь, «обычном учете».
Только пожалуйста, обратите внимание, что я говорю не о бухгалтерском учете, а о, как вы выражаетесь, «обычном учете».
Перечисляю:
1. Учет обязательств в качестве будущих объектов.
2. Отсутствие понятия «закрытие периода».
3. Сведение дебета и кредита к приходу и расходу (в некоторых небухгалтерских учетных программах имеется, да).
4. Формализация понятий «доходы-расходы».
5. Отказ от учета бухгалтерских абстракций (при том, что в большинстве своем они могут быть получены).
6. Автоматическое согласование разных баз данных при передаче объектов.
Возможно, что-то упустил.
1. Учет обязательств в качестве будущих объектов.
2. Отсутствие понятия «закрытие периода».
3. Сведение дебета и кредита к приходу и расходу (в некоторых небухгалтерских учетных программах имеется, да).
4. Формализация понятий «доходы-расходы».
5. Отказ от учета бухгалтерских абстракций (при том, что в большинстве своем они могут быть получены).
6. Автоматическое согласование разных баз данных при передаче объектов.
Возможно, что-то упустил.
Ну вот я смотрю на учетную систему, в которой:
1. Обязательств нет вообще
2. Нет закрытия периода
3. Нет дебета и кредита
4. Нет доходов и расходов
5. Нет бухгалтерских абстракций
6. Автоматическое согласование данных с интегрируемыми системами.
Что я делаю не так?
1. Обязательств нет вообще
2. Нет закрытия периода
3. Нет дебета и кредита
4. Нет доходов и расходов
5. Нет бухгалтерских абстракций
6. Автоматическое согласование данных с интегрируемыми системами.
Что я делаю не так?
Теперь, пожалуйста, вы мне ссылочку на описание своей системы.
А для начала можете пояснить: Петя задолжал Васе такую-то вещь. Каким образом осуществляется учет долга?
А для начала можете пояснить: Петя задолжал Васе такую-то вещь. Каким образом осуществляется учет долга?
Не скину — NDA. Внутренняя учетная система для ведомства.
Никаким: система не учитывает долги; учитывается только актуальное владение и управление имуществом.
Никаким: система не учитывает долги; учитывается только актуальное владение и управление имуществом.
А, не учитывает…
Насмешили.
В таком случае, идеальной учетной программой является калькулятор: обязательств нет вообще, нет закрытия периода… (далее по тексту). Берите и считайте!
Насмешили.
В таком случае, идеальной учетной программой является калькулятор: обязательств нет вообще, нет закрытия периода… (далее по тексту). Берите и считайте!
(… а тем временем «в природе» так и есть — в природе никто никому ничего не должен, в природе каждая вещь где-то находится (и имеет какие-то свойства). Долги и обязательства — это введенные обществом абстракции.)
Понимаете ли, я не зря в начале спросил, какую задачу вы решаете.
Понимаете ли, я не зря в начале спросил, какую задачу вы решаете.
Не вполне понимаю.
Обязательство (долг — синоним) — абстракция только в том смысле слова, что принадлежит будущему. Однако когда это будущее случится, передаваемая вещь окажется вполне реальна. И учитывать ее нужно загодя.
Для сравнения: пощупать наяву резервы или собственный капитал (все — в бухгалтерском смысле слова) никак не получится.
А задачу я все равно решаю учетную (не только учета текущих объектов, как вы в своем ведомстве, но и учета будущих объектов — обязательств).
Обязательство (долг — синоним) — абстракция только в том смысле слова, что принадлежит будущему. Однако когда это будущее случится, передаваемая вещь окажется вполне реальна. И учитывать ее нужно загодя.
Для сравнения: пощупать наяву резервы или собственный капитал (все — в бухгалтерском смысле слова) никак не получится.
А задачу я все равно решаю учетную (не только учета текущих объектов, как вы в своем ведомстве, но и учета будущих объектов — обязательств).
«когда» и «если» — это как раз то, что является абстракцией, созданной человеком. «Природе» не нужно ничего учитывать загодя.
В таком случае будущее — это абстракция?
Тоже точка зрения, понимаю. Однако я исходил из того, что будущее учитывать необходимо. Как и прошлое, к слову (ведь прошлое — такая же абстракция, как и будущее). Или вы в своем ведомстве только текущие вещи учитываете, без возможности сгенерировать оборотку, скажем, за прошлый месяц?
Тоже точка зрения, понимаю. Однако я исходил из того, что будущее учитывать необходимо. Как и прошлое, к слову (ведь прошлое — такая же абстракция, как и будущее). Или вы в своем ведомстве только текущие вещи учитываете, без возможности сгенерировать оборотку, скажем, за прошлый месяц?
Ну вот в нашей конкретной задаче нет необходимости учитывать будущее — только прошлое и настоящее.
В вашей нет, а в моем учетном конструкторе есть. Не вижу причин для разногласий.
Завершился полный цикл и вы не заметили, как вопрос вернулся на круги своя: сейчас вас спросят, какую задачу решает ваш конструктор.
Наблюдая данную ветку я всё же примерно понял, что у lair такая задача есть — ведомственая, под NDA. А у вас задача есть? Практическая, конкретная задача, а не «в моём конструкторе такая задача есть — учитывать будущее».
Хочу понять, в каких случаях ваша система будет иметь преимущества.
Наблюдая данную ветку я всё же примерно понял, что у lair такая задача есть — ведомственая, под NDA. А у вас задача есть? Практическая, конкретная задача, а не «в моём конструкторе такая задача есть — учитывать будущее».
Хочу понять, в каких случаях ваша система будет иметь преимущества.
А какую конкретную задачу решает Excel? Конструктор он и есть конструктор.
В свое время я опубликовал Манифест, в котором высказался о сверхзадаче экаунтологии. И на Хабре посты публиковал (Бухгалтерия будущего, к примеру). Все это довольно фантастично и напыщенно, конечно. Можете как угодно к этому относиться, а я… не то чтобы верю, просто мне хочется понять, как должно быть. То, что миллионы моих коллег выполняют в компьютерный век бессмысленную и непродуктивную работу, для меня очевидно.
В свое время я опубликовал Манифест, в котором высказался о сверхзадаче экаунтологии. И на Хабре посты публиковал (Бухгалтерия будущего, к примеру). Все это довольно фантастично и напыщенно, конечно. Можете как угодно к этому относиться, а я… не то чтобы верю, просто мне хочется понять, как должно быть. То, что миллионы моих коллег выполняют в компьютерный век бессмысленную и непродуктивную работу, для меня очевидно.
А какую конкретную задачу решает Excel? Конструктор он и есть конструктор.
Давайте без демагогии? Задача есть? Задача решается проще, лучше, быстрее, чем принятые и привычные методологии учёта? В чём практический выигрыш вашего подхода?
Можно говорить о том, какая прекрасная сверхзадача поставлена — но бизнесу нужна окупаемость. Зачем переходить на новую методологию, какие плюсы?
Двойная запись тоже не сразу прижилась, какое будущее ждёт вашу систему — никто не может предвидеть будущее. Но если у вас нет овета на практические вопросы, который неизбежно будут задавать лица, принимающие решения — ну тогда шансы на какое-то использование будут падать.
У вас ответы есть на эти вопросы? Если есть — пишите новую статью, аргументируйте.
Какую демагогию вы усматриваете в вопросе: «Какую конкретную задачу решает Excel?». Есть типы программ, требующих настройки для решения конкретной задачи, моя программка принадлежит этому типу. Полагаю, не сообщил Вам ничего нового.
Конкретный плюс — возможность создания на основе данной учетной методики всемирной информационной сети. В ссылках, которые я вам указал, написано ясно и подробно. Окупаемость бизнеса меня мало волнует, потому как научно-технический прогресс часто развивается вопреки интересам бизнеса. Прошу прощения за пафос, но меня истина волнует, а не мошна толстосумов.
Про то, как, по вашему мнению, приживалась двойная запись, с интересом послушаю. Хотя предупреждаю: в этом вопросе я специалист, автор опубликованных трудов.
Конкретный плюс — возможность создания на основе данной учетной методики всемирной информационной сети. В ссылках, которые я вам указал, написано ясно и подробно. Окупаемость бизнеса меня мало волнует, потому как научно-технический прогресс часто развивается вопреки интересам бизнеса. Прошу прощения за пафос, но меня истина волнует, а не мошна толстосумов.
Про то, как, по вашему мнению, приживалась двойная запись, с интересом послушаю. Хотя предупреждаю: в этом вопросе я специалист, автор опубликованных трудов.
Когда передо мной стоит задача, я могу выбрать Excel, если он мне подходит.
Вас просят назвать задачу, для решения которой было бы удобно использовать ваше решение. А вы всё уходите от ответа.
Вас просят назвать задачу, для решения которой было бы удобно использовать ваше решение. А вы всё уходите от ответа.
Потенциальные задачи: инвентарный учет, обязательственный учет, учет доходов и расходов. Программа планируется к использованию для складского учета, домашнего учета. Версия 1.0 рекомендуется для использования в качестве учебного пособия по экаунтологии.
Хорошо, поставим вопрос по другому: "… задачу, для решения которой было бы удобнее использовать ваше решение, выбирая между аналогами".
Во, давно бы так. Представим, что некоторая фирма заинтересовалась вашей разработкой и захотела бы у себя внедрить подобный учёт, то:
1. Какую практическую пользу она бы получила от использования вашей методики?
2. Правильно я понимаю, что пришлось бы вести по как минимум двум методикам (вашей и обычной)?
3. Если есть необходимость вести одновременный учёт по двум методикам, то задумывались ли вы о каком-то автоматическом конверторе из вашего учёта в привычный? Есть намётки, что предложить?
1. Какую практическую пользу она бы получила от использования вашей методики?
2. Правильно я понимаю, что пришлось бы вести по как минимум двум методикам (вашей и обычной)?
3. Если есть необходимость вести одновременный учёт по двум методикам, то задумывались ли вы о каком-то автоматическом конверторе из вашего учёта в привычный? Есть намётки, что предложить?
2. Правильно я понимаю, что пришлось бы вести по как минимум двум методикам (вашей и обычной)?И да, и нет. Нет, дублировать по обычной методике не требуется. Да, на выходе придется все равно выдавать отчеты для налоговой (независимо от выбранной методики — это уже ответ на пункт 3).
Моя система не для фирм, а для индивидуальных пользователей.
В идеале распространение такое: торговая сеть предлагает новый вид услуг — сообщение о покупках в систему покупателя. Покупатель инсталлирует программку, регистрируется на сайте, и получает данные о произведенных покупках непосредственно в базу. Ну, типа электронной накладной, только при этом пользователь может вести домашний учет, какой захочет.
Это один из вариантов.
В идеале распространение такое: торговая сеть предлагает новый вид услуг — сообщение о покупках в систему покупателя. Покупатель инсталлирует программку, регистрируется на сайте, и получает данные о произведенных покупках непосредственно в базу. Ну, типа электронной накладной, только при этом пользователь может вести домашний учет, какой захочет.
Это один из вариантов.
Существенно проще использовать пластик и использовать данные банка, чем уговаривать каждого продавца устанавливать вашу систему.
Пластик — это пластик, а речь идет о софте, об обработке данных. Пластик софту ни в коем случае не противоречит. Провели транзакцию по пластику, так пускай данные сразу попадут в личную учетную базу, в которой уже хранится информация по имуществу, по другим карточкам и банковским счетам и т.п.
Возможно Daemon_Hell имел ввиду, что реализацией и распространением такой системы должен заниматься банк. Это, кстати, очевидно на примере разных дисконтных программ. Т.к. программ много -> карточек много -> не удобно. В тоже время банковская карта всегда с собой, без неё покупку не сделаешь.
Т.е. именно банк имеет больше возможностей и удобства для клиентов реализовать потенциал методологии, например, в личном кабинете интернет-банка. (С архитектурной точки зрения. Вопросы согласований с МПС никто не снимает).
Т.е. именно банк имеет больше возможностей и удобства для клиентов реализовать потенциал методологии, например, в личном кабинете интернет-банка. (С архитектурной точки зрения. Вопросы согласований с МПС никто не снимает).
А почему сразу столько хейтерства?
Вроде как человек тут не пытается свои теории некому навязывать. Он сделал программу и предлагает ее абсолютно бесплатно. Попробовал — удобно — пользуйся. Нет — ну и нет.
Или Вам очень важно работать в программе, основанной обязательно на проверенных научных разработках, заверенных РАН или кем-то еще?
Ну тогда SAP / 1C да и кучу всего еще Вам в помощь.
Тут же не спутники запускают, а домашнюю бухгалтерию ведут.
А по поводу «семи лет» — то, что для одного человека — ерунда, для другого может быть жизнью. Вам никто ничего не навязывает.
Будьте добрее.
Вроде как человек тут не пытается свои теории некому навязывать. Он сделал программу и предлагает ее абсолютно бесплатно. Попробовал — удобно — пользуйся. Нет — ну и нет.
Или Вам очень важно работать в программе, основанной обязательно на проверенных научных разработках, заверенных РАН или кем-то еще?
Ну тогда SAP / 1C да и кучу всего еще Вам в помощь.
Тут же не спутники запускают, а домашнюю бухгалтерию ведут.
А по поводу «семи лет» — то, что для одного человека — ерунда, для другого может быть жизнью. Вам никто ничего не навязывает.
Будьте добрее.
Хейтерство не к статье и не к тому, что человек самостоятельно изучил ЯП, сделал и бесплатно распространяет программу. Это как раз вызывает уважение и благодарность.
Напрягают комментарии. В них автор, с моей предвзятой точки зрения, повышает градус напряжения. Особенно часто встречаются конфликтогены через проявление позиции превосходства.
За статью и программу автору большое спасибо.
Напрягают комментарии. В них автор, с моей предвзятой точки зрения, повышает градус напряжения. Особенно часто встречаются конфликтогены через проявление позиции превосходства.
За статью и программу автору большое спасибо.
Как вам сказать… В целом вы правы. Однако жизнь многогранна: как методолог учета я действительно ощущаю превосходство — слишком редко встречаю людей, которые мне ровня в этом отношении. Большинство не в состоянии воспринять довольно простые вещи, которые я объясняю: даже друзья, не говоря уже о незнакомых комментаторах с техническим образованием (никого конкретно не имею в виду, просто на Хабре меня много пинали по разным поводам). Но то, что я профессиональный методолог, не мешает мне быть лохом во многих других отношениях и вообще малосимпатичным субъектом. Например, в качестве программиста я наглый самозванец и неумеха, было бы смешно утверждать что-то иное при моем стаже в программировании. Однако программировать я никого и не поучаю, не по Сеньке шапка. Все люди такие: хороши в одних отношениях и плохи в других, — вы не находите?..
Спасибо за статью принимаю (все-таки, помимо того, что я профессиональный методолог, я еще и профессиональный писатель), а за программу воздержусь, до полного прояснения обстоятельств. В конце концов, «ЭкаунтоЛогика» предназначена для демонстрации моей учетной методики: будучи непрофессионалом в программировании, гарантировать ее стабильной работы не могу. Здесь профессиональный программист требуется, а не бухгалтер…
Спасибо за статью принимаю (все-таки, помимо того, что я профессиональный методолог, я еще и профессиональный писатель), а за программу воздержусь, до полного прояснения обстоятельств. В конце концов, «ЭкаунтоЛогика» предназначена для демонстрации моей учетной методики: будучи непрофессионалом в программировании, гарантировать ее стабильной работы не могу. Здесь профессиональный программист требуется, а не бухгалтер…
«Есть теории колеса, которые постарше вот этой вот вашей поделки будут!», — чего вы так неаргументированно взъелись на автора?
Я не взъелся, я задал простой вопрос «чем лучше». А мне в ответ, вместо простого списка преимуществ, выдали «различия есть, огромные, но увидеть их может только методолог.… мой подход основывается на научной разработке… k лет труда»
Ну дак прочтите статью, вроде из нее понятно, какими сущностями оперирует программа и сравните с теми, что применяются при учете в обычных бухгалтерских программах.
Или не читатель? :)
Или не читатель? :)
Ответил, читайте выше:
habrahabr.ru/post/244465/#comment_8156309
habrahabr.ru/post/244465/#comment_8156309
Найдите прошлые статьи автора на Хабре, он очень подробно разъяснял, почему существующий учет сложен и нелогичен.
А тогда о какой научности можно говорить? Собственные книги — это совсем не то же самое, выпустить книгу может любой, у кого есть какое-то количество денег.
Вы бы по ссылке сначала прошли.
Супер, особенно как система для «изобретения» в процессе обучения бухгалтерского учета. Ну а после того как обучающийся его изобрел, то можно добавить план счетов и вуаля, получаем толкового бухгалтера.
Не увидел принципиальных отличий от традиционных учетных программ, простите. приход, расход, объекты как разрезы учета
Различия есть, огромные, но увидеть их может только методолог.
Самая кардинальная новация — восприятие обязательств как вещей, регистрируемых будущей датой. Гарантирую, что такого нет нигде (точно ни в одной бухгалтерской программе, т.к. такой естественный способ учета противоречит традиционной двойной записи, в которой обязательства — особый тип объектов). Вообще, у меня реализован отказ от двойной записи (дебета и кредита, которые в бухгалтерии не совсем равнозначны приходу и расходу). Есть другие находки, помельче.
А если в целом… Представьте, что вы находитесь на заводе. Вокруг здания, машины, механизмы, тюки с изделиями и проч. — то есть вещи. И никаких тебе вложений, резервов, расчетов, капитала и прочей непонятной бухгалтерской дребедени. Соответственно, вещи и учитываются — в этом отличие моей программы от бухгалтерских.
Самая кардинальная новация — восприятие обязательств как вещей, регистрируемых будущей датой. Гарантирую, что такого нет нигде (точно ни в одной бухгалтерской программе, т.к. такой естественный способ учета противоречит традиционной двойной записи, в которой обязательства — особый тип объектов). Вообще, у меня реализован отказ от двойной записи (дебета и кредита, которые в бухгалтерии не совсем равнозначны приходу и расходу). Есть другие находки, помельче.
А если в целом… Представьте, что вы находитесь на заводе. Вокруг здания, машины, механизмы, тюки с изделиями и проч. — то есть вещи. И никаких тебе вложений, резервов, расчетов, капитала и прочей непонятной бухгалтерской дребедени. Соответственно, вещи и учитываются — в этом отличие моей программы от бухгалтерских.
двойная запись это частный случай, многие учетные программы прекрасно без нее обходятся
Согласен. Однако покажите мне учетную программу, в которой для принятия к учету обязательства необходимо указать дату совершения операции больше, чем дата регистрации операции.
Я думаю, это придет в голову каждому, кто решил сделать себе программу учета финансов и закладывать регулярные или будущие платежи.
Собственно, я в своем учете именно так и сделал.
А дебета-кредита тоже нет, есть операция, которая может быть как положительной, так и отрицательной. Просто потому, что это упрощает структуру классов, а делает тоже самое.
Собственно, я в своем учете именно так и сделал.
А дебета-кредита тоже нет, есть операция, которая может быть как положительной, так и отрицательной. Просто потому, что это упрощает структуру классов, а делает тоже самое.
Верю.
Решения, к которым я пришел, довольно просты. Поэтому цена программки полушка в базарный день. Однако я смог систематизировать возможные решения и изложить на бумаге (не слишком удачно, но тем не менее). Ценна теория, а не программный код.
К слову, а вы можете учитывать в своей программке вещи, а не деньги? Любопытно.
Решения, к которым я пришел, довольно просты. Поэтому цена программки полушка в базарный день. Однако я смог систематизировать возможные решения и изложить на бумаге (не слишком удачно, но тем не менее). Ценна теория, а не программный код.
К слову, а вы можете учитывать в своей программке вещи, а не деньги? Любопытно.
А в чем принципиальная разница между деньгами и вещами? Если вести мультивалютный учет — в любом случае добавляется свойство валюта. Можно его и использовать чтобы различать вещи и деньги.
В том, что у вещей больше одной учитываемой характеристики (например, помещения учитываются по стоимости и площади).
Деньги тоже могут учитываться по нескольким стоимостным характеристикам. Например, купюра в 100 рублей — это 100 рублей, 2 доллара и т.д.
Собственная характеристика денег только одна — это сумма. Купюра в сто рублей — это сто рублей. Два доллара — это производная рассчитываемая величина (которая меняется в зависимости от чего угодно).
В целом, да. Однако тут имеет значение, это «что угодно» присутствует в системе или нет:
если присутствует, то да, два доллара — расчетная величина,
если нет, то два доллара (в качестве регистрируемого свойства купюры) — характеристика купюры.
если присутствует, то да, два доллара — расчетная величина,
если нет, то два доллара (в качестве регистрируемого свойства купюры) — характеристика купюры.
Купюры как вещи. Не денег.
Да, как вещи.
Просто в современной экономике деньги используются в двух ипостасях:
1) в качестве стоимостной характеристики других вещей (вещь стоимостью сто рублей),
2) в качестве объекта учета (в кассе 100 рублей).
Просто в современной экономике деньги используются в двух ипостасях:
1) в качестве стоимостной характеристики других вещей (вещь стоимостью сто рублей),
2) в качестве объекта учета (в кассе 100 рублей).
Вот и учитываться деньги могут как вещи, а могут — как деньги (да, я понимаю, что звучит криво, но это данность). В зависимости от целей учета структура учетной системы будет меняться.
Структура учетной системы едина: есть вещи, а есть их свойства.
Если учитываем деньги в качестве купюр, то наличность в 100 руб. может обладать числовыми свойствами:
рублей — 100,
долларов — 2,
и т.д.
Если вы имеете в виду, что вещи могут оцениваться в рублях, то да, могут — как и в любых других своих числовых свойствах.
Если учитываем деньги в качестве купюр, то наличность в 100 руб. может обладать числовыми свойствами:
рублей — 100,
долларов — 2,
и т.д.
Если вы имеете в виду, что вещи могут оцениваться в рублях, то да, могут — как и в любых других своих числовых свойствах.
>> Структура учетной системы едина: есть вещи, а есть их свойства.
Знаете, это утверждение верно вообще для любой модели — есть сущности, есть их свойства. Вопрос в том, как именно представляются эти свойства в системе — например, возможна по ним агрегация, или нет? Есть у них история, или нет? Приводит ли изменение одного к изменению другого?
Знаете, это утверждение верно вообще для любой модели — есть сущности, есть их свойства. Вопрос в том, как именно представляются эти свойства в системе — например, возможна по ним агрегация, или нет? Есть у них история, или нет? Приводит ли изменение одного к изменению другого?
Агрегация — да, возможна (у меня это отчетные папки, показатели по ним подсчитываются по агрегированным данным).
История изменений — да, имеется.
Смотря что под этим понимать. У меня любое изменение объекта заключается в расходе одного объекта и приходе другого (связь между ними устанавливается через операцию).
История изменений — да, имеется.
Приводит ли изменение одного к изменению другого?
Смотря что под этим понимать. У меня любое изменение объекта заключается в расходе одного объекта и приходе другого (связь между ними устанавливается через операцию).
>> Агрегация — да, возможна (у меня это отчетные папки, показатели по ним подсчитываются по агрегированным данным).
Вы, похоже, не представляете себе стоимости такой модели (с произвольно агреггируемыми атрибутами) на сотнях тысяч и миллионах учитываемых объектов при группировке по десятку критериев.
Вы, похоже, не представляете себе стоимости такой модели (с произвольно агреггируемыми атрибутами) на сотнях тысяч и миллионах учитываемых объектов при группировке по десятку критериев.
А. Если учитывать все характеристики объекта — то действительно все усложняется. У себя в голове я держал учет в штуках. А уже конкретные характеристики этих штук — отдельно сбоку.
Правильно.
Принципиальная разница в том, что вещи существуют как бы изначально, а деньги выдуманы для экономических нужд (хотя могут представлять собой вещи, но могут и не представлять). Таким образом, вещи естественны, а деньги искусственны.
Принципиальная разница в том, что вещи существуют как бы изначально, а деньги выдуманы для экономических нужд (хотя могут представлять собой вещи, но могут и не представлять). Таким образом, вещи естественны, а деньги искусственны.
>а вы можете учитывать в своей программке вещи, а не деньги?
это делают все программы складского учета без исключения
это делают все программы складского учета без исключения
У вас вроде программа учета финансов, потому и спросил.
Речь идет об универсальном учетном конструкторе, функционирующем по универсальным природным правилам: что-то вроде Excel для учета. А что множество учетных программ решают локальные задача, мне известно. Ну решают. И учитывают одно и то же — вещи. И часто очень похожи друг на друга. А иногда отличаются какими-нибудь находками, умными и полезными. Однако речь не о частностях, а об учетном универсализме.
Речь идет об универсальном учетном конструкторе, функционирующем по универсальным природным правилам: что-то вроде Excel для учета. А что множество учетных программ решают локальные задача, мне известно. Ну решают. И учитывают одно и то же — вещи. И часто очень похожи друг на друга. А иногда отличаются какими-нибудь находками, умными и полезными. Однако речь не о частностях, а об учетном универсализме.
> покажите мне учетную программу, в которой для принятия к учету обязательства необходимо указать дату совершения операции
каждая первая включающая в себя планирование расходов или график поступления денежных средств, например.
каждая первая включающая в себя планирование расходов или график поступления денежных средств, например.
Мне сложно судить без конкретного примера.
В бухгалтерской литературе концепция обязательства как будущего объекта не изложена. Но если кто-то из программистов до этого самостоятельно додумался, не удивлюсь.
Нужен текст, в котором описывалась бы концепция обязательства. Если мои методы учета кто-то сформулировал раньше меня, я данный факт признаю. А софт- это слишком зыбко: нужно лезть в опции, смотреть базу, как она устроена… Причем наверняка выяснится, что иначе, чем у меня.
В бухгалтерской литературе концепция обязательства как будущего объекта не изложена. Но если кто-то из программистов до этого самостоятельно додумался, не удивлюсь.
Нужен текст, в котором описывалась бы концепция обязательства. Если мои методы учета кто-то сформулировал раньше меня, я данный факт признаю. А софт- это слишком зыбко: нужно лезть в опции, смотреть базу, как она устроена… Причем наверняка выяснится, что иначе, чем у меня.
Просто для справки: все биржевые учетные системы, а также депозитарного учета и регистраторы работают с учетом в будущем времени. Основная площадка на ММВБ работает в режиме Т+2, когда сделка регистрируется сейчас а приход по ней будет учтен через два дня.
Наверное. Однако биржевая система не универсальна, это один из множества частных случаев применения учета на практике. Регистрировать что-то будущей датой, ясен пень, не я придумал. Я всего лишь создал (или считаю, что создал — на ваше усмотрение) теорию естественного компьютерного учета. Универсальную. Программа — попытка проверить, работоспособна методика или нет.
Что-то мне это напомнило один комментарий, если я не ошибаюсь, от Milfgard: «сначала было все очень сложно и мы позвали спеца для того, чтобы он выпилил лишний функционал. Но с ростом оборота все эти аналитики оказались нужны и мы опять позвали спеца, чтобы он вернул как было». Это я вот к чему: на какой объем движений рассчитан ваш продукт? Точнее несколько не так: До какого момента роста объемов ваш подход из 6ти действий будет действительно удобней, чем дебет и кредит (вполне понятные, кстати) по нескольким счетам? И да, учитывайте, что полярный подход более привычен всем, за редким исключение: тепло/холодно, есть/нет, дебет/кредит.
Шесть действий покрывают все природные явления (все то, что можно сделать с вещами). Строго говоря, изменение объекта единственно по своей природе, а шесть действий — в некотором смысле адаптация к учетным нуждам и упрощение жизни пользователю. Можно было обойтись одним диалоговым окошком изменения объекта (но тогда пользователю было бы сложно с этим окошком работать).
В том, что дебет и кредит понятны, не согласен. Вы, возможно, феномен, а вот мне, обыкновенному студенту, в институте было абсолютно непонятно: дебет — поступление денег, а какого тогда рожна поступление капитала — это кредит?!
В том, что дебет и кредит понятны, не согласен. Вы, возможно, феномен, а вот мне, обыкновенному студенту, в институте было абсолютно непонятно: дебет — поступление денег, а какого тогда рожна поступление капитала — это кредит?!
Да нет, я не гений) просто вы, как и все, путаете крЕдит и кредИт ) ну или путали в начале своего пути
Дебет с кредитом становятся понятны и логичны, как только приходит осознание, что предприятие и его владельцы – разные сущности, и учет ведется именно с точки зрения предприятия.
Тогда поступление капитала означает увеличение обязательств предприятия перед владельцами, и всё становится на свои места.
Тогда поступление капитала означает увеличение обязательств предприятия перед владельцами, и всё становится на свои места.
Спасибо, с обязательственной теорией баланса я знаком. И со многими другими худо-бедно тоже (к примеру, Помазков их около четырех десятков насчитывал). Однако обсуждение счетных теорий в комментариях к этому посту вряд ли правильно. Могу лишь сказать, что ни одна из существующих балансовых теорий меня не устраивает, в том числе обязательственная (иначе бы я не изобретал собственную теорию — экаунтологию).
Если желаете услышать мои возражения по поводу обязательственной теории, найдите мою брошюру «Баланс для начинающих», 3-е изд., глава 27 «Обязательственная концепция». В Сети книга валяется, найти несложно.
Если желаете услышать мои возражения по поводу обязательственной теории, найдите мою брошюру «Баланс для начинающих», 3-е изд., глава 27 «Обязательственная концепция». В Сети книга валяется, найти несложно.
Мне кажется что вы зря сравниваете Вашу программу с программой бухгалтерского учета.
По мне так это обычный количественный учет. Но вот если взять задачку посложнее, то для учитывания всех тонкостей количественного учета придется слишком часто применять эти шесть действий.
С усушкой вы делаете на 1 действие больше чем обычно, вместо списания разницы вы списываете все, потом приходуете остаток.
Как тут будет работать партионный учет или учет себестоимости — вообще не понятно, но дело не в этом. Возьмем учет немного сложнее.
Итак у нас общепит, мы готовим некое блюдо. В простом случае (салат) мы смешали помидор и огурец.
Соединить огурец и помидор и все (ну если я верно понял вашу систему)
Но вот нам приходится готовить суп, на каждый ингридиент у нас идет от 1 до 4 (в простом случае) этапов приготовления.
Этапы к примеру свеклы:
Купили, почистили (часть притом), отварили (масса изменилась), обжарили с маслом (опять что — то поменялось с массой), бросили в суп.
Как ваша программа будет описывать каждый этап количественного учета?
Также мы понимаем что ингридиент свекла может после второй стадии (варки) использоваться в салатах (частично положим ее в винегрет) а частично обжарим.
Я понимаю что это учетная задача средней сложности. Есть более сложные варианты, к примеру учет на непрерывном производстве и т.п.
По мне так это обычный количественный учет. Но вот если взять задачку посложнее, то для учитывания всех тонкостей количественного учета придется слишком часто применять эти шесть действий.
добавить (то есть внести в учетную систему, зарегистрировать в ней),
соединить (несколько вещей в одну),
изменить (те или иные свойства вещи),
передать (другому лицу),
разделить (одну вещь на несколько),
удалить (вычеркнуть вещь из учетной системы).
С усушкой вы делаете на 1 действие больше чем обычно, вместо списания разницы вы списываете все, потом приходуете остаток.
Как тут будет работать партионный учет или учет себестоимости — вообще не понятно, но дело не в этом. Возьмем учет немного сложнее.
Итак у нас общепит, мы готовим некое блюдо. В простом случае (салат) мы смешали помидор и огурец.
Соединить огурец и помидор и все (ну если я верно понял вашу систему)
Но вот нам приходится готовить суп, на каждый ингридиент у нас идет от 1 до 4 (в простом случае) этапов приготовления.
Этапы к примеру свеклы:
Купили, почистили (часть притом), отварили (масса изменилась), обжарили с маслом (опять что — то поменялось с массой), бросили в суп.
Как ваша программа будет описывать каждый этап количественного учета?
Также мы понимаем что ингридиент свекла может после второй стадии (варки) использоваться в салатах (частично положим ее в винегрет) а частично обжарим.
Я понимаю что это учетная задача средней сложности. Есть более сложные варианты, к примеру учет на непрерывном производстве и т.п.
Про салат абсолютно правильно излагаете.
Пример с супом решается в таком же ключе, посредством выполнения изменения, соединения, разделения:
почистили — изменение (масса уменьшилась, также можно зафиксировать изменение какого-либо свойства, к примеру: вместо «неочищенная» стала «очищенная»),
если далее использовали часть вещи — разделение (одну часть — для супа, вторую — для салата),
отварили — в том же порядке, что первая операция.
Вот так это и будет описываться, как в жизни происходит. Разумеется, если нет желания регистрировать мельчайшие изменения, можно соединить ингредиенты сразу в суп (ну, еще отходы вычесть придется). Вот именно для учета таких операций программа и предназначена. Непрерывное производство тому не помеха, ведь регистрировать можно с разной степенью временнОй детализации. Если двойная запись с этим кое-как справляется, то естественная методика — тем более (я имею в виду не конкретный софт, написанный непрофессионалом, а методику).
Партионный учет (если я вас правильно понял) — не проблема, только в посте об этом не говорится. Программа позволяет учитывать вещи как по отдельности, так и кучно (посредством химического объединения), так что сложить вещи в кучу — не проблема. Учет себестоимости — тоже не вижу проблем. Если вещи объединять, то их числовые характеристики автоматически складываются, стоимость тарелки супа будет подсчитана автоматически.
Вообще, немного не так. Сначала разделяю вещь надвое, а потом одну из вещей удаляю. Но действий два, как ни крути, хотя одно из них можно выполнять автоматически. Сейчас у меня так реализована передача: если передаем другому лицу часть вещи, то непосредственно при передаче указываем числовую характеристику, тогда разделение вещи на части происходит автоматически. Надо будет и для удаления то же самое сделать, спасибо за подсказку!
Пример с супом решается в таком же ключе, посредством выполнения изменения, соединения, разделения:
почистили — изменение (масса уменьшилась, также можно зафиксировать изменение какого-либо свойства, к примеру: вместо «неочищенная» стала «очищенная»),
если далее использовали часть вещи — разделение (одну часть — для супа, вторую — для салата),
отварили — в том же порядке, что первая операция.
Вот так это и будет описываться, как в жизни происходит. Разумеется, если нет желания регистрировать мельчайшие изменения, можно соединить ингредиенты сразу в суп (ну, еще отходы вычесть придется). Вот именно для учета таких операций программа и предназначена. Непрерывное производство тому не помеха, ведь регистрировать можно с разной степенью временнОй детализации. Если двойная запись с этим кое-как справляется, то естественная методика — тем более (я имею в виду не конкретный софт, написанный непрофессионалом, а методику).
Партионный учет (если я вас правильно понял) — не проблема, только в посте об этом не говорится. Программа позволяет учитывать вещи как по отдельности, так и кучно (посредством химического объединения), так что сложить вещи в кучу — не проблема. Учет себестоимости — тоже не вижу проблем. Если вещи объединять, то их числовые характеристики автоматически складываются, стоимость тарелки супа будет подсчитана автоматически.
С усушкой вы делаете на 1 действие больше чем обычно, вместо списания разницы вы списываете все, потом приходуете остаток.
Вообще, немного не так. Сначала разделяю вещь надвое, а потом одну из вещей удаляю. Но действий два, как ни крути, хотя одно из них можно выполнять автоматически. Сейчас у меня так реализована передача: если передаем другому лицу часть вещи, то непосредственно при передаче указываем числовую характеристику, тогда разделение вещи на части происходит автоматически. Надо будет и для удаления то же самое сделать, спасибо за подсказку!
Плюсанул как минимум за упертость в достижении цели. Изучить язык программирования и написать программу ради реализации одной идеи — это достойно уважения.
Конечно, автор молодец, но…
Этому приложению не хватает юзабилити или удобного интерфейса.
Кнопка «Служебное меню» не сразу можно найти. И зачем эта кнопка, если она повторяет все пункты меню?
Горячие клавиши — тоже немного поправить бы — F5 — больше ассоциируется с обновлением данных, а не с отображением папок.
В общем по хорошему надо продумать интерфейс. Но для версии 1.0 сойдет и такой. Это так, на будущее.
А вообще я бы почитал отдельную статью про экаунтологию от автора, в котором он сравнивал бы с существующим подходом (дебет/кредит). И объяснил там все ньюансы, плюсы и минусы и варианты использования (масштабы применения методики экаунтологии).
Этому приложению не хватает юзабилити или удобного интерфейса.
Кнопка «Служебное меню» не сразу можно найти. И зачем эта кнопка, если она повторяет все пункты меню?
Горячие клавиши — тоже немного поправить бы — F5 — больше ассоциируется с обновлением данных, а не с отображением папок.
В общем по хорошему надо продумать интерфейс. Но для версии 1.0 сойдет и такой. Это так, на будущее.
А вообще я бы почитал отдельную статью про экаунтологию от автора, в котором он сравнивал бы с существующим подходом (дебет/кредит). И объяснил там все ньюансы, плюсы и минусы и варианты использования (масштабы применения методики экаунтологии).
Столько всего понаписано (увы, не всегда удачного), что даже затрудняюсь… Ну вот эти посты можете прочитать:
geektimes.ru/post/186874/
geektimes.ru/post/181077/
Или посмотрите в профиле сайт (тот, который экаунтологический). Хотя, опять-таки, материал не всегда удачный.
За замечания большое спасибо, учту в следующей версии.
geektimes.ru/post/186874/
geektimes.ru/post/181077/
Или посмотрите в профиле сайт (тот, который экаунтологический). Хотя, опять-таки, материал не всегда удачный.
За замечания большое спасибо, учту в следующей версии.
А вообще если идея такая крутая — то нужно создавать интернет-сервис. А не локальное приложение с локальной базой данных в 1 файле.
А дальше API и т.д.
А дальше API и т.д.
Ага, нужно. Я год назад оборался на Хабре, пытаясь протолкнуть эту идею. Пара человек проявили интерес и мгновенно потеряли. Пришлось делать самому. Пока десктопная версия, а там поглядим… В сравнении с техническим заданием много изменений получилось: то одно с целым не вязалось, то другое — изрядно помучился.
По крайней мере, ясно, что учитывать таким способом можно.
По крайней мере, ясно, что учитывать таким способом можно.
по естественным, заимствованным у природызаконам, неисполнение обязательств не приводит ни к чему. Просто ничего не происходит и все. А в вашей методике необходимо обновлять свойства вещей (сроки прихода), иначе система перейдет в несогласованное состояние. Нет такого кладовщика Василия, который бы согласился хранить на своем складе некие вещи, объем которых в прошлом изменяется в будущем. Я не понимаю, в чем кроме лени, причины хранить разные сущности (материальные и нематериальные) в одном измерении.
Дело в том, что природа учитывает не бухгалтерские обязательства (неисполнение которых действительно ни к чему не приводит), а вещи. Грубо говоря, если природа зарегистрировала, что через неделю метеорит упадет кому-то на башку, то метеорит обязательно упадет, будьте уверены. А вы говорите, ни к чему не приводит!
Аналогичным образом, если у меня регистрируется вещь, она обязательно случится, если только Творец Системы (в данном случае я, как в предыдущем случае Природа) не исправит зарегистрированное ранее. Вы написали:
А все ровно наоборот: как зарегистрировал, так и случится. А если выяснилось, что зарегистрировано неправильно, нужно исправить.
Вы глубоко копнули, но немного недопоняли.
Что касается кладовщика Василия, полностью согласен: кладовщик будет недоволен (как, впрочем, при любой смене программного обеспечения).
Сущность у вещей одна — материальная (нематериальная сущность у абстракций). Только вещи бывают прошлыми, текущими и будущими (причем реально существующими они являются в текущий момент времени. Но это не значит, что прошлые или будущие вещи — абстракции! Вы же не возмущаетесь тем, что прошлые вещи учитываются в одном измерении наряду с текущими, отчего тогда в этот ряд не добавить будущие вещи? В природе именно так происходит, не правда ли: будущее проявляется в текущем, а затем растворяется в прошлом).
Аналогичным образом, если у меня регистрируется вещь, она обязательно случится, если только Творец Системы (в данном случае я, как в предыдущем случае Природа) не исправит зарегистрированное ранее. Вы написали:
А в вашей методике необходимо обновлять свойства вещей (сроки прихода), иначе система перейдет в несогласованное состояние.
А все ровно наоборот: как зарегистрировал, так и случится. А если выяснилось, что зарегистрировано неправильно, нужно исправить.
Вы глубоко копнули, но немного недопоняли.
Что касается кладовщика Василия, полностью согласен: кладовщик будет недоволен (как, впрочем, при любой смене программного обеспечения).
Я не понимаю, в чем кроме лени, причины хранить разные сущности (материальные и нематериальные) в одном измерении.
Сущность у вещей одна — материальная (нематериальная сущность у абстракций). Только вещи бывают прошлыми, текущими и будущими (причем реально существующими они являются в текущий момент времени. Но это не значит, что прошлые или будущие вещи — абстракции! Вы же не возмущаетесь тем, что прошлые вещи учитываются в одном измерении наряду с текущими, отчего тогда в этот ряд не добавить будущие вещи? В природе именно так происходит, не правда ли: будущее проявляется в текущем, а затем растворяется в прошлом).
Давайте не будем углубляться в философию, а разберем простейший случай. Нам на склад отправили посылку, одна штука. Точнее, даже не нам — а мы сами отправили, из филиала. То есть эта самая посылка должна быть уже зарегистрирована в бухгалтерии (допустим, должна).
Все бы ничего, но эту посылку доставляет Почта России, и дата ее прибытия подчиняется принципу неопределенности. Как регистрировать обязательство Почты России перед нами в объеме одной посылки в вашей программе?
Все бы ничего, но эту посылку доставляет Почта России, и дата ее прибытия подчиняется принципу неопределенности. Как регистрировать обязательство Почты России перед нами в объеме одной посылки в вашей программе?
На начало примера (допустим, 1 декабря) зарегистрирован объект, допустим со свойствами:
Название = посылка,
Место = филиал № 1.
Отправили посылку 2 декабря, предполагаем получить 12 декабря. Регистрируем передачу объекта на почту (дата регистрации 2 декабря, дата совершения 2 декабря):
Название = посылка,
Место = почта.
Теперь регистрируем ожидаемое поступление с почты в головной офис (дата регистрации 2 декабря, дата совершения 12 декабря):
Название = посылка,
Место = головной офис.
Это если учет ведется в одной программе. Если головной офис и филиал — разные лица, то иначе. Долго все варианты рассматривать.
Название = посылка,
Место = филиал № 1.
Отправили посылку 2 декабря, предполагаем получить 12 декабря. Регистрируем передачу объекта на почту (дата регистрации 2 декабря, дата совершения 2 декабря):
Название = посылка,
Место = почта.
Теперь регистрируем ожидаемое поступление с почты в головной офис (дата регистрации 2 декабря, дата совершения 12 декабря):
Название = посылка,
Место = головной офис.
Это если учет ведется в одной программе. Если головной офис и филиал — разные лица, то иначе. Долго все варианты рассматривать.
Я не зря упомянул Почту России. Наступило 12 декабря, посылки нет.
Тогда придется отодвинуть обязательство (будущий объект) на более позднюю дату.
Какую? Откуда ее взять-то, если даже лучшие шаманы лишь разводят руками? И сколько раз придется эту дату передвигать?
Предлагаю ввести дополнительную сущность — «плюс вечность», как бесконечно далекий момент времени в будущем. В момент возникновения такое «неопределенное» обязательство регистрируется как проводка с датой исполнения в вечности — а в момент исполнения эта дата сдвигается на текущую.
Предлагаю ввести дополнительную сущность — «плюс вечность», как бесконечно далекий момент времени в будущем. В момент возникновения такое «неопределенное» обязательство регистрируется как проводка с датой исполнения в вечности — а в момент исполнения эта дата сдвигается на текущую.
Верно! Была такая идея, но потом от нее отказался. Зачем, если можно отодвинуть обязательство на 100 лет?
Чтобы не было магических цифер. Работающих бухгалтерских программ полно, чтобы их победить, нужна внутренняя красота, а не внутренние костыли :) Ну и работоспособность, конечно же.
Бритва Оккама.
Зачем вводить понятие бесконечности, если есть понятие 100 лет?
Зачем вводить понятие бесконечности, если есть понятие 100 лет?
Та же бритва: зачем вводить константу 100, если на оси времени уже присутствует удобная абстракция?..
Да можно теоретически — несложно. Однако противоречит сущности обязательства. Вещь, которую отдадут в бесконечности, черт знает что.
На этот случай у меня вероятность погашения обязательства предусмотрена. Таким образом, вещь отдают в конкретный момент, но с некоторой долей вероятия.
На этот случай у меня вероятность погашения обязательства предусмотрена. Таким образом, вещь отдают в конкретный момент, но с некоторой долей вероятия.
Ну вот, одна сторона уже готова признать, что абстракции протекают. А другая?
Вероятность — крайне неудобная вещь. Просто потому что правильно оценить ее довольно сложно. Вот пример: обязательство запланировано к исполнению через 10 лет. Какова вероятность того, что оно исполнится через 5 лет?
Ответ: данных недостаточно! Нужен закон распределения вероятности. Природа обязательства может быть такова, что оно вообще не может исполниться раньше срока — тогда будет ноль. Это может быть нормальное распределение (к примеру, если обязательство исполняется по завершении последней стадии из сотни примерно одинаковых последовательных стадий) — тут нужно знать сигму. А если речь идет про Почту России — тут скорее надо смотреть экспоненциальное распределение (точнее, экспоненциальным будет «положительный» хвост распределения, другая половина устроена куда более сложно).
Без учета всех этих факторов так называемые «вероятности», выдаваемые программой, будут всего лишь красивыми циферками, не имеющими ничего общего с реальностью.
Предлагаю достать бритву и вырезать эти вероятности. Задача прогнозирования — на порядок сложнее задачи учета.
Ответ: данных недостаточно! Нужен закон распределения вероятности. Природа обязательства может быть такова, что оно вообще не может исполниться раньше срока — тогда будет ноль. Это может быть нормальное распределение (к примеру, если обязательство исполняется по завершении последней стадии из сотни примерно одинаковых последовательных стадий) — тут нужно знать сигму. А если речь идет про Почту России — тут скорее надо смотреть экспоненциальное распределение (точнее, экспоненциальным будет «положительный» хвост распределения, другая половина устроена куда более сложно).
Без учета всех этих факторов так называемые «вероятности», выдаваемые программой, будут всего лишь красивыми циферками, не имеющими ничего общего с реальностью.
Предлагаю достать бритву и вырезать эти вероятности. Задача прогнозирования — на порядок сложнее задачи учета.
Согласен с тем, что вероятность — вещь неудобная. Однако у меня ее применение чисто утилитарное. Тебе должны 100 руб., но отдадут с вероятностью 80 %. Показываем в отчете 80 руб. (при желании, если указать в настройках).
Скажите, а вот «чисто утилитарно» кто будет эти вероятности сочинять? :)
Регистратор — тот, кто учитывает. А какие еще имеются кандидатуры?
Однако, не хотите — не учитывайте. Пусть в отчетах отражаются обязательства по номиналу.
Да, и почему вы так ехидно спрашиваете? В бухгалтерии вероятности давным-давно используются, для начисления резервов. Вероятности в бухгалтерии — их не я придумал.
Однако, не хотите — не учитывайте. Пусть в отчетах отражаются обязательства по номиналу.
Да, и почему вы так ехидно спрашиваете? В бухгалтерии вероятности давным-давно используются, для начисления резервов. Вероятности в бухгалтерии — их не я придумал.
Именно в этом случае, имхо, лучше обойтись только двумя значениями: 0 и 100.
Либо я полагаюсь на эти деньги (100%) и поэтому мне их нужно видеть в «доступных» на будущую дату,
либо не полагаюсь и тогда 0%.
Например, мне нужно совершить покупку на 90 руб., я ставлю вероятность возврата 80% и вижу в учёте, что «получу» 80 руб., ага, значит, всё путём, нужно только вещь подешевле найти. Рублей за 79 :))))
Так не пойдёт, либо я смогу купить то, что нужно, либо не смогу.
Либо я полагаюсь на эти деньги (100%) и поэтому мне их нужно видеть в «доступных» на будущую дату,
либо не полагаюсь и тогда 0%.
Например, мне нужно совершить покупку на 90 руб., я ставлю вероятность возврата 80% и вижу в учёте, что «получу» 80 руб., ага, значит, всё путём, нужно только вещь подешевле найти. Рублей за 79 :))))
Так не пойдёт, либо я смогу купить то, что нужно, либо не смогу.
Дихотомия «черное-белое» здесь не прокатит, «полагаюсь — не полагаюсь» — не разговор. А что если не уверен? Кто его знает, получишь деньги или не получишь? Поэтому оценка по вероятности (имеющая место в современном учете, что удивительно) — разумный подход.
А если не уверен, ставишь — 0.
Потому что оценить вероятностью числом от 0 до 100 не получится. 85% от 80% в плане уверенности ничем не отличается, а в учёте «лишние» 5 рублей.
Тут можно только качественные категории использовать. Максимум 4-5 бальную шкалу (и даже это от лукавого).
Вероятностный подход может сработать только на больших числах, например, для банков с заёмщиками.
А если у вас 10-15 контрагентов (а у физиков и того меньше), никакого вероятностного подхода быть не может, имхо.
Потому что оценить вероятностью числом от 0 до 100 не получится. 85% от 80% в плане уверенности ничем не отличается, а в учёте «лишние» 5 рублей.
Тут можно только качественные категории использовать. Максимум 4-5 бальную шкалу (и даже это от лукавого).
Вероятностный подход может сработать только на больших числах, например, для банков с заёмщиками.
А если у вас 10-15 контрагентов (а у физиков и того меньше), никакого вероятностного подхода быть не может, имхо.
Зачем, если можно отодвинуть обязательство на 100 лет?У меня был разрыв шаблона, когда я увидел дату «конца света» в SAP: 31 декабря 9999 г.
Потом ничего, привык относиться к ней как к бесконечности :)
«Все абстракции протекают»: поставщик гарантирует некоторый уровень сервиса, вы в учётной системе фиксируете задекларированный уровень сервиса, а фактический уровень отличается… Отсюда, из протекающей абстракции и идёт беда.
Затыкать её другой абстракцией («дата +100 лет» или «дата вечность») — не менее порочный подход.
А, ну да: есть ещё пушистые/нечёткие множества: там сразу вводится другая абстракция, которая более устойчива к протеканию. Но и сложнее считается.
Затыкать её другой абстракцией («дата +100 лет» или «дата вечность») — не менее порочный подход.
А, ну да: есть ещё пушистые/нечёткие множества: там сразу вводится другая абстракция, которая более устойчива к протеканию. Но и сложнее считается.
Это вот тоже выглядит как усложнение учетной работы — вместо отражения факта (по факту того как он случился!) учетчику придется регулярно (ежедневно с более-менее регулярным учетом чего-то «существенного») проверять наступление таких обязательств…
Плюс излишнее шаманство с «добавить вещь-отнять вещь», или «вероятность наступления» в операциях, осуществляемых в уже работающих «традиционных учетных» продуктах одним кликом…
Вроде бы Вы (КМК, как человек «уставший» от излишней «накрученности учетов»...) стремитесь упростить и понятия и операции, но почему-то это все равно вытекает в усложнение и условности…
Плюс излишнее шаманство с «добавить вещь-отнять вещь», или «вероятность наступления» в операциях, осуществляемых в уже работающих «традиционных учетных» продуктах одним кликом…
Вроде бы Вы (КМК, как человек «уставший» от излишней «накрученности учетов»...) стремитесь упростить и понятия и операции, но почему-то это все равно вытекает в усложнение и условности…
Это вот тоже выглядит как усложнение учетной работы.
Не согласен. Никакого усложнения в данном случае нет, хотя упрощения тоже. Регистрировать погашения обязательства в бухгалтерии или проверять в экаунтологии, в чем разница? К тому же можно регистрировать обязательства со сроком погашения в 100 лет, как предлагалось выше, тогда методика приблизится к обычной бухгалтерской.
Плюс излишнее шаманство с «добавить вещь-отнять вещь»
Будет и у меня одним кликом, дайте время. Только на основе не «спецбухгалтерских», а универсальных опций по работе с учетными базами данных.
или «вероятность наступления» в операциях, осуществляемых в уже работающих «традиционных учетных» продуктах одним кликом…
Неужели начисление бухгалтерского резерва проще указания на вероятность в моей программе??? Вероятность можно и не отражать, в конце концов.
Вроде бы Вы (КМК, как человек «уставший» от излишней «накрученности учетов»...) стремитесь упростить и понятия и операции, но почему-то это все равно вытекает в усложнение и условности…
Мой метод более естественный, чем бухгалтерский: во всяком случае, условностей в нем на порядок меньше. Что касается сложности… да, программа сложна. Сложна, как сама жизнь. Программа всего лишь имитирует то, что можно произвести с вещами в реальной жизни.
Программа всего лишь имитирует то, что можно произвести с вещами в реальной жизни.Ну так механизм учёта не должен имитировать реальную жизнь, он должен являться моделью. При этом, наоборот, чем проще модель — тем лучше.
Модель — это и есть некоторым образом имитация, по-моему. А бухгалтерский учет настолько отдалился от реальной жизни, что давно уже существует по принципу: Если я не похож на реальную жизнь, тем хуже для нее.
Согласен. Только простота не должна мешать исполнению функций. Если реальность, которую необходимо отобразить, сложна, тогда модели — хочешь не хочешь — тоже приходится быть сложной.
чем проще модель — тем лучше.
Согласен. Только простота не должна мешать исполнению функций. Если реальность, которую необходимо отобразить, сложна, тогда модели — хочешь не хочешь — тоже приходится быть сложной.
Про Василия дело не в ПО, а в том, что в отчетную дату у него Х вещей на полке, он им рад, он их чувствует и пыль стирает. А завтра вы ему измените сегодня, изменив остаток объема обязательств. Василий лицо материально-ответственное и ему не понравится отвечать за сохранность того, чего он в глаза не видел.
если у меня регистрируется вещь, она обязательно случитсяэто платоновщина, в хорошем смысле. Объем и сроки исполнения обязательств подконтрольны только субъектам управления (поставщикам), кем вы в момент регистрации не являетесь. Поэтому просто плодится энтропия. Нет практического смысла, зарегистрируете вы 1 или 10 яблок, их в дату поставки может быть и 50.
Будущее всегда предположительно, поэтому регистрация любого обязательства — в некотором роде сказки про белого бычка.
На самом деле все равно:
зарегистрировать погашение обязательства и не регистрировать отсутствие погашения, как в бухгалтерии,
или не регистрировать погашение обязательства и регистрировать отсутствие погашения, как у меня.
Поставщикам сроки исполнения обязательств тоже неподконтрольны, всегда может образоваться форс-мажор. Это одному Богу подконтрольно.
На самом деле все равно:
зарегистрировать погашение обязательства и не регистрировать отсутствие погашения, как в бухгалтерии,
или не регистрировать погашение обязательства и регистрировать отсутствие погашения, как у меня.
Поставщикам сроки исполнения обязательств тоже неподконтрольны, всегда может образоваться форс-мажор. Это одному Богу подконтрольно.
Грубо говоря, если природа зарегистрировала, что через неделю метеорит упадет кому-то на башку, то метеорит обязательно упадет, будьте уверены
Знаете, это очень спорная аналогия и вы становитесь на весьма скользкий путь, используя её. «Природа зарегистрировала, что через неделю...»
Кроме того, очень спорны некоторые моменты. Вот вы говорите: «как зарегистрировал — так и случится», «природа учитывает вещи, а не абстракции». Понимаете, ваша [учётная] система — это тоже один из способов описания реальности.
Более того — из того, что вы описываете вещи, а не некоторые абстракции (вы полагаете, что «дебет» и «кредит» — некие абстракции, верно полагаете), ваша система по-прежнему остаётся такой же абстрактной методологией, как и другая методология, которая оперирует абстракциями типа «кредит» и «дебет».
Вы говорите «я учитываю вещь» (как сама природа), а на самом деле учитываете «абстракция называемая 'вещь'».
Любая модель — получается отсекновением, упрощением оригинала. Вот и ваша… Вы же говорили в примере про светофор, который меняет цвет с красного на жёлтый — что его можно по-разному моделировать и описали «а в моей модели принят следующий принцип». Ну хорошо, принят.
А кроме того, я бы не рекомендовал апеллировать к фразе «как написано в модели — так и станет в реальности» (как зарегистрировал — так и случится), это чистейший воды пример магического мышления, когда думают, что совершая некие ритуальные действия можно повлиять на материальный мир. Разницы между шаманом Ктулху и финансовым шарлатаном из Enron в этом мало: реальность имеет свойство глубоко наплевательски относиться к происходящему в виртуальности.
В общем я о чём? Ваша модель в чём-то любопытна, явно неординарна — но попробуйте как-то несколько по-иному подбирать аргументацию, возможно тогда ваши идеи будут приниматься с меньшим скепсисом.
Вот здорово! Бухгалтерский учёт без придурей. Ну и изучение ЯП до такого достойного уровня вызывает глубокое уважение!
Я для себя упрощал БУ так:
1. С помощью отрицательных чисел: у меня -2 яблока = я должен 2 яблока
Сумма каждой проводки аксиоматически принимается равной нулю, так что sum(Credit) = sum(Debit)
sum(Credit) — sum(Debit) = 0.
Какие-то счета удобнее вести, помножив всё уравнение на -1, но это нужно лишь для преставления пользователю.
А вы учитываете отрицательные значения?
2. Применения единиц измерения в расширенном физическом смысле.
Цена это коэффициент преобразования одной величины в другую.
2 яблока — 1 груша = 0 рублей (баланс операции обмена)
это можно решить, например, если ввести коэффициенты преобразования яблок и груш в рубли — их цены.
Таким образом, денежное представление баланса является лишь одним из возможных. Для управленческого учёта можно представлять базу сразу в натуральных единицах. Это как выбор единиц измерения для графиков — кг или граммы. Меняются коэффициенты и числа, но «суть» остаётся той же.
Я для себя упрощал БУ так:
1. С помощью отрицательных чисел: у меня -2 яблока = я должен 2 яблока
Сумма каждой проводки аксиоматически принимается равной нулю, так что sum(Credit) = sum(Debit)
sum(Credit) — sum(Debit) = 0.
Какие-то счета удобнее вести, помножив всё уравнение на -1, но это нужно лишь для преставления пользователю.
А вы учитываете отрицательные значения?
2. Применения единиц измерения в расширенном физическом смысле.
Цена это коэффициент преобразования одной величины в другую.
2 яблока — 1 груша = 0 рублей (баланс операции обмена)
это можно решить, например, если ввести коэффициенты преобразования яблок и груш в рубли — их цены.
Таким образом, денежное представление баланса является лишь одним из возможных. Для управленческого учёта можно представлять базу сразу в натуральных единицах. Это как выбор единиц измерения для графиков — кг или граммы. Меняются коэффициенты и числа, но «суть» остаётся той же.
Цена это коэффициент преобразования одной величины в другуюСмешно. Начнем с того, что цена бывает покупки и продажи — и они не совпадают, даже если обе имеют смысл. Продолжим тем, что может быть еще и несколько разных валют. И закончим осознанием того факта, что все эти «коэффициенты преобразования» изменяются с течением времени.
К примеру, если произойдет дефолт, и директор, хватаясь за сердце, спросит у бухгалтера: «а сколько у нас, собственно, было валюты?» — то ответ «наш суммарный капитал в пересчете на рубли составлял столько-то» не будет содержать ни капли полезной информации.
Скорее наоборот, каждая валюта это отдельная сущность в базе! «Вещь», если хотите.
Деньги в кассе тоже совершенно отдельная вещь с суб-счетами по каждой валюте.
Этот весьма философский пункт я включил именно, чтобы избежать приведения всего «к общему знаменателю» денег в самой БД.
Так что ответы на ваш вопрос в такой системе полностью возможны. Решение о группировке и пересчёте принимается в момент составления отчёта, а не записи в БД. Просто бухгалтер не должен просить систему приводить всё к рублям, а оставить «как есть».
Более того, валюта в разной форме / счетах — это разные вещи. 100 руб в Сбербанке и 100 руб в ПСБ это разные вещи. Особенно они разные при обвале банка. Транзакция про будущую страховую выплату:
— 1 млн 200 тыс единиц «Рубль в банке Рога и Копыта» (произошло вчера)
+ 700 тыс единиц «Рубль в Сберьбанке» (произойдёт через 3 месяца)
Извините, если спутано объясняю, но в своей «методологии» я хотел избежать лишнего приведения всего в деньгам, а по-максимуму сохранять натуральные единицы.
Деньги в кассе тоже совершенно отдельная вещь с суб-счетами по каждой валюте.
Этот весьма философский пункт я включил именно, чтобы избежать приведения всего «к общему знаменателю» денег в самой БД.
Так что ответы на ваш вопрос в такой системе полностью возможны. Решение о группировке и пересчёте принимается в момент составления отчёта, а не записи в БД. Просто бухгалтер не должен просить систему приводить всё к рублям, а оставить «как есть».
Более того, валюта в разной форме / счетах — это разные вещи. 100 руб в Сбербанке и 100 руб в ПСБ это разные вещи. Особенно они разные при обвале банка. Транзакция про будущую страховую выплату:
— 1 млн 200 тыс единиц «Рубль в банке Рога и Копыта» (произошло вчера)
+ 700 тыс единиц «Рубль в Сберьбанке» (произойдёт через 3 месяца)
Извините, если спутано объясняю, но в своей «методологии» я хотел избежать лишнего приведения всего в деньгам, а по-максимуму сохранять натуральные единицы.
А, в таком случае все правильно. К деньгам все приводить можно лишь в красивых отчетах )
Все правильно. У меня именно так реализовано, по крайней мере в смысле валют.
Один в один.
100 руб в Сбербанке и 100 руб в ПСБ это разные вещи.
Один в один.
Чесслово, это скорее недостаток. Деньги были придуманы как некая универсальная вещь в обмене. «Доллар он и в Африке доллар».
Экономическая теория знает многие недостатки золота, доллара и т.п. — но лучше пока вряд ли что-то придумали.
А вы так это отметаете сходу. Что предложите взамен?
Экономическая теория знает многие недостатки золота, доллара и т.п. — но лучше пока вряд ли что-то придумали.
А вы так это отметаете сходу. Что предложите взамен?
Это называется «текущая абстракция» (она же «протекающая» или «дырявая»). Для директора 100 рублей в любом из банков — почти то же самое, что и 100 рублей в сейфе. Но бухгалтеру нужно как минимум знать, какой из банк-клиентов запускать. А еще у денег есть такая вещь, как ликвидность.
Я знаю, что такое протекающая абстракция, но тут речь не о том, что абстракция протекает — а о том, что была удобная абстракция, очень удобная. А вы её прямо под нож искоренили. Ну протекала в некоторых случаях, бывает со всеми.
Но это была очень, очень удобная абстракция. А вот так вместе с водой и ребёночка… Есть что предложить взамен?
Я же не против, что в каких-то случаях абстракция протекала — но что ваша предлагает взамен? Есть понимание? Можете объяснить?
Но это была очень, очень удобная абстракция. А вот так вместе с водой и ребёночка… Есть что предложить взамен?
Я же не против, что в каких-то случаях абстракция протекала — но что ваша предлагает взамен? Есть понимание? Можете объяснить?
Давно известно, что. Труд, без которого не вынешь рыбку из пруда. Теория трудовой стоимости, есть такая. С моей вариацией данной теории можно ознакомиться у меня на экаунтологическом сайте (см. профиль — на сайте колонка справа, называется «Экономические законы природы»).
«Доллар и в Африке доллар», только если мы говорим о физической бумажке.
А с того момента, когда вы этот доллар отдали в кассу банка, вы взамен получили обязательство банка по выдаче вам долларовой бумажки (например называется договор банковского вклада — ДБВ).
И вот обязательство одного банка, совсем не равно обязательству другого банка. Думаю понятно.
Можно на это смотреть как на две валюты: ДБВ_СБЕР и ДБВ_ПСБ.
А с того момента, когда вы этот доллар отдали в кассу банка, вы взамен получили обязательство банка по выдаче вам долларовой бумажки (например называется договор банковского вклада — ДБВ).
И вот обязательство одного банка, совсем не равно обязательству другого банка. Думаю понятно.
Можно на это смотреть как на две валюты: ДБВ_СБЕР и ДБВ_ПСБ.
Список учётных единиц:
доллары, рубли, цена_покупки_руб, цена_продажи_руб,
Для представления в разных учётных единицах есть свои коэффициенты.
Для наличных денег коэффициент будет 1.
В каких хотите единицах, в таких и стройте отчёт.
доллары, рубли, цена_покупки_руб, цена_продажи_руб,
Для представления в разных учётных единицах есть свои коэффициенты.
Для наличных денег коэффициент будет 1.
В каких хотите единицах, в таких и стройте отчёт.
С помощью отрицательных чиселМинус 2 яблока -это ноль яблок. Сами потом грузите минус сто ящиков со склада
Зря вы про ноль яблок. Минус два яблока остаются минус двумя яблоками — отрицательные числа человечество не просто так придумало.
А вот про склад замечание — очень правильное. Если у меня есть 3т яблок, и одну тонну яблок я должен — то сумма в две тонны красиво выглядит лишь в итоговом отчете, а на складе продолжают лежать три.
А вот про склад замечание — очень правильное. Если у меня есть 3т яблок, и одну тонну яблок я должен — то сумма в две тонны красиво выглядит лишь в итоговом отчете, а на складе продолжают лежать три.
Ну да, в итоговом отчёте на конец месяца нужны именно две тонны.
А в операционном отчёте на любую конкретную дату, в т.ч. «на сегодня» — отдельно плюс и минус.
Разве не так?
Причём, большинство вещей может иметь (для транзакционной целостности) лишь положительный баланс. Какие-то (вроде выданных кредитов) — только отрицательный баланс.
А в операционном отчёте на любую конкретную дату, в т.ч. «на сегодня» — отдельно плюс и минус.
Разве не так?
Причём, большинство вещей может иметь (для транзакционной целостности) лишь положительный баланс. Какие-то (вроде выданных кредитов) — только отрицательный баланс.
1. Отрицательные величины не могут регистрироваться в качестве свойств объекта, но могут в частных случаях присутствовать в отчетах (один из таких случаев рассмотрен в посте).
2. Про преобразование не очень понял. А что баланс можно составлять в натуральном выражении — это верно.
2. Про преобразование не очень понял. А что баланс можно составлять в натуральном выражении — это верно.
Прочитал, хорошо, но есть момент, по которому всё это ляжет в ящик стола на ближайшие лет сто, в лучшем случае.
А всё потому, что чиновникам нужна работа. Если чиновники не будут сочинять кучу постоянно меняющихся бумажек — их уволят. Чиновники этого не хотят, поэтому они будут делать всё, чтобы не уволили их. Соответственно, пока чиновники являются столпом этой системы и пока они диктуют свои правила, программисты (1Сники, признавайтесь) получают огромные выплаты из-за того, что каждый раз приходится обновлять базы и формы большому количеству предприятий. В следствии программистам тоже выгодно, что чиновники занимают свои места.
Если руководство страны примет решение заморозить хотя бы на 5 лет формы отчётности — часть компаний разорится, отсюда государство получит меньше налогов и поимеет проблем в виде необходимости в сокращении штата чиновников (ух, как чиновники не любят расставаться со своими креслами), ну и соответственно, наметится некоторая безработица у 1Сников, которым придётся переучиваться на что-нибудь другое, либо соглашаться на более низкую зарплату.
Соответственно, пока государство не перестроит подход по управлению собой (не думаю, что такое возможно), все подобные работы будут ложиться в пыльный ящик стола.
P.S> извиняюсь за оффтопик, политику и прочее. Накипело.
А всё потому, что чиновникам нужна работа. Если чиновники не будут сочинять кучу постоянно меняющихся бумажек — их уволят. Чиновники этого не хотят, поэтому они будут делать всё, чтобы не уволили их. Соответственно, пока чиновники являются столпом этой системы и пока они диктуют свои правила, программисты (1Сники, признавайтесь) получают огромные выплаты из-за того, что каждый раз приходится обновлять базы и формы большому количеству предприятий. В следствии программистам тоже выгодно, что чиновники занимают свои места.
Если руководство страны примет решение заморозить хотя бы на 5 лет формы отчётности — часть компаний разорится, отсюда государство получит меньше налогов и поимеет проблем в виде необходимости в сокращении штата чиновников (ух, как чиновники не любят расставаться со своими креслами), ну и соответственно, наметится некоторая безработица у 1Сников, которым придётся переучиваться на что-нибудь другое, либо соглашаться на более низкую зарплату.
Соответственно, пока государство не перестроит подход по управлению собой (не думаю, что такое возможно), все подобные работы будут ложиться в пыльный ящик стола.
P.S> извиняюсь за оффтопик, политику и прочее. Накипело.
Причем тут чиновники? Нормальная бухгалтерская программа должна уметь выдавать на выходе отчеты по любым формам, независимо от того, что у нее внутри.
А кто занимается изменениями форм, введением новых форм и отчётов? Программа, конечно, может и уметь, но про новые формы просто не знать, так как её не обновили.
Именно. Поэтому на рынке выживает та программа, которую обновлять проще. И если какая-то желтая программа никак не умрет — это из-за ее гибкости, а не из-за заговора 1C-ников.
Если вдруг сделать программу, которая окажется на порядок лучше 1С — она взлетит, и никакие чиновники ей не помешают. Напротив, они и дадут стимул к сокращению расходов на обновление программы. Ну а 1С-ники переучатся.
Почему же такого до сих пор не случилось? Наверное, потому что нельзя так просто взять и сделать программу, которая была бы лучше 1С. И программа автора не взлетит именно по этой причине, а не из-за чиновников, жадных до работы.
Если вдруг сделать программу, которая окажется на порядок лучше 1С — она взлетит, и никакие чиновники ей не помешают. Напротив, они и дадут стимул к сокращению расходов на обновление программы. Ну а 1С-ники переучатся.
Почему же такого до сих пор не случилось? Наверное, потому что нельзя так просто взять и сделать программу, которая была бы лучше 1С. И программа автора не взлетит именно по этой причине, а не из-за чиновников, жадных до работы.
Абсолютно согласен!
Выход из этого замкнутого круга только один — сделать такой софт, который начался бы с индивидуального распространения, а потом уничтожил бы саму порочную систему. Ну, как Интернет: его совсем для других нужд изобретали, насколько мне известно, никто такого эффекта не ожидал. Если бы ожидали, прикрыли в зародыше.
Выход из этого замкнутого круга только один — сделать такой софт, который начался бы с индивидуального распространения, а потом уничтожил бы саму порочную систему. Ну, как Интернет: его совсем для других нужд изобретали, насколько мне известно, никто такого эффекта не ожидал. Если бы ожидали, прикрыли в зародыше.
Труд и подвижничество, безусловно, заслуживают уважения.
Автор идет по пути разработки универсальной системы компьютерного моделирования с бухгалтерским уклоном. Событийно-ориентированной. Только событие он называет проводкой. В событии, вероятно, соблюдается уравнение баланса стоимости. А обязательство заменяются планированием события на будущее время. Типа кредитовое сальдо на счете учета прибыли заменяется планированием события закрыть предприятие и вернуть все владельцам. Это понятно.
Но вот выдержит ли этот подход масштабирование? — Когда придется трансформировать партии в отдельные расходы и считать стоимость списания по средней (то есть ее уже не посчитать внутри трансформации). Когда нужно будет вести учет на многопередельном производстве и распределять затраты типа заработной платы. Когда нужно будет исправлять ошибки учета (а они бывают), отражать возвраты. Будет много однотипных вещей. Их понадобится группировать, а стоимость считать в регистрах. И получится что-то типа DAX или 1С.
Ну а глобализация этих моделей и построение мегамодели? Типа БухEverNote. Еще более сомнительно. Модель — основа управления. Если субъекты разные, то и модель у каждого своя. У каждого свои цели и свои критерии существенности. Зачем соединять учетные системы? Как тогда от жены прятать заначку? Учетный коммунизм? — Чур меня, проходили уже.
А вообще рекомендую автору поискать адептов на более специализированных ресурсах типа ИС.
Также порекомендую вот такую ссылочку. Автор также предлагает универсальную учетную модель. Правда, с опорой больше не на программирование, а на математику — теорию графов.
Ну и нужно попытаться на базе этого подхода сначала домашнюю бухгалтерию сделать. Если получится — можно будет двигаться дальше.
Автор идет по пути разработки универсальной системы компьютерного моделирования с бухгалтерским уклоном. Событийно-ориентированной. Только событие он называет проводкой. В событии, вероятно, соблюдается уравнение баланса стоимости. А обязательство заменяются планированием события на будущее время. Типа кредитовое сальдо на счете учета прибыли заменяется планированием события закрыть предприятие и вернуть все владельцам. Это понятно.
Но вот выдержит ли этот подход масштабирование? — Когда придется трансформировать партии в отдельные расходы и считать стоимость списания по средней (то есть ее уже не посчитать внутри трансформации). Когда нужно будет вести учет на многопередельном производстве и распределять затраты типа заработной платы. Когда нужно будет исправлять ошибки учета (а они бывают), отражать возвраты. Будет много однотипных вещей. Их понадобится группировать, а стоимость считать в регистрах. И получится что-то типа DAX или 1С.
Ну а глобализация этих моделей и построение мегамодели? Типа БухEverNote. Еще более сомнительно. Модель — основа управления. Если субъекты разные, то и модель у каждого своя. У каждого свои цели и свои критерии существенности. Зачем соединять учетные системы? Как тогда от жены прятать заначку? Учетный коммунизм? — Чур меня, проходили уже.
А вообще рекомендую автору поискать адептов на более специализированных ресурсах типа ИС.
Также порекомендую вот такую ссылочку. Автор также предлагает универсальную учетную модель. Правда, с опорой больше не на программирование, а на математику — теорию графов.
Ну и нужно попытаться на базе этого подхода сначала домашнюю бухгалтерию сделать. Если получится — можно будет двигаться дальше.
Видите ли, я не пытаюсь распространить свои идеи на крупные предприятия и вообще на предприятия. С моей точки зрения, юридические лица — это абсурд, поскольку в реальной экономике существуют лишь люди. Предприятия — это у них в головах, людям в мозги намертво вкомпостировали, чтобы не брыкались при распределении ресурсов по понятиям, а не по труду. Будем считать, что меня интересует исключительно теория. Да и версия 1.0 предназначена, собственно, для использования в качестве учебного пособия по экаунтологии.
Тогда непонятно, при чем тут вообще бухгалтерский учет. Индивидууму бухгалтерский учет не нужен в большинстве случаев. Он прекрасно обходится без него. Более простыми экономическими моделями. Рассуждать иначе — профессиональный эгоизм.
Например, одно из требований бухучета — непрерывность. А зачем она всем?
Подумал тут еще о том, зачем в вашей модели знак сальдо заменен понятиями прошлое — будущее. Это излишнее усложнение. В плоскую модель — остатки, спроецированные на настоящее, добавляется время. Ладно бы для прошлого. Для будущего — это чаще всего неразрешимая неопределенность. А платежи с оговоренными графиками оплаты: в два, три приема, регулярные платежи?
Например, одно из требований бухучета — непрерывность. А зачем она всем?
Подумал тут еще о том, зачем в вашей модели знак сальдо заменен понятиями прошлое — будущее. Это излишнее усложнение. В плоскую модель — остатки, спроецированные на настоящее, добавляется время. Ладно бы для прошлого. Для будущего — это чаще всего неразрешимая неопределенность. А платежи с оговоренными графиками оплаты: в два, три приема, регулярные платежи?
Бухгалтерский учет тут не при чем. А вот учет очень даже при чем: программа учетная…
Согласен. Попытки внедрить домашнюю бухгалтерию, еще в позапрошлом веке, окончились ничем. Поэтому вести ее намеренно не будут. А если данные начнут поступать в домашние базы, непосредственно из магазинов, почему бы и нет? Применительно ко мне самому: хочу я вести домашний учет личного имущества? Нет, мне в лом. А не против того, чтобы у меня под рукой был список моего личного имущества? Нет, совершенно не против. Полагаю, у других так же.
Вот уж действительно, зачем? По-моему, никому не нужна, как и другие так называемые принципы бухгалтерского учета, не выдерживающие никакой критики.
Не понимаю вас. Или вы меня не поняли.
Такая проблема действительно есть. В первой версии придется каждый платеж набивать отдельно. Если дойдет до второй версии, сделаю автоматическую операцию, концепции это не противоречит.
Индивидууму бухгалтерский учет не нужен в большинстве случаев. Он прекрасно обходится без него.
Согласен. Попытки внедрить домашнюю бухгалтерию, еще в позапрошлом веке, окончились ничем. Поэтому вести ее намеренно не будут. А если данные начнут поступать в домашние базы, непосредственно из магазинов, почему бы и нет? Применительно ко мне самому: хочу я вести домашний учет личного имущества? Нет, мне в лом. А не против того, чтобы у меня под рукой был список моего личного имущества? Нет, совершенно не против. Полагаю, у других так же.
Например, одно из требований бухучета — непрерывность. А зачем она всем?
Вот уж действительно, зачем? По-моему, никому не нужна, как и другие так называемые принципы бухгалтерского учета, не выдерживающие никакой критики.
Подумал тут еще о том, зачем в вашей модели знак сальдо заменен понятиями прошлое — будущее.
Не понимаю вас. Или вы меня не поняли.
А платежи с оговоренными графиками оплаты: в два, три приема, регулярные платежи?
Такая проблема действительно есть. В первой версии придется каждый платеж набивать отдельно. Если дойдет до второй версии, сделаю автоматическую операцию, концепции это не противоречит.
Я понял так: Вы храните только положительные — дебетовые сальдо, соответствующие вещам — активам. А если сальдо кредитовое — вместо того, чтобы просто обозначить пассив отрицательным сальдо на этом счете — вы учитываете пассивы — обязательства событиями в будущем — со временем и вероятностью. То есть вместо знака сальдо — время события. Это более сложная и не симметричная модель. Все равно вам потребуется хранить признак «будущее» или «прошлое» у остатка. Чтобы, например, просуммировать только обязательства. Ну и оставьте кредитовые счета, двойную запись, а время учитывайте факультативно.
Вероятность вообще не из той оперы понятие. Чтобы назвать что-то вероятностью, нужно обеспечить повторяемость оцениваемого явления. Вряд ли кто-либо сможет увидеть все варианты возможного будущего, чтобы посчитать долю «благоприятных» событий. Поэтому то, что вы назвали вероятностью — это что-то типа меры уверенности в выполнении обязательства. Эта величина вообще трудно измеримая. Зачем включать ее в модель, оперирующую стоимостью, измеряемую (чаще всего) с двумя знаками после запятой? То есть совсем другим порядком точности.
Вероятность вообще не из той оперы понятие. Чтобы назвать что-то вероятностью, нужно обеспечить повторяемость оцениваемого явления. Вряд ли кто-либо сможет увидеть все варианты возможного будущего, чтобы посчитать долю «благоприятных» событий. Поэтому то, что вы назвали вероятностью — это что-то типа меры уверенности в выполнении обязательства. Эта величина вообще трудно измеримая. Зачем включать ее в модель, оперирующую стоимостью, измеряемую (чаще всего) с двумя знаками после запятой? То есть совсем другим порядком точности.
Увы, про сальдо вы не так поняли — видимо, бухгалтерский шаблон сработал. У меня нет счетов в принципе, у меня отдельные объекты. У каждого объекта приход и расход по времени. Если расход не пустой, объект выбыл. Но выбыть объект может будущей датой, к примеру: поступил 1 декабря, выбыл 10 декабря. Если сегодня 2 декабря, то выбытие данного объекта — обязательство. С бухгалтерией ничего общего.
С определением вероятности согласен. Мне она понадобилась для одного: чтобы в отчетах показывать обязательства по уменьшенной стоимости.
С определением вероятности согласен. Мне она понадобилась для одного: чтобы в отчетах показывать обязательства по уменьшенной стоимости.
Как по мне — вы переизобрели MRP.
Я с этой концепцией даже не знаком. Вряд ли…
Знакомьтесь и удивляйтесь :)
ru.wikipedia.org/wiki/MRP_II
ru.wikipedia.org/wiki/MRP_II
Да я уже посмотрел, спасибо. Ничего общего.
А я вот наоборот. Много общего увидел.
Вы просто отошли от бухгалтерии в сторону логистики (изобрели свои термины и правила).
Делаем следующие замены:
Вещь -> Материал
Действие -> Движение материала
Обязательство -> Планирование поставок (и платежей в MRP II)
Вероятности -> Оценка рисков (только не пальцем в небо, а с помощью методик)
Генерация отчетов — тут даже переименовывать ничего не надо, оно и так все есть
И получается, что ЭкаунтоЛогика -> Учет и планирование в логистике.
Вы просто отошли от бухгалтерии в сторону логистики (изобрели свои термины и правила).
Делаем следующие замены:
Вещь -> Материал
Действие -> Движение материала
Обязательство -> Планирование поставок (и платежей в MRP II)
Вероятности -> Оценка рисков (только не пальцем в небо, а с помощью методик)
Генерация отчетов — тут даже переименовывать ничего не надо, оно и так все есть
И получается, что ЭкаунтоЛогика -> Учет и планирование в логистике.
Все учетные программы занимаются одним и тем же, только по-разному. Вы сравнили термины, но ни словом не обмолвились о методе. Дело-то именно в методике учета (в том, каким способом осуществляется учет и планирование — в логистике или где угодно)… А то ведь можно подумать, что ваша MRP именно тем и хороша, что вещи называет материалами, операции — движениями, и т.д.
К слову:
К слову:
- обязательство у меня — не вполне планирование поставок (обязательство как будущий объект может вообще не иметь отношения к поставкам),
- никакие методики оценки вероятности не обеспечат стопроцентного угадывания. К тому же ничто не мешает пользователю моей программы оценить вероятность по известной ему методике, хотя бы по вашей. У меня программа для учета, а не для бизнес-аналитики,
- генерация отчетов — общеупотребительный термин, по-моему.
Я бы не хотел сравнивать. Сравнил не просто термины, а термины, применимые в конкретном программном обеспечении, которое реализует вами описанный функционал (причем годов эдак с 70-x). Вы почти в каждом комментарии пишете об особом методе. В чем же заключается ваш метод (достаточно ссылки на публикацию, я сам постараюсь разобраться), и что в нем особого (нового)?
Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке). Обещание жениться к методологии движения материала не применимо :)
По поводу (У меня программа для учета, а не для бизнес-аналитики) вы сами себя загоняете в угол. Любая программа учета — это аналитика. Они собственно для аналитики и создаются. Посмотреть наличие товара на складе на дату, посмотреть движение материалов за интервал времени, посмотреть объемы поставок по контрагентам — все это аналитика. Без этого функционала — ваша программа не будет отличаться от ведения приход/расход кладовщиком в тетрадке, соответственно будет не нужна.
Про генерацию отчетов неправильно изъяснился. Имел ввиду, что все эти отчеты в методологии MRP давно известны (см. предыдущий абзац).
Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке). Обещание жениться к методологии движения материала не применимо :)
По поводу (У меня программа для учета, а не для бизнес-аналитики) вы сами себя загоняете в угол. Любая программа учета — это аналитика. Они собственно для аналитики и создаются. Посмотреть наличие товара на складе на дату, посмотреть движение материалов за интервал времени, посмотреть объемы поставок по контрагентам — все это аналитика. Без этого функционала — ваша программа не будет отличаться от ведения приход/расход кладовщиком в тетрадке, соответственно будет не нужна.
Про генерацию отчетов неправильно изъяснился. Имел ввиду, что все эти отчеты в методологии MRP давно известны (см. предыдущий абзац).
В чем же заключается ваш метод (достаточно ссылки на публикацию, я сам постараюсь разобраться), и что в нем особого (нового)?
Дать ссылку на текущий пост? :)
Можете зайти в мой профиль, там указание на целый сайт, посвященный экаунтологии.
Обязательство у вас понятие абстрактное — неживое. Как только вы его пытаетесь применить в программе, оно оказывается еще как формализуемым: либо поставка, либо выполнение работ, либо финансовое (что в принципе можно свести к поставке).
Насчет живое-неживое спорить не буду, тем более что с MRP не знаком. Возможно, там оно и живое… Что касается дальнейших ваших слов, они свидетельствуют о том, что вы моей методой не владеете. «Либо поставка, либо выполнение работ, либо финансовое»? А вот и нет. У меня обязательство — понятие более широкое, чем юридическое определение: это любой будущий объект (любое событие, которое произойдет в будущем). К примеру, ожидается, что через месяц вещь будет выкинута на свалку. Данное предположение, если его зарегистрировать, тоже обязательство (как это трактуется в юриспруденции, мне известно, можете не объяснять), при этом абсолютно формализованное.
С вашей трактовкой аналитики согласен.
все эти отчеты в методологии MRP давно известны
Оборотно-сальдовые ведомости и в бухгалтерии давно известны, они никак не новации MRP.
О том, что я какие-то новые формы отчетности придумал, ни словом не обмолвился. Нет такого: одно старье.
Дать ссылку на текущий пост? :)
Зря вы так… Посмотрите сколько к вам вопросов в комментариях. В данном посте вам не очень удалось описать методологию.
Прочитал описание вот тут: accountology.ucoz.ru/faq/1-1#1, как по мне — так это больше философские размышления о видении правильного учета, описанные художественным языком. Никакого формализма, никаких правил, приемов и способов… Методологии, практической методологии, как таковой, так и не смог увидеть/понять. Хотя, причина этого может быть в математическом складе ума и попытках структурировать и систематизировать знания.
К примеру, ожидается, что через месяц вещь будет выкинута на свалку.
Так это совершенно не контрпример к моим примерам. В MRP есть понятие списания — поставка, или грамотнее — движение материала, (например, при истечении срока годности). Причем это не перевод наличия в ноль, а даже в минус, вследствие затрат на утилизацию… И выбытие, списание, делается все тем же видом движения материала (действием по вашей терминологии).
Обижать никого не хотел, извините. Сами напросились.
Возможно, не мне судить. Я назвал два главных отличия: учет обязательств в качестве будущих объектов и формализацию доходов-расходов.
Про доходы-расходы слишком долго, но вот про обязательства. Зарегистрирована вещь с датой прихода 10 апреля. Это обязательство или не обязательство? В зависимости от того, какое сегодня число: если 1 апреля, то обязательство, а если 15 апреля, то нет (тогда данная вещь — прошлая). Никаких других различий в регистрации нет, все зависит от текущей даты.
Ну, значит, здесь наблюдается некоторое пересечение. Но вы поймите, различия нужно искать не в поставленных задачах, которые по определению одинаковы, а в способах решения — методике! Мне все кажется: вы путаете задачи и методы. Вообще, наш разговор напоминает общение глухонемых: вы владеете MRP, но не владеете экаунтологией, я наоборот.
А вы хотите во вводной статье сразу и приемы, и правила, и способы?.. А дальше лениво почитать? Да, по причине экономического образования изложение у меня не математическое. Однако не думаю, что обилие формул сразу приводит к истине, нередко и отдаляет от нее.
В данном посте вам не очень удалось описать методологию.
Возможно, не мне судить. Я назвал два главных отличия: учет обязательств в качестве будущих объектов и формализацию доходов-расходов.
Про доходы-расходы слишком долго, но вот про обязательства. Зарегистрирована вещь с датой прихода 10 апреля. Это обязательство или не обязательство? В зависимости от того, какое сегодня число: если 1 апреля, то обязательство, а если 15 апреля, то нет (тогда данная вещь — прошлая). Никаких других различий в регистрации нет, все зависит от текущей даты.
И выбытие, списание, делается все тем же видом движения материала (действием по вашей терминологии).
Ну, значит, здесь наблюдается некоторое пересечение. Но вы поймите, различия нужно искать не в поставленных задачах, которые по определению одинаковы, а в способах решения — методике! Мне все кажется: вы путаете задачи и методы. Вообще, наш разговор напоминает общение глухонемых: вы владеете MRP, но не владеете экаунтологией, я наоборот.
Никакого формализма, никаких правил, приемов и способов…
А вы хотите во вводной статье сразу и приемы, и правила, и способы?.. А дальше лениво почитать? Да, по причине экономического образования изложение у меня не математическое. Однако не думаю, что обилие формул сразу приводит к истине, нередко и отдаляет от нее.
вы владеете MRP, но не владеете экаунтологией, я наоборот.
Я назвал два главных отличия: учет обязательств в качестве будущих объектов и формализацию доходов-расходов.
Это отличие от бухгалтерии или от MRP? Я же писал в самом начале
вы переизобрели MRP
в том, что касается методологии, а не философском видении.
А дальше лениво почитать?
С удовольствием, но не нашел. Киньте, пожалуйста, ссылку на практическую методологию.
Это отличие от бухгалтерии. Как организован учет в MRP, мне неизвестно.
Вы прочитали первую вводную статью в разделе «Экаунтология». Вслед за ней идет еще много-много других статей. Либо по ссылкам на правой панели скачайте файлы «Принципиальная схема Мироздания» и «Экономические законы природы». Хотя там, с вашей точки зрения, будет одна вода и никакой практики. Еще могу порекомендовать эту книгу: «Экаунтология: компьютерный учет вместо бухгалтерского». М., 2012. В ней система рассмотрена в подробностях применительно к компьютерным базам данных (хотя, предупрежу сразу, крайне неудачно: программисты сильно возмущаются, когда читают). А вообще, практическая методология реализована в программе, тестируйте ее. Программа для того и написана. Ну в самом-то деле…
С удовольствием, но не нашел.
Вы прочитали первую вводную статью в разделе «Экаунтология». Вслед за ней идет еще много-много других статей. Либо по ссылкам на правой панели скачайте файлы «Принципиальная схема Мироздания» и «Экономические законы природы». Хотя там, с вашей точки зрения, будет одна вода и никакой практики. Еще могу порекомендовать эту книгу: «Экаунтология: компьютерный учет вместо бухгалтерского». М., 2012. В ней система рассмотрена в подробностях применительно к компьютерным базам данных (хотя, предупрежу сразу, крайне неудачно: программисты сильно возмущаются, когда читают). А вообще, практическая методология реализована в программе, тестируйте ее. Программа для того и написана. Ну в самом-то деле…
Тут выше эпичный тред с lair. Не ввязываясь в ценность научной составляющей я присоединюсь к вопросу: в чем ценность этого подхода учета?
Пока сама система похожа на обычный складской учет с функцией «объединения дублей». Или, обычный забалансовый учет. Но, возможно, в концепции есть идея, которая должна получить развитие. Или есть важные отличия, на которые нужно обратить внимание?
Пока сама система похожа на обычный складской учет с функцией «объединения дублей». Или, обычный забалансовый учет. Но, возможно, в концепции есть идея, которая должна получить развитие. Или есть важные отличия, на которые нужно обратить внимание?
Никак не уловлю отличий от БУ(
Можете пояснить?
Скажем напишу я сейчас софтинку, которая позволит забивать документы прихода и расхода.
Что именно пришло или ушло выбираю из справочника при заведении(существующее или добавляю новую запись).
Если поставлю дату документа прошлым числом — действие совершенное, будущим — обязательство.
Вот вам упрощенный донельзя БУ(тетрадка кладовщика только с возможностью построения отчетов).
Можете пояснить?
Скажем напишу я сейчас софтинку, которая позволит забивать документы прихода и расхода.
Что именно пришло или ушло выбираю из справочника при заведении(существующее или добавляю новую запись).
Если поставлю дату документа прошлым числом — действие совершенное, будущим — обязательство.
Вот вам упрощенный донельзя БУ(тетрадка кладовщика только с возможностью построения отчетов).
Мне казалось, я многократно объяснил. Если не поняли, значит я плохо объясняю. Как умею, лучше вряд ли смогу…
Система, которую вы описали, — это моя система (в чрезвычайно упрощенном представлении, конечно). В бухгалтерии не так: бухгалтер регистрирует обязательство сегодняшним числом, а не будущим: ему совершенно до лампочки, когда предполагается погашение обязательства (разве только для классификации обязательств на кратко- и долгосрочные). Также до лампочки, будет обязательство погашено или нет (если только в целях его списания за баланс в некоторых ситуациях, ну или для поступления денег на счета). А у меня обязательства придется отслеживать, как в жизни: не дай Бог проворонить дату погашения, придут кредиторы и начнут права качать (применительно к моей учетной системе — обязательство превратится в свершившийся факт).
Система, которую вы описали, — это моя система (в чрезвычайно упрощенном представлении, конечно). В бухгалтерии не так: бухгалтер регистрирует обязательство сегодняшним числом, а не будущим: ему совершенно до лампочки, когда предполагается погашение обязательства (разве только для классификации обязательств на кратко- и долгосрочные). Также до лампочки, будет обязательство погашено или нет (если только в целях его списания за баланс в некоторых ситуациях, ну или для поступления денег на счета). А у меня обязательства придется отслеживать, как в жизни: не дай Бог проворонить дату погашения, придут кредиторы и начнут права качать (применительно к моей учетной системе — обязательство превратится в свершившийся факт).
Значит у меня в компании используется ваш учет :)
У нас в порядке вещей регистрировать приход будущим числом, а по факту приемки товара уже корректировать его…
У нас в порядке вещей регистрировать приход будущим числом, а по факту приемки товара уже корректировать его…
Если вы не придумываете, это очень круто. Настолько, что с трудом верится…
Хотя учет обязательств — один из аспектов моей системы, существуют другие важные нюансы.
В любом случае данный учет обязательств — не бухгалтерский.
Хотя учет обязательств — один из аспектов моей системы, существуют другие важные нюансы.
В любом случае данный учет обязательств — не бухгалтерский.
Снова наткнулся на данную публикацию, вспомнил что так и не ответил.
Проанализировал нашу систему учета и пришел к выводу что не совсем корректно описал процесс.
Учет у нас существует в двух уровнях:
1. Реальная учетная система(самописная, от собственного департамента разработки), распределенная БД, основные узлы в головной компании и складах, которые позиционируются как собственные поставщики. Вторичные узлы на объектах обслуживания(собственно в магазинах). Именно здесь все происходит естественным образом — автозаказ генерирует документ заказа товара, из него генерируется ожидаемый приход. По факту прихода происходит приемка товара и, в случае расхождения плана и факта, генерируются документы на недовоз\перевоз разницы.
2. Бухгалтерия. Вещь в себе. Поднята на доработанной 1С, через веб-сервис обменивается с основным узлом основной БД. Армия бухгалтеров подгоняет план под факт для отчетности. Генерирует кучи проводок, работают с реальными и синтетическими счетами.
Проанализировал нашу систему учета и пришел к выводу что не совсем корректно описал процесс.
Учет у нас существует в двух уровнях:
1. Реальная учетная система(самописная, от собственного департамента разработки), распределенная БД, основные узлы в головной компании и складах, которые позиционируются как собственные поставщики. Вторичные узлы на объектах обслуживания(собственно в магазинах). Именно здесь все происходит естественным образом — автозаказ генерирует документ заказа товара, из него генерируется ожидаемый приход. По факту прихода происходит приемка товара и, в случае расхождения плана и факта, генерируются документы на недовоз\перевоз разницы.
2. Бухгалтерия. Вещь в себе. Поднята на доработанной 1С, через веб-сервис обменивается с основным узлом основной БД. Армия бухгалтеров подгоняет план под факт для отчетности. Генерирует кучи проводок, работают с реальными и синтетическими счетами.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
ЭкаунтоЛогика 1.0