Що відбувається, коли комусь на роботі потрібен новий ноутбук, сировина для виробництва чи клінінгові послуги? У багатьох компаніях стара відповідь означала електронні листи, таблиці, паперові форми та когось, хто намагається знайти рахунок через кілька тижнів. Вітаємо в черговому епізоді Microsoft Knowledge Nuggets на М365FM. Я Мірко Петерс, і сьогодні ми розглядаємо закупівлі та постачання, зв'язаний процес, який компанія використовує для придбання товарів і послуг у постачальників. Уявіть це як єдину стійку реєстрації в офісній будівлі. Кожен запит, погодження, замовлення, доставка, рахунок і оплата проходять через одне місце. Ми простежемо за однією закупівлею від першого запиту до механізмів контролю, що працюють за лаштунками. Перше, що насправді охоплюють закупівлі та постачання. Закупівлі та постачання можуть звучати як занадто довга назва для купівлі речей, і це справді про купівлю, але ці два слова описують різні завдання.

Постачання – це робота з пошуку та вибору правильного постачальника. Подумайте про компанію, якій потрібні рукавички, шоломи, знаки безпеки та захисні окуляри. Перш ніж хтось оформить замовлення, хтось має вирішити, хто може поставити потрібні продукти за прийнятною ціною в потрібну дату на умовах, які влаштовують компанію. Це і є постачання. Закупівлі починаються тоді, коли компанії потрібно керувати безпосередньо процесом придбання. Вони охоплюють запит, погодження, замовлення на закупівлю, доставку, рахунок фактуру та оплату. Разом цей процес називається «Від джерела до оплати – соступей». Назва описує весь шлях. Бізнес визначає потребу, обирає постачальника, надсилає замовлення, отримує товар чи послугу, отримує рахунок від постачальника, а потім фінансовий відділ оплачує його. Кожен крок пов'язаний із наступним. Ви б подумали, що це очевидно, але багато компаній досі виконують ці кроки окремо.

Співробітник надсилає запит електронною поштою, менеджер погоджує його в чаті, закупівельник зберігає деталі в таблиці, склад перевіряє паперову накладну, бухгалтерія отримує рахунок, який не має чіткого зв'язку із замовленням. Люди все ще можуть купувати речі таким чином, але вони втрачають контроль над процесом. Закупівельник не може знати, що склад уже отримав частину замовлення. Фінансовий відділ може випадково оплатити один і той самий рахунок двічі, якщо він надійде через різні канали. Менеджери дізнаються про витрати лише після того, як гроші пішли з компанії. Коли хтось запитує, хто це погодив, відповідь означає довгий пошук у поштових скриньках. Dynamics 365 об'єднує цей шлях в одну пов'язану платформу. Закупівлі та постачання в Dynamics 365 Supply Chain Management – це середовище, де компанія керує рухом і наявністю товарів, а також взаємодіє з фінансовим відділом та відділом розрахунків з постачальниками для реєстрації рахунків, відстеження заборгованості та здійснення платежів.

Отже, процес закупівель не відбувається ізольовано. Склад може зафіксувати надходження товарів, фінансовий відділ бачить рахунок фактуру, пов'язану з цією закупівлею, а відділ розрахунків може порівняти замовлений з фактично отриманим і виставленим постачальником рахунком. Кожна команда бачить лише потрібну їй частину, тоді як закупівля залишається єдиним пов'язаним записом. Існує два типи закупівель. Прямі закупівлі охоплюють товари чи послуги, пов'язані з тим, що компанія виробляє або продає. Виробник меблів, що купує деревину, гвинти та тканину, купує прямі матеріали. Без цих матеріалів він не зможе створити продукт, який продає. Непрямі закупівлі охоплюють речі, що забезпечують роботу бізнесу, але не стають частиною проданого товару, ноутбуки, офісні меблі, навчання, ремонт, прибирання, програмне забезпечення або юридичні консультації. Обидва типи важливі, але вони часто починаються по-різному.

