Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 107
Выше описанное нужно реализовывать как государственную систему товаро-оборота и учета или как частно-государственное партнерство (ассоциация банков + гос. поддержка), как частный проект это почти неподъемная задача.
Инвестиции в такой проект будут гигантскими (вы почитайте как люди дисконтные системы с учетом купли/продажи реализовывают, и уже объем работы нереальный, а тут такое).
Выгодопреобретателей у этой сети два — создатель и государство, больше она никому не нужна по сути.
— Потребителю до лампочки, как и у кого куплен оптом товар, который он приобрел.
— Организациям еще один инструмент отчетности, который нужно внедрять и лишний способ контроля их продаж со стороны государства.
— Банкам и оптовикам, еще одни проблемы с поддержкой системы, еще один способ государства контролировать их деятельность (соответственно, меньше возможностей «оптимизации» налогов).
С этимпроектом нужно идти в думу/правительство/сбербанк, а не на Хабр.
Инвестиции в такой проект будут гигантскими (вы почитайте как люди дисконтные системы с учетом купли/продажи реализовывают, и уже объем работы нереальный, а тут такое).
Выгодопреобретателей у этой сети два — создатель и государство, больше она никому не нужна по сути.
— Потребителю до лампочки, как и у кого куплен оптом товар, который он приобрел.
— Организациям еще один инструмент отчетности, который нужно внедрять и лишний способ контроля их продаж со стороны государства.
— Банкам и оптовикам, еще одни проблемы с поддержкой системы, еще один способ государства контролировать их деятельность (соответственно, меньше возможностей «оптимизации» налогов).
С этимпроектом нужно идти в думу/правительство/сбербанк, а не на Хабр.
В таком случае интернет — тоже отличный способ контролировать общение: удобней же читать файлы, чем перлюстрировать письма.
Государству подобная система не нужна, ему нужно другое. И по поводу гигантских вложений вы тоже заблуждаетесь: подумаешь, маленькая учетная программка плюс небольшой сервис, обрабатывающий ссылки на передаваемые между пользователями объектами.
Государству подобная система не нужна, ему нужно другое. И по поводу гигантских вложений вы тоже заблуждаетесь: подумаешь, маленькая учетная программка плюс небольшой сервис, обрабатывающий ссылки на передаваемые между пользователями объектами.
Вот с этого места поподробней.
Что есть «обрабатывающий ссылки на передаваемые объекты»
В чем будет заключаться суть этих обработок?
Это важно!
Что есть «обрабатывающий ссылки на передаваемые объекты»
В чем будет заключаться суть этих обработок?
Это важно!
Есть две независимые программки. В одной регистрируется передача объекта — его расход. Программа связывается с сервером (сайтом) производителя, производитель посылает сообщение второй программе. Если второй пользователь соглашается принять объект, у него регистрируется приход данного объекта, если нет — расход объекта в первой программе считается несостоявшимся. Ссылка реализуется через одинаковый ID в обеих базах, то есть переданный объект первым пользователем — это принятый объект вторым пользователем.
То есть сайт нужен для согласования передаваемых-принимаемых объектов, установления между ними взаимосвязей.
Так приблизительно.
То есть сайт нужен для согласования передаваемых-принимаемых объектов, установления между ними взаимосвязей.
Так приблизительно.
Ситуация с этим ID будет такая же как сейчас со штрих-кодом, который по сути и является оффлайновым аналогом ID.
Согласен с тем, что штрих-код является оффлайновым аналогом ID, но не понял, какая сейчас с ним ситуация.
Куча стандартов и видов. Есть несколько крупных мировых организаций, на вроде GS1, и помельче локальных (азиатских например).
В итоге всё равно штрихкод не унифицирован. Сейчас идёт ему активная замена RFID метки, но сами значения, которые пишутся в эту метку опять же считаются на основе штрихкодов.
Это всё к тому, что уже на этапе выбора GUID могут возникнуть серьезные трудности внедрения.
В итоге всё равно штрихкод не унифицирован. Сейчас идёт ему активная замена RFID метки, но сами значения, которые пишутся в эту метку опять же считаются на основе штрихкодов.
Это всё к тому, что уже на этапе выбора GUID могут возникнуть серьезные трудности внедрения.
Тоже была подобная идея. Правда, на мой взгляд конечному потребителю такая информация и учёт всего ни к чему. Главное, это связать в такую сеть предприятия хотя бы нашей страны, например, с помощью какого-нибудь плагина для 1С Бухгалтерии.
Такая сеть являлась бы одним из необходимых условий перехода к настоящей плановой экономике.
Такая сеть являлась бы одним из необходимых условий перехода к настоящей плановой экономике.
Существующие программы связывать воедино можно, но бессмысленно, т.к. применяемая методология (двойная запись) не позволит проследить историю объекта.
Самая простая альтернатива — открыть производственные базы данных для всех интересующихся, то есть отменить коммерческую тайну. Но на это никто не пойдет.
Самая простая альтернатива — открыть производственные базы данных для всех интересующихся, то есть отменить коммерческую тайну. Но на это никто не пойдет.
Я, конечно, понимаю, что гораздо легче, когда все поставят себе такую программку и они начнут учитывать всё подряд, но что при этом будет с существующим, т.е. произведённым до этого момента товаром?
Все равно ведь его надо как-то учитывать.
Мир под вас не прогнётся. На мой взгляд, вам нужно сосредоточиться на том, как можно модифицировать существующие учётные системы. Например, чтобы при продаже товара из одной базы 1С, информацию о нём можно было передать базе 1С покупателя или вашей программе если покупатель — частное лицо.
И кстати, с физическим товаром ещё более-менее понятно, а как быть с услугами?
Все равно ведь его надо как-то учитывать.
Мир под вас не прогнётся. На мой взгляд, вам нужно сосредоточиться на том, как можно модифицировать существующие учётные системы. Например, чтобы при продаже товара из одной базы 1С, информацию о нём можно было передать базе 1С покупателя или вашей программе если покупатель — частное лицо.
И кстати, с физическим товаром ещё более-менее понятно, а как быть с услугами?
Модифицировать существующие учетные программы невозможно, т.к. они основаны на ошибочной методологии — двойной записи. Возможности системы зависят от заложенной в ней методологии.
Что такое услуги и как их учитывать, мне известно, я же методолог. Долго объяснять. Если коротко, услуги — это действия работников: учитывайте работников, тогда будут учтены услуги. Просто в официальной бухгалтерии работники не учитываются (учитывается выплачиваемая им зарплата, но не сами работники).
Что такое услуги и как их учитывать, мне известно, я же методолог. Долго объяснять. Если коротко, услуги — это действия работников: учитывайте работников, тогда будут учтены услуги. Просто в официальной бухгалтерии работники не учитываются (учитывается выплачиваемая им зарплата, но не сами работники).
Извините, я не бухгалтер, но я работал с базами данных, в которых в том числе, ведётся и вся ваша бухгалтерия. И я не понимаю чем вам мешает двойная запись?
На мой взгляд основной проблемой является не двойная запись, а различие в наименование номенклатуры в базах данных разных фирм.
Я думаю вопросы по объединения нескольких баз разных предприятий в одну возникали далеко не один раз, например, во время слияний и поглощений. Посмотрите как там решались подобные вопросы.
На мой взгляд основной проблемой является не двойная запись, а различие в наименование номенклатуры в базах данных разных фирм.
Я думаю вопросы по объединения нескольких баз разных предприятий в одну возникали далеко не один раз, например, во время слияний и поглощений. Посмотрите как там решались подобные вопросы.
Речь не об объединении нескольких баз в одну (консолидации), а о том,, что я называю вложенностью. В бухгалтерском учете аналогичный термин отсутствует.
Вы извините, но в комментариях не могу объяснить, чем плоха двойная запись. В ней есть рациональное начало, но в том виде, в котором применяется, она не соответствует компьютерному учету. Это слишком специальный разговор.
Вы извините, но в комментариях не могу объяснить, чем плоха двойная запись. В ней есть рациональное начало, но в том виде, в котором применяется, она не соответствует компьютерному учету. Это слишком специальный разговор.
Я не про консолидацию. Вам ведь по большому счёту нужно:
Организовать взаимодействие между БД разных предприятий, чтобы:
1. Номенклатура товаров и услуг в разных БД совпадала, либо имелась бы таблица сопоставления.
2. При обмене товарами и услугами, передавалась ссылка на запись о данном товаре от БД продавца к БД покупателя, что обеспечивало бы ваш принцип «вложенности».
3. Информация о проданном товаре не удалялась бы.
4. Доступ на чтение БД был у всех заинтересованных лиц, или по крайней мере у всех торговых партнёров.
Организовать взаимодействие между БД разных предприятий, чтобы:
1. Номенклатура товаров и услуг в разных БД совпадала, либо имелась бы таблица сопоставления.
2. При обмене товарами и услугами, передавалась ссылка на запись о данном товаре от БД продавца к БД покупателя, что обеспечивало бы ваш принцип «вложенности».
3. Информация о проданном товаре не удалялась бы.
4. Доступ на чтение БД был у всех заинтересованных лиц, или по крайней мере у всех торговых партнёров.
Закономерные вопросы.
Отвечаю по пунктам:
1. Идея немного не такая. Есть ограниченное число полей, в которых каждый из пользователей характеризует объекты. Данные признаки могут совпадать, а могут не совпадать. Но поскольку переданный объект, учтенный в разных базах, имеет один идентификатор (за что отвечает сервис производителя), то по ссылке можно перейти в базу прежнего владельца и (в той же программе!) просмотреть, как он учитывал данный объект.
2. Ну да. Ссылка обеспечивается одинаковым идентификатором переданного объекта в разных базах, как я сказал.
3. На программном уровне должен существовать запрет на удаление переданных объектов. Конечно, нельзя запретить пользователю влезть в базу в другом софте и удалить запись. Добровольное это дело, короче.
4. Передача объекта означает доступ в базу (к записям, относящимся к переданному объекту).
Отвечаю по пунктам:
1. Идея немного не такая. Есть ограниченное число полей, в которых каждый из пользователей характеризует объекты. Данные признаки могут совпадать, а могут не совпадать. Но поскольку переданный объект, учтенный в разных базах, имеет один идентификатор (за что отвечает сервис производителя), то по ссылке можно перейти в базу прежнего владельца и (в той же программе!) просмотреть, как он учитывал данный объект.
2. Ну да. Ссылка обеспечивается одинаковым идентификатором переданного объекта в разных базах, как я сказал.
3. На программном уровне должен существовать запрет на удаление переданных объектов. Конечно, нельзя запретить пользователю влезть в базу в другом софте и удалить запись. Добровольное это дело, короче.
4. Передача объекта означает доступ в базу (к записям, относящимся к переданному объекту).
«Закономерные вопросы.»
Это были не вопросы.
Подытожим:
Программа-агент должна:
1. Модифицировать БД так, чтобы она присваивала каждому товару GUID.
2. При продаже товара передавать GUID в БД покупателя.
3. При получении запроса с GUID'ом, передавать удобоваримую информацию о соответствующем товаре (что вообще-то не так просто).
В итоге я так и не понял чем вам мешает двойная запись.
Вам нужно, для начала описать протокол взаимодействие вашей программы-агента друг с другом и с локальной БД.
Потом опубликовать его, авось кто-то и реализует.
Это были не вопросы.
Подытожим:
Программа-агент должна:
1. Модифицировать БД так, чтобы она присваивала каждому товару GUID.
2. При продаже товара передавать GUID в БД покупателя.
3. При получении запроса с GUID'ом, передавать удобоваримую информацию о соответствующем товаре (что вообще-то не так просто).
В итоге я так и не понял чем вам мешает двойная запись.
Вам нужно, для начала описать протокол взаимодействие вашей программы-агента друг с другом и с локальной БД.
Потом опубликовать его, авось кто-то и реализует.
Да, как-то так.
Двойная запись не подходит по многим причинам, в которые нет смысла вдаваться. Достаточно того, что GUID-ы в ней не присвоить, насколько я понимаю, в ней другая система идентификации.
Двойная запись не подходит по многим причинам, в которые нет смысла вдаваться. Достаточно того, что GUID-ы в ней не присвоить, насколько я понимаю, в ней другая система идентификации.
GUID'ы присваиваются в рамках СУБД. В этом как раз ничего принципиально сложного нет.
Мне сложно с вами спорить. Я только сейчас посмотрел, что такое GUID, а вы абсолютно не представляете двойной бухгалтерии.
«вы абсолютно не представляете двойной бухгалтерии»
наверное, всё-таки двойной записи.
В общем я описал вам способ реализации вашей идеи поверх существующей инфраструктуры за исключением пункта «Решение задачи облегчается тем, что структура баз у всех пользователей единая. „
Ну т.е. у конечных пользователей структура БД может быть и одинаковой, но вот на предприятиях на это рассчитывать бессмысленно.
Но если вы хотите заменить двойную запись на свою методологию, то тут шансов нет. Выгоды для конечного предприятия от такого перехода не будет.
наверное, всё-таки двойной записи.
В общем я описал вам способ реализации вашей идеи поверх существующей инфраструктуры за исключением пункта «Решение задачи облегчается тем, что структура баз у всех пользователей единая. „
Ну т.е. у конечных пользователей структура БД может быть и одинаковой, но вот на предприятиях на это рассчитывать бессмысленно.
Но если вы хотите заменить двойную запись на свою методологию, то тут шансов нет. Выгоды для конечного предприятия от такого перехода не будет.
Структура базы данных — в том смысле, что программа одна, и методология одна, а пользователи могут характеризовать объекты разными свойствами.
Я бы не против реализовать идею поверх существующей инфраструктуры, но это невозможно, к сожалению.
И поверьте, не все преобразования в этом мире определяются «выгодой конечного предприятия».
Я бы не против реализовать идею поверх существующей инфраструктуры, но это невозможно, к сожалению.
И поверьте, не все преобразования в этом мире определяются «выгодой конечного предприятия».
«Структура базы данных — в том смысле, что программа одна, и методология одна, а пользователи могут характеризовать объекты разными свойствами.»
Я вам пытаюсь объяснить, что нельзя заставить крупную фирму поменять структуру своей БД, на ту что предлагаете вы, ибо она убога и подходит только для обычного потребителя. И переход на которую только в разы ухудшит работу фирмы.
«И поверьте, не все преобразования в этом мире определяются «выгодой конечного предприятия».»
Вы не надеетесь, ни на государство, на на выгоду конечного предприятие, которое и должно внедрять вашу методологию. Так на что вы надеетесь?
Я вам пытаюсь объяснить, что нельзя заставить крупную фирму поменять структуру своей БД, на ту что предлагаете вы, ибо она убога и подходит только для обычного потребителя. И переход на которую только в разы ухудшит работу фирмы.
«И поверьте, не все преобразования в этом мире определяются «выгодой конечного предприятия».»
Вы не надеетесь, ни на государство, на на выгоду конечного предприятие, которое и должно внедрять вашу методологию. Так на что вы надеетесь?
Я не пытаюсь заставить крупную фирму менять свои базы данных, у меня силенки не те. Я пытаюсь вбросить в мир идею, которая сама за себя постоять сможет (если она та, за кого я ее полагаю).
Про убогую структуру баз я бы не стал так категорично утверждать. Вы с ТЗ успели ознакомиться и по ТЗ установили,, что структура убогая?
А по поводу конечной выгоды… Кто там открыл микробов, не помню? Представьте, что ему говорят: а в чем выгода от вашего открытия? Какие-то крохотные существа, которые проникают в организм и заражают его? Да с ними же невозможно бороться? Кому это нужно?
Идеи определяются не выгодой от них, а мироустройством. Человеку всегда интересно узнать, как мир устроен и как он может быть устроен.
Про убогую структуру баз я бы не стал так категорично утверждать. Вы с ТЗ успели ознакомиться и по ТЗ установили,, что структура убогая?
А по поводу конечной выгоды… Кто там открыл микробов, не помню? Представьте, что ему говорят: а в чем выгода от вашего открытия? Какие-то крохотные существа, которые проникают в организм и заражают его? Да с ними же невозможно бороться? Кому это нужно?
Идеи определяются не выгодой от них, а мироустройством. Человеку всегда интересно узнать, как мир устроен и как он может быть устроен.
«Про убогую структуру баз я бы не стал так категорично утверждать. Вы с ТЗ успели ознакомиться и по ТЗ установили,, что структура убогая?»
А что? В ТЗ вы описали идеальную структуру БД которая одинаково эффективна для всех бизнес процессов?
«Идеи определяются не выгодой от них, а мироустройством.»
А реализация идеи именно от выгоды.
А что? В ТЗ вы описали идеальную структуру БД которая одинаково эффективна для всех бизнес процессов?
«Идеи определяются не выгодой от них, а мироустройством.»
А реализация идеи именно от выгоды.
Я не описывал структуру баз данных применительно к конкретным бизнес-процессам, я всего лишь попытался разработать структуру баз данных,, пригодную для компьютерного учета вещей, другими словами разработать методологию компьютерного учета. Имеющиеся методологии — не компьютерные или не вполне компьютерные, в силу разных причин.
Да, реализация идей определяется выгодой от них. Как правило. Но не всегда, особенно на начальном этапе реализации, когда установить будущую выгоду от реализации практически невозможно.
Да, реализация идей определяется выгодой от них. Как правило. Но не всегда, особенно на начальном этапе реализации, когда установить будущую выгоду от реализации практически невозможно.
Если не будет выходы пипл хавать не будет, а значить и идея встанет на длинную полку памятников утопичным идеям и заоблачным проектам.
Есть очень хорошая пропорция у маркетологов:.если у тебя есть идея, то у тебя есть 1 рубль, если ты из идеи сделал продукт, то у тебя есть 10 рублей, а если ты смог продать этот продукт потребителям, то у тебя есть 100 рублей.
Это пропорция важности и отношения.
По поводу выгоды конечного потребителя! Она должна быть в любом случае. Т.е. продукт выросший из идеи должен нести пользу. А вот как раз продать, это сделать так, чтобы эту пользу оценили потребители. Т.е. продукт приобрел бы для них ценность.
Вы рассуждаете об идее глобальной учетной системы, но плюете даже на добротное обоснование выгодности, не говоря уже про этап убеждения потребителей в этом.
Пока видно так. Удобно, если оформленная транзакция в одной базе согласовывается автоматически с другой, это большая польза. И удобно, если не надо будет заносить в следующей базе транзакцию можно будет ее подтвердить, ну и удобно если видна история объекта, ведь именно эту историю называет автор вложенностью. Это я перечислил выгоды, которые получит конечный потребитель, если будет реализован продукт и проект из этой идеи. Но этого не достаточно. Пока вижу только продукт, некую программу, способную интегрироваться с существующими системами с целью автоматизации согласования взаиморасчетов. Особенно это может быть ценно в больших холдингах, с большим количеством внутрихолдинговых операций.
Есть очень хорошая пропорция у маркетологов:.если у тебя есть идея, то у тебя есть 1 рубль, если ты из идеи сделал продукт, то у тебя есть 10 рублей, а если ты смог продать этот продукт потребителям, то у тебя есть 100 рублей.
Это пропорция важности и отношения.
По поводу выгоды конечного потребителя! Она должна быть в любом случае. Т.е. продукт выросший из идеи должен нести пользу. А вот как раз продать, это сделать так, чтобы эту пользу оценили потребители. Т.е. продукт приобрел бы для них ценность.
Вы рассуждаете об идее глобальной учетной системы, но плюете даже на добротное обоснование выгодности, не говоря уже про этап убеждения потребителей в этом.
Пока видно так. Удобно, если оформленная транзакция в одной базе согласовывается автоматически с другой, это большая польза. И удобно, если не надо будет заносить в следующей базе транзакцию можно будет ее подтвердить, ну и удобно если видна история объекта, ведь именно эту историю называет автор вложенностью. Это я перечислил выгоды, которые получит конечный потребитель, если будет реализован продукт и проект из этой идеи. Но этого не достаточно. Пока вижу только продукт, некую программу, способную интегрироваться с существующими системами с целью автоматизации согласования взаиморасчетов. Особенно это может быть ценно в больших холдингах, с большим количеством внутрихолдинговых операций.
Для этого есть субконто
А вот надо вдаваться, поскольку это камень предкновения.
Практика подсказывает, что не должно быть никаких программных запретов на удаление. Всего не запретишь, есть права администратора, который все что угодно может сделать, или период закрывать??? Опять же, Вы понимаете о чем я.
Доступ к базам???, к записям относящимся к переданному объекту??? Трудно себе это представить!!!
Возможно только так, при передаче объекта вся история переезжает вместе с объектом в новую базу, как история по предыдущему и более раннему владельцу. С доступами вы тут перегибаете.
Доступ к базам???, к записям относящимся к переданному объекту??? Трудно себе это представить!!!
Возможно только так, при передаче объекта вся история переезжает вместе с объектом в новую базу, как история по предыдущему и более раннему владельцу. С доступами вы тут перегибаете.
Насколько я понимаю, в Вашей системе тоже должна быть двойная запись, или ее модификация в натуральных величинах, только дебетуется счет одной компании, а кредитуется счет другой компании.
Тогда вопрос. Украли деньги, кого будем дебетовать?
Тогда вопрос. Украли деньги, кого будем дебетовать?
Нулевой объект — термин экаунтологии. По-русски, внешняя среда. Правда, пользователю дебетовать ничего не придется, в системе нулевой объект остается за кадром. Пользователь укажет лишь расход (не кредит, конечно) объекта, что будет означать: объект оказался во внешней среде — от нас убыл, но ни к кому не прибыл.
>>Модифицировать существующие учетные программы невозможно, т.к. они основаны на ошибочной методологии — двойной записи.
1C не основано на двойной записи. Точнее двойная запись ведется в бухгалтерии, но это не единственный способ учета, предусмотренный в программе. В управлении торговлей вообще не ведется классического бухучета
1C не основано на двойной записи. Точнее двойная запись ведется в бухгалтерии, но это не единственный способ учета, предусмотренный в программе. В управлении торговлей вообще не ведется классического бухучета
Честно говоря, мне недосуг разбираться, что там наворочано в управлении торговлей. С теми учетными концепциями, которые опубликованы на русском языке, я знаком. Поскольку среди них нет концепции «1С: торговля», я заключаю, что никакой научной концепции в этой программе не реализовано.
Правильнее говорить не о научной концепции, а о методологии, заложенной в программе.
От вашего заключения ничего не изменится, двойной записи там как не было, так и нет
От вашего заключения ничего не изменится, двойной записи там как не было, так и нет
Одного отсутствия двойной записи недостаточно, нужно данное отсутствие чем-то заменить. Универсальным желательно. А универсальные принципы учета — это и есть научная концепция.
Какие будут предложения?? Чем будем менять двойную запись?? Автор понимает о чем я . Но требую ответа! Ведь автор кидает идею полететь в другую галактику, а каким образом и способами хотя бы концептуально не снабжает. У многих писателей фантастов получалось заглянуть таким образом в будущее. Нужны обоснования. Дайте их.
На входе в форму счетоводства, которая крутится на двойной записи стоят первичные документы, у которых нет двойной записи. Насколько я понял malan, предлагает обмениваться именно ссылками на первоисточник информации – первичный документ. Модернизировать любые программы модулем обмена данными можно. Кстати это может быть простая программа которая сможет интегрироваться со всем зоопарком ЕРП систем.
А вот на счет услуг. Уточняйте пожалуйста, что Вы подразумеваете учет работников.
В моем понимании это учет времени работников, так?
Если так то услуги, это передача объекта учета «время» . Логично, но подобной постановки вопроса я у Вас пока не видел.
А вот на счет услуг. Уточняйте пожалуйста, что Вы подразумеваете учет работников.
В моем понимании это учет времени работников, так?
Если так то услуги, это передача объекта учета «время» . Логично, но подобной постановки вопроса я у Вас пока не видел.
Какие еще первичные документы при компьютерном учете? Бумажные, что ли? Даже комментировать это не хочется.
Чуть подробнее об услугах. Согласно экаунтологии, работники — это орудия труда, аналогичные станкам и другим механизмам, только одушевленные. Принцип воздействия тот же самый, как у любого орудия на предмет (термины экономики). Если бы в бухгалтерии учитывались работники в качестве объектов, работники переносили бы свою стоимость на предметы в виде амортизации. Но этого не делается, в основном по той причине, что работникам платят зарплату периодически, тем самым работники выступают в качестве арендованных орудий труда. У бухгалтерии с учетом арендованных орудий традиционно плохо, поэтому работники не учитываются, а зарплата включается в объекты калькулирования. Если объект калькулирования — не вещь, то есть не материальна (например, разработка документации), тогда возникают услуги. Либо, второй вариант, услуги оказываются напрямую клиенту, фактически — взятый в аренду работник передается в субаренду. Таким образом, имеет место наслоение сразу нескольких методологических ошибок.
А время здесь не при чем: время имеет лишь то значение, что орудия всегда воздействуют на предметы длительно.
Сложно?
Чуть подробнее об услугах. Согласно экаунтологии, работники — это орудия труда, аналогичные станкам и другим механизмам, только одушевленные. Принцип воздействия тот же самый, как у любого орудия на предмет (термины экономики). Если бы в бухгалтерии учитывались работники в качестве объектов, работники переносили бы свою стоимость на предметы в виде амортизации. Но этого не делается, в основном по той причине, что работникам платят зарплату периодически, тем самым работники выступают в качестве арендованных орудий труда. У бухгалтерии с учетом арендованных орудий традиционно плохо, поэтому работники не учитываются, а зарплата включается в объекты калькулирования. Если объект калькулирования — не вещь, то есть не материальна (например, разработка документации), тогда возникают услуги. Либо, второй вариант, услуги оказываются напрямую клиенту, фактически — взятый в аренду работник передается в субаренду. Таким образом, имеет место наслоение сразу нескольких методологических ошибок.
А время здесь не при чем: время имеет лишь то значение, что орудия всегда воздействуют на предметы длительно.
Сложно?
Нельзя не согласиться. Если возникнет критерий оценки предлагаемых учетных систем, как возможность обмена ссылками на оформленный документ, но это будет первый практический шаг в стороны этой идеи. И, кстати, он не утопия, а реальная потребность.
Два предприятия взаимодействуют в действительности, но базы отдельные и отдельные варианты взаиморасчетов. Потом приходится периодически их сверять. Практики знают, что это зачастую не так просто, особенно согласовывать несостыковки, занимает уйму времени, соответственно это расходы предприятия. Если бы программы позволяли обмениваться ссылками по документам и соовтественно автоматизировать проверку взаиморасчетов, то это позволило бы значительно улучшить учет. Это уж реальная практика с экономией и с улучшеним качества учета (более постоянное соответствие учтенных данных реальной действительности).
Два предприятия взаимодействуют в действительности, но базы отдельные и отдельные варианты взаиморасчетов. Потом приходится периодически их сверять. Практики знают, что это зачастую не так просто, особенно согласовывать несостыковки, занимает уйму времени, соответственно это расходы предприятия. Если бы программы позволяли обмениваться ссылками по документам и соовтественно автоматизировать проверку взаиморасчетов, то это позволило бы значительно улучшить учет. Это уж реальная практика с экономией и с улучшеним качества учета (более постоянное соответствие учтенных данных реальной действительности).
Вы против столпа бухгалтерии — двойной записи — пойти хотите? Это… Эээ… Наивно.
Наивно — считать двойную запись (в ее современном виде) столпом бухгалтерии.
Это не наивно, а очень правильно. Смею заметить, что системы управленческого учета уже давно наплевали на двойную запись, именно потому что есть недостатки и ограничения, но это не значит, что в управленческом учете правильнее двойной записи. Современный упр учет – это шаг назад в технологии учета, а не вперед, просто компромисс. Для управленцев нужны такие данные и двойная запись с этим не справляется, убрали… Внешним сторонам нужна общая картина, а для этого не обойтись без двойной записи. Компромисс в том, что существует две параллельные системы учета, а это все усложняет. Должна быть одна система и разные формы информации.
О том и речь, так нельзя и так нельзя. Самый главной вопрос жизнеспособности данной идеи заключается в том, а как можно?
Прикрепили бы вы опрос, сколько % среди технически продвинутых пользователей желали бы использовать хоть что-то подобное.
Можно было, конечно.
Но в любом случае потребность в неофициальном учете существует.
Но в любом случае потребность в неофициальном учете существует.
Если вы считаете, что она существует — кто мешает вам реализовать выше изложенное?
Какое именно внимание вы хотите привлечь этим топиком: найти инвесторов, набрать сотрудников, получить увесистую долю критики от реалистов?
Какое именно внимание вы хотите привлечь этим топиком: найти инвесторов, набрать сотрудников, получить увесистую долю критики от реалистов?
Управленческий учет, считается внутренней кухней предприятия, ведется везде, и он не официальный. Поэтому подобной потребностью нельзя обосновывать потребность к продуктам на базе ваших идей.
Призываю robux в комментарии. Он разрабатывает программу Pandora, где существует возможность децентрализованного распределённого документооборота.
Сразу вопрос ему: У Вас в программе получится реализовать что-то подобное?
Сразу вопрос ему: У Вас в программе получится реализовать что-то подобное?
С проектом Pandora я знаком.
У меня ничего похожего, уж не знаю, к счастью или к сожалению.
У меня ничего похожего, уж не знаю, к счастью или к сожалению.
Жизнеспособные IT-концепции способны создавать только практикующие программисты.
Мнения теоретиков IT без практического опыта программирования для меня интересны как экспонаты Кункстамеры: да забавно, да поглядел, да навевает. Но это мир фантазии, а не реальности.
Мнения теоретиков IT без практического опыта программирования для меня интересны как экспонаты Кункстамеры: да забавно, да поглядел, да навевает. Но это мир фантазии, а не реальности.
Ага, практикующий программист — единственная достойная уважения профессия. А кроме них, никто ни черта не понимает, даже в своих научных областях.
Михаил, всё-таки на днях вдумчиво прочитал статью.
Вы и раньше высказывали эту идею, идея действительно хороша.
Данные о товаре идут по цепочкам производителей, цепочкам сбыта, и в итоге приходят к конечному потребителю. Все участники добавляют (по желанию) учетные данные.
Учётные объекты постепенно обрастают новыми аттрибутами, курсируя между участникам.
Первый раз глянул по диогонали (не было времени) и подумал, какая-то ерунда. Поэтому отписался критически. (Тем не менее, статью сразу плюсанул, так как уважаю ваш опыт и в принципе понимаю ваши чаяния, не грешите на меня).
Как это может быть реализовано в Пандоре?
В Пандоре уже сейчас существует объекты «Товар» (потомок объекта «Вещь»), «Файл», который может иметь любое наполнение, и «Связь», который устанавливает связь между разными объектами.
Например, можно придумать стандарт файла (в формате xml, json, pson или каком-либо другом структурированном формате), позволяющий многократно добавлять поля. Для этого на базе объекта Файл создать потомка на уровне Дело, обозвав его например «Карточка».
Для редактирования Карточки можно сделать даже несколько форм ввода, которые избавят пользователя от необходимости вникать в структуру файла и позволят ему сосредоточиться на вводе учетных данных.
Работа будет выглядеть так:
1) на уровне Мир вводится Вещь, например «Ноутбук».
2) на уровне Дело вводится Товар, например «Ноутбук Asus Eee PC X101CH»
3) на уровне Дело вводится Карточка, в которой заводятся аттрибуты:
«Диагональ: 10''; вес: 1 кг; процессор: Atom 1600 МГц; память: 1024 Мб DDR3; накопитель: HDD 320 Гб» и другие по желанию.
Связи определяют, каким образом соотносится данная Карточка с Товарами. Или конкретный Товар с разными Карточками.
В Пандоре существуют разные типы связей (подробнее в моей статье про Пандору), поэтому карточка может по разному быть связана, причем не только с товаром, но и с записями других типов.
Отчасти, Карточка дублирует запись Объявление и возможно она будет излишеством… хотя, может она и будет полезна. Особенно в цепочке производителей, которым важно отслеживать движение деталей и сборку узлов.
Вы и раньше высказывали эту идею, идея действительно хороша.
Данные о товаре идут по цепочкам производителей, цепочкам сбыта, и в итоге приходят к конечному потребителю. Все участники добавляют (по желанию) учетные данные.
Учётные объекты постепенно обрастают новыми аттрибутами, курсируя между участникам.
Первый раз глянул по диогонали (не было времени) и подумал, какая-то ерунда. Поэтому отписался критически. (Тем не менее, статью сразу плюсанул, так как уважаю ваш опыт и в принципе понимаю ваши чаяния, не грешите на меня).
Как это может быть реализовано в Пандоре?
В Пандоре уже сейчас существует объекты «Товар» (потомок объекта «Вещь»), «Файл», который может иметь любое наполнение, и «Связь», который устанавливает связь между разными объектами.
Например, можно придумать стандарт файла (в формате xml, json, pson или каком-либо другом структурированном формате), позволяющий многократно добавлять поля. Для этого на базе объекта Файл создать потомка на уровне Дело, обозвав его например «Карточка».
Для редактирования Карточки можно сделать даже несколько форм ввода, которые избавят пользователя от необходимости вникать в структуру файла и позволят ему сосредоточиться на вводе учетных данных.
Работа будет выглядеть так:
1) на уровне Мир вводится Вещь, например «Ноутбук».
2) на уровне Дело вводится Товар, например «Ноутбук Asus Eee PC X101CH»
3) на уровне Дело вводится Карточка, в которой заводятся аттрибуты:
«Диагональ: 10''; вес: 1 кг; процессор: Atom 1600 МГц; память: 1024 Мб DDR3; накопитель: HDD 320 Гб» и другие по желанию.
Связи определяют, каким образом соотносится данная Карточка с Товарами. Или конкретный Товар с разными Карточками.
В Пандоре существуют разные типы связей (подробнее в моей статье про Пандору), поэтому карточка может по разному быть связана, причем не только с товаром, но и с записями других типов.
Отчасти, Карточка дублирует запись Объявление и возможно она будет излишеством… хотя, может она и будет полезна. Особенно в цепочке производителей, которым важно отслеживать движение деталей и сборку узлов.
Спасибо, Михаил. Сейчас перечитал статью про Пандору. Ну что я могу сказать? Дело в том, что наши проекты почти не пересекаются, хотя могут дополнить друг друга.
Я методолог, и проект мой в первую очередь методологический. В данном посте предполагается, что обмен объектами происходит через сервер производителя. Это не методологическое требование, а коммерческое, в надежде найти инвестора. Тот же проект можно реализовать по-другому, например хранить базы данных на сервере производителя, то есть сделать учет on-line. А можно, как вы предлагаете, абсолютно децентрализовать пользовательские базы данных, чтобы пользователи объектами обменивались напрямую между собой. Такой вариант, делающий пользователей независимыми от государства, мне близок и нравится. Но это не методология учета.
То есть ситуация такая: обмен объектами непосредственно между пользователями сделать можно, и даже запросто. Это было бы здорово! Но это программистские дела, от меня в этом отношении ничего не потребуется, кроме согласования с программистами изменений в структуре баз данных. А с методологией учета сложней. Я не смогу ее пересмотреть применительно к Пандоре при всем желании. Вы не представляете, чего мне стоило изобрести свою методологию и сформулировать (достаточно сказать, что пришлось целую философско-экономическую дисциплину разработать для ее обоснования, на что ушло десятилетие). Сейчас методология решена в реляционных базах. В принципе, программное решение может быть любым другим (графы или что там еще у программистов припасено?), другим может быть интерфейс, но саму методологию не изменить без уничтожения. Я не смогу приспособить ее к вашим карточкам и товарам, которые представляют собой другой методологический подход. Я его даже не понимаю, потому как на единственной картинке, которая в посте (та, которая с меню), я вижу лишь непроработанный и хаотический перечень названий. Мне это так со стороны представляется, хотя я наверняка неправ. Но если даже я постараюсь разобраться в вашем подходе, он гарантированно не совпадет с моим. На уровне методологии, а на уровне программной реализации подходы, как я сказал, могут друг друга взаимодополнить.
Резюме: если бы мы надумали совместить системы, пришлось бы к вашим «внутренним» программным наработкам присобачивать мой интерфейс и учетные базы моей структуры, что равносильно написанию моей программы с нуля. Грустно, а что поделаешь?
Я методолог, и проект мой в первую очередь методологический. В данном посте предполагается, что обмен объектами происходит через сервер производителя. Это не методологическое требование, а коммерческое, в надежде найти инвестора. Тот же проект можно реализовать по-другому, например хранить базы данных на сервере производителя, то есть сделать учет on-line. А можно, как вы предлагаете, абсолютно децентрализовать пользовательские базы данных, чтобы пользователи объектами обменивались напрямую между собой. Такой вариант, делающий пользователей независимыми от государства, мне близок и нравится. Но это не методология учета.
То есть ситуация такая: обмен объектами непосредственно между пользователями сделать можно, и даже запросто. Это было бы здорово! Но это программистские дела, от меня в этом отношении ничего не потребуется, кроме согласования с программистами изменений в структуре баз данных. А с методологией учета сложней. Я не смогу ее пересмотреть применительно к Пандоре при всем желании. Вы не представляете, чего мне стоило изобрести свою методологию и сформулировать (достаточно сказать, что пришлось целую философско-экономическую дисциплину разработать для ее обоснования, на что ушло десятилетие). Сейчас методология решена в реляционных базах. В принципе, программное решение может быть любым другим (графы или что там еще у программистов припасено?), другим может быть интерфейс, но саму методологию не изменить без уничтожения. Я не смогу приспособить ее к вашим карточкам и товарам, которые представляют собой другой методологический подход. Я его даже не понимаю, потому как на единственной картинке, которая в посте (та, которая с меню), я вижу лишь непроработанный и хаотический перечень названий. Мне это так со стороны представляется, хотя я наверняка неправ. Но если даже я постараюсь разобраться в вашем подходе, он гарантированно не совпадет с моим. На уровне методологии, а на уровне программной реализации подходы, как я сказал, могут друг друга взаимодополнить.
Резюме: если бы мы надумали совместить системы, пришлось бы к вашим «внутренним» программным наработкам присобачивать мой интерфейс и учетные базы моей структуры, что равносильно написанию моей программы с нуля. Грустно, а что поделаешь?
Где тут клавиша, чтобы плюс жирным выделить.
Только маленькая корректировка. Сами программисты зачастую далеки от специальной области, где должна проводиться автоматизация. Сами они такого понаворотят….это уже проходили. Но то, что подобные концепции должны делаться с полным пониманием всех основ программирования, баз данных и с хорошим опытом управления разработками, согласен на все 100.
Для разработки мостик взаимопонимания должен быть построен между программистом и специалистом в требуемой области, а это ооооочень сложный вопрос.
Только маленькая корректировка. Сами программисты зачастую далеки от специальной области, где должна проводиться автоматизация. Сами они такого понаворотят….это уже проходили. Но то, что подобные концепции должны делаться с полным пониманием всех основ программирования, баз данных и с хорошим опытом управления разработками, согласен на все 100.
Для разработки мостик взаимопонимания должен быть построен между программистом и специалистом в требуемой области, а это ооооочень сложный вопрос.
Программисты должны программировать. Учетная методология — совершенно иная область,, в которой программисты не сильны. Приходится либо доводить программиста до уровня методолога (что чрезвычайно сложно, ибо — вторая специальность), либо ставить ему задачу как исполнителю. Ставит задачу методолог.
Грубо говоря, программист — это каменщик, а методолог — архитектор. Почему-то программисты всегда упираются рогом, когда им сообщают, что имеются иные предметные области.
Грубо говоря, программист — это каменщик, а методолог — архитектор. Почему-то программисты всегда упираются рогом, когда им сообщают, что имеются иные предметные области.
У вашей идеи есть маааленькая проблемка. Она неинтересна пока все не начнуть её использовать. Это как новая операционка — какой бы шикарной она не была, но без приложений она не нужна.
В известном смысле вы правы. Однако программа интересна учетной методологией: методология принципиально новая, поверьте. В конце концов, учитывать что-то по мелочам многим необходимо. От ограниченного использования — к массовому, короче.
Вы попробуйте подойти к бухгалтеру и предложить новую методологию… результат очевиден.
Еще бы! Переучиваться-то никому не охота, даже если тебя в свое время обучили черт-те знает чему.
Знаете, как в свое время извозчики двигатели внутреннего сгорания крыли?!
Знаете, как в свое время извозчики двигатели внутреннего сгорания крыли?!
Я полагаю, что переход с традиционной методологии на новую пойдет лучше, если у этих методологий будут точки соприкосновения. Перейти на новую методику учета с ходу вряд ли кто сможет себе позволить. Поэтому неплохо бы представлять, в каких случаях и сценариях новая методология сможет безболезненно для предприятия не только заменить элементы старой методологии, но и дать выигрыш от нового учета.
Да, она будет интересна всем, если будет использоваться широко — тогда идея об обмене структурированной информацией об объектах учета будет работать максимально эффективно. Но чтобы методологию начали использовать все — она должна давать некий выигрыш локально, в рамках одного предприятия, без оглядки на других, которые ее используют. Если это принципиально возможно — то можно внедрять методологию не как инфраструктурный проект на уровне государства, а в отдельных компаниях.
Кстати, а вы с этой идеей в 1С обращаться не пробовали? Им может показаться интересной идея создания среды для обмена информацией об объектах учета поверх (или в дополнение) к их бухгалтерским системам. Новый сервис — новые клиенты и новые деньги. А при том, что такого еще ни у кого из конкурентов нет — возможность захватить кусок рынка в дополнение к уже имеющейся доле.
Да, она будет интересна всем, если будет использоваться широко — тогда идея об обмене структурированной информацией об объектах учета будет работать максимально эффективно. Но чтобы методологию начали использовать все — она должна давать некий выигрыш локально, в рамках одного предприятия, без оглядки на других, которые ее используют. Если это принципиально возможно — то можно внедрять методологию не как инфраструктурный проект на уровне государства, а в отдельных компаниях.
Кстати, а вы с этой идеей в 1С обращаться не пробовали? Им может показаться интересной идея создания среды для обмена информацией об объектах учета поверх (или в дополнение) к их бухгалтерским системам. Новый сервис — новые клиенты и новые деньги. А при том, что такого еще ни у кого из конкурентов нет — возможность захватить кусок рынка в дополнение к уже имеющейся доле.
У новой и старой методологий слишком мало точек соприкосновения, как, скажем, у телег и двигателей внутреннего сгорания.
В 1С не обращался, зато посылал предложения в Яндекс и Рамблер. Ясен пень, мне даже не ответили. Им письма от таких придурков, как я, регулярно поступают, наверное. В 1С, полагаю, тоже.
В 1С не обращался, зато посылал предложения в Яндекс и Рамблер. Ясен пень, мне даже не ответили. Им письма от таких придурков, как я, регулярно поступают, наверное. В 1С, полагаю, тоже.
В торговле в фармацевтике уже довольно давно существует нечто подобное. Правда, провайдеров сетей несколько.
Но не _много_.
Могу подсказать проблемы, которые сейчас в этих вариантах всплывают.
1. Если провайдер не один — сразу ОГРОМНАЯ проблема синхронизации классификаторов. А сделать так, чтобы провайдер был ОДИН — я даже не знаю, как. Если только это не будет госведомство «РосТоргЭлектронУчет» :)
2. Весь учет, во всяком случае, в России, первостепенной целью ставит отчетность :) Это неправильно, есть управленческий, есть куча других целей и они тоже достигаются или достижимы, но первостепенная — именно регламентированная отчетность. А вот с этим, пока провайдеры — не единое госведомство, во всех этих «сетях» очень туго. Ибо либо писать новую 1С, либо ограничиваться тем, что уже есть. А этого ой как недостаточно. А разработчики, как правило, наколенные и больше пекутся о решении проблемы №1 и о продажах через эти сети.
А еще очень туманно выглядит схема учета персональных богатств. Вы когда-нибудь пробовали учесть хотя бы просто персональные финансы? И когда в последний раз реальное состояние кошелька сходилось с электронной версией? А что, повседневное питание, туалетную бумагу — тоже «списывать» по факту? И презервативы? И расходы на шл… кхм… прекрасных дам?
Но не _много_.
Могу подсказать проблемы, которые сейчас в этих вариантах всплывают.
1. Если провайдер не один — сразу ОГРОМНАЯ проблема синхронизации классификаторов. А сделать так, чтобы провайдер был ОДИН — я даже не знаю, как. Если только это не будет госведомство «РосТоргЭлектронУчет» :)
2. Весь учет, во всяком случае, в России, первостепенной целью ставит отчетность :) Это неправильно, есть управленческий, есть куча других целей и они тоже достигаются или достижимы, но первостепенная — именно регламентированная отчетность. А вот с этим, пока провайдеры — не единое госведомство, во всех этих «сетях» очень туго. Ибо либо писать новую 1С, либо ограничиваться тем, что уже есть. А этого ой как недостаточно. А разработчики, как правило, наколенные и больше пекутся о решении проблемы №1 и о продажах через эти сети.
А еще очень туманно выглядит схема учета персональных богатств. Вы когда-нибудь пробовали учесть хотя бы просто персональные финансы? И когда в последний раз реальное состояние кошелька сходилось с электронной версией? А что, повседневное питание, туалетную бумагу — тоже «списывать» по факту? И презервативы? И расходы на шл… кхм… прекрасных дам?
По поводу фармацевтики мне сложно что-либо ответить, я не в курсе тамошних проблем.
А по поводу туалетной бумаги и прекрасных дам, ага, точно так. Ну если вы захотите, конечно. При желании можете провести данные расходы по статье «посещение планетария».
А по поводу туалетной бумаги и прекрасных дам, ага, точно так. Ну если вы захотите, конечно. При желании можете провести данные расходы по статье «посещение планетария».
Фармацевтика приведена просто как набор уже реально существующих примеров таких «сетей». Обе проблемы будут возникать в любой отрасли.
И тогда мне слабо видится смысл такой «сети», если я на основе данных ее базы не смогу получить какую-то аналитику.
А получить я ее не смогу до тех пор, пока не будет синхронизации классификаторов. То есть, пока я не смогу купить в двух разных магазинах «Аспирин №20» и «Аспирин 20таб» как одно и то же (по желанию Аспирин меняете на что угодно — от батареек до чеснока). Толку мне от того, что я могу полностью просмотреть информацию о происхождении товара и его истории, если у меня на полке стоит 40 одинаковых таблеток, а аналитика выдает мне их как 20 одних и 20 других просто потому что одни выпущены в Рязани, а другие — в Штутгарте.
Я не к тому, что идея плохая или нерабочая. Я к тому, что идея глобальной системы учета всего — боюсь, лишена исходного драйва, который был у соцсетей.
И тогда мне слабо видится смысл такой «сети», если я на основе данных ее базы не смогу получить какую-то аналитику.
А получить я ее не смогу до тех пор, пока не будет синхронизации классификаторов. То есть, пока я не смогу купить в двух разных магазинах «Аспирин №20» и «Аспирин 20таб» как одно и то же (по желанию Аспирин меняете на что угодно — от батареек до чеснока). Толку мне от того, что я могу полностью просмотреть информацию о происхождении товара и его истории, если у меня на полке стоит 40 одинаковых таблеток, а аналитика выдает мне их как 20 одних и 20 других просто потому что одни выпущены в Рязани, а другие — в Штутгарте.
Я не к тому, что идея плохая или нерабочая. Я к тому, что идея глобальной системы учета всего — боюсь, лишена исходного драйва, который был у соцсетей.
Не совсем так. Идея предполагает идентификацию каждого объекта, то есть каждой таблетки. Если все правильно организовать, вы сможете посмотреть, на каком станке выпущена конкретная таблетка и как фамилия начальника смены.
«Вот же ж круто! А зачем?» ((с)Д.Быков «Путин и мужик»)
А почему нет? Если уж учитывать, то как в реальности, где каждый объект идентифицирован (то есть он именно этот объект, а не другой).
Ну тогда нужно определиться, кто будет решать, когда переставать учитывать объекты.
Для меня это уже мусор и шлак, который я давно исключил из рассмотрения, не имеющий информационного смысла и объекта описания. А для мусоросжигательного завода — еще пока предметы разного происхождения и из разных материалов, которые надо (учитывать)утилизировать по-разному.
«почему нет» — потому что технически Матрица нереализуема на том уровне детализации, который удовлетворит ВСЕХ. Кому-то достаточно подсчитать расход молока в целом, а кому-то — важно, что ела корова и как она себя чувствовала, которая дала молоко, которое сейчас в стакане. Причины такого интереса — лежат за пределами обсуждения, для неограничения общности.
Для меня это уже мусор и шлак, который я давно исключил из рассмотрения, не имеющий информационного смысла и объекта описания. А для мусоросжигательного завода — еще пока предметы разного происхождения и из разных материалов, которые надо (учитывать)утилизировать по-разному.
«почему нет» — потому что технически Матрица нереализуема на том уровне детализации, который удовлетворит ВСЕХ. Кому-то достаточно подсчитать расход молока в целом, а кому-то — важно, что ела корова и как она себя чувствовала, которая дала молоко, которое сейчас в стакане. Причины такого интереса — лежат за пределами обсуждения, для неограничения общности.
Концепция предполагает добровольный учет. Добровольный. как сам Интернет. Кто решает, продолжать свой блог в социальной сети или удалить его со всеми данными? Пользователь.
И никакого всеобщего удовлетворения быть не может. Одним интересно одно, другим противоположное. Как хочешь, так учитывай; что хочешь, то и смотри.
И никакого всеобщего удовлетворения быть не может. Одним интересно одно, другим противоположное. Как хочешь, так учитывай; что хочешь, то и смотри.
Очень хочется вставить комментарий, что состояние (финансовое), т.е. персональное богатство, не имеет ничего общего с тратами и получением денег и доходами расходами, т.е.операциями, которые изменяют это состояние.
Учитывать траты, доходи и расходы сложно, это точно. А вот состояние учитывать нет проблем, даже программ не надо. Ссылка на статью
Учитывать траты, доходи и расходы сложно, это точно. А вот состояние учитывать нет проблем, даже программ не надо. Ссылка на статью
Простите, при все моем к вам уважении и интересе к вашим статьям про бухгалтерский учет, возникает ряд вопросов:
Техническое задание выполнено на основе экаунтологии – научной дисциплины, разработанной мной в попытке осмыслить технологию идеального учета.
1. Можно ли посмотреть на какие-либо публикации по теме в рецензируемых источниках?
2. Попытался полазить по сайту в поисках информации. Нашел вот это:
accountology.ucoz.ru/index/ehzoterizm_v_bukhgalterii/0-8
Бухгалтерия — эзотерическая наука? Даже без претензий к тому что эзотерических наук не бывает (см. критерий Поппера). И к тому что научные статьи не пишут в тоне д’Артаньяна.(http://lurkmore.to/%D0%92%D1%81%D0%B5_%D0%BF%D0%B8%D0%B4%D0%BE%D1%80%D0%B0%D1%81%D1%8B,_%D0%B0_%D1%8F_%E2%80%94_%D0%B4%E2%80%99%D0%90%D1%80%D1%82%D0%B0%D0%BD%D1%8C%D1%8F%D0%BD)
3. Вот тут — accountology.ucoz.ru/
Я не понял. Вы пытаетесь изобрести заново реляционную алгебру? Зачем?
Техническое задание выполнено на основе экаунтологии – научной дисциплины, разработанной мной в попытке осмыслить технологию идеального учета.
1. Можно ли посмотреть на какие-либо публикации по теме в рецензируемых источниках?
2. Попытался полазить по сайту в поисках информации. Нашел вот это:
accountology.ucoz.ru/index/ehzoterizm_v_bukhgalterii/0-8
Бухгалтерия — эзотерическая наука? Даже без претензий к тому что эзотерических наук не бывает (см. критерий Поппера). И к тому что научные статьи не пишут в тоне д’Артаньяна.(http://lurkmore.to/%D0%92%D1%81%D0%B5_%D0%BF%D0%B8%D0%B4%D0%BE%D1%80%D0%B0%D1%81%D1%8B,_%D0%B0_%D1%8F_%E2%80%94_%D0%B4%E2%80%99%D0%90%D1%80%D1%82%D0%B0%D0%BD%D1%8C%D1%8F%D0%BD)
3. Вот тут — accountology.ucoz.ru/
Я не понял. Вы пытаетесь изобрести заново реляционную алгебру? Зачем?
Сайт вы нашли, там большинство материалов.
Эзотерические науки существуют, Поппер ошибался, я вообще его критерия не придерживаюсь.
Да, мои статьи в тоне д’Артаньяна, такой уж авторский стиль, ничего не поделаешь.
Реляционную алгебру я не пытаюсь изобрести, я вообще в алгебре ничего не понимаю. Моя задача — понять, как нужно учитывать. Исходя из этой задачи, пришлось разработать экаунтологию, т.к. другие учения меня не устраивали.
Эзотерические науки существуют, Поппер ошибался, я вообще его критерия не придерживаюсь.
Да, мои статьи в тоне д’Артаньяна, такой уж авторский стиль, ничего не поделаешь.
Реляционную алгебру я не пытаюсь изобрести, я вообще в алгебре ничего не понимаю. Моя задача — понять, как нужно учитывать. Исходя из этой задачи, пришлось разработать экаунтологию, т.к. другие учения меня не устраивали.
>> Сайт вы нашли, там большинство материалов.
Как вы ловко обошли слово «рецензируемых» ;)
>> Эзотерические науки существуют, Поппер ошибался, я вообще его критерия не придерживаюсь.
>> я вообще в алгебре ничего не понимаю.
>> т.к. другие учения меня не устраивали.
Спасибо, больше вопросов не имеется.
Как вы ловко обошли слово «рецензируемых» ;)
>> Эзотерические науки существуют, Поппер ошибался, я вообще его критерия не придерживаюсь.
>> я вообще в алгебре ничего не понимаю.
>> т.к. другие учения меня не устраивали.
Спасибо, больше вопросов не имеется.
Слишком сложно и никому не нужно. Выгода от предоставления кому-либо информации о том как использовался объект сомнительная. Не взлетит
Ага. Кому, в самом деле, интересно знать, из какого г… изготавливаются продукты, которые продаются в магазинах, и сколько получают таджики, которые эти продукты изготавливают?
Если ваша цель в этом, то где проверка на достоверность? Что мешает покупать говно, а проводить его по документам как мясо ягнёнка?
Учет не может проверить сам себя на соответствие действительности. Но если кто-то уличен в неблаговидном, это сказывается на его репутации. Просто возможностей протестировать репутацию станет больше.
Разве всеобщая информационная база — это плохо?
Разве всеобщая информационная база — это плохо?
Я вспомнил… мы с вами уже общались в апрельских тезисах :D
Но если кто-то уличен в неблаговидном, это сказывается на его репутацииТо есть, в самой системе должна быть
Нет, разумеется. Имеется в виду общечеловеческая репутация. Если магазин продает дрянь, а по учету — хай-класс, его репутация соответствующая.
Для этого нет необходимости вести подобный учет
Михаил мне друг, но истина дороже ©.
В целом концепция понятна. Интернет, глобализация во всем, доберется и до учета.
У меня пока два вопроса, чтобы не путаться буду добавлять вопросы разными комментариями.
1. Простая универсальная программа агент, в которой должны будут вести учет все от мала до велика. Уже тут есть момент утопичности. Каждый, кто касался задачи ведения учета, понимает насколько она непростая, и специальная. Причем большинство людей не поймет, куда чего с объектами делать, и для чего им вообще это надо. А специалисты не примут, поскольку мыслят другими категориями, выполняют другие задачи (к примеру, составление отчетов в соответствии со стандартами МСФО, расчет себестоимости по установленному внутри компании алгоритму, который никто не понимает и др.). Так напрашивается мысль, что придется учить всех этой простой универсальной программе. А еще вопрос, каким медом она должна быть намазана, чтобы стали учиться. Простым людям надо будет понять, что вся жизнь устроена из обмена объектами, понять саму концепцию, которую тут с трех раз трудно проходят, а на хабре сидят очень и очень сообразительные люди. А специалистам нужно будет сообразить, куда делись долги в денежном выражении и где доходы и расходы, а их другому учили. Потом, как можно программу сделать простой, если у каждого движения будет 40 полей для при концепция их заполнения, а иначе туши фонарь. В целом сомнения по поводу одной из опорных свай конструкции этого предложения, а именно, «простая универсальная программка-агент для учета»
В целом концепция понятна. Интернет, глобализация во всем, доберется и до учета.
У меня пока два вопроса, чтобы не путаться буду добавлять вопросы разными комментариями.
1. Простая универсальная программа агент, в которой должны будут вести учет все от мала до велика. Уже тут есть момент утопичности. Каждый, кто касался задачи ведения учета, понимает насколько она непростая, и специальная. Причем большинство людей не поймет, куда чего с объектами делать, и для чего им вообще это надо. А специалисты не примут, поскольку мыслят другими категориями, выполняют другие задачи (к примеру, составление отчетов в соответствии со стандартами МСФО, расчет себестоимости по установленному внутри компании алгоритму, который никто не понимает и др.). Так напрашивается мысль, что придется учить всех этой простой универсальной программе. А еще вопрос, каким медом она должна быть намазана, чтобы стали учиться. Простым людям надо будет понять, что вся жизнь устроена из обмена объектами, понять саму концепцию, которую тут с трех раз трудно проходят, а на хабре сидят очень и очень сообразительные люди. А специалистам нужно будет сообразить, куда делись долги в денежном выражении и где доходы и расходы, а их другому учили. Потом, как можно программу сделать простой, если у каждого движения будет 40 полей для при концепция их заполнения, а иначе туши фонарь. В целом сомнения по поводу одной из опорных свай конструкции этого предложения, а именно, «простая универсальная программка-агент для учета»
Отвечаю другу Аристотелю.
Я и не собираюсь заставлять всех пользоваться своей программой, это в самом деле немного утопично. :) Я собираюсь вбросить в мир, в котором все пользуются счётами, арифмометр, и посмотреть, что произойдет. Думается мне, со временем все перейдут на арифмометры, хотя пользование ими действительно несколько сложней, чем счётами. Так и будет. Если, конечно, верховные счетоводы на запретят применение арифмометров как дьявольской техники.
Я и не собираюсь заставлять всех пользоваться своей программой, это в самом деле немного утопично. :) Я собираюсь вбросить в мир, в котором все пользуются счётами, арифмометр, и посмотреть, что произойдет. Думается мне, со временем все перейдут на арифмометры, хотя пользование ими действительно несколько сложней, чем счётами. Так и будет. Если, конечно, верховные счетоводы на запретят применение арифмометров как дьявольской техники.
2. Наверное, основное сомнение заключено в интимности. Недавно один человек мне показал айфон, и сказал, что даже контакты туда не записывает, потому, как он не понимает, с кем этот айфон общается в инете, и какой информацией обменивается. Предлагаю автору сделать на хабре опрос. Еще раз кратко изложить концепцию, и спросить, кто был бы готов присоединиться. Надо разобраться в том, какую ценность данная система будет нести конечному потребителю (автор считает, что это все предприятия и все частные лица глобально). Какую такую, объединяющую интересы всех этих потребителей, функцию будет нести система, что они захотят стать учетными нудистами. Есть и другие примеры, когда наши реальные клиенты сервер, на котором собирается консолидированная информация по холдингу держат в сейфовой комнате, в никому не известном месте, и в особом режиме физического доступа, и без физического подключения к интернету. Информация с разных баз вливается туда в локальной сети через флешь накопители. Интересно, как с этим бороться, продвигаю систему глобальной учетной соцсети. Видал я и людей в дырявых штанах с миллионами долларов состояния, и таких, что с виду просто богатей, а в реалии пустое место. У каждого свои резоны демонстрации внешнего вида.
Опрос — отличная идея. Жаль, в свое время не устроили опрос среди извозчиков, как они относятся к двигателям внутреннего сгорания. А Галилею надо было устроить опрос, как люди относятся к тому, что Земля вертится вокруг Солнца. Собрали бы анкеты, обработали данные, и ситуация прояснилась бы.
Что касается коммерческой тайны — да, концепция таковой не предполагает, исходя из принципа: если передал кому-то вещь, будь добр раскрыть учетную информацию относительно этой вещи. Это принципиальный момент. Планетарная база данных с коммерческой тайной не совместима: или не будет планетарной базы, или не будет коммерческой тайны.
В конце концов, никто не сможет помешать фиктивным богатеям заносить в базу ложные состояния о своем богатстве. Здесь бухгалтерия бессильна.
Что касается коммерческой тайны — да, концепция таковой не предполагает, исходя из принципа: если передал кому-то вещь, будь добр раскрыть учетную информацию относительно этой вещи. Это принципиальный момент. Планетарная база данных с коммерческой тайной не совместима: или не будет планетарной базы, или не будет коммерческой тайны.
В конце концов, никто не сможет помешать фиктивным богатеям заносить в базу ложные состояния о своем богатстве. Здесь бухгалтерия бессильна.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Бухгалтерская… социальная сеть