WEBVTT

00:00:00.000 --> 00:00:03.520
Вы совершили продажу, вы отправили счет, но когда деньги на самом деле поступят на ваш счет?

00:00:03.640 --> 00:00:06.720
И что будет, если они не поступят? Добро пожаловать в очередной выпуск

00:00:06.720 --> 00:00:12.260
Крупиц знаний Microsoft на М365FM. Я Мерка Питерс. Сегодня мы разберем дебиторскую задолженность

00:00:12.260 --> 00:00:17.600
в Dynamics 365 простыми словами. К концу этого выпуска вы проследите баланс одного клиента от

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

00:00:22.580 --> 00:00:26.480
определение. Дебиторская задолженность очлеживает деньги, которые должны вам клиенты,

00:00:26.480 --> 00:00:30.780
а также поступающие от них платежи. Представьте это как картотеку для денег внутри вашего

00:00:30.780 --> 00:00:35.400
бизнеса. У каждого клиента есть своя папка. В этой папке хранятся их счета, платежи,

00:00:35.560 --> 00:00:40.020
сроки оплаты и вся последующая работа. Конечно, в электронной таблице можно перечислить эти данные,

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

00:00:44.080 --> 00:00:50.180
решение во всей компании. Dynamics 365 финанс может. Итак, начнем с самого начала с учетной записи

00:00:50.180 --> 00:00:55.240
клиента. Первая учетная запись клиента – отправная точка для каждого счета. Представьте,

00:00:55.240 --> 00:00:59.700
что вы работаете с клиентом под названием Nordwind Equipment. Прежде чем они смогут оформить заказ,

00:00:59.860 --> 00:01:04.520
Dynamics 365 потребуется нечто большее, чем просто имя и номер телефона. Системе нужны финансовые

00:01:04.520 --> 00:01:09.320
правила ведения бизнеса с Nordwind. Учетная запись клиента – это та самая подписанная папка в нашей

00:01:09.320 --> 00:01:14.900
картотеке. В ней хранятся все данные, которые сообщают Dynamics 365, кто такой клиент, куда отправлять

00:01:14.900 --> 00:01:19.040
счета, как они обычно платят и какой объем кредита компания готова им предоставить. Это может

00:01:19.040 --> 00:01:23.500
показаться базовой настройкой, но она предотвращает массу путаницы в будущем. Например, в учетной записи

00:01:23.500 --> 00:01:27.120
хранится адрес клиента для выставления счетов. Часто он отличается от адреса доставки.

00:01:27.280 --> 00:01:31.220
Оборудование может быть отправлено на завод, а счета – в финансовый отдел. Там также хранятся

00:01:31.220 --> 00:01:35.460
условия оплаты. Условия оплаты отвечают на простой вопрос. Сколько времени у клиента есть на оплату?

00:01:35.560 --> 00:01:40.140
Nordwind может платить в течение 30 дней. Другой клиент может платить авансом. Более крупный клиент

00:01:40.140 --> 00:01:45.120
может договориться о 60 днях. Как только эти условия внесены в учетную запись, Dynamics 365 автоматически

00:01:45.120 --> 00:01:48.460
рассчитывает срок оплаты. Никому не нужно искать цепочки электронных писем или гадать,

00:01:48.460 --> 00:01:52.800
отчитываются ли 30 дней с даты заказа, даты доставки или даты счета. Система просто это знает.

00:01:52.960 --> 00:01:56.920
И вот в чем дело. В учетной записи клиента также хранится обычный способ оплаты. Если

00:01:56.920 --> 00:02:00.460
Nordwind платит банковским переводом, а другой клиент – кредитной картой, финансовая команда

00:02:00.460 --> 00:02:03.980
следует правильному процессу в момент оплаты. Им не приходится рассматривать каждого клиента

00:02:03.980 --> 00:02:07.980
как разовый случай. И еще есть кредитный лимит. Кредитный лимит – это максимальная сумма,

00:02:07.980 --> 00:02:11.500
которую компания готова позволить клиенту задолжать единовременно. Представьте себе стойку

00:02:11.500 --> 00:02:15.380
регистрации в офисном здании. Администратор проверяет, разрешен ли кому-то доступ на другой

00:02:15.380 --> 00:02:18.820
этаж. Не то, приятный ли это посетитель, а просто позволяют ли правила его пропустить.

