В соответствии с замыслом, a-Mail (accounting mail, то есть бухгалтерская почта) – ближайший родственник электронной почты e-mail. Отличие в том, что по электронной почте данные передаются в произвольном текстовом виде, а по бухгалтерской почте – в формализованном, предназначенном для автоматического размещения в учетной базе пользователя. Фактически речь идет стандарте обмена данными между бухгалтерскими программами.
Стандарт реализован в ходе проекта «Учетная Логика». Данная история разворачивалась на Хабре в течение трех лет и теперь, похоже, близка к завершению.
Под катом находится краткое описание стандарта a-Mail и сетевых возможностей «Учетной Логики» версии 3.0 (в предыдущих версиях данная функция отсутствовала).
Прежде всего, для чего это нужно? Для того чтобы информация из одной учетной базы попадала непосредственно в другую учетную базу.
Представим заурядную сделку купли-продажи. Имеется продавец, также имеется покупатель. Продавец ведет учет в одной бухгалтерской программе, покупатель – в другой. Очевидно, что покупателю выгодней получать информацию – как о заплаченных деньгах, так и о купленном товаре – не в текстовом виде, а в виде записей в учетную базу данных. В результате проведения автоматизированной сделки пользователю должно поступить не текстовое сообщение типа «С вас снята такая-то сумма за такие-то товары», требующее дополнительной обработки посредством ввода соответствующих записей в личную учетную базу, – нет, учетная база должна измениться соответствующим образом без участия пользователя. Какое еще участие, когда вся необходимая информация налицо?!
Да, архитектура бухгалтерских программ различна, но извините, автоматизируемая ими предметная область едина! По этой простой причине разработка стандарта – не вопрос совмещения различных программных архитектур, как может кому-то ошибочно показаться, а вопрос стандартизации самой предметной области.
Рассмотрим тему подробней.
Одно из самых распространенных отношений в гражданском праве – упомянутый выше договор купли-продажи. При сделке данного вида отношения между сторонами распадаются на две части:
- передача товара от продавца покупателю,
- передача денег от покупателя продавцу.
Части сделки противоположны по направленности, но идентичны по смыслу, поэтому в качестве полигона для обкатывания идеи можно взять любую часть, допустим первую.
Продавец передал покупателю товар. Имеется одна операция – передача товара, затрагивающая обе стороны, и товар, переходящий из рук в руки. Если перейти на бухгалтерский язык, то операция – это бухгалтерская проводка, а товары – это объекты учета. Каждую из этих сущностей можно описать некоторыми свойствами, например установить, что:
- операция характеризуется временем совершения, комментарием (это практически обязательные бухгалтерские реквизиты), также названием договора и тем, доходы или расходы составляет,
- товары характеризуются названием, массой, стоимостью (опять-таки) обязательные бухгалтерские реквизиты), также сортом, страной-производителем, фирмой-производителем и т.п.
Так делается в любой бухгалтерской программе, без исключений. Наборы применяемых свойств в каждой из бухгалтерских программ, также у разных пользователей различны – разумеется, разумеется! – но что мешает использовать пересечения свойств?
Допустим, продавец учитывает товары по свойствам «Название», «Цена», «Масса», «Склад», «Сорт», «Ответственное лицо», тогда как покупатель учитывает свое личное имущество по свойствам «Название», «Стоимость», «Масса», «Тип имущества», «Местонахождение». Свойства, являющиеся пересечениями обеих множеств: «Название», «Масса». Таким образом, если продавец перешлет покупателю информацию о проданном товаре – в том виде, в каком она фигурирует в базе данных продавца, – то покупатель, верней используемое им программное средство, сможет, отфильтровав полученный контент по совпадающим полям, внести в свою базу необходимые данные: значения по полям «Название», «Масса». И любым другим, названия которых совпадают в учетных базах продавца и покупателя.
Сложность возникает в случае, когда названия полей различны, а содержание идентично: например, у продавца поле называется «Цена», а покупатель обозвал данное поле «Стоимостью». Тем более, если продавец и покупатель вообще разноязычные: в этом случае названия полей в их базах данных будут гарантированно не совпадать.
Решение традиционно: применение языка, считающегося межнациональным для делового общения – английского. Поля баз данных предлагается именовать на английском, при этом брать стандартные наименования – из списка, который в случае популярности a-Mail непременно будет составлен. В рамках же пользовательского интерфейса, дабы пользователи ощущали себя в привычной языковой среде, ничто не мешает присваивать полям псевдонимы. Магазин может использовать псевдоним «Цена», а покупатель – псевдоним «Стоимость», но, в случае если истинные названия полей в обоих случаях будут «Cost», проблем не возникнет: данные о цене товара будут благополучно скопированы из базы продавца в базу покупателя.
Остается решить, имеет ли смысл пересылать покупателю свойства не только объектов учета – товаров, – но и самой операции, в том виде, в котором она регистрируется в учетной базе продавца. По моему мнению, не стоит. Возьмем ту же куплю-продажу: для продавца данная сделка представляет собой продажу, а для покупателя – куплю, нет резона пытаться соединить их в одно целое. Строго говоря, при купле-продаже это совсем несложно (купля-продажа – это и есть общее название сделки для всех сторон), но как быть в случае, скажем, товарооборота между двумя юридическими лицами, когда продавец учитывал отпущенный товар на складе № 1, а покупатель принял купленный товар на склад № 2? Очевидно, что некоторые свойства операций у обеих сторон сделки могут совпадать, но могут и не совпадать. Это характеристика не софта, и не архитектуры баз данных, а самой автоматизируемой сущности. Ввиду этого операция в a-Mail описывается конечным набором традиционных для бухгалтерии свойств.
После теоретического экскурса переходим к рассмотрению самого стандарта.
Итак, от продавца (Отправителя) к покупателю (Получателю) – через сервер разработчика – пересылаются данные:
- об операции,
- об объектах учета, переданных в рамках данной операции.
Для пересылки используется формат json.
Данные об операции представляют собой переведенную в json структуру Dictionary<string, string> с конечным набором значений, основными из которых являются a-Mail данные Отправителя и Получателя (логин и сублогин; сублогин – это название локальной базы данных пользователя, ввиду того что пользователь может вести одновременный учет в нескольких базах), также дата регистрации операции и комментарий. Тут все понятно: это либо адресные, либо стандартные для бухгалтерской проводки реквизиты.
В комментарии Отправитель может указать реквизиты, отсутствующие в приведенном списке, например номер договора, дату договора и т.п., чтобы по поступлении a-Mail Получатель перенес эти сведения в поля своей базы. Да, перенес вручную, однако альтернативой является сложное – ручное же! – определение списка разрешенных или же запрещенных к переносу полей, при этом нет никакой гарантии, что не потребуется ручная корректировка. А дата регистрации и комментарий присутствуют в любой бухгалтерской записи, с ними проблем не возникнет.
Так как a-Mail разрабатывался непосредственно для «Учетной Логики», данные об операции содержат полезные нововведения. В частности, помимо даты регистрации, указывается также дата совершения. Таким способом становится возможным регистрация не только текущих хозяйственных операций, но и обязательств.
Предположим, оплата зарегистрирована 10 мая, но передача товара должна состояться 25 июня: имеет место тривиальная отсрочка оплаты. В таком случае – если дата регистрации операции меньше даты ее совершения, – имеет место обязательство. «Учетная Логика» пользуется данной оригинальной методикой, но это не обязательное требование. В общем случае дата регистрации операции совпадает с датой совершения операции, что означает: операция зарегистрирована и совершена в указанный момент времени.
Данные об объектах учета, пересылаемых в рамках операции, имеют более сложную структуру List<Dictionary<string, string>> – за счет того, что объектов в рамках одной операции может быть множество. Во внутренней части структуры (в словаре) указывается название поля (то есть название свойства объекта), значение по данному полю и формат. Таким образом, не имеет теоретических ограничений не только число передаваемых объектов, но и число свойств, которыми могут быть охарактеризованы такие объекты.
Данные об операции-объектах пересылаются через сервер разработчика, от Отправителя к Получателю, однако одной пересылкой дело не завершается. Смысл a-Mail заключается в корреляции между учетными базами (при условии одобрения корреляции обеими сторонами сделки), поэтому Получатель должен сообщить Отправителю, согласен ли он принять посланные ему объекты. При обычной электронной переписке нет необходимости возвращать письмо обратно Получателю – ненужное письмо всего лишь подлежащий утилизации хлам, – однако в бухгалтерской почте необходимость в этом появляется. При отправке по a-Mail Отправитель наблюдает в своей учетной базе выбытие соответствующего объекта, которое… может быть отыграно назад в случае отказа в приеме. Получатель отказался от сделки, следовательно, вещь осталась у прежнего владельца. На случай, когда Получатель отказывается из-за пустой прихоти – вещь купил, а регистрировать в своей базе не желаю, и все! – в «Учетной Логике» предусмотрена опция удаления объекта взамен восстановления. Получатель отказался от объекта, но Отправитель игнорирует отказ Получателя, и объект продолжает считаться выбывшим.
Согласие или отказ Получателя принять вещи (то есть зарегистрировать их поступление в своей учетной базе) отсылается на сервер для уведомления Отправителя – в том же порядке, с использованием формата json, что и пересылка объекта. Только направление движения информации происходит в обратном порядке: от Получателя к Отправителю.
Таким образом, имеется четыре типа обращения сервера к клиенту, при которых происходит обмен информацией в ту или другую сторону.
- Передача данных от Отправителя на сервер.
- Их пересылка Получателю.
- Передача на сервер согласия или отказа Получателя принять данные.
- Сообщение об отказе или согласии Отправителю.
Остается посмотреть, как a-Mail реализован в интерфейсе «Учетной Логики».
1. Сначала необходимо зарегистрироваться в системе – получить a-Mail адрес.
2. После регистрации нужно добавить, то есть учесть, какую-нибудь вещь. Пока в системе не учтено ни одной вещи, нечего передавать контрагенту.
3. После того, как вещь появилась, ее можно кому-нибудь передать. В принципе, передавать можно самому себе (для этого придется зарегистрироваться под вторым логином), но лучше договориться с товарищем.
Для передачи необходимо выбрать пункт меню «Операции/Передать вещи…», затем в открывшемся диалоговом окне указать a-Mail Получателя.
Первая часть a-Mail – логин (под которым пользователь регистрируется), вторая часть – сублогин (название пользовательской базы – в начальном окошке «Войти под именем»). Ок, и a-Mail ушло.
4. Мысленно переносимся в базу Получателя.
Пункт меню «Операции/Получить вещи…». В открывшемся диалоговом окне Получатель увидит принятый a-Mail. Можно отказаться от принятия или согласиться. Во втором случае в пользовательскую базу будут добавлены данные о поступившем объекте.
Обращаю внимание: время, установленное на компьютерах отправителя и Получателя, должно быть синхронизировано, в противном случае возможны неожиданности. К примеру, если на компьютере Отправителя время установлено с 5-минутным опозданием, то Получатель увидит поступление через 5 минут – в момент, указанный в качестве даты выполнения действия (для чего потребуется перезагрузить рабочую область, приблизительно так, как это осуществляется в браузере). Так происходит вследствие того, что «Учетная Логика» отображает вещи, зарегистрированные на момент, указанный на таймере. Если передать вещи будущим моментом, Получатель увидит их не раньше указанного срока.
Настоящий стандарт разрабатывался для «Учетной Логики», однако он применим к прочим бухгалтерским программам, ведь суть передачи вещей от Отправителя к Получателю всегда идентична. Совершенно понятно, что – при наличии учета с обеих сторон – информация должна записываться единовременно в обеих базах (либо в одной общей), коррелируя между собой. Вы же не полагаете иначе?
Если найдутся желающие вставить a-Mail модуль в готовый бухгалтерский софт, обращайтесь в личку, авторы проекта сделают все от них зависящее, чтобы мероприятие состоялось. Цель: обмен данными между бухгалтерскими программами разных производителей.
Скачать «Учетную Логику» 3.0 WWW можно по этой ссылке.
В настоящий момент бухгалтерская почта проходит тестирование. От того, какой интерес будет проявлен к a-Mail со стороны сведущей публики, зависит будущее проекта.
Комментарии (145)
serafims
02.12.2015 11:22Лучше бы единый формат, с текстовым представлением (Base64?), для вставки реквизитов компаниии (и пересылки) их придумали.
Один раз закодировал во что-то типа
«TmFtZT3QntCe0J4g0KDQuNC20YHQutC40Lkg0JvQsNC80L/QvtCy0YvQuSDQl9Cw0LLQvtC0DQrQmNCd0J09MTIzNDU2Nzg5DQpCYW5rPdCj0YDQsNC70YzRgdC60LjQuSDQkdCw0L3QuiDQoNC40JoNClR5cGU9T09PDQpPR1JOPTU5ODc0NjUyOTgzNzY=»
и потом вставляешь и все. Ну или Json…
alekciy
02.12.2015 11:25Json грубо говоря это «транспортный» уровень. Т.е. формат передаваемых данных. Что-бы это реально работало как стандарт нужно описание именно «словаря», т.е. список допустимых полей и их значений.
mikejum
02.12.2015 11:28Чем JSON от текстового представления отличается, если по сути? То же название компаний плюс данные об операции плюс данные о пересылаемых вещах. Принципиальных отличие нет, по-моему, а о частностях можно спорить.
alekciy
02.12.2015 11:23+1Может я невнимательно читал, но где собственно текст самого стандарта? Не его имплементация в Х, а именно сам стандарт (ух коль скоро первоначальный посыл статьи именно в этом).
mikejum
02.12.2015 11:35-5Описание стандарта будет предоставлено желающим сделать свой модуль. Общие достаточные сведения указаны в посте, а перечень полей, типов запросов и адресов, по которым их отправлять — для тех, кто захочет присоединиться. На данном этапе не я не готов обнародовать эти данные, тем более что технология предполагает передавать каждому разработчику идентификатор (с целью отслеживать, с каких модулей поступает спам). Возможно, я не прав. Так что стандарт пока условно-открытый, о чем сказано в посте: «обращайтесь в личку». Если проявится обвальный интерес, стандарт может стать полностью открытым. Н-да. Но тут свои возможности я оцениваю трезво…
lair
02.12.2015 11:51Описание стандарта будет предоставлено желающим сделать свой модуль.
Тогда о чем вообще пост?mikejum
02.12.2015 11:55Пост о том, что бухгалтерскую почту сделать легко и просто, а эффект, в том числе финансовый, может быть велик.
lair
02.12.2015 13:17Пост о том, что бухгалтерскую почту сделать легко и просто
Давайте я сразу и в лоб спрошу: сколько гетерогенных интеграций вы провели за свой опыт?mikejum
02.12.2015 13:37Послушайте, я ведь не притворяюсь программистом, я методолог учета. Если вы укажете на мои ошибки как программиста, буду признателен. Но если продолжите кичиться умными терминами, отвечу. К примеру, вы теории двух рядов счетов счетов от теорий трех рядов счетов твердо различаете?
lair
02.12.2015 13:46Послушайте, я ведь не притворяюсь программистом, я методолог учета. Если вы укажете на мои ошибки как программиста, буду признателен.
А это и не программная ошибка, а аналитическая. Вы по каким-то причинам считаете, что сделать интеграцию систем, основанных на разной методологии — легко; хотя опыт показывает, что сложно интегрировать даже системы, основанные на одной методологии. У вас есть реальный опыт (как методолога, не как программиста) интеграции хотя бы двух разных систем друг с другом?
К примеру, вы теории двух рядов счетов счетов от теорий трех рядов счетов твердо различаете?
Нет, а мне надо?mikejum
02.12.2015 14:01-1Вы по каким-то причинам считаете, что сделать интеграцию систем, основанных на разной методологии — легко; хотя опыт показывает, что сложно интегрировать даже системы, основанные на одной методологии.
Я начинающий программист, да, но методологического опыта у меня выше крыши, на десяток профессоров хватит. Полсотни учебников и учебных пособий по бухгалтерскому учету, разработка собственной учетно-философско-информационной теории, теперь вот написание кода программного продукта. Этого недостаточно?lair
02.12.2015 14:21+1Этого недостаточно?
Я задал конкретный вопрос: у вас есть реальный практический опыт интеграции двух разных учетных систем друг с другом?mikejum
02.12.2015 14:49Почему вы считаете, что для получения практического решения обязателен практический опыт? К примеру, я раньше ни разу в жизни не складывал 31 и 8, вот другие числа складывал, а именно эти нет. И вы полагаете, я не смогу этого сделать? Я, знаете ли, обладаю относительно широкими познаниями о том, что вообще учитывается, как учитывается (и как учитывалось на протяжении веков), много лет изучал разные системы учета, с учетным софтом тоже сталкивался. И о современной двойной записи тоже все-все-все знаю (сравнительно с большинством других бухгалтеров, тем более программистов, уж точно). И вы пытаетесь убедить меня, что мне недостает практического опыта интеграции двух учетных систем?! А что в них такого, на уровне методологии, имеется, чего бы я не знал? Та же пресловутая двойная запись, в 99% случаев (о чем большинство программистов даже не догадывается). А архитектура и формат баз данных — это, извините, уже дело десятое, это не методология. Вот как вам объяснить… Накладными все предприятия пользуются, независимо от учетного софта? И ничего, обходятся как-то? У меня речь идет о том, чтобы пересылать данную информацию в электронном виде. Всего-навсего. А как запихнуть информацию из накладной в конкретную архитектуру — дело разработчиков, я в данную область и не лезу.
lair
02.12.2015 14:54Почему вы считаете, что для получения практического решения обязателен практический опыт?
Потому что без практического опыта вы не сможете оценить сложность задачи.
К примеру, я раньше ни разу в жизни не складывал 31 и 8, вот другие числа складывал, а именно эти нет. И вы полагаете, я не смогу этого сделать?
Вот поэтому я и спрашиваю про интеграцию двух любых учетных систем по любому протоколу, а не только по a-Mail.
И вы пытаетесь убедить меня, что мне недостает практического опыта интеграции двух учетных систем?! А что в них такого, на уровне методологии, имеется, чего бы я не знал?
То, что интеграция — это всегда больше, чем совокупная сложность интегрируемых зон в каждой интегрируемой системе. Недостаточно просто знать каждую из систем, нужно еще знать, как делается интеграция.
У меня речь идет о том, чтобы пересылать данную информацию в электронном виде. Всего-навсего
Вот об это «всего-навсего» люди годами бьются. Есть такой малоизвестный госпроектик УНИФО/ГИС ГМП…mikejum
02.12.2015 14:59Это смотря какие люди… Если такие же, какие правят бал в бухгалтерском учете, тогда они десятилетиями могут «биться». А что, тепло, светло и мухи не кусают.
То, что интеграция — это всегда больше, чем совокупная сложность интегрируемых зон в каждой интегрируемой системе. Недостаточно просто знать каждую из систем, нужно еще знать, как делается интеграция.
На данное обвинение я, как мне кажется, полно ответил в самом посте:
Да, архитектура бухгалтерских программ различна, но извините, автоматизируемая ими предметная область едина! По этой простой причине разработка стандарта – не вопрос совмещения различных программных архитектур, как может кому-то ошибочно показаться, а вопрос стандартизации самой предметной области.
lair
02.12.2015 15:05Это смотря какие люди…
Разные люди.
На данное обвинение я, как мне кажется, полно ответил в самом посте:
Не, не ответили.
Во-первых, ваша фраза подразумевает обязательную унификацию методологии учета (что противоречит посылу про интеграцию различных учетных систем).
Во-вторых, даже в случае с одной методологией, переход от локальной системы к распределенной всегда увеличивает сложность (если только методология изначально не была распределенной, чего у вас явно нет), а вы это игнорируете.mikejum
02.12.2015 15:17Не согласен, ответил. Стандарт предполагает унификацию только передаваемых данных, но никак не методологий, используемых в стороннем софте.
Что вы имеете в виду под переходом от локальной системе к распределенной, не понял. Моя методология не принудительная, получатель может отказаться от принятия вещи. Другое дело, что у него появляется возможность сразу запихнуть информацию в свою личную базу данных.lair
02.12.2015 15:44Стандарт предполагает унификацию только передаваемых данных, но никак не методологий, используемых в стороннем софте.
Вы не можете унифицировать передаваемые данные «без потерь», не унифицируя методологию.
Что вы имеете в виду под переходом от локальной системе к распределенной, не понял
У вас была система, в которой один пользователь учитывал свои вещи в своей БД. Теперь вы хотите сделать обмен информацией об учете между несколькими такими пользователями и несколькими БД. Была локальная система, стала распределенная.mikejum
02.12.2015 15:52Вы не можете унифицировать передаваемые данные «без потерь», не унифицируя методологию.
Почему? Как раз этот вопрос решен: данные передаются лишь в части пересечения реквизитов.вещей.
По поводу распределенной системы понял. Сложность увеличивается, конечно: если к системе что-то новое приделываешь, сложность всегда увеличивается.lair
02.12.2015 16:02Как раз этот вопрос решен: данные передаются лишь в части пересечения реквизитов.вещей.
Вот вы и потеряли данные, которые снаружи пересечения (даже если семантически они идентичны). Что веселее, внутри пересечения вы все равно не знаете, идентична ли семантика данных с одинаковыми именами.
По поводу распределенной системы понял. Сложность увеличивается, конечно: если к системе что-то новое приделываешь, сложность всегда увеличивается.
Вот именно поэтому интеграция — это отдельный опыт. Он у вас есть?mikejum
02.12.2015 16:12Хм… Иногда вы попадаете в точку.
Ответ такой. Дело в том, что никакой учет не обеспечивает целостности и правдивости данных. Вбить в качестве учетных данных можно что угодно. К примеру, составили акт о списании испортившихся вещей, а на самом деле растащили по домам. Нет никакого способа — методологически! — сделать учетные данные правдивыми. Точнее, есть, но до него пока далеко: автоматическая регистрация прихода и расхода вещей, — неподкупные датчики. По этой причине подмеченное вами обстоятельства (и в самом деле, методологическое) ничего не меняет в общем раскладе. Каждый учитывает так, как хочет, и то, что хочет. Свою задачу я видел в том, чтобы автоматизировать учет при желании, с обеих сторон, коррелировать учетные базы.
Вот именно поэтому интеграция — это отдельный опыт. Он у вас есть?
Опыта интеграции софта — нет. Зато, как у всякого бухгалтера, имеется опыт интеграции филиалов, которые ведут разный учет, зачастую с использованием разного софта. Не знаю, говорят вам что-нибудь такие понятия как консолидация отчетности или счет 79 «Внутрихозяйственные расчеты». Это тоже интеграция данных, между прочим.lair
02.12.2015 16:15Свою задачу я видел в том, чтобы автоматизировать учет при желании, с обеих сторон, коррелировать учетные базы.
Желания мало, нужны еще знания и ресурсы. То решение, которое вы приводите в посте, никак не решает тех проблем, которые мешают такой интеграции сейчас, в существующих решениях.
Опыта интеграции софта — нет.
Тогда я вам настоятельно рекомендую воздержаться от оценки сложности таких задач, пока вы не попробуете это сделать хотя бы пару раз.mikejum
02.12.2015 16:29Да, про знания — это вы с плеча, от всей души. :) А вот по поводу ресурсов согласен, нет у меня таких ресурсов, иначе многие из бухгалтеров лишились бы работы.
Еще, по поводу решения проблем. Не уверен, что вы понимаете, что мешает решению данных проблем сейчас: подскажу, что это никоим образом не технические сложности, а вполне себе волюнтаристские…
Тогда я вам настоятельно рекомендую воздержаться от оценки сложности таких задач, пока вы не попробуете это сделать хотя бы пару раз.
Видите ли, я высказывался о решении достаточно узкой задачи. Моя система предполагает не обязательный учет чего бы то ни было, а добровольный. Если получатель согласен с присланными характеристиками вещи, он нажатием на кнопку отправляет запись в базу данных; если нет — подвергает запись корректировке. Что вы все об интеграции твердите? Базы интегрировать не нужно: попала информация в яблочко — жми Ок; не попала — получатель ничего не теряет.lair
02.12.2015 16:33Не уверен, что вы понимаете, что мешает решению данных проблем сейчас: подскажу, что это никоим образом не технические сложности, а вполне себе волюнтаристские…
Между техническими и волюнтаристскими есть еще много других вариантов. Например — аналитический. И это, поверьте мне, реально существующая проблема.
Что вы все об интеграции твердите?
Потому что задача, которую вы решаете — интеграционная.
Базы интегрировать не нужно: попала информация в яблочко — жми Ок; не попала — получатель ничего не теряет.
Если в 99% случаев пользователь «не жмет Ок», смысла в этом «стандарте» нет.
Ну и да, описанное вами решение в таком случае не автоматическое (напомню: «по бухгалтерской почте [данные передаются] в формализованном, предназначенном для автоматического размещения в учетной базе пользователя.»)mikejum
02.12.2015 16:41Решение частично автоматическое, в зависимости от конкретной ситуации. Подбирая варианты, можно задать 1% или 99% попадания, но такой способ доказательств некорректен.
Если в 99% случаев пользователь «не жмет Ок», смысла в этом «стандарте» нет.
Вы уверены, что, буде мои идеи реализуются, покупателю, получающему из магазина сообщение: <Название> = «молоко», <Производитель> = «Останкино», <Емкость> = 1 литр, <Цена> = 80 руб., <Срок годности> = 2 декабря 2015 г., этого окажется недостаточно для ведения личного учета?lair
02.12.2015 16:46Решение частично автоматическое, в зависимости от конкретной ситуации
И как определять, какая сейчас ситуация?
Вы уверены, что, буде мои идеи реализуются, покупателю, получающему из магазина сообщение: <Название> = «молоко», <Производитель> = «Останкино», <Емкость> = 1 литр, <Цена> = 80 руб., <Срок годности> = 2 декабря 2015 г., этого окажется недостаточно для ведения личного учета?
Мне недостаточно. Потому что «молоко» — это «продукт», «название» у него «Останкинское», а еще мне нужна дата производства и срок годности, записанный в днях. Заодно я хочу знать, что цена этого пакета молока — 80 рублей, но я его купил за 72, потому что у меня скидка в 10%. А год назад мне нужна была бы жирность этого молока, потому что у меня были раздельные траты на цельное и 1.5%.mikejum
02.12.2015 16:50И как определять, какая сейчас ситуация?
Так пользователь и определит при добавлении. Запись же не автоматически попадает в базу, ее предварительно требуется одобрить. При одобрении можно откорректировать.
Мне недостаточно.
Ну хорошо, вам недостаточно. Желаете набивать вручную все реквизиты или некоторые предпочтете все же запихнуть в базу автоматически?lair
02.12.2015 16:58Так пользователь и определит при добавлении.
Значит, это не автоматическое решение, а автоматизированное.
Желаете набивать вручную все реквизиты или некоторые предпочтете все же запихнуть в базу автоматически?
А вы посмотрите, сколько реквизитов реально совпало, и сколько мне надо набивать ручками. По опыту работы с системой, которая часть данных брала автоматически, а остальную (заметим, меньшую!) надо было править руками — это быстро надоедает, и эту систему (или, по крайней мере, интеграцию) просто забрасывают.mikejum
02.12.2015 17:18Да, автоматизированное, тут вы правы. Некорректно употребил термин, виноват.
По опыту работы с системой, которая часть данных брала автоматически, а остальную (заметим, меньшую!) надо было править руками — это быстро надоедает, и эту систему (или, по крайней мере, интеграцию) просто забрасывают.
Многообразный у вас опыт, однако. Тем не мене представить, что ручное переписывание с накладных лучше, все равно не могу.lair
02.12.2015 17:21Тем не мене представить, что ручное переписывание с накладных лучше, все равно не могу.
Вы можете не поверить, но ручное переписывание данных с накладных действительно лучше, чем сверка всех данных с этой же накладной глазами (особенно если за системой таки замечены ошибки, скажем, в два порядка в суммах).mikejum
02.12.2015 17:25Так ведь и в накладной возможны ошибки. Для проверки придется лезть в договор или прошлые учетные данные, то есть глазками побегать… Общеучетные претензии в рамках данного конкретного поста не принимаются.
lair
02.12.2015 17:32А вот если построить автоматизированную систему с жесткими формальными правилами, то такая активность пользователя будет сведена к минимуму.
mikejum
02.12.2015 17:46Жесткие формальные правила возможны при полной регламентации, которая отсутствует. Я исходил, наоборот, из корреляции баз на основе полной анархии. Ясно же, что здесь корреляция возможна лишь по пересекающимся реквизитам.
lair
02.12.2015 17:49Ясно же, что здесь корреляция возможна лишь по пересекающимся реквизитам.
Корреляция возможна только по семантически идентичным реквизитам. В условиях полной анархии это невозможно. Что, собственно, и делает описанный вами подход нежизнеспособным.mikejum
02.12.2015 18:06А одинаковое название — это не семантически идентичный реквизит? Ну, вы даете! Как вы с женой общаетесь, при отсутствии гарантий совпадения семантики в ее голове и вашей?
lair
02.12.2015 18:10А одинаковое название — это не семантически идентичный реквизит?
Конечно, нет. Примеры я уже приводил.
Как вы с женой общаетесь, при отсутствии гарантий совпадения семантики в ее голове и вашей?
Как и полагается людям, с постоянными оговорками и уточнениями.mikejum
02.12.2015 18:19Как ведь и уточнения выполняются между головами, в которых разная семантика! Выходит, вы принципиально не в состоянии друг друга понять.
lair
02.12.2015 18:26А для вас это новость? «Понимание» между людьми — это социальная условность.
Вот только вы радостно ушли от темы. То, что происходит между людьми, не имеет отношения к тому, что происходит между системами. К счастью, для компьютерных систем возможно определить семантическую идентичность тех или иных сущностей.mikejum
02.12.2015 18:40Нет, нельзя, если сущности заполняются людьми. Вы рассматриваете запрещенный случай, когда пользователь намеренно вкладывает в информационный пакет иное содержимое. Ясен пень, содержимое не будет соответствовать наклейке, никто и не сомневается…
lair
02.12.2015 18:43Нет, нельзя, если сущности заполняются людьми.
Можно, можно. Формализованная семантика никак не связана с тем, кем поле заполняется.
Вы рассматриваете запрещенный случай, когда пользователь намеренно вкладывает в информационный пакет иное содержимое.
Это он в моем идеальном мире запрещенный, и этот запрет всячески поддерживается информационными системами. А в условиях полной анархии и отсутствия регламентации это как раз разрешенный случай.mikejum
02.12.2015 18:56Учетные системы имеют дело не с формализованной семантикой, а с информацией, которую вбивают люди. Нет никаких формальных препятствий для введения ошибочных или ложных данных, это азы. Любые такие препятствия можно обойти. Эта ваша претензия абсолютно несостоятельная, не принимается.
lair
02.12.2015 19:00Учетные системы имеют дело не с формализованной семантикой, а с информацией, которую вбивают люди
Это ложная дихотомия. Можно одновременно иметь строго формализованную семантику в системной модели, и при этом получать данные от пользователей. Да, пользователи могут вводить данные, которые не совпадают с этой семантикой. Нет, существуют способы контроля этого, которые сводят такие ошибки (как случайные, так и намеренные) к минимуму.
Нет никаких формальных препятствий для введения ошибочных или ложных данных, это азы.
Есть, есть. Начиная от технических и заканчивая административными.
Любые такие препятствия можно обойти
Обычно самый эффективный способ обойти такие препятствия — не использовать систему.
Эта ваша претензия абсолютно несостоятельная
Какая претензия-то?mikejum
02.12.2015 19:19Есть, есть. Начиная от технических и заканчивая административными.
Технически можно проверить, чтобы цена не была отрицательной. Административно можно наказать кладовщика за недостачу. И что, сильно помогает?
Обычно самый эффективный способ обойти такие препятствия — не использовать систему.
Правильно. Поэтому многие предпочитают вообще не вести учет. Вы же не станете утверждать, что и тут формализованная семантика поможет?
Какая претензия-то?
Претензия в том, что корреляция учетных баз в моей системе может выполняться некорректно.lair
02.12.2015 20:45Технически можно проверить, чтобы цена не была отрицательной. Административно можно наказать кладовщика за недостачу. И что, сильно помогает?
Да.
Правильно. Поэтому многие предпочитают вообще не вести учет. Вы же не станете утверждать, что и тут формализованная семантика поможет?
Тут не поможет.
Претензия в том, что корреляция учетных баз в моей системе может выполняться некорректно.
Ну так она и может выполняться некорректно, разве нет?mikejum
02.12.2015 20:57Да.
Если б помогало, воровства бы уже не было.
Ну так она и может выполняться некорректно, разве нет?
Может. Но это не претензия конкретно к моей системе, это общее положение дел для всех систем учета.lair
02.12.2015 21:03Если б помогало, воровства бы уже не было.
Вы правда не понимаете разницы между «помогает» и «полностью решает проблему»?
Но это не претензия конкретно к моей системе, это общее положение дел для всех систем учета.
Тем не менее некоторые системы учета менее подвержены этой проблеме, нежели то, что вы предлагаете.mikejum
02.12.2015 21:07Вот честно, не вижу, чем моя система более плоха с точки зрения формализованной семантики. По-моему, здесь они все одинаково плохие или одинаково хорошие, как посмотреть. В любой системе в поле <Название товара> я могу вбить «первый сорт», никакая формализованная семантика с этим не справится. Ну, если только из жестко заданного словаря не выбирать, так ведь подобные варианты мы не рассматриваем?!
lair
02.12.2015 21:13Вот честно, не вижу, чем моя система более плоха с точки зрения формализованной семантики.
Тем, что в предлагаемом вами стандарте формализованной семантики нет.mikejum
02.12.2015 21:15Ну хорошо, можете пояснить в двух словах, что вы понимаете под формализованной семантикой?
lair
02.12.2015 21:17Строго описанный набор бизнес-сущностей, их атрибутов и связей, для каждой/каждого из которых описаны бизнес-смысл, жизненный цикл, допустимый набор значений и иные бизнес-правила.
mikejum
02.12.2015 21:29Вполне себе методологическая задача.
Вроде как рассказывал об этом в посте. Логин и сублогин как части общего адреса a-Mail. Даты регистрации и совершения операции. Комментарий к операции. Свойства вещей: обязательные названы (название и масса), остальные являются произвольными. Для каждого поля присутствует указатель на формат: текст или число. Разумеется, каждому значению соответствует поле-идентификатор.
Стандарт делался для моей системы, которая вроде работает (по крайней мере, на уровне методологии), так что формальное описание имеется. Надо было, конечно, выложить все реквизиты, вообще все, за исключением адресов доступа — в этом дал маху, каюсь.lair
02.12.2015 22:02Логин и сублогин как части общего адреса a-Mail.
Заметим в скобках, что это решение уже негенерализуемо.
Даты регистрации и совершения операции. Комментарий к операции.
При этом уникального идентификатора операции нет.
остальные являются произвольными
Вот это и есть неформализованная семантика.
Для каждого поля присутствует указатель на формат: текст или число.
А ничего, что в JSON это не нужно?
(при этом, скажем, дат у вас тоже нет)
Разумеется, каждому значению соответствует поле-идентификатор.
Зачем?
Стандарт делался для моей системы, которая вроде работает (по крайней мере, на уровне методологии), так что формальное описание имеется.
Вот именно поэтому он и не взлетит для остальных систем. Если вы хотите получить обобщенное решение, нужно сразу смотреть на несколько систем.
Ну и да, вы пропустили большую часто того, что я описал выше. Просто названий (и даже названий с типами) недостаточно.mikejum
02.12.2015 22:26Заметим в скобках, что это решение уже негенерализуемо.
Что такое негенереализуемо?
При этом уникального идентификатора операции нет.
С чего вы взяли? Как без идентификатора определять, с какой операцией имеешь дело? В качестве идентификатора используется 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 июня.
** – поскольку любое обязательство (дата его погашения) носит предполагаемый характер, возможно указывать вероятность погашения.
lair
02.12.2015 23:16Что такое негенереализуемо?
Невыполнимо в общем случае.
С чего вы взяли?
С того, что он у вас не упомянут.
В качестве идентификатора используется id базы на сервере.
Теперь система еще и жестко завязана на сервер. Сочувствую.
То есть если перечень полей открытый, это неформализованная семантика?
Ну да. Пиши, что хочу.
Разумеется, в JSON это не нужно: нужно получателю, как раз для формализованной проверки. Если поля совпадут, но не совпадут форматы, поля будут считаться разными.
Вы про схемы данных не слышали никогда?
Все учетные системы базируются на правилах учета, о которых мне известно очень и очень хорошо.
Тем не менее, формат разработан для вашей. Дело же не только в правилах учета.
Поле-значение — обычная связка же.
Обычная связка — это «ключ-значение». И в JSON именно она и является полем.
она все равно взлетит, только под другим названием и будучи сделана профессиональным программистом, потому что идея бухгалтерской почты витает в воздухе.
… и это будет не ваша идея. В воздухе витает унифицированный обмен данными, еще со времен, когда про вашу эккаунтологию ни слова не было слышно. Вот только каждый раз он упирается в одну и ту же проблему схемы, и вы тоже не предлагаете путей ее решения. Почему вы считаете, что ваш подход — в котором, заметим, нет ничего, чего не было бы уже сказано раньше — имеет большие шансы на выигрыш, чем те, которые были до него?
Параметр 1 — данные об операции передачи,
Вот и нет там никакого идентификатора. И типов данных, кстати, тоже нет.
Параметр 1 имеет структуру Dictionary<string, string> (поле, значение),
Вот это и есть неформализованная семантика. Туда можно запихнуть что угодно, и валидность формата будет сохранена.
формат обеих дат: «dd-MM-yyyy HH':'mm':'ss».
Удачи в интеграции Владивостока с Калининградом.
Дата исполнения необходима для обозначения обязательств: если дата исполнения больше, чем дата регистрации, имеет место обязательство.
Это, заметим, единственное описанное в вашем формате бизнес-правило. И оно, внезапно, связано как раз с вашей гениальной идеей обязательств.
поскольку любое обязательство (дата его погашения) носит предполагаемый характер, возможно указывать вероятность погашения.
Вот вам типичный пример неформальности. Одна система будет указывать вероятность в процентах, другая — в долях, третья — в словесных оценках. Хотя всего этого можно было бы избежать одним простым правилом.mikejum
02.12.2015 23:55Угу, сильно, вот теперь отправили в нокаут.
Кое-что, типа вероятности, легко исправимо, другое уже посложней. Не понял относительно JSON, схем данных и валидности, что вы имеете в виду. Если есть string, понятно, что туда можно запихнуть что угодно, и не надо ссылаться на формализованную семантику, она валидности не поможет. Однако спорить не буду, это уже мелочи.
Как говорится, спасибо за конструктивную критику.
Единственное, чего не понимаю, почему программисты, такие все из себя профессиональные, столь беспомощны в методах учета. Это не в оправдание себя, а к слову. Я ведь приблизительно то же в такие моменты ощущаю, что и вы, вероятно, в настоящий момент. Никакого вам унифицированного обмена данными не будет, пока предметную область как следует не изучите, попомните мое слово.lair
03.12.2015 00:00Если есть string, понятно, что туда можно запихнуть что угодно
Вот поэтому везде, где может быть не стринг, должен быть не стринг.
Единственное, чего не понимаю, почему программисты, такие все из себя профессиональные, столь беспомощны в методах учета.
Во-первых, они не так беспомощны, как вы думаете. Во-вторых, ответ прост: нельзя быть профессионалом во всех областях сразу. Поэтому программисты работают в команде с аналитиками и специалистами в прикладной области.
Никакого вам унифицированного обмена данными не будет, пока предметную область как следует не изучите
А вы правда думаете, что схемы обмена данными программисты придумывают?mikejum
03.12.2015 00:13А вы правда думаете, что схемы обмена данными программисты придумывают?
А кто, инопланетяне?
И что, наконец, вы понимаете под схемами данных? Описания полей?lair
03.12.2015 00:16А кто, инопланетяне?
Забавно, вы правда считаете, что эта планета сплошь населена программистами? Я буквально строчкой выше описал типовой состав проектной команды (без учета QA, Ops и PM).
И что, наконец, вы понимаете под схемами данных?
Схема данных — это, действительно, развернутое описание структуры передаваемых данных. Схема обмена данными — это все то же самое, плюс протоколы и последовательности.
(естественно, это все сильно упрощая, там страницы fine print)
lair
02.12.2015 11:51Простой вопрос: через какой транспорт вы предлагает производить обмен? Как происходит адресация?
mikejum
02.12.2015 12:02Обмен уже производится, через хостинг, в котором я арендую место. Вроде как работает, в тестировочном режиме. Адресация происходит следующим образом: json от Отправителя отсылается по определенному адресу, на сервере происходит обработка, составляется временная база (записи хранятся до момента, пока не будет произведен полный обмен информацией). Затем, при подключении Получателя, данные переадресуются ему. В клиентской программе Получателя данные обрабатываются, ожидается ответ Получателя, после чего он (ответ) отправляется на сервер для уведомления Отправителя.
Серверная часть написана на Ruby on Rails, данный код писал не я — помогли.
Пока это делается через мой сервер, но, конечно, напрашивается использование многих серверов, по типу электронной почты. Добавить лишнее поле в стандарт несложно, был бы интерес.lair
02.12.2015 13:17Повторю вопрос: какой транспорт используется? Заодно вот еще спрошу: а как обеспечивается конфиденциальность и подлинность транзакций?
mikejum
02.12.2015 13:51Что вы имеете в виду под транспортом? Выполняется запрос определенного вида к серверу, возвращается html-страничка с данными. Подлинность транзакций обеспечиваются паролированием, на уровне клиентской программы и сервера. Из клиентской программы устанавливается соединение с сервером (Войти или Зарегистрироваться), данные отправляются с зашитым в них паролем, сервер проверяет пароль. Помимо этого, имеется еще пароль для входа в клиентскую программу. Я ответил на ваш вопрос или вы что-то более специальное имели в виду?
lair
02.12.2015 13:55Выполняется запрос определенного вида к серверу, возвращается html-страничка с данными.
Понятно.
Подлинность транзакций обеспечиваются паролированием, на уровне клиентской программы и сервера. Из клиентской программы устанавливается соединение с сервером (Войти или Зарегистрироваться), данные отправляются с зашитым в них паролем, сервер проверяет пароль. Помимо этого, имеется еще пароль для входа в клиентскую программу. Я ответил на ваш вопрос или вы что-то более специальное имели в виду?
Ох. Если вкратце, то описанная вами система никак не гарантирует ни конфиденциальности, ни подлинности проведенных транзакций. Ничто не мешает мне, как атакующему, врезаться в обмен между клиентом и сервером и сделать практически что угодно. И тем более ничего не мешает злонамеренному серверу делать с клиентскими данными что угодно.
И да, это не сугубо технологический вопрос — как только вы выходите за пределы одной системы, вопрос доверия становится методологическим. Особенно когда речь идет об имущественных транзакциях.mikejum
02.12.2015 14:18Особенно когда речь идет об имущественных транзакциях.
Вы не путайте имущественные транзакции с информационными, у меня ж не банковский счет.
Почему подлинности не гарантирует, если паролирование имеется? Конфиденциальность данных вроде бы от канала связи зависит, но тут я не спец, спрошу помощника, который серверную часть писал.
И тем более ничего не мешает злонамеренному серверу делать с клиентскими данными что угодно.
Вот тут я вообще не понимаю. Теоретически, любой сервер может сделать с пересылаемыми данными что угодно. Почтовые разве не так работают?
В любом случае определитесь с претензиями: если вы пеняете на слабую защищенность данных, то тут вы, скорей всего, правы. Правда, сильно сомневаюсь, что в другую систему нельзя вклиниться. Речь идет о том, чтобы пересылать данные, к примеру, от продавца к покупателю. Если уж контора захочет, то сможет получить данные непосредственно от продавца, зачем взламывать систему покупателя? Если же вы пеняете на методологическую непроработанность системы, то тут, являясь специалистом в области методологии, я категорически против. Моя система реализована в соответствии с лучшей на сегодня методологией. К сожалению, оценить ее новизну способны не все, вследствие ее неприменимости для ведения регламентированного учета (который давно уже ни в какие ворота не лезет).lair
02.12.2015 14:31Вы не путайте имущественные транзакции с информационными, у меня ж не банковский счет.
А какая разница? Информация об учете вещей иногда ценнее, чем сами вещи.
Почему подлинности не гарантирует, если паролирование имеется?
Потому что клиент (1) ничего не знает о пароле, который клиент (2) предъявил серверу. Это если в простоте. А если идти глубже, то пароль никак не защищает транзакцию, скажем, от изменения на лету, поэтому мы не знаем, пришла ли к нам транзакция с теми же данными, с которыми ее послал отправитель.
Конфиденциальность данных вроде бы от канала связи зависит,
Конфиденциальность зависит от канала связи в том случае, когда она не обеспечивается стандартом сообщения. У вас, похоже, не обеспечивается.
Теоретически, любой сервер может сделать с пересылаемыми данными что угодно
Если данные адекватно защищены, то нет, будет нарушена целостность. Если ставилась соответствующая задача, то он не сможет их даже прочитать.
Почтовые разве не так работают?
В рамках неконфиденциального обмена — так и работают. Именно поэтому есть больше одного варианта обеспечения конфиденциальности/подлинности почты поверх существующих небезопасных протоколов.
Правда, сильно сомневаюсь, что в другую систему нельзя вклиниться.
Зря сомневаетесь.
Если же вы пеняете на методологическую непроработанность системы, то тут, являясь специалистом в области методологии, я категорически против.
Я пеняю на то, что ваша методология, став из локальной распределенной, так и не обрела необходимые для распределенной системы качества. И это — методологическая ошибка.
Моя система реализована в соответствии с лучшей на сегодня методологией.
Еще раз: вы можете сколько угодно гордиться придуманной вами методологией учета, здесь моей компетенции недостаточно, чтобы как-то о ней судить. Но когда вы говорите о том, что вы предлагаете стандарт обмена данными между бухгалтерскими программами, вы выходите за границы вашей учетной методологии, и вступаете в совершенно другую область.mikejum
02.12.2015 15:24Здесь мне сложно вам возражать. Будем считать да, на сегодня защита данных не обеспечена надлежащим образом, ввиду недостаточной работы и профессионализма исполнителей.
Что касается стандарта, он ведь к защите данных отношения не имеет? Вполне себе рабочий стандарт. И тут я не выхожу за границы учетной методологии, а нахожусь в самой ее середочке.lair
02.12.2015 15:45Что касается стандарта, он ведь к защите данных отношения не имеет?
Имеет. Если стандарт заранее не предполагает решение проблемы хотя бы подлинности данных, в сегодняшних ИТ его можно считать мертвым.mikejum
02.12.2015 16:03Обеспечение подлинности данных — проблема техническая, сам стандарт — проблема методологическая. Я, в силу специализации, решал проблему методологическую. Но конечно, отсутствие приемлемого технического решения — моя вина, целиком и полностью сознаю и готов встать на путь исправления, если кто-нибудь мне такой путь предложит.
lair
02.12.2015 16:07Обеспечение подлинности данных — проблема техническая, сам стандарт — проблема методологическая.
Да нет же. В распредленной системе определение подлинности операции — это вопрос методологии, действующей в этой системе. То, что вы этого все еще не осознаете — следствие, простите за прямоту, вашей нехватки опыта в построении и проектировании таких систем.mikejum
02.12.2015 16:54Может, и так. А может, подобные упреки — следствие непонимание вами того, что такое учетная методология. Она не средство программирования или обеспечения конфиденциальности данных, а совсем другое. Самоценная дисциплина (или поддисциплина).
lair
02.12.2015 16:59Вот только в посте вы пишете не об учетной методологии, а о «стандарте обмена данными между бухгалтерскими программами». Ваша методология сама по себе мне не интересна.
mikejum
02.12.2015 17:32Хм. Пожалуй.
Остается только спросить: что же те, у кого такой большой опыт интеграции систем, не могут организовать корреляцию учетных баз, какую я предлагаю? Я вам отвечу: потому что они, с присущим программистам апломбом, пытаются с помощью наисовременнейших программных средств автоматизировать устаревшую методологию двойной записи и тот тихий ужас, который называется регламентацией бухгалтерского учета. Задача сама по себе недостижимая. Ровно до тех пор, пока методология бумажного учета не будет заменена на единую методологию компьютерного учета, в рамках которой можно будет вести произвольный и нерегламентированный учет чего бы то ни было.lair
02.12.2015 17:39что же те, у кого такой большой опыт интеграции систем, не могут организовать корреляцию учетных баз, какую я предлагаю?
А зачем им организовывать такую корреляцию, как вы предлагаете?
единую методологию компьютерного учета, в рамках которой можно будет вести произвольный и нерегламентированный учет чего бы то ни было.
«Единая… произвольный и нерегламентированный». Не взлетит. Причины описаны как раз выше.
(Нет, ну правда же. Люди годами составляют онтологии для систем интеграции — не бухгалтерских, поэтому все ваши выпады в сторону устаревших методологий бессмысленны, — а вы предлагаете просто взять, и заменить это парой «ключ-значение». Вы хотя бы про RDF слышали?)mikejum
02.12.2015 17:57А зачем им организовывать такую корреляцию, как вы предлагаете?
Затем, чтобы товар нельзя было закупить по-черному, у подставной организации. Но программистам это ни к чему, понятное дело, за это денег не заплатят.
(Нет, ну правда же. Люди годами составляют онтологии для систем интеграции — не бухгалтерских, поэтому все ваши выпады в сторону устаревших методологий бессмысленны, — а вы предлагаете просто взять, и заменить это парой «ключ-значение». Вы хотя бы про RDF слышали?)
Я тоже человек и тоже решал эту проблему годами, так что я один из этих людей, о которых вы говорите.
Про RDF не слышал, вот сейчас посмотрел. На первый взгляд, проблематика сходна с моей, которую я решал в изобретенной мной экаунтологии. В ней именно рассматриваются понятия объекта, субъекта и их свойств.Так что восклицать: «Ах, какой я глупый, не знал про RDF!», — извините, не намерен. Выработанного в экаунтологии категориального аппарата для решений учетных задач вполне хватает. А претензии по делу я принимаю — надеюсь, вы в этом убедились.lair
02.12.2015 18:00Затем, чтобы товар нельзя было закупить по-черному, у подставной организации.
А зачем эту проблему решать интеграторам?
(я уж не говорю о том, что то, что вы предлагаете в посте, эту проблему не решит, поскольку оно не налагает никаких регламентных ограничений, а без них эту проблему решить нельзя)
Я тоже человек и тоже решал эту проблему годами, так что я один из этих людей, о которых вы говорите.
Неа. У вас так и нет (и не планируется) введения фиксированной онтологии.
На первый взгляд, проблематика сходна с моей, которую я решал в изобретенной мной экаунтологии.
Посмотрите еще раз.
В ней именно рассматриваются понятия объекта, субъекта и их свойств.
Понятия объекта и его свойств рассматриваются в любой модели, связанной с объектами.
VenomBlood
03.12.2015 05:18Обращаю внимание: время, установленное на компьютерах отправителя и Получателя, должно быть синхронизировано
А теперь открываем учебник и видим что синхронизировать время невозможно, всегда будет небольшое расхождение, ну и конечно при попытке использовать описанное поделие для чего-то автоматического — обязательно эта проблема вылезет. Это безотносительно вопросов о том зачем вообще нужен этот велосипед, на это lair уже ответил.mikejum
03.12.2015 09:01Небольшое расхождение роли не играет, тем более что система позволяет вести учет в любой временнОй продолжительности, от секунд до лет.
По поводу велосипеда уже посыпаю голову пеплом. Единственное мне оправдание — то, что система единого всемирного учета не реализована, и перспективы ее туманны, особенно если глядеть с моей методологической колокольни.VenomBlood
03.12.2015 09:03«Небольшое расхождение» в вашем случае приведет к тому что все записи перемешаются, как только системой станет пользоваться больше 2х человек или как только ее будут использовать другие системы.
mikejum
03.12.2015 09:16-1Что значит перемешаются? Система распределенная, корреляция между клиентскими базами добровольная. В клиентской базе ничего перемешаться не может по определению, раз клиент вносит записи в свою базу после одобрения. Не понял суть претензии.
VenomBlood
03.12.2015 09:23Это значит что вам не нужно лезть в области в которой вы ничего не понимаете (вроде это вам несколько раз в каждом посте говорят). Если в вашей системе не гарантируется консистентность очередности сообщений и вообще нет какого либо механизма эту очерденость поддерживать — поздравляю, вашу систему можно поставить тете Маше и тете Клаше. Использовать ее в промышленности нельзя, уж тем более учитывая что проблемы могут возникнуть не просто финансовые — но и налоговые (в смысле неправильных отчетностей).
Кроме того похоже вы не понмаете даже сути термина «распределенный», если вас волнует только то что в клиентской базе все записано по мере поступления — это ни разу не распределенная система.mikejum
03.12.2015 09:50-1Понятно. На личные выпады мне сложно отвечать, так как я действительно мало что понимаю в программировании. Зато понимаю в бухгалтерии, в частности то, какой налоговый и финансовый маразм вы, технари, автоматизируете, сами того не замечая. А выправить предметную область мозгов не хватает, тут специалисты иного профиля нужны, да и кто им позволит? Ваша ссылка на неправильные отчетности иллюстрирует данное печальное положение наглядно. К слову, я изначально не собирался автоматизировать промышленность, в рамках законодательства это невозможно: система для теть Маш и Клаш предназначалась. Ну да Бог с ней, с системой, с ней полная ясность. Претензии весомы, я не уверен, что захочу исправлять ошибки (хотя исправление возможно, в принципе). Спасибо за теплый прием! Заглядывайте на огонек к нам, методологам, обещаю столь же дружескую встречу.
mayorovp
03.12.2015 14:01Проблема не в том, что вы мало что понимаете в программировании. Проблема в том, что вы при этом пытаетесь делать работу программиста.
Мне вот было бы интересно прочитать статью про методологию бухгалтерии. Но за описанием программы методологии, к сожалению, просто не видно.
А выправить предметную область мозгов не хватает, тут специалисты иного профиля нужны, да и кто им позволит?
Встречный вопрос: а кто вам не позволяет?mikejum
03.12.2015 14:42Проблема в том, что вы при этом пытаетесь делать работу программиста.
Это ж от безысходности. Я пару лет пытался найти людей, которые реализовали бы мои — методологические! — идеи, но где ж их взять, людей? После пары минут общения все понимают, что на этом не заработаешь, поэтому предпочитают автоматизировать то, что по своей сути антикомпьютерно, — современную бухгалтерию. Только по этой причине я сел за программирование.
Мне вот было бы интересно прочитать статью про методологию бухгалтерии.
Сейчас кину в ссылки на некоторые их моих работ по методологии в личку.
Встречный вопрос: а кто вам не позволяет?
Так и и пытаюсь, вот в этом самом посте, что-то изменить в лучшую сторону. Хотя попытка не самая удачная, признаться.lair
03.12.2015 14:47Так и и пытаюсь, вот в этом самом посте, что-то изменить в лучшую сторону.
Не, не пытаетесь. Вы не предлагаете ничего, что могло быть изменить ситуацию в лучшую сторону.
Klaster
Картинка про 15 конкурирующих стандартов.jpg то есть по факту если кто то из клиентов будет пользоваться а-маил мне надо будет писать загрузку из еще одного формата, вместо того что бы взять старый уже готовый и немного его подкрутить.
mikejum
Что-то я не слышал про конкурирующие стандарты. Были бы такие — имею в виду, не в рамках софта одного производителя, а общие, — данный стандарт был бы давно прикручен к пластиковым карточкам. Если указать в пластиковой карточке адрес учетной базы, данные о снятии-поступлении денег могут направляться непосредственно в базу. Разве есть такое? Это я так, в качестве примера.
lair
А ваш «стандарт» выходит за пределы «софта одного производителя»? Кто, кроме вас, его поддерживает?
mikejum
Никто, разумеется. Я ж методолог-одиночка, мне важна красота идеи, а предпринимательскими навыками «отжимать копеечку на голом месте» я не обладаю, даже если сильно захочу. Однако это не отменяет того факта, что предприниматели используют наработки исследователей навроде меня. Идея бухгалтерского почтового стандарта витает в воздухе, поэтому в скором времени кто-то на этом хорошо погреет руки. Но не я, разумеется, кто ж из софтверных производителей меня поддержит?
lair
Значит, он (ваш стандарт) ничем не отличается от всех остальных внутренних форматов обмена, которых есть у всех производителей соответствующего софта.
mikejum
Возможно, хотя не уверен. В моем формате имеются методологические особенности, например использование второй даты для регистрации обязательств. Однако это не программистский вопрос: чтобы понять, о чем идет речь, нужно обладать недюжинной квалификацией в области методологии учета, каковой программисты не обладают в силу другой специализации (это не в обиду: точно так же учетчики никогда не смогут понять сложную программную закавыку). В любом случае в качестве всеобщего формата (такого, чтобы можно было коррелировать между собой любые учетные базы данных) ни один из форматов де-факто не принят.
lair
… и эта методология пропиетарна для вашей системы. И именно поэтому ваш формат тоже не будет принят в качестве всеобщего.
mikejum
О, не сомневаюсь! Мне достаточно того, что данная методология могла бы быть принята. Как я уже написал в одном из комментариев, я не обладаю умением выбивать под свои идеи гранты и привлекать жаждущих быстро и гарантированно наварить «легкого бабла». Мне было интересно проверить, может ли моя метода быть претворена на практике. Убедился: может. К каким впечатляющим последствиям это ведет, мне известно. Остальное не в моих силах, увы.
lair
Внутри одной вашей системы — да. Но вы-то пишете о применимости к другим бухгалтерским программам; а это вы на практике проверяли?
mikejum
Я не могу это проверить для продуктов сторонних производителей. Если кто-то пожелает проверить, проверит. И убедится, что такое вполне возможно. Я в этом не сомневаюсь, ведь задача элементарна: обменяться данными о вещах, переданных в рамках одной хозяйственной операции.
lair
Значит, вы не убедились в возможности того, что описано в посте.
Возможно практически все. Вопрос стоимости.
Эта задача выглядит элементарной, но таковой не является. Банальный, казалось бы, вопрос: как определить передаваемые «вещи»?
mikejum
Тут вы влезаете в мою область.
Поясняю: система реализована на основании экаунтологии — дисциплины, которую я изобрел для решения учетных задач. Согласно экаунтологии, объектом учета могут быть только вещи. Определить вещь чрезвычайно просто: это объекты реального мира, доступные в наших ощущениях. Все, что вы можете потрогать — это вещь, все остальное — не вещи.
Бухгалтерская методология основана на ином: помимо вещей, она учитывает в качестве объектов учета абстрактные понятия. Однако и в этом случае объект учета гарантированно имеется: это то, что учитывается на счете бухгалтерского учета. Учитывать в моей системе можно и абстракции, хотя это будет некорректно. (При этом оговорюсь, что обязательства и доходы-расходы определяются в моей системе на ином смысловом уровне, то есть они соответственно учитываются и рассчитываются).
Надеюсь, я ответил на ваш вопрос.
lair
Нет, вы не ответили на мой вопрос.
Вот вы учитываете земельные участки (я надеюсь, они вещи?). Вам надо зарегистрировать передачу земельного участка из ведения одной организации в ведение другой организации. Внимание, вопрос: как одной организации однозначно объяснить другой, какой земельный участок передается?
(не нравятся земельные участки — примените то же самое к самолетам)
mikejum
Честно говоря, не понимаю, каким образом вы пытаетесь поддеть меня.
Да, земельные участки — вещи. Информация о них передается в точно таком же порядке, как и об остальных вещах: вещи может быть присвоен идентификатор (например, № в регистрирующем органе) либо вещь может быть идентифицирована по своему названию. Когда вы покупаете в магазине пакет молока, вы же не потребуете его уникальный номер? Он просто не нужен (хотя в контексте идеи всемирного учета желателен). Пакет молока будет идентифицирован названием, также другими характеристиками: маркой, сортом, производителем, датой производства и т.п.
lair
Я не пытаюсь вас поддеть, я пытаюсь указать вам на проблемы.
У земельных участков нет названий. Идентификатор… это прекрасно, но предположим, что отдающая организация не использует ГКН для идентификации земельных участков, а принимающая — использует. Что в этом случае делать?
Более того, есть и более интересный вопрос: как отразить тот факт, что одна организация использует в качестве стоимости земельных участков кадастровую стоимость, а другая — оценочную?
mikejum
А, некоторое знакомство с учетной проблематикой у вас имеется, это хорошо! Однако мне данная проблематика тоже знакома не понаслышке, указывать на нее не нужно, это моя специальность. Объясняю.
Учитывать без идентификатора нельзя, просто не получится. В любой компьютерной системе идентификаторы используются как ID записей, не мне вам такое говорить. Однако имеется еще идентификация для пользователя. Традиционно для этих целей использовался счет бухгалтерского учета (попросту, обиходное название вещи). Когда выяснилось, что этого недостаточно, стали использоваться множественные идентификатор в виде субсчетов и аналитических признаков. Но название, в качестве обязательного реквизита, осталось. Оно и является пользовательским идентификатором. Продавец может указать: земельный участок по адресу такому-то. Это название и послужит идентификатором. Обращаю ваше внимание, что в моей системе корреляция не является обязательной: получатель может переименовать участок по собственному усмотрению, ему не возбраняется.
Аналогичным образом решается вопрос со стоимостью. Моя система позволяет учитывать вещи по множеству числовых признаков, поэтому получатель оприходует полученный участок как пожелает: по оценочной стоимости и(или) по кадастровой и(или) по любой другой. Если данная стоимость указана в данных отправителя, вбивать ее в базу не будет необходимости; если же данные отсутствуют, разумеется, реквизит придется вбить.
Замечу, что систем, позволяющих вести мультивалютный учет, уже тучи, насколько я понимаю. Это только традиционная бухгалтерия велит: или оценочная стоимость, или кадастровая.
lair
Вы про искусственные идентификаторы сейчас говорите? Они нас не интересуют, их вы между системами никогда не скоррелируете.
Ну то есть вы навязываете всем системам обязательную идентификацию по наименованию?
Вы не поняли. Вот у вас есть атрибут Cost (я беру название из поста). Одна система хранит в нем кадастровую стоимость, другая — оценочную. Это, очевидно, приведет к проблеме при передаче информации.
mikejum
Нет, обязательная идентификация по наименованию отсутствует. При этом поле «Название» должно быть заполнено в обязательном порядке (не может быть пустым).
Да, ваш пример с Cost корректен. В этом случае действительно появятся разночтения. Необходимо знать, что учитывает в поле Cost отправитель: если что-то другое, значение придется скорректировать на правильную величину. Другого варианта нет, по-моему.
lair
Так как же принимающей организации, которая не учитывает земельные участки без кадастровых номеров, принять на учет земельный участок, пришедший от организации, которая не ведет кадастровые номера для своих земельных участков?
Угу. Причем решить эту проблему автоматически невозможно.
mikejum
В общем порядке. Вместо названия, где указан кадастровый номер, можно вписать любое другое, хоть бы адрес.
Я ее и не решаю, по указанной причине. Для этого и сообщил о необходимости составить список общеупотребительных полей.
lair
Не, не взлетит. Название земельного участка — это его название («земельный участок, предназначенный для блаблабла»), причем в каждой организации оно свое. При этом адрес — это адрес, он не совпадает с названием. А кадастровый номер, очевидно — еще более отдельная вещь. Нельзя решить одним строковым полем все проблемы, пробовали.
Вам мало составить список, необходимо еще жестко регламентировать правила заполнения этих полей. И вот на этой фазе (которая называется «формализация схемы») вы и завязнете если не навсегда, то очень надолго.
(Собственно, вот и картинка про конкурирующие стандарты)
И что характерно, ничего нового кроме схемы, в вашем «стандарте» нет.
mikejum
Чем же это более отдельная? Обычный реквизит. Я не собираюсь составлять схему реквизитов (по-бухгалтерски, составлять План счетов) для каждого из предприятий. Если кто-то не может, это его проблемы, не мои. Собственно, ничего другого, кроме реквизитов, описывающих вещь, все равно не придумать: один реквизит, два реквизита для этого используется или более — не суть важно.
Да, если кто-то захочет намеренно перепутать характеристики объектов, вполне преуспеет. Но зачем?
Конечно, нет. Как в схеме принципиально нового мотора нет ничего, кроме схемы мотора. Что характерно.
lair
Как раз тем, что отдельный реквизит с требованиями по уникальности (я даже не буду заикаться про валидацию).
Вот, собственно, и объяснение того, почему это провалится.
Вы не поняли: как раз схема-то в вашем стандарте не описана (цитирую: «необходимости составить список общеупотребительных полей»). А без этой схемы стандарт не имеет смысла (потому что больше ничего полезного он не привносит; я могу продолжать задавать вопросы по тем местам, где в стандарте дыры, но не вижу особого смысла, он не этим интересен).
mikejum
Извините, но в любом Плане счетов указан стандартный набор реквизитов, по которым следует учитывать вещи. Данные перечни зачастую некорректны, но в целом они покрывают потребности на 90%. А обо всем покрытии речи не идет.
Снова не понял. Ну, уникальный реквизит. У отправителя уникальный, а получатель как захочет учитывать вещь, так и станет. В чем проблема именно для кадастрового номера?
lair
Ничего не знаю про «любой план счетов», равно и как про его применимость для конкретных учетных задач. Ваш стандарт-то тут при чем?
Проблема (не кадастрового номера, а ситуации) в том, что получателю нужна информация, которую отправитель не передает. И как вы предлагаете это обрабатывать?
mikejum
Над вопросом классификации вещей, т.е. определения необходимых для ведения учета признаков, люди задумывались с момента зарождения учета. В настоящее время обязательные для учета реквизиты указаны в Плане счетов (хотя указаны хаотично, неполно и противоречиво).
Смеетесь? А если получателю нужна информация о Проксиме Центавра, а пользователь ее не передает, тогда как? Если же вы спрашиваете о дополнении получаемых данных, никто не мешает получателю внести их в свою базу данных. Получатель учитывает по полю <Марка>, а у отправителя такой информации нет. Придется вносить информацию при получении a-Mail, а как иначе? Но информацию, находящуюся на пересечении учетных систем, править не придется, в этом облегчение труда. Разве нет?
lair
Какое отношение это имеет к вашему стандарту?
Прекрасно, откуда он ее возьмет?
Вопрос размера этого пересечения (не формального, а семантического) и его отношения к общему размеру учитываемых реквизитов.
mikejum
Вы же мне инкриминировали отсутствие списка реквизитов. Вот я и ответил: такие списки люди на протяжении веков составляют, они не секрет Полишинеля. При чем здесь мой стандарт, в самом деле?
Это общий вопрос к учету, а не к моему стандарту. Используются лишь те реквизиты, в которых есть необходимость (при получении выходной информации). Требовать от отправителя информации, у него отсутствующей, — нонсенс.
Полагаю, более 50%. Но доказать без практического внедрения не могу, как, впрочем, и вы обратного.
lair
То есть в вашем стандарте списка реквизитов нет и не будет, правильно я вас понял?
А что вообще вопрос к вашему стандарту? Иначе говоря: что именно ваш стандарт формализует?
mikejum
Составить рекомендуемый список реквизитов я могу за день. Но он будет именно что рекомендуемым.
Мой стандарт формализует набор параметров, необходимых для корреляции учетных баз при передаче вещи от одного пользователя к другому. Часть параметров представляет собой жестко закрепленные реквизиты (например, логин пользователя), другая часть — список используемых пользователями произвольных реквизитов. Для списка указана только структура (поле-значение), пара полей является обязательными. Все.
lair
А конкретно?
И в чем тогда смысл такого стандарта? Что нового он приносит в существующие практики обмена? Какие конкретные существующие проблемы он решает?
mikejum
Параметры, в принципе, известны. Я предложил вариант формализации: для операции — две даты плюс комментарий, для объектов — название свойства плюс значение. Это не считая служебных и вспомогательных полей.
В практики обмена — ничего. Если, конечно, не считать вторую дату, при помощи которой определяются обязательства. Сомневаюсь, что аналог отыщется. Во всех других системах обязательства — особый род объектов, требующих специальной идентификации.
В первую очередь ту, которая не решена до сих пор, — корреляцию учетных баз данных. У меня корреляция добровольная, но должна быть принудительной, конечно. После исполнения сделки пользователи должны не иметь возможности править свои базы, во всяком случае в пересекающихся реквизитах.
Я могу попросить магазин прислать мне, в мою личную учетную базу, сведения о купленном товаре, хоть в каком-то формате? Нет? Ну и где ваши опытные интеграторы, занимаются тем, что, заработков ради, автоматизируют глупейшую бумажную методологию?
lair
Даже идентификатора нет, как это прекрасно.
Они определены стандартом?
Мы уже выяснили, что эта дата специфична для вашей методологии, к обмену она отношения не имеет.
Это не формализация, это вид записи. Ничего формального в нем нет, он определен нижележащих форматом (простите) передачи данных.
Почему не решена? Есть учетные системы, поддерживающие синхронизацию различных экземпляров системы, причем иногда даже в полностью автоматическом режиме.
Да, можете.
Занимаются тем, что им интересно и/или выгодно. Вас это удивляет?
mikejum
Идентификаторы есть, естественно. А что, нужно было указать. как называется поле во время пересылки? Захотите интегрироваться, скажу.
Да, служебные и вспомогательные поля определены стандартом.
Имеет в смысле «конвертации» данных: сведения об обязательствах приходится пересылать всем, кто этим занимается. У меня предложен иной способ пересылки.
Вы правы. Единственно новаторство в том, чтобы использовать пересекающиеся значения.
Ну и где общие стандарты для многих систем, а не для софта одного производителя?
Хе. Попрошу в «Перекрестке».
Нет, не удивляет. Я сам такой.
lair
Но вы про них не упоминаете.
Нет, нужно указать состав полей.
То, что ваш стандарт еще и закрытый, не делает ему чести. И резко уменьшает шансы на внедрение.
… который все равно обозначает, что вторая сторона как-то конвертирует свои данные — в ваши, и наоборот. То, по какому признаку обязательство отличается от не-обязательства — технический вопрос второго, что ли, порядка малости, на фоне всего остального.
Вы это серьезно? Любая интеграция использует пересекающееся между системами множество значений.
Поищите, если интересно. Я для бухгалтерской отрасли не нашел, видимо, никому не надо. В других отраслях — есть.
Замечу, впрочем, что ваш стандарт в этой части ничем не отличается.
mikejum
Состав полей приблизительно указан, в посте.
Да уж, сглупил.
Сложно отрицать.
Если не нашли, от чего тогда он не отличается?
lair
«Приблизительно» — это не стандарт.
Значит, никакого новаторства нет и в помине.
От существующих стандартов для софта одного производителя. Ваш тоже — для софта одного производителя.
mikejum
Никакого новаторства в данном узком аспекте.
Поскольку предметная область одна, любой стандарт может быть использован в качестве общего. Теоретически, конечно.
lair
А в каком есть? (напоминаю, речь идет о предлагаемом вами стандарте)
Вот именно, что любой. Видимо, картинка все-таки нужна.
mikejum
В методологии точно есть (увы, это не ваша область, поэтому доказательства опущу). Наверное, вы правы, никакого новаторства в стандарте нет. Но разве я упоминал о новаторстве? Да, разработал стандарт для своей системы, предложил в качестве всеобщего, Это большой криминал, особенно для методолога в области учета? Ну раз они такие все одинаковые, что друг от друга не отличаются.
Картинку эту я уже видел, спасибо.
lair
Предложить — не криминал. Не понимать, почему это предложение обречено — уже ближе к криминалу.
mikejum
Я могу по крайней мере десяток причин назвать, из-за которых мое предложение обречено. Однако мне интересно этим заниматься, кто запретит? Понятное дело, что, будучи методологом, я многого не вижу. Так ведь и вы, не будучи методологом, тоже много не видите из того, что отчетливо наблюдаю я.
lair
Никто. Занимайтесь, сколько угодно.
mikejum
К слову, о новаторстве. Не уверен, что прочие стандарты предусматривают отказ от принятия вещи с последующим «восстановлением» ее в первоначальной базе. Впрочем, не знаю, насколько данная возможность относится непосредственно к протоколу.
lair
А это входит в описанный вами стандарт, или это исключительно функциональность сопрягаемых систем? Иначе говоря, если система, которую вы интегрируете, построена не по вашей методологии, в ней это обязано быть?
mikejum
Нет, не обязано. Но возможность передать отказ в принятии вещи имеется. Это у получателя. Соответственно, у отправителя имеется возможность, получив отказ, оформить откат вещи назад как непринятой.
lair
Значит, это не предусмотрено в вашем стандарте.
А так, по большому счету, это обычная распределенная транзакция (и вас ждет еще много веселого в том, что именно может произойти внутри).
mikejum
Возражений нет.
Klaster
У 1С как обычно на все есть свой стандарт для этих целей, другое дело, что им никто не пользуется кроме нее http://v8.1c.ru/edi/edi_stnd/90/92.htm
lair
Смешно, кстати, что CommerceML — не только 1С-овский стандарт, там аж прямо MS и Intel вписались… но не взлетело, да.
А так — да, типичный пример.
Klaster
Ничто не может сразу направляться в базу. В мою базу. По крайней мере само собой. Должен быть код который обработает входящий поток данных и потом либо пользователь либо автомат эти данные импортирует. По правилам которые напишет программист. То есть отработает код который напишет программист. Этот код может обработать данные с электронной почты, ftp или еще откуда то, они могут быть в xml тексте, экселе или даже в ворде. Код отработает и если нужно подтверждение ответ уйдет. Зачем нужен ваш протокол? Если код писать придется в любом случае в полном объеме(не библиотек не исходных кодов, я не заметил, плохо смотрел?)
mikejum
Верно говорите. Можно было в любой формат запихнуть, в принципе. И код придется писать в полном объеме, для каждого софта по отдельности, по другому никак.
Была мысль сделать считывание из файла, но пока не реализовал. Замечу, протокол при этом все равно необходим: тот или другой.
Klaster
Вы смешиваете протокол: чисто техническая часть:
«Клиент и сервер обмениваются заголовками содержащими… В случае если клиент… сервер считает...» и тд. То есть информацию как байты от клиента А должны в целости и сохранности добраться до клиента Б, с непосредственно методической частью, как клиент должен поступить с этой поступившей информацией. Первая часть на плечи которой ложится непосредственно транспорт решена и не один раз. Начиная от протокола обмена заканчивая форматом самого сообщения. Вторую часть вы предлагает писать в каждой системе заново(с учетом того, что там уже что то написано, системы работают и какие то соглашения достигнуты). Я не вижу куда здесь можно вставить ваш протокол.
mikejum
Возможно, я недопонимаю, специализация у меня иная, вестимо. Однако, формализовать список полей для передачи нужно же в любом случае… Мой протокол или другой протокол, но эти данные должны соответствовать определенному стандарту, чтобы получатель мог их считать и правильно интерпретировать.
Klaster
>>Однако, формализовать список полей для передачи нужно же в любом случае
Это называется разработка протокола? Какие поля будут в сообщении?
Ну вот вам готовый всеобъемлющий стандарт ссылку на который я давал выше, полностью документированный открытый предназначенный для обмена между учетными системами, пройдите по ссылкам в начале статьи и получите полное и детальное описание без всяких «напишите мне в личку».
http://v8.1c.ru/edi/edi_stnd/90/92.htm
mikejum
Посмотрел, спасибо.
Без комментариев.
Да, поля, пожалуй, мне следовало указать все. Правда, без адресов для запросов они особого смысла не имеют, по крайней мере в рамках моей системы. Тем более что главные поля названы: адреса отправителя и получателя, даты и комментарий для операции, список свойств для объектов. Принципиальным является только введение второй даты, остальное — само собой разумеющееся.