WEBVTT

00:00:00.000 --> 00:00:04.560
Що відбувається, коли комусь на роботі потрібен новий ноутбук, сировина для виробництва чи клінінгові послуги?

00:00:04.680 --> 00:00:10.540
У багатьох компаніях стара відповідь означала електронні листи, таблиці, паперові форми та когось, хто намагається знайти рахунок через кілька тижнів.

00:00:10.680 --> 00:00:14.720
Вітаємо в черговому епізоді Microsoft Knowledge Nuggets на М365FM.

00:00:14.880 --> 00:00:21.660
Я Мірко Петерс, і сьогодні ми розглядаємо закупівлі та постачання, зв'язаний процес, який компанія використовує для придбання товарів і послуг у постачальників.

00:00:21.660 --> 00:00:29.360
Уявіть це як єдину стійку реєстрації в офісній будівлі. Кожен запит, погодження, замовлення, доставка, рахунок і оплата проходять через одне місце.

00:00:29.520 --> 00:00:34.780
Ми простежемо за однією закупівлею від першого запиту до механізмів контролю, що працюють за лаштунками.

00:00:34.940 --> 00:00:37.980
Перше, що насправді охоплюють закупівлі та постачання.

00:00:38.160 --> 00:00:44.620
Закупівлі та постачання можуть звучати як занадто довга назва для купівлі речей, і це справді про купівлю, але ці два слова описують різні завдання.

00:00:44.780 --> 00:00:47.780
Постачання – це робота з пошуку та вибору правильного постачальника.

00:00:47.780 --> 00:00:52.160
Подумайте про компанію, якій потрібні рукавички, шоломи, знаки безпеки та захисні окуляри.

00:00:52.280 --> 00:00:59.560
Перш ніж хтось оформить замовлення, хтось має вирішити, хто може поставити потрібні продукти за прийнятною ціною в потрібну дату на умовах, які влаштовують компанію.

00:00:59.700 --> 00:01:00.820
Це і є постачання.

00:01:01.020 --> 00:01:04.540
Закупівлі починаються тоді, коли компанії потрібно керувати безпосередньо процесом придбання.

00:01:04.720 --> 00:01:08.840
Вони охоплюють запит, погодження, замовлення на закупівлю, доставку, рахунок фактуру та оплату.

00:01:08.840 --> 00:01:12.020
Разом цей процес називається «Від джерела до оплати – соступей».

00:01:12.020 --> 00:01:13.620
Назва описує весь шлях.

00:01:13.720 --> 00:01:21.780
Бізнес визначає потребу, обирає постачальника, надсилає замовлення, отримує товар чи послугу, отримує рахунок від постачальника, а потім фінансовий відділ оплачує його.

00:01:21.960 --> 00:01:23.840
Кожен крок пов'язаний із наступним.

00:01:24.020 --> 00:01:28.040
Ви б подумали, що це очевидно, але багато компаній досі виконують ці кроки окремо.

00:01:28.040 --> 00:01:38.620
Співробітник надсилає запит електронною поштою, менеджер погоджує його в чаті, закупівельник зберігає деталі в таблиці, склад перевіряє паперову накладну, бухгалтерія отримує рахунок, який не має чіткого зв'язку із замовленням.

00:01:38.740 --> 00:01:42.160
Люди все ще можуть купувати речі таким чином, але вони втрачають контроль над процесом.

00:01:42.380 --> 00:01:45.260
Закупівельник не може знати, що склад уже отримав частину замовлення.

00:01:45.360 --> 00:01:49.460
Фінансовий відділ може випадково оплатити один і той самий рахунок двічі, якщо він надійде через різні канали.

00:01:49.460 --> 00:01:53.100
Менеджери дізнаються про витрати лише після того, як гроші пішли з компанії.

00:01:53.260 --> 00:01:57.880
Коли хтось запитує, хто це погодив, відповідь означає довгий пошук у поштових скриньках.

00:01:58.080 --> 00:02:01.560
Dynamics 365 об'єднує цей шлях в одну пов'язану платформу.

00:02:01.700 --> 00:02:07.760
Закупівлі та постачання в Dynamics 365 Supply Chain Management – це середовище, де компанія керує рухом і наявністю товарів,

00:02:07.820 --> 00:02:14.260
а також взаємодіє з фінансовим відділом та відділом розрахунків з постачальниками для реєстрації рахунків, відстеження заборгованості та здійснення платежів.

00:02:14.260 --> 00:02:21.860
Отже, процес закупівель не відбувається ізольовано. Склад може зафіксувати надходження товарів, фінансовий відділ бачить рахунок фактуру, пов'язану з цією закупівлею,

00:02:21.920 --> 00:02:26.100
а відділ розрахунків може порівняти замовлений з фактично отриманим і виставленим постачальником рахунком.

00:02:26.240 --> 00:02:30.840
Кожна команда бачить лише потрібну їй частину, тоді як закупівля залишається єдиним пов'язаним записом.