00:02:19.020 --> 00:02:23.040
Здесь та же идея. Кредитный лимит устанавливает четкую границу для отделов продаж и финансов.

00:02:23.160 --> 00:02:26.040
Nordwind может быть надежным клиентом, но если они уже должны крупную сумму,

00:02:26.160 --> 00:02:28.800
компании стоит повременить, прежде чем принимать еще один большой заказ.

00:02:28.940 --> 00:02:32.980
За кулисами Dynamics 365 также использует группы клиентов и профиль разноски.

00:02:32.980 --> 00:02:36.720
Пусть вас не пугают эти названия. Группа клиентов – это просто способ объединить

00:02:36.720 --> 00:02:40.780
похожих клиентов. Розничные клиенты – в одну группу, оптовые – в другую. Так компания

00:02:40.780 --> 00:02:44.260
может применять общие правила там, где это целесообразно. Профиль разноски – это

00:02:44.260 --> 00:02:48.440
бухгалтерское правило, которое указывает Dynamics 365, на какие финансовые счета записывать

00:02:48.440 --> 00:02:52.520
долг при поступлении счета фактуры. Обычно вы не увидите эту работу как продавец или клиент,

00:02:52.660 --> 00:02:56.140
но финансовый отдел полагается на нее, потому что в бухгалтерских книгах каждая сумма должна

00:02:56.140 --> 00:03:00.720
быть на своем месте. А вот в чем настоящая сила. Учетная запись клиента связывает отдел продаж

00:03:00.720 --> 00:03:04.740
с финансовым отделом. Продавец может создать заказ для Nordwind, и финансистам не нужно будет

00:03:04.740 --> 00:03:09.120
воссоздавать эту информацию позже. Они видят клиента, условия оплаты, кредитную позицию и сумму

00:03:09.120 --> 00:03:13.500
к оплате. Все связывается автоматически. В этом разница между списком контактов и учетной записью

00:03:13.500 --> 00:03:17.520
клиента. Список контактов помогает вам позвонить кому-то. Учетная запись клиента фиксирует

00:03:17.520 --> 00:03:21.240
финансовые отношения, включая правила, которые регулируют процесс продаж этой компании.

00:03:21.420 --> 00:03:26.040
Поэтому, как только Nordwind что-то покупает, Dynamics 365 должна превратить эту продажу в

00:03:26.040 --> 00:03:31.800
надлежащий запрос на оплату. 2. Создание счета фактуры – превращение продажи в задолженность.

00:03:31.900 --> 00:03:36.100
Так в чем разница между заказом и счетом фактуры? Заказ говорит о том, что хочет клиент,

00:03:36.220 --> 00:03:40.720
а счет фактура – о том, что он должен заплатить. Вот в чем дело. Счет фактура создает открытый баланс

00:03:40.720 --> 00:03:44.240
на учетные записи клиента. Как только он разнесен, вы официально выставляете им счет,

00:03:44.360 --> 00:03:46.600
и отдел дебиторской задолженности может отслеживать платежи.

00:03:46.700 --> 00:03:50.000
Давайте вернемся к Nordwind Экипмент. Они заказали 10 единиц оборудования,

00:03:50.220 --> 00:03:53.420
ваш отдел продаж регистрирует заказ, склад готовит товары, а вы их отправляете.

00:03:53.560 --> 00:03:56.680
Теперь оборудование у Nordwind. В этот момент вам нужна четкая запись о том,

00:03:56.800 --> 00:03:59.280
что они купили, сколько это стоит и когда наступает срок оплаты.

00:03:59.380 --> 00:04:03.560
Такой записью является счет фактура клиента. Большинство счетов фактур в Dynamics 365 финанс

00:04:03.560 --> 00:04:06.300
создаются непосредственно на основе заказа на продажу. Это позволяет сохранить

00:04:06.300 --> 00:04:10.600
связь счета фактурой с исходной продажей. Товары клиента, цены, количество и все согласованные

00:04:10.600 --> 00:04:14.580
правила уже есть в системе. Вам не нужно, чтобы кто-то заново вводил эти данные в отдельную

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

00:04:18.020 --> 00:04:22.320
подлежащего оплате, вы создаете счет на основе этого заказа на продажу. Точные сроки зависят от того,

00:04:22.500 --> 00:04:26.660
как работает ваша компания. Некоторые компании выставляют счета при отгрузке, другие – после завершения

