ЭКАУНТОЛОГИЯ
Сайт, посвященный истории бухгалтерского учета и его неминуемому превращению в компьютерный учет
Электронная форма учета - Форум
Меню сайта

Войти

Случайная картинка

Умная мысль
Как двуликий Янус, бухгалтерия обращена одною стороною к прошлому, а другою – к будущему.
В.Д. Белов

Старинный термин
ПЕРЕЕМ – в Древней Руси: вознаграждение за помощь в обнаружении беглого холопа или преступника.

Последняя картинка

Социальные сети

Статистика

Время жизни

Приветствую Вас, Гость · RSS 29.03.2024, 18:39

Личка:

[ Новые сообщения · Участники · Правила форума · Поиск · RSS ]

Уважаемые посетители!
Для участия в обсуждениях, а также инициативного создания тем для обсуждений Вам необходимо зарегистрироваться и зайти на сайт в качестве пользователя (см. "Войти" на левой панели).


  • Страница 1 из 1
  • 1
Модератор форума: mikejum  
Форум » Обсуждаем... » Нормативная база » Электронная форма учета (документация принципов учета с использованием ЭВМ)
Электронная форма учета
serbodДата: Вторник, 18.03.2014, 16:22 | Сообщение # 1
Группа: Пользователи
Сообщений: 12
Предлагаю автору в рамках проекта "Учетное Мироздание" разработать методику учета при помощи современных технологий (компутеры, принтеры, интернет, сотовая связь...). Но так, чтобы была возможность "откатиться" на бумажное ведение учета, или чтобы бумажный учет мог относительно безболезненно сосуществовать с электронным. И по возможности избежать многих устаревших сложностей.

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

Я сам предпочитаю сочетать машиночитаемую форму (коды, ссылки) с человекочитаемой. Например, под штрихкодом обязательно нужен человекочитаемый текст, а счет в электронном виде должен включать не только набор ИНН/КПП/БИК/Расч.сч, но и названия организации, города и банка.

Также, при сохранении или передаче данных предпочитаю давать краткую расшифровку ссылок на товары и контрагентов. То есть, если сохраняется журнал расходных накладных за год, то он хоть и разбивается на 3 части (таблица товаров, таблица контрагентов, таблица строк в которых есть ссылки на товары и контрагентов), но к каждой ссылке прилагается строка с кратким наименованием. И формат данных такой, что он легко читается человеком в текстовом редакторе. Разделители-запятые, например. Ничего, что данные получаются избыточными - алгоритмы сжатия это запросто переваривают. Зато при повреждении файла его легко восстановить вручную, и потеря ссылок не так критична. По этим причинам я избегаю популярный, но сложный для невооруженного глаза XML.


Сообщение отредактировал serbod - Вторник, 18.03.2014, 16:35
 
mikejumДата: Вторник, 18.03.2014, 16:47 | Сообщение # 2
Группа: Администраторы
Сообщений: 181
Спасибо за интерес к "Учетному мирозданию". Однако, Вы ознакомились с проектом слишком поверхностно.
"Учетное мироздание" - это и есть сетевой компьютерный учет, таким оно мыслилось с самого начала. Никакого деления на бухгалтерский/управленческий/финансовый/бюджетный/оперативный учет не предполагается - это само собой разумеется.
Откат на бумажный учет всегда возможен, но не интересен. Зачем допускать возможность отката к каменным топорам? Лучше вглядываться вдаль, по-моему.

Если Вы желаете получить об "Учетном мироздании" более полное представление, в первую очередь читайте Манифест ("Всем! Всем! Всем!" на левой панели), затем на правой панели - "Принципиальная схема Мироздания", "Экономические законы Мироздания" и "ТЗ на Учетное мироздание".
Если возникнут вопросы, я буду рад ответить.
 
serbodДата: Вторник, 18.03.2014, 17:08 | Сообщение # 3
Группа: Пользователи
Сообщений: 12
Просмотрел (не особо тщательно, каюсь) манифест и ТЗ. Названия "Принципиальная схема Мироздания" и "Экономические законы Мироздания" меня пугают. Вернее, пугает слово Мироздание в этом контексте, попахивает психушкой. Нельзя ли придумать какой-нибудь нейтральный политкорректный синоним? Или хотя бы брать "Мироздание" в кавычки?