00:02:31.000 --> 00:02:36.900
Існує два типи закупівель. Прямі закупівлі охоплюють товари чи послуги, пов'язані з тим, що компанія виробляє або продає.

00:02:36.900 --> 00:02:43.840
Виробник меблів, що купує деревину, гвинти та тканину, купує прямі матеріали. Без цих матеріалів він не зможе створити продукт, який продає.

00:02:44.040 --> 00:02:53.000
Непрямі закупівлі охоплюють речі, що забезпечують роботу бізнесу, але не стають частиною проданого товару, ноутбуки, офісні меблі, навчання, ремонт, прибирання, програмне забезпечення або юридичні консультації.

00:02:53.140 --> 00:02:55.740
Обидва типи важливі, але вони часто починаються по-різному.

00:02:55.900 --> 00:02:58.780
Виробнича потреба може підказати компанії, що потрібно більше запчастин.

00:02:58.780 --> 00:03:03.600
Співробітник може запросити новий монітор. Керівник адміністративно-господарського відділу може потребувати послуг з ремонту.

00:03:03.760 --> 00:03:07.680
Dynamics 365 обробляє всі ці різноманітні потреби, зберігаючи прозорість процесу закупівель.

00:03:07.820 --> 00:03:10.080
Візьмемо один простий приклад для цього епізоду.

00:03:10.260 --> 00:03:14.040
Уявіть, що менеджер складу помічає, що команді потрібне нове захисне спорядження.

00:03:14.220 --> 00:03:17.160
Деякі шоломи пошкоджені, а запас захисних рукавиць на вичерпанні.

00:03:17.160 --> 00:03:21.860
Менеджеру потрібна достатня кількість спорядження для команди, а компанії «Чіткий облік» перш ніж кошти будуть виділені.

00:03:21.960 --> 00:03:26.640
Ця закупівля починається з потреби, а кожна контрольована закупівля починається з того, що хтось просить про щось.

00:03:26.800 --> 00:03:29.760
Два – від внутрішнього запиту до відповідного постачальника.

00:03:29.960 --> 00:03:32.120
Ось як починається весь процес закупівлі.

00:03:32.280 --> 00:03:38.660
Ваш складський менеджер виявляє потребу в захисному спорядженні, і першим записом, створеним у Dynamics 365, є заявка на закупівлю.

00:03:38.800 --> 00:03:41.820
Заявка на закупівлю – це внутрішній запит на придбання чого-небудь.

00:03:41.820 --> 00:03:46.360
Вона повідомляє компанії, що саме потрібно, в якій кількості і куди це має бути доставлено.

00:03:46.560 --> 00:03:49.520
Зауважте, що цей запит ще нічого не обіцяє постачальнику.

00:03:49.680 --> 00:03:53.560
Ця відмінність дозволяє утримувати початковий етап закупівель під контролем вашої компанії.

00:03:53.740 --> 00:04:00.580
Менеджер складу може запросити 20 шоломів і кілька коробок рукавиць, але жоден постачальник не отримає замовлення, доки відповідні особи його не перевірять.

00:04:00.740 --> 00:04:03.700
Для звичайних закупівель запит може починатися в каталозі товарів.

00:04:03.700 --> 00:04:06.920
Уявіть цей каталог як затверджену полицю товарів вашої компанії.

00:04:07.060 --> 00:04:14.620
Замість того, щоб вводити розмитий запит, наприклад, захисні рукавиці, співробітник може обрати затверджений товар із відомим описом, варіантами постачальників та вже визначеною ціною.

00:04:14.740 --> 00:04:19.340
Це економить час, а також запобігає купівлі випадкових товарів, що не відповідають правилам компанії.

00:04:19.480 --> 00:04:21.580
Проте не кожна заявка вписується в каталог.

00:04:21.780 --> 00:04:26.500
Компанії може знадобитися одноразовий ремонт, навчання консультанта чи послуга, що не зберігається як фізичний товар.

00:04:26.500 --> 00:04:30.000
У такому разі Dynamics 365 дозволяє використовувати категорію закупівель.

00:04:30.120 --> 00:04:32.460
Категорія закупівель групує витрати за їхнім типом.

00:04:32.600 --> 00:04:38.040
Наприклад, компанія може використовувати такі категорії, як засоби безпеки, ремонт будівель, юридичні послуги або комп'ютерне обладнання.

00:04:38.220 --> 00:04:43.340
Заявник може описати, що йому потрібно і віднести це до відповідної категорії, навіть якщо немає артикула на складі.

00:04:43.500 --> 00:04:47.480
Заявка не повинна автоматично перетворюватися на закупівлю лише тому, що хтось натиснув «Надіслати».

00:04:47.480 --> 00:04:50.960
Компанія може встановлювати ліміти витрат, перевірку бюджету та робочі процеси затвердження.

00:04:51.100 --> 00:04:54.000
Невелика заявка на рукавички може надходити до менеджера складу.

