WEBVTT

00:00:00.000 --> 00:00:03.860
Что происходит, когда кому-то на работе нужен новый ноутбук, сырье для производства или

00:00:03.860 --> 00:00:07.780
клининговые услуги? Во многих компаниях раньше это означало электронные письма, таблицы,

00:00:07.940 --> 00:00:11.680
бумажные формы и попытки отыскать счет спустя несколько недель. Добро пожаловать в очередной

00:00:11.680 --> 00:00:16.800
выпуск «Полезных знаний» от Microsoft на M365FM. Я Мирко Питерс, и сегодня мы рассмотрим

00:00:16.800 --> 00:00:20.840
закупки и снабжения, единый процесс, который компания использует для приобретения товаров и

00:00:20.840 --> 00:00:24.960
услуг у поставщиков. Представьте себе это как стойку администратора в офисном здании. Каждый

00:00:24.960 --> 00:00:30.260
запрос, согласование, заказ, доставка, счет и платеж проходят через одно место. Мы проследим

00:00:30.260 --> 00:00:34.840
за одной закупкой, от первого запроса до механизмов контроля, работающих за кулисами.

00:00:35.020 --> 00:00:39.760
Во-первых, что именно охватывают закупки и снабжения? Закупки и снабжения могут звучать как

00:00:39.760 --> 00:00:44.020
слишком сложное название для покупки вещей, и хотя речь идет о покупках, эти два слова описывают

00:00:44.020 --> 00:00:48.420
разные задачи. Снабжение – это работа по поиску и выбору подходящего поставщика. Представьте

00:00:48.420 --> 00:00:53.160
компанию, которой нужны перчатки, каски, знаки безопасности и защитные очки. Прежде чем кто-либо

00:00:53.160 --> 00:00:57.060
сделает заказ, нужно решить, кто может поставить нужные товары по приемлемой цене,

00:00:57.240 --> 00:01:01.920
к нужному сроку и на приемлемых для компании условиях. Это и есть снабжение. Закупки начинаются,

00:01:02.100 --> 00:01:06.420
когда компании нужно управлять самим процессом приобретения. Они включают запрос, согласование,

00:01:06.660 --> 00:01:11.980
заказ на поставку, доставку, счет и оплату. Вместе этот процесс называется «от поиска до оплаты».

00:01:11.980 --> 00:01:17.440
Название описывает весь путь. Бизнес определяет потребность, выбирает поставщика, отправляет заказ,

00:01:17.620 --> 00:01:22.920
получает товар или услугу, получает счет, а затем финансовый отдел оплачивает его. Каждый шаг связан

00:01:22.920 --> 00:01:27.720
с последующим. Можно подумать, что это очевидно, но многие компании до сих пор выполняют эти шаги

00:01:27.720 --> 00:01:32.820
разрозненно. Сотрудник отправляет запрос по почте, менеджер одобряет его в чате, закупщик хранит

00:01:32.820 --> 00:01:37.800
детали заказа в таблице, склад проверяет бумажную накладную, а бухгалтерия получает счет без явной

00:01:37.800 --> 00:01:42.220
связи с заказом. Люди все еще могут покупать товары таким образом, но они теряют нить процесса.

00:01:42.360 --> 00:01:46.680
Закупщик не может знать, что на склад уже поступила часть заказа. Финансовый отдел может случайно

00:01:46.680 --> 00:01:51.000
оплатить один и тот же счет дважды, если он придет по разным каналам. Руководители узнают о расходах

00:01:51.000 --> 00:01:55.720
только после того, как деньги ушли из компании. Когда кто-то спрашивает, кто это одобрил? Ответ

00:01:55.720 --> 00:02:01.140
требует долгих поисков по почтовым ящикам. Dynamics 365 объединяет всю эту цепочку в единую

00:02:01.140 --> 00:02:06.420
платформу. Закупки и снабжения в Dynamics 365 Supply Chain Management позволяют компании управлять

00:02:06.420 --> 00:02:10.380
движением и наличием товаров, а также интегрироваться с финансовым отделом и кредиторской

00:02:10.380 --> 00:02:14.280
задолженностью для регистрации счетов, отслеживания обязательств и обработки платежей.

00:02:14.380 --> 00:02:18.280
Таким образом, отдел закупок не работает изолированно. Склад может зарегистрировать

00:02:18.280 --> 00:02:22.600
поступление товаров. Финансовый отдел увидит счет, связанный с этой закупкой, а бухгалтерия

00:02:22.600 --> 00:02:26.760
по расчетам с поставщиками сверит заказанное с полученным и счетами от поставщика. Каждый отдел

00:02:26.760 --> 00:02:30.860
видит только нужную ему часть, в то время как закупка остается единой связанной записью.

