WEBVTT

00:00:01.360 --> 00:00:06.500
Счет от поставщика оказывается у вас на столе. Товар может быть уже на складе, а услуга оказана.

00:00:06.500 --> 00:00:10.460
Но отсчет времени для оплаты начинается сразу же. Итак, что же на самом деле происходит,

00:00:10.640 --> 00:00:14.940
прежде чем деньги покидают компанию? Добро пожаловать в очередную полезную заметку от М365FM.

00:00:15.100 --> 00:00:19.160
Я Мир Питерс, и сегодня мы простыми словами поговорим о расчетах с кредиторами в Dynamics 365.

00:00:19.620 --> 00:00:23.660
Это не просто место, где кто-то вводит счета в компьютер. Это финансовый отдел компании,

00:00:23.860 --> 00:00:28.000
который проверяет каждый счет, кто его прислал, что компания согласилась купить и нужно ли его

00:00:28.000 --> 00:00:31.600
оплачивать. Вот самое простое определение. Кредиторская задолженность – это деньги,

00:00:31.600 --> 00:00:34.780
которые ваша компания должна поставщикам за товары или услуги, которые вы уже приобрели.

00:00:34.920 --> 00:00:38.820
Представьте себе это как кассу внутри большого здания. Счета поступают на стойку регистрации,

00:00:38.940 --> 00:00:42.400
сверяются с записями компаний, проходят процедуру согласования и только после этого попадают к

00:00:42.400 --> 00:00:46.460
человеку, который осуществляет платеж. Мы проследим этот путь от записи о поставщике до финальной

00:00:46.460 --> 00:00:51.980
отметки об оплате. В Dynamics 365 это называется урегулированием. Почему существует кредиторская

00:00:51.980 --> 00:00:56.520
задолженность? Представьте, что вы управляете небольшой компанией по продаже офисной мебели. Вам нужны

00:00:56.520 --> 00:01:00.920
столы, прежде чем вы сможете их продать. А еще вам нужны упаковочные коробки, услуги уборки,

00:01:01.080 --> 00:01:05.420
интернет, запчасти и, возможно, транспортная компания. Если бы вам приходилось платить каждому

00:01:05.420 --> 00:01:09.560
поставщику сразу при заказе, закупать что-либо стало бы очень сложно и очень быстро. Большинство

00:01:09.560 --> 00:01:13.820
компаний сначала покупают, а потом платят на согласованных условиях. Поставщик доставляет товар или

00:01:13.820 --> 00:01:18.200
выполняет работу, а затем присылает инвойс, свой счет. Теперь ваша компания должна эту сумму,

00:01:18.340 --> 00:01:22.420
но не отправляет деньги, не проверив все детали. Эта неоплаченная сумма отражается в бухгалтерских

00:01:22.420 --> 00:01:26.540
книгах компании как обязательство. Обязательство может звучать как пугающий финансовый термин,

00:01:26.740 --> 00:01:31.120
но смысл прост, это сумма, которую компания должна кому-то другому. Если ваш бизнес получил счет

00:01:31.120 --> 00:01:34.980
за концтовары и еще не оплатил его, этот счет относится к кредиторской задолженности до тех пор,

00:01:35.160 --> 00:01:39.180
пока оплата не будет произведена. Деньги у компании пока остаются, но у нее также есть обязательства,

00:01:39.280 --> 00:01:43.620
которые нужно выполнить. Это важно, потому что бизнес может выглядеть благополучно на банковском счете,

00:01:43.860 --> 00:01:47.840
имея при этом стопку неоплаченных счетов. Финансовым командам нужно видеть обе стороны,

00:01:47.840 --> 00:01:51.760
сколько денег лежит в банке и какая часть этих средств скоро должна будет уйти.

00:01:51.760 --> 00:01:55.520
До появления интегрированных финансовых систем эта работа часто превращалась в бумажную

00:01:55.520 --> 00:01:59.620
волокиту. Счет мог прийти по почте, лежать на чьем-то столе, затем перемещаться по внутренней

00:01:59.620 --> 00:02:03.360
почте на подпись, в то время как другой счет пылился во входящих письмах. Кто-то мог вводить

00:02:03.360 --> 00:02:06.880
один и тот же счет в электронную таблицу, пока другой сотрудник вносил его в систему

00:02:06.880 --> 00:02:11.140
бухгалтерского учета. Это создает всем знакомые проблемы. Менеджер пропускает письмо с запросом

00:02:11.140 --> 00:02:14.780
на согласование, счет оплачивается с опозданием, или поставщик присылает тот же счет повторно,

