Формат електронних документів EDI ANSI ASC X12 (документація), Документація, Програмування, статті

Введення.

В даній статті представлено опис стандарту EDI ANSI ASC X12. Стаття призначена для початківців фахівців, які тільки починають працювати з електронним документообігом в форматі EDI ANSI ASC X12, але, можливо, буде цікава й професіоналам, які вже мають досвід роботи в даній області. На початку статті даються загальні терміни (Interchange, функціональна група, документ), детальний опис основних складових EDI документа (сегментів, елементів) і зв’язок між ними. Потім описується, як з цих складових формуються документи, детально розбирається їх ієрархічна структура. В кінці статті коротко описується, як використовується EDI в умовах реального електронного документообігу.

Історія.

Електронний документообіг EDI (Electronic Data Interchange) – обмін між комп’ютерами структурованої інформацією по взаємоузгоджених правилам. Вперше EDI почав застосовуватися в середині 60х років в сфері залізничних і автомобільних перевезень. У 1968 році був організований комітет United States Transportation Data Coordinating Committee (TDCC) для робіт над стандартом електронного документообігу для даної індустрії. Надалі роботою по розширенню та вдосконаленню стандарту став займатися

American National Standards Institute (ANSI)

. Стандарт електронного обміну документами ANSI ASC X12 (American National Standards Institute Accredited Standards Committee X12) був розроблений в 70-х роках, коли був важливий малий розмір електронного документа (Для модемів зі швидкостями 300-1200 біт в секунду) і кожен байт повинен був нести максимум інформації. Таким чином, від «читаності» електронного документа відмовилися на користь «щільності інформації». У той час комунікації між компаніями були далекі від ідеалу, і непоодинокими були випадки «обриву» лінії і втрати даних. Тому формат електронних документів розроблявся в тому числі з метою збереження цілісності даних, для чого були використані механізм «конвертів» (envelopes) і контрольні числа, які дозволяли перевіряти, що передані дані не були порушені або втрачені. Стандарт EDI можна визначити як набір правил, що визначають структуру і формат EDI документа. Існує кілька організацій, які в даний момент працюють над стандартами EDI:

Стандарт EDI ANSI ASC X12 (далі – просто X12) включає в себе опис форматів документів (наборів транзакцій – transaction sets) і має різні версії (пов’язані з розвитком стандартів) – 4030VICS, 5010 і т.д.

Термінологія.

Документ (document або transaction set).

Стандарт X12 оперує поняттям «документ» (document), або «набір транзакції» (transaction set). Документ – це набір даних, що представляють в сукупності закінчену інформацію, цінну для сторін, що беруть участь в документообігу. Transaction set в більшості випадків – це звичайний документ, який компанії використовують у своїй роботі – наприклад Invoice (рахунок) або Purchase Order (ордер замовлення).

Функціональна група (Functional Group).

Функціональна група – це група (набір) однакових за типом документів (ордерів, інвойсів тощо), які входять в Interchange. Структура EDI буде описана далі, але поки просто відзначимо, що початок і кінець функціональної групи визначаються сегментами GS / GE (GS / GE Envelope). Тип функціональної групи визначається елементом GS-01 (наприклад, функціональна група PO містить ордера замовлень – Purchase Orders, функціональна група IN – інвойси). Сегмент GS так само іноді служить для маршрутизації документів між підрозділами партнера-отримувача документів.

Interchange.

Interchange це структурований (згідно з правилами, що визначаються стандартом X12) набір даних, яким обмінюються партнери по (електронну) документообороту. Interchange – це більше, ніж просто документ, скоріше це пакет груп документів (хоча interchange може містити лише одну групу з одним документом). Надалі я буду використовувати термін «EDI документ» якщо мова йде про Interchange і просто «документ» якщо мова йде про окремий документі (transaction set) з цього Interchange. Можна зобразити структуру Interchange таким чином (пізніше ми розберемо складові частини і структуру більш детально): рис 6. Слід зазначити, що елемент поза сегмента не має сенсу. Елементи в сегменті мають свій «адресу», який складається з імені сегмента і позиції елемента в даному сегменті. Зазвичай позначається як <ІМ’Я СЕГМЕНТА> – <ПОЗИЦІЯ> Або <ІМ’Я СЕГМЕНТА> <ПОЗИЦІЯ> Наприклад, PO101 або PO1-01 для першого (01) елемента в сегменті PO1.