00:02:31.080 --> 00:02:35.280
Существует два типа закупок. Прямые закупки охватывают товары или услуги, связанные с тем,

00:02:35.440 --> 00:02:39.860
что компания производит или продает. Производитель мебели, покупающий древесину, шурупы и ткань,

00:02:39.900 --> 00:02:44.000
приобретает прямые материалы. Без этих материалов он не сможет изготовить продукт, который продает.

00:02:44.000 --> 00:02:47.760
Косвенные закупки охватывают то, что поддерживает работу бизнеса, но не становится частью

00:02:48.280 --> 00:02:52.300
товара, ноутбуки, офисную мебель, обучение, ремонт, уборку, программное обеспечение или

00:02:52.300 --> 00:02:56.840
юридические услуги. Оба типа важны, но они часто начинаются по-разному. Производственная потребность

00:02:56.840 --> 00:03:00.860
может подсказать компании, что ей нужно больше деталей. Сотрудник может запросить новый монитор.

00:03:01.060 --> 00:03:05.400
Администратору объекта может потребоваться ремонтная услуга. Dynamics 365 справляется со всеми

00:03:05.400 --> 00:03:09.040
этими задачами, сохраняя при этом прозрачный путь закупки. Давайте будем использовать один простой

00:03:09.040 --> 00:03:13.000
пример на протяжении этого эпизода. Представьте, что менеджер склада замечает, что команде нужно

00:03:13.000 --> 00:03:17.240
новое защитное снаряжение. Некоторые шлемы повреждены, запас защитных перчаток на исходе.

00:03:17.380 --> 00:03:20.760
Менеджеру нужно достаточно оборудования для команды, а компании – четкий учет до того,

00:03:20.880 --> 00:03:24.760
как будут выделены средства. Такая закупка начинается с потребности, и каждая контролируемая

00:03:24.760 --> 00:03:29.640
закупка начинается с того, что кто-то что-то просит. 2. От внутреннего запроса к нужному поставщику.

00:03:30.120 --> 00:03:34.180
Вот как начинается весь процесс закупки. Ваш менеджер склада видит потребность в защитном

00:03:34.180 --> 00:03:38.640
снаряжении, и первой записью, созданной в Dynamics 365, является заявка на закупку.

00:03:38.640 --> 00:03:43.000
Заявка на закупку – это внутренний запрос на приобретение чего-либо. Она сообщает компании,

00:03:43.240 --> 00:03:47.260
что нужно человеку, в каком количестве и часто, куда это доставить. Обратите внимание,

00:03:47.560 --> 00:03:51.840
что этот запрос еще ничего не обещает поставщику. Это различие позволяет компании сохранять

00:03:51.840 --> 00:03:56.260
контроль над начальным этапом закупки. Менеджер склада может запросить 20 шлемов и несколько

00:03:56.260 --> 00:04:00.580
коробок перчаток, но ни один поставщик не получит заказ, пока его не одобрят нужные люди.

00:04:00.780 --> 00:04:04.700
Для стандартных закупок запрос может начинаться с каталога товаров. Представьте каталог,

00:04:04.700 --> 00:04:08.620
как утвержденную витрину вашей компании. Вместо того, чтобы вводить расплывчатый

00:04:08.640 --> 00:04:12.640
запрос типа «защитные перчатки» сотрудник может выбрать утвержденный товар с уже известным

00:04:12.640 --> 00:04:16.880
описанием, вариантом поставщика и ценой. Это экономит время, а также не дает людям покупать

00:04:16.880 --> 00:04:20.900
случайные товары, которые не соответствуют правилам компании. Однако не каждый запрос можно

00:04:20.900 --> 00:04:24.680
включить в каталог. Компании может потребоваться разовый ремонт, обучение от консультантов или

00:04:24.680 --> 00:04:29.320
услуга, которая не хранится как физический товар. В таком случае в Dynamics 365 можно использовать

00:04:29.320 --> 00:04:33.440
категорию закупок. Категория закупок группирует расходы по их типу. Например, компания может

00:04:33.440 --> 00:04:37.660
использовать такие категории, как средства безопасности, ремонт зданий, юридические услуги или компьютерное

00:04:37.660 --> 00:04:41.520
оборудование. Заявитель может описать нужный товар и отнести его к соответствующей категории,

00:04:41.680 --> 00:04:45.540
даже если для него нет артикула на складе. Конечно, запрос не должен превращаться в покупку

00:04:45.540 --> 00:04:49.040
просто потому, что кто-то нажал кнопку отправки. Компания может установить лимиты расходов,

00:04:49.160 --> 00:04:53.200
проверки бюджета и рабочие процессы утверждения. Небольшой запрос на перчатки может быть направлен