00:04:26.660 --> 00:04:30.300
этапа работ. Консалтинговая фирма может выставить счет после выполнения определенного этапа.

00:04:30.300 --> 00:04:35.600
Dynamics 365 следует тем процессам, которые вы уже настроили. Возможно, вы слышали термин «счет на

00:04:35.600 --> 00:04:39.880
основе упаковочного листа». Упаковочный лист подтверждает, что физически покинуло склад и перешло

00:04:39.880 --> 00:04:43.640
на стадию доставки. Если ваша компания выставляет счета на основе фактически отгруженных товаров,

00:04:43.800 --> 00:04:46.960
в счете можно использовать эти подтвержденные данные о доставке. Это позволяет избежать

00:04:46.960 --> 00:04:50.280
распространенные проблемы. Предположим, заказ на 10 единиц, но сегодня отгружено только 8,

00:04:50.280 --> 00:04:53.420
так как 2 еще ожидают поступления на склад. Если вы выставляете счет на основе упаковочного листа,

00:04:53.560 --> 00:04:57.500
вы выставляете его только за 8 отгруженных единиц. Вы не берете Smartwind плату за все 10 единиц до того,

00:04:57.500 --> 00:05:01.400
как они их получат. Заказ по-прежнему важен, но подтвержденная доставка указывает бухгалтерии,

00:05:01.580 --> 00:05:05.500
что именно должно быть в счете. Но не каждый счет начинается с заказа на продажу. Иногда нужно

00:05:05.500 --> 00:05:09.660
выставить счет за разовую услугу, не связанную с доставкой. Может быть, Нортвин запрашивает

00:05:09.660 --> 00:05:13.380
специальный тренинг. Возможно, есть сервисный сбор, плата за проект или корректировка,

00:05:13.540 --> 00:05:18.100
требующая отдельного счета. Для таких случаев в Dynamics 365 финанс предусмотрен счет со свободным

00:05:18.100 --> 00:05:22.980
текстом. Свободный текст не означает случайный или неформальный. Это означает, что счет не привязан к заказу на

00:05:22.980 --> 00:05:26.980
продажу. Вы указываете клиента, статью начислений, сумму, при необходимости данные по налогам и

00:05:26.980 --> 00:05:30.680
платежную информацию. После разноски он становится обычной суммой задолженности на счете клиента.

00:05:30.820 --> 00:05:34.600
Клиент по-прежнему получает полноценный счет. Финансовый отдел по-прежнему видит открытый баланс.

00:05:34.740 --> 00:05:38.480
А как насчет периодических работ? Предположим, Нортвин платит ежемесячный взнос за обслуживание

00:05:38.480 --> 00:05:42.480
оборудования. Создание одного и того же счета вручную каждый месяц – это трата времени и риск допустить

00:05:42.480 --> 00:05:46.840
мелкие ошибки. Биллинг подписок использует графики выставления счетов для обработки регулярных платежей.

00:05:46.840 --> 00:05:52.240
Вы настраиваете соглашение и график оплат, а затем Dynamics 365 создает счета по мере наступления

00:05:52.240 --> 00:05:56.080
каждого периода. Это дает вам надежный способ выставления счетов за регулярные услуги,

00:05:56.300 --> 00:06:00.140
а клиент получает счета в соответствии с согласованным графиком. Разноска – это момент,

00:06:00.340 --> 00:06:04.600
который меняет статус продажи. Она записывает сумму на счете клиента Нортвин как сумму

00:06:04.600 --> 00:06:08.360
задолженности. Она также отправляет сумму в финансовые отчеты компании, где видно,

00:06:08.640 --> 00:06:12.520
что продажа выставлена в счет, а оплата еще не поступила. Счет больше не является черновиком,

00:06:12.740 --> 00:06:16.000
который кто-то может случайно изменить. Теперь он является частью финансовой отчетности.

00:06:16.000 --> 00:06:19.700
Давайте разберем на конкретном примере. Нортвинд заказывает оборудование на сумму 10 тысяч

00:06:19.700 --> 00:06:23.400
долларов. Сначала отгружаются 8 единиц товара, поэтому вы выставляете счет на эти 8 единиц.

00:06:23.540 --> 00:06:27.700
В счете указаны сумма, срок оплаты и инструкции по платежу. Нортвинд получает счет,

