Комментарии 145
Картинка про 15 конкурирующих стандартов.jpg то есть по факту если кто то из клиентов будет пользоваться а-маил мне надо будет писать загрузку из еще одного формата, вместо того что бы взять старый уже готовый и немного его подкрутить.
Что-то я не слышал про конкурирующие стандарты. Были бы такие — имею в виду, не в рамках софта одного производителя, а общие, — данный стандарт был бы давно прикручен к пластиковым карточкам. Если указать в пластиковой карточке адрес учетной базы, данные о снятии-поступлении денег могут направляться непосредственно в базу. Разве есть такое? Это я так, в качестве примера.
А ваш «стандарт» выходит за пределы «софта одного производителя»? Кто, кроме вас, его поддерживает?
Никто, разумеется. Я ж методолог-одиночка, мне важна красота идеи, а предпринимательскими навыками «отжимать копеечку на голом месте» я не обладаю, даже если сильно захочу. Однако это не отменяет того факта, что предприниматели используют наработки исследователей навроде меня. Идея бухгалтерского почтового стандарта витает в воздухе, поэтому в скором времени кто-то на этом хорошо погреет руки. Но не я, разумеется, кто ж из софтверных производителей меня поддержит?
Значит, он (ваш стандарт) ничем не отличается от всех остальных внутренних форматов обмена, которых есть у всех производителей соответствующего софта.
Возможно, хотя не уверен. В моем формате имеются методологические особенности, например использование второй даты для регистрации обязательств. Однако это не программистский вопрос: чтобы понять, о чем идет речь, нужно обладать недюжинной квалификацией в области методологии учета, каковой программисты не обладают в силу другой специализации (это не в обиду: точно так же учетчики никогда не смогут понять сложную программную закавыку). В любом случае в качестве всеобщего формата (такого, чтобы можно было коррелировать между собой любые учетные базы данных) ни один из форматов де-факто не принят.
В моем формате имеются методологические особенности, например использование второй даты для регистрации обязательств.
… и эта методология пропиетарна для вашей системы. И именно поэтому ваш формат тоже не будет принят в качестве всеобщего.
О, не сомневаюсь! Мне достаточно того, что данная методология могла бы быть принята. Как я уже написал в одном из комментариев, я не обладаю умением выбивать под свои идеи гранты и привлекать жаждущих быстро и гарантированно наварить «легкого бабла». Мне было интересно проверить, может ли моя метода быть претворена на практике. Убедился: может. К каким впечатляющим последствиям это ведет, мне известно. Остальное не в моих силах, увы.
Мне было интересно проверить, может ли моя метода быть претворена на практике. Убедился: может.
Внутри одной вашей системы — да. Но вы-то пишете о применимости к другим бухгалтерским программам; а это вы на практике проверяли?
Я не могу это проверить для продуктов сторонних производителей. Если кто-то пожелает проверить, проверит. И убедится, что такое вполне возможно. Я в этом не сомневаюсь, ведь задача элементарна: обменяться данными о вещах, переданных в рамках одной хозяйственной операции.
Я не могу это проверить для продуктов сторонних производителей.
Значит, вы не убедились в возможности того, что описано в посте.
убедится, что такое вполне возможно
Возможно практически все. Вопрос стоимости.
Я в этом не сомневаюсь, ведь задача элементарна: обменяться данными о вещах, переданных в рамках одной хозяйственной операции.
Эта задача выглядит элементарной, но таковой не является. Банальный, казалось бы, вопрос: как определить передаваемые «вещи»?
Тут вы влезаете в мою область.
Поясняю: система реализована на основании экаунтологии — дисциплины, которую я изобрел для решения учетных задач. Согласно экаунтологии, объектом учета могут быть только вещи. Определить вещь чрезвычайно просто: это объекты реального мира, доступные в наших ощущениях. Все, что вы можете потрогать — это вещь, все остальное — не вещи.
Бухгалтерская методология основана на ином: помимо вещей, она учитывает в качестве объектов учета абстрактные понятия. Однако и в этом случае объект учета гарантированно имеется: это то, что учитывается на счете бухгалтерского учета. Учитывать в моей системе можно и абстракции, хотя это будет некорректно. (При этом оговорюсь, что обязательства и доходы-расходы определяются в моей системе на ином смысловом уровне, то есть они соответственно учитываются и рассчитываются).
Надеюсь, я ответил на ваш вопрос.
Поясняю: система реализована на основании экаунтологии — дисциплины, которую я изобрел для решения учетных задач. Согласно экаунтологии, объектом учета могут быть только вещи. Определить вещь чрезвычайно просто: это объекты реального мира, доступные в наших ощущениях. Все, что вы можете потрогать — это вещь, все остальное — не вещи.
Бухгалтерская методология основана на ином: помимо вещей, она учитывает в качестве объектов учета абстрактные понятия. Однако и в этом случае объект учета гарантированно имеется: это то, что учитывается на счете бухгалтерского учета. Учитывать в моей системе можно и абстракции, хотя это будет некорректно. (При этом оговорюсь, что обязательства и доходы-расходы определяются в моей системе на ином смысловом уровне, то есть они соответственно учитываются и рассчитываются).
Надеюсь, я ответил на ваш вопрос.
Нет, вы не ответили на мой вопрос.
Вот вы учитываете земельные участки (я надеюсь, они вещи?). Вам надо зарегистрировать передачу земельного участка из ведения одной организации в ведение другой организации. Внимание, вопрос: как одной организации однозначно объяснить другой, какой земельный участок передается?
(не нравятся земельные участки — примените то же самое к самолетам)
Вот вы учитываете земельные участки (я надеюсь, они вещи?). Вам надо зарегистрировать передачу земельного участка из ведения одной организации в ведение другой организации. Внимание, вопрос: как одной организации однозначно объяснить другой, какой земельный участок передается?
(не нравятся земельные участки — примените то же самое к самолетам)
Честно говоря, не понимаю, каким образом вы пытаетесь поддеть меня.
Да, земельные участки — вещи. Информация о них передается в точно таком же порядке, как и об остальных вещах: вещи может быть присвоен идентификатор (например, № в регистрирующем органе) либо вещь может быть идентифицирована по своему названию. Когда вы покупаете в магазине пакет молока, вы же не потребуете его уникальный номер? Он просто не нужен (хотя в контексте идеи всемирного учета желателен). Пакет молока будет идентифицирован названием, также другими характеристиками: маркой, сортом, производителем, датой производства и т.п.
Да, земельные участки — вещи. Информация о них передается в точно таком же порядке, как и об остальных вещах: вещи может быть присвоен идентификатор (например, № в регистрирующем органе) либо вещь может быть идентифицирована по своему названию. Когда вы покупаете в магазине пакет молока, вы же не потребуете его уникальный номер? Он просто не нужен (хотя в контексте идеи всемирного учета желателен). Пакет молока будет идентифицирован названием, также другими характеристиками: маркой, сортом, производителем, датой производства и т.п.
Я не пытаюсь вас поддеть, я пытаюсь указать вам на проблемы.
У земельных участков нет названий. Идентификатор… это прекрасно, но предположим, что отдающая организация не использует ГКН для идентификации земельных участков, а принимающая — использует. Что в этом случае делать?
Более того, есть и более интересный вопрос: как отразить тот факт, что одна организация использует в качестве стоимости земельных участков кадастровую стоимость, а другая — оценочную?
Информация о них передается в точно таком же порядке, как и об остальных вещах: вещи может быть присвоен идентификатор (например, № в регистрирующем органе) либо вещь может быть идентифицирована по своему названию
У земельных участков нет названий. Идентификатор… это прекрасно, но предположим, что отдающая организация не использует ГКН для идентификации земельных участков, а принимающая — использует. Что в этом случае делать?
Более того, есть и более интересный вопрос: как отразить тот факт, что одна организация использует в качестве стоимости земельных участков кадастровую стоимость, а другая — оценочную?
А, некоторое знакомство с учетной проблематикой у вас имеется, это хорошо! Однако мне данная проблематика тоже знакома не понаслышке, указывать на нее не нужно, это моя специальность. Объясняю.
Учитывать без идентификатора нельзя, просто не получится. В любой компьютерной системе идентификаторы используются как ID записей, не мне вам такое говорить. Однако имеется еще идентификация для пользователя. Традиционно для этих целей использовался счет бухгалтерского учета (попросту, обиходное название вещи). Когда выяснилось, что этого недостаточно, стали использоваться множественные идентификатор в виде субсчетов и аналитических признаков. Но название, в качестве обязательного реквизита, осталось. Оно и является пользовательским идентификатором. Продавец может указать: земельный участок по адресу такому-то. Это название и послужит идентификатором. Обращаю ваше внимание, что в моей системе корреляция не является обязательной: получатель может переименовать участок по собственному усмотрению, ему не возбраняется.
Аналогичным образом решается вопрос со стоимостью. Моя система позволяет учитывать вещи по множеству числовых признаков, поэтому получатель оприходует полученный участок как пожелает: по оценочной стоимости и(или) по кадастровой и(или) по любой другой. Если данная стоимость указана в данных отправителя, вбивать ее в базу не будет необходимости; если же данные отсутствуют, разумеется, реквизит придется вбить.
Замечу, что систем, позволяющих вести мультивалютный учет, уже тучи, насколько я понимаю. Это только традиционная бухгалтерия велит: или оценочная стоимость, или кадастровая.
Учитывать без идентификатора нельзя, просто не получится. В любой компьютерной системе идентификаторы используются как ID записей, не мне вам такое говорить. Однако имеется еще идентификация для пользователя. Традиционно для этих целей использовался счет бухгалтерского учета (попросту, обиходное название вещи). Когда выяснилось, что этого недостаточно, стали использоваться множественные идентификатор в виде субсчетов и аналитических признаков. Но название, в качестве обязательного реквизита, осталось. Оно и является пользовательским идентификатором. Продавец может указать: земельный участок по адресу такому-то. Это название и послужит идентификатором. Обращаю ваше внимание, что в моей системе корреляция не является обязательной: получатель может переименовать участок по собственному усмотрению, ему не возбраняется.
Аналогичным образом решается вопрос со стоимостью. Моя система позволяет учитывать вещи по множеству числовых признаков, поэтому получатель оприходует полученный участок как пожелает: по оценочной стоимости и(или) по кадастровой и(или) по любой другой. Если данная стоимость указана в данных отправителя, вбивать ее в базу не будет необходимости; если же данные отсутствуют, разумеется, реквизит придется вбить.
Замечу, что систем, позволяющих вести мультивалютный учет, уже тучи, насколько я понимаю. Это только традиционная бухгалтерия велит: или оценочная стоимость, или кадастровая.
В любой компьютерной системе идентификаторы используются как ID записей, не мне вам такое говорить.
Вы про искусственные идентификаторы сейчас говорите? Они нас не интересуют, их вы между системами никогда не скоррелируете.
Но название, в качестве обязательного реквизита, осталось. Оно и является пользовательским идентификатором.
Ну то есть вы навязываете всем системам обязательную идентификацию по наименованию?
Если данная стоимость указана в данных отправителя, вбивать ее в базу не будет необходимости; если же данные отсутствуют, разумеется, реквизит придется вбить.
Вы не поняли. Вот у вас есть атрибут Cost (я беру название из поста). Одна система хранит в нем кадастровую стоимость, другая — оценочную. Это, очевидно, приведет к проблеме при передаче информации.
Нет, обязательная идентификация по наименованию отсутствует. При этом поле «Название» должно быть заполнено в обязательном порядке (не может быть пустым).
Да, ваш пример с Cost корректен. В этом случае действительно появятся разночтения. Необходимо знать, что учитывает в поле Cost отправитель: если что-то другое, значение придется скорректировать на правильную величину. Другого варианта нет, по-моему.
Да, ваш пример с Cost корректен. В этом случае действительно появятся разночтения. Необходимо знать, что учитывает в поле Cost отправитель: если что-то другое, значение придется скорректировать на правильную величину. Другого варианта нет, по-моему.
Нет, обязательная идентификация по наименованию отсутствует. При этом поле «Название» должно быть заполнено в обязательном порядке (не может быть пустым).
Так как же принимающей организации, которая не учитывает земельные участки без кадастровых номеров, принять на учет земельный участок, пришедший от организации, которая не ведет кадастровые номера для своих земельных участков?
Да, ваш пример с Cost корректен. В этом случае действительно появятся разночтения. Необходимо знать, что учитывает в поле Cost отправитель: если что-то другое, значение придется скорректировать на правильную величину. Другого варианта нет, по-моему.
Угу. Причем решить эту проблему автоматически невозможно.
Так как же принимающей организации, которая не учитывает земельные участки без кадастровых номеров, принять на учет земельный участок, пришедший от организации, которая не ведет кадастровые номера для своих земельных участков?
В общем порядке. Вместо названия, где указан кадастровый номер, можно вписать любое другое, хоть бы адрес.
Угу. Причем решить эту проблему автоматически невозможно.
Я ее и не решаю, по указанной причине. Для этого и сообщил о необходимости составить список общеупотребительных полей.
Вместо названия, где указан кадастровый номер, можно вписать любое другое, хоть бы адрес.
Не, не взлетит. Название земельного участка — это его название («земельный участок, предназначенный для блаблабла»), причем в каждой организации оно свое. При этом адрес — это адрес, он не совпадает с названием. А кадастровый номер, очевидно — еще более отдельная вещь. Нельзя решить одним строковым полем все проблемы, пробовали.
Для этого и сообщил о необходимости составить список общеупотребительных полей.
Вам мало составить список, необходимо еще жестко регламентировать правила заполнения этих полей. И вот на этой фазе (которая называется «формализация схемы») вы и завязнете если не навсегда, то очень надолго.
(Собственно, вот и картинка про конкурирующие стандарты)
И что характерно, ничего нового кроме схемы, в вашем «стандарте» нет.
А кадастровый номер, очевидно — еще более отдельная вещь. Нельзя решить одним строковым полем все проблемы, пробовали.
Чем же это более отдельная? Обычный реквизит. Я не собираюсь составлять схему реквизитов (по-бухгалтерски, составлять План счетов) для каждого из предприятий. Если кто-то не может, это его проблемы, не мои. Собственно, ничего другого, кроме реквизитов, описывающих вещь, все равно не придумать: один реквизит, два реквизита для этого используется или более — не суть важно.
Да, если кто-то захочет намеренно перепутать характеристики объектов, вполне преуспеет. Но зачем?
И что характерно, ничего нового кроме схемы, в вашем «стандарте» нет.
Конечно, нет. Как в схеме принципиально нового мотора нет ничего, кроме схемы мотора. Что характерно.
Чем же это более отдельная? Обычный реквизит.
Как раз тем, что отдельный реквизит с требованиями по уникальности (я даже не буду заикаться про валидацию).
Если кто-то не может, это его проблемы, не мои.
Вот, собственно, и объяснение того, почему это провалится.
Конечно, нет. Как в схеме принципиально нового мотора нет ничего, кроме схемы мотора
Вы не поняли: как раз схема-то в вашем стандарте не описана (цитирую: «необходимости составить список общеупотребительных полей»). А без этой схемы стандарт не имеет смысла (потому что больше ничего полезного он не привносит; я могу продолжать задавать вопросы по тем местам, где в стандарте дыры, но не вижу особого смысла, он не этим интересен).
Извините, но в любом Плане счетов указан стандартный набор реквизитов, по которым следует учитывать вещи. Данные перечни зачастую некорректны, но в целом они покрывают потребности на 90%. А обо всем покрытии речи не идет.
Снова не понял. Ну, уникальный реквизит. У отправителя уникальный, а получатель как захочет учитывать вещь, так и станет. В чем проблема именно для кадастрового номера?
Как раз тем, что отдельный реквизит с требованиями по уникальности
Снова не понял. Ну, уникальный реквизит. У отправителя уникальный, а получатель как захочет учитывать вещь, так и станет. В чем проблема именно для кадастрового номера?
Извините, но в любом Плане счетов указан стандартный набор реквизитов, по которым следует учитывать вещи.
Ничего не знаю про «любой план счетов», равно и как про его применимость для конкретных учетных задач. Ваш стандарт-то тут при чем?
У отправителя уникальный, а получатель как захочет учитывать вещь, так и станет. В чем проблема именно для кадастрового номера?
Проблема (не кадастрового номера, а ситуации) в том, что получателю нужна информация, которую отправитель не передает. И как вы предлагаете это обрабатывать?
Ничего не знаю про «любой план счетов», равно и как про его применимость для конкретных учетных задач. Ваш стандарт-то тут при чем?
Над вопросом классификации вещей, т.е. определения необходимых для ведения учета признаков, люди задумывались с момента зарождения учета. В настоящее время обязательные для учета реквизиты указаны в Плане счетов (хотя указаны хаотично, неполно и противоречиво).
получателю нужна информация, которую отправитель не передает. И как вы предлагаете это обрабатывать?
Смеетесь? А если получателю нужна информация о Проксиме Центавра, а пользователь ее не передает, тогда как? Если же вы спрашиваете о дополнении получаемых данных, никто не мешает получателю внести их в свою базу данных. Получатель учитывает по полю <Марка>, а у отправителя такой информации нет. Придется вносить информацию при получении a-Mail, а как иначе? Но информацию, находящуюся на пересечении учетных систем, править не придется, в этом облегчение труда. Разве нет?
В настоящее время обязательные для учета реквизиты указаны в Плане счетов (хотя указаны хаотично, неполно и противоречиво).
Какое отношение это имеет к вашему стандарту?
Если же вы спрашиваете о дополнении получаемых данных, никто не мешает получателю внести их в свою базу данных.
Прекрасно, откуда он ее возьмет?
Но информацию, находящуюся на пересечении учетных систем, править не придется, в этом облегчение труда.
Вопрос размера этого пересечения (не формального, а семантического) и его отношения к общему размеру учитываемых реквизитов.
Какое отношение это имеет к вашему стандарту?
Вы же мне инкриминировали отсутствие списка реквизитов. Вот я и ответил: такие списки люди на протяжении веков составляют, они не секрет Полишинеля. При чем здесь мой стандарт, в самом деле?
Прекрасно, откуда он ее возьмет?
Это общий вопрос к учету, а не к моему стандарту. Используются лишь те реквизиты, в которых есть необходимость (при получении выходной информации). Требовать от отправителя информации, у него отсутствующей, — нонсенс.
Вопрос размера этого пересечения (не формального, а семантического) и его отношения к общему размеру учитываемых реквизитов.
Полагаю, более 50%. Но доказать без практического внедрения не могу, как, впрочем, и вы обратного.
Вы же мне инкриминировали отсутствие списка реквизитов. Вот я и ответил: такие списки люди на протяжении веков составляют, они не секрет Полишинеля. При чем здесь мой стандарт, в самом деле?
То есть в вашем стандарте списка реквизитов нет и не будет, правильно я вас понял?
Это общий вопрос к учету, а не к моему стандарту.
А что вообще вопрос к вашему стандарту? Иначе говоря: что именно ваш стандарт формализует?
Составить рекомендуемый список реквизитов я могу за день. Но он будет именно что рекомендуемым.
Мой стандарт формализует набор параметров, необходимых для корреляции учетных баз при передаче вещи от одного пользователя к другому. Часть параметров представляет собой жестко закрепленные реквизиты (например, логин пользователя), другая часть — список используемых пользователями произвольных реквизитов. Для списка указана только структура (поле-значение), пара полей является обязательными. Все.
Мой стандарт формализует набор параметров, необходимых для корреляции учетных баз при передаче вещи от одного пользователя к другому. Часть параметров представляет собой жестко закрепленные реквизиты (например, логин пользователя), другая часть — список используемых пользователями произвольных реквизитов. Для списка указана только структура (поле-значение), пара полей является обязательными. Все.
Мой стандарт формализует набор параметров, необходимых для корреляции учетных баз при передаче вещи от одного пользователя к другому.
А конкретно?
Все
И в чем тогда смысл такого стандарта? Что нового он приносит в существующие практики обмена? Какие конкретные существующие проблемы он решает?
А конкретно?
Параметры, в принципе, известны. Я предложил вариант формализации: для операции — две даты плюс комментарий, для объектов — название свойства плюс значение. Это не считая служебных и вспомогательных полей.
Что нового он приносит в существующие практики обмена?
В практики обмена — ничего. Если, конечно, не считать вторую дату, при помощи которой определяются обязательства. Сомневаюсь, что аналог отыщется. Во всех других системах обязательства — особый род объектов, требующих специальной идентификации.
Какие конкретные существующие проблемы он решает?
В первую очередь ту, которая не решена до сих пор, — корреляцию учетных баз данных. У меня корреляция добровольная, но должна быть принудительной, конечно. После исполнения сделки пользователи должны не иметь возможности править свои базы, во всяком случае в пересекающихся реквизитах.
Я могу попросить магазин прислать мне, в мою личную учетную базу, сведения о купленном товаре, хоть в каком-то формате? Нет? Ну и где ваши опытные интеграторы, занимаются тем, что, заработков ради, автоматизируют глупейшую бумажную методологию?
Я предложил вариант формализации: для операции — две даты плюс комментарий
Даже идентификатора нет, как это прекрасно.
Это не считая служебных и вспомогательных полей.
Они определены стандартом?
Если, конечно, не считать вторую дату, при помощи которой определяются обязательства.
Мы уже выяснили, что эта дата специфична для вашей методологии, к обмену она отношения не имеет.
для объектов — название свойства плюс значение
Это не формализация, это вид записи. Ничего формального в нем нет, он определен нижележащих форматом (простите) передачи данных.
В первую очередь ту, которая не решена до сих пор, — корреляцию учетных баз данных
Почему не решена? Есть учетные системы, поддерживающие синхронизацию различных экземпляров системы, причем иногда даже в полностью автоматическом режиме.
Я могу попросить магазин прислать мне, в мою личную учетную базу, сведения о купленном товаре, хоть в каком-то формате?
Да, можете.
Ну и где ваши опытные интеграторы
Занимаются тем, что им интересно и/или выгодно. Вас это удивляет?
Даже идентификатора нет, как это прекрасно.
Идентификаторы есть, естественно. А что, нужно было указать. как называется поле во время пересылки? Захотите интегрироваться, скажу.
Они определены стандартом?
Да, служебные и вспомогательные поля определены стандартом.
Мы уже выяснили, что эта дата специфична для вашей методологии, к обмену она отношения не имеет.
Имеет в смысле «конвертации» данных: сведения об обязательствах приходится пересылать всем, кто этим занимается. У меня предложен иной способ пересылки.
Это не формализация, это вид записи. Ничего формального в нем нет, он определен нижележащих форматом (простите) передачи данных.
Вы правы. Единственно новаторство в том, чтобы использовать пересекающиеся значения.
Есть учетные системы, поддерживающие синхронизацию различных экземпляров системы, причем иногда даже в полностью автоматическом режиме.
Ну и где общие стандарты для многих систем, а не для софта одного производителя?
Да, можете.
Хе. Попрошу в «Перекрестке».
Занимаются тем, что им интересно и/или выгодно. Вас это удивляет?
Нет, не удивляет. Я сам такой.
Идентификаторы есть, естественно.
Но вы про них не упоминаете.
А что, нужно было указать. как называется поле во время пересылки?
Нет, нужно указать состав полей.
Захотите интегрироваться, скажу.
То, что ваш стандарт еще и закрытый, не делает ему чести. И резко уменьшает шансы на внедрение.
У меня предложен иной способ пересылки.
… который все равно обозначает, что вторая сторона как-то конвертирует свои данные — в ваши, и наоборот. То, по какому признаку обязательство отличается от не-обязательства — технический вопрос второго, что ли, порядка малости, на фоне всего остального.
Единственно новаторство в том, чтобы использовать пересекающиеся значения.
Вы это серьезно? Любая интеграция использует пересекающееся между системами множество значений.
Ну и где общие стандарты для многих систем, а не для софта одного производителя?
Поищите, если интересно. Я для бухгалтерской отрасли не нашел, видимо, никому не надо. В других отраслях — есть.
Замечу, впрочем, что ваш стандарт в этой части ничем не отличается.
Нет, нужно указать состав полей.
Состав полей приблизительно указан, в посте.
То, что ваш стандарт еще и закрытый, не делает ему чести. И резко уменьшает шансы на внедрение.
Да уж, сглупил.
Вы это серьезно? Любая интеграция использует пересекающееся между системами множество значений.
Сложно отрицать.
Замечу, впрочем, что ваш стандарт в этой части ничем не отличается.
Если не нашли, от чего тогда он не отличается?
Состав полей приблизительно указан, в посте.
«Приблизительно» — это не стандарт.
Сложно отрицать.
Значит, никакого новаторства нет и в помине.
Если не нашли, от чего тогда он не отличается?
От существующих стандартов для софта одного производителя. Ваш тоже — для софта одного производителя.
Значит, никакого новаторства нет и в помине.
Никакого новаторства в данном узком аспекте.
От существующих стандартов для софта одного производителя. Ваш тоже — для софта одного производителя.
Поскольку предметная область одна, любой стандарт может быть использован в качестве общего. Теоретически, конечно.
Никакого новаторства в данном узком аспекте.
А в каком есть? (напоминаю, речь идет о предлагаемом вами стандарте)
Поскольку предметная область одна, любой стандарт может быть использован в качестве общего.
Вот именно, что любой. Видимо, картинка все-таки нужна.
В методологии точно есть (увы, это не ваша область, поэтому доказательства опущу). Наверное, вы правы, никакого новаторства в стандарте нет. Но разве я упоминал о новаторстве? Да, разработал стандарт для своей системы, предложил в качестве всеобщего, Это большой криминал, особенно для методолога в области учета? Ну раз они такие все одинаковые, что друг от друга не отличаются.
Картинку эту я уже видел, спасибо.
Картинку эту я уже видел, спасибо.
Да, разработал стандарт для своей системы, предложил в качестве всеобщего, Это большой криминал, особенно для методолога в области учета?
Предложить — не криминал. Не понимать, почему это предложение обречено — уже ближе к криминалу.
К слову, о новаторстве. Не уверен, что прочие стандарты предусматривают отказ от принятия вещи с последующим «восстановлением» ее в первоначальной базе. Впрочем, не знаю, насколько данная возможность относится непосредственно к протоколу.
А это входит в описанный вами стандарт, или это исключительно функциональность сопрягаемых систем? Иначе говоря, если система, которую вы интегрируете, построена не по вашей методологии, в ней это обязано быть?
Поищите, если интересно. Я для бухгалтерской отрасли не нашел, видимо, никому не надо. В других отраслях — есть.
У 1С как обычно на все есть свой стандарт для этих целей, другое дело, что им никто не пользуется кроме нее http://v8.1c.ru/edi/edi_stnd/90/92.htm
Ничто не может сразу направляться в базу. В мою базу. По крайней мере само собой. Должен быть код который обработает входящий поток данных и потом либо пользователь либо автомат эти данные импортирует. По правилам которые напишет программист. То есть отработает код который напишет программист. Этот код может обработать данные с электронной почты, ftp или еще откуда то, они могут быть в xml тексте, экселе или даже в ворде. Код отработает и если нужно подтверждение ответ уйдет. Зачем нужен ваш протокол? Если код писать придется в любом случае в полном объеме(не библиотек не исходных кодов, я не заметил, плохо смотрел?)
Верно говорите. Можно было в любой формат запихнуть, в принципе. И код придется писать в полном объеме, для каждого софта по отдельности, по другому никак.
Была мысль сделать считывание из файла, но пока не реализовал. Замечу, протокол при этом все равно необходим: тот или другой.
Была мысль сделать считывание из файла, но пока не реализовал. Замечу, протокол при этом все равно необходим: тот или другой.
Вы смешиваете протокол: чисто техническая часть:
«Клиент и сервер обмениваются заголовками содержащими… В случае если клиент… сервер считает...» и тд. То есть информацию как байты от клиента А должны в целости и сохранности добраться до клиента Б, с непосредственно методической частью, как клиент должен поступить с этой поступившей информацией. Первая часть на плечи которой ложится непосредственно транспорт решена и не один раз. Начиная от протокола обмена заканчивая форматом самого сообщения. Вторую часть вы предлагает писать в каждой системе заново(с учетом того, что там уже что то написано, системы работают и какие то соглашения достигнуты). Я не вижу куда здесь можно вставить ваш протокол.
«Клиент и сервер обмениваются заголовками содержащими… В случае если клиент… сервер считает...» и тд. То есть информацию как байты от клиента А должны в целости и сохранности добраться до клиента Б, с непосредственно методической частью, как клиент должен поступить с этой поступившей информацией. Первая часть на плечи которой ложится непосредственно транспорт решена и не один раз. Начиная от протокола обмена заканчивая форматом самого сообщения. Вторую часть вы предлагает писать в каждой системе заново(с учетом того, что там уже что то написано, системы работают и какие то соглашения достигнуты). Я не вижу куда здесь можно вставить ваш протокол.
Возможно, я недопонимаю, специализация у меня иная, вестимо. Однако, формализовать список полей для передачи нужно же в любом случае… Мой протокол или другой протокол, но эти данные должны соответствовать определенному стандарту, чтобы получатель мог их считать и правильно интерпретировать.
>>Однако, формализовать список полей для передачи нужно же в любом случае
Это называется разработка протокола? Какие поля будут в сообщении?
Ну вот вам готовый всеобъемлющий стандарт ссылку на который я давал выше, полностью документированный открытый предназначенный для обмена между учетными системами, пройдите по ссылкам в начале статьи и получите полное и детальное описание без всяких «напишите мне в личку».
http://v8.1c.ru/edi/edi_stnd/90/92.htm
Это называется разработка протокола? Какие поля будут в сообщении?
Ну вот вам готовый всеобъемлющий стандарт ссылку на который я давал выше, полностью документированный открытый предназначенный для обмена между учетными системами, пройдите по ссылкам в начале статьи и получите полное и детальное описание без всяких «напишите мне в личку».
http://v8.1c.ru/edi/edi_stnd/90/92.htm
Посмотрел, спасибо.
Без комментариев.
Да, поля, пожалуй, мне следовало указать все. Правда, без адресов для запросов они особого смысла не имеют, по крайней мере в рамках моей системы. Тем более что главные поля названы: адреса отправителя и получателя, даты и комментарий для операции, список свойств для объектов. Принципиальным является только введение второй даты, остальное — само собой разумеющееся.
Без комментариев.
Это называется разработка протокола? Какие поля будут в сообщении?
Да, поля, пожалуй, мне следовало указать все. Правда, без адресов для запросов они особого смысла не имеют, по крайней мере в рамках моей системы. Тем более что главные поля названы: адреса отправителя и получателя, даты и комментарий для операции, список свойств для объектов. Принципиальным является только введение второй даты, остальное — само собой разумеющееся.
Лучше бы единый формат, с текстовым представлением (Base64?), для вставки реквизитов компаниии (и пересылки) их придумали.
Один раз закодировал во что-то типа
«TmFtZT3QntCe0J4g0KDQuNC20YHQutC40Lkg0JvQsNC80L/QvtCy0YvQuSDQl9Cw0LLQvtC0DQrQmNCd0J09MTIzNDU2Nzg5DQpCYW5rPdCj0YDQsNC70YzRgdC60LjQuSDQkdCw0L3QuiDQoNC40JoNClR5cGU9T09PDQpPR1JOPTU5ODc0NjUyOTgzNzY=»
и потом вставляешь и все. Ну или Json…
Один раз закодировал во что-то типа
«TmFtZT3QntCe0J4g0KDQuNC20YHQutC40Lkg0JvQsNC80L/QvtCy0YvQuSDQl9Cw0LLQvtC0DQrQmNCd0J09MTIzNDU2Nzg5DQpCYW5rPdCj0YDQsNC70YzRgdC60LjQuSDQkdCw0L3QuiDQoNC40JoNClR5cGU9T09PDQpPR1JOPTU5ODc0NjUyOTgzNzY=»
и потом вставляешь и все. Ну или Json…
Json грубо говоря это «транспортный» уровень. Т.е. формат передаваемых данных. Что-бы это реально работало как стандарт нужно описание именно «словаря», т.е. список допустимых полей и их значений.
Основные поля (за исключением служебных) указаны в посте. Об остальном читайте в комментарии ниже.
Чем JSON от текстового представления отличается, если по сути? То же название компаний плюс данные об операции плюс данные о пересылаемых вещах. Принципиальных отличие нет, по-моему, а о частностях можно спорить.
Может я невнимательно читал, но где собственно текст самого стандарта? Не его имплементация в Х, а именно сам стандарт (ух коль скоро первоначальный посыл статьи именно в этом).
Описание стандарта будет предоставлено желающим сделать свой модуль. Общие достаточные сведения указаны в посте, а перечень полей, типов запросов и адресов, по которым их отправлять — для тех, кто захочет присоединиться. На данном этапе не я не готов обнародовать эти данные, тем более что технология предполагает передавать каждому разработчику идентификатор (с целью отслеживать, с каких модулей поступает спам). Возможно, я не прав. Так что стандарт пока условно-открытый, о чем сказано в посте: «обращайтесь в личку». Если проявится обвальный интерес, стандарт может стать полностью открытым. Н-да. Но тут свои возможности я оцениваю трезво…
Описание стандарта будет предоставлено желающим сделать свой модуль.
Тогда о чем вообще пост?
Пост о том, что бухгалтерскую почту сделать легко и просто, а эффект, в том числе финансовый, может быть велик.
Пост о том, что бухгалтерскую почту сделать легко и просто
Давайте я сразу и в лоб спрошу: сколько гетерогенных интеграций вы провели за свой опыт?
Послушайте, я ведь не притворяюсь программистом, я методолог учета. Если вы укажете на мои ошибки как программиста, буду признателен. Но если продолжите кичиться умными терминами, отвечу. К примеру, вы теории двух рядов счетов счетов от теорий трех рядов счетов твердо различаете?
Послушайте, я ведь не притворяюсь программистом, я методолог учета. Если вы укажете на мои ошибки как программиста, буду признателен.
А это и не программная ошибка, а аналитическая. Вы по каким-то причинам считаете, что сделать интеграцию систем, основанных на разной методологии — легко; хотя опыт показывает, что сложно интегрировать даже системы, основанные на одной методологии. У вас есть реальный опыт (как методолога, не как программиста) интеграции хотя бы двух разных систем друг с другом?
К примеру, вы теории двух рядов счетов счетов от теорий трех рядов счетов твердо различаете?
Нет, а мне надо?
Вы по каким-то причинам считаете, что сделать интеграцию систем, основанных на разной методологии — легко; хотя опыт показывает, что сложно интегрировать даже системы, основанные на одной методологии.
Я начинающий программист, да, но методологического опыта у меня выше крыши, на десяток профессоров хватит. Полсотни учебников и учебных пособий по бухгалтерскому учету, разработка собственной учетно-философско-информационной теории, теперь вот написание кода программного продукта. Этого недостаточно?
Этого недостаточно?
Я задал конкретный вопрос: у вас есть реальный практический опыт интеграции двух разных учетных систем друг с другом?
Почему вы считаете, что для получения практического решения обязателен практический опыт? К примеру, я раньше ни разу в жизни не складывал 31 и 8, вот другие числа складывал, а именно эти нет. И вы полагаете, я не смогу этого сделать? Я, знаете ли, обладаю относительно широкими познаниями о том, что вообще учитывается, как учитывается (и как учитывалось на протяжении веков), много лет изучал разные системы учета, с учетным софтом тоже сталкивался. И о современной двойной записи тоже все-все-все знаю (сравнительно с большинством других бухгалтеров, тем более программистов, уж точно). И вы пытаетесь убедить меня, что мне недостает практического опыта интеграции двух учетных систем?! А что в них такого, на уровне методологии, имеется, чего бы я не знал? Та же пресловутая двойная запись, в 99% случаев (о чем большинство программистов даже не догадывается). А архитектура и формат баз данных — это, извините, уже дело десятое, это не методология. Вот как вам объяснить… Накладными все предприятия пользуются, независимо от учетного софта? И ничего, обходятся как-то? У меня речь идет о том, чтобы пересылать данную информацию в электронном виде. Всего-навсего. А как запихнуть информацию из накладной в конкретную архитектуру — дело разработчиков, я в данную область и не лезу.
Почему вы считаете, что для получения практического решения обязателен практический опыт?
Потому что без практического опыта вы не сможете оценить сложность задачи.
К примеру, я раньше ни разу в жизни не складывал 31 и 8, вот другие числа складывал, а именно эти нет. И вы полагаете, я не смогу этого сделать?
Вот поэтому я и спрашиваю про интеграцию двух любых учетных систем по любому протоколу, а не только по a-Mail.
И вы пытаетесь убедить меня, что мне недостает практического опыта интеграции двух учетных систем?! А что в них такого, на уровне методологии, имеется, чего бы я не знал?
То, что интеграция — это всегда больше, чем совокупная сложность интегрируемых зон в каждой интегрируемой системе. Недостаточно просто знать каждую из систем, нужно еще знать, как делается интеграция.
У меня речь идет о том, чтобы пересылать данную информацию в электронном виде. Всего-навсего
Вот об это «всего-навсего» люди годами бьются. Есть такой малоизвестный госпроектик УНИФО/ГИС ГМП…
Это смотря какие люди… Если такие же, какие правят бал в бухгалтерском учете, тогда они десятилетиями могут «биться». А что, тепло, светло и мухи не кусают.
На данное обвинение я, как мне кажется, полно ответил в самом посте:
То, что интеграция — это всегда больше, чем совокупная сложность интегрируемых зон в каждой интегрируемой системе. Недостаточно просто знать каждую из систем, нужно еще знать, как делается интеграция.
На данное обвинение я, как мне кажется, полно ответил в самом посте:
Да, архитектура бухгалтерских программ различна, но извините, автоматизируемая ими предметная область едина! По этой простой причине разработка стандарта – не вопрос совмещения различных программных архитектур, как может кому-то ошибочно показаться, а вопрос стандартизации самой предметной области.
Это смотря какие люди…
Разные люди.
На данное обвинение я, как мне кажется, полно ответил в самом посте:
Не, не ответили.
Во-первых, ваша фраза подразумевает обязательную унификацию методологии учета (что противоречит посылу про интеграцию различных учетных систем).
Во-вторых, даже в случае с одной методологией, переход от локальной системы к распределенной всегда увеличивает сложность (если только методология изначально не была распределенной, чего у вас явно нет), а вы это игнорируете.
Не согласен, ответил. Стандарт предполагает унификацию только передаваемых данных, но никак не методологий, используемых в стороннем софте.
Что вы имеете в виду под переходом от локальной системе к распределенной, не понял. Моя методология не принудительная, получатель может отказаться от принятия вещи. Другое дело, что у него появляется возможность сразу запихнуть информацию в свою личную базу данных.
Что вы имеете в виду под переходом от локальной системе к распределенной, не понял. Моя методология не принудительная, получатель может отказаться от принятия вещи. Другое дело, что у него появляется возможность сразу запихнуть информацию в свою личную базу данных.
Стандарт предполагает унификацию только передаваемых данных, но никак не методологий, используемых в стороннем софте.
Вы не можете унифицировать передаваемые данные «без потерь», не унифицируя методологию.
Что вы имеете в виду под переходом от локальной системе к распределенной, не понял
У вас была система, в которой один пользователь учитывал свои вещи в своей БД. Теперь вы хотите сделать обмен информацией об учете между несколькими такими пользователями и несколькими БД. Была локальная система, стала распределенная.
Вы не можете унифицировать передаваемые данные «без потерь», не унифицируя методологию.
Почему? Как раз этот вопрос решен: данные передаются лишь в части пересечения реквизитов.вещей.
По поводу распределенной системы понял. Сложность увеличивается, конечно: если к системе что-то новое приделываешь, сложность всегда увеличивается.
Как раз этот вопрос решен: данные передаются лишь в части пересечения реквизитов.вещей.
Вот вы и потеряли данные, которые снаружи пересечения (даже если семантически они идентичны). Что веселее, внутри пересечения вы все равно не знаете, идентична ли семантика данных с одинаковыми именами.
По поводу распределенной системы понял. Сложность увеличивается, конечно: если к системе что-то новое приделываешь, сложность всегда увеличивается.
Вот именно поэтому интеграция — это отдельный опыт. Он у вас есть?
Хм… Иногда вы попадаете в точку.
Ответ такой. Дело в том, что никакой учет не обеспечивает целостности и правдивости данных. Вбить в качестве учетных данных можно что угодно. К примеру, составили акт о списании испортившихся вещей, а на самом деле растащили по домам. Нет никакого способа — методологически! — сделать учетные данные правдивыми. Точнее, есть, но до него пока далеко: автоматическая регистрация прихода и расхода вещей, — неподкупные датчики. По этой причине подмеченное вами обстоятельства (и в самом деле, методологическое) ничего не меняет в общем раскладе. Каждый учитывает так, как хочет, и то, что хочет. Свою задачу я видел в том, чтобы автоматизировать учет при желании, с обеих сторон, коррелировать учетные базы.
Опыта интеграции софта — нет. Зато, как у всякого бухгалтера, имеется опыт интеграции филиалов, которые ведут разный учет, зачастую с использованием разного софта. Не знаю, говорят вам что-нибудь такие понятия как консолидация отчетности или счет 79 «Внутрихозяйственные расчеты». Это тоже интеграция данных, между прочим.
Ответ такой. Дело в том, что никакой учет не обеспечивает целостности и правдивости данных. Вбить в качестве учетных данных можно что угодно. К примеру, составили акт о списании испортившихся вещей, а на самом деле растащили по домам. Нет никакого способа — методологически! — сделать учетные данные правдивыми. Точнее, есть, но до него пока далеко: автоматическая регистрация прихода и расхода вещей, — неподкупные датчики. По этой причине подмеченное вами обстоятельства (и в самом деле, методологическое) ничего не меняет в общем раскладе. Каждый учитывает так, как хочет, и то, что хочет. Свою задачу я видел в том, чтобы автоматизировать учет при желании, с обеих сторон, коррелировать учетные базы.
Вот именно поэтому интеграция — это отдельный опыт. Он у вас есть?
Опыта интеграции софта — нет. Зато, как у всякого бухгалтера, имеется опыт интеграции филиалов, которые ведут разный учет, зачастую с использованием разного софта. Не знаю, говорят вам что-нибудь такие понятия как консолидация отчетности или счет 79 «Внутрихозяйственные расчеты». Это тоже интеграция данных, между прочим.
Свою задачу я видел в том, чтобы автоматизировать учет при желании, с обеих сторон, коррелировать учетные базы.
Желания мало, нужны еще знания и ресурсы. То решение, которое вы приводите в посте, никак не решает тех проблем, которые мешают такой интеграции сейчас, в существующих решениях.
Опыта интеграции софта — нет.
Тогда я вам настоятельно рекомендую воздержаться от оценки сложности таких задач, пока вы не попробуете это сделать хотя бы пару раз.
Да, про знания — это вы с плеча, от всей души. :) А вот по поводу ресурсов согласен, нет у меня таких ресурсов, иначе многие из бухгалтеров лишились бы работы.
Еще, по поводу решения проблем. Не уверен, что вы понимаете, что мешает решению данных проблем сейчас: подскажу, что это никоим образом не технические сложности, а вполне себе волюнтаристские…
Видите ли, я высказывался о решении достаточно узкой задачи. Моя система предполагает не обязательный учет чего бы то ни было, а добровольный. Если получатель согласен с присланными характеристиками вещи, он нажатием на кнопку отправляет запись в базу данных; если нет — подвергает запись корректировке. Что вы все об интеграции твердите? Базы интегрировать не нужно: попала информация в яблочко — жми Ок; не попала — получатель ничего не теряет.
Еще, по поводу решения проблем. Не уверен, что вы понимаете, что мешает решению данных проблем сейчас: подскажу, что это никоим образом не технические сложности, а вполне себе волюнтаристские…
Тогда я вам настоятельно рекомендую воздержаться от оценки сложности таких задач, пока вы не попробуете это сделать хотя бы пару раз.
Видите ли, я высказывался о решении достаточно узкой задачи. Моя система предполагает не обязательный учет чего бы то ни было, а добровольный. Если получатель согласен с присланными характеристиками вещи, он нажатием на кнопку отправляет запись в базу данных; если нет — подвергает запись корректировке. Что вы все об интеграции твердите? Базы интегрировать не нужно: попала информация в яблочко — жми Ок; не попала — получатель ничего не теряет.
Не уверен, что вы понимаете, что мешает решению данных проблем сейчас: подскажу, что это никоим образом не технические сложности, а вполне себе волюнтаристские…
Между техническими и волюнтаристскими есть еще много других вариантов. Например — аналитический. И это, поверьте мне, реально существующая проблема.
Что вы все об интеграции твердите?
Потому что задача, которую вы решаете — интеграционная.
Базы интегрировать не нужно: попала информация в яблочко — жми Ок; не попала — получатель ничего не теряет.
Если в 99% случаев пользователь «не жмет Ок», смысла в этом «стандарте» нет.
Ну и да, описанное вами решение в таком случае не автоматическое (напомню: «по бухгалтерской почте [данные передаются] в формализованном, предназначенном для автоматического размещения в учетной базе пользователя.»)
Решение частично автоматическое, в зависимости от конкретной ситуации. Подбирая варианты, можно задать 1% или 99% попадания, но такой способ доказательств некорректен.
Вы уверены, что, буде мои идеи реализуются, покупателю, получающему из магазина сообщение: <Название> = «молоко», <Производитель> = «Останкино», <Емкость> = 1 литр, <Цена> = 80 руб., <Срок годности> = 2 декабря 2015 г., этого окажется недостаточно для ведения личного учета?
Если в 99% случаев пользователь «не жмет Ок», смысла в этом «стандарте» нет.
Вы уверены, что, буде мои идеи реализуются, покупателю, получающему из магазина сообщение: <Название> = «молоко», <Производитель> = «Останкино», <Емкость> = 1 литр, <Цена> = 80 руб., <Срок годности> = 2 декабря 2015 г., этого окажется недостаточно для ведения личного учета?
Решение частично автоматическое, в зависимости от конкретной ситуации
И как определять, какая сейчас ситуация?
Вы уверены, что, буде мои идеи реализуются, покупателю, получающему из магазина сообщение: <Название> = «молоко», <Производитель> = «Останкино», <Емкость> = 1 литр, <Цена> = 80 руб., <Срок годности> = 2 декабря 2015 г., этого окажется недостаточно для ведения личного учета?
Мне недостаточно. Потому что «молоко» — это «продукт», «название» у него «Останкинское», а еще мне нужна дата производства и срок годности, записанный в днях. Заодно я хочу знать, что цена этого пакета молока — 80 рублей, но я его купил за 72, потому что у меня скидка в 10%. А год назад мне нужна была бы жирность этого молока, потому что у меня были раздельные траты на цельное и 1.5%.
И как определять, какая сейчас ситуация?
Так пользователь и определит при добавлении. Запись же не автоматически попадает в базу, ее предварительно требуется одобрить. При одобрении можно откорректировать.
Мне недостаточно.
Ну хорошо, вам недостаточно. Желаете набивать вручную все реквизиты или некоторые предпочтете все же запихнуть в базу автоматически?
Так пользователь и определит при добавлении.
Значит, это не автоматическое решение, а автоматизированное.
Желаете набивать вручную все реквизиты или некоторые предпочтете все же запихнуть в базу автоматически?
А вы посмотрите, сколько реквизитов реально совпало, и сколько мне надо набивать ручками. По опыту работы с системой, которая часть данных брала автоматически, а остальную (заметим, меньшую!) надо было править руками — это быстро надоедает, и эту систему (или, по крайней мере, интеграцию) просто забрасывают.
Да, автоматизированное, тут вы правы. Некорректно употребил термин, виноват.
Многообразный у вас опыт, однако. Тем не мене представить, что ручное переписывание с накладных лучше, все равно не могу.
По опыту работы с системой, которая часть данных брала автоматически, а остальную (заметим, меньшую!) надо было править руками — это быстро надоедает, и эту систему (или, по крайней мере, интеграцию) просто забрасывают.
Многообразный у вас опыт, однако. Тем не мене представить, что ручное переписывание с накладных лучше, все равно не могу.
Тем не мене представить, что ручное переписывание с накладных лучше, все равно не могу.
Вы можете не поверить, но ручное переписывание данных с накладных действительно лучше, чем сверка всех данных с этой же накладной глазами (особенно если за системой таки замечены ошибки, скажем, в два порядка в суммах).
Так ведь и в накладной возможны ошибки. Для проверки придется лезть в договор или прошлые учетные данные, то есть глазками побегать… Общеучетные претензии в рамках данного конкретного поста не принимаются.
А вот если построить автоматизированную систему с жесткими формальными правилами, то такая активность пользователя будет сведена к минимуму.
Жесткие формальные правила возможны при полной регламентации, которая отсутствует. Я исходил, наоборот, из корреляции баз на основе полной анархии. Ясно же, что здесь корреляция возможна лишь по пересекающимся реквизитам.
Ясно же, что здесь корреляция возможна лишь по пересекающимся реквизитам.
Корреляция возможна только по семантически идентичным реквизитам. В условиях полной анархии это невозможно. Что, собственно, и делает описанный вами подход нежизнеспособным.
А одинаковое название — это не семантически идентичный реквизит? Ну, вы даете! Как вы с женой общаетесь, при отсутствии гарантий совпадения семантики в ее голове и вашей?
А одинаковое название — это не семантически идентичный реквизит?
Конечно, нет. Примеры я уже приводил.
Как вы с женой общаетесь, при отсутствии гарантий совпадения семантики в ее голове и вашей?
Как и полагается людям, с постоянными оговорками и уточнениями.
Как ведь и уточнения выполняются между головами, в которых разная семантика! Выходит, вы принципиально не в состоянии друг друга понять.
А для вас это новость? «Понимание» между людьми — это социальная условность.
Вот только вы радостно ушли от темы. То, что происходит между людьми, не имеет отношения к тому, что происходит между системами. К счастью, для компьютерных систем возможно определить семантическую идентичность тех или иных сущностей.
Вот только вы радостно ушли от темы. То, что происходит между людьми, не имеет отношения к тому, что происходит между системами. К счастью, для компьютерных систем возможно определить семантическую идентичность тех или иных сущностей.
Нет, нельзя, если сущности заполняются людьми. Вы рассматриваете запрещенный случай, когда пользователь намеренно вкладывает в информационный пакет иное содержимое. Ясен пень, содержимое не будет соответствовать наклейке, никто и не сомневается…
Нет, нельзя, если сущности заполняются людьми.
Можно, можно. Формализованная семантика никак не связана с тем, кем поле заполняется.
Вы рассматриваете запрещенный случай, когда пользователь намеренно вкладывает в информационный пакет иное содержимое.
Это он в моем идеальном мире запрещенный, и этот запрет всячески поддерживается информационными системами. А в условиях полной анархии и отсутствия регламентации это как раз разрешенный случай.
Учетные системы имеют дело не с формализованной семантикой, а с информацией, которую вбивают люди. Нет никаких формальных препятствий для введения ошибочных или ложных данных, это азы. Любые такие препятствия можно обойти. Эта ваша претензия абсолютно несостоятельная, не принимается.
Учетные системы имеют дело не с формализованной семантикой, а с информацией, которую вбивают люди
Это ложная дихотомия. Можно одновременно иметь строго формализованную семантику в системной модели, и при этом получать данные от пользователей. Да, пользователи могут вводить данные, которые не совпадают с этой семантикой. Нет, существуют способы контроля этого, которые сводят такие ошибки (как случайные, так и намеренные) к минимуму.
Нет никаких формальных препятствий для введения ошибочных или ложных данных, это азы.
Есть, есть. Начиная от технических и заканчивая административными.
Любые такие препятствия можно обойти
Обычно самый эффективный способ обойти такие препятствия — не использовать систему.
Эта ваша претензия абсолютно несостоятельная
Какая претензия-то?
Есть, есть. Начиная от технических и заканчивая административными.
Технически можно проверить, чтобы цена не была отрицательной. Административно можно наказать кладовщика за недостачу. И что, сильно помогает?
Обычно самый эффективный способ обойти такие препятствия — не использовать систему.
Правильно. Поэтому многие предпочитают вообще не вести учет. Вы же не станете утверждать, что и тут формализованная семантика поможет?
Какая претензия-то?
Претензия в том, что корреляция учетных баз в моей системе может выполняться некорректно.
Технически можно проверить, чтобы цена не была отрицательной. Административно можно наказать кладовщика за недостачу. И что, сильно помогает?
Да.
Правильно. Поэтому многие предпочитают вообще не вести учет. Вы же не станете утверждать, что и тут формализованная семантика поможет?
Тут не поможет.
Претензия в том, что корреляция учетных баз в моей системе может выполняться некорректно.
Ну так она и может выполняться некорректно, разве нет?
Да.
Если б помогало, воровства бы уже не было.
Ну так она и может выполняться некорректно, разве нет?
Может. Но это не претензия конкретно к моей системе, это общее положение дел для всех систем учета.
Если б помогало, воровства бы уже не было.
Вы правда не понимаете разницы между «помогает» и «полностью решает проблему»?
Но это не претензия конкретно к моей системе, это общее положение дел для всех систем учета.
Тем не менее некоторые системы учета менее подвержены этой проблеме, нежели то, что вы предлагаете.
Вот честно, не вижу, чем моя система более плоха с точки зрения формализованной семантики. По-моему, здесь они все одинаково плохие или одинаково хорошие, как посмотреть. В любой системе в поле <Название товара> я могу вбить «первый сорт», никакая формализованная семантика с этим не справится. Ну, если только из жестко заданного словаря не выбирать, так ведь подобные варианты мы не рассматриваем?!
Вот честно, не вижу, чем моя система более плоха с точки зрения формализованной семантики.
Тем, что в предлагаемом вами стандарте формализованной семантики нет.
Ну хорошо, можете пояснить в двух словах, что вы понимаете под формализованной семантикой?
Строго описанный набор бизнес-сущностей, их атрибутов и связей, для каждой/каждого из которых описаны бизнес-смысл, жизненный цикл, допустимый набор значений и иные бизнес-правила.
Вполне себе методологическая задача.
Вроде как рассказывал об этом в посте. Логин и сублогин как части общего адреса a-Mail. Даты регистрации и совершения операции. Комментарий к операции. Свойства вещей: обязательные названы (название и масса), остальные являются произвольными. Для каждого поля присутствует указатель на формат: текст или число. Разумеется, каждому значению соответствует поле-идентификатор.
Стандарт делался для моей системы, которая вроде работает (по крайней мере, на уровне методологии), так что формальное описание имеется. Надо было, конечно, выложить все реквизиты, вообще все, за исключением адресов доступа — в этом дал маху, каюсь.
Вроде как рассказывал об этом в посте. Логин и сублогин как части общего адреса a-Mail. Даты регистрации и совершения операции. Комментарий к операции. Свойства вещей: обязательные названы (название и масса), остальные являются произвольными. Для каждого поля присутствует указатель на формат: текст или число. Разумеется, каждому значению соответствует поле-идентификатор.
Стандарт делался для моей системы, которая вроде работает (по крайней мере, на уровне методологии), так что формальное описание имеется. Надо было, конечно, выложить все реквизиты, вообще все, за исключением адресов доступа — в этом дал маху, каюсь.
Логин и сублогин как части общего адреса a-Mail.
Заметим в скобках, что это решение уже негенерализуемо.
Даты регистрации и совершения операции. Комментарий к операции.
При этом уникального идентификатора операции нет.
остальные являются произвольными
Вот это и есть неформализованная семантика.
Для каждого поля присутствует указатель на формат: текст или число.
А ничего, что в JSON это не нужно?
(при этом, скажем, дат у вас тоже нет)
Разумеется, каждому значению соответствует поле-идентификатор.
Зачем?
Стандарт делался для моей системы, которая вроде работает (по крайней мере, на уровне методологии), так что формальное описание имеется.
Вот именно поэтому он и не взлетит для остальных систем. Если вы хотите получить обобщенное решение, нужно сразу смотреть на несколько систем.
Ну и да, вы пропустили большую часто того, что я описал выше. Просто названий (и даже названий с типами) недостаточно.
Заметим в скобках, что это решение уже негенерализуемо.
Что такое негенереализуемо?
При этом уникального идентификатора операции нет.
С чего вы взяли? Как без идентификатора определять, с какой операцией имеешь дело? В качестве идентификатора используется id базы на сервере.
Вот это и есть неформализованная семантика.
В самом деле? То есть если перечень полей открытый, это неформализованная семантика?
А ничего, что в JSON это не нужно?
Разумеется, в JSON это не нужно: нужно получателю, как раз для формализованной проверки. Если поля совпадут, но не совпадут форматы, поля будут считаться разными.
Если вы хотите получить обобщенное решение, нужно сразу смотреть на несколько систем.
Все учетные системы базируются на правилах учета, о которых мне известно очень и очень хорошо.
Зачем?
Поле-значение — обычная связка же. Хотя, при заданных полях, можно было обойтись только значениями.
Могу в качестве образчика формализации выложить данные об операции, полстраницы из четырех. Наверное, вы сейчас оживитесь и найдете новые подтверждения моей некомпетентности, однако мне уже до фонаря. Повторять, что моя система не взлетит, больше не надо:
во-первых, я это не оспариваю,
во-вторых, она все равно взлетит, только под другим названием и будучи сделана профессиональным программистом, потому что идея бухгалтерской почты витает в воздухе.
Нате, вострите зубки.
Параметр 1 — данные об операции передачи,
Параметр 1 имеет структуру Dictionary<string, string> (поле, значение), переведенную в формат json:
«LoginSender», «Логин отправителя»;
«SubLoginSender», «Сублогин отправителя»;
«LoginReceiver», «Логин получателя»;
«SubLoginReceiver», «Сублогин получателя»;
«DateRegistration», «Дата регистрации операции»*;
«DateExecution», «Дата исполнения операции»*;
«PlanFact», «0 или 1»; //0 – план, 1 – факт
«Probability», «Вероятность будущей операции»**;
«Status», «1»; //статус: всегда 1, информация для сервера
«CountThings», «Число передаваемых вещей»;
«Comment», «Комментарий».
* – формат обеих дат: «dd-MM-yyyy HH':'mm':'ss».
Дата исполнения необходима для обозначения обязательств: если дата исполнения больше, чем дата регистрации, имеет место обязательство. Пример: дата регистрации 3 мая, дата исполнения 15 июня. Следовательно, 3 мая возникло обязательство с предполагаемой датой погашения 15 июня.
** – поскольку любое обязательство (дата его погашения) носит предполагаемый характер, возможно указывать вероятность погашения.
Что такое негенереализуемо?
Невыполнимо в общем случае.
С чего вы взяли?
С того, что он у вас не упомянут.
В качестве идентификатора используется id базы на сервере.
Теперь система еще и жестко завязана на сервер. Сочувствую.
То есть если перечень полей открытый, это неформализованная семантика?
Ну да. Пиши, что хочу.
Разумеется, в JSON это не нужно: нужно получателю, как раз для формализованной проверки. Если поля совпадут, но не совпадут форматы, поля будут считаться разными.
Вы про схемы данных не слышали никогда?
Все учетные системы базируются на правилах учета, о которых мне известно очень и очень хорошо.
Тем не менее, формат разработан для вашей. Дело же не только в правилах учета.
Поле-значение — обычная связка же.
Обычная связка — это «ключ-значение». И в JSON именно она и является полем.
она все равно взлетит, только под другим названием и будучи сделана профессиональным программистом, потому что идея бухгалтерской почты витает в воздухе.
… и это будет не ваша идея. В воздухе витает унифицированный обмен данными, еще со времен, когда про вашу эккаунтологию ни слова не было слышно. Вот только каждый раз он упирается в одну и ту же проблему схемы, и вы тоже не предлагаете путей ее решения. Почему вы считаете, что ваш подход — в котором, заметим, нет ничего, чего не было бы уже сказано раньше — имеет большие шансы на выигрыш, чем те, которые были до него?
Параметр 1 — данные об операции передачи,
Вот и нет там никакого идентификатора. И типов данных, кстати, тоже нет.
Параметр 1 имеет структуру Dictionary<string, string> (поле, значение),
Вот это и есть неформализованная семантика. Туда можно запихнуть что угодно, и валидность формата будет сохранена.
формат обеих дат: «dd-MM-yyyy HH':'mm':'ss».
Удачи в интеграции Владивостока с Калининградом.
Дата исполнения необходима для обозначения обязательств: если дата исполнения больше, чем дата регистрации, имеет место обязательство.
Это, заметим, единственное описанное в вашем формате бизнес-правило. И оно, внезапно, связано как раз с вашей гениальной идеей обязательств.
поскольку любое обязательство (дата его погашения) носит предполагаемый характер, возможно указывать вероятность погашения.
Вот вам типичный пример неформальности. Одна система будет указывать вероятность в процентах, другая — в долях, третья — в словесных оценках. Хотя всего этого можно было бы избежать одним простым правилом.
Угу, сильно, вот теперь отправили в нокаут.
Кое-что, типа вероятности, легко исправимо, другое уже посложней. Не понял относительно JSON, схем данных и валидности, что вы имеете в виду. Если есть string, понятно, что туда можно запихнуть что угодно, и не надо ссылаться на формализованную семантику, она валидности не поможет. Однако спорить не буду, это уже мелочи.
Как говорится, спасибо за конструктивную критику.
Единственное, чего не понимаю, почему программисты, такие все из себя профессиональные, столь беспомощны в методах учета. Это не в оправдание себя, а к слову. Я ведь приблизительно то же в такие моменты ощущаю, что и вы, вероятно, в настоящий момент. Никакого вам унифицированного обмена данными не будет, пока предметную область как следует не изучите, попомните мое слово.
Кое-что, типа вероятности, легко исправимо, другое уже посложней. Не понял относительно JSON, схем данных и валидности, что вы имеете в виду. Если есть string, понятно, что туда можно запихнуть что угодно, и не надо ссылаться на формализованную семантику, она валидности не поможет. Однако спорить не буду, это уже мелочи.
Как говорится, спасибо за конструктивную критику.
Единственное, чего не понимаю, почему программисты, такие все из себя профессиональные, столь беспомощны в методах учета. Это не в оправдание себя, а к слову. Я ведь приблизительно то же в такие моменты ощущаю, что и вы, вероятно, в настоящий момент. Никакого вам унифицированного обмена данными не будет, пока предметную область как следует не изучите, попомните мое слово.
Если есть string, понятно, что туда можно запихнуть что угодно
Вот поэтому везде, где может быть не стринг, должен быть не стринг.
Единственное, чего не понимаю, почему программисты, такие все из себя профессиональные, столь беспомощны в методах учета.
Во-первых, они не так беспомощны, как вы думаете. Во-вторых, ответ прост: нельзя быть профессионалом во всех областях сразу. Поэтому программисты работают в команде с аналитиками и специалистами в прикладной области.
Никакого вам унифицированного обмена данными не будет, пока предметную область как следует не изучите
А вы правда думаете, что схемы обмена данными программисты придумывают?
А вы правда думаете, что схемы обмена данными программисты придумывают?
А кто, инопланетяне?
И что, наконец, вы понимаете под схемами данных? Описания полей?
А кто, инопланетяне?
Забавно, вы правда считаете, что эта планета сплошь населена программистами? Я буквально строчкой выше описал типовой состав проектной команды (без учета QA, Ops и PM).
И что, наконец, вы понимаете под схемами данных?
Схема данных — это, действительно, развернутое описание структуры передаваемых данных. Схема обмена данными — это все то же самое, плюс протоколы и последовательности.
(естественно, это все сильно упрощая, там страницы fine print)
Простой вопрос: через какой транспорт вы предлагает производить обмен? Как происходит адресация?
Обмен уже производится, через хостинг, в котором я арендую место. Вроде как работает, в тестировочном режиме. Адресация происходит следующим образом: json от Отправителя отсылается по определенному адресу, на сервере происходит обработка, составляется временная база (записи хранятся до момента, пока не будет произведен полный обмен информацией). Затем, при подключении Получателя, данные переадресуются ему. В клиентской программе Получателя данные обрабатываются, ожидается ответ Получателя, после чего он (ответ) отправляется на сервер для уведомления Отправителя.
Серверная часть написана на Ruby on Rails, данный код писал не я — помогли.
Пока это делается через мой сервер, но, конечно, напрашивается использование многих серверов, по типу электронной почты. Добавить лишнее поле в стандарт несложно, был бы интерес.
Серверная часть написана на Ruby on Rails, данный код писал не я — помогли.
Пока это делается через мой сервер, но, конечно, напрашивается использование многих серверов, по типу электронной почты. Добавить лишнее поле в стандарт несложно, был бы интерес.
Повторю вопрос: какой транспорт используется? Заодно вот еще спрошу: а как обеспечивается конфиденциальность и подлинность транзакций?
Что вы имеете в виду под транспортом? Выполняется запрос определенного вида к серверу, возвращается html-страничка с данными. Подлинность транзакций обеспечиваются паролированием, на уровне клиентской программы и сервера. Из клиентской программы устанавливается соединение с сервером (Войти или Зарегистрироваться), данные отправляются с зашитым в них паролем, сервер проверяет пароль. Помимо этого, имеется еще пароль для входа в клиентскую программу. Я ответил на ваш вопрос или вы что-то более специальное имели в виду?
Выполняется запрос определенного вида к серверу, возвращается html-страничка с данными.
Понятно.
Подлинность транзакций обеспечиваются паролированием, на уровне клиентской программы и сервера. Из клиентской программы устанавливается соединение с сервером (Войти или Зарегистрироваться), данные отправляются с зашитым в них паролем, сервер проверяет пароль. Помимо этого, имеется еще пароль для входа в клиентскую программу. Я ответил на ваш вопрос или вы что-то более специальное имели в виду?
Ох. Если вкратце, то описанная вами система никак не гарантирует ни конфиденциальности, ни подлинности проведенных транзакций. Ничто не мешает мне, как атакующему, врезаться в обмен между клиентом и сервером и сделать практически что угодно. И тем более ничего не мешает злонамеренному серверу делать с клиентскими данными что угодно.
И да, это не сугубо технологический вопрос — как только вы выходите за пределы одной системы, вопрос доверия становится методологическим. Особенно когда речь идет об имущественных транзакциях.
Особенно когда речь идет об имущественных транзакциях.
Вы не путайте имущественные транзакции с информационными, у меня ж не банковский счет.
Почему подлинности не гарантирует, если паролирование имеется? Конфиденциальность данных вроде бы от канала связи зависит, но тут я не спец, спрошу помощника, который серверную часть писал.
И тем более ничего не мешает злонамеренному серверу делать с клиентскими данными что угодно.
Вот тут я вообще не понимаю. Теоретически, любой сервер может сделать с пересылаемыми данными что угодно. Почтовые разве не так работают?
В любом случае определитесь с претензиями: если вы пеняете на слабую защищенность данных, то тут вы, скорей всего, правы. Правда, сильно сомневаюсь, что в другую систему нельзя вклиниться. Речь идет о том, чтобы пересылать данные, к примеру, от продавца к покупателю. Если уж контора захочет, то сможет получить данные непосредственно от продавца, зачем взламывать систему покупателя? Если же вы пеняете на методологическую непроработанность системы, то тут, являясь специалистом в области методологии, я категорически против. Моя система реализована в соответствии с лучшей на сегодня методологией. К сожалению, оценить ее новизну способны не все, вследствие ее неприменимости для ведения регламентированного учета (который давно уже ни в какие ворота не лезет).
Вы не путайте имущественные транзакции с информационными, у меня ж не банковский счет.
А какая разница? Информация об учете вещей иногда ценнее, чем сами вещи.
Почему подлинности не гарантирует, если паролирование имеется?
Потому что клиент (1) ничего не знает о пароле, который клиент (2) предъявил серверу. Это если в простоте. А если идти глубже, то пароль никак не защищает транзакцию, скажем, от изменения на лету, поэтому мы не знаем, пришла ли к нам транзакция с теми же данными, с которыми ее послал отправитель.
Конфиденциальность данных вроде бы от канала связи зависит,
Конфиденциальность зависит от канала связи в том случае, когда она не обеспечивается стандартом сообщения. У вас, похоже, не обеспечивается.
Теоретически, любой сервер может сделать с пересылаемыми данными что угодно
Если данные адекватно защищены, то нет, будет нарушена целостность. Если ставилась соответствующая задача, то он не сможет их даже прочитать.
Почтовые разве не так работают?
В рамках неконфиденциального обмена — так и работают. Именно поэтому есть больше одного варианта обеспечения конфиденциальности/подлинности почты поверх существующих небезопасных протоколов.
Правда, сильно сомневаюсь, что в другую систему нельзя вклиниться.
Зря сомневаетесь.
Если же вы пеняете на методологическую непроработанность системы, то тут, являясь специалистом в области методологии, я категорически против.
Я пеняю на то, что ваша методология, став из локальной распределенной, так и не обрела необходимые для распределенной системы качества. И это — методологическая ошибка.
Моя система реализована в соответствии с лучшей на сегодня методологией.
Еще раз: вы можете сколько угодно гордиться придуманной вами методологией учета, здесь моей компетенции недостаточно, чтобы как-то о ней судить. Но когда вы говорите о том, что вы предлагаете стандарт обмена данными между бухгалтерскими программами, вы выходите за границы вашей учетной методологии, и вступаете в совершенно другую область.
Здесь мне сложно вам возражать. Будем считать да, на сегодня защита данных не обеспечена надлежащим образом, ввиду недостаточной работы и профессионализма исполнителей.
Что касается стандарта, он ведь к защите данных отношения не имеет? Вполне себе рабочий стандарт. И тут я не выхожу за границы учетной методологии, а нахожусь в самой ее середочке.
Что касается стандарта, он ведь к защите данных отношения не имеет? Вполне себе рабочий стандарт. И тут я не выхожу за границы учетной методологии, а нахожусь в самой ее середочке.
Что касается стандарта, он ведь к защите данных отношения не имеет?
Имеет. Если стандарт заранее не предполагает решение проблемы хотя бы подлинности данных, в сегодняшних ИТ его можно считать мертвым.
Обеспечение подлинности данных — проблема техническая, сам стандарт — проблема методологическая. Я, в силу специализации, решал проблему методологическую. Но конечно, отсутствие приемлемого технического решения — моя вина, целиком и полностью сознаю и готов встать на путь исправления, если кто-нибудь мне такой путь предложит.
Обеспечение подлинности данных — проблема техническая, сам стандарт — проблема методологическая.
Да нет же. В распредленной системе определение подлинности операции — это вопрос методологии, действующей в этой системе. То, что вы этого все еще не осознаете — следствие, простите за прямоту, вашей нехватки опыта в построении и проектировании таких систем.
Может, и так. А может, подобные упреки — следствие непонимание вами того, что такое учетная методология. Она не средство программирования или обеспечения конфиденциальности данных, а совсем другое. Самоценная дисциплина (или поддисциплина).
Вот только в посте вы пишете не об учетной методологии, а о «стандарте обмена данными между бухгалтерскими программами». Ваша методология сама по себе мне не интересна.
Хм. Пожалуй.
Остается только спросить: что же те, у кого такой большой опыт интеграции систем, не могут организовать корреляцию учетных баз, какую я предлагаю? Я вам отвечу: потому что они, с присущим программистам апломбом, пытаются с помощью наисовременнейших программных средств автоматизировать устаревшую методологию двойной записи и тот тихий ужас, который называется регламентацией бухгалтерского учета. Задача сама по себе недостижимая. Ровно до тех пор, пока методология бумажного учета не будет заменена на единую методологию компьютерного учета, в рамках которой можно будет вести произвольный и нерегламентированный учет чего бы то ни было.
Остается только спросить: что же те, у кого такой большой опыт интеграции систем, не могут организовать корреляцию учетных баз, какую я предлагаю? Я вам отвечу: потому что они, с присущим программистам апломбом, пытаются с помощью наисовременнейших программных средств автоматизировать устаревшую методологию двойной записи и тот тихий ужас, который называется регламентацией бухгалтерского учета. Задача сама по себе недостижимая. Ровно до тех пор, пока методология бумажного учета не будет заменена на единую методологию компьютерного учета, в рамках которой можно будет вести произвольный и нерегламентированный учет чего бы то ни было.
что же те, у кого такой большой опыт интеграции систем, не могут организовать корреляцию учетных баз, какую я предлагаю?
А зачем им организовывать такую корреляцию, как вы предлагаете?
единую методологию компьютерного учета, в рамках которой можно будет вести произвольный и нерегламентированный учет чего бы то ни было.
«Единая… произвольный и нерегламентированный». Не взлетит. Причины описаны как раз выше.
(Нет, ну правда же. Люди годами составляют онтологии для систем интеграции — не бухгалтерских, поэтому все ваши выпады в сторону устаревших методологий бессмысленны, — а вы предлагаете просто взять, и заменить это парой «ключ-значение». Вы хотя бы про RDF слышали?)
А зачем им организовывать такую корреляцию, как вы предлагаете?
Затем, чтобы товар нельзя было закупить по-черному, у подставной организации. Но программистам это ни к чему, понятное дело, за это денег не заплатят.
(Нет, ну правда же. Люди годами составляют онтологии для систем интеграции — не бухгалтерских, поэтому все ваши выпады в сторону устаревших методологий бессмысленны, — а вы предлагаете просто взять, и заменить это парой «ключ-значение». Вы хотя бы про RDF слышали?)
Я тоже человек и тоже решал эту проблему годами, так что я один из этих людей, о которых вы говорите.
Про RDF не слышал, вот сейчас посмотрел. На первый взгляд, проблематика сходна с моей, которую я решал в изобретенной мной экаунтологии. В ней именно рассматриваются понятия объекта, субъекта и их свойств.Так что восклицать: «Ах, какой я глупый, не знал про RDF!», — извините, не намерен. Выработанного в экаунтологии категориального аппарата для решений учетных задач вполне хватает. А претензии по делу я принимаю — надеюсь, вы в этом убедились.
Затем, чтобы товар нельзя было закупить по-черному, у подставной организации.
А зачем эту проблему решать интеграторам?
(я уж не говорю о том, что то, что вы предлагаете в посте, эту проблему не решит, поскольку оно не налагает никаких регламентных ограничений, а без них эту проблему решить нельзя)
Я тоже человек и тоже решал эту проблему годами, так что я один из этих людей, о которых вы говорите.
Неа. У вас так и нет (и не планируется) введения фиксированной онтологии.
На первый взгляд, проблематика сходна с моей, которую я решал в изобретенной мной экаунтологии.
Посмотрите еще раз.
В ней именно рассматриваются понятия объекта, субъекта и их свойств.
Понятия объекта и его свойств рассматриваются в любой модели, связанной с объектами.
Обращаю внимание: время, установленное на компьютерах отправителя и Получателя, должно быть синхронизированоА теперь открываем учебник и видим что синхронизировать время невозможно, всегда будет небольшое расхождение, ну и конечно при попытке использовать описанное поделие для чего-то автоматического — обязательно эта проблема вылезет. Это безотносительно вопросов о том зачем вообще нужен этот велосипед, на это lair уже ответил.
Небольшое расхождение роли не играет, тем более что система позволяет вести учет в любой временнОй продолжительности, от секунд до лет.
По поводу велосипеда уже посыпаю голову пеплом. Единственное мне оправдание — то, что система единого всемирного учета не реализована, и перспективы ее туманны, особенно если глядеть с моей методологической колокольни.
По поводу велосипеда уже посыпаю голову пеплом. Единственное мне оправдание — то, что система единого всемирного учета не реализована, и перспективы ее туманны, особенно если глядеть с моей методологической колокольни.
«Небольшое расхождение» в вашем случае приведет к тому что все записи перемешаются, как только системой станет пользоваться больше 2х человек или как только ее будут использовать другие системы.
Что значит перемешаются? Система распределенная, корреляция между клиентскими базами добровольная. В клиентской базе ничего перемешаться не может по определению, раз клиент вносит записи в свою базу после одобрения. Не понял суть претензии.
Это значит что вам не нужно лезть в области в которой вы ничего не понимаете (вроде это вам несколько раз в каждом посте говорят). Если в вашей системе не гарантируется консистентность очередности сообщений и вообще нет какого либо механизма эту очерденость поддерживать — поздравляю, вашу систему можно поставить тете Маше и тете Клаше. Использовать ее в промышленности нельзя, уж тем более учитывая что проблемы могут возникнуть не просто финансовые — но и налоговые (в смысле неправильных отчетностей).
Кроме того похоже вы не понмаете даже сути термина «распределенный», если вас волнует только то что в клиентской базе все записано по мере поступления — это ни разу не распределенная система.
Кроме того похоже вы не понмаете даже сути термина «распределенный», если вас волнует только то что в клиентской базе все записано по мере поступления — это ни разу не распределенная система.
Понятно. На личные выпады мне сложно отвечать, так как я действительно мало что понимаю в программировании. Зато понимаю в бухгалтерии, в частности то, какой налоговый и финансовый маразм вы, технари, автоматизируете, сами того не замечая. А выправить предметную область мозгов не хватает, тут специалисты иного профиля нужны, да и кто им позволит? Ваша ссылка на неправильные отчетности иллюстрирует данное печальное положение наглядно. К слову, я изначально не собирался автоматизировать промышленность, в рамках законодательства это невозможно: система для теть Маш и Клаш предназначалась. Ну да Бог с ней, с системой, с ней полная ясность. Претензии весомы, я не уверен, что захочу исправлять ошибки (хотя исправление возможно, в принципе). Спасибо за теплый прием! Заглядывайте на огонек к нам, методологам, обещаю столь же дружескую встречу.
Проблема не в том, что вы мало что понимаете в программировании. Проблема в том, что вы при этом пытаетесь делать работу программиста.
Мне вот было бы интересно прочитать статью про методологию бухгалтерии. Но за описанием программы методологии, к сожалению, просто не видно.
Мне вот было бы интересно прочитать статью про методологию бухгалтерии. Но за описанием программы методологии, к сожалению, просто не видно.
А выправить предметную область мозгов не хватает, тут специалисты иного профиля нужны, да и кто им позволит?Встречный вопрос: а кто вам не позволяет?
Проблема в том, что вы при этом пытаетесь делать работу программиста.
Это ж от безысходности. Я пару лет пытался найти людей, которые реализовали бы мои — методологические! — идеи, но где ж их взять, людей? После пары минут общения все понимают, что на этом не заработаешь, поэтому предпочитают автоматизировать то, что по своей сути антикомпьютерно, — современную бухгалтерию. Только по этой причине я сел за программирование.
Мне вот было бы интересно прочитать статью про методологию бухгалтерии.
Сейчас кину в ссылки на некоторые их моих работ по методологии в личку.
Встречный вопрос: а кто вам не позволяет?
Так и и пытаюсь, вот в этом самом посте, что-то изменить в лучшую сторону. Хотя попытка не самая удачная, признаться.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
А вы получили a-Mail?.. Бухгалтерская почта