00:04:53.200 --> 00:04:57.100
менеджеру склада. Более крупный запрос на средства безопасности может потребовать одобрения от

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

00:05:01.180 --> 00:05:04.760
департамента или правила закупок, привязанного к данному типу расходов. Это означает,

00:05:04.760 --> 00:05:10.460
что сотрудникам не нужно самостоятельно запоминать все правила утверждения. Dynamics 365 направляет

00:05:10.460 --> 00:05:15.440
запрос по нужному пути, сохраняя при этом его историю в системе. Предположим, менеджер запрашивает

00:05:15.440 --> 00:05:19.500
большое количество оборудования, а компания еще не знает, какому поставщику отдать заказ.

00:05:19.640 --> 00:05:24.040
Отдел закупок может создать запрос котировок, который часто называют RFQ. RFQ предлагает

00:05:24.040 --> 00:05:27.760
нескольким поставщикам сделать заявку на одну и ту же потребность. Покупатель отправляет требования,

00:05:28.000 --> 00:05:32.020
такие как тип касок, размер перчаток, количество и желаемая дата доставки. Каждый поставщик

00:05:32.020 --> 00:05:35.420
может предложить свою цену и условия. Может быть, один поставщик берет меньше, но не может

00:05:35.420 --> 00:05:38.680
доставить товар в течение трех недель. Другой стоит немного дороже, но может поставить все уже

00:05:38.680 --> 00:05:41.680
в следующий вторник. Покупатель может сравнить эти ответы перед принятием решения.

00:05:41.840 --> 00:05:46.540
Цена важна, но это не единственный фактор. Сроки доставки, детали продукта, скидки и способность

00:05:46.540 --> 00:05:50.400
самого поставщика выполнить запрос – все это влияет на выбор. Система хранит заявки,

00:05:50.580 --> 00:05:54.380
привязанные к запросу, вместо того, чтобы оставлять сравнение в цепочке электронных писем.

00:05:54.520 --> 00:05:59.240
Прежде чем покупатель сделает выбор, Dynamics 365 также ведет учет записи поставщиков.

00:05:59.240 --> 00:06:03.000
Запись о поставщике содержит данные компании, необходимые для закупок,

00:06:03.220 --> 00:06:07.460
такие как название поставщика и информация для деловых отношений. Каталоги поставщиков

00:06:07.460 --> 00:06:11.680
могут отображать поставляемую ими продукцию, а сами поставщики могут публиковать эти каталоги

00:06:11.680 --> 00:06:15.220
для поддержания актуальности данных. Для более строгого контроля у продукта может быть

00:06:15.220 --> 00:06:19.040
список утвержденных поставщиков. Он подсказывает покупателю, каких поставщиков компания

00:06:19.040 --> 00:06:22.720
одобрила для данного товара. Это направляет выбор и может предотвратить ситуацию, когда кто-то

00:06:22.720 --> 00:06:26.500
выбирает поставщика, с которым компания не планировала работать. Некоторые отношения с поставщиками

00:06:26.500 --> 00:06:30.480
также включают условия, согласованные заранее. Соглашение о закупках фиксирует долгосрочную

00:06:30.480 --> 00:06:34.200
сделку между компанией и поставщиком. Компания может обязаться закупить определенное количество

00:06:34.200 --> 00:06:37.640
или потратить определенную сумму за период, а поставщик соглашается на соответствующие

00:06:37.640 --> 00:06:42.120
условия. Торговые соглашения фиксируют цены или скидки поставщиков, действующие в определенные

00:06:42.120 --> 00:06:45.880
сроки. Поэтому, если поставщик защитного оборудования согласился снизить цену на перчатки

00:06:45.880 --> 00:06:50.280
на следующие 6 месяцев, Dynamics 365 сохранит эту договоренность, вместо того, чтобы полагаться

00:06:50.280 --> 00:06:53.660
на память каждого закупщика. Соглашения о скидках также позволяют отслеживать случай,

00:06:53.660 --> 00:06:57.500
когда поставщик возвращает часть средств после того, как компания достигает определенного объема

00:06:57.500 --> 00:07:01.840
или суммы закупок. К этому моменту компания уже знает, что ей нужно, кто может это поставить

00:07:01.840 --> 00:07:06.260
и на каких условиях. Поиск завершен, но поставщику все еще нужен официальный заказ.

00:07:06.400 --> 00:07:10.900
Третье. Заказ на закупку – письменное обязательство компании. Закупщик уже выбрал

00:07:10.900 --> 00:07:15.340
поставщика защитного оборудования. Теперь компании нужен заказ на закупку, который обычно называют

00:07:15.340 --> 00:07:18.840
ПИО. Заказ на закупку – это официальный документ, который точно сообщает поставщику,