00:06:27.880 --> 00:06:32.480
а Dynamics 365 фиксирует эту же сумму как открытую задолженность на их счете. Эта общая запись

00:06:32.480 --> 00:06:35.840
позволяет отделу продаж, сотрудникам склада и финансовому отделу работать с одной и той же

00:06:35.840 --> 00:06:40.420
транзакцией. Больше никаких споров из-за разных версий файлов, однако счет – это лишь запрос на оплату.

00:06:40.420 --> 00:06:44.320
Следующая задача – распознать поступивший платеж и привязать его к нужному открытому сальдо.

00:06:44.440 --> 00:06:48.060
Два. Три. Получение и сопоставление платежей. Закрытие соответствующего счета.

00:06:48.180 --> 00:06:51.340
Поступление платежа кажется простым процессом. Баланс на банковском счете увеличивается,

00:06:51.540 --> 00:06:55.140
значит, работа сделана. Верно. Не совсем. Финансовому отделу нужно ответить на два

00:06:55.140 --> 00:06:59.300
вопроса. Кто отправил деньги и какой открытый счет или счета должны быть закрыты этим платежом?

00:06:59.420 --> 00:07:03.380
Представьте, что Нортвинд оплачивает счет за оборудование. В банковской выписке платеж может

00:07:03.380 --> 00:07:07.260
отображаться с кратким комментарием, суммой и датой. Если не сопоставить этот платеж с открытой

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

00:07:10.940 --> 00:07:13.480
что Нортвинд все еще должен. Эти записи должны встретиться.

00:07:13.680 --> 00:07:18.820
Dynamics 365 финанс поддерживает несколько способов оплаты для клиентов. Вы можете получать

00:07:18.820 --> 00:07:22.360
наличные, чеки, платежи по кредитным картам, банковские переводы или переводные векселя,

00:07:22.580 --> 00:07:25.260
официальные платежные документы, используемые в некоторых бизнес-процессах.

00:07:25.360 --> 00:07:28.980
Каждый метод проходит свой собственный путь к финансовым записям. Банковский перевод

00:07:28.980 --> 00:07:33.240
может появиться в выписке по счету. Чек может потребовать регистрации до того, как банк его проведет.

00:07:33.240 --> 00:07:35.620
Оплата карты может поступить через платежный сервис.

00:07:35.620 --> 00:07:39.660
Dynamics 365 предоставляет финансовому отделу место для регистрации данных о платежах по нужному

00:07:39.660 --> 00:07:43.700
клиентскому счету. Таким местом часто является журнал платежей клиентов. Журнал звучит как

00:07:43.700 --> 00:07:48.140
бумажная книга учета, но в Dynamics 365 это просто контролируемая область для ввода и проверки

00:07:48.140 --> 00:07:52.280
платежей перед их проведением. Финансовый отдел фиксирует клиента, сумму, способ оплаты,

00:07:52.480 --> 00:07:56.820
банковский счет и любые данные, сопровождавшие платеж. Затем идет термин, который часто звучит

00:07:56.820 --> 00:08:01.040
сложнее, чем есть на самом деле «выверка». «Выверка» означает сопоставление платежа со счетом,

00:08:01.040 --> 00:08:05.300
который он оплачивает. Нортвинт оплачивает точную сумму по счету за оборудование. Финансовый

00:08:05.300 --> 00:08:09.620
отдел выбирает платеж и открытый счет, а затем проводит их выверку. После проведения счет больше

00:08:09.620 --> 00:08:14.640
не отображается как неоплаченный. Платеж закрыл его. Сальдо клиента уменьшается на соответствующую

00:08:14.640 --> 00:08:19.100
сумму. Это важно, потому что платеж без выверки может оставить открытый счет висеть на аккаунте,

00:08:19.260 --> 00:08:23.960
даже если деньги уже получены. Это ведет к плохим отчетам, ненужным напоминаниям и неловким звонкам

00:08:23.960 --> 00:08:28.320
клиентам, которые уже заплатили. Иногда платеж не покрывает весь счет целиком. Возможно,

00:08:28.320 --> 00:08:33.520
Нортвинт оплатит часть суммы сейчас, а остальное – позже. Dynamics 365 позволяет закрыть

00:08:33.520 --> 00:08:37.740
поступившую сумму по счету, оставляя неоплаченную часть открытой. Счет не исчезает только потому,