Бумажный учет, к сожалению, нужен. Хотя бы в виде отражения электронного, с возможностью ручной корректировки. Я обычно вижу учет в виде цифрового мусора в файлах, который управляется магией "черного ящика" - программы. И если программа ломается (а такое, увы, бывает), то весь учет так и остается мусором. Ладно, хрен с ним, но хотя бы архивные копии нужно сохранять в более-менее читаемом формате. А то бывает, что уже через 10-20 лет технология сдохнет, а файл уже нечем открыть.

И еще, не вижу особого смысла делить объединение и разделение объектов на физические процессы (разборка/резка/расплавление). Оставить только логический принцип - был один объект - стало много других. И добавлять произвольные свойства для операции.
 
mikejumДата: Вторник, 18.03.2014, 17:29 | Сообщение # 4
Группа: Администраторы
Сообщений: 181
А мне слово "Мироздание" нравится (хотя психушкой попахивает, конечно). smile
Если кто-нибудь возьмется реализовать мои идеи, у него будет полная возможность придумать что-нибудь более политкорректное. Мне вот гораздо больше "Учетного мироздания" не нравится "Экаунтология"... Однако поезд уехал: десять лет назад сглупил, теперь не воротишь.

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

Разборка, резка, расплавление - не от фонаря придумано, а аналогично тому, как в природе. Грубо говоря, собранную вещь можно и расплавить, и разобрать, а сплавленную - только расплавить. Если, к примеру, железную и медную вещи сначала собрать, а потом разобрать, получатся железная вещь и медная вещь, первоначальные. А если их сначала сплавить, а потом разрезать, получатся две новые вещи из сплава. Большая разница.

Произвольные свойства для операций предусмотрены.
 
serbodДата: Вторник, 18.03.2014, 17:52 | Сообщение # 5
Группа: Пользователи
Сообщений: 12
Не вижу принципиальной разницы между разборкой и расплавлением. Это просто названия свойств операций, сути вещей оно не меняет. Принципиальная разница только в "наследовании" свойств, что стоит изучить поподробнее.

Я пытаюсь мысленно приложить эту систему к банальному торгово-сервисному учету, где у товара/услуги есть денежный эквивалент, с которым производят всякие противоестественные операции. Да вот что-то слабо получается. "Мироздание" хорошо подходит для учета реальных объектов, а как параллельно учитывать бабло?

В "Экономических законах природы" я ответа не нашел. Только философию на тему, что деньги - зло. Но на данный момент это неизбежное зло, которое приходится учитывать. Так вот, как это делать? Как правильно забивать микроскопом гвозди, если молоток мы отвергаем как устаревший инструмент? Я уверен, что Мироздание с этим справится.
 
mikejumДата: Вторник, 18.03.2014, 18:00 | Сообщение # 6
Группа: Администраторы
Сообщений: 181
Верно, разница в наследовании свойств - для того и сделано.

О том, как и где применить, читать лучше здесь:
http://habrahabr.ru/post/186874/
http://habrahabr.ru/post/181077/

По-хорошему, деньги следует учитывать не в качестве объекта, а как числовое свойство вещей (продолжительность воздействия, оказываемого на них человеком, - то есть продолжительность труда). Однако, за отсутствием коммунизма, можно и в качестве объекта, система это допускает. В целом Вы понимаете верно, за одним исключением. Сами по себе деньги не зло, а объективная необходимость: зло - современные правила их использования.
 
serbodДата: Вторник, 18.03.2014, 19:55 | Сообщение # 7
Группа: Пользователи
Сообщений: 12
Я делал универсальную систему учета бюджета, где два вида сущностей - кошельки (счета) и деньги, а все остальное - их свойства. Всего три операции - приход, расход, перемещение. И она была весьма всеобъемлющая. На ней работали кадры, авансовые отчеты, банк-касса и немного торговля и склад. Вернее, торговля и склад работали отдельно, но их операции автоматом учитывались в бюджете. В принципе, это было похоже на план счетов, но без двойной записи, актива-пассива и прочих заморочек.

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