Типи даних.

У стандарті X12 визначаються такі типи даних, які може містити елемент: AN (Alpha-Numeric) – рядок, який може містити літери, цифри, знаки пунктуації. Це може бути довільна рядок, наприклад ім’я товару або назву вулиці на яку потрібно доставити товар, і т.д. Приклади: «Батон нарізний, 1-ГО СОРТИ», «САНКТ-ПЕТЕРБУРГ». Для цього типу даних так само накладається обмеження на довжину рядка, наприклад 1/20 – від 1 до 20 символів, 2/2 – рівно 2 символу і т.д. R (Real) – дробове число. Даний тип даних використовується для інформації про ціну, вагу продукту, відстані, розмір знижки і т.д. Приклади: 1.23; 75.99. Починаючи з версії 4010 підтримується експоненціальна нотація. N[X] (Number) – спеціальний формат числа. [X] визначає, скільки знаків праворуч треба «відступити» щоб поставити кому. Наприклад, для типу даних N2 для позначення числа 1,23 значенням елемента буде 123, а для 10,5 – 1050 (тобто щоб отримати потрібне значення ми беремо значення елемента і ділимо його на 102). N0 відповідає цілому числу, тобто його значення залишається як є. ID (Identity) – ідентифікатор. Про це типі даних слід розповісти докладніше. Найпростіший приклад ідентифікаторів з реального життя – це одиниці вимірювання, наприклад «ММ» (міліметр), «СМ» (сантиметр), «РУБ» (Рубль) і т.д. У X12 все ідентифікатори зібрані в логічні групи (класифікатори), і цим групам привласнені унікальні ідентифікатори – номери. Класифікатор складається з декількох значень, і кожне значення має своє унікальне ім’я (зазвичай, 2-3 букви і цифри) і розшифровку (визначення). Приклади класифікаторів – одиниці ваги, типи валют, коди країн. Розглянемо, наприклад, класифікатор (групу ідентифікаторів) номер 90

90 Measurement Unit Qualifier Одиниці Вимірювання
ENGINE=ID MIN=1 MAX=1 Тип – ідентифікатор, довжина імені MIN = 1, MAX = 1
Code specifying the linear dimensional unit Код, що визначає одиницю лінійного розміру
CODE DEFINITION & EXPLANATION
C Centimeters
E Feet
N Inches
X Meters

Стає зрозуміло, що якщо елемент сегмента у нас має тип ID з класифікатора 90, то мова йде про довжину. І якщо значення цього елемента, наприклад, «N», то довжина визначається в дюймах (inches). Особливо відзначу, що якщо елемент має тип даних ID, то його значення може належати тільки одному класифікатором, визначеним стандартом для цього елемента в даному сегменті. Інакше кажучи, не може бути ситуації, коли елемент типу ID може бути одиницею вимірювання маси (наприклад, класифікатор 188 Weight Unit Code) і в той же час – одиницею вимірювання довжини (наприклад, класифікатор 90 Measurement Unit Qualifier). Так само часто в класифікаторі існує спеціальне значення – «Z», «ZZ» або «ZZZ» залежно від обмежень по довжині значення ідентифікатора. Це ім’я має розшифровку (визначення) «Mutually Defined» (Взаємно певне), і використовується для позначення одиниць, відсутніх в стандарті для даного класифікатора, про які учасники документообігу домовилися заздалегідь. Компанії, які обмінюються документами, коли зустрічають подібне значення ідентифікатора, в більшості випадків знають, про що йде мова – це можуть бути «(33) папуги» або «(10) сірникових коробок». Для цього типу даних так само накладається обмеження на довжину рядка, наприклад 3/3 – від 3 до 3 символів, або (простіше кажучи) 3 символи рівно. Дане обмеження виходить не від стандарту сегмента документа, а від типу використовуваного класифікатора (якщо класифікатор 90 визначає обмеження на довжину значення як 1/1, то елемент-ідентифікатор який використовує цей класифікатор, так само буде мати обмеження на довжину 1/1). Існують спеціальні довідники (наприклад,

www.x12.org/x12org/subcommittees/dev/pdf/V5_x123.pdf)