00:08:37.980 --> 00:08:42.160
что поступила часть денег. Финансовый отдел точно видит, какая сумма осталась. Это гораздо лучше,

00:08:42.320 --> 00:08:45.840
чем по ошибке пометить счет как полностью оплаченный, а потом пытаться вспомнить недостающую

00:08:45.840 --> 00:08:50.000
сумму в заметках или отдельной таблице. Во многие компании банковские платежи поступают в большом

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

00:08:54.640 --> 00:08:58.960
клиенты оплачивают несколько счетов сразу или указывают не вполне понятное назначение платежа.

00:08:59.100 --> 00:09:04.300
В Dynamics 365 для этой работы есть журнал выверки платежей. Сотрудники могут импортировать

00:09:04.300 --> 00:09:08.560
банковскую выписку и использовать ее для сопоставления входящих платежей с открытыми счетами

00:09:08.560 --> 00:09:13.220
клиентов. Платежные реквизиты, суммы, данные клиентов и правила сопоставления помогают системе

00:09:13.220 --> 00:09:17.920
определить, к какому счету относится платеж. Вы все равно проверяете результат – это важный этап.

00:09:18.120 --> 00:09:22.600
Автоматизация сокращает поиск, но ответственность за то, что платеж закрывает нужный счет,

00:09:22.600 --> 00:09:26.560
остается на финансовом отделе. Если клиент отправляет один платеж за несколько счетов,

00:09:26.740 --> 00:09:30.340
ответственный сотрудник может распределить этот платеж по этим счетам. Если в назначении

00:09:30.340 --> 00:09:33.860
платежа указан неверный документ, его можно исправить перед проводкой. Цель не в том,

00:09:34.000 --> 00:09:37.840
чтобы исключить участие человека, а в том, чтобы избавить сотрудников от бесконечного поиска в

00:09:37.840 --> 00:09:41.520
банковских файлах и списках счетов. Теперь представьте, что Нортвинд ведет деятельность

00:09:41.520 --> 00:09:45.240
через несколько компаний в рамках одной бизнес-группы. Одно юридическое лицо может продавать

00:09:45.240 --> 00:09:48.700
оборудование, а центральная финансовая компания – получать платежи для всей группы.

00:09:48.700 --> 00:09:52.560
Dynamics 365 поддерживает централизованные платежи для таких ситуаций.

00:09:52.600 --> 00:09:56.680
Платеж можно зарегистрировать в одном юридическом лице от имени другого. Компании не нужно

00:09:56.680 --> 00:10:00.700
делать вид, что деньги сначала поступили в продающую организацию или вести этот процесс

00:10:00.700 --> 00:10:05.060
вне системы. Записи могут показать, где был получен платеж и какую задолженность клиента он

00:10:05.060 --> 00:10:08.380
закрывает. Это упрощает общую финансовую работу, особенно когда несколько компаний

00:10:08.380 --> 00:10:12.380
используют единую группу по работе с денежными средствами. Таким образом, полный процесс оплаты – это

00:10:12.380 --> 00:10:16.600
больше, чем просто регистрация денег в банке. Dynamics 365 связывает клиента,

00:10:16.600 --> 00:10:20.820
платеж и счет, пока баланс не будет закрыт или пока остаток не укажет финансовому отделу на

00:10:20.820 --> 00:10:23.820
необходимость дальнейших оплат. На этом сегодняшний платеж закрыт.

00:10:23.920 --> 00:10:28.200
Следующий вопрос возникает перед следующей продажей. Стоит ли компании позволять клиенту

00:10:28.200 --> 00:10:32.580
занимать еще больше? Четвертое – управление кредитами, принятие решения о продолжении

00:10:32.580 --> 00:10:37.900
продаж. Итак, вы получаете платеж, и он гасит старый баланс. Довольно просто, правда. Но вот что

00:10:37.900 --> 00:10:41.840
управление кредитами спрашивает перед тем, как перейти к следующему заказу. На какой еще риск

00:10:41.840 --> 00:10:46.140
готова пойти ваша компания? Вспомните стойку регистрации в отеле. Гость хочет остаться еще на

00:10:46.140 --> 00:10:50.020
одну ночь, поэтому персонал проверяет бронирование, статус оплаты и правила, прежде чем выдать новую

00:10:50.020 --> 00:10:53.720
карту от номера. Именно так работает управление кредитами в отношении заказов на продажу.