00:02:14.780 --> 00:02:18.220
а никто не замечает, что он уже поступил в финансовый отдел. Хуже того, его могут оплатить

00:02:18.220 --> 00:02:21.440
дважды, потому что бумажная копия и копия по электронной почте выглядят как разные счета.

00:02:21.600 --> 00:02:26.140
Dynamics 365 предоставляет компании единое место для отслеживания этой работы. Система фиксирует

00:02:26.140 --> 00:02:30.260
задолженность компании, помогает проверять счета и обеспечивает четкий путь от получения счета до

00:02:30.260 --> 00:02:34.860
его оплаты. Это не означает, что каждый счет проходит без участия человека. Финансовый отдел по-прежнему

00:02:34.860 --> 00:02:38.940
принимает решения, если что-то не так, но система предоставляет им записи и правила для принятия решений

00:02:38.940 --> 00:02:43.120
без беготни с бумагами по всему офису. Возможно, вы также услышите термин «дебиторская задолженность»

00:02:43.120 --> 00:02:46.800
в этом же контексте. Названия звучат почти одинаково, но они указывают на противоположные

00:02:46.800 --> 00:02:49.920
направления. Кредиторская задолженность очлеживает деньги, уходящие из вашей компании,

00:02:50.120 --> 00:02:53.720
потому что вы должны поставщикам. Дебиторская задолженность очлеживает деньги, поступающие в вашу

00:02:53.720 --> 00:02:57.300
компанию, потому что клиенты должны вам. Если ваша компания покупает принтеры у поставщика,

00:02:57.460 --> 00:03:01.500
этот счет попадает в кредиторскую задолженность. Если ваша компания продает столы клиенту и выставляет

00:03:01.500 --> 00:03:04.620
ему счет, этот счет клиента попадает в дебиторскую задолженность. Таким образом,

00:03:04.760 --> 00:03:08.380
кредиторская задолженность очлеживает то, что должны вы, а дебиторская то, что должны вам.

00:03:08.560 --> 00:03:12.600
Цель кредиторской задолженности – очень практический результат. Оплатить нужному поставщику

00:03:12.600 --> 00:03:17.060
нужную сумму в согласованную дату. Оплатите слишком рано, и компания потеряет наличные средства

00:03:17.060 --> 00:03:20.840
раньше времени. Оплатите слишком поздно, и поставщик может начать требовать оплату или

00:03:20.840 --> 00:03:25.140
перестанет предлагать выгодные условия. Оплатите неверную сумму, и кому-то придется исправлять

00:03:25.140 --> 00:03:29.960
ошибку позже, часто с помощью писем, кредитовых авизо и больших усилий. Поэтому, прежде чем счет

00:03:29.960 --> 00:03:34.920
пройдет через этот процесс, Dynamics 365 должна точно знать, кто является поставщиком и какие

00:03:34.920 --> 00:03:39.520
правила применяются к этим отношениям. Создание базы данных поставщиков. Прежде чем Dynamics

00:03:39.520 --> 00:03:44.080
365 сможет обработать хотя бы один счет, ей нужно точно знать, от кого он пришел. Именно здесь

00:03:44.080 --> 00:03:48.380
на помощь приходит карточка поставщика. Без нее система не знает, кому платить и каким правилам

00:03:48.380 --> 00:03:52.740
следовать. Поставщик может поставлять физические товары, такие как бумага, ноутбуки или запчасти.

00:03:52.880 --> 00:03:56.580
Они также могут предоставлять услуги, например, бухгалтерский учет или программную поддержку.

00:03:56.580 --> 00:04:00.600
Товар меняется, но роль остается прежней. Это сторона, которой ваша компания, возможно,

00:04:00.840 --> 00:04:05.160
должна произвести оплату. Рассматривайте карточку поставщика как досье контрагента внутри Dynamics 365.

00:04:05.600 --> 00:04:09.200
Она хранит базовые данные, необходимые вашему финансовому отделу, а также устанавливает правила,

00:04:09.320 --> 00:04:12.900
которые определяют дальнейшие действия. Вы вводите имя, адрес и контактную информацию

00:04:12.900 --> 00:04:17.240
поставщика, чтобы компания точно знала, с кем имеет дело. Вы также можете указать валюту,

00:04:17.340 --> 00:04:21.400
используемую для счетов и платежей, что очень важно при закупках у поставщиков из разных стран.