00:07:19.020 --> 00:07:23.300
что именно компания намерена приобрести. В нем указывается поставщик, перечисляются товары или услуги,

00:07:23.300 --> 00:07:26.740
количество и согласованная цена, а также дата доставки и условия оплаты.

00:07:26.840 --> 00:07:31.460
Для нашего склада в заказе могут быть указаны 20 шлемов, 10 коробок перчаток и дата доставки на

00:07:31.460 --> 00:07:35.340
следующий вторник. Он превращает решение о покупке в четкую запись, с которой могут работать

00:07:35.340 --> 00:07:39.340
обе стороны. Никому не нужно гадать, какой тип перчаток запросила компания, сколько единиц

00:07:39.340 --> 00:07:43.500
ожидается или какую цену закупщик согласовал с поставщиком. Заказ на закупку может быть создан

00:07:43.500 --> 00:07:47.260
несколькими способами. Чаще всего он создается на основе утвержденной заявки на закупку.

00:07:47.440 --> 00:07:50.820
Менеджер склада запросил защитное оборудование, ответственные лица одобрили этот запрос,

00:07:50.820 --> 00:07:54.620
а отдел закупок превращает его в заказ. Он также может быть создан на основе соглашения о

00:07:54.620 --> 00:07:58.120
закупках. Если компания уже заключила долгосрочную сделку с поставщиком оборудования,

00:07:58.260 --> 00:08:01.620
закупщик может создать заказ на выпуск по этому соглашению вместо того, чтобы вводить все

00:08:01.620 --> 00:08:05.520
детали с нуля. Иногда заказ создается на основе спроса. Компания может планировать закупку

00:08:05.520 --> 00:08:09.900
материалов, ожидая будущих производственных нужд, а Dynamics 365 может создавать плановые заказы

00:08:09.900 --> 00:08:13.980
на закупку, исходя из этого спроса. Когда компания выпускает плановый заказ, он становится реальным

00:08:13.980 --> 00:08:18.740
заказом на закупку. Кроме того, существуют прямые закупки. Закупщик может создать заказ вручную,

00:08:18.740 --> 00:08:22.980
если нет предварительной заявки, соглашения или планового спроса. Это может произойти,

00:08:23.180 --> 00:08:26.640
когда закупщик уже знает, что нужно компании и какой поставщик это обеспечит.

00:08:26.740 --> 00:08:30.720
Разные отправные точки – одна цель. Перед тем, как заказ на закупку вступит в силу,

00:08:30.900 --> 00:08:34.400
компания может потребовать его утверждения. Покупатель готовит заказ, но до отправки

00:08:34.400 --> 00:08:37.600
поставщику ему может потребоваться внутреннее согласование в соответствии с правилами

00:08:37.600 --> 00:08:41.880
компании по автоматическим суммам. Это разделяет два решения. Сначала компания подтверждает

00:08:41.880 --> 00:08:46.360
свои обязательства, затем согласовывает заказ с поставщиком, демонстрируя, что обе стороны пришли к

00:08:46.360 --> 00:08:50.440
соглашению. Подтвержденный заказ на закупку – это больше, чем просто внутренняя заметка. Он

00:08:50.440 --> 00:08:54.400
фиксирует, что заказ был получен поставщиком и что достигнуто соглашение о покупке.

00:08:54.580 --> 00:08:58.740
Dynamics 365 также избавляет покупателей от необходимости повторного ввода одной и той же

00:08:58.740 --> 00:09:02.600
информации при заказе у знакомого поставщика. Карточка поставщика может содержать такие детали,

00:09:02.740 --> 00:09:06.840
как информация о доставке, условия оплаты и другие стандартные настройки. Покупатель по-прежнему

00:09:06.840 --> 00:09:11.320
проверяет заказ и может изменить детали при необходимости, но стандартные данные уже на своих местах.

00:09:11.320 --> 00:09:14.840
Это сокращает объем ввода данных и делает повторные заказы более согласованными.

00:09:14.840 --> 00:09:18.020
Доставка не всегда происходит в одной коробке и в один день. Представьте,

00:09:18.160 --> 00:09:21.280
что у поставщика есть все перчатки прямо сейчас, но готовы только половина шлемов.

00:09:21.400 --> 00:09:25.020
График поставок позволяет компании разделить один заказ на закупку на несколько запланированных

00:09:25.020 --> 00:09:29.100
поставок в разные даты. В заказе можно указать, что 10 шлемов прибудут в следующий вторник,

00:09:29.280 --> 00:09:34.120
оставшиеся 10 – через неделю, а перчатки прибудут с первой партией. Один заказ остается целостным,