Например, школьник подписан на завтраки. В заданное время в базе данных формируется счет за завтрак, при условии что ученик в школе (прошел через турникет). Если счет не отменят вручную, то к вечеру этот счет оплачивается из карточного счета (виртуального кошелька) ученика. Также ученик может самостоятельно приобрести еду в торговом автомате или буфете по карточке. В конце месяца в зависимости от остатка на карточном счету ученика выставляется счет родителям. Ученик может самостоятельно пополнить свой карточный счет наличкой через платежный терминал. Родители могут получать СМС-уведомления об операциях ученика и других событиях в школе, и это тоже учитывается и оплачивается по тарифам.

Как можно для этой системы (которая вполне подходит под определение бухгалтерии будущего) применить вашу теорию учета?


Сообщение отредактировал serbod - Вторник, 18.03.2014, 19:56
 
mikejumДата: Вторник, 18.03.2014, 20:31 | Сообщение # 8
Группа: Администраторы
Сообщений: 181
Что называется, быка за рога!..
Понимаете, учет - прикладная дисциплина, зависящая от постановки задачи. Попросту говоря, чтобы корректно учитывать, нужно корректно хозяйствовать: любое отступление от нормы хозяйствования ведет к учетным извращениям. Представить учет, какой Вы описали, в своей системе я могу, но принимая во внимание данную оговорку.
Дайте сообразить.
1. За субъектов можно считать как семью (одна семья - один счет), так и каждую голову поодиночке (если, допустим, кошельки и ребенка и каждого из родителей разные).
2. Поступление денег на кошелек - в обычном порядке: т.е. мою систему можно (и даже напрашивается) связать с платежными системами. Деньги поступили или выбыли - соответствующая запись в учетной системе.
3. Ребенок купил булочку, отлично: приход булочки, расход денег. (Когда скушал, придется записать расход булочки, иначе булочки станут накапливаться).
4. Плата за СМС-уведомления: расход денег. Вообще, по теории это услуга (должно быть воздействие орудия на предмет), но в данном случае по-другому не сделаешь (поскольку экономика не моя). То есть в расходе денег (операции) помечается цель списания, все стандартно.
5. Подписан на завтраки: по теории учета - обязательство, у меня это называется будущей операцией. Школа (тоже субъект) обязуется передать завтрак, а ребенок обязуется его оплатить. Запись осуществляется в момент прохода ребенка (допустим, в 8-00) через турникет на окончание дня (14-00). Таким образом, если до 14-00 запись не будет отменена вручную, она станет действительной: будет считаться, что школа передала завтрак, а со счета списана соответствующая сумма. Ну и маленькие замечания: а) если денег на счете ребенка не хватает, операция не сможет быть записана (отрицательный остаток в системе не предусмотрен), б) школе придется предварительно учесть завтраки в качестве объектов, чтобы было чего передавать школьникам. А можно "приготовить" завтраки из отдельных продуктов. А если еще поставщик продуктов ведет учет в системе....

Да нет, все достаточно типично: в теории не вижу проблем.
 
serbodДата: Среда, 19.03.2014, 15:42 | Сообщение # 9
Группа: Пользователи
Сообщений: 12
1. Счета заведены на каждого человека, пользователя системы - родитель, ученик, сотрудник школы. Родитель может управлять счетами своих детей - пополнять, устанавливать лимиты, подписывать на услуги. Школьное комплексное питание - формально услуга, потому что конкретный состав комплексных блюд на каждый день меняется.

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

3. Необходимость учета поедания булочки показывает несовершенство такой системы. =) Логически, булочка выбывает из учета. Конечно, в глобальном смысле булочка не выбывает, ученик может ее обменять на что-то. Но вести учет такой степени детализации не представляется возможным. В плане кошелька все проще - происходит расход денег с пометкой "булочка".

И так далее. Я хочу сказать, что на практике схема учета на основе денег и кошельков оказывается гораздо проще и удобнее, чем объектно-ориентированная. Но в ней не хватает материального учета, когда операция не имеет денежного эквивалента, этот эквивалент неизвестен или не пригоден для учета. И вот тут помогает ваша схема с операциями типа слияние (А, B => C), разборка (C => A, B), преобразование ( A => B ). И мне интересно, как бы их красиво совместить.
 
mikejumДата: Среда, 19.03.2014, 16:47 | Сообщение # 10
Группа: Администраторы
Сообщений: 181
1. Счета заведены на каждого? Это правильно.

2. Как Вы понимаете, заморочки отдельных платежных систем к теории учета отношения не имеют.
Не понял, что значит: внутри одного кошелька могут лежать другие.