00:04:54.160 --> 00:04:59.160
Більша заявка на обладнання для безпеки може потребувати схвалення власника бюджету відділу або команди закупівель.

00:04:59.300 --> 00:05:03.940
Маршрут може змінюватися залежно від суми, відділу або правил закупівлі, що стосуються цього типу витрат.

00:05:03.940 --> 00:05:08.120
Це означає, що людям не потрібно пам'ятати кожне правило затвердження самостійно.

00:05:08.120 --> 00:05:13.840
Dynamics 365 спрямовує заявку за потрібним шляхом, зберігаючи її історію в системі.

00:05:13.940 --> 00:05:19.400
Припустімо, менеджер замовляє велику партію обладнання, а компанія ще не знає, якому постачальнику надати замовлення.

00:05:19.520 --> 00:05:23.100
Відділ закупівель може створити запит на комерційну пропозицію, часто званий RFQ.

00:05:23.100 --> 00:05:26.500
RFQ пропонує кільком постачальникам позмагатися за виконання одного запиту.

00:05:26.640 --> 00:05:31.140
Покупець надсилає вимоги, такі як тип шолома, розмір рукавичок, кількість та бажану дату доставки.

00:05:31.280 --> 00:05:33.460
Кожен постачальник може надати свою ціну та умови.

00:05:33.460 --> 00:05:36.580
Можливо, один постачальник пропонує меншу ціну, але не може доставити товар протягом трьох тижнів.

00:05:36.740 --> 00:05:39.320
Інший коштує трохи дорожче, але може все доставити вже наступного вівторка.

00:05:39.460 --> 00:05:41.580
Покупець може порівняти ці відповіді перед вибором.

00:05:41.700 --> 00:05:43.760
Ціна має значення, але це не єдиний фактор.

00:05:43.760 --> 00:05:49.020
Дати доставки, деталі продукту, знижки та здатність постачальника виконати запит – усе це впливає на вибір.

00:05:49.160 --> 00:05:54.400
Система зберігає пропозиції, пов'язані із заявкою, замість того, щоб залишати порівняння в купі електронних листів.

00:05:54.400 --> 00:05:59.340
Перш ніж покупець зробить вибір, Dynamics 365 також зберігає записи про постачальників.

00:05:59.520 --> 00:06:06.100
Запис про постачальника містить дані компанії, необхідні для закупівель, такі як назва та інформація для ділових відносин.

00:06:06.100 --> 00:06:13.160
Каталоги постачальників можуть відображати товари, які вони пропонують, а постачальники можуть публікувати ці каталоги, щоб підтримувати інформацію в актуальному стані.

00:06:13.300 --> 00:06:16.500
Для суварішого контролю продукт може мати список затверджених постачальників.

00:06:16.640 --> 00:06:20.140
Це підказує покупцеві, яких постачальників компанія схвалила для цього продукту.

00:06:20.140 --> 00:06:24.900
Це спрямовує вибір і може зупинити людину від вибору постачальника, якого компанія ніколи не планувала використовувати.

00:06:25.100 --> 00:06:28.480
Деякі відносини з постачальниками також передбачають умови у згодженні заздалегідь.

00:06:28.480 --> 00:06:32.000
Угода про закупівлю фіксує довгострокові домовленості між компанією та постачальником.

00:06:32.160 --> 00:06:38.020
Компанія може зобов'язатися закупити певну кількість або витратити визначену суму за певний період, а постачальник погоджується на відповідні умови.

00:06:38.020 --> 00:06:42.320
Торговельні угоди фіксують ціни або знижки постачальника, що діють протягом певних дат.

00:06:42.320 --> 00:06:46.660
Отже, якщо постачальник засобів безпеки погодився на нижчу ціну на рукавички на наступні 6 місяців,

00:06:46.780 --> 00:06:51.300
Dynamics 365 може зберегти цю домовленість, замість того, щоб кожен покупець пам'ятав про неї.

00:06:51.560 --> 00:06:58.040
Угоди про знижки також можуть відстежувати випадки, коли постачальник повертає кошти після того, як компанія досягає певної суми або обсягу закупівлі.

00:06:58.040 --> 00:07:02.680
На цьому етапі компанія вже знає, що їй потрібно, хто може це поставити та які умови застосовуються.

00:07:02.820 --> 00:07:06.300
Пошук завершено, але постачальнику все ще потрібне офіційне замовлення.

00:07:06.440 --> 00:07:09.860
Третє – замовлення на закупівлю – це письмове зобов'язання компанії.

00:07:10.000 --> 00:07:12.340
Покупець обрав постачальника засобів безпеки.

00:07:12.480 --> 00:07:15.600
Тепер компанії потрібне замовлення на закупівлю, яке зазвичай називають ПІО.

00:07:15.760 --> 00:07:20.360
Замовлення на закупівлю – це офіційний документ, який повідомляє постачальнику, що саме компанія має намір придбати.

00:07:20.360 --> 00:07:26.540
У ньому зазначається постачальник, перелік товарів або послуг, кількість і узгоджена ціна, а також дата доставки та умови оплати.