00:09:34.360 --> 00:09:39.240
при этом план поставок соответствует реальности. Некоторые закупки вообще не поступают в компанию.

00:09:39.240 --> 00:09:44.800
Прямая доставка означает, что поставщик отправляет товар на прямую клиенту компании. Например,

00:09:45.080 --> 00:09:49.360
компания продает специализированный товар, но не хранит его на собственном складе. Она может

00:09:49.360 --> 00:09:53.100
создать заказ на продажу для клиента и связанный с ним заказ на закупку у поставщика.

00:09:53.240 --> 00:09:58.840
Поставщик отправляет товар на прямую клиенту, а Dynamics 365 автоматически связывает соответствующие

00:09:58.840 --> 00:10:04.800
этапы продаж и закупок. Это исключает ненужную остановку на складе компании и связывает заказ клиента

00:10:04.800 --> 00:10:10.220
с заказом поставщика, позволяя отслеживать товар с обеих сторон сделки. Заказ на закупку может

00:10:10.220 --> 00:10:14.600
включать не только основной товар. Некоторые продукты требуют сопутствующих товаров. При заказе

00:10:14.600 --> 00:10:20.060
шлема в компании могут понадобиться сменные визоры или детали для крепления. Dynamics 365 может

00:10:20.060 --> 00:10:24.640
предлагать дополнительные товары, которые могут быть обязательными, опциональными или бесплатными.

00:10:24.780 --> 00:10:28.580
Покупатель видит сопутствующую потребность при формировании заказа, а не обнаруживает ее после

00:10:28.580 --> 00:10:32.360
прибытия основной поставки. Затем существуют дополнительные расходы. Стоимость доставки,

00:10:32.360 --> 00:10:35.920
обработки и аналогичные расходы также могут быть включены в заказ на закупку. Начисление может

00:10:35.920 --> 00:10:39.640
относиться ко всему заказу или к отдельной строке заказа, в зависимости от того, как компании нужно

00:10:39.640 --> 00:10:44.280
это отразить. Это важно, поскольку низкая цена товара не отражает полную стоимость, если доставка

00:10:44.280 --> 00:10:48.600
обходится дорого. Регистрация расходов в заказе позволяет связать эти затраты с покупкой,

00:10:48.820 --> 00:10:52.760
а не оставлять их в отдельном документе. Теперь у поставщика есть подтвержденный заказ с четким

00:10:52.760 --> 00:10:57.780
перечнем товаров, ценами, датами и условиями. Но подтвержденный заказ лишь фиксирует то, что компания

00:10:57.780 --> 00:11:02.340
ожидает получить. Dynamics 365 все равно требуется подтверждение того, что товары

00:11:02.340 --> 00:11:07.220
или услуги действительно поступили. 4. Приемка товаров и проверка счета

00:11:07.220 --> 00:11:12.200
Грузовик подъезжает к складу со шлемами и перчатками. Прежде чем кто-либо отметит заказ как

00:11:12.200 --> 00:11:16.720
выполненный, складская команда должна проверить, что именно прибыло. Они регистрируют поступление,

00:11:16.960 --> 00:11:20.740
сверяют поставку с заказом на закупку и проводят приходную накладную по этому заказу.

00:11:20.840 --> 00:11:25.860
Приходная накладная – это просто способ записи в системе о том, что товары прибыли. Здесь 10 единиц

00:11:25.860 --> 00:11:31.000
товара. В заказе указано 20 шлемов и 10 коробок перчаток, но водитель привозит только 10 шлемов и все

00:11:31.000 --> 00:11:35.080
10 коробок перчаток. Склад отражает то, что было фактически получено, а не то, что компания

00:11:35.080 --> 00:11:38.980
надеялась получить. Оставшиеся 10 шлемов остаются открытыми в заказе на закупку, пока поставщик

00:11:38.980 --> 00:11:42.760
их не доставит или покупатель не изменит заказ. Это поддерживает точность учета. Как только

00:11:42.760 --> 00:11:47.120
приходная накладная проведена, заказ на закупку меняется. Система теперь разделяет заказанное

00:11:47.120 --> 00:11:52.140
количество и полученное, поэтому закупщики, склад и финансовый отдел видят состояние заказа без лишних

00:11:52.140 --> 00:11:56.900
звонков. Для складских позиций приемка также обновляет данные инвентаризации. Перчатки отображаются

00:11:56.900 --> 00:12:01.000
как доступный запас, готовый к использованию складской командой. Если товары относятся к

00:12:01.000 --> 00:12:06.020
конкретному проекту, основному средству или прямой поставки, Dynamics 365 может зарегистрировать

00:12:06.020 --> 00:12:10.500
покупку с учетом этого целевого назначения. Компания знает больше, чем просто-то, как мы купили

