Рекомендації щодо впровадження обміну GS1 XML

Уся подана інформація має суто рекомендаційний характер та не є обов’язковою до застосування.

Назви ключів в прикладах тако можна змінювати довільно, якщо вони не закріплені стандартом.

Одне повідомлення - один документ

Згідно зі стандартом кожне повідомлення може містити один та більше документів. Наприклад, щоб не слати 10 замовлень окремими документами, відправник може надіслати всього одне повідомлення, в якому буде міститися 10 замовлень.

В певних випадках це може спрощувати роботу сторонам.

Однак, якщо під час обміну документами сторони домовилися контролювати статуси повідомлень, то в такому разі рекомендується використовувати підхід Одне повідомлення - один документ. Це дуже спрощує контроль за статусами повідомлень.

Додавання нестандартних даних

Формат GS1 XML дозволяє додати нестандартну інформацію майже до будь-якого елемента у повідомленні.

Наприклад, може виникнути потреба передавати якесь додаткове кодування для товара, номер ліцензій чи сертифікатів для товара, додаткові відомості про бонуси, коди алкогольної продукції, дати випуску для МРЦ на цигарках тощо. Будь-що можна додати в повідомлення не порушуючи його структуру.

В таких випадках потрібно скористатися елементом <avpList/>, який повинен міститися у відповідному елементі повідомлення, куди треба додати нестандартну інформацію.

Наприклад, таким чином до товара можна додати УКТЗЕД

<avpList>
    <eComStringAttributeValuePairList attributeName="UKTZED">
        2203 00 01 00
    </eComStringAttributeValuePairList>
</avpList>

Унікальний ідентифікатор документа

В облікових системах нумерація документів може бути циклічною: повторюватися щомісяця або щороку. В такому випадку можуть виникнути непорозуміння, коли документ відповіді на замовлення посилається на документ замовлення використовуючи його ідентифікатор в елементі originalOrder, або ж в ситуації, коли отримувач використовує цей ідентифікатор як прив’язку отриманих документів до документів у своїй обліковій системі.

В цій ситуації доведеться використовувати додаткову логіку при пошуку оригінального документа в обліковій системі, оскільки документів з номером, наприклад, ЗМ-00001 може бути декілька штук.

Для вирішення цієї ситуації рекомендується в кожному документі використовувати елемент avpList з вказанням унікального ідентифікатора цього документа. Наприклад, для 1С це може бути guid документа.

  • SELLER_DOCUMENT_ID - значення атрибуту для документів, які надсилаються постачальником

  • BUYER_DOCUMENT_ID - значення атрибуту для документів, які надсилаються покупцем

Рекомендуємо використовувати саме ID, а не GUID, оскільки в обліковій системі ідентифікувати документ можна не тільки через guid. Наприклад, може використовуватися штучний ID який складається з року документа та його реального номера: 2023_ЗМ-00001 - в цьому разі GUID було б помилковим визначенням.

Документи від постачальника
<avpList>
    <eComStringAttributeValuePairList attributeName="SELLER_DOCUMENT_ID">
        b50bfaa0-136a-4822-9904-83f8050a096d
    </eComStringAttributeValuePairList>
</avpList>
Документи від покупця
<avpList>
    <eComStringAttributeValuePairList attributeName="BUYER_DOCUMENT_ID">
        d06eae0c-2934-49b2-a024-4570b3ee8b9e
    </eComStringAttributeValuePairList>
</avpList>

Форма оплати

Інколи в документах потрібно відобразити форму оплати: перша чи друга.

В такому разі документі можна використовувати елемент avpList, де зазначити форму оплати. Наприклад, назва для визначення форми може бути PAYFORM_CODE, а значеннями будуть F1 та F2.

Документи з другою формою оплати
<avpList>
    <eComStringAttributeValuePairList attributeName="PAYFORM_CODE">
        F2
    </eComStringAttributeValuePairList>
</avpList>

Звісно, що значень форм оплат може бути більше - все залежить від погоджень між відправником та отримувачем.

Відповідь на замовлення без замовлення

Інколи замовлення для постачальника збирають торгові агенти, що позбавляє покупця необхідності створювати електронне замовлення в системі Edibox.

В такому випадку у відповіді на замовлення постачальник не має документу-підстави від покупця. Як наслідок, постачальник не має інформації для заповнення обов’язкового елементу <originalOrder> номером вхідного замовлення.

У такому випадку рекомендується у цьому елементі вказувати дефіс "-".

Відсутнє вхідне замовлення
<originalOrder>-</originalOrder>

Попередньо цей варіант взаємодії постачальник та покупець повинні узгодити між собою.

Дані про товар

В документах GS1 товар ідентифікується через елементи з типом TransactionalTradeItemType. Цей тип дозволя вказати назву, штрихкоди, опис, вагу, розміри та будь-які додаткові відомості товару - жоден з елементів не є обов’язковим.

Приклад опису товара з додатковими даними про вагу
<transactionalTradeItem>
    <additionalTradeItemIdentification additionalTradeItemIdentificationTypeCode="GTIN_13">
        4820000538169
    </additionalTradeItemIdentification>
    <tradeItemDescription languageCode="uk">Дриль-шурупокрут акумуляторний RZTK RD 1220Li</tradeItemDescription>
    <transactionalItemData>
        <transactionalItemWeight>
            <!-- Вага товару без упаковки -->
            <measurementType>DECLARED_NET_WEIGHT</measurementType>
            <measurementValue measurementUnitCode="KGM">1.5</measurementValue>
        </transactionalItemWeight>
        <transactionalItemWeight>
            <!-- Вага товару з упаковкою -->
            <measurementType>TOTAL_GROSS_WEIGHT</measurementType>
            <measurementValue measurementUnitCode="KGM">12</measurementValue>
        </transactionalItemWeight>
    </transactionalItemData>
</transactionalTradeItem>

Також можна вказати будь-які додаткові відомості, які не покриваються стандартом GS1 - для цього можна використати елемент avpList з типом AttributeValuePairListType

Для отримання повного переліку всіх можливих елементів варто скористатися схемою xsd і знайти там елемент ecom_common:TransactionalTradeItemType або використати один з навігаторів по документах.