Comments 132
Краткое изложение для тех кому лень читать.
Автор придумал новую классную модель для бухгалтерского учета, но она никогда не будет работать, так как реальная бухгалтерия штука сложная, а модель не охватывает и 10% потребностей учета.
Автор придумал новую классную модель для бухгалтерского учета, но она никогда не будет работать, так как реальная бухгалтерия штука сложная, а модель не охватывает и 10% потребностей учета.
Пардон, я со сложностями реальной бухгалтерии хорошо знаком, просто в текущем посте их не рассматривал. Они решаемы, хотя при кардинальном изменении принципов учета. О чем и речь.
Не дезинформируйте читателей.
Не дезинформируйте читателей.
Да я тоже с бухгалтерией знаком не по наслышке. Учет ТМЦ — это простейшая из задач, которую решает бухгалтерия. Она настолько проста и очевидна, что с учета ТМЦ начинается обучение бухучету. Гораздо интереснее было бы посмотреть работу этой модели на расчете себестоимсти в многопередельном производстве с косвенными затратами и вспомогательными производствами.
Мне бы тоже было интересно.
Однако почему Вы считаете, что моя система не справится? Она имитирует реальность, а Вы же не станете отрицать, что многопередельное производство совершается в реальности, а не в головах бухгалтеров? Собственно, моя система как раз заточена под такую вот задачу со множеством объединения-разделений объектов. Соблюсти некоторые законодательные требования будет действительно непросто, но это оттого, что законодательство кривое. А в смысле имитации реальных производственных процессов моя система гораздо прогрессивней традиционной бухгалтерии, поверьте на слово.
Однако почему Вы считаете, что моя система не справится? Она имитирует реальность, а Вы же не станете отрицать, что многопередельное производство совершается в реальности, а не в головах бухгалтеров? Собственно, моя система как раз заточена под такую вот задачу со множеством объединения-разделений объектов. Соблюсти некоторые законодательные требования будет действительно непросто, но это оттого, что законодательство кривое. А в смысле имитации реальных производственных процессов моя система гораздо прогрессивней традиционной бухгалтерии, поверьте на слово.
Интересно, как будет выглядеть возврат из эксплуатации слегка поношенной спецодежды?
Если такой учет необходим, будет выглядеть так:
1) изменение свойств одежды (например, вместо значения «новая» вставляем значение «поношенная». Если очень хочется, можем и картинку исправить),
2) изменение пространственного местоположения (было значение «цех», стало значение «склад»).
Элементарно, Ватсон.
1) изменение свойств одежды (например, вместо значения «новая» вставляем значение «поношенная». Если очень хочется, можем и картинку исправить),
2) изменение пространственного местоположения (было значение «цех», стало значение «склад»).
Элементарно, Ватсон.
Это все понятно. Что будет со стоимостной оценкой?
Останется. Как она относится к трехмерности, по-Вашему?
Останется где? Вы точно с бухгалтерией знакомы?
Как относится к трехмерности? Ну если я правильно понял, трехмерность должна решать задачи учета. В том числе и суммового.
Как относится к трехмерности? Ну если я правильно понял, трехмерность должна решать задачи учета. В том числе и суммового.
>>одна реальная вещь, находящаяся в имущественном комплексе, соответствует одному объекту базы данных.
В таком подходе есть одна маленькая проблема — это никому нафиг не нужно. Ближе всего к подобному подходу сейчас является учет по серийным номерам. Все кто может не использовать серии не используют серии. Потому что это лишняя сущность, которая не важна при планировании, не важна при анализе, забивает ограниченные ресурсы мозга, увеличивает нагрузку на сервер и плодит ошибки в учете (пересорт по сериям, например, обычное явление)
В таком подходе есть одна маленькая проблема — это никому нафиг не нужно. Ближе всего к подобному подходу сейчас является учет по серийным номерам. Все кто может не использовать серии не используют серии. Потому что это лишняя сущность, которая не важна при планировании, не важна при анализе, забивает ограниченные ресурсы мозга, увеличивает нагрузку на сервер и плодит ошибки в учете (пересорт по сериям, например, обычное явление)
Чтобы выяснить, кому это нужно, я ввел опрос.
А по поводу серийных номеров Вы не правы. Где я предлагаю вести учет по серийным номерам, с чего Вы взяли? Не хотите, не ведите, будет одинаковая картинка для всех аналогичных объектов, независимо от серийных номеров.
А по поводу серийных номеров Вы не правы. Где я предлагаю вести учет по серийным номерам, с чего Вы взяли? Не хотите, не ведите, будет одинаковая картинка для всех аналогичных объектов, независимо от серийных номеров.
Но для десяти одинаковых объектов — десять картинок на рабочем поле, а не одна картинка с цифрой 10?
Я не говорил, что вы предлагали именно по серийным номерам вести учет. Я говорил про уровень детализации учета.
— Можно вести обобщенный учет по номенклатурным группам. Например, продукты, топливо, одежда, развлечения и т.д. Подойдет для домашней бухгалтерии
— Можно вести учет по номенклатуре. Подойдет, например, для продажи какой-нибудь мебели.
— Можно номенклатуру разбить на серии. Требуется, например, для учета медикаментов или продуктов с ограниченным сроком годности.
— Можно номенклатуру учитывать поштучно, присвоив, например каждому объекту по собственному серийному номеру. Подобный учет думаю требуется для производства телефонов или автомобилей. Также основные средства учитываются в организациях.
— Можно пойти дальше и разобрать штучный товар до уровня запчастей, как вы тут предлагаете. Еще и каждую запчасть учитывать поштучно
В принципе весь этот учет можно вести в современных ERP. Можно и посмотреть из чего сделана та или иная деталь, открыв документ сборки /разборки / производства. Серийные номера тогда будут в качестве уникального идентификатора товара или запчастей из которых товар состоит. Можно и с 3D картинками побаловаться и свойства задать и разукрасить карандашами цветными т.д.
Так вот дальше второго уровня (по номенклатуре) как правило учет не ведется всеми, кто может обойтись без большей детализации, потому что лишний геморой, лишние трудозатраты, дополнительные ошибки. Также никто не ведет учет кирпичей или гвоздей поштучно, потому что трудозатраты на учет превысят плюсы от правильного учета себестоимости. Приближения по ФИФО, ЛИФО, РАУЗ или по средней дают картину приемлимую для финансистов
— Можно вести обобщенный учет по номенклатурным группам. Например, продукты, топливо, одежда, развлечения и т.д. Подойдет для домашней бухгалтерии
— Можно вести учет по номенклатуре. Подойдет, например, для продажи какой-нибудь мебели.
— Можно номенклатуру разбить на серии. Требуется, например, для учета медикаментов или продуктов с ограниченным сроком годности.
— Можно номенклатуру учитывать поштучно, присвоив, например каждому объекту по собственному серийному номеру. Подобный учет думаю требуется для производства телефонов или автомобилей. Также основные средства учитываются в организациях.
— Можно пойти дальше и разобрать штучный товар до уровня запчастей, как вы тут предлагаете. Еще и каждую запчасть учитывать поштучно
В принципе весь этот учет можно вести в современных ERP. Можно и посмотреть из чего сделана та или иная деталь, открыв документ сборки /разборки / производства. Серийные номера тогда будут в качестве уникального идентификатора товара или запчастей из которых товар состоит. Можно и с 3D картинками побаловаться и свойства задать и разукрасить карандашами цветными т.д.
Так вот дальше второго уровня (по номенклатуре) как правило учет не ведется всеми, кто может обойтись без большей детализации, потому что лишний геморой, лишние трудозатраты, дополнительные ошибки. Также никто не ведет учет кирпичей или гвоздей поштучно, потому что трудозатраты на учет превысят плюсы от правильного учета себестоимости. Приближения по ФИФО, ЛИФО, РАУЗ или по средней дают картину приемлимую для финансистов
Вы все правильно объясняете. Правда, насчет моей системы немного не правы. Я вовсе не предлагаю регистрировать все составные части вещей: составные части регистрируются производителями. Субъект покупает изделие, при этом получает ссылку на соответствующий объект в базе производителя, а само зарегистрированное новым владельцем изделие учитывается по необходимости в качестве целостного объекта. Об этом в посте не говорилось: он немного о другом.
Чем, по-вашему, занимается бухгалтерия? Учитывает вещи реального мираА по-моему, бухгалтерия считает деньги, а в объектах реального мира её интересует только их денежное выражение.
Смысла нет. Если нужно поставить на учет какую либо вещь, то проще уж на нее штрих-код наклеить. Это банально удобнее потом систематизировать и проверять.
К систематизации трехмерность не относится, она никак не запрещает любую систематизацию. И штрих-коды трехмерность не отменяет: напротив, поощряет, поскольку пообъектный учет требует пообъектной идентификации. Относительно проверки тоже не соглашусь: инвентаризовать удобней по картинкам, чем табличным записям.
Разумеется 100 картинок каждая из которых килограммовая упаковка сахара гораздо наглядней, чем строчка
Сахар — 100 кг.
Сахар — 100 кг.
А разве нет? Тем более что сахар продается как в пакетах, так и в коробках.
Вы при работе на компьютере графическим интерфейсом пользуетесь, ничего? Не тоскуете по временам DOS, когда каждую команду нужно было строкой вводить?
Вы при работе на компьютере графическим интерфейсом пользуетесь, ничего? Не тоскуете по временам DOS, когда каждую команду нужно было строкой вводить?
Вы когда нибудь бывали на настоящем оптовом складе? Где хранится 3-5 тыс РАЗНЫХ наименований номенклатуры?
Таки да. Я утверждаю, что строчка Сахар -100 кг наглядней чем 100 картинок с килограмовыми пакетами.
И это всего лишь сахар. Это не мясо, где каждый кусок уникален. И не 200 литровая бочка из которой сцедили 30 литров.
Таки да. Я утверждаю, что строчка Сахар -100 кг наглядней чем 100 картинок с килограмовыми пакетами.
И это всего лишь сахар. Это не мясо, где каждый кусок уникален. И не 200 литровая бочка из которой сцедили 30 литров.
Нет, не бывал. Это автоматически делает мою идею невыполнимой?
Почему 100 картинок? Картинки для идентичных вещей будет идентичными: фактически это будет одна картинка.
Почему 100 картинок? Картинки для идентичных вещей будет идентичными: фактически это будет одна картинка.
Вообще-то многие задачи можно намного быстрее выполнить с помощью командной строки, чем через GUI. Конечно, если уметь ей пользоваться.
Не все, наверное?
Конечно, не все. Поиск/создание универсального средства на все случаи жизни вообще дело неблагодарное. Для каждой задачи нужно выбирать наиболее подходящий инструмент. Или наоборот, браться за задачи, инструменты для которых освоены.
Я взялся за поиск универсальных принципов для весьма ограниченной задачи: учета чего-либо. Какая разница, что учитывается — принципы должны быть одни и те же. Но я еще сузил задачу, остановившись на учете в реляционных базах данных.
Выглядит как будто заточено под учет материальных объектов. Которые не могут, например, бесконечно тиражироваться.
Именно так. Правда, в позднейшее версии предусмотрен учет информационных объектов, которые как раз могут бесконечно тиражироваться. При этом информационные объекты учитываются не сами по себе, а лишь в качестве записанных на материальные объекты. Как в жизни.
В принципе, учитывать можно любые другие объекты (абстрактные). Если они не могут объединяться-разделяться, для них используются операции: добавить, изменить, удалить.
В принципе, учитывать можно любые другие объекты (абстрактные). Если они не могут объединяться-разделяться, для них используются операции: добавить, изменить, удалить.
а лишь в качестве записанных на материальные объекты. Как в жизни.
Это мягко говоря не так. Один нематериальный объект может находиться на множестве носителей, а может ни на одном, то тем не менее быть объектом учета.
Если они не могут объединяться-разделяться, для них используются операции: добавить, изменить, удалить.
Как минимум не хватает «клонировать» для абстрактных объектов.
Информация всегда записана на материальный носитель, по-другому не бывает. Разумеется, на один материальный носитель может быть записано множество разных объектов и один информационный объект может находиться на множестве носителей, это предусмотрено.
Клонировать для информационных объектов тоже предусмотрено. Абстракции здесь ни при чем. Допустим, я желаю учитывать цвета спектра. Как можно размножить «зеленый» или «желтый»? Никак. Их можно принять к учету, изменить какие-либо установленные свойства, затем снять с учета. Все.
Клонировать для информационных объектов тоже предусмотрено. Абстракции здесь ни при чем. Допустим, я желаю учитывать цвета спектра. Как можно размножить «зеленый» или «желтый»? Никак. Их можно принять к учету, изменить какие-либо установленные свойства, затем снять с учета. Все.
Не всегда. Информация может генерироваться из другой информации на основе каких-то правил.
А если я хочу учитывать права, выданные клиентам? У меня есть исключительное право, а я выдаю неисключительные. Какую из операций нужно применять?
А если я хочу учитывать права, выданные клиентам? У меня есть исключительное право, а я выдаю неисключительные. Какую из операций нужно применять?
Генерироваться может как угодно и на основании чего угодно, но записывается всегда на материальный носитель. Система предназначена для имитации реальности, а не экономических правил, зачастую ошибочных или абсурдных вроде упомянутых Вами исключительных и неисключительных прав. Собственно, информационные объекты — вспомогательные, моя система предназначена для учета в том числе произведений искусства как информации, произведенной человеком. Можно зарегистрировать информационный объект, указав его свойства (в т.ч. привязать к конкретному файлу), учитывать копирование на другие материальные носители, в т.ч. других субъектов, стереть объект с материального носителя. Еще можно регистрировать время использования информационного объекта (путем его специального учета, а не установления каких-то датчиков, разумеется). Все, собственно. Другие задачи не ставились. Хотя теоретически возможно, к примеру, интегрировать в систему диспетчер файлов. В таком случае каждая операция с файлом будет регистрироваться отдельной записью. Но это вне экономики, по-моему, ведь файлы — не произведения искусства.
То есть вы предлагаете методологию бухгалтерского учёта, которая не способна адекватно отражать правовые реалии?
Я предлагаю методологию учета, которая способна корректно отражать корректные экономические реалии. А всякие человеческие выкидоны — с трудом. Я всегда говорил: чтобы организовать правильный учет, необходимо вести правильную экономику. Учет — весьма чуткий индикатор: едва сбиваешься с единственно верного пути, он тут же сигнализирует о некорректности того, что Вы называете правовыми реалиями.
Впрочем, все эти исключительные-неисключительные права можно учитывать в качестве свойства объектов. Вводишь поле «Тип права» и ставишь значения «исключительное право» или «неисключительное право». Пожалуйста.
Впрочем, все эти исключительные-неисключительные права можно учитывать в качестве свойства объектов. Вводишь поле «Тип права» и ставишь значения «исключительное право» или «неисключительное право». Пожалуйста.
Трехмерная модель предмета имеет смысл, только для уникальной позиции к примеру «стул модели 2». Для всего остального есть инвентарный номер/штрих код или серийный номер. Хранить же для каждого объекта свою уникальную трехмерную модель вещь бессмысленная и беспощадная. Это проистекает из самой сути бухгалтерии.
Если объекты идентичны, то для них будет использоваться одна трехмерная модель.
набор выпускаемых человечеством изделий ограничен, так что на практике речь пойдет о применении бухгалтерами готовых шаблонов, не более
В таком случае ни о какой 3D-бухгалтерии речи не идет. Я и сейчас могу довольно просто в ту же 1С добавить атрибут к конкретной единице учета, положить туда 3D модель и добавить возможность вызова 3D просмотра. Только что это даст и кому?
1С, поскольку она автоматизирует традиционную бухгалтерию, не поддерживает объектность. Привязать объект к картинке Вы сможете, но не сможете установить составные части объекта (если только специально не изгаляться — впрочем, сомневаюсь, что и в этом случае удастся). Вы можете взять в 1С объект — допустим, товар — и без помощи технической документации установить, из каких составных частей он состоит, и какая составная часть каким производителем изготовлена. А пообъектный подход данные возможности поддерживает.
Это называется «Система прослеживаемости». И имеет отношение не к бухгалтерии, а к ERP.
Не знал. Я называю это вложенностью (то есть одни объекты вложены в другие, и так до элементарных).
Жизнь намного сложнее. Вложенностью можно описать процесс сборки чего либо. А в жизни бывает еще и разборка.
Пример.
Есть свиная туша. Разделываем. Условно получаем 5 кг вырезки, 10 кг грудинки, окорок 15 кг, окорок 16 кг, 30 кг сала и т.д.
Разумеется из другой туши получим совсем другие массы.
Дальше. Из этих кусков начинаем собирать котлеты и пельмени.
Котлеты состоят из вырезки и сухарей
Пельмени из сала, окорока, муки, воды, яйца, соли и т.д.
Ну как себя чувствует объектная модель? Уже не уютно. А тут пока нет зарплаты, амортизации, транспортных расходов и т.д. Ведь эту тушу привезли. Потратили 10 литров бензина. Сколько литров должно упасть на пельмени? А сколько на котлеты?
Пример.
Есть свиная туша. Разделываем. Условно получаем 5 кг вырезки, 10 кг грудинки, окорок 15 кг, окорок 16 кг, 30 кг сала и т.д.
Разумеется из другой туши получим совсем другие массы.
Дальше. Из этих кусков начинаем собирать котлеты и пельмени.
Котлеты состоят из вырезки и сухарей
Пельмени из сала, окорока, муки, воды, яйца, соли и т.д.
Ну как себя чувствует объектная модель? Уже не уютно. А тут пока нет зарплаты, амортизации, транспортных расходов и т.д. Ведь эту тушу привезли. Потратили 10 литров бензина. Сколько литров должно упасть на пельмени? А сколько на котлеты?
У меня ж не только объединение объектов (сборка), но и разделение (разборка). Более того, предусмотрены механическое объединение-разделение объектов и химическое.
И что такое амортизация, мне известно. Правда, подсчет ее базируется на иных экономических принципах. Впрочем, допустимо учитывать и по существующей модели.
Перечисленные Вами вопросы у меня проработаны в деталях, так что система чувствует себя уютно.
И что такое амортизация, мне известно. Правда, подсчет ее базируется на иных экономических принципах. Впрочем, допустимо учитывать и по существующей модели.
Перечисленные Вами вопросы у меня проработаны в деталях, так что система чувствует себя уютно.
фишка в том что у нас даже такая наука как физика не может вам дать полную и точную информацию о объекте. А вы хотите такую информацию иметь внутри какой-то системы. Причем чем количество информации растет лавинообразно. По этой причине практически везде используются модели той или иной степени приближения. И чем детальнее объект тем сложнее его описать и тем сложнее описать все необходимые операции и связи. По этой причине при оценке автоматизации какого либо процесса первым делом ограничивают детализацию. Все что вы называете проблемами бух. учета таковыми не являются. Так-как на его уровне детализации их нет.
Я вовсе не хочу иметь полную информацию об объекте в рамках учета. То есть, конечно, хочу, но это невозможно. Но в рамках учетных баз я желаю иметь всю информацию об объекте, которая когда-либо была зарегистрирована бухгалтерами. Когда в производстве объект собирается из 1 млн. деталей, очевидно, что система учета должна позволять получать список всех этих деталей (системным образом, а не из технической документации), также список всех участвовавших в производстве орудий. Сейчас это невозможно, по крайней мере практически.
Но в рамках учетных баз я желаю иметь всю информацию об объекте, которая когда-либо была зарегистрирована бухгалтерами. Когда в производстве объект собирается из 1 млн. деталей, очевидно, что система учета должна позволять получать список всех этих деталей
У меня тут один вопрос зачем? Вот я имею список в 1 млн. деталей у объекта. Что дальше? Опять же где та ограничительная планка что является минимальной неделимой деталью? Просто вот не понятно что это дает конечному пользователю.
В станке полетела деталь. Я желаю знать того гада, который эту деталь произвел. Почему бы мне не узнать об этом из учетной системы? Такой подход кажется логичным.
Например. Ехал автобус по трассе. Взорвалась шина. Есть жертвы.
Расследование показало, что использована некачественная резина. Шинный завод зная серийный номер шины знает когда и из чего эта шина была сделана. Предположим шина сделана 18.09.2013, при этом использовался обрезиненный корд от 30.08.2013, а резина для его обрезинки варилась из каучука поставщика1 и поставшика2, серы поставщика3, масла поставщика4, а брак связан с плохим пластификатором поставщика 126 партия этого пластификатора поступила 02.03.2013. А еще пластификатор из этой партии отгружался еще 5 шинным заводам (что как бы намекает)
Такие системы прослеживаемости стоят громадных бабок, крайне сложны во внедрении и при этом отностиельно просты во внутренней архитектуре. Основная проблема не создать такую систему. Их куча на рынке. Главное их внедрить. А тут уходит романтика и наступает жизнь. Таких внедрений единицы.
И кстати, такие системы прекрасно себя чуствуют в рамках классических реляционных баз данных. Без всяких там объектов
Расследование показало, что использована некачественная резина. Шинный завод зная серийный номер шины знает когда и из чего эта шина была сделана. Предположим шина сделана 18.09.2013, при этом использовался обрезиненный корд от 30.08.2013, а резина для его обрезинки варилась из каучука поставщика1 и поставшика2, серы поставщика3, масла поставщика4, а брак связан с плохим пластификатором поставщика 126 партия этого пластификатора поступила 02.03.2013. А еще пластификатор из этой партии отгружался еще 5 шинным заводам (что как бы намекает)
Такие системы прослеживаемости стоят громадных бабок, крайне сложны во внедрении и при этом отностиельно просты во внутренней архитектуре. Основная проблема не создать такую систему. Их куча на рынке. Главное их внедрить. А тут уходит романтика и наступает жизнь. Таких внедрений единицы.
И кстати, такие системы прекрасно себя чуствуют в рамках классических реляционных баз данных. Без всяких там объектов
Описано совершенно верно.
Может быть, «куча и все внедрено», не знаю. Для меня вопросом было: как учитывать правильно. Я всего лишь разрабатывал учетную методологию, т.к. существующая меня не устраивала. Если такая уже имеется, мне остается горько сожалеть о потраченном времени.
Может быть, «куча и все внедрено», не знаю. Для меня вопросом было: как учитывать правильно. Я всего лишь разрабатывал учетную методологию, т.к. существующая меня не устраивала. Если такая уже имеется, мне остается горько сожалеть о потраченном времени.
при этом отностиельно просты во внутренней архитектуре.
Зато весьма сложны при взаимодействии а так же при трекинге описанного вами случая. Ну и да внедрение такой системы может быть ее сложнее чем ее разработка.
Значительная часть таких систем это модули взаимодействия со всевозможным оборудованием. Сканеры штрихкодов и радиометок, разнообразные весы и системы автоматической развески, станки, производственные линии, терминалы сбора данных и т.д.
Такие системы очень сложны в настройке для конкретного предприятия, чувствительны к производственному процессу. Достаточно сложно менять тех процесс, внутрицеховую и межцеховую логистику.
Вот настоящие трудности, а не моделирование самой системы и создание базы данных и отчетов. Хотя и там их много. Миллионы одновременных транзаций накладывают некоторые требования к производительности.
Такие системы очень сложны в настройке для конкретного предприятия, чувствительны к производственному процессу. Достаточно сложно менять тех процесс, внутрицеховую и межцеховую логистику.
Вот настоящие трудности, а не моделирование самой системы и создание базы данных и отчетов. Хотя и там их много. Миллионы одновременных транзаций накладывают некоторые требования к производительности.
Фишка в том что это не требуется. Фактически знать из чего состоит объект в случае бух. учета нам нужно редко. А когда же надо то можно использовать уже другую систему. Как вам ниже и пишут. Опять же ERP как система включает в себя бух. учет как подсистему работающую с ее объектами.
Про ERP ничего не могу сказать, не знаю.
Что касается «нам нужно редко», то Вы путаете его с «нельзя». Если кто-то захочет посмотреть, из каких частей состоит объект, то в рамках используемой учетной методологии не сможет. Это правильно?
Что касается «нам нужно редко», то Вы путаете его с «нельзя». Если кто-то захочет посмотреть, из каких частей состоит объект, то в рамках используемой учетной методологии не сможет. Это правильно?
Что касается «нам нужно редко», то Вы путаете его с «нельзя». Если кто-то захочет посмотреть, из каких частей состоит объект, то в рамках используемой учетной методологии не сможет. Это правильно?
Да правильно. Потому что если у меня подразумевается такая необходимость, то объект заводится частями и включается в него. К примеру если я покупаю у предприятия собранный компьютер, то они мне его продают как готовое изделие в виде одной позиции и разбить корректно его на составляющие со своей стороны не сможете.
А я разработал методологию, согласно которой корректно разбить купленный компьютер на составляющие возможно. Конечно, для этого придется воспользоваться данными из баз производителей. Смотрите мой пост «Бухгалтерская… социальная сеть», если еще не видели.
А я разработал методологию, согласно которой корректно разбить купленный компьютер на составляющие возможно.
Это возможно только в случае если поставщик вам предоставляет информацию о компонентах и их стоимости. А ему это смысла делать нет. Простой пример у компьютера на системной плате сгорает конденсатор, вы отдаете его в ремонт, они там меняют конденсатор. Будете ли вы учитывать конденсатор и списывать его, а дальше по новой ставить на баланс?
Речь не о практической применимости, а о потенциальных возможностях.
Ну представьте, как изобретателю автомобиля трезвомыслящий человек советует:
«На хрена тебе изобретать автомобиль? Проселочные дороги для езды на нем непригодны, к тому же в округе ни одной бензоколонки».
Ну представьте, как изобретателю автомобиля трезвомыслящий человек советует:
«На хрена тебе изобретать автомобиль? Проселочные дороги для езды на нем непригодны, к тому же в округе ни одной бензоколонки».
Речь не о практической применимости, а о потенциальных возможностях.
И какие у нас потенциальные возможности? У нас дофига данных и мы их можем по разному обрабатывать? Извините, но проблема как правило не в том как получить информацию и откуда. А как ее обработать и получить из нее что-то полезное. Без этого любой информационный блок представляет из себя информационный мусор. Вы бы пошли почитали по теме big data что-то уже в конце концов. Начать можно к примеру отсюда Большие данные
Спасибо, почитаю.
А как обрабатывать информацию, не Ваша задача. Пользователь сам сообразит, что ему нужно. За всех пользователей Вы все равно не решите. Применительно к бухгалтерии это означает, что не существует одного оптимального бухгалтерского отчета — пользователю необходимо предоставить возможность строить отчеты самому, с любой степенью детализации. Понимаете, с любой! Для этого данные должны быть полными, а не обрезанными. Тем более что речь идет о данных, которые уже учтены в системах разных производителей.
А как обрабатывать информацию, не Ваша задача. Пользователь сам сообразит, что ему нужно. За всех пользователей Вы все равно не решите. Применительно к бухгалтерии это означает, что не существует одного оптимального бухгалтерского отчета — пользователю необходимо предоставить возможность строить отчеты самому, с любой степенью детализации. Понимаете, с любой! Для этого данные должны быть полными, а не обрезанными. Тем более что речь идет о данных, которые уже учтены в системах разных производителей.
А как обрабатывать информацию, не Ваша задача.
ДА ЛАДНО?! Вы вообще в курсе что такое информатика? :) И вообще зачем необходимо программирование?
Пользователь сам сообразит, что ему нужно. За всех пользователей Вы все равно не решите.
У пользователя таблица в 10 миллионов позиций, что по вашему он с ней должен сделать?
пользователю необходимо предоставить возможность строить отчеты самому, с любой степенью детализации.
Вы в курсе откуда появился язык запросов SQL? Я подозреваю нет :) Опять же пользователь довольно редко может сказать какие данные и в каком виде ему надо. Я как человек регулярно делающий различные отчеты из информационных систем говорю.
1. Под обработкой я имею в виду построение бухгалтерских отчетов, то есть выходную информацию, а не операционную.
2. Пользователь построит отчет сам, а если не сможет этого сделать, воспользуется готовой структурой (шаблоном).
3. Нет, не в курсе. Вообще, пользователей надо приучать к компьютерной грамотности, а то: подай то, чего не знаю, принеси то, о чем не ведаю. Консультантам, конечно, хорошо, да…
2. Пользователь построит отчет сам, а если не сможет этого сделать, воспользуется готовой структурой (шаблоном).
3. Нет, не в курсе. Вообще, пользователей надо приучать к компьютерной грамотности, а то: подай то, чего не знаю, принеси то, о чем не ведаю. Консультантам, конечно, хорошо, да…
Под обработкой я имею в виду построение бухгалтерских отчетов, то есть выходную информацию, а не операционную.
А откуда он их возьмет?
2. Пользователь построит отчет сам, а если не сможет этого сделать, воспользуется готовой структурой (шаблоном).
Как он его построит САМ? Откуда возьмутся шаблоны?
3. Нет, не в курсе. Вообще, пользователей надо приучать к компьютерной грамотности, а то: подай то, чего не знаю, принеси то, о чем не ведаю. Консультантам, конечно, хорошо, да…
Информатика как и программирование по сути дела занимаются одной вещью обработкой информации и ее представлением. Язык же SQL придумали в свое время для того чтобы дать конечным пользователям не специалистам делать отчеты из баз данных. Как раз то что вы хотите. По факту это вылилось в то что теперь программисты скрывают этот слой от пользователя так-как он не хочет и не желает изучать данный язык.
1. Я рассматриваю структуру операционных данных — методологию. Возможности формирования отчетных форм — за пределами настоящего поста.
Пользователь возьмет данные для формирования отчета из системы, разумеется.
2. А как Вы строите сами, так и он построит. Не сможет, тогда купит шаблон у какой-нибудь фирмы или скачает в Интернете.
3. Понятно. Собственно, я так и думал. Полностью согласен. Вы о чем, вообще?
Пользователь возьмет данные для формирования отчета из системы, разумеется.
2. А как Вы строите сами, так и он построит. Не сможет, тогда купит шаблон у какой-нибудь фирмы или скачает в Интернете.
3. Понятно. Собственно, я так и думал. Полностью согласен. Вы о чем, вообще?
Я рассматриваю структуру операционных данных — методологию. Возможности формирования отчетных форм — за пределами настоящего поста.
Фишка в том что все чем вы оперируете весьма напоминает ООП в программировании.
А как Вы строите сами, так и он построит. Не сможет, тогда купит шаблон у какой-нибудь фирмы или скачает в Интернете.
Это и есть основная проблема. Чем больше у вас данных и чем больше у вас критериев и признаков тем сложнее это сделать. В определенный момент времени вообще не получается это сделать и приходится делать отчеты отчетов.
Вы о чем, вообще?
О том что вы пытаетесь придумать информатику и программирование :)
1. Я рад,
2. Не вижу проблемы. Строить отчеты можно с любой степенью детализации.
3. Нет, я пытаюсь придумать учетную методологию, при этом использую простейшие термины информатики. Мой дилетантский уровень в информатике Вы видите, а профессионального уровня в методологии не замечаете, т.к. он превышает Вашу компетенцию.
2. Не вижу проблемы. Строить отчеты можно с любой степенью детализации.
3. Нет, я пытаюсь придумать учетную методологию, при этом использую простейшие термины информатики. Мой дилетантский уровень в информатике Вы видите, а профессионального уровня в методологии не замечаете, т.к. он превышает Вашу компетенцию.
Можно придумать прекрасную модель учета, которую невозможно реализовать на практике и дальше что?
Я вот знаю как сделать межзвездный космический корабль. Правда для этого нужен антигравитатор и гипердвигатель. Ну и 8-9 тонн антивещества.
Невозможно? Технологии не позволяют. Ну не знаю. Придумайте что нибудь. Я же не техник. Я методист. Методика готова. Воплощайте!
Я вот знаю как сделать межзвездный космический корабль. Правда для этого нужен антигравитатор и гипердвигатель. Ну и 8-9 тонн антивещества.
Невозможно? Технологии не позволяют. Ну не знаю. Придумайте что нибудь. Я же не техник. Я методист. Методика готова. Воплощайте!
Некорректно, т.к. для реализации Вашей методологии нужны еще не изобретенные предметы. А были бы они изобретены, другое дело. Если бы Вы могли соорудить межзвездный космический корабль из пачки соли и батареек, купленных в ближайшем маркете, цены бы Вам не было.
Вот-вот. А в вашем случае это неизобретенные методы организации СУБД.
Я всегда удивлялся. Кто придумывает типовые формы первичных документов типа ТОРГ-12. Ведь они жутко неудобны для программного формирования и не слишком читабельны для человека. А в ручную их уже давно никто не заполняет.
А теперь понимаю. Такие же теоретики после ВУЗов не побывав на производстве идут в «науку» и изобретают кривожопые вилосипеды которые конечно едут, но плохо и не туда.
Я всегда удивлялся. Кто придумывает типовые формы первичных документов типа ТОРГ-12. Ведь они жутко неудобны для программного формирования и не слишком читабельны для человека. А в ручную их уже давно никто не заполняет.
А теперь понимаю. Такие же теоретики после ВУЗов не побывав на производстве идут в «науку» и изобретают кривожопые вилосипеды которые конечно едут, но плохо и не туда.
В своей профессии я прошел путь от низов до верхов. Правда, на верхах не задержался, мне там сильно не понравилось, пришлось отойти в сторонку. Не выдумывайте, коли не знаете.
Кстати, типовые формы первичных документов типа ТОРГ-12 меня жутко раздражают. Я бы не стал их изобретать ни в коем случае, тут Вы тоже неправы.
Кстати, типовые формы первичных документов типа ТОРГ-12 меня жутко раздражают. Я бы не стал их изобретать ни в коем случае, тут Вы тоже неправы.
Не вижу проблемы. Строить отчеты можно с любой степенью детализации.
Нет. Отчеты всегда ограничены детализацией информационной системы в целом.
Нет, я пытаюсь придумать учетную методологию, при этом использую простейшие термины информатики.
Право не стоит.
Мой дилетантский уровень в информатике Вы видите, а профессионального уровня в методологии не замечаете, т.к. он превышает Вашу компетенцию.
Пока вы не подтянете свой дилетантский уровень в информатике от вашего профессионального уровня в методологии заметно не будет. Вы будете обречено придумывать, то что до вас придумали другие люди. Которые обладали компетенцией и там и там. Так-как ваша методология опирается на автоматизированную систему учета
1. Разумеется. Я имею в виду, детализацию в рамках того, что зарегистрировано в системе.
2. Не стоит беспокойства, я попытаюсь.
3. Вы, вероятно, автоматизаторов учета считаете людьми, обладающими двухсторонней компетенцией? Ой ли? Они люди подневольные: какую херню им скажут автоматизировать, ту и автоматизируют, при этом методологическими вопросами задаваться не станут. Что в настоящий момент и наблюдается.
2. Не стоит беспокойства, я попытаюсь.
3. Вы, вероятно, автоматизаторов учета считаете людьми, обладающими двухсторонней компетенцией? Ой ли? Они люди подневольные: какую херню им скажут автоматизировать, ту и автоматизируют, при этом методологическими вопросами задаваться не станут. Что в настоящий момент и наблюдается.
Вы, вероятно, автоматизаторов учета считаете людьми, обладающими двухсторонней компетенцией? Ой ли?
Хорошему автоматизатору приходится. Опять же как правило там выделен специальный человек аналитик. Который дополнительно еще формализует процессы если они не формализованы.
Они люди подневольные: какую херню им скажут автоматизировать, ту и автоматизируют, при этом методологическими вопросами задаваться не станут.
Ничего подобного. Если нет формализации процессов, то ничего никто автоматизировать не будет. Так-как нечего автоматизировать.
Что в настоящий момент и наблюдается.
Еще раз напоминаю вам магическую аривиатуру ERP посмотрите а потом уже рассказывайте
1. Да-да, аналитик. Оригинальных текстов по методологии учета можно пересчитать по пальцам одной руки, зато аналитиков пруд пруди — тыщи.
2. Вы опять путаете программирование и методологию. Даже скверная методология может быть формализована (видимо, этим и занимаются Ваши аналитики).
3. А Вы в таком случае ознакомьтесь с формами учета, хотя бы по книге Помазкова.
2. Вы опять путаете программирование и методологию. Даже скверная методология может быть формализована (видимо, этим и занимаются Ваши аналитики).
3. А Вы в таком случае ознакомьтесь с формами учета, хотя бы по книге Помазкова.
Оригинальных текстов по методологии учета можно пересчитать по пальцам одной руки
Значит тема не особо актуальна и текущая методология учета вполне устраивает.
Вы опять путаете программирование и методологию. Даже скверная методология может быть формализована (видимо, этим и занимаются Ваши аналитики).
Скверная увы не может. Если у нее видны дыры сразу при анализе то методологию предлагают менять.
А Вы в таком случае ознакомьтесь с формами учета, хотя бы по книге Помазкова.
Сходил для интереса посмотрел. Ознакомился и что я из этого должен был почерпнуть? Они различаются только методикой учета первичных документов в любом случае номер операции/документа присутствует и там и там. И построить любую из форм учета по данным в базе большой проблемы не составит.
1. Полагаете, что до изобретения автомобиля текстов по автомобилестроению было маловато из-за того, что извозчики всех устраивали. Ну да, Вы правы.
2. Нет и еще раз нет. Вы опять путаете. Формализовать можно как счет на пальцах, так и счет на калькуляторе. Но это не означает, что методы продвинуты в равной степени.
3. А что, по-Вашему, я должен почерпнуть из ERP? Что такое реляционные базы, даже я понимаю. Подумаешь, программисты бессмысленно наворочали миллион функций и обозвали их красивой иностранной аббревиатурой. Данные навороты не обязательно составляют методологию.
2. Нет и еще раз нет. Вы опять путаете. Формализовать можно как счет на пальцах, так и счет на калькуляторе. Но это не означает, что методы продвинуты в равной степени.
3. А что, по-Вашему, я должен почерпнуть из ERP? Что такое реляционные базы, даже я понимаю. Подумаешь, программисты бессмысленно наворочали миллион функций и обозвали их красивой иностранной аббревиатурой. Данные навороты не обязательно составляют методологию.
А что вы собственно подразумеваете под методологией? Я вот подразумеваю формализацию тех или иных процессов для минимизации решения каких либо проблем. Активно используемые текущие методологии бух. учета в своей основе просты и из-за этого и используются. Да у нее есть ограничения.
Но какие из ограничений решает ваша методология не понятно. Если кратко сформулировать вашу методологию, то вы считаете что все проблемы в том что бух. учет не учитывает реальные объекты. И проблема как-то магическим образом рассосется, если мы их начнем их как-то учитывать. Вот на то как и что мы будет учитывать я как-то ответа так и не получил.
Но какие из ограничений решает ваша методология не понятно. Если кратко сформулировать вашу методологию, то вы считаете что все проблемы в том что бух. учет не учитывает реальные объекты. И проблема как-то магическим образом рассосется, если мы их начнем их как-то учитывать. Вот на то как и что мы будет учитывать я как-то ответа так и не получил.
С моей точки зрения, методология — это не формализация данных, а структура данных (операционных, имеется в виду). Формализовать можно что угодно, но этого мало: нужно создать оптимальную структуру. Чтобы понять, какая структура оптимальная и почему бухгалтерский учет так ей противится, мне пришлось разработать теорию, лежащую между учетом-экономикой, информатикой и философией. Полагаю, что Ваши аналитики никакой теорией не обладают, все их убеждения почерпнуты из учебников и законодательства и т.н. «практического» опыта. Если не согласны, спросите у них, что такое дебет и кредит. Сошлются на приход-расход, спросите, что такое приход-расход. Уверен, они не ответят. А в моей теории данные понятия проработаны досконально, на философском уровне.
В настоящем посте я свою теорию не рассматривал, краем бока задел. Поэтому ответа на вопрос обо всех преимуществах системы Вы получить не могли.
В настоящем посте я свою теорию не рассматривал, краем бока задел. Поэтому ответа на вопрос обо всех преимуществах системы Вы получить не могли.
С моей точки зрения, методология — это не формализация данных, а структура данных (операционных, имеется в виду). Формализовать можно что угодно, но этого мало: нужно создать оптимальную структуру.
Вы не сможете сделать универсальную структуру данных. Увы это не возможно. Возможно сделать только расширяемую. Это кстати еще до вас сделали. Есть вот такая вот штука Entity-Attribute-Value Model. Использовать ее можно, но трудоемко и ресурсоемко.
Чтобы понять, какая структура оптимальная и почему бухгалтерский учет так ей противится, мне пришлось разработать теорию, лежащую между учетом-экономикой, информатикой и философией.
Как говорит мой коллега «Жизнь богаче схемы». Я вам уже указывал на то что модель точно отображающую реальный объект не возможно.
Полагаю, что Ваши аналитики никакой теорией не обладают, все их убеждения почерпнуты из учебников и законодательства и т.н. «практического» опыта. Если не согласны, спросите у них, что такое дебет и кредит. Сошлются на приход-расход, спросите, что такое приход-расход. Уверен, они не ответят. А в моей теории данные понятия проработаны досконально, на философском уровне.
Дебет и кредит это вообще говоря вполне себе практические понятия и никакой философской подоплеки не имеют.
В настоящем посте я свою теорию не рассматривал, краем бока задел. Поэтому ответа на вопрос обо всех преимуществах системы Вы получить не могли.
А давайте вы сначала теорию, а уже потом остальное. А то как-то однобоко получается. Меня интересует что же такое дебет и кредит на философском уровне.
1.
Универсальную в рамках ограниченной задачи — можно.
2.
«Теория, мой друг, суха, но зеленеет древо жизни»?
Так Вы с Мефистофелем знакомы? Круто.
3.
Нет слов. А Вы еще спрашиваете, чего страшного?
4.
Польщен. Ступайте на мой сайт, раздел «Экаунтология». Читайте на здоровье.
Вы не сможете сделать универсальную структуру данных.
Универсальную в рамках ограниченной задачи — можно.
2.
Как говорит мой коллега «Жизнь богаче схемы».
«Теория, мой друг, суха, но зеленеет древо жизни»?
Так Вы с Мефистофелем знакомы? Круто.
3.
Дебет и кредит это вообще говоря вполне себе практические понятия и никакой философской подоплеки не имеют.
Нет слов. А Вы еще спрашиваете, чего страшного?
4.
А давайте вы сначала теорию, а уже потом остальное. А то как-то однобоко получается. Меня интересует что же такое дебет и кредит на философском уровне.
Польщен. Ступайте на мой сайт, раздел «Экаунтология». Читайте на здоровье.
Универсальную в рамках ограниченной задачи — можно.
У вас ограниченная задача? Что-то у меня такого ощущения нет.
«Теория, мой друг, суха, но зеленеет древо жизни»?
Так Вы с Мефистофелем знакомы? Круто.
Не только.
Нет слов. А Вы еще спрашиваете, чего страшного?
Да и буду продолжать спрашивать.
раздел «Экаунтология». Читайте на здоровье.
Открыл поискал по слову кредит и дебит. Никаких описаний этих понятий на филосовском уровне я там не наблюдаю. Можно ткнуть пальцем или процитировать где это написано?
1. Задача ограничена рамками учета.
2. Обширные у Вас связи!
3. Спрашивайте. Правда, сейчас прервусь на часок-другой, устал.
4. Дебет и кредит — искаженные приход и расход. О приходе-расходе читайте здесь.
2. Обширные у Вас связи!
3. Спрашивайте. Правда, сейчас прервусь на часок-другой, устал.
4. Дебет и кредит — искаженные приход и расход. О приходе-расходе читайте здесь.
Задача ограничена рамками учета.
Вы там собирались 10 миллионов деталей брать. Какая будет схема для того чтобы покрыть все необходимые данные?
Дебет и кредит — искаженные приход и расход. О приходе-расходе читайте здесь.
Почитал. Собственно никакой там философской подоплеки нет. Чисто утилитарный подход мы получили ресурс А (услугу, предмет что угодно) теперь нам его надо отобразить на баланс каким-то образом. В чем философия то? Обычная математика.
Всё правильно. Кроме бухгалтерского есть и другие виды учёта, например, складской, а также управление производством со своими деталями и т.д. ERP их объединяет, а пытаться запихнуть это всё в единую универсальную бухгалтерию совершенно ни к чему.
ERP их объединяет, потому что ущербная методология не может охватить все разом. Это признак ущербности, если учитывать что-либо приходится не учетными методами.
Так и вижу себе 3D учет небольшого угольного разреза с огромным количеством очень сложных механизмов, где каждый механизм (тот же проходческий щит) состоит из over 9000 сложных узлов. И все это, с точностью до гайки, введено в бухгалтерию, естественно с 3D моделью каждой гайки и связей между ними (читай сборочный чертеж).
И при необходимости ремонта правого ниппеля левого штуцера главного цилиндра транспортера, находящемся в четвертой шахте, пятом уровне, бухгалтер открывает учетную систему и тыкает навороченным манипулятором (нет, даже визуальным 3D интерфейсом показанным в к/ф Джони-Мнемоник) на замененные детали, в результате учетная программа по имеющейся схеме и указанным деталям производит расчет стоимости проведения ремонта, потому как для того, чтобы заменить тот самый ниппель надо разобрать треть того злосчастного транспортера.
PS. Не плодите сущностей без крайней на то необходимости.
И при необходимости ремонта правого ниппеля левого штуцера главного цилиндра транспортера, находящемся в четвертой шахте, пятом уровне, бухгалтер открывает учетную систему и тыкает навороченным манипулятором (нет, даже визуальным 3D интерфейсом показанным в к/ф Джони-Мнемоник) на замененные детали, в результате учетная программа по имеющейся схеме и указанным деталям производит расчет стоимости проведения ремонта, потому как для того, чтобы заменить тот самый ниппель надо разобрать треть того злосчастного транспортера.
PS. Не плодите сущностей без крайней на то необходимости.
Очень наглядно, мне понравилось. Почему нет, если компьютерные мощности позволяют? Не большая фантастика, чем тема колонизация других планет, которая на Хабре на ура проходит.
А ссылку напрасно дали, с бритвой Оккама я знаком.
А ссылку напрасно дали, с бритвой Оккама я знаком.
Фишка в том что для указанной выше процедуры 3D-интерфейс не нужен. Достаточно простой формы выбора и это кстати будет быстрее и проще в использовании и что самое важное на то как происходит расчет не влияет вообще.
Вы правы.
При помощи 3D-интерфейса я просто привлек внимание к проблеме объектности. Многие, особенно из айтишников, не понимают, что такое объектность и считают, что в бухгалтерии объектность давно реализована (видимо, на том основании, что объектность реализована в программировании). Однако программирование и учетная методология — не близнецы-братья. Вот я и пытаюсь объяснить, что такое объектность и какие возможности она предоставляет в принципе.
При помощи 3D-интерфейса я просто привлек внимание к проблеме объектности. Многие, особенно из айтишников, не понимают, что такое объектность и считают, что в бухгалтерии объектность давно реализована (видимо, на том основании, что объектность реализована в программировании). Однако программирование и учетная методология — не близнецы-братья. Вот я и пытаюсь объяснить, что такое объектность и какие возможности она предоставляет в принципе.
Многие, особенно из айтишников, не понимают, что такое объектность и считают, что в бухгалтерии объектность давно реализована
Она и в программировании то не реализована. То что называется ООП позволяет делать фактически модель объекта, в рамках конкретной предметной области, но не более. В случае автоматизации бухгалтерия это просто еще одна предметная область. И что хорошо со своими устоявшимися терминами и метологиями. Не без тараканов там конечно, но во многих областях еще хуже.
В программировании хоть разные подходы реализованы, множество языков программирования. А в бухгалтерии? Единственная применяемая на практике методология, которой от 500 до 2000, по разным прикидкам. И за шаг вправо, шаг влево расстреливают на месте. Каково?
Какие разные? Если по парадигмы то их там тоже весьма немного. Процедурная, функциональная, объектная, декларативная. И то все это многообразие надо так-как у программирования нет четкой предметной области. Так-как это метод сделать что-то без участия человека. В случае бух учета предметная область четкая, по этой причине методология тоже одна. Вы же не негодуете на наличие системы Си и то что надо это мерить в метрах.
Про программирование на стану спорить, не моя область. Готов выслушать все, что скажут.
Что касается бухгалтерии, я в ней по уши сижу десятилетия. Предметная область действительно одна, однако методология ошибочная, извращенная, пользоваться ей при компьютерном учете нельзя, если по-хорошему.
Что касается бухгалтерии, я в ней по уши сижу десятилетия. Предметная область действительно одна, однако методология ошибочная, извращенная, пользоваться ей при компьютерном учете нельзя, если по-хорошему.
В чем извращенность то? У нее очень жестко ограничена детализация и это позволяет вывести метологию которая хорошо работает в пределах этой детализации.
Неужели Вы сами не видите? Боже ж ты мой, насколько плохо программисты разбираются в методологии. И вечно путают ее с программированием.
Вообще, на эту тему книги написаны. Кое-о-чем в посте упоминалось: дебет-кредит, не имеющие соответствия в реальности; учет объектов, не имеющих соответствия в реальности. Достаточно?
Вы свои ощущения помните, когда впервые столкнулись с бухгалтерией? Хорошо было? Сейчас-то я понимаю, привыкли, пообтерлись и все стало казаться нормальным.
Вообще, на эту тему книги написаны. Кое-о-чем в посте упоминалось: дебет-кредит, не имеющие соответствия в реальности; учет объектов, не имеющих соответствия в реальности. Достаточно?
Вы свои ощущения помните, когда впервые столкнулись с бухгалтерией? Хорошо было? Сейчас-то я понимаю, привыкли, пообтерлись и все стало казаться нормальным.
Неужели Вы сами не видите?
Нет. В данный момент нет альтернативной методологии. И если бы текущая была настолько плоха как вы уверяете, то их была бы не одна и не две.
дебет-кредит, не имеющие соответствия в реальности; учет объектов, не имеющих соответствия в реальности. Достаточно?
«Виртуальные деньги» неизбежны. У нас всегда есть задержка между тем что мы делаем и то когда это попадает в систему учета.
Вы свои ощущения помните, когда впервые столкнулись с бухгалтерией? Хорошо было?
Точно так же как и в случае когда я взялся за язык программирования без чтения по нему документации. Важно прочитать документацию для базового понимания что происходит. Опять же бух. учет это не серебряная пуля, как и любой другой инструмент он имеет свои ограничения. Я не зря про предметную область и детализацию упомянул. Проблемы возникают как раз когда начинают натягивать ужа на ежа. Проще говоря пытаются решить проблемы другого характера при помощи бух. учета.
1.
Вы просто не в курсе, сколько таких методологий изобреталось. Множество. Почитайте хотя бы про Езерского. А что применяется одна, спасибо советской власти, которая всякое разнообразие (свободомыслие) устранила декретами да расстрелами.
2. При чем здесь виртуальные деньги? Проблема ажура — совсем не о том.
3. Меня интересуют проблемы учета. Решать проблемы учета логично при помощи учетной методологии, а не всяких программистских прибамбасов.
И если бы текущая была настолько плоха как вы уверяете, то их была бы не одна и не две.
Вы просто не в курсе, сколько таких методологий изобреталось. Множество. Почитайте хотя бы про Езерского. А что применяется одна, спасибо советской власти, которая всякое разнообразие (свободомыслие) устранила декретами да расстрелами.
2. При чем здесь виртуальные деньги? Проблема ажура — совсем не о том.
3. Меня интересуют проблемы учета. Решать проблемы учета логично при помощи учетной методологии, а не всяких программистских прибамбасов.
Вы просто не в курсе, сколько таких методологий изобреталось. Множество. Почитайте хотя бы про Езерского. А что применяется одна, спасибо советской власти, которая всякое разнообразие (свободомыслие) устранила декретами да расстрелами.
Я верю что придумывалось много. Но фактически по всему миру активно применяется только одна методология. Значит у других методологий нет явных приемуществ. Опять же мир СССР не ограничивается как сами понимаете.
При чем здесь виртуальные деньги? Проблема ажура — совсем не о том.
При том. Фактически надо понимать что многие вещи выходят за рамки предметной области бух. учета, но никто не мешает ее дополнять.
Меня интересуют проблемы учета. Решать проблемы учета логично при помощи учетной методологии, а не всяких программистских прибамбасов.
Проблемы учета надо решать при помощи математических моделей, на основе которых уже выводить учетную методологию. А уже дальше реализовывать ее в программистких прибамбасах.
1. На самом деле наряду с двойной (диграфической) применяется и простая (униграфическая) модель. Уже сейчас, в Плане счетов. Не так все просто.
2. А Вы часто дополняете программистские решения бухгалтерскими наработками? Наверное, обходитесь без этого. Вот и бухгалтеры должны обходиться. Методы — одно, программирование методов — другое.
3. Названные методы должны реализовываться при помощи математических моделей, тут я с Вами согласен.
2. А Вы часто дополняете программистские решения бухгалтерскими наработками? Наверное, обходитесь без этого. Вот и бухгалтеры должны обходиться. Методы — одно, программирование методов — другое.
3. Названные методы должны реализовываться при помощи математических моделей, тут я с Вами согласен.
1. На самом деле наряду с двойной (диграфической) применяется и простая (униграфическая) модель. Уже
сейчас, в Плане счетов. Не так все просто.
Как правило это простая модель применяется не в самом бух. учете, а в различных системах учета типа биллингов.
А Вы часто дополняете программистские решения бухгалтерскими наработками?
Если к примеру модули 1С типа склад и т.п. называть бухгалтерскими наработками, то этим много кто занимается.
Вот и бухгалтеры должны обходиться. Методы — одно, программирование методов — другое.
Проблема в том что ваш подход требует автоматизированных средств. Без них в системе делать нечего. А вот обычный бух. учет позволяет использовать для ведения бумагу. А если вы используете автоматизированную систему то мы приходим к такой штуке как ERP.
1. В самом бухгалтерском учете. Это же в План счетов заложено.
2. Вам видней.
3. Ничего не имею против ERP, просто пытаюсь объяснить, что в таком случае двойную запись придется менять. А это уже методология. Двойная запись, реализованная в ERP, — это классическое забивание гвоздей микроскопом.
2. Вам видней.
3. Ничего не имею против ERP, просто пытаюсь объяснить, что в таком случае двойную запись придется менять. А это уже методология. Двойная запись, реализованная в ERP, — это классическое забивание гвоздей микроскопом.
В самом бухгалтерском учете. Это же в План счетов заложено.
Ну флаг им в руки. Я обычно в системах учета наблюдал такие штуки.
Ничего не имею против ERP, просто пытаюсь объяснить, что в таком случае двойную запись придется менять. А это уже методология. Двойная запись, реализованная в ERP, — это классическое забивание гвоздей микроскопом.
А зачем? ERP может вообще без бух. учета использоваться. А когда он нужен, то там идет по сути дела выгрузка и упрощение данных для бух. учета.
А зачем? ERP может вообще без бух. учета использоваться. А когда он нужен, то там идет по сути дела выгрузка и упрощение данных для бух. учета.
Не сомневаюсь, что программисты способны быстро и качественно изобрести новую методологию учета. Возможно, ERP — она самая. Но судя по тому, что автоматизаторы учета пишут в своих текстах, они в плане учетной методологии не сильно преуспели, совсем зеленые, ну вроде меня в информатике.
Что же такого они пишут страшного?
А то же, что и Вы. По их мнению, методология учета — это то, что они запрограммируют. А что можно запрограммировать, не понимая проблем учета? Смешно.
Эх. Давайте начнем с простого. Зачем был придуман бух. учет? Цель была вполне утилитарная знать сколько у нас ресурсов ушло (услуги, товары и т.п.) и сколько у нас ресурсов пришло. Какие тут проблемы в методологии могут быть? Как ушло и пришло? Что делать если часть зерна испортилось?
Не стоит, мы так далеко от темы забредем.
Но если о ресурсах, где Вы видели такие ресурсы как «амортизация», «резервы», «расходы будущих периодов», «продажи» и проч.? Цель-то утилитарная, да вот решение подкачало.
Но если о ресурсах, где Вы видели такие ресурсы как «амортизация», «резервы», «расходы будущих периодов», «продажи» и проч.? Цель-то утилитарная, да вот решение подкачало.
<sarcasm>
Что-то так и представляется телефонный разговор:
— Алло, бухгалтерия? Посмотрите пожалуйста, сколько у нас на складе осталось больших белых хреновин с четырьмя ножками?
</sarcasm>
Что-то так и представляется телефонный разговор:
— Алло, бухгалтерия? Посмотрите пожалуйста, сколько у нас на складе осталось больших белых хреновин с четырьмя ножками?
</sarcasm>
Мне кажется, не стоило в статье употреблять 3D. Звучит не к месту совсем. Про новые подходы в бухгалтерии знать очень полезно, ибо вы правы насчет единственной и устаревшей неизвестно на сколько лет технологии. Ситуация напоминает ту, что была бы разработке, будь в ней «единый стандартный великий язык» и даже за обсуждение других языков сразу бы заклевывали до смерти.
Кстати, давно вот хотелось узнать, как устроен учет такой штуки.
У меня есть куча ресурса. Назовем его «зерно». И я трейдер, то есть продаю и покупаю зерно разными порциями, от килограмма, до тысяч тонн. Продаю и покупаю постоянно и все с одного склада.
И дальше начинается веселье. Я хочу знать прибыль от каждой из операций. Например, я купил килограмм, а потом его продал в составе тонны. Прикол в том, что за это время еще и цена на рынке упала. Это в плюс или минус? А в какой? А еще круче — я купил тонну, половину распродал по килограмму, а остальное толкнул в составе тысячи тонн. И все это по разным ценам. Стоило мне связываться с каждой из этих операций?
А прибыль по каждой операции мне нужна для ретроспективного анализа и настройки системы принятия решений о покупке/продаже и выставлении цены. Т.е. это очень важная штука, так как речь идет о бирже и о том, что я не могу продать всем желающим и купить у всех желающих, т.к. в этом случае просто разорюсь. А цена все время колеблется.
Вот как такое учитывать?
У меня есть куча ресурса. Назовем его «зерно». И я трейдер, то есть продаю и покупаю зерно разными порциями, от килограмма, до тысяч тонн. Продаю и покупаю постоянно и все с одного склада.
И дальше начинается веселье. Я хочу знать прибыль от каждой из операций. Например, я купил килограмм, а потом его продал в составе тонны. Прикол в том, что за это время еще и цена на рынке упала. Это в плюс или минус? А в какой? А еще круче — я купил тонну, половину распродал по килограмму, а остальное толкнул в составе тысячи тонн. И все это по разным ценам. Стоило мне связываться с каждой из этих операций?
А прибыль по каждой операции мне нужна для ретроспективного анализа и настройки системы принятия решений о покупке/продаже и выставлении цены. Т.е. это очень важная штука, так как речь идет о бирже и о том, что я не могу продать всем желающим и купить у всех желающих, т.к. в этом случае просто разорюсь. А цена все время колеблется.
Вот как такое учитывать?
Согласно предложенной методологии продавайте по зернышку. ;)
Причем в учете должно быть отражено размер зернышка, его вес, влажность, количество клейковины и прочие параметры. Только тогда можно будет ответить на Ваши вопросы в любом разрезе.
3D модель каждого зернышка должны быть обязательны, а то кому-то надо круглое зерно, а кому-то продолговатое, но не слишком.
Причем в учете должно быть отражено размер зернышка, его вес, влажность, количество клейковины и прочие параметры. Только тогда можно будет ответить на Ваши вопросы в любом разрезе.
3D модель каждого зернышка должны быть обязательны, а то кому-то надо круглое зерно, а кому-то продолговатое, но не слишком.
Неверная трактовка. Вес, влажность, количество клейковины и прочие параметры могут относиться как к отдельному зернышку, так и к партии зерна в целом. То есть объектом может быть и отдельное зерно, и вся партия.
А этого недостаточно :) Зерно ведь лопатой гребут, я реально не знаю, куда ушло в итоге каждое отдельное зерно или каждый отдельный килограмм. Пул обезличенный в любом случае.
Ясно.
Дело в том, что при невозможности идентифицировать объекты невозможно и рассчитать корректный результат. ФИФО, ЛИФО и прочие прелести — слышали, наверное? В этом случае остаются возможности манипулировать финансовым результатом. Собственно, Вы бы смогли бы манипулировать им и при полной идентификации. Представьте, что в одном амбаре зерно по 100 руб., а в другом по 80 руб. Если Вы продаете зерно по 120 руб., то финансовый результат зависит от того, из какого амбара Вы произведете отгрузку. В одном случае прибыль составит 20 руб., во втором — 40 руб.
Решения нет. Просто при хранении зерна в разных амбарах (то есть идентификации) Вы сможете иметь реальный, а не воображаемый результат. Насколько велики различия, решайте сами, Вам видней.
Дело в том, что при невозможности идентифицировать объекты невозможно и рассчитать корректный результат. ФИФО, ЛИФО и прочие прелести — слышали, наверное? В этом случае остаются возможности манипулировать финансовым результатом. Собственно, Вы бы смогли бы манипулировать им и при полной идентификации. Представьте, что в одном амбаре зерно по 100 руб., а в другом по 80 руб. Если Вы продаете зерно по 120 руб., то финансовый результат зависит от того, из какого амбара Вы произведете отгрузку. В одном случае прибыль составит 20 руб., во втором — 40 руб.
Решения нет. Просто при хранении зерна в разных амбарах (то есть идентификации) Вы сможете иметь реальный, а не воображаемый результат. Насколько велики различия, решайте сами, Вам видней.
Ну, это проблема логистики — отгрузить именно те зерна, которые Вы продали. В любом другом случае возникнет пересортица и придется проводить инвентаризацию каждого зернышка ;). Заодно и проведут сортировку на предмет сохранности и изменения свойств в процессе хранения.
Перейдем к описанной в статье методологии:
Далее, описано, что возможно объединение объектов в более сложную сущность. В Вашем случае — партия зерна, которая будет состоять объектов «зернышки». В этом случае можно будет говорить об средней влажности, клековиности и т.д. продаваемого нового объекта — партии зерна.
С точки зрения учета получается очень даже неплохо. Кроме одного — БД для такого учета будет, мягко говоря, размером с элеватор, где это самое зерно хранится. :)
PS. Прошу считать, что я везде проставил тег «сарказм».
Перейдем к описанной в статье методологии:
Для создания 3D бухгалтерии необходим пообъектный подход, в соответствии с которым одна реальная вещь, находящаяся в имущественном комплексе, соответствует одному объекту базы данных.
Далее, описано, что возможно объединение объектов в более сложную сущность. В Вашем случае — партия зерна, которая будет состоять объектов «зернышки». В этом случае можно будет говорить об средней влажности, клековиности и т.д. продаваемого нового объекта — партии зерна.
С точки зрения учета получается очень даже неплохо. Кроме одного — БД для такого учета будет, мягко говоря, размером с элеватор, где это самое зерно хранится. :)
PS. Прошу считать, что я везде проставил тег «сарказм».
Небольшая неточность.
В партии объединенных зерен будут прослеживаемы параметры первоначальных объектов, по ссылкам на них, хотя можно будет и подсчитать средние параметры.
Ну и по поводу элеватора — не уверен. Тем более что потребные мощности в расчет не принимаются, с ними можно и подождать, в конце концов.
В партии объединенных зерен будут прослеживаемы параметры первоначальных объектов, по ссылкам на них, хотя можно будет и подсчитать средние параметры.
Ну и по поводу элеватора — не уверен. Тем более что потребные мощности в расчет не принимаются, с ними можно и подождать, в конце концов.
Описанная Вами ситуация известна и давно обсуждается, минимум полсотни лет. Хотя не скажу, что найдено устраивающее всех решение. Описывать все варианты учета, извините, не могу — это слишком долго.
Если интересуетесь, почитайте специальную литературу, к примеру книжку:
Бюрло А., Жио А., Бар А. де, Тоден К. Бухгалтерский учет и инфляция. – М., Международный центр финансово-экономического развития, 1998.
Если интересуетесь, почитайте специальную литературу, к примеру книжку:
Бюрло А., Жио А., Бар А. де, Тоден К. Бухгалтерский учет и инфляция. – М., Международный центр финансово-экономического развития, 1998.
Сразу видно, что автор не сталкивался с бухгалтерами, которым ты пытаешься объяснить прелести новой версии чего либо, а у них в это время прервался разговор про саженцы и курица остывает в микроволновке.
Sign up to leave a comment.
Бухгалтерия 3D