00:12:10.500 --> 00:12:15.720
перчатки. Она знает, прибыли ли перчатки, сколько их прибыло и к чему они относятся. Однако не каждая

00:12:15.720 --> 00:12:19.780
покупка доставляется на погрузочную платформу. Представьте, что компания нанимает инструктора по

00:12:19.780 --> 00:12:24.320
безопасности на день, оплачивает доступ к по или привлекает стороннюю сервисную службу. Здесь нет материальных

00:12:24.320 --> 00:12:28.420
объектов, палет для подсчета и складского поступления для регистрации. Для услуг и других

00:12:28.420 --> 00:12:32.940
нематериальных покупок компания может использовать более простой путь. В зависимости от настроек

00:12:32.940 --> 00:12:38.220
закупки можно зарегистрировать получение в заказе без складских операций или сразу перейти к счету

00:12:38.220 --> 00:12:43.860
поставщика. Тот же вопрос остается актуальным. Получила ли компания это, что договорилась купить? В случае

00:12:43.860 --> 00:12:48.340
с обучением ответом может быть подтверждение того, что тренинг состоялся. В случае с ремонтом кто-то

00:12:48.340 --> 00:12:52.580
подтверждает, что работы выполнены. Для подтверждения получения товара компании не обязательно иметь

00:12:52.580 --> 00:12:57.040
коробку или штрих-код. Затем поступает счет от поставщика. Счет попадает в модуль расчетов с

00:12:57.040 --> 00:13:02.060
кредиторами, часть Dynamics 365, где фиксируются обязательства перед поставщиками и готовятся

00:13:02.060 --> 00:13:06.820
платежи. Счет привязывается к заказу на закупку, поэтому система не считает его изолированным

00:13:06.820 --> 00:13:10.780
документом без истории. Именно здесь простая проверка предотвращает множество проблем.

00:13:10.980 --> 00:13:16.140
Dynamics 365 сравнивает три показателя, что компания заказала, что получила и что выставил поставщик.

00:13:16.260 --> 00:13:20.820
Это называют сопоставлением. Простыми словами, соответствует ли счет договоренности? В заказе на закупку

00:13:20.820 --> 00:13:24.500
может быть указано 20 шлемов по согласованной цене. В накладной на получение может значиться,

00:13:24.720 --> 00:13:29.080
что пока прибыло только 10 шлемов. Если поставщик пришлет счет на 20 штук, система укажет на разницу

00:13:29.080 --> 00:13:32.900
до того, как компания проведет оплату. Это автоматизирует трехсторонние сопоставления.

00:13:33.120 --> 00:13:37.680
Эти три записи – заказ на закупку, накладная на получение товара и счет. Когда они совпадают,

00:13:37.800 --> 00:13:41.540
у отдела расчетов с кредиторами есть четкий алгоритм действий. Если цена отличается,

00:13:41.720 --> 00:13:46.360
количество в счете превышает полученное или появилась лишняя позиция, компания может остановиться и все

00:13:46.360 --> 00:13:50.480
проверить. Возможно, поставщик прислал счет раньше времени. Возможно, появилась отдельная сумма

00:13:50.480 --> 00:13:54.180
за доставку, которую нужно проверить покупателю. Может быть, поставщик просто ошибся в количестве

00:13:54.180 --> 00:13:58.600
при вводе данных. Смысл не в том, чтобы подозревать злой умысел. Система автоматически выявляет

00:13:58.600 --> 00:14:03.100
расхождение, пока можно задать уточняющие вопросы, а не после того, как деньги ушли со счета.

00:14:03.220 --> 00:14:07.260
Каждому счету также нужно найти место в автоматизированных финансовых записях компании.

00:14:07.460 --> 00:14:11.600
Это автоматизирует задачу бухгалтерского распределения. Они сообщают Dynamics 365,

00:14:11.920 --> 00:14:15.460
как именно нужно отразить затраты. Защитные перчатки могут относиться к эксплуатационным

00:14:15.460 --> 00:14:19.060
расходам склада. Новый вилочный погрузчик может быть отнесен к счету основных средств.

00:14:19.060 --> 00:14:22.600
Затраты по проектной закупке могут требовать отражения на соответствующем проекте.

00:14:22.740 --> 00:14:27.460
Один счет можно даже распределить по нескольким статьям. Например, если две складские команды

00:14:27.460 --> 00:14:31.140
делят заказ перчаток, компания может разделить стоимость между их отделами.

00:14:31.300 --> 00:14:35.100
Финансовый отдел будет видеть, куда ушли деньги, не пытаясь позже восстановить картину

00:14:35.100 --> 00:14:39.180
по расплывчатому описанию в счете. После того, как данные сопоставлены и все проверки завершены,