3. Никакой необходимости учета поедания булочки нет. Булочки можно не учитывать, никто не неволит. Учитывается то, что необходимо.

4. Не знаю, как учет реализуется в объектно-ориентированной системе, но по поводу схемы учета на основе денег и кошельков могу высказаться.
Вы не понимаете, насколько данные системы близки. Можно сказать, что Ваша система - костяк моей. Вот смотрите.
Кошелек у Вас - это субъект у меня. Деньги у Вас - это объект у меня. То есть не деньги перемещаются между кошельками, а объекты перемещаются между субъектами (при этом деньги - один из объектов, объект с названием "Деньги". А могут быть объекты с названиями "Шуруп", "Стол" и т.д.).
А теперь об отличиях систем, от мелкого и бОльшему.
1). Передача объектов между субъектами осуществляется по взаимной договоренности. То есть первый субъект может послать вещь, а второй отказаться от приема. Ну это ерунда.
2). Второе отличие Вы уже просекли. Внутри одного кошелька-субъекта объекты могут преобразовываться: либо менять свойства, либо объединяться, либо разделяться.
3) и самое главное. Учет обязательств, в первую очередь кредиторки. Тут я не уверен, что Вы до конца осознали методу, поскольку она революционна, кардинально отличается от существующей.
Можете вот эту статейку прочитать, для полного прояснения:

http://accountology.ucoz.ru/index....-24

Итак, обязательства учитываются в качестве будущих объектов (записываются будущей датой). Когда наступает срок, будущие объекты без всякой дополнительной записи становятся текущими объектами. Конечно, если предполагаемой оплаты нет, запись можно исправить, указав дату позже, или вообще удалить. Отсюда следует: кредиторку нельзя зарегистрировать раньше дебиторки (потому что вещь не может выбыть прежде, чем поступила: сначала на шкале времени приход, потом расход).
Учет обязательств - это стержень системы:
  • или Вы принимаете его со всеми весьма нестандартными (хотя естественными) последствиями,
  • или Вы вынуждены регистрировать кредиторку текущей датой по расходу, фактически получая двойную запись (дебет-кредит без учета капитала).

Еще раз. У меня регистрация кредиторки 19 марта будет выглядеть естественно: расход денег, допустим, 25 марта. Когда 25 марта подойдет, объект из будущего превратится в текущий, никакой дополнительной регистрации не потребуется. Для регистрации необходимо иметь достаточную сумму (либо зарегистрировать дебиторку, допустим, 20 марта). Именно так происходит в жизни, когда Вы 19 марта думаете: Петька отдаст деньги 25 марта. А 25 марта или Петька отдает деньги, или Вы соображаете: ничего, отдаст в апреле.
Как в двойной записи делается, Вам известно: 19 марта регистрируется сумма по кредиту (то есть расходу) - это кредиторское обязательство. 25 марта, если оплата состоялась, кредиторка погашается по дебету.

Вы абсолютно правильно отказались от учета капитала, но пока не решите вопрос с учетом кредиторки, дальше в теории не продвинетесь. А приделать к Вашей системе материальный учет несложно: в ней все необходимое имеется.
 
serbodДата: Среда, 19.03.2014, 18:10 | Сообщение # 11
Группа: Пользователи
Сообщений: 12
У меня обязательства учитываются очень просто - операция имеет свойства "Дата операции", "Сумма операции", "Сумма оплаты" и "Дата оплаты". Неполностью оплаченная операция и есть обязательство. Можно создать обязательство будущей датой, тогда до наступления этой даты обязательства как бы не существует, а потом оно появляется. Можно оплатить обязательство до даты его появления. Дата оплаты - это дата последней корректировки суммы оплаты.

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

Ключевое отличие этой схемы - обязательство не может стать выполненным само собой, просто по наступлению заданного срока. Можно отсрочить появление обязательства, но не его выполнение.
 
mikejumДата: Среда, 19.03.2014, 18:15 | Сообщение # 12
Группа: Администраторы
Сообщений: 181
Более-менее ясно. Остроумно. Надо обдумать.
Однако не понял, как Вы отличаете дебиторку и от кредиторки.
 