00:07:26.720 --> 00:07:32.040
Для нашого складу в ПІО може бути вказано 20 шоломів, 10 коробок рукавичок і дата доставки на наступний вівторок.

00:07:32.140 --> 00:07:35.800
Це перетворює рішення про закупівлю на чіткий запис, з яким можуть працювати обидві сторони.

00:07:35.940 --> 00:07:41.780
Нікому не потрібно вгадувати, який саме тип рукавичок замовила компанія, скільки одиниць очікується або про яку ціну покупець домовився з постачальником.

00:07:41.780 --> 00:07:47.260
Замовлення на закупівлю може бути створене кількома способами. Найчастіше воно виникає на основі затвердженої заявки на закупівлю.

00:07:47.400 --> 00:07:52.380
Завідувач складу зробив запит на засоби безпеки, відповідальні особи затвердили його і відділ закупівель перетворює це на ПІО.

00:07:52.540 --> 00:07:54.980
Воно також може бути створене на основі угоди про закупівлю.

00:07:55.120 --> 00:08:02.080
Якщо компанія вже уклала довгострокову угоду з постачальником засобів безпеки, покупець може створити замовлення на відпуск товарів за цією угодою, замість того, щоб формувати кожну деталь з нуля.

00:08:02.080 --> 00:08:11.160
Іноді замовлення створюється через попит. Компанія може планувати закупівлю матеріалів через очікувані потреби виробництва, і Dynamics 365 може створювати планові замовлення на закупівлю на основі цього попиту.

00:08:11.320 --> 00:08:16.720
Коли компанія випускає планове замовлення, воно стає реальним замовленням на закупівлю. Також існують прямі закупівлі.

00:08:16.860 --> 00:08:21.920
Покупець може створити ПІО вручну, якщо для цього немає попередньої заявки, угоди або планового попиту.

00:08:22.100 --> 00:08:26.280
Це може статися, коли покупець уже знає, що потрібно компанії та який постачальник це надасть.

00:08:26.280 --> 00:08:32.560
Різні початкові точки – один і той самий результат. Перш ніж замовлення на закупівлю піде в роботу, компанія може вимагати його затвердження.

00:08:32.720 --> 00:08:38.800
Покупець готує замовлення, але воно може потребувати внутрішнього погодження згідно з правилами компанії щодо автоматичних сум, перш ніж потрапить до постачальника.

00:08:38.960 --> 00:08:46.820
Це розмежовує два рішення. Спочатку компанія схвалює власні зобов'язання, а потім підтверджує замовлення постачальнику, засвідчуючи згоду обох сторон щодо подальших дій.

00:08:46.820 --> 00:08:54.420
Підтверджене замовлення на закупівлю – це більше, ніж просто внутрішня нотатка. Воно фіксує, що замовлення отримане постачальником і між сторонами існує домовленість про купівлю.

00:08:54.580 --> 00:09:00.540
Dynamics 365 також звільняє покупців від необхідності щоразу вводити одну і ту саму інформацію при замовленні у звичного постачальника.

00:09:00.720 --> 00:09:05.700
Запис про постачальника може містити такі деталі, як інформація про доставку, умови оплати та інші звичайні налаштування.

00:09:05.700 --> 00:09:11.240
Покупець все одно перевіряє замовлення і може змінити деталі, якщо того вимагає ситуація, але стандартні дані вже на місці.

00:09:11.380 --> 00:09:14.780
Це зменшує обсяг введення даних і забезпечує більшу узгодженість повторних замовлень.

00:09:14.940 --> 00:09:17.580
Доставка не завжди відбувається однією посилкою в один день.

00:09:17.740 --> 00:09:21.120
Уявіть, що у постачальника є всі рукавички, але готові лише половина шоломів.

00:09:21.260 --> 00:09:25.800
Графік доставки дозволяє компанії розділити одне замовлення на закупівлю на заплановані постачання в різні дні.

00:09:25.800 --> 00:09:32.120
У замовленні можна вказати, що 10 шоломів прибудуть наступного вівторка, решта 10 – через тиждень, а рукавички надійдуть з першою партією.

00:09:32.260 --> 00:09:36.420
Одне замовлення залишається єдиним цілим, тоді як план доставки відповідає реальним можливостям.

00:09:36.620 --> 00:09:39.440
Деякі товари ніколи не потрапляють безпосередньо до компанії.

00:09:39.600 --> 00:09:44.440
Пряма доставка означає, що постачальник відправляє товар безпосередньо клієнту компанії.

00:09:44.640 --> 00:09:48.660
Наприклад, бізнес продає спеціалізований товар, якого немає на власному складі.

00:09:48.660 --> 00:09:53.100
Він може створити замовлення на продаж для клієнта і відповідне замовлення на закупівлю для постачальника.

00:09:53.260 --> 00:09:59.900
Постачальник відправляє товар безпосередньо клієнту, а Dynamics 365 автоматично пов'язує відповідні етапи продажу та закупівлі.