00:14:39.400 --> 00:14:42.880
счет может пройти процедуру утверждения. Проведение счета фиксирует сумму задолженности

00:14:42.880 --> 00:14:46.400
перед поставщиком в расчетах с кредиторами. Счет становится кредиторской задолженностью.

00:14:46.400 --> 00:14:50.280
Условия оплаты помогают определить срок ее погашения. Отдел расчетов с кредиторами

00:14:50.280 --> 00:14:55.600
готовит счета к оплате, и как только компания проводит платеж, Dynamics 365 закрывает баланс

00:14:55.600 --> 00:15:00.060
по этому счету. Заказ прошел путь от ожидаемой поставки до отраженных затрат и завершенного

00:15:00.060 --> 00:15:03.960
платежа. Но этот след – это нечто большее, чем просто оплата одного счета. Это дает компании

00:15:03.960 --> 00:15:07.180
удобный учет каждого решения и каждой передачи ответственности, связанных с закупкой.

00:15:07.280 --> 00:15:10.480
Пятое – контроль видимости и более обоснованные решения в выборе поставщиков.

00:15:10.660 --> 00:15:13.860
Единая система учета закупок также позволяет компании контролировать расходы до того,

00:15:13.860 --> 00:15:17.660
как возникнут финансовые проблемы. Политика закупок устанавливает базовые правила. Она

00:15:17.660 --> 00:15:21.300
определяет, что сотрудники могут запрашивать, каких поставщиков использовать и когда покупка

00:15:21.300 --> 00:15:25.040
требует согласования перед тратой средств компании. Рассмотрим запрос на получение защитного

00:15:25.040 --> 00:15:28.600
снаряжения. Компания может обязать складской персонал выбирать только одобренные средства защиты.

00:15:28.800 --> 00:15:32.400
При этом право выбора нового поставщика остается за отделом закупок. Небольшой заказ на замену

00:15:32.400 --> 00:15:36.680
может потребовать одного согласования, а крупный заказ для нового подразделения – одобрение владельца

00:15:36.680 --> 00:15:40.900
бюджета и менеджера по закупкам. Правила заложены непосредственно в процесс. Сотрудникам

00:15:40.900 --> 00:15:45.320
не нужно искать внутренние документы, гадать, кто должен утвердить заявку или пересылать

00:15:45.320 --> 00:15:50.660
письма в ожидании ответа. Dynamics 365 направляет запрос в зависимости от отдела, суммы,

00:15:50.800 --> 00:15:54.860
типа закупки или связанной с ней политики. Этот маршрут называется рабочим процессом

00:15:54.860 --> 00:15:59.280
Workflow. Рабочий процесс обеспечивает четкий путь для заявок, заказов на закупку и счетов от

00:15:59.280 --> 00:16:03.480
одного ответственного лица к другому. Каждый может одобрить, отклонить или отправить документ на

00:16:03.480 --> 00:16:08.220
доработку, а система фиксирует все эти действия. Больше не нужно гадать, было ли получено одобрение в

00:16:08.220 --> 00:16:11.920
длинной цепочке электронных писем. Это также помогает, когда кто-то из сотрудников отсутствует.

00:16:12.100 --> 00:16:16.240
Задача не исчезает в папке «Входящие» сотрудника без следов того, на каком этапе она остановилась.

00:16:16.420 --> 00:16:20.000
Компания может видеть текущий статус и принять необходимые меры. Поставщики также могут

00:16:20.000 --> 00:16:24.160
участвовать в процессе, если компания использует портал поставщиков. Портал поставщиков позволяет

00:16:24.160 --> 00:16:28.460
им просматривать направленные им запросы котировок или заказы на закупку. Они могут отвечать на

00:16:28.460 --> 00:16:33.120
запросы котировок и подтверждать заказы напрямую, когда компания отправляет запрос на подтверждение.

00:16:33.280 --> 00:16:37.100
Это дает обеим сторонам возможность работать с одним и тем же документом. Вместо того,

00:16:37.100 --> 00:16:41.940
чтобы отправлять PDF-файлы, ждать ответа и вносить данные вручную, поставщик подтверждает

00:16:41.940 --> 00:16:46.280
детали через единый процесс. Покупатель видит ответ сразу, без необходимости заново вносить

00:16:46.280 --> 00:16:50.720
данные в систему. Когда закупки проходят через систему, компания автоматически собирает полезную

00:16:50.720 --> 00:16:55.520
информацию без создания дополнительных таблиц. Анализ расходов отвечает на простой вопрос – куда

00:16:55.520 --> 00:16:59.620
уходят деньги? Менеджер по закупкам может изучить расходы по поставщикам, продуктам,