00:10:53.900 --> 00:10:57.800
Система не оценивает, является ли Нортвинд Экипмент хорошим клиентом в целом. Она просто

00:10:57.800 --> 00:11:01.100
сверяет их текущее финансовое положение с правилами, установленными в вашей компании.

00:11:01.340 --> 00:11:04.680
Одно из этих правил – кредитный лимит. Кредитный лимит – это максимальная сумма,

00:11:04.820 --> 00:11:09.060
которую клиент может быть должен в любой момент времени. Так, если у Нортвинд лимит 50 тысяч долларов,

00:11:09.340 --> 00:11:14.020
а долг уже 45 тысяч, новый заказ на 20 тысяч долларов требует внимания. Клиент все еще может

00:11:14.020 --> 00:11:19.340
оформить заказ, но ваш бизнес не должен упускать это решение из виду. Dynamics 365 может проверять

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

00:11:24.040 --> 00:11:28.340
заказа и доступный для клиента кредитный лимит. Клиент, который платит вовремя, может иметь

00:11:28.340 --> 00:11:32.620
запас по кредиту, в то время как у другого клиента лимит не превышен, но есть счета с серьезной

00:11:32.620 --> 00:11:37.960
просрочкой. Это разные риски. При срабатывании правила Dynamics 365 может поставить заказ на

00:11:37.960 --> 00:11:42.240
кредитное удержание, приостанавливая его до отправки товаров или выполнения неоплаченных работ.

00:11:42.240 --> 00:11:46.880
Отдел продаж видит удержание, финансовый отдел – его причину, и никто не узнает о проблеме

00:11:46.880 --> 00:11:51.360
постфактум, когда товар уже отгружен. Кредитное удержание не означает, что заказ отклонен

00:11:51.360 --> 00:11:56.340
навсегда. Это означает, что его нужно пересмотреть. Возможно, Нортвинт подтвердил оплату,

00:11:56.500 --> 00:12:01.600
или финансовый менеджер знает об ошибке в счетах, или клиент попросил временное увеличение

00:12:01.600 --> 00:12:06.160
лимита из-за крупного проекта. Уполномоченный персонал может разблокировать заказ при наличии

00:12:06.160 --> 00:12:10.660
веских причин. Это важно, поскольку бизнес-правила должны учитывать реалии жизни. Система может

00:12:10.660 --> 00:12:14.200
остановить автоматическое решение, но ответственные сотрудники решают, что делать дальше,

00:12:14.200 --> 00:12:18.260
оставляя четкий след своего решения. Здесь отделы продаж и финансов должны работать с единой

00:12:18.260 --> 00:12:22.380
картиной данных. Отделу продаж важно поддерживать клиента, особенно с крупным заказом,

00:12:22.560 --> 00:12:26.800
а финансом – защитить компанию от накопления невозвратных долгов. Никому не нужно доказывать

00:12:26.800 --> 00:12:31.560
свою правоту в споре. Им просто нужно видеть заказ, неоплаченную сумму и кредитные правила в одном

00:12:31.560 --> 00:12:36.660
месте. Многие слышат управление кредитами и думают, что это значит отказ клиентам. Это не так,

00:12:36.760 --> 00:12:40.360
это значит установить безопасные границы, прежде чем задержка платежа превратится в серьезную

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

00:12:43.980 --> 00:12:47.920
продавать уверенно. Вы просто перестаете увеличивать долг, не проверив предварительно все факты.

00:12:48.040 --> 00:12:51.820
Как только срок оплаты по счету истекает, на смену профилактики приходит контроль.

00:12:51.920 --> 00:12:56.220
Пятое – взыскание задолженности и споры, как получить оплату, не теряя клиента.

00:12:56.380 --> 00:13:01.180
Когда наступает срок оплаты, задача меняется. Компания больше не решает, предоставлять ли кредит.

00:13:01.340 --> 00:13:04.620
Ей нужен ясный и уважительный способ запросить средства, срок оплаты которых уже вышел.

00:13:04.760 --> 00:13:08.240
Dynamics 365 финанс переносит эту работу на страницу взыскания задолженности.

00:13:08.300 --> 00:13:12.160
Представьте это как общий рабочий стол для просроченных счетов клиентов. Вместо того,