00:10:00.040 --> 00:10:06.060
Це дозволяє уникнути зайвої зупинки на складі компанії та пов'язує замовлення клієнта із замовленням постачальника,

00:10:06.220 --> 00:10:08.900
щоб можна було відстежити товар з обох боків угоди.

00:10:09.060 --> 00:10:11.720
Замовлення на закупівлю може містити не лише основний товар.

00:10:11.900 --> 00:10:13.920
Деякі продукти потребують супутніх товарів.

00:10:13.920 --> 00:10:18.100
Коли компанія замовляє шоломи, їй також можуть знадобитися змінні візори або кріплення.

00:10:18.260 --> 00:10:24.700
Dynamics 365 може запропонувати додаткові товари, які можуть бути обов'язковими, опціональними або включеними без додаткової плати.

00:10:24.860 --> 00:10:29.660
Покупець бачить супутні потреби ще під час формування замовлення, а не дізнається про них після отримання основної партії.

00:10:29.820 --> 00:10:31.460
Крім того, існують додаткові витрати.

00:10:31.660 --> 00:10:35.120
Витрати на фракт, обробку та інші подібні нарахування також можна додати до замовлення на закупівлю.

00:10:35.120 --> 00:10:40.040
Нарахування може стосуватися всього замовлення або окремого рядка замовлення, залежно від того, як компанії потрібно це відобразити.

00:10:40.180 --> 00:10:44.900
Це важливо, оскільки низька ціна товару не відображає повну вартість, якщо доставка додає значну плату.

00:10:45.120 --> 00:10:50.540
Запис витрат разом із замовленням пов'язує цю вартість із купівлею, замість того, щоб залишати її в окремому документи.

00:10:50.700 --> 00:10:54.960
Тепер постачальник має підтверджене замовлення з чіткими позиціями, цінами, датами та умовами.

00:10:55.120 --> 00:10:58.620
Але підтверджене замовлення лише фіксує те, що компанія очікує отримати.

00:10:58.620 --> 00:11:03.700
Dynamics 365 все одно потребує підтвердження того, що товари чи послуги фактично надійшли.

00:11:04.240 --> 00:11:07.380
Четверте – отримання товарів та перевірка рахунка фактури.

00:11:07.540 --> 00:11:10.440
Вантажівка під'їжджає до складу з шоломами та рукавичками.

00:11:10.620 --> 00:11:15.200
Перш ніж хтось позначить замовлення як виконане, складська команда має перевірити, що саме прибуло.

00:11:15.380 --> 00:11:20.780
Вони реєструють прибуття, порівнюють поставку із замовленням на закупівлю та проводять надходження товарів за цим замовленням.

00:11:20.900 --> 00:11:24.660
Надходження товарів – це просто спосіб для системи зафіксувати, що товари прибули.

00:11:24.660 --> 00:11:26.060
Ось десятьох одиниць.

00:11:26.060 --> 00:11:32.000
У замовленні зазначено 20 шоломів та 10 коробок рукавичок, але водій привозить лише 10 шоломів та всі 10 коробок рукавичок.

00:11:32.120 --> 00:11:35.700
Склад фіксує те, що фактично отримав, а не те, що компанія сподівалася отримати.

00:11:35.860 --> 00:11:40.560
Решта 10 шоломів залишаються відкритими у замовленні на закупівлю, доки постачальник їх не доставить або покупець не змінить замовлення.

00:11:40.680 --> 00:11:42.200
Це забезпечує точність обліку.

00:11:42.380 --> 00:11:45.380
Після того, як надходження товарів проведено, замовлення на закупівлю змінюється.

00:11:45.380 --> 00:11:52.640
Система тепер розділяє замовлену кількість та отриману, тому покупці, складський персонал та фінансовий відділ бачать статус замовлення, не телефонуючи один одному.

00:11:52.840 --> 00:11:55.660
Для складських позицій отримання також оновлює запаси.

00:11:55.800 --> 00:11:59.800
Рукавички з'являються як доступний запас, готовий до використання командою складу.

00:11:59.940 --> 00:12:07.780
Якщо товари належать до певного проєкту, основного засобу або прямої поставки, Dynamics 365 може записати закупівлю на відповідне призначення.

00:12:07.780 --> 00:12:10.880
Компанія знає більше, ніж просто те, як ми купили рукавички.

00:12:11.040 --> 00:12:14.840
Вона знає, чи прибули рукавички, скільки їх надійшло і куди вони мають потрапити.

00:12:15.000 --> 00:12:17.740
Проте не кожна закупівля потрапляє на вантажну платформу.

00:12:17.860 --> 00:12:23.180
Уявіть, що компанія наймає інструктора з техніки безпеки на день, оплачує доступ до ПЕЗе або запрошує зовнішню ремонтну службу.

00:12:23.300 --> 00:12:27.400
Тут немає фізичних товарів, немає піддонів для підрахунку та немає надходження на склад для реєстрації.