, За якими можна визначити набір значень даного класифікатора або за значенням елемента та номером класифікатора знайти визначення цього значення. DT (Date) – дата. Цей тип даних призначений для зберігання значення дати і має формат YYMMDD (починаючи з версії 4010 – CCYYMMDD). Приклади: 20060625 (25 червня 2006). TM (Time) – час. Цей тип даних призначений для зберігання значення часу і має формат HHMM. Приклади: 1259 (12:59). Так само може включати секунди (опціонально). B (Binary) – бінарні дані, послідовність 8-ми бітних байтів. <composite> – Композитний елемент. Це елемент, який містить одразу кілька значень, розділених спеціальним символом (цей символ вказується в сегменті ISA, елемент ISA-16). Приклади: 12345.67> 12.55 (в даному прикладі роздільником є ​​”>”). Елементи, з яких складається композитний елемент, називаються так само компонентами (component data element) або суб-елементами (sub-element).

Опціонально елементів.

Елементи сегмента мають три типи опціонально: M (Mandatory) – обов’язковий елемент. Зазвичай обов’язковими елементами є ті, які несуть основну інформацію сегмента. Наприклад, у сегменті DTM (Date / Time Reference, описує дату і / або час) елемент DTM-01 (Date / Time Qualifier, тип Дати та / або часу) обов’язковий, так як без нього ми не могли б визначити, що саме це за дата. В нашому прикладі DTM*002*20060625~ DTM*010*20060618~ Елементи DTM-01 мають значення 002 і 010. Тип даних DTM-01 – ID, класифікатор – 374 (Date / Time Qualifier, Code specifying type of date or time, or both date and time). За довідником знаходимо значення для 002 і 010: 002 Delivery Requested (запитувана доставка) 010 Requested Ship (запитувана навантаження) Т.ч. в документі вказано, що для описаного товару дата навантаження – 18 Червня 2006 року, а дата доставки – 25 червня 2006. Якби DTM-01 був би опціональним (необов’язковим) елементом, і він би був відсутній в обох сегментах, то одержувач документа не міг би визначити, що це за дати. O (Optional) – необов’язковий, опціональний елемент. Ці елементи зазвичай несуть другорядну інформацію, яка не обов’язкова для розуміння інформації, що містяться в сегменті. В нашому прикладі PO1*004005006*10*EA*15**BP*123456321~ Можна помітити, що між елементами PO1-04 (значення 15) і елементом PO1-06 (значення BP) йде елемент PO1-05 який не має значення (пропущений). PO1-05 (Basis Unit Price Code, код, що ідентифікує тип ціни одиниці товару) є опціональним елементом. Цей елемент описує тип ціни, наприклад BD (Before Discount, до знижки) або HF (Per 100 Feet, за 100 футів – наприклад, для кабелю), або HP (Price per Hundred, ціна за сотню) і т.д. В даному випадку нам не потрібно додатково вказувати, що ціна саме за одиницю товару, тому в сегменті цей елемент пропущений. C (Conditional) – залежний елемент, чия опціонально залежить від умов. У нашому прикладі: PO1*004005006*10*EA*15**BP*123456321~ PO1-06 (Product / Service Id Qualifier, тип ідентифікатора товару / послуги) та PO1-07 (Product / Service Id, ідентифікатор товару / послуги) – приклади подібних елементів. X12 визначає умова їх опціонально так: P0607 – If either PO1-06 or PO1-07 is present, then the other is required. Тобто якщо або PO1-06, або PO1-07 присутній в сегменті, то другий – обов’язковий. В даному випадку це очевидно – якщо є ідентифікатор товару, то нам потрібно знати його тип. І навпаки, якщо є тип ідентифікатора, то було б дивно, якби сам ідентифікатор відсутній. Далі будуть коротко розглянуті основні типи правил і обмежень, які стандарт накладає на елементи сегмента. Правила та обмеження Для залежних елементів в сегменті стандарт визначає набір правил / зауважень. Кожне правило має спеціальне ім’я-ідентифікатор. Ім’я-ідентифікатор «будується» за спеціальними правилами – перша буква визначає тип правила, далі йдуть числа, що позначають позицію сегментів в елементі, для яких діє це правило. В залежності від типу правила, позиції елементів так само йдуть в певному порядку:

