Pull to refresh

А вы получили a-Mail?.. Бухгалтерская почта

Reading time 8 min
Views 5.5K


В соответствии с замыслом, 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, что и пересылка объекта. Только направление движения информации происходит в обратном порядке: от Получателя к Отправителю.

Таким образом, имеется четыре типа обращения сервера к клиенту, при которых происходит обмен информацией в ту или другую сторону.



  1. Передача данных от Отправителя на сервер.
  2. Их пересылка Получателю.
  3. Передача на сервер согласия или отказа Получателя принять данные.
  4. Сообщение об отказе или согласии Отправителю.


Остается посмотреть, как a-Mail реализован в интерфейсе «Учетной Логики».

1. Сначала необходимо зарегистрироваться в системе – получить a-Mail адрес.



2. После регистрации нужно добавить, то есть учесть, какую-нибудь вещь. Пока в системе не учтено ни одной вещи, нечего передавать контрагенту.

3. После того, как вещь появилась, ее можно кому-нибудь передать. В принципе, передавать можно самому себе (для этого придется зарегистрироваться под вторым логином), но лучше договориться с товарищем.

Для передачи необходимо выбрать пункт меню «Операции/Передать вещи…», затем в открывшемся диалоговом окне указать a-Mail Получателя.



Первая часть a-Mail – логин (под которым пользователь регистрируется), вторая часть – сублогин (название пользовательской базы – в начальном окошке «Войти под именем»). Ок, и a-Mail ушло.

4. Мысленно переносимся в базу Получателя.

Пункт меню «Операции/Получить вещи…». В открывшемся диалоговом окне Получатель увидит принятый a-Mail. Можно отказаться от принятия или согласиться. Во втором случае в пользовательскую базу будут добавлены данные о поступившем объекте.



Обращаю внимание: время, установленное на компьютерах отправителя и Получателя, должно быть синхронизировано, в противном случае возможны неожиданности. К примеру, если на компьютере Отправителя время установлено с 5-минутным опозданием, то Получатель увидит поступление через 5 минут – в момент, указанный в качестве даты выполнения действия (для чего потребуется перезагрузить рабочую область, приблизительно так, как это осуществляется в браузере). Так происходит вследствие того, что «Учетная Логика» отображает вещи, зарегистрированные на момент, указанный на таймере. Если передать вещи будущим моментом, Получатель увидит их не раньше указанного срока.

Настоящий стандарт разрабатывался для «Учетной Логики», однако он применим к прочим бухгалтерским программам, ведь суть передачи вещей от Отправителя к Получателю всегда идентична. Совершенно понятно, что – при наличии учета с обеих сторон – информация должна записываться единовременно в обеих базах (либо в одной общей), коррелируя между собой. Вы же не полагаете иначе?

Если найдутся желающие вставить a-Mail модуль в готовый бухгалтерский софт, обращайтесь в личку, авторы проекта сделают все от них зависящее, чтобы мероприятие состоялось. Цель: обмен данными между бухгалтерскими программами разных производителей.

Скачать «Учетную Логику» 3.0 WWW можно по этой ссылке.

Системные требования
Необходимы 32-разрядные Microsoft Office и Windows. При 64-разрядной Windows требуется установить утилиту Microsoft Access Database Engine 2010 (32-разрядную).

В настоящий момент бухгалтерская почта проходит тестирование. От того, какой интерес будет проявлен к a-Mail со стороны сведущей публики, зависит будущее проекта.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+5
Comments 145
Comments Comments 145

Articles