00:13:12.160 --> 00:13:17.540
чтобы один сотрудник вел записи в почте, другой очлеживал звонки в таблице, а кто-то еще проверял

00:13:17.540 --> 00:13:22.620
счета в финансах, команда видит баланс клиента и историю действий в одном месте. Это меняет

00:13:22.620 --> 00:13:27.660
характер общения. Агент по взысканию работает со списками, созданными по критериям,

00:13:27.680 --> 00:13:33.320
которые позволяют найти клиентов с просрочкой на определенное число дней, превышающие нужную сумму

00:13:33.320 --> 00:13:38.560
или требующие внимания по правилам компании. Таким образом, команде не нужно гадать, кому звонить

00:13:38.560 --> 00:13:42.500
в первую очередь. Для каждого клиента агент может принять меры, отправить напоминания,

00:13:42.720 --> 00:13:46.420
создать письмо о задолженности, написать по электронной почте или запланировать телефонный

00:13:46.420 --> 00:13:50.740
звонок. Цель состоит не в том, чтобы рассылать гневные сообщения. Большинство задержек платежей

00:13:50.740 --> 00:13:56.080
начинаются с обычных вещей. Например, счет попал не в тот почтовый ящик, клиенту нужна копия или отдел

00:13:56.080 --> 00:14:01.220
платежей пропустил срок. Спокойное напоминание может многое решить. Иногда клиент отвечает обещанием

00:14:01.220 --> 00:14:06.220
оплатить в следующую пятницу. Dynamics 365 позволяет зафиксировать это как обещание платежа,

00:14:06.220 --> 00:14:10.180
чтобы команда знала о договоренности и могла проверить, поступили ли деньги вовремя. Без такой

00:14:10.180 --> 00:14:14.580
записи следующий агент может позвонить тому же клиенту на следующее утро, не зная, что дата уже

00:14:14.580 --> 00:14:19.460
согласована. Спорные ситуации требуют такого же внимательного подхода. Спор означает, что клиент

00:14:19.460 --> 00:14:24.640
оспаривает весь счет или его часть. Возможно, из-за неверной цены, недопоставки товаров или потому,

00:14:24.800 --> 00:14:29.340
что счет включает работы, которые клиент не утверждал. Худшее, что можно сделать, это позволить

00:14:29.340 --> 00:14:34.780
проблеме затеряться в почтовом ящике. Dynamics 365 позволяет пометить счет как спорный и держать его на виду

00:14:34.780 --> 00:14:38.340
при работе с задолженностью. Команда может отслеживать статус и процесс решения проблемы,

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

00:14:42.240 --> 00:14:46.400
Это также помогает бизнесу выявлять повторяющиеся проблемы. Если несколько клиентов оспаривают

00:14:46.400 --> 00:14:50.720
один и тот же тип начислений, финансовый отдел узнает нечто большее, чем просто факт задержки оплаты.

00:14:50.860 --> 00:14:54.700
Возможно, отделом продаж, доставки, биллинга или обслуживания клиентов нужно исправить процесс,

00:14:54.860 --> 00:14:58.560
порождающий такие споры. Для взыскания также используются отчеты о старении дебиторской задолженности,

00:14:58.560 --> 00:15:02.260
которые сортируют неоплаченные суммы по длительности просрочки. Вы можете видеть суммы к оплате сейчас,

00:15:04.780 --> 00:15:07.840
эти временные интервалы помогают команде понять, какие задолженности требуют внимания,

00:15:07.980 --> 00:15:11.340
прежде чем они перерастут в гораздо более сложный разговор. Счет, просроченный на два дня,

00:15:11.520 --> 00:15:15.280
не всегда требует такой же реакции, как тот, который не оплачен в течение трех месяцев.

00:15:15.440 --> 00:15:19.640
Финансовый отдел также может использовать прогнозы платежей, если они доступны, чтобы оценить,

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

00:15:24.360 --> 00:15:28.700
платежах и данных клиента. Отчет о дебиторской задолженности показывает то, что уже произошло,

00:15:28.700 --> 00:15:33.040
а прогноз помогает команде определить приоритеты до того, как очередная просрочка создаст проблему.

00:15:33.040 --> 00:15:37.260
Это не заменяет необходимость принятия решений. Это дает отделу по работе с задолженностями

00:15:37.260 --> 00:15:42.100
дополнительный сигнал, когда им нужно сделать выбор из длинного списка счетов. Цель проста – взимать