serbodДата: Среда, 19.03.2014, 18:40 | Сообщение # 13
Группа: Пользователи
Сообщений: 12
Цитата mikejum ()
Однако не понял, как Вы отличаете дебиторку и от кредиторки.
Приход или расход обязательства (относительно субъекта).
 
mikejumДата: Среда, 19.03.2014, 19:35 | Сообщение # 14
Группа: Администраторы
Сообщений: 181
Обдумал.
Опять-таки очень похоже на мою систему. У меня ведь тоже две даты: текущая и та, которой регистрируется обязательство. Только текущая дата по понятным причинам не регистрируется и постоянно приближается к будущей, до момента слияния, когда будущий объект становится текущим. Таким образом:
  • если регистрируешь операцию текущей (или прошлой) датой, регистрируешь текущий объект,
  • если регистрируешь операцию будущей датой, регистрируешь будущий объект. А потом он автоматически становится текущим.


Фактически, варианты одной системы. К слову, Ваш вариант я обдумывал, но отказался из-за необходимости регистрировать лишнюю дату.

Однако есть еще одна проблема, которую я упустил: проблема объектности. У меня, в отличие от традиционных систем, учет ведется по объектам: 2 объекта "гвозди" количеством по 1 шт. и ценой по 10 руб. совершенно не то же что 1 объект "гвозди" количеством 2 шт. и ценой 20 руб. Учет пообъектный, что, собственно, и дает возможность объединять и разделять отдельные объекты.
Деньги - объект во многом неестественный, поэтому его вынужденно придется учитывать через задницу. Если к 1 рублю в кассе просто добавить еще 1 рубль, получится два объекта, учитываемых различно (в результате деньги получатся как бы нумерованными, то есть возникнет покупюрный учет). Чтобы этого избежать, необходимо 1 рубль и рубль химически объединить, тогда получится единый объект номиналом 2 рубля. Звучит глупо, знаю, однако виновата не методология, а некорректное использование денег (в электронном виде, строго говоря, не существующих). В ТЗ не предусмотрено, кажется, но данную запись можно выполнять автоматически (для всех объектов с таким-то названием).

Насколько я понимаю, нестыковки две:
1. Пообъектный учет (без которого объединение-разделение объектов невозможно). Допустим, у Вас учитываются 100 болтов и 100 гаек. Каким образом зарегистрировать объединение 1 болта с 1 гайкой? Сначала их придется отделить от своих куч, а при отсутствии пообъектного учета это возможно лишь приданием им оригинальных характеристик (чтобы этот болт и эта гайка начали отличаться от тех, что в кучах). А ведь они не отличаются!
2. Возможность (у Вас) отрицательного остатка в кошельке. Я правильно понимаю, если в кошельке зарегистрирована кредиторка, получится отрицательный остаток? У меня такое невозможно, т.к. прежде чем отдать, необходимо получить: нельзя отдать несуществующее. Данное расхождение можно обойти, если допустить возможность отрицательной величины, но это лишний геморрой. С налету не представляю, каким образом изменить структуру базы. И главное, зачем? В жизни-то никаких отрицательных величин нет, значит и в системе, отражающей жизненные явления, их не должно быть.

К слову, как Вы регистрируете погашение кредиторки? Приходом по ней? А выбывающую вещь одновременно регистрируете по расходу? Но тогда это дебет-кредит, двойная запись и есть! Не, отрицательные остатки в кошельке невозможны! Или придется связывать в один объект два разных, зарегистрированных ранее: вещь (которая выбывает в погашение кредиторки) и кредиторку (которая погашается выбытием вещи). На самом-то деле имеет место лишь расход вещи. Объект один, как в моей системе.
 
mikejumДата: Среда, 19.03.2014, 21:45 | Сообщение # 15
Группа: Администраторы
Сообщений: 181
Еще важно, Вы "Сумма оплаты" и "Дата оплаты" только к обязательствам присобачиваете или к любым объектам? Если только к обязательствам, тогда усеченная двойная запись: к моей системе отношение отдаленное. У меня обязательство - это будущая вещь. Учитываются только вещи: текущий или будущей датой. Если зарегистрировать приход стула текущей датой - стул поступил; если приход будущей датой - стул должен поступить (дебиторка); ну а если расход имеющегося стула будущей датой - стол должен выбыть (кредиторка).
 