Виробнича потреба може підказати компанії, що потрібно більше запчастин. Співробітник може запросити новий монітор. Керівник адміністративно-господарського відділу може потребувати послуг з ремонту. Dynamics 365 обробляє всі ці різноманітні потреби, зберігаючи прозорість процесу закупівель. Візьмемо один простий приклад для цього епізоду. Уявіть, що менеджер складу помічає, що команді потрібне нове захисне спорядження. Деякі шоломи пошкоджені, а запас захисних рукавиць на вичерпанні. Менеджеру потрібна достатня кількість спорядження для команди, а компанії «Чіткий облік» перш ніж кошти будуть виділені. Ця закупівля починається з потреби, а кожна контрольована закупівля починається з того, що хтось просить про щось. Два – від внутрішнього запиту до відповідного постачальника. Ось як починається весь процес закупівлі. Ваш складський менеджер виявляє потребу в захисному спорядженні, і першим записом, створеним у Dynamics 365, є заявка на закупівлю.

Заявка на закупівлю – це внутрішній запит на придбання чого-небудь. Вона повідомляє компанії, що саме потрібно, в якій кількості і куди це має бути доставлено. Зауважте, що цей запит ще нічого не обіцяє постачальнику. Ця відмінність дозволяє утримувати початковий етап закупівель під контролем вашої компанії. Менеджер складу може запросити 20 шоломів і кілька коробок рукавиць, але жоден постачальник не отримає замовлення, доки відповідні особи його не перевірять. Для звичайних закупівель запит може починатися в каталозі товарів. Уявіть цей каталог як затверджену полицю товарів вашої компанії. Замість того, щоб вводити розмитий запит, наприклад, захисні рукавиці, співробітник може обрати затверджений товар із відомим описом, варіантами постачальників та вже визначеною ціною. Це економить час, а також запобігає купівлі випадкових товарів, що не відповідають правилам компанії. Проте не кожна заявка вписується в каталог.

Компанії може знадобитися одноразовий ремонт, навчання консультанта чи послуга, що не зберігається як фізичний товар. У такому разі Dynamics 365 дозволяє використовувати категорію закупівель. Категорія закупівель групує витрати за їхнім типом. Наприклад, компанія може використовувати такі категорії, як засоби безпеки, ремонт будівель, юридичні послуги або комп'ютерне обладнання. Заявник може описати, що йому потрібно і віднести це до відповідної категорії, навіть якщо немає артикула на складі. Заявка не повинна автоматично перетворюватися на закупівлю лише тому, що хтось натиснув «Надіслати». Компанія може встановлювати ліміти витрат, перевірку бюджету та робочі процеси затвердження. Невелика заявка на рукавички може надходити до менеджера складу. Більша заявка на обладнання для безпеки може потребувати схвалення власника бюджету відділу або команди закупівель. Маршрут може змінюватися залежно від суми, відділу або правил закупівлі, що стосуються цього типу витрат.

Це означає, що людям не потрібно пам'ятати кожне правило затвердження самостійно. Dynamics 365 спрямовує заявку за потрібним шляхом, зберігаючи її історію в системі. Припустімо, менеджер замовляє велику партію обладнання, а компанія ще не знає, якому постачальнику надати замовлення. Відділ закупівель може створити запит на комерційну пропозицію, часто званий RFQ. RFQ пропонує кільком постачальникам позмагатися за виконання одного запиту. Покупець надсилає вимоги, такі як тип шолома, розмір рукавичок, кількість та бажану дату доставки. Кожен постачальник може надати свою ціну та умови. Можливо, один постачальник пропонує меншу ціну, але не може доставити товар протягом трьох тижнів. Інший коштує трохи дорожче, але може все доставити вже наступного вівторка. Покупець може порівняти ці відповіді перед вибором. Ціна має значення, але це не єдиний фактор. Дати доставки, деталі продукту, знижки та здатність постачальника виконати запит – усе це впливає на вибір.