00:12:27.600 --> 00:12:31.480
Для послуг та інших нематеріальних закупівель компанія може обрати простіший шлях.

00:12:31.480 --> 00:12:38.680
Залежно від налаштувань закупівлі, вона може зареєструвати отримання в замовленні без складського етапу або перейти одразу до рахунка постачальника.

00:12:38.860 --> 00:12:40.780
Тут застосовується те саме питання.

00:12:40.960 --> 00:12:43.620
Чи отримала компанія те, що вона погодилася купити?

00:12:43.820 --> 00:12:47.100
Для навчальної послуги відповіддю може бути те, що навчання відбулося.

00:12:47.300 --> 00:12:49.660
Для ремонту хтось підтверджує, що роботу завершено.

00:12:49.840 --> 00:12:53.420
Запис не потребує коробки чи штрих-коду, щоб підтвердити, що компанія щось отримала.

00:12:53.540 --> 00:12:55.460
Потім надходить рахунок від постачальника.

00:12:55.460 --> 00:13:02.360
Рахунок потрапляє до кредиторської заборгованості частини Dynamics 365, яка фіксує борги компанії перед постачальниками та готує платежі.

00:13:02.480 --> 00:13:07.940
Рахунок пов'язується із замовленням на купівлю, тому кредиторська заборгованість не розглядає його як ізольований рахунок без історії.

00:13:08.120 --> 00:13:10.820
Саме тут проста перевірка допомагає уникнути багатьох проблем.

00:13:11.020 --> 00:13:16.120
Dynamics 365 порівнює три речі, що компанія замовила, що отримала і що виставив постачальник.

00:13:16.220 --> 00:13:17.440
Це називають звіренням.

00:13:17.540 --> 00:13:19.840
Простою мовою, чи збігається рахунок із домовленостями?

00:13:19.840 --> 00:13:22.800
У замовленні на купівлю може бути вказано 20 шоломів за узгодженою ціною.

00:13:22.940 --> 00:13:26.080
У квитанції про отримання товару може бути зазначено, що поки що прибуло лише 10 шоломів.

00:13:26.200 --> 00:13:30.720
Якщо постачальник надсилає рахунок на 20 одиниць, система може показати різницю до того, як компанія здійснить оплату.

00:13:30.860 --> 00:13:32.700
Це автоматизує тристоронні звірення.

00:13:32.860 --> 00:13:36.760
Цими трьома записами є замовлення на купівлю, квитанція про отримання товару та рахунок фактура.

00:13:36.900 --> 00:13:40.220
Коли вони збігаються, кредиторська заборгованість має чіткий шлях для подальших дій.

00:13:40.220 --> 00:13:46.760
Якщо ціна відрізняється, кількість у рахунку перевищує отримано або з'являється рядок, який ніхто не замовляв, компанія може зупинитися і з'ясувати причину.

00:13:46.900 --> 00:13:49.020
Можливо, постачальник надіслав рахунок завчасно.

00:13:49.140 --> 00:13:52.360
Можливо, витрати на перевезення виділені окремою сумою, яку покупцю варто перевірити.

00:13:52.520 --> 00:13:54.820
Можливо, постачальник просто помилився в кількості.

00:13:54.960 --> 00:13:56.780
Мета – не припускати злого наміру.

00:13:56.960 --> 00:14:03.080
Система автоматично виявляє розбіжності, поки компанія може поставити запитання, а не після того, як гроші пішли з банку.

00:14:03.080 --> 00:14:07.160
Кожен рахунок також має знайти своє місце у фінансових записах компанії.

00:14:07.320 --> 00:14:09.860
Це автоматизує завдання бухгалтерських розподілів.

00:14:10.020 --> 00:14:13.120
Вони підказують Dynamics 365, як саме відобразити витрати.

00:14:13.280 --> 00:14:16.080
Захисні рукавиці можуть належати до операційних витрат складу.

00:14:16.240 --> 00:14:19.020
Новий навантажувач може належати до рахунку основних засобів.

00:14:19.200 --> 00:14:22.360
Витрати на проектну закупівлю мають бути записані на відповідний проект.

00:14:22.540 --> 00:14:25.280
Один рахунок можна навіть розподілити між кількома місцями.

00:14:25.280 --> 00:14:31.120
Наприклад, якщо дві складські команди ділять замовлення на рукавиці, компанія може розділити вартість між їхніми відділами.

00:14:31.260 --> 00:14:36.540
Фінансовий відділ зможе побачити, куди пішли кошти, не намагаючись згодом відновити картину за нечітким описом у рахунку.

00:14:36.680 --> 00:14:40.800
Після того, як рахунок пройшов звіряння і всі необхідні перевірки завершено, він може пройти процес затвердження.

00:14:40.940 --> 00:14:44.400
Проведення рахунку записує суму боргу компанії перед постачальником у кредиторській заборгованості.

00:14:44.540 --> 00:14:46.260
Рахунок тепер є заборгованістю до сплати.