00:15:42.100 --> 00:15:47.120
средства стабильно и прозрачно, относясь к клиенту как к человеку, а не как к номеру дела.

00:15:47.280 --> 00:15:50.480
А теперь давайте разберем весь процесс на одном простом примере.

00:15:51.060 --> 00:15:54.600
6. Один счет. Один связанный процесс. Общая картина.

00:15:54.600 --> 00:15:59.220
Итак, давайте проследим, что происходит, когда Нортвинд размещает заказ, ваша система обрабатывает

00:15:59.220 --> 00:16:03.200
его, и как только наступает согласованный момент выставления счета, счет отправляется клиенту.

00:16:03.300 --> 00:16:07.980
В учетной записи клиента уже указаны условия оплаты, поэтому Dynamics 365 автоматически

00:16:07.980 --> 00:16:10.820
рассчитывает срок платежа на основе правил, согласованных с Нортвинд.

00:16:10.960 --> 00:16:14.900
Финансовый отдел видит открытую сумму, а клиент получает четкий запрос на оплату.

00:16:15.000 --> 00:16:19.140
Это начало процесса. Через несколько недель Нортвинд отправляет банковский платеж с указанием

00:16:19.140 --> 00:16:22.620
номера счета. Финансовый отдел сопоставляет платеж со счетом, а затем закрывает его.

00:16:22.620 --> 00:16:26.660
Открытый баланс закрывается, и в учетной записи клиента отображается, что эта часть сделки

00:16:26.660 --> 00:16:30.840
завершена. Никаких ручных сверок не требуется. Но что происходит, если все идет иначе?

00:16:30.960 --> 00:16:34.260
Если Нортвинд пропускает срок оплаты, счет переходит в отдел по работе с задолженностями.

00:16:34.460 --> 00:16:37.720
Сотрудник отправляет напоминание, Нортвинд отвечает, что часть начислений неверна,

00:16:37.860 --> 00:16:41.520
и команда фиксирует спор, вместо того, чтобы рассматривать это как необъяснимую просрочку платежа.

00:16:41.640 --> 00:16:45.460
Все видят одинаковый статус и знают, какое действие предпринять дальше, потому что вся информация

00:16:45.460 --> 00:16:50.640
находится в одном месте. В этом преимущество Dynamics 365 финанс. Здесь ничто не остается разрозненным.

00:16:50.640 --> 00:16:55.040
Заказы на продажу, счета, платежи, проверки кредитоспособности и работа по взысканию – все это

00:16:55.040 --> 00:16:58.900
связано с одними и теми же отношениями с клиентом, поэтому вам не нужно искать информацию в разных

00:16:58.900 --> 00:17:03.680
системах. Это означает более быстрые решения и меньше ошибок. Раньше данные были разбросаны по

00:17:03.680 --> 00:17:08.280
таблицам, папкам электронной почты, бумажным заметкам и банковским файлам, и люди тратили время,

00:17:08.480 --> 00:17:13.400
выясняя, какая версия верна. Dynamics 365 сохраняет целостность данных, предоставляя единый обзор

00:17:13.400 --> 00:17:17.680
взаимодействия с клиентом от начала до конца. Дебиторская задолженность – это значит знать, кто должен вам деньги,

00:17:17.680 --> 00:17:21.480
когда наступает срок оплаты, что уже произошло и что нужно сделать дальше. Если какой-то элемент

00:17:21.480 --> 00:17:25.580
отсутствует, компания может много продавать, но все равно не понимать, где ее деньги. Вот почему

00:17:25.580 --> 00:17:30.620
этот связанный процесс так важен. Заключение. Держите внутренние финансы под контролем.

00:17:31.180 --> 00:17:36.020
Счет лишь запускает процесс. Очлеживает ли ваша дебиторская задолженность поступления средств

00:17:36.020 --> 00:17:40.760
до закрытия баланса или принятия мер по неоплате? Контроль за этими деньгами внутри компании

00:17:40.760 --> 00:17:45.180
критически важен для здоровья бизнеса. Я Мирко Питерс. Подпишитесь на Microsoft Knowledge

00:17:45.180 --> 00:17:50.300
Magnets на М365FM. Затем посмотрите связанный эпизод Dynamics 365 финанс на экране,

00:17:50.400 --> 00:17:52.040
чтобы и дальше прояснять все простыми словами.