Система зберігає пропозиції, пов'язані із заявкою, замість того, щоб залишати порівняння в купі електронних листів. Перш ніж покупець зробить вибір, Dynamics 365 також зберігає записи про постачальників. Запис про постачальника містить дані компанії, необхідні для закупівель, такі як назва та інформація для ділових відносин. Каталоги постачальників можуть відображати товари, які вони пропонують, а постачальники можуть публікувати ці каталоги, щоб підтримувати інформацію в актуальному стані. Для суварішого контролю продукт може мати список затверджених постачальників. Це підказує покупцеві, яких постачальників компанія схвалила для цього продукту. Це спрямовує вибір і може зупинити людину від вибору постачальника, якого компанія ніколи не планувала використовувати. Деякі відносини з постачальниками також передбачають умови у згодженні заздалегідь. Угода про закупівлю фіксує довгострокові домовленості між компанією та постачальником.

Компанія може зобов'язатися закупити певну кількість або витратити визначену суму за певний період, а постачальник погоджується на відповідні умови. Торговельні угоди фіксують ціни або знижки постачальника, що діють протягом певних дат. Отже, якщо постачальник засобів безпеки погодився на нижчу ціну на рукавички на наступні 6 місяців, Dynamics 365 може зберегти цю домовленість, замість того, щоб кожен покупець пам'ятав про неї. Угоди про знижки також можуть відстежувати випадки, коли постачальник повертає кошти після того, як компанія досягає певної суми або обсягу закупівлі. На цьому етапі компанія вже знає, що їй потрібно, хто може це поставити та які умови застосовуються. Пошук завершено, але постачальнику все ще потрібне офіційне замовлення. Третє – замовлення на закупівлю – це письмове зобов'язання компанії. Покупець обрав постачальника засобів безпеки. Тепер компанії потрібне замовлення на закупівлю, яке зазвичай називають ПІО.

Замовлення на закупівлю – це офіційний документ, який повідомляє постачальнику, що саме компанія має намір придбати. У ньому зазначається постачальник, перелік товарів або послуг, кількість і узгоджена ціна, а також дата доставки та умови оплати. Для нашого складу в ПІО може бути вказано 20 шоломів, 10 коробок рукавичок і дата доставки на наступний вівторок. Це перетворює рішення про закупівлю на чіткий запис, з яким можуть працювати обидві сторони. Нікому не потрібно вгадувати, який саме тип рукавичок замовила компанія, скільки одиниць очікується або про яку ціну покупець домовився з постачальником. Замовлення на закупівлю може бути створене кількома способами. Найчастіше воно виникає на основі затвердженої заявки на закупівлю. Завідувач складу зробив запит на засоби безпеки, відповідальні особи затвердили його і відділ закупівель перетворює це на ПІО. Воно також може бути створене на основі угоди про закупівлю.

Якщо компанія вже уклала довгострокову угоду з постачальником засобів безпеки, покупець може створити замовлення на відпуск товарів за цією угодою, замість того, щоб формувати кожну деталь з нуля. Іноді замовлення створюється через попит. Компанія може планувати закупівлю матеріалів через очікувані потреби виробництва, і Dynamics 365 може створювати планові замовлення на закупівлю на основі цього попиту. Коли компанія випускає планове замовлення, воно стає реальним замовленням на закупівлю. Також існують прямі закупівлі. Покупець може створити ПІО вручну, якщо для цього немає попередньої заявки, угоди або планового попиту. Це може статися, коли покупець уже знає, що потрібно компанії та який постачальник це надасть. Різні початкові точки – один і той самий результат. Перш ніж замовлення на закупівлю піде в роботу, компанія може вимагати його затвердження. Покупець готує замовлення, але воно може потребувати внутрішнього погодження згідно з правилами компанії щодо автоматичних сум, перш ніж потрапить до постачальника.