Семантичні зауваження Стандарт може визначати семантичні правила для елементів сегмента. Ці зауваження призначені для кращого розуміння призначення елементів. Наприклад, для сегмента PO1 існує таке семантичне зауваження: PO106 through PO125 provide for ten different product / service IDs per each item. For example: Case, Color, Drawing No., U.P.C. No., ISBN No., Model No., Or SKU. (Елементи, починаючи з PO1-06 і закінчуючи PO1-25 надають 10 різних ідентифікаторів для кожного товару. Наприклад: упаковка, колір і т.д.). Нарешті, розглянемо наш сегмент PO1 для прикладу, і подивимось як стандарт X12 (версія 4010) описує його елементи: PO1*004005006*10*EA*15**BP*123456321~

Елемент Опис Тип даних Значення
PO1-01 Assigned Identificator, присвоєний ідентифікатор O AN 1/20 004004005
PO1-02 Quantity Ordered, кількість замовлених примірників товару C R 1/15 10
PO1-03 Unit / Basis Measurement Code, одиниця вимірювання кількості товару O ID (355) 2/2 EA = Each
PO1-04 Unit Price, ціна одиниці товару C R 1/17 15
PO1-05 Basis Unit Price Code, код, що ідентифікує тип ціни одиниці товару O ID (639) 2/2
PO1-06 Product / Service Id Qualifier, тип ідентифікатора товару / послуги C ID (235) 2/2 BP = Buyer”s Part Number
PO1-07 Product / Service Id, ідентифікатор товару / послуги C AN 1/48 123456321

SYNTAX NOTES

  1. C0302 – If PO103 is present, then PO102 is required.
  2. C0504 – If PO105 is present, then PO104 is required.
  3. P0607 – If either PO106 or PO107 is present, then the other is required.

Структура EDI документа

Як вже було сказано вище, EDI документ можна представити у вигляді документа / документів, вкладених в конверти, які мають різне призначення.

Конверти (envelopes)

Існують три типи конвертів – ISA / IEA Envelopes, GS / GE Envelopes і ST / SE Envelopes. Початкові сегменти конвертів мають назву Header, а завершальні – Trailer:

Розглянемо ці сегменти докладніше. ISA (Interchange Control Header) – Сегмент, який визначає відправника і одержувача документа. Важливо, що елементи цього сегмента мають фіксовану довжину, наприклад ISA-06 має розмір 15/15 і до потрібної довжини доповнюється пробілами, в результаті, замість * A1STORES * ми маємо * A1STORES *. Це властивість використовується для визначення розділових елементів, які використовуються в даному EDI документі. Символ закінчення сегмента береться з позиції 106 (~), роздільник елементів – з позиції 4 (*). Роздільник суб-елементів в композитному елементі знаходиться в позиції 105 (>). ISA*00* *00* *ZZ*A1STORES       *ZZ*LEXINGTON *020115*0900*U*00400*000000005*0*T*>~

Елемент Опис Тип даних Значення Коментар
ISA-01 Authorization Information Qualifier M ID (101) 2/2 00 Тип авторизації (визначається в ISA-02) 00 – No Authorization present
ISA-02 Authorization Information M AN 10/10 “” (10 пробілів) Інформація, яка використовується для додаткової ідентифікації або авторизації відправника EDI документа або даних, які в ньому знаходяться.
ISA-03 Security Information Qualifier M ID (103) 2/2 00 Тип security інформації, що міститься в ISA-04. 00 – No Security Information present. 01 – Password.
ISA-04 Security Information M AN 10/10 “” (10 пробілів) «Пароль» документа. Цей елемент майже не використовується за призначенням.
ISA-05 Interchange ID Qualifier M ID (105) 2/2 ZZ Ідентифікатор типу даних елемента ISA-06. У нашому прикладі це ZZ – взаємно певні значення, але часто використовуються також 01 – DUNS 02 – SCAC code 10 – DODAAC 16 – DUNS + 4 та інші
ISA-06 Interchange Sender ID M AN 15/15 “A1STORES       “ Використовується для визначення відправника документа
ISA-07 Interchange ID Qualifier M ID (105) 2/2 ZZ Ідентифікатор типу даних елемента ISA-08. У нашому прикладі це ZZ – взаємно певні значення, але часто використовуються також 01 – DUNS 02 – SCAC code 10 – DODAAC 16 – DUNS + 4 та інші
ISA-08 Interchange Receiver ID M AN 15/15 “LEXINGTON      “ Використовується для визначення одержувача документа
ISA-09 Interchange Date M DT 6/6 020115 Дата документа
ISA-10 Interchange Time M TM 4/4 0900 Час документа
ISA-11 Interchange Control Standards ID M ID (110) 1/1 U Код, що ідентифікує агенство, яке відповідає за EDI стандарт, використовуваний в даному EDI документі. U – US EDI community
ISA-12 Interchange Control Version Number M ID (111) 5/5 00400 Версія ISA / IEA Envelope
ISA-13 Interchange Control Number M N0 9/9 000000005 Спеціальний ідентифікатор, який використовується для перевірки унікальності документа і запобігання відправки дубліцірованних документів. Зазвичай використовується цілочисельне значення, і з кожним новим документом, відправленим одного й того ж партнера, збільшується на одиницю.
ISA-14 Acknowledgement Requested M ID (113) 1/1 0 Індикатор запиту сегмента TA3 (Interchange Delivery Notice Segment) у відповіді приймаючої сервісу. Цей сегмент (TA3) використовується для визначення, чи був EDI документ (interchange) доставлений кінцевому одержувачу, і деякої іншої допоміжної інформації.
ISA-15 Test Indicator M ID (114) 1/1 T Має два можливі значення – T (Test) або P (Production), і використовується для визначення типу документа. Можна використовувати “T” для перевірки правильності формату документа.
ISA-16 Subelement Separator M (Символ-роздільник) 1/1 > Роздільник суб-елементів в композитному елементі.