serbodДата: Четверг, 20.03.2014, 12:35 | Сообщение # 16
Группа: Пользователи
Сообщений: 12
1. Получается тогда, что нужно вести учет не объектов, а сущностей, обладающих такими характеристиками, как количество и сумма. И когда мы объединяем две сущности (болты и гайки), то некоторые характеристики суммируются, а некоторые видоизменяются.

Еще и с интересной проблемой я столкнулся, автоматизируя учет в ювелирной отрасли. Там учет драгоценных изделий ведется по штукам и по граммам одновременно. И плюс еще сумма, которая может зависеть как от цены за грамм, так и от цены за штуку. Учет ювелирки в рознице (где формально только суммы) - сплошные переоценки и инвентаризации. И если основной единицей измерения сделать граммы, то тогда при суммировании теряется количество. А если сделать основным количество, то теряется вес отдельных изделий и их невозможно правильно оценить. Получается, что изделия могут объединяться только по одинаковым весам, то есть кольца весом 5 грамм друг с другом объединять (логически суммировать) можно, а с кольцами весом 6 грамм уже нельзя.

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

Например, на карточке-кошельке ученика остаток 8 руб. При  этом он каждый день питается в столовой и на него оформлено 10 неоплаченных операций по 26 руб. Получается, что баланс -218 руб. Когда произойдет пополнение кошелька, в неоплаченных операциях будет проставлена сумма оплаты, а оставшаяся сумма оплаты прибавится к остатку.

"Сумма оплаты" и "Дата оплаты" - характеристики для решения конкретной бизнес-задачи по учету обязательств. В других задачах их может не быть - учет гуманитарной помощи, или спортивных состязаний, где нет ни сумм, ни обязательств. А в других случаях могут быть еще какие-то характеристики - учебные часы и оценки в школе, например.
 
mikejumДата: Четверг, 20.03.2014, 13:17 | Сообщение # 17
Группа: Администраторы
Сообщений: 181
1. У меня объекты - это вещи. Мир состоит из вещей, и учитываются вещи, которые только и могут объединяться и разделяться. Можно учитывать и абстракции, но к ним понятия объединения и разделения неприменимы.
Каждая вещь-объект может характеризоваться произвольным числом свойств, текстовых или числовых. Масса, количество, цена - примеры числовых свойств, но могут быть и другие. Все числовые свойства равноправные. При объединении вещей все числовые свойства суммируются. При объединении объектов массами 2 и 3 кг и ценой 5 и 8 руб. получится объект массой 5 кг и ценой 13 руб. Количество имеет смысл использовать в некоторых случаях. Например, если в ящике 10 деталей, то объединение 10 отдельных деталей даст 1 ящик деталей с количеством 10 шт. Если нет смысла использовать количество (или любое другое числовое свойство), можно поле не заполнить. Но можно и заполнить, тогда количество покажет число объединенных деталей: в первом примере объединение объектов в один покажет 2 шт. Текстовые свойства указываются при объединении произвольно: полученный объект может обладать или не обладать свойствами первоначальных объектов. Такие же правила при разделении: числовые свойства полученных при разделении объектов в сумме дают числовые свойства первоначального объекта.
Изменить числовое свойства объекта можно лишь при операции изменения качества: например, указать, что масса объекта уменьшилась с 2 кг на 1,5 кг. Но не при операциях объединения и разделения.
Проблемы ювелирной отрасли в моей системе преодолены полностью. Определенные сложности существуют при многовалютном учете - в силу того, что в нормальной экономике ничего похожего быть не может. Многовалютность - это искусственное извращение, с ней моя естественная методология справляется плохо.

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

Да, с арифметикой не понял. Точно, "10 неоплаченных операций по 26 руб."? Может, по 21 руб.?
 
serbodДата: Четверг, 20.03.2014, 14:32 | Сообщение # 18
Группа: Пользователи
Сообщений: 12
С математикой лажанул, 8-(10*26)=-252 будет баланс. Но это логический баланс, полученный путем вычета суммы обязательств из суммы остатка, он нигде не зафиксирован.

Это не двойная запись типа "приход-расход", а просто запись где сумма обязательства является числовой характеристикой. Ее можно учитывать, суммировать, а можно и просто игнорировать. Но уравновешивать ее в принципе необязательно. Когда ученик выбыл из школы (умер, например), то его обязательства так и останутся невыполненными. Их можно будет оформить где-то еще как гарантированный убыток.
 