Це розмежовує два рішення. Спочатку компанія схвалює власні зобов'язання, а потім підтверджує замовлення постачальнику, засвідчуючи згоду обох сторон щодо подальших дій. Підтверджене замовлення на закупівлю – це більше, ніж просто внутрішня нотатка. Воно фіксує, що замовлення отримане постачальником і між сторонами існує домовленість про купівлю. Dynamics 365 також звільняє покупців від необхідності щоразу вводити одну і ту саму інформацію при замовленні у звичного постачальника. Запис про постачальника може містити такі деталі, як інформація про доставку, умови оплати та інші звичайні налаштування. Покупець все одно перевіряє замовлення і може змінити деталі, якщо того вимагає ситуація, але стандартні дані вже на місці. Це зменшує обсяг введення даних і забезпечує більшу узгодженість повторних замовлень. Доставка не завжди відбувається однією посилкою в один день. Уявіть, що у постачальника є всі рукавички, але готові лише половина шоломів.

Графік доставки дозволяє компанії розділити одне замовлення на закупівлю на заплановані постачання в різні дні. У замовленні можна вказати, що 10 шоломів прибудуть наступного вівторка, решта 10 – через тиждень, а рукавички надійдуть з першою партією. Одне замовлення залишається єдиним цілим, тоді як план доставки відповідає реальним можливостям. Деякі товари ніколи не потрапляють безпосередньо до компанії. Пряма доставка означає, що постачальник відправляє товар безпосередньо клієнту компанії. Наприклад, бізнес продає спеціалізований товар, якого немає на власному складі. Він може створити замовлення на продаж для клієнта і відповідне замовлення на закупівлю для постачальника. Постачальник відправляє товар безпосередньо клієнту, а Dynamics 365 автоматично пов'язує відповідні етапи продажу та закупівлі. Це дозволяє уникнути зайвої зупинки на складі компанії та пов'язує замовлення клієнта із замовленням постачальника, щоб можна було відстежити товар з обох боків угоди.

Замовлення на закупівлю може містити не лише основний товар. Деякі продукти потребують супутніх товарів. Коли компанія замовляє шоломи, їй також можуть знадобитися змінні візори або кріплення. Dynamics 365 може запропонувати додаткові товари, які можуть бути обов'язковими, опціональними або включеними без додаткової плати. Покупець бачить супутні потреби ще під час формування замовлення, а не дізнається про них після отримання основної партії. Крім того, існують додаткові витрати. Витрати на фракт, обробку та інші подібні нарахування також можна додати до замовлення на закупівлю. Нарахування може стосуватися всього замовлення або окремого рядка замовлення, залежно від того, як компанії потрібно це відобразити. Це важливо, оскільки низька ціна товару не відображає повну вартість, якщо доставка додає значну плату. Запис витрат разом із замовленням пов'язує цю вартість із купівлею, замість того, щоб залишати її в окремому документи.

Тепер постачальник має підтверджене замовлення з чіткими позиціями, цінами, датами та умовами. Але підтверджене замовлення лише фіксує те, що компанія очікує отримати. Dynamics 365 все одно потребує підтвердження того, що товари чи послуги фактично надійшли. Четверте – отримання товарів та перевірка рахунка фактури. Вантажівка під'їжджає до складу з шоломами та рукавичками. Перш ніж хтось позначить замовлення як виконане, складська команда має перевірити, що саме прибуло. Вони реєструють прибуття, порівнюють поставку із замовленням на закупівлю та проводять надходження товарів за цим замовленням. Надходження товарів – це просто спосіб для системи зафіксувати, що товари прибули. Ось десятьох одиниць. У замовленні зазначено 20 шоломів та 10 коробок рукавичок, але водій привозить лише 10 шоломів та всі 10 коробок рукавичок. Склад фіксує те, що фактично отримав, а не те, що компанія сподівалася отримати.

