Skip to content

Поддержка Клиентов:

(044)585-97-12


Новый формат электронных документов *.xmmo

Logo_xmmoИнформационные технологии не перестают развиваться, на смену старым форматам приходят новые. Так случилось с известным форматом электронных накладных *.mmo. Многие участники рынка (производители, оптовые поставщики, аптеки) столкнулись с проблемой, когда возникает необходимость передавать в электронных накладных больше информации, чем это заложено форматом. Такие необходимые на сегодняшний день атрибуты как коды УКТВЭД, принадлежность к ЦРГ, акционность товара и многие другие не могут передаваться в формате *.mmo из-за его ограничений и невозможности гибкого расширения. Исходя из этого был разработан новый формат *.xmmo на основе XML, который является более гибким и расширяемым.

Описание формата *.xmmo

Расширение файла: xmmo

Классификация файла: XML

Кодировка xml-файла: windows-1251, utf-8

Формат даты: YYYY.MM.DD HH:MM:SS

Формат чисел: разделитель «.»

Если реквизит пустой или равен «0» — выводить необязательно

Идентификаторы, помеченные как «*» являются обязательными

Структура файла

— комментарий, указывающий на тип файла (xml)

— тег-контейнер, для электронных документов

Version=»1″ DivType=» Простые «> — тег-контейнер документа

Доступные параметры

Параметр

Описание

Тип данных

1 *DocType Тип документа: «РасходнаяНакладная», «Прейскурант», «Заказ», «Потребность» char
2 *Version Версия документа sbyte
3 *DivType Тип распаковки для дробного прихода (в десятичных или простых дробях): «Десятичные», «Простые». char

 

— тег-контейнер шапки документа. Может содержать следующие теги:

Тег

Описание

Тип данных

1 UID Уникальный идентификатор документа char
2 *DocDate Дата документа date
3 *DocNum Номер документа char
4 UserNote Комментарий char
5 LocationID Идентификатор точки доставки (дислокации) long
6 LocationName Название точки доставки (дислокации) char
7 LocationAdr Адрес точки доставки char
8 *DocSum Сумма документа (без НДС) float
9 *DocSumVat Сумма НДС документа (если документ без НДС, то «0») float
10 DocNalogNum Номер налоговой накладной int
11 DocNalogDate Дата налоговой накладной date
12 PayID Идентификатор вида оплаты. Актуально, если по контрагенту есть несколько соглашений char
13 PayName Наименование вида оплаты char
14 PayDate Дата оплаты date
15 OrderNum Номер заказа (если несколько — через разделитель «;») char
16 *SellerName Наименование поставщика char
17 *SellerERGPOU Код ЕГРПОУ поставщика int
18 *ClientName Наименование покупателя char
19 *ClientERGPOU Код ЕГРПОУ покупателя (плательщика) int
20 Contract Номер договора char
21 Reg Накладная подлежит регистрации (1 – подлежит, 0 – не подлежит) int

закрытие шапки документа

— тег-контейнер, тела  документа

тег-контейнер, содержания документа. В содержании документа в тегах описываются позиции документа.

Доступные параметры тега <i>

Параметр

Описание

Тип данных

1 *SellerID Идентификатор товара (код поставщика) char
2 MorionID Код Мориона int
3 *DrugName Наименование товара char
3 DrugNameUkr Наименование товара на украинском char
4 *DrugVat Процент НДС sbyte
5 OwnerName Название владельца лицензии char
6 OwnerID Идентификатор владельца лицензии char
7 *MakerName Название производителя char
8 MakerID Идентификатор производителя char
9 ItemRegNum Номер регистрации товара char
10 ItemRegStart Дата регистрации товара date
11 ItemRegEnd Срок регистрации товара date
12 ItemExtID Идентификатор товара во внешней БД (например: ГосНоменклатура или др.) char
13 Barcode Заводской штрих-код char
14 HsCode Украинский классификатор товара ВЭД char
15 Divisor Распаковка int
16 Ord333 Принадлежность к ЦРГ (1 – принадлежит к ЦРГ,  0 – не принадлежит ) sbyte
17 Promotion Акционный товар (1 – товар акционный, 0 – не акционный) sbyte
18 PartID Идентификатор партии char
19 SeriesID Идентификатор серии char
20 *SeriesName Представление серии char
21 SerisesStart Дата производства date
22 *SerisesEnd Срок годности date
23 CertificateNum Номер сертификата char
24 CertificateDate Дата сертификата date
25 CertificateURL Адрес zip-архива c картинками сертификата char
26 OrderMarker Маркер заказа (поставщик получает маркер в заказе от аптеки и передает его в накладной) char
27 *Unit Единица измерения (Строка) char
28 *Quant Количество float
29 QuantNum Дробное количество – числитель (при простых дробях) int
30 QuantDiv Дробное количество – знаменатель (при простых дробях) int
31r/td> *PriceFactory Цена таможенная или заводская float
32 *Price Цена без НДС float
33 *PriceVat Цена НДС float
34 *Sum Сумма без НДС float
35 *SumVat Сумма НДС float

закрытие содержания

— закрытие тела документа

— закрытие документа

— закрытие контейнера электронных документов

Описание в формате *.doc

Примеры документов в формате *.xmmo

Скачать пример приходной накладной в формате *.xmmo

Работа над расширением формата

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


  1. Александр says

    А почему в качестве формата выбран XML? Уверен, для этой задачи он слишком громоздкий. Учитывая современные тенденции в веб-технологиях, советую обратить внимание на JSON. Он стандартизирован, намного компактнее и проще, чем XML.

    Еще несколько технических замечаний:
    1) Кодировка windows-1251, utf-8 — если уж разрабатывать стандарт, лучше оставить только одну, UTF-8
    2) В формате даты отсутствует временная зона (Time Zone), которая очень пригодится в будущем. Настоятельно рекомендую ознакомится с форматами даты и времени, принятыми организацией ISO

  2. slayer says

    Формат XML выбран благодаря его распространенности. Бесспорно JSON перспективен, но для организации документооборота «Оптовый поставщик — Аптека» он может стать серьезной помехой. У многих поставщиков реализован экспорт документов в XML, в случае с форматом XMMO необходимо только реализовать соответствующую структуру файла. В случае с учетными системами в аптеках — у многих есть XML парсеры для различных нужд и «научить» учетную систему читать XMMO не так сложно, как в случае с JSON.

    Что касается кодировки — windows-1251 и utf-8 наиболее часто встречаются в учетных системах.

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

  3. Антон says

    Полностью поддерживаю комментарий Александра. JSON предпочтительнее и более распространен в Вэб. XML избыточен, трудночитаем.
    Предлагаю разработчикам из Морион не навязывать свой стандарт, иначе это получается монополизация или просто нежелание переделывать свою систему, которая жестко завязана на XML ;). Делайте свой xmmo, а другие пусть делают на базе json, а время покажет что лучше, а что «умрет».
    Для нормального разработчика не проблема реализовать импорт/экпорт из/в XML/JSON. Поэтому не надо списывать на то, что у многих видите ли реализован экспорт куда-то.
    Что касается кодировки, то должен быть только UTF-8, а про windows-1251 надо забыть.
    Или продолжайте «клепать» софт 90-х годов…
    Успехов…