00:04:21.580 --> 00:04:25.680
Теперь о платежных реквизитах. Запись о поставщике может содержать условия и способ оплаты.

00:04:25.680 --> 00:04:29.240
Это может показаться лишь парой полей на экране, но они отвечают на очень важные практические

00:04:29.240 --> 00:04:33.180
вопросы. Когда нужно оплатить счет этого поставщика? И как компания должна отправить эти деньги?

00:04:33.360 --> 00:04:36.360
Условия оплаты определяют правила расчета срока платежа. Некоторые поставщики позволяют

00:04:36.360 --> 00:04:40.120
платить через 30 дней после даты выставления счета. Другие требуют оплаты в течение 14 дней.

00:04:40.320 --> 00:04:44.960
Некоторые даже предлагают скидку за досрочную оплату. Dynamics 365 использует заданные вами условия

00:04:44.960 --> 00:04:48.900
для автоматического расчета срока оплаты каждого счета. Никому не нужно держать условия соглашения

00:04:48.900 --> 00:04:52.620
в голове. Это обеспечивает согласованность. Если пять разных сотрудников обрабатывают

00:04:52.620 --> 00:04:56.600
счета одного и того же поставщика, они следуют единому правилу оплаты. Никому не нужно перебирать

00:04:56.600 --> 00:05:00.360
старые письма или звонить в отдел закупок, чтобы узнать срок оплаты счета. Способ оплаты

00:05:00.360 --> 00:05:03.980
описывает, как именно средства поступят поставщику. Ваша компания может оплачивать услуги

00:05:03.980 --> 00:05:07.920
одного поставщика электронным переводом, а другого – чеком. В некоторых случаях бизнес может

00:05:07.920 --> 00:05:13.100
использовать простые векселя. Dynamics 365 позволяет определять собственные способы оплаты и при

00:05:13.100 --> 00:05:17.480
необходимости привязывать их к системным типам. Компании обычно работают не с одним поставщиком.

00:05:17.480 --> 00:05:22.880
У растущего бизнеса их могут быть десятки, сотни и даже тысячи. Настройка каждого из них с нуля – это

00:05:22.880 --> 00:05:27.640
пустая трата времени и риск совершить ошибку. Вот почему в Dynamics 365 используются группы

00:05:27.640 --> 00:05:31.400
поставщиков. Группа поставщиков объединяет контрагентов, у которых действуют общие финансовые

00:05:31.400 --> 00:05:34.700
правила. Например, можно выделить местных поставщиков офисных товаров в одну группу,

00:05:34.820 --> 00:05:38.480
а зарубежных поставщиков сырья – в другую. Группа содержит общие настройки для проведения

00:05:38.480 --> 00:05:43.160
транзакций, выполнения платежей и взаиморасшитов, а также отчетности по балансам поставщиков. При этом

00:05:43.160 --> 00:05:47.020
вы сохраняете отдельную карточку для каждого поставщика. Это важно, так как у каждого

00:05:47.020 --> 00:05:51.020
поставщика должны быть свои имя, адрес, платежные реквизиты и истории операций. Группа

00:05:51.020 --> 00:05:54.680
поставщиков служит общей отправной точкой, чтобы финансовому отделу не приходилось раз за разом

00:05:54.680 --> 00:05:58.740
воссоздавать одни и те же правила. За кулисами работает еще один механизм – профиль разноски

00:05:58.740 --> 00:06:02.280
поставщика. Название звучит технически сложно, поэтому давайте скажем проще.

00:06:02.420 --> 00:06:06.640
Профиль разноски – это карта, которая указывает Dynamics 365, куда относить транзакции

00:06:06.640 --> 00:06:10.020
поставщиков в главной книге. Главная книга – это основной реестр финансовых

00:06:10.020 --> 00:06:14.900
счетов компании. При проведении счета Dynamics 365 должна отразить как задолженность компании,

00:06:14.900 --> 00:06:18.720
так это, к какой статье расходов она относится. Профиль разноски управляет частью

00:06:18.720 --> 00:06:22.640
бухгалтерской проводки, касающейся поставщика, используя правила, заданные для поставщика или

00:06:22.640 --> 00:06:26.460
группы поставщиков. Сотрудникам финансового отдела не нужно каждый раз выбирать эти бухгалтерские

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

00:06:30.440 --> 00:06:33.960
команде четкое представление о задолженности перед поставщиками. Компания также подготавливает

00:06:33.960 --> 00:06:37.340
платежную базу до того, как поступят счета. В модуле управления денежными средствами и банками