Решта 10 шоломів залишаються відкритими у замовленні на закупівлю, доки постачальник їх не доставить або покупець не змінить замовлення. Це забезпечує точність обліку. Після того, як надходження товарів проведено, замовлення на закупівлю змінюється. Система тепер розділяє замовлену кількість та отриману, тому покупці, складський персонал та фінансовий відділ бачать статус замовлення, не телефонуючи один одному. Для складських позицій отримання також оновлює запаси. Рукавички з'являються як доступний запас, готовий до використання командою складу. Якщо товари належать до певного проєкту, основного засобу або прямої поставки, Dynamics 365 може записати закупівлю на відповідне призначення. Компанія знає більше, ніж просто те, як ми купили рукавички. Вона знає, чи прибули рукавички, скільки їх надійшло і куди вони мають потрапити. Проте не кожна закупівля потрапляє на вантажну платформу. Уявіть, що компанія наймає інструктора з техніки безпеки на день, оплачує доступ до ПЕЗе або запрошує зовнішню ремонтну службу.

Тут немає фізичних товарів, немає піддонів для підрахунку та немає надходження на склад для реєстрації. Для послуг та інших нематеріальних закупівель компанія може обрати простіший шлях. Залежно від налаштувань закупівлі, вона може зареєструвати отримання в замовленні без складського етапу або перейти одразу до рахунка постачальника. Тут застосовується те саме питання. Чи отримала компанія те, що вона погодилася купити? Для навчальної послуги відповіддю може бути те, що навчання відбулося. Для ремонту хтось підтверджує, що роботу завершено. Запис не потребує коробки чи штрих-коду, щоб підтвердити, що компанія щось отримала. Потім надходить рахунок від постачальника. Рахунок потрапляє до кредиторської заборгованості частини Dynamics 365, яка фіксує борги компанії перед постачальниками та готує платежі. Рахунок пов'язується із замовленням на купівлю, тому кредиторська заборгованість не розглядає його як ізольований рахунок без історії.

Саме тут проста перевірка допомагає уникнути багатьох проблем. Dynamics 365 порівнює три речі, що компанія замовила, що отримала і що виставив постачальник. Це називають звіренням. Простою мовою, чи збігається рахунок із домовленостями? У замовленні на купівлю може бути вказано 20 шоломів за узгодженою ціною. У квитанції про отримання товару може бути зазначено, що поки що прибуло лише 10 шоломів. Якщо постачальник надсилає рахунок на 20 одиниць, система може показати різницю до того, як компанія здійснить оплату. Це автоматизує тристоронні звірення. Цими трьома записами є замовлення на купівлю, квитанція про отримання товару та рахунок фактура. Коли вони збігаються, кредиторська заборгованість має чіткий шлях для подальших дій. Якщо ціна відрізняється, кількість у рахунку перевищує отримано або з'являється рядок, який ніхто не замовляв, компанія може зупинитися і з'ясувати причину. Можливо, постачальник надіслав рахунок завчасно.

Можливо, витрати на перевезення виділені окремою сумою, яку покупцю варто перевірити. Можливо, постачальник просто помилився в кількості. Мета – не припускати злого наміру. Система автоматично виявляє розбіжності, поки компанія може поставити запитання, а не після того, як гроші пішли з банку. Кожен рахунок також має знайти своє місце у фінансових записах компанії. Це автоматизує завдання бухгалтерських розподілів. Вони підказують Dynamics 365, як саме відобразити витрати. Захисні рукавиці можуть належати до операційних витрат складу. Новий навантажувач може належати до рахунку основних засобів. Витрати на проектну закупівлю мають бути записані на відповідний проект. Один рахунок можна навіть розподілити між кількома місцями. Наприклад, якщо дві складські команди ділять замовлення на рукавиці, компанія може розділити вартість між їхніми відділами. Фінансовий відділ зможе побачити, куди пішли кошти, не намагаючись згодом відновити картину за нечітким описом у рахунку.

Після того, як рахунок пройшов звіряння і всі необхідні перевірки завершено, він може пройти процес затвердження. Проведення рахунку записує суму боргу компанії перед постачальником у кредиторській заборгованості. Рахунок тепер є заборгованістю до сплати. Умови оплати допомагають визначити термін її виконання. Відділ кредиторської заборгованості готує рахунки до оплати, і як тільки компанія проводить платіж, Dynamics 365 закриває баланс постачальника за цим рахунком. Замовлення пройшло шлях від очікуваної доставки до відображених витрат та здійсненої оплати. Але цей ланцюжок робить значно більше, ніж просто оплачує один рахунок. Це надає компанії зручний запис кожного рішення та кожної передачі, пов'язаної з цією закупівлею. 5. Контроль видимості та кращі рішення щодо постачальників. Єдиний запис про закупівлю також дозволяє компанії контролювати витрати до того, як проблема дійде до фінансового відділу.