IEA (Interchange Control Trailer) – Замикає Interchange сегмент. IEA*1*000000005~

Елемент Опис Тип даних Значення Коментар
IEA-01 Number of Function Groups Included M N0 1/5 1 Кількість функціональних груп (обмежених GS / GE сегментами), які входять в даний Interchange. У нашому прикладі це 1 – одна функціональна група (PO).
IEA-02 Interchange Control Number M N0 9/9 000000005 Контрольний номер Interchange, збігається з ISA-13

GS (Function Group Header) – Сегмент визначає тип документа (ів), які входять в цю групу, містить контрольну інформацію. Він може використовуватися для роутінга EDI документа між різними системами і / або адресами компаній, які обмінюються цими документами. Ще раз – GS / GE сегменти є «конвертом» (envelope) для документів одного типу (тип визначається GS-01 сегментом). GS*PO*A1STORES*LEXINGTON*20020110*0900*5*X*004010~

Елемент Опис Тип даних Значення Коментар
GS-01 Functional Identifier Code M ID (479) 2/2 PO Тип документів, включених в дану функціональну групу. PO – ордера, IN – інвойси тощо (См специфікацію).
GS-02 Application Sender’s Code M AN 14/14 A1STORES Код, що ідентифікує сторону-відправника. Даний код узгоджується партнерами з документообігу.
GS-03 Application Receiver’s Code M AN 9/9 LEXINGTON Код, що ідентифікує сторону-одержувача. Даний код узгоджується партнерами з документообігу.
GS-04 Date M DT 8/8 20020110 Дата
GS-05 Time M TM 4/4 0900 Час
GS-06 Group Control Number M N0 1/9 5 Присвоєний відправником номер.
GS-07 Responsible Agency Code M ID(455) 1/2 X Код, який використовується для визначення компанії, яка випустила цей стандарт. X – Accredited Standards Committee X12, T – Transportation Data Coordinating Committee (TDCC)
GS-08 Version/Release/Industry Identifier Code M AN 1/12 004010 Код, що ідентифікує номер версії, релізу та суб-релізу використовуваного стандарту. В нашому випадку це версія стандарту – 4010.

GE (Function Group Trailer) – Сегмент визначає кінець даних, які були розпочаті GS сегментом. В EDI-документ (Interchange) може бути включено декілька функціональних груп, сегмент GE використовується для визначення місця, де завершується функціональна група. GE*1*5~

Елемент Опис Тип даних Значення Коментар
GE-01 Number of Transaction Sets Included M N0 1/6 1 Кількість документів (transaction sets), включених в дану функціональну групу. Використовується як контрольне значення.
GE-02 Group Control Number M N0 1/9 5 Присвоєний відправником номер. Використовується як контрольне число при визначенні GS / GE конверта (GS-06 = GE-02).