00:14:46.260 --> 00:14:48.740
Умови оплати допомагають визначити термін її виконання.

00:14:48.880 --> 00:14:52.980
Відділ кредиторської заборгованості готує рахунки до оплати, і як тільки компанія проводить платіж,

00:14:53.100 --> 00:14:56.260
Dynamics 365 закриває баланс постачальника за цим рахунком.

00:14:56.420 --> 00:15:00.480
Замовлення пройшло шлях від очікуваної доставки до відображених витрат та здійсненої оплати.

00:15:00.640 --> 00:15:03.200
Але цей ланцюжок робить значно більше, ніж просто оплачує один рахунок.

00:15:03.320 --> 00:15:07.280
Це надає компанії зручний запис кожного рішення та кожної передачі, пов'язаної з цією закупівлею.

00:15:07.280 --> 00:15:10.320
5. Контроль видимості та кращі рішення щодо постачальників.

00:15:10.420 --> 00:15:15.040
Єдиний запис про закупівлю також дозволяє компанії контролювати витрати до того, як проблема дійде до фінансового відділу.

00:15:15.160 --> 00:15:17.360
Політика закупівель встановлює основні правила.

00:15:17.580 --> 00:15:21.960
Вона визначає, що працівники можуть замовляти, яких постачальників використовувати та коли закупівля потребує схвалення,

00:15:22.040 --> 00:15:23.340
перш ніж витрачати кошти компанії.

00:15:23.460 --> 00:15:25.340
Подумайте про запит на засоби безпеки.

00:15:25.480 --> 00:15:28.620
Компанія може вимагати від персоналу складу вибирати лише схвалені засоби безпеки,

00:15:28.620 --> 00:15:31.140
тоді як лише відділ закупівель може обрати нового постачальника.

00:15:31.280 --> 00:15:34.140
Невелике замовлення на заміну може потребувати одного схвалення,

00:15:34.240 --> 00:15:38.080
а велике замовлення для нового відділу – власника бюджету та менеджера із закупівель.

00:15:38.200 --> 00:15:40.020
Правила закладені в сам процес.

00:15:40.200 --> 00:15:44.120
Людям не потрібно шукати документи з політикою, вгадувати, хто має щось схвалити,

00:15:44.220 --> 00:15:46.560
або пересилати листи, очікуючи на відповідь.

00:15:46.560 --> 00:15:52.960
Dynamics 365 може спрямовувати запит залежно від відділу, суми, типу закупівлі або застосованої політики.

00:15:53.120 --> 00:15:55.280
Цей маршрут називається робочим процесом.

00:15:55.280 --> 00:16:00.620
Робочий процес забезпечує чіткий шлях для запитів, замовлень на купівлю та рахунків від однієї людини до іншої.

00:16:00.800 --> 00:16:05.760
Кожен може схвалити, відхилити або повернути запис на доопрацювання, а система фіксує цю дію.

00:16:05.940 --> 00:16:09.480
Більше не потрібно гадати, чи було отримано схвалення у довгому ланцюжку електронних листів.

00:16:09.620 --> 00:16:11.900
Це також допомагає, коли хтось відсутній на робочому місці.

00:16:11.900 --> 00:16:16.240
Робота не зникає в папці, вхідні, аутлук цієї особи без жодних слідів того, де вона зупинилася.

00:16:16.240 --> 00:16:18.940
Компанія бачить поточний етап і може на нього вплинути.

00:16:19.060 --> 00:16:22.620
Постачальники також можуть брати участь, якщо компанія використовує портал постачальників.

00:16:22.740 --> 00:16:27.400
Портал постачальників надає місце для перегляду запитів на комерційну пропозицію або надісланих їм замовлень.

00:16:27.580 --> 00:16:33.220
Вони можуть відповідати на запити та підтверджувати замовлення безпосередньо, коли компанія надсилає запит на підтвердження.

00:16:33.220 --> 00:16:36.220
Це надає обом сторонам однаковий документ для роботи.

00:16:36.220 --> 00:16:43.640
Замість того, щоб надсилати PDF, чекати відповіді, а потім вводити її в систему, постачальник може підтвердити деталі через єдиний процес.

00:16:43.760 --> 00:16:46.760
Покупець бачить відповідь, не переробляючи запис вручну.

00:16:46.920 --> 00:16:52.680
Коли закупівлі проходять через систему, компанія також збирає корисну інформацію без створення зайвих таблиць.

00:16:52.680 --> 00:16:56.080
Аналіз витрат відповідає на просте питання, куди йдуть гроші.

00:16:56.240 --> 00:17:01.240
Менеджер із закупівель може переглядати витрати за постачальником, продуктом, категорією закупівлі чи відділом.

00:17:01.240 --> 00:17:07.200
Можливо, компанія вважає, що купує рукавички в одного постачальника, але записи показують, що різні команди купують схожі рукавички у різних постачальників.