Політика закупівель встановлює основні правила. Вона визначає, що працівники можуть замовляти, яких постачальників використовувати та коли закупівля потребує схвалення, перш ніж витрачати кошти компанії. Подумайте про запит на засоби безпеки. Компанія може вимагати від персоналу складу вибирати лише схвалені засоби безпеки, тоді як лише відділ закупівель може обрати нового постачальника. Невелике замовлення на заміну може потребувати одного схвалення, а велике замовлення для нового відділу – власника бюджету та менеджера із закупівель. Правила закладені в сам процес. Людям не потрібно шукати документи з політикою, вгадувати, хто має щось схвалити, або пересилати листи, очікуючи на відповідь. Dynamics 365 може спрямовувати запит залежно від відділу, суми, типу закупівлі або застосованої політики. Цей маршрут називається робочим процесом. Робочий процес забезпечує чіткий шлях для запитів, замовлень на купівлю та рахунків від однієї людини до іншої.

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

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

Компанія може використовувати власні записи про закупівлі під час перегляду відносин із постачальником. Потім з'являється аудиторський слід. Аудиторський слід дозволяє відстежити закупівлю протягом усієї її історії. Можна почати з початкового запиту, побачити, хто його схвалив, переглянути замовлення на купівлю, перевірити квитанцію, знайти рахунок фактуру та побачити платіж, що його закрив. Цей запис допомагає фінансовим та аудиторським групам, але він також допомагає звичайним працівникам відповідати на звичайні запитання. Чому ми це купили? Хто обрав цього постачальника? Чи надійшов товар? Чи вже оплачено рахунок фактуру? Відповідь міститься в записі про закупівлю. Повернімося до офісної будівлі, з якої ми починали. Відділ закупівель, приймальний док і фінансовий відділ мають різні завдання, але всі вони розглядають частини однієї і тієї ж закупівлі, замість того, щоб передавати папери між окремими кімнатами.

Наш менеджер складу, наш ТМС, запит на шоломи та рукавички тепер має повну історію. Запит відповідав політиці компанії. Потрібні люди його схвалили. Постачальник надав обладнання. Персонал складу зареєстрував доставку. Відділ розрахунків із кредиторами зіставив рахунок фактуру та оплатив його. Одна проста відмінність робить усі ці складові елементи зрозумілими. Пошук джерел постачання допомагає компанії вибрати, у кого купувати, тоді як закупівлі керують тим, що відбувається після того, як компанія вирішила купити. Висновок. Один пов'язаний запис від ініціації до оплати. Ось повна картина. Закупівлі та пошук джерел постачання перетворюють усі ці розрізнені етапи на один відстежуваний процес компанії. Запит не зникає в папці, вхідні, схвалення не залишається лише в чиїсь пам'яті, а рахунок фактура не надходить без чіткого зв'язку з рішенням, що стоїть за ним. Натомість компанія має один пов'язаний запис, який відстежує закупівлю від початку до кінця.

Це дає вам чітку відповідь, коли вона вам потрібна. Як покупець, ви бачите замовлення. Склад бачить, що очікується. Фінансовий відділ знає, що компанія винна. А менеджери бачать, куди саме йдуть витрати. Закупівлі все ще включають людей, постачальників, товари, послуги та рішення. Dynamics 365 не усуває ці речі. Система зберігає їхні записи разом, тому ви можете здійснювати закупівлі з меншою кількістю незавершених справ і несподівано. Підписуйтесь на вашій улюбленій подкаст-платформі та поділіться цим корисним досвідом з тими, хто починає вивчати модуль «Закупівлі та джерела постачання» в Dynamics 365.