mikejumДата: Четверг, 20.03.2014, 14:39 | Сообщение # 19
Группа: Администраторы
Сообщений: 181
Это я и называю: несистемно. Вроде забалансовых счетов.
А прослеживаемая связь между выбытием денег из одного кошелька и их поступлением в другой есть? Если нет, это простая запись: приход-расход по кошелькам без всякой взаимной связи между поступлениями и выбытиями.
 
serbodДата: Четверг, 20.03.2014, 15:18 | Сообщение # 20
Группа: Пользователи
Сообщений: 12
Связь между кошельками может быть, а может и не быть. Всего три вида операций с кошельками - приход, расход, перемещение. По сути это все одна операция, просто в приходе не указан кошелек источника, а в расходе не не указан кошелек получателя. Ничто не мешает сделать расход из кошелька "А" в никуда, а затем сделать приход в кошелек "Б" из ниоткуда. Это вполне нормально для ситуаций, когда транзакция происходит не мгновенно, а в течении некоторого времени, и при этом учет и контроль не возможен. Ежели логическая связь есть, то ее можно оформить в виде обязательства.

Например, при перемещении товара из одного склада в другой, можно не заморачиваться с перемещением сначала со склада на перевозчика, потом с перевозчика на склад. А сразу сделать перемещение со склада на склад, а в характеристиках операции указать перевозчика, ожидаемый срок доставки, отправленное количество, доставленное количество и дату доставки. Это чисто прикладное решение, оно практичнее в работе, чем цепочка детальных операций, детали которых могут быть неизвестны. Например, можно не указывать перевозчика или дату и количество доставки, если они не критичны для учета.
 
mikejumДата: Четверг, 20.03.2014, 15:29 | Сообщение # 21
Группа: Администраторы
Сообщений: 181
Сделано абсолютно правильно.
Остается неясным, а связь между кошельками при учете обязательств присутствует? Можно записать, что в будущем ожидается перемещение из одного кошелька в другой?
Если да, тогда учет обязательств просто оторван от учета наличности: как бы две разные системы. Что, конечно, методологическая ошибка, поскольку вещи одни, только одни вещи перемещаются в настоящем, а перемещение других планируется в будущем.
Также остается непроясненным:
а) поступившая вещь и погашенное вследствие данного поступления кредиторское обязательство - два разных объекта? Насколько я понимаю, да. Тогда просматривается разногласие с моей системой (и с природой, в которой объект один),
б) так что насчет объектности? Можно ли зарегистрировать два разных объекта с абсолютно одинаковыми свойствами? Или это будет один объект (учитываемый в одном кошельке) в количестве 2 шт.? Опять-таки да, и опять-таки ошибка. В жизни не так: можно сложить 2 идентичных яблока в кучу из двух яблок, но можно рассматривать (учитывать) их по отдельности. Разные состояния системы.
 
serbodДата: Четверг, 20.03.2014, 16:32 | Сообщение # 22
Группа: Пользователи
Сообщений: 12
Обязательство при перемещении подразумевает, что одна сторона операции что-то отдала, а вторая что-то еще не получила, то есть перемещение не завершено. То есть, кошелек "А" выполнил расход, а кошелек "Б" не выполнил приход. При этом обязательство привязано к обоим кошелькам и может учитываться при расчете баланса.

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

Получается, что расход и приход в перемещении могут быть разнесены во времени.

Что касается объектности, то в характеристиках операции могут быть объекты с разными единицами измерения. Расход яблок поштучно или килограммами. Как при этом правильно учесть остаток яблок я точно не знаю. Видимо, это будет зависеть от конкретной ситуации. Например, столовая покупает яблоки килограммами, а продает штуками. Делать операции преобразования, взвешивать каждое яблоко, учитывать усушку-утруску - на практике столовой это нафиг не надо. Им нужно посчитать разницу в рублях между купленными и проданными яблоками. При этом часть яблок подарят, часть выкинут, часть потеряют. И таких примеров много, даже среди изначально штучных товаров с серийными номерами. То есть, сбалансированный учет передачи объектов на практике не всегда осуществим, увы. Но учитывать это как-то нужно..
 