00:16:59.780 --> 00:17:03.960
категориям закупок или отделам. Возможно, компания думает, что закупает перчатки у одного поставщика,

00:17:03.960 --> 00:17:07.220
но записи показывают, что разные отделы покупают похожие перчатки у разных продавцов.

00:17:07.340 --> 00:17:11.080
Может оказаться, что отдел тратит на внешний ремонт больше средств, чем ожидалось. Эти данные

00:17:11.080 --> 00:17:14.520
дают компании повод задать более правильные вопросы перед совершением следующей закупки.

00:17:14.700 --> 00:17:17.820
Анализ эффективности поставщиков позволяет взглянуть на ситуацию с их стороны.

00:17:18.000 --> 00:17:21.820
Покупатели могут сравнивать результаты закупок и поставок при выборе исполнителей для будущих

00:17:21.820 --> 00:17:25.680
заказов. Низкая цена на бумаге может оказаться не столь привлекательной, если поставщик постоянно

00:17:25.680 --> 00:17:29.720
задерживает доставку, присылает неполные заказы или не соблюдает условия договора. Компания может

00:17:29.720 --> 00:17:33.020
использовать собственные записи о закупках при оценке отношений с таким поставщиком.

00:17:33.020 --> 00:17:37.420
Далее, контрольный след. Контрольный след позволяет проследить полную историю покупки.

00:17:37.600 --> 00:17:41.060
Можно начать с исходной заявки, узнать, кто ее одобрил, просмотреть заказ на закупку,

00:17:41.200 --> 00:17:44.260
проверить приемку, найти счет-фактуру и увидеть платеж, который его закрыл.

00:17:44.340 --> 00:17:47.620
Эта запись полезна не только финансовым и аудиторским отделам, но и обычным сотрудникам

00:17:47.620 --> 00:17:51.700
для поиска ответов на повседневные вопросы. Зачем мы это купили? Кто выбрал этого поставщика?

00:17:51.840 --> 00:17:56.000
Пришли ли товары? Оплачен ли уже этот счет? Ответ содержится в записи о закупке.

00:17:56.200 --> 00:17:59.640
Вернемся в офисное издание, с которого мы начали. У отдела закупок,

00:17:59.640 --> 00:18:04.700
склада и финансового отдела разные задачи, но все они работают частями одной и той же сделки,

00:18:04.920 --> 00:18:09.980
они пересылают бумажки между комнатами. У нашего менеджера склада, который оформлял

00:18:09.980 --> 00:18:14.760
запрос на каски и перчатки, теперь есть полная история. Заявка соответствовала политике

00:18:14.760 --> 00:18:19.480
компании. Нужные люди ее одобрили. Поставщик предоставил оборудование. Складской персонал

00:18:19.480 --> 00:18:24.540
зафиксировал доставку. Бухгалтерия сопоставила счет-фактуру и оплатила его. Одно простое различие

00:18:24.540 --> 00:18:29.040
помогает упорядочить все эти элементы. Поиск поставщиков помогает компании выбрать партнера,

00:18:29.280 --> 00:18:32.900
а закупки управляют тем, что происходит после принятия решения о покупке.

00:18:33.160 --> 00:18:37.640
Заключение. Единая связная запись от заявки до оплаты. Общая картина выглядит так.

00:18:37.760 --> 00:18:42.060
Модуль закупок и поиска поставщиков объединяет разрозненные этапы в единый очлеживаемый процесс.

00:18:42.340 --> 00:18:46.020
Заявка не теряется во входящих, одобрение не хранится только в чьей-то памяти,

00:18:46.180 --> 00:18:50.400
а счет не приходит без четкой связи с принятым ранее решением. Вместо этого у компании есть

00:18:50.400 --> 00:18:54.300
единая запись, которая сопровождает всю цепочку закупок. Это дает вам ясный ответ,

00:18:54.460 --> 00:18:58.420
когда он нужен. Вы как покупатель видите заказ. Склад видит, что ожидается к поставке.

00:18:58.540 --> 00:19:01.480
Финансовый отдел знает, сколько компания должна выплатить, а менеджеры видят,

00:19:01.640 --> 00:19:05.380
куда именно уходят средства. Закупки по-прежнему включают людей, поставщиков, товары,

00:19:05.520 --> 00:19:10.180
услуги и решения. Dynamics 365 не отменяет все это. Система хранит все записи в одном месте,

00:19:10.380 --> 00:19:13.600
чтобы вы могли закупать с меньшим количеством недоработок и неожиданностей. Подписывайтесь на

00:19:13.600 --> 00:19:18.000
удобной вам платформе и делитесь этой информацией с теми, кто только начинает изучать Dynamics 365,

00:19:18.280 --> 00:19:19.200
закупки и источники.