00:17:07.320 --> 00:17:10.520
Можливо, якийсь відділ витрачає на зовнішній ремонт більше, ніж очікувалося.

00:17:10.680 --> 00:17:14.320
Ці деталі дають компанії підставу ставити кращі питання перед наступною закупівлею.

00:17:14.480 --> 00:17:17.760
Аналіз ефективності постачальника розглядає цю ж історію з боку постачальника.

00:17:17.760 --> 00:17:22.220
Покупці можуть порівняти результати закупівель і доставки, коли вирішують, хто отримає майбутнє замовлення.

00:17:22.220 --> 00:17:28.920
Низька ціна на папері може виглядати не так привабливо, якщо постачальник постійно затримує доставку, відправляє неповні замовлення або не може виконати узгоджені умови.

00:17:29.020 --> 00:17:32.720
Компанія може використовувати власні записи про закупівлі під час перегляду відносин із постачальником.

00:17:32.900 --> 00:17:34.500
Потім з'являється аудиторський слід.

00:17:34.640 --> 00:17:37.640
Аудиторський слід дозволяє відстежити закупівлю протягом усієї її історії.

00:17:37.640 --> 00:17:44.160
Можна почати з початкового запиту, побачити, хто його схвалив, переглянути замовлення на купівлю, перевірити квитанцію, знайти рахунок фактуру та побачити платіж, що його закрив.

00:17:44.280 --> 00:17:48.920
Цей запис допомагає фінансовим та аудиторським групам, але він також допомагає звичайним працівникам відповідати на звичайні запитання.

00:17:49.060 --> 00:17:54.240
Чому ми це купили? Хто обрав цього постачальника? Чи надійшов товар? Чи вже оплачено рахунок фактуру?

00:17:54.400 --> 00:17:56.140
Відповідь міститься в записі про закупівлю.

00:17:56.280 --> 00:17:58.560
Повернімося до офісної будівлі, з якої ми починали.

00:17:58.560 --> 00:18:07.260
Відділ закупівель, приймальний док і фінансовий відділ мають різні завдання, але всі вони розглядають частини однієї і тієї ж закупівлі, замість того, щоб передавати папери між окремими кімнатами.

00:18:08.060 --> 00:18:12.840
Наш менеджер складу, наш ТМС, запит на шоломи та рукавички тепер має повну історію.

00:18:13.040 --> 00:18:14.980
Запит відповідав політиці компанії.

00:18:15.140 --> 00:18:16.660
Потрібні люди його схвалили.

00:18:16.860 --> 00:18:18.320
Постачальник надав обладнання.

00:18:18.480 --> 00:18:20.360
Персонал складу зареєстрував доставку.

00:18:20.560 --> 00:18:23.280
Відділ розрахунків із кредиторами зіставив рахунок фактуру та оплатив його.

00:18:23.280 --> 00:18:26.360
Одна проста відмінність робить усі ці складові елементи зрозумілими.

00:18:26.480 --> 00:18:32.980
Пошук джерел постачання допомагає компанії вибрати, у кого купувати, тоді як закупівлі керують тим, що відбувається після того, як компанія вирішила купити.

00:18:33.240 --> 00:18:36.200
Висновок. Один пов'язаний запис від ініціації до оплати.

00:18:36.380 --> 00:18:37.380
Ось повна картина.

00:18:37.540 --> 00:18:42.100
Закупівлі та пошук джерел постачання перетворюють усі ці розрізнені етапи на один відстежуваний процес компанії.

00:18:42.100 --> 00:18:48.980
Запит не зникає в папці, вхідні, схвалення не залишається лише в чиїсь пам'яті, а рахунок фактура не надходить без чіткого зв'язку з рішенням, що стоїть за ним.

00:18:49.140 --> 00:18:52.860
Натомість компанія має один пов'язаний запис, який відстежує закупівлю від початку до кінця.

00:18:53.000 --> 00:18:55.060
Це дає вам чітку відповідь, коли вона вам потрібна.

00:18:55.180 --> 00:18:56.780
Як покупець, ви бачите замовлення.

00:18:56.960 --> 00:18:58.420
Склад бачить, що очікується.

00:18:58.580 --> 00:19:00.540
Фінансовий відділ знає, що компанія винна.

00:19:00.640 --> 00:19:02.580
А менеджери бачать, куди саме йдуть витрати.

00:19:02.580 --> 00:19:06.160
Закупівлі все ще включають людей, постачальників, товари, послуги та рішення.

00:19:06.360 --> 00:19:08.580
Dynamics 365 не усуває ці речі.

00:19:08.740 --> 00:19:12.800
Система зберігає їхні записи разом, тому ви можете здійснювати закупівлі з меншою кількістю незавершених справ і несподівано.

00:19:12.900 --> 00:19:15.800
Підписуйтесь на вашій улюбленій подкаст-платформі та поділіться цим корисним досвідом з тими,

00:19:15.800 --> 00:19:19.020
хто починає вивчати модуль «Закупівлі та джерела постачання» в Dynamics 365.