00:06:37.340 --> 00:06:40.440
вы настраиваете банковские счета, с которых будут проводиться платежи поставщикам. Журналы платежей

00:06:40.440 --> 00:06:43.800
предоставляют сотрудникам рабочую область для подготовки и регистрации оплат с использованием

00:06:43.800 --> 00:06:48.200
утвержденных методов. Итак, подведем итог. Карточка поставщика определяет получателя средств.

00:06:48.360 --> 00:06:53.080
Условия оплаты определяют сроки, а метод платежа и банковский счет – порядок перечисления

00:06:53.080 --> 00:06:58.320
средств компании. Когда эти правила настроены, счет может поступить в финансовый отдел и начать

00:06:58.320 --> 00:07:02.400
свой путь от получения до утверждения. Благодаря настроенной карточке поставщика система

00:07:02.400 --> 00:07:07.220
Dynamics 365 теперь знает, кому и на каких условиях нужно платить. Итак, что происходит,

00:07:07.220 --> 00:07:11.420
когда приходит реальный счет. Иногда финансовый клерк вводит его вручную. Это актуально,

00:07:11.600 --> 00:07:15.140
когда счет приходит по электронной почте, в бумажном виде или через портал поставщика,

00:07:15.340 --> 00:07:19.900
и данные нужно перенести в систему. Клерк выбирает поставщика, вводит номер и дату счета,

00:07:20.140 --> 00:07:25.540
а затем добавляет строки, суммы, налоги и ссылки на заказы на закупку. Номер счета заслуживает

00:07:25.540 --> 00:07:30.000
особого внимания. Он присваивается поставщиком, а не вашей компанией, и помогает идентифицировать

00:07:30.000 --> 00:07:34.580
конкретный документ. Если поступает счет на 1200 долларов от Nortwind Office Supplies под номером

00:07:34.580 --> 00:07:39.980
N148, Dynamics 365 сопоставляет этот номер с карточкой поставщика, чтобы выявить дубликат.

00:07:40.120 --> 00:07:44.580
Вложения также прикрепляются к записи. PDF-счет, отсканированный документ или подтверждающие

00:07:44.580 --> 00:07:50.020
бумаги могут храниться прямо в Dynamics 365 вместе со счетом. Это означает, что проверяющий может

00:07:50.020 --> 00:07:55.700
увидеть исходный документ, не копаясь в общих почтовых ящиках или архивах. При больших объемах

00:07:55.700 --> 00:08:01.100
счета могут поступать в электронном виде. Dynamics 365 поддерживает импорт данных счетов через

00:08:01.100 --> 00:08:05.380
сущности данных. Рассматривайте сущность данных как стандартную форму, которую заполняет другая

00:08:05.380 --> 00:08:10.880
система перед отправкой информации в Dynamics 365. Например, внешняя служба распознавания счетов

00:08:10.880 --> 00:08:15.720
может отправить заголовок счета, строки и вложения одним пакетом данных. Заголовок содержит

00:08:15.720 --> 00:08:20.740
основные детали счета, поставщика, номер, даты, валюту, общую сумму и ссылку на заказ на закупку.

00:08:20.940 --> 00:08:25.100
Строки объясняют, за что именно выставлен счет. Одна строка может быть за бумагу для принтера,

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

00:08:29.580 --> 00:08:33.420
что именно они утверждают. Налоговая информация также передается вместе со счетом.

00:08:33.560 --> 00:08:37.820
Dynamics 365 требует сумму налога и сопутствующие данные для правильного отражения счета в учете

00:08:37.820 --> 00:08:41.700
компании. Есть несколько причин, по которым счет может быть задержан до проверки. Отсутствие

00:08:41.700 --> 00:08:46.600
поставщика, неверная дата, повтор номера счета или несовпадение итоговой суммы. Такая пауза защищает

00:08:46.600 --> 00:08:51.060
интересы компании. Политика по счетам от поставщиков проверяет, соблюдает ли счет установленные

00:08:51.060 --> 00:08:55.460
вами правила. Проверка на дубликаты выявляет знакомые счета, например, с уже зарегистрированными

00:08:55.460 --> 00:08:59.700
поставщиком и номером. Цель – вовсе не обвинить поставщика в ошибке. Поставщики могут прислать

00:08:59.700 --> 00:09:03.640
счет повторно, если не уверены, что он дошел. Сотрудник может случайно ввести один и тот же

00:09:03.640 --> 00:09:07.660
PDF-файл дважды. В любом случае, двойная оплата одного счета создает никому не нужную работу.