mikejumДата: Четверг, 20.03.2014, 17:17 | Сообщение # 23
Группа: Администраторы
Сообщений: 181
Как-то Вы обязательство странно трактуете. Обязательство - это когда первая сторона пообещала передать вещь второй стороне. Все это в будущем. А если передача осуществляется в настоящем, это перемещение.
Видимо, Вы путаете обязательство с обменом вещами. При обмене имеют место два обязательства, одно из которых может быть настоящим, а второе будущим. Допустим, я получил от Вас аванс деньгами, а взамен пообещал рукопись. Первое обязательство (Ваше передо мной) исполнено в настоящем, а второе (мое перед Вами) планируется исполнить в будущем. И оба эти обязательства связаны одним отношением обмена.
По этой причине разнесение прихода и расхода в рамках одного обязательства во времени теоретически недопустимо. Разнесены во времени могут быть обязательства в рамках обмена. Это Вы из двойной записи неудачно скопировали.

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

Относительно столовой. Перегонка штук в килограммы имеет прикладное значение, для теории это ничто. Разумеется, учитывать нужно в одном измерителе: если хозяйствовать через жопу, то и учет будет соответствующий. Здесь методология бессильна.
 
mikejumДата: Четверг, 20.03.2014, 17:43 | Сообщение # 24
Группа: Администраторы
Сообщений: 181
Добавление о столовой: вообще-то, нужно учитывать яблоки в двух измерителях, высчитав средний вес одного яблока. В этом случае можно будет ориентироваться как на количество штук, так и на массу. Всего-навсего.
 
serbodДата: Четверг, 20.03.2014, 17:52 | Сообщение # 25
Группа: Пользователи
Сообщений: 12
При простом обязательстве (только прихода или только расход) есть только одна сторона. Мы фиксируем ожидаемую сумму денег к поступлению, но не выполняем расход денег откуда-то еще. Это как проводка без кредита и с нулевой суммой дебита, но в ней есть сумма обязательства. Она не меняет сумму остатка счета или кошелька, но меняет сумму остатка обязательства.

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

В классическом учете такое недопустимо - это ломает систему, деньги пропадают в никуда и появляются из ниоткуда. На самом деле они не пропадают, а переходят в другую плоскость учета. Примерно как проводки между балансовыми и забалансовыми счетами.
 
mikejumДата: Четверг, 20.03.2014, 18:59 | Сообщение # 26
Группа: Администраторы
Сообщений: 181
Вы описываете "классический" подход. Он мне известен и он ошибочен (даже с юридической стороны, между прочим).
В жизни иначе: имеются два встречных обязательства (допустим, одно выполняется немедленно, другое с отсрочкой). Взаимосвязь в рамках одного обязательства (приход вещи - расход вещи) должна прослеживаться у разных субъектов. Если один передал деньги (расход), то другой принял (приход). А то, что второй взамен пообещал товар, это второе обязательство, будущее (будущий приход у одного и будущий расход у второго). Вместе обязательства составляют обмен (для чего обязательства нужно связать каким-нибудь идентификатором).
А то, что в двойной бухгалтерии расход вещи и приход денег у одного и приход вещи и расход денег у второго учитываются как единое обязательство, это ошибка. Говоря по-научному, не соблюдается коллация (соответствие учета у обоих сторон сделки). Бумажный это учет, не компьютерный.

Не, Сергей, Ваша система естественному порядку учета не соответствует. Когда из кошелька в кошелек деньги перекладываете, все правильно решено: приход, расход, перемещение. Вот это у нас один в один. Но тут простейший случай, а с обязательствами и пообъектным учетом морока начинается. К слову, зачем Вам объединение-разделение понадобилось? Сложно представить, что у специалиста в 1С проблемы с материальным учетом. Хотя понятно: если Вы осмелились выползти за пределы дебета-кредита, то все - болото, проблема на проблеме. Мне пара десятилетий понадобилась, чтобы разобраться, и то постоянно приходится что-то уточнять и исправлять.

Могу предложить то, что всем предлагаю: реализуйте мою систему. Не гарантирую, что заработаете (хотя надеюсь: почему бы и нет?), но мозги себе капитально прочистите.
 
Форум » Обсуждаем... » Нормативная база » Электронная форма учета (документация принципов учета с использованием ЭВМ)
  • Страница 1 из 1
  • 1
Поиск:
Колонка Редактора

Постоянные авторы
Copyright Медведев М.Ю. © 2012-2024