ST (Transaction Set Header) – Сегмент ідентифікує тип документа. Цей сегмент починає документ (наприклад, ордер або інвойс). Як вже було сказано на початку, в X12 тип документа має тризначний номер-ідентифікатор. ST*850*50001~

Елемент Опис Тип даних Значення Коментар
ST-01 Transaction Set Identifier Code M ID(143) 3/3 850 Тризначний номер-ідентифікатор, що визначає тип документа. Приклади: 850 – Purchase Order 810 – Invoice 855 – Purchase Order Acknowledgment 889 – Promotion Announcement
ST-02 Transaction Set Control Number M AN 4/9 50001 Унікальний ідентифікатор документа в даній функціональної групи. Зазвичай (часто) використовується послідовність 0001, 0002, … але бувають і інші (як у нашому прикладі).

SE (Transaction Set Trailer) – Сегмент визначає кінець документа. Цей сегмент містить інформацію про загальну кількість сегментів з даними (включаючи ST і SE сегменти). Це число використовується для верифікації документа. SE*33*50001~

Елемент Опис Тип даних Значення Коментар
SE-01 Number of included segments M N0 1/10 33 Кількість сегментів, що входять в даний документ (transaction set), обмежений конвертом ST / SE. Самі сегменти ST / SE так же підраховуються в цьому числі. Ці дані використовуються для контрольної перевірки цілісності документа після обробки – чи всі сегменти були оброблені.
SE-02 Transaction Set Control Number M AN 4/9 50001 Контрольний номер, SE-02 = ST-02 для кожного ST / SE конверта.

Header (заголовок), Details (деталі) і Summary (підсумок).

Нарешті, розглянемо сам документ (transaction set). Як вже було сказано вище, документ (transaction set) являє собою набір даних, що представляють в сукупності закінчену інформацію, цінну для сторін, що беруть участь в документообігу. Приклади документів – ордер, рахунок, документ з інформацією про знижки, каталог і т.д. Кожен документ укладений в «конверт» ST / SE, в якому вказаний тип документа. Документ, в свою чергу, розділений на три групи – Header (заголовок), Details (деталі) і Summary (Підсумок). (Див. рис 6.) Заголовок документа містить дані, загальні для документа – наприклад номер, контактна інформація, дати навантаження / доставки, адреси і т.д. В деталях документа включено зміст документа, наприклад для ордера замовлення – інформація про замовлений товар, кількість, ціна та знижки на даний тип товару. Підсумкові дані зазвичай містять сумарну інформацію – для ордера це може бути кількість типів замовлених товарів, для рахунку – загальна вартість товару, загальні знижки і т.д.

Використання EDI в реальному документообіг.

Електронний документообіг використовується в багатьох областях діяльності, де потрібно обмін даними. Це в першу чергу торгівля, страхування, медицина, транспортна логістика і т.д. Великі роздрібні мережі (рітейлери), типу Wal-Mart, Kroger, K-Mart і інші використовують EDI X12 для обміну електронними документами зі своїми торговими партнерами. Вони задають формат документів, які вони відправляють самі і які вони очікують від постачальників. Компанії-постачальники, які хочуть працювати з цими ритейлерами, зобов’язані використовувати ці формати – інакше вони не зможуть «зрозуміти», що замовляє ритейлер або в компанії-рітейлері не зможуть «зрозуміти» інвойс. Зазвичай набір документів, якими обмінюється ритейлер з постачальниками, включає в себе наступні документи:

Незважаючи на те, що стандарти EDI для певного типу документа (наприклад, ордера або інвойсу) включають в себе безліч можливих даних (допустимих сегментів), на практиці рідко хто повністю використовує повний набір сегментів і елементів. Зазвичай компанії «вибирають» із стандарту тільки ті сегменти і елементи, які потрібні для їхнього бізнесу. У прикладі з роздрібними мережами EDI є сполучною ланкою між постачальниками товару і ритейлерами. Рітейлер, визначаючи версію і формат EDI документів, встановлює суворі правила на документообіг зі своїми торговими партнерами. EDI дозволяє компаніям-партнерам з електронного документообігу звести до мінімуму ймовірність помилок (у першу чергу, людських), уніфікувати свій документообіг, автоматизувати свої процеси, чітко налагодити комунікації зі своїми партнерами і багато іншого.

Автор: Геннадий Ким

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*