00:09:07.800 --> 00:09:12.360
Когда Dynamics 365 принимает счет, возникает простой вопрос. Кто уполномочен его утвердить?

00:09:12.520 --> 00:09:16.840
Здесь на помощь приходит функция Workflow. Workflow – это маршрут утверждения внутри системы.

00:09:16.840 --> 00:09:22.240
Вместо пересылки PDF-менеджеру в надежде на ответ, Dynamics 365 сама направляет счет

00:09:22.240 --> 00:09:26.780
нужному лицу или роли согласно правилам компании. Каждая организация определяет эти правила,

00:09:26.880 --> 00:09:30.780
исходя из того, как должны приниматься финансовые решения. Обычный небольшой счет может

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

00:09:34.500 --> 00:09:38.940
руководителя. Счет, относящийся к конкретному отделу, может быть направлен руководителю этого отдела.

00:09:39.080 --> 00:09:42.660
Можно даже создать разные пути утверждения для разных типов поставщиков, поставщиков товаров,

00:09:42.660 --> 00:09:47.420
услуг или подрядчиков. Маршрут следует правилам, а не чьей-то памяти. Это значительно упрощает

00:09:47.420 --> 00:09:52.100
отслеживание утверждений. Финансовый отдел видит, ожидает ли счет проверки, утвержден ли он

00:09:52.100 --> 00:09:57.000
или требует уточнений. Утверждающий может проверить счет, решить, относится ли он к его отделу

00:09:57.000 --> 00:10:01.340
и верна ли сумма. Некоторые счета соответствуют всем правилам и проходят дальше автоматически.

00:10:01.480 --> 00:10:06.460
Поставщик известен, все данные на месте, и счет прошел все проверки политики. Такие счета не

00:10:06.460 --> 00:10:10.680
требуют повторения одних и тех же базовых проверок. Другие счета становятся исключениями.

00:10:10.680 --> 00:10:14.540
Возможно, отсутствует учетная запись поставщика. Возможно, номер счета уже существует.

00:10:14.720 --> 00:10:19.620
Возможно, в импортированной строке есть ошибка. Dynamics 365 помещает такие счета в список ошибок

00:10:19.620 --> 00:10:22.840
импорта, где финансовые специалисты могут увидеть сообщение об ошибке и исправить

00:10:22.840 --> 00:10:26.660
проблему перед созданием ожидающего счета. Сам документ остается важным при проверке.

00:10:26.860 --> 00:10:31.520
Dynamics 365 включает просмотрщик вложений на страницах счетов, поэтому сотрудник может

00:10:31.520 --> 00:10:35.820
видеть изображение счета прямо рядом с записью, которую он правит. Нет нужды переключаться между

00:10:35.820 --> 00:10:41.460
экранами, чтобы сверить, указал ли поставщик 6000 или 8000 в оригинале. Автоматизация берет на себя

00:10:41.460 --> 00:10:45.580
рутину. Люди берут на себя вопросы. Утверждение подтверждает, что нужный человек разрешил продолжить

00:10:45.580 --> 00:10:49.260
работу со счетом, но оно еще не доказывает, что поставщик выставил счет именно за то, что было заказано или

00:10:49.260 --> 00:10:53.740
получено. Для этого Dynamics 365 сопоставляет документацию. Сопоставление счетов

00:10:53.740 --> 00:10:58.420
Проверка заказа компании подтверждает, что нужный сотрудник ознакомился со счетом. Но сопоставление

00:10:58.420 --> 00:11:02.440
отвечает на другой вопрос. Соответствует ли счет тому, что компания действительно договорилась

00:11:02.440 --> 00:11:07.340
купить? Если закупка начинается с заказа на закупку, у Dynamics 365 есть запись для сверки.

00:11:07.460 --> 00:11:11.920
Представьте заказ на закупку как внутреннюю квитанцию компании. В нем фиксируется поставщик,

00:11:12.140 --> 00:11:16.660
запрос, количество, цена и условия. Сотрудник отдела закупок создает этот заказ до того,

00:11:16.660 --> 00:11:21.340
как придет счет. Почему это важно? Заказ на закупку фиксирует соглашение до появления счета.

00:11:21.520 --> 00:11:25.640
Без него сотрудник финансового отдела видит лишь счет от имени поставщика. С ним можно сравнить

00:11:25.640 --> 00:11:30.420
сумму поставщика с первоначальным запросом. Для физических товаров есть еще одна важная запись.

00:11:30.580 --> 00:11:35.360
Когда прибывает доставка, склад регистрирует приходный ордер. Это подтверждение в Dynamics 365,

00:11:35.680 --> 00:11:40.140
что товар поступил в компанию, включая его количество. Это не значит, что все позиции идеальны,

00:11:40.300 --> 00:11:44.720
но фиксируется то, что было получено по заказу. Представьте, что компания заказывает 10 офисных

00:11:44.720 --> 00:11:49.040
стульев. В заказе указано 10 стульев по согласованной цене, но при доставке на складе

00:11:49.040 --> 00:11:54.100
насчитывают только 8, так как 2 в отложенном заказе. Команда приемки проводит приходный ордер на 8

00:11:54.100 --> 00:11:58.260
единиц. Затем поставщик выставляет счет на 10 стульев, что может быть верно с его стороны,

00:11:58.500 --> 00:12:02.760
если они выставили счет до отгрузки оставшихся двух. Но теперь у вашей компании есть расхождение.

00:12:02.960 --> 00:12:09.100
Заказано 10, получено 8, счет на 10. Dynamics 365 может выявить это расхождение через сопоставление

00:12:09.100 --> 00:12:13.220
счетов. Двухстороннее сопоставление сравнивает заказ на закупку со счетом поставщика,

00:12:13.220 --> 00:12:18.080
проверяя соответствие цены и количества. Это подходит для закупок, где контроля по исходному

00:12:18.080 --> 00:12:23.060
заказу достаточно. Это помогает обнаружить завышенную цену или большее количество единиц,

00:12:23.300 --> 00:12:27.860
но не проверяет факт доставки, так как сравниваются только две записи – заказ и счет.

00:12:28.100 --> 00:12:33.500
Трехстороннее сопоставление добавляет приходный ордер. Теперь Dynamics 365 сравнивает заказ на

00:12:33.500 --> 00:12:38.700
закупку, приходный ордер и счет вместе. В нашем примере со стульями система видит заказ на 10,

00:12:38.700 --> 00:12:43.680
приход на 8 и счет на 10. И эта разница становится поводом приостановить оплату счета,

00:12:43.900 --> 00:12:49.640
а не проводить ее дальше. Для компаний, закупающих запасы, оборудований или большие партии товаров,

00:12:49.820 --> 00:12:55.220
эта проверка дает финансовому отделу контроль, помогая избежать оплаты неполученных товаров или

00:12:55.220 --> 00:12:59.940
переплат. Отдел закупок подтверждает соглашение. Отдел приемки подтверждает получение товара,

00:13:00.120 --> 00:13:04.420
а счет от поставщика требует оплаты. Ой, все три записи должны соответствовать друг другу.

00:13:04.420 --> 00:13:08.880
В реальном бизнесе случаются небольшие расхождения. Цена может отличаться из-за округления,

00:13:09.120 --> 00:13:13.260
или поставщик может внести допустимые изменения в количество. Если бы каждая мелкая разница

00:13:13.260 --> 00:13:16.860
блокировала счет, финансовые отделы тратили бы слишком много времени на решение пустяковых

00:13:16.860 --> 00:13:21.220
проблем. Поэтому Dynamics 365 позволяет компании настраивать политики сопоставления и пределы

00:13:21.220 --> 00:13:25.880
допустимых отклонений. Допуск – это разрешенная разница, и компания сама решает, какой объем или

00:13:25.880 --> 00:13:31.100
процент она может принять по цене, количеству, итогу или сопутствующим расходам. Все, что укладывается в этот

00:13:31.100 --> 00:13:34.920
предел, проходят по правилам компании, а все, что превышает, помечается для проверки.

00:13:35.040 --> 00:13:38.640
Компания сама определяет эти пределы. Предприятие может допускать небольшие отклонения для

00:13:38.640 --> 00:13:41.860
недорогих канцелярских товаров, но устанавливать гораздо более строгие лимиты для дорогостоящего

00:13:41.860 --> 00:13:46.240
оборудования. Система не решает, что кажется разумным. Финансовые и закупочные отделы устанавливают

00:13:46.240 --> 00:13:51.280
правила, а Dynamics 365 последовательно их применяет. Это меняет-то, как финансовая команда распределяет

00:13:51.280 --> 00:13:55.180
свое время. Вместо того, чтобы построчно проверять каждый корректный счет, они могут сосредоточиться

00:13:55.180 --> 00:14:00.080
на исключениях. О, расследование счета, где изменилась цена, отсутствует квитанция или не совпадает

00:14:00.080 --> 00:14:04.360
количество. Корректные счета проходят по правилам, а люди тратят внимание там, где нужно принять

00:14:04.360 --> 00:14:08.480
решение. В этом и заключается реальная ценность сопоставления. Система берет на себя рутинные

00:14:08.480 --> 00:14:13.300
проверки, пока люди решают вопросы, требующие суждения. Это не замена суждения системой. Это

00:14:13.300 --> 00:14:18.080
отделение рутинных проверок от реальных вопросов. Один момент может вызвать путаницу. Стандартное

00:14:18.080 --> 00:14:22.760
сопоставление в Dynamics 365 поддерживает двухстороннюю и трехстороннюю сверку. Если компании нужно

00:14:22.760 --> 00:14:25.920
четырехсторонние сопоставления, например, добавление еще одной проверки, как запись об инспекции,

00:14:26.020 --> 00:14:29.520
это требует дополнительной работы через настройку или другое решение. Итак, у сопоставления есть

00:14:29.520 --> 00:14:34.120
четкая задача. АУ. Оно сравнивает счет поставщика с собственными записями компании о закупках и

00:14:34.120 --> 00:14:38.620
приемке, а затем указывает на пробелы до оплаты. Как только счет проходит проверку и сопоставление,

00:14:38.760 --> 00:14:42.780
он становится суммой, которую компания должна и может планировать к выплате, рассчитываясь с

00:14:42.780 --> 00:14:46.900
поставщиками и закрывая отчеты. После того, как счет проходит требуемой вашей компании проверки,

00:14:47.140 --> 00:14:51.860
Dynamics 365 может его провести. Проведение означает, что счет становится официальной финансовой

00:14:51.860 --> 00:14:55.840
записью, и компания отражает сумму долга этому поставщику. При этом счет числится неоплаченным,

00:14:56.020 --> 00:15:00.020
пока платеж его не закроет. Счет готов, но это не значит, что деньги уходят немедленно.

00:15:00.180 --> 00:15:03.580
Финансовым командам нужно решить, какие счета оплатить в рамках платежного цикла.

00:15:03.740 --> 00:15:08.320
Dynamics 365 помогает с предложением по оплате, которое анализирует счета с истекающим сроком и

00:15:08.320 --> 00:15:11.440
предлагает, какие из них включить в платеж на основе выбранных компаний правил.

00:15:11.580 --> 00:15:15.280
Предложение по оплате – это начальный список, который все равно проверяет человек. Возможно,

00:15:15.460 --> 00:15:19.060
срок оплаты счета поставщика наступает на этой неделе, в то время как другой можно оплатить позже в этом же

00:15:19.060 --> 00:15:22.200
месяце согласно условиям договора. Финансовый отдел проверяет предложенные счета,

00:15:22.420 --> 00:15:26.040
при необходимости удаляет или добавляет позиции, а затем готовит журнал платежей.

00:15:26.160 --> 00:15:29.640
Таким образом, платежи группируются и контролируются, вместо того, чтобы отправляться

00:15:29.640 --> 00:15:33.300
разрозненно. Представьте журнал платежей как рабочий документ компании по расчетам.

00:15:33.460 --> 00:15:37.700
В нем перечислены платежи поставщикам, которые компания планирует отправить, суммы и детали платежей.

00:15:37.860 --> 00:15:41.700
Финансисты используют его для подготовки контролируемого пакета платежей вместо отправки денег

00:15:41.700 --> 00:15:46.440
по каждому счету отдельно без общей записи. Как именно уходят деньги? Это зависит от способа оплаты,

00:15:46.440 --> 00:15:51.040
установленного для поставщика и компании. Dynamics 365 позволяет компании создавать свои

00:15:51.040 --> 00:15:54.920
способы оплаты и связывать их с типами платежей, такими как чеки, электронные переводы или

00:15:54.920 --> 00:15:59.400
простые векселя. Чек всем знаком. Электронный платеж отправляет деньги через банковскую систему

00:15:59.400 --> 00:16:03.580
компании. Простой вексель фиксирует официальное обязательство заплатить на оговоренных условиях.

00:16:03.760 --> 00:16:08.140
Не каждый бизнес использует все методы, но Dynamics 365 дает компании способ зафиксировать

00:16:08.140 --> 00:16:12.560
используемый маршрут. Каждый способ оплаты также должен быть привязан к нужному банковскому счету компании.

00:16:12.560 --> 00:16:15.940
Эта связь важна, так как компания может иметь отдельные счета для разных

00:16:15.940 --> 00:16:20.660
юридических лиц, валют или целей платежа. Когда финансовый отдел готовит платеж, система должна знать,

00:16:20.800 --> 00:16:24.680
с какого банковского счета он будет профинансирован. В противном случае сотрудники могут создать

00:16:24.680 --> 00:16:29.420
корректный платеж по неверному счету. Сроки оплаты также требуют внимания. Оплата после установленного

00:16:29.420 --> 00:16:33.400
срока может привести к напоминаниям, спорам или испорченным отношениям с поставщиком. Слишком

00:16:33.400 --> 00:16:38.860
ранняя оплата выводит наличные средства раньше, чем это необходимо компании. Dynamics 365 сохраняет

00:16:38.860 --> 00:16:43.180
видимость срока оплаты счета, чтобы финансовый отдел мог планировать платежи с учетом условий

00:16:43.180 --> 00:16:48.720
каждого поставщика, обеспечивая компании контроль над денежными потоками. Dynamics 365 должна

00:16:48.720 --> 00:16:53.140
ответить на простой вопрос. Какой именно счет покрыл этот платеж? Ответ – выверка.

00:16:53.340 --> 00:16:57.340
Выверка связывает платеж с конкретным счетом поставщика или счетами, которые он закрывает.

00:16:57.420 --> 00:17:01.660
Представьте это как сопоставление чека со счетом, который он оплачивает. Без выверки компания

00:17:01.660 --> 00:17:05.900
может видеть счет и платеж по одному и тому же поставщику, но не иметь четкого подтверждения,

00:17:05.900 --> 00:17:10.280
что они связаны. Полный платеж закрывает весь счет, но в бизнесе не всегда все так просто.

00:17:10.280 --> 00:17:14.440
Компания может оплатить только часть счета сейчас, а остаток – позже. Выверка фиксирует

00:17:14.440 --> 00:17:17.540
частичный платеж и оставляет остаток открытым, чтобы финансовый отдел видел,

00:17:17.720 --> 00:17:21.360
сколько еще причитается поставщику. Эта прозрачность критически важна для точного учета

00:17:21.360 --> 00:17:25.380
балансов поставщиков. Один платеж также может покрывать сразу несколько счетов. Возможно,

00:17:25.640 --> 00:17:29.180
компания оплачивает пять счетов одного поставщика одним электронным платежом.

00:17:29.360 --> 00:17:33.040
Взаимозачет связывает эту единую исходящую сумму с каждым оплаченным счетом.

00:17:33.040 --> 00:17:37.340
Если платеж не покрывает все счета полностью, открытый остаток остается понятным,

00:17:37.340 --> 00:17:41.100
а не теряется в запутанной итоговой сумме. Это создает очлеживаемую запись,

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

00:17:44.520 --> 00:17:48.440
Увидьте платеж, подготовленный в журнале, и так, как этот платеж погасил задолженность

00:17:48.440 --> 00:17:51.840
перед поставщиком. Когда кто-то спрашивает, почему деньги покинули компанию,

00:17:52.080 --> 00:17:55.120
финансовому отделу не нужно восстанавливать историю по письмам и выпискам.

00:17:55.280 --> 00:18:00.100
Процесс может отображаться на разных страницах Dynamics 365, но каждая запись связана

00:18:00.100 --> 00:18:04.540
с другой в единый контролируемый поток, формируя целостную картину кредиторской задолженности.

00:18:04.540 --> 00:18:08.780
Представьте, что вы получили один счет на канцелярские товары. Запись о поставщике

00:18:08.780 --> 00:18:13.180
содержит правила оплаты, а импортированный счет добавляет детали платежа и сам документ.

00:18:13.340 --> 00:18:17.320
Отдел закупок предоставляет заказ на поставку. Отдел приемки предоставляет накладную,

00:18:17.540 --> 00:18:20.900
чтобы процесс сверки опирался на реальные документы. Затем, в фоновом режиме,

00:18:21.060 --> 00:18:24.040
профиль разноски относит задолженность и расходы на нужные счета главной книги.

00:18:24.180 --> 00:18:28.380
Управление банком и кассой контролирует метод оплаты и банковский счет, с которого списываются

00:18:28.380 --> 00:18:32.880
средства. Вложение остается привязанным к транзакции, поэтому вы всегда сможете открыть

00:18:32.880 --> 00:18:37.140
исходный счет для проверки. Автоматизация не заменяет суждений финансовой команды.

00:18:50.360 --> 00:19:10.200
Нагрев. Нагрев.