WEBVTT

00:00:00.000 --> 00:00:03.440
Ви здійснили продаж, надіслали рахунок, але коли гроші насправді надійдуть на ваш рахунок.

00:00:03.500 --> 00:00:05.320
І що станеться, якщо цього не відбудеться?

00:00:05.460 --> 00:00:09.260
Вітаємо в черговому епізоді Microsoft Knowledge Nuggets на M365FM.

00:00:09.440 --> 00:00:10.340
Я Мерко Пітерс.

00:00:10.480 --> 00:00:12.960
Сьогодні ми пояснимо роботу з дебіторською заборгованістю в Dynamics

00:00:12.960 --> 00:00:14.700
трьомастами шістдесятьма п'ятьма простою мовою.

00:00:14.880 --> 00:00:18.600
До кінця цього епізоду ви простежите баланс одного клієнта від продажу до оплати

00:00:18.600 --> 00:00:21.380
і побачите, що робить бізнес, коли платіж затримується.

00:00:21.560 --> 00:00:23.080
Ось найпростіше визначення.

00:00:30.000 --> 00:00:33.180
Кожен клієнт отримує окрему папку.

00:00:33.300 --> 00:00:37.440
У цій папці зберігаються їхні рахунки, платежі, терміни оплати та будь-яка подальша робота.

00:00:37.600 --> 00:00:41.300
Звісно, електронна таблиця може перелічити ці речі, але вона не може надійно пов'язати новий продаж

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

00:00:45.080 --> 00:00:47.420
Dynamics 365 Finance може.

00:00:47.540 --> 00:00:50.600
Отже, почнемо з самого початку, з облікового запису клієнта.

00:00:50.740 --> 00:00:54.600
Перше, обліковий запис клієнта – відправна точка для кожного рахунку.

00:00:54.600 --> 00:00:58.200
Уявіть, що ви працюєте з клієнтом під назвою Noswind Equipment.

00:00:58.340 --> 00:01:03.260
Перш ніж вони зможуть зробити замовлення, Dynamics 365 потрібно більше, ніж просто назва та номер телефону.

00:01:03.380 --> 00:01:05.940
Потрібні фінансові правила для ведення бізнесу з Noswind.

00:01:06.120 --> 00:01:09.720
Обліковий запис клієнта – це та сама підписана папка у нашій картотиці.

00:01:09.720 --> 00:01:15.400
Він містить усі деталі, які повідомляють Dynamics 365, хто такий клієнт, куди надсилати рахунки,

00:01:15.540 --> 00:01:18.460
як вони зазвичай платять і який кредит компанія готова надати.

00:01:18.460 --> 00:01:22.140
Це може здатися базовим налаштуванням, але воно запобігає багатьом плутанинам у майбутньому.

00:01:22.280 --> 00:01:25.060
Наприклад, обліковий запис зберігає адресу для виставлення рахунків клієнту.

00:01:25.240 --> 00:01:27.080
Вона часто відрізняється від адреси доставки.

00:01:27.240 --> 00:01:30.320
Обладнання може бути відправлене на завод, тоді як рахунки надходять у фінансовий відділ.

00:01:30.480 --> 00:01:31.960
Він також містить умови оплати.

00:01:31.960 --> 00:01:35.420
Умови оплати відповідають на просте запитання, скільки часу у цього клієнта на оплату.

00:01:35.560 --> 00:01:37.520
Noswind може платити протягом 30 днів.

00:01:37.680 --> 00:01:39.100
Інший клієнт платить наперед.

00:01:39.100 --> 00:01:41.400
Більший клієнт може домовитися про 60 днів.

00:01:41.580 --> 00:01:43.140
Як тільки ці умови внесені в обліковий запис,

00:01:43.280 --> 00:01:45.920
Dynamics 365 автоматично розраховує термін оплати.

00:01:46.080 --> 00:01:47.960
Нікому не потрібно шукати в листуванні чи вгадувати,

00:01:48.100 --> 00:01:51.340
чи означає NET30, термін віддати замовлення, доставки чи дати рахунку.

00:01:51.520 --> 00:01:52.740
Система просто це знає.

00:01:52.740 --> 00:01:53.880
Ось у чому справа.

00:01:53.980 --> 00:01:56.560
Обліковий запис клієнта також містить звичайний спосіб оплати.

00:01:56.720 --> 00:01:59.640
Якщо Noswind платить банківським переказом, а інший клієнт кредитною карткою,

00:01:59.640 --> 00:02:02.000
фінансовий відділ дотримується правильного процесу під час оплати.

00:02:02.200 --> 00:02:04.780
Їм не потрібно розглядати кожного клієнта як винятковий випадок.

00:02:04.920 --> 00:02:06.140
І ще є кредитний ліміт.

00:02:06.280 --> 00:02:07.720
Кредитний ліміт – це максимальна сума,

00:02:07.840 --> 00:02:10.340
яку компанія готова дозволити клієнту заборгувати одночасно.

00:02:10.480 --> 00:02:12.840
Уявіть, це як стійку реєстрації в офісній будівлі.

00:02:13.040 --> 00:02:15.480
Адміністратор перевіряє, чи дозволено комусь пройти на інший поверх,

00:02:15.600 --> 00:02:17.180
незважаючи на те, чи приємний відвідувач,

00:02:17.280 --> 00:02:18.680
а лише на те, чи дозволяють це правила.

00:02:18.800 --> 00:02:19.920
Тут така сама ідея.

00:02:19.920 --> 00:02:22.960
Кредитний ліміт встановлює чіткі межі для відділів продажу та фінансів.

00:02:23.100 --> 00:02:24.480
Носвінд може бути надійним клієнтом,

00:02:24.580 --> 00:02:26.200
але якщо вони вже винні велику суму бізнесу,

00:02:26.260 --> 00:02:28.640
варто зробити паузу, перш ніж приймати ще одне велике замовлення.

00:02:28.780 --> 00:02:31.440
За лаштунками Dynamics 365 також може використовувати

00:02:31.440 --> 00:02:32.940
групи клієнтів та профілі публікації.

00:02:33.120 --> 00:02:34.620
Нехай ці назви вас не лякають.

00:02:34.780 --> 00:02:37.560
Група клієнтів – це просто спосіб об'єднати схожих клієнтів.

00:02:37.700 --> 00:02:39.960
Роздрібна торгівля в одній групі, гуртова – в іншій.

00:02:39.960 --> 00:02:42.500
Таким чином бізнес може застосовувати спільні правила там,

00:02:42.600 --> 00:02:43.200
де це доцільно.

00:02:43.320 --> 00:02:44.920
Профіль публікації – це бухгалтерське правило,

00:02:45.040 --> 00:02:47.800
яке вказує Dynamics 365, на яких фінансових рахунках

00:02:47.800 --> 00:02:49.700
відображати заборгованість при надходженні рахунка.

00:02:49.820 --> 00:02:52.600
Ви зазвичай не бачите метецю роботу як продавець чи клієнт.

00:02:52.720 --> 00:02:54.300
Але фінансовий відділ залежить від цього,

00:02:54.400 --> 00:02:56.700
тому що в книгах кожна сума має бути на своєму місці.

00:02:56.860 --> 00:02:58.320
І ось у чому справжня сила.

00:02:58.500 --> 00:03:01.540
Клієнтський аккаунт пов'язує відділ продажу з фінансовим відділом.

00:03:01.540 --> 00:03:03.520
Продавець може створити замовлення для Носвінд,

00:03:03.580 --> 00:03:06.180
і фінансистам не потрібно буде вводити цю інформацію повторно.

00:03:06.320 --> 00:03:09.340
Вони бачать клієнта, умови оплати, кредитний стан та суму до сплати.

00:03:09.520 --> 00:03:11.020
Все підключається автоматично.

00:03:11.180 --> 00:03:13.680
У цьому різниця між списком контактів і клієнтським аккаунтом.

00:03:13.860 --> 00:03:16.080
Список контактів допомагає вам комусь зателефонувати.

00:03:16.240 --> 00:03:18.340
Клієнтський аккаунт фіксує фінансові відносини,

00:03:18.460 --> 00:03:21.160
включаючи правила, що контролюють процеси під час продажу.

00:03:21.340 --> 00:03:22.880
Тож як тільки Носвінд щось купує,

00:03:22.880 --> 00:03:27.100
Дайнемикс 365 має перетворити цей продаж на належний запит на оплату.

00:03:27.840 --> 00:03:31.920
2. Створення рахунка – перетворення продажу на дебіторську заборгованість.

00:03:32.020 --> 00:03:34.380
То яка різниця між замовленням і рахунком?

00:03:34.560 --> 00:03:37.820
Замовлення каже, що хоче клієнт, а рахунок – що вони мають сплатити.

00:03:38.000 --> 00:03:39.020
Ось у чому справа.

00:03:39.140 --> 00:03:41.820
Рахунок створює відкритий баланс на аккаунті клієнта.

00:03:41.980 --> 00:03:43.900
Після проведення ви офіційно виставляєте рахунок,

00:03:43.960 --> 00:03:46.360
і дебіторська заборгованість може відстежувати належні суми.

00:03:46.360 --> 00:03:48.420
Давайте повернемося до Носвінд Аквіпмант.

00:03:52.880 --> 00:03:54.940
Тепер у Носвінд є обладнання.

00:03:55.120 --> 00:03:57.260
У цей момент вам потрібен чіткий запис того, що вони купили,

00:03:57.400 --> 00:03:59.340
скільки це коштує і коли потрібно здійснити оплату.

00:03:59.460 --> 00:04:01.180
Цей запис і є рахунком для клієнта.

00:04:01.380 --> 00:04:05.100
Більшість рахунків у Дайнемикс 365 Finance надходять безпосередньо із замовлення на продаж.

00:04:05.240 --> 00:04:08.000
Це дозволяє рахунку залишатися прив'язаним до початкового продажу.

00:04:08.140 --> 00:04:11.940
Товари клієнта, ціни, кількості та всі узгоджені правила вже є в базі даних.

00:04:11.940 --> 00:04:15.360
Вам не потрібно, щоб хтось переписував ці дані в окрему білінгову систему.

00:04:15.360 --> 00:04:18.720
Щойно товар відвантажено або послуга досягла етапу, коли її слід оплатити,

00:04:18.840 --> 00:04:20.980
ви створюєте рахунок на основі цього замовлення на продаж.

00:04:21.100 --> 00:04:23.560
Точний час залежить від того, як працює ваша компанія.

00:04:23.760 --> 00:04:27.060
Деякі компанії виставляють рахунки при відправленні, інші – після завершення етапу роботи.

00:04:27.200 --> 00:04:30.260
Консултингова фірма може виставити рахунок після виконання певного етапу.

00:04:30.400 --> 00:04:33.800
Дайнемикс 365 дотримується процесу, який ви вже налаштували.

00:04:33.800 --> 00:04:36.560
Ви могли чути термін «рахунок» на основі пакувального листа.

00:04:36.560 --> 00:04:40.600
Пакувальний лист підтверджує, що саме фізично залишило склад і перейшло на етап доставки.

00:04:40.740 --> 00:04:43.580
Коли ваша компанія виставляє рахунки на основі фактично відвантажених товарів,

00:04:43.680 --> 00:04:45.900
рахунок може використовувати ці підтверджені дані про доставку.

00:04:46.040 --> 00:04:47.940
Це дозволяє уникнути поширеної проблеми.

00:04:48.060 --> 00:04:51.580
Скажімо, є замовлення на 10 одиниць, але сьогодні відвантажили лише 8, бо дві ще очікують на складі.

00:04:51.700 --> 00:04:53.360
Якщо ви виставляєте рахунок на основі пакувального листа,

00:04:53.360 --> 00:04:55.220
ви виставляєте рахунок лише за 8 відвантажених одиниць.

00:04:55.220 --> 00:04:58.200
Ви не виставляєте Носвінд рахунок за всі 10 одиниць до того, як вони їх отримають.

00:04:58.360 --> 00:05:01.260
Замовлення все ще має значення, але підтверджена доставка вказує відділ розрахунків,

00:05:01.340 --> 00:05:02.440
що саме має бути в цьому рахунку.

00:05:02.560 --> 00:05:04.820
Але не кожен рахунок починається із замовлення на продаж.

00:05:04.980 --> 00:05:08.060
Іноді потрібно виставити рахунок за разову послугу, яка не передбачає відправлення товару.

00:05:08.200 --> 00:05:10.500
Можливо, Носвінд замовляє спеціальний навчальний сеанс.

00:05:10.500 --> 00:05:14.580
Можливо, є плата за обслуговування, проектні витрати або коригування, для яких потрібен окремий рахунок.

00:05:14.700 --> 00:05:18.400
Для таких випадків Dynamics 365 Finance підтримує рахунки з вільним текстом.

00:05:18.540 --> 00:05:20.820
Вільний текст не означає випадковий або неформальний.

00:05:20.940 --> 00:05:23.380
Це означає, що рахунок не прив'язаний до замовлення на продаж.

00:05:23.500 --> 00:05:27.640
Ви вводите дані клієнта на рахування, суму, податкову інформацію, де це необхідно, та дані про оплату.

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

00:05:30.680 --> 00:05:32.680
Клієнт все одно отримує належний рахунок.

00:05:32.780 --> 00:05:34.560
Фінансовий відділ бачить відкритий баланс.

00:05:34.700 --> 00:05:36.000
А як щодо регулярних робіт?

00:05:36.080 --> 00:05:38.940
Припустимо, Носвінд сплачує щомісячну плату за обслуговування обладнання.

00:05:39.140 --> 00:05:43.020
Створення одного і того самого рахунка вручну щомісяця забирає час і призводить до дрібних помилок.

00:05:43.180 --> 00:05:46.700
Білінг підписки використовує графіки виставлення рахунків для регулярних нарахувань.

00:05:46.840 --> 00:05:53.060
Ви налаштовуєте угоду та графік розрахунків, після чого Dynamics 365 може створювати рахунки з настанням кожного білінгового періоду.

00:05:53.060 --> 00:05:58.700
Це дає вам повторюваний спосіб виставлення рахунків за регулярні послуги, а клієнт отримує рахунки відповідно до погодженого графіка.

00:05:58.900 --> 00:06:01.840
Відображення в обліку – це момент, коли змінюється статус продажу.

00:06:02.060 --> 00:06:05.220
Воно записує суму на рахунку клієнта Носвінд як заборгованість.

00:06:05.360 --> 00:06:11.120
Це також передає суму у фінансові записи компанії, де ви бачите, що рахунок за продаж виставлено, а оплата ще очікується.

00:06:11.280 --> 00:06:13.960
Рахунок більше не є черниткою, яку хтось може випадково змінити.

00:06:14.120 --> 00:06:15.820
Тепер це частина фінансової звітності.

00:06:15.820 --> 00:06:17.660
Давайте розглянемо це на конкретному прикладі.

00:06:17.760 --> 00:06:20.000
Носвінд замовляє обладнання на суму 10 тисяч доларів.

00:06:20.140 --> 00:06:23.380
Спершу відвантажується 8 одиниць товару, тому ви виставляєте рахунок на ці 8 одиниць.

00:06:23.460 --> 00:06:26.580
У рахунку вказано суму, термін оплати та інструкції щодо платежу.

00:06:26.720 --> 00:06:31.660
Носвінд отримує рахунок, а Dynamics 365 фіксує цю ж суму як відкрито на їхньому рахунку.

00:06:31.820 --> 00:06:36.080
Такий спільний запис допомагає відділу продажів, складу та фінансистам зосередитися на одній операції.

00:06:36.080 --> 00:06:40.300
Більше ніяких суперечок щодо різних версій у різних файлах, проте рахунок лише вимагає гроші.

00:06:40.420 --> 00:06:44.420
Наступне завдання – розпізнати платіж, коли він надійде, і пов'язати його з відповідним відкритим балансом.

00:06:44.560 --> 00:06:46.580
2. 3. Отримання та зіставлення платежів.

00:06:46.700 --> 00:06:48.080
Закриття відповідного рахунку.

00:06:48.280 --> 00:06:49.780
Надходження платежу звучить просто.

00:06:49.960 --> 00:06:52.440
Баланс у банку зростає, отже роботу виконано, чи не так?

00:06:52.560 --> 00:06:53.160
Не зовсім.

00:06:53.340 --> 00:06:55.600
Фінансовий відділ має відповісти на два запитання.

00:06:55.600 --> 00:06:59.240
Хто надіслав гроші і який відкритий рахунок або рахунки, ці гроші мають закрити.

00:06:59.420 --> 00:07:01.900
Уявіть, що Носвінд оплачує рахунок за обладнання.

00:07:02.100 --> 00:07:05.440
Банк може відобразити платіж із коротким посиланням, сумою та датою.

00:07:05.620 --> 00:07:09.480
Без зіставлення цього платежу з відкритим балансом Носвінд, система може показувати готівку в банку,

00:07:09.580 --> 00:07:11.840
водночас вказуючи, що Носвінд все ще винен гроші.

00:07:11.960 --> 00:07:13.480
Ці записи повинні зійтися.

00:07:13.660 --> 00:07:18.000
Dynamics 365 Finance підтримує кілька способів оплати від клієнтів.

00:07:18.000 --> 00:07:22.240
Ви можете отримувати готівку, чеки, платежі кредитними картками, банківські перекази або в екселі –

00:07:22.240 --> 00:07:25.320
це офіційні платіжні документи, що використовуються в деяких бізнес-процесах.

00:07:25.440 --> 00:07:27.840
Кожен метод має свій шлях до фінансових записів.

00:07:28.020 --> 00:07:30.400
Банківський переказ може з'явитися у банківській виписці.

00:07:30.540 --> 00:07:33.200
Чек може потребувати реєстрації до того, як банк його погасить.

00:07:33.320 --> 00:07:35.580
Оплата карткою може надійти через платіжний сервіс.

00:07:35.580 --> 00:07:40.260
Dynamics 365 надає фінансовому відділу місце для реєстрації деталей платежу на відповідному клієнтському рахунку.

00:07:40.380 --> 00:07:42.800
Таким місцем найчастіше є журнал платежів клієнтів.

00:07:42.940 --> 00:07:49.200
Журнал звучить як паперова книга, але в Dynamics 365 це просто контрольоване місце для введення та перегляду платежів перед їх проведенням.

00:07:49.320 --> 00:07:55.140
Фінансовий відділ реєструє клієнта, суму, спосіб оплати, банківський рахунок та будь-яке посилання, що надійшло разом із платежем.

00:07:55.260 --> 00:07:58.620
І є слово, яке часто звучить складніше, ніж воно є насправді розрахунок.

00:07:58.620 --> 00:08:01.880
Розрахунок означає зіставлення платежу з рахунком, який він покриває.

00:08:02.020 --> 00:08:04.520
Носвінд сплачує точну суму за рахунком на обладнання.

00:08:04.700 --> 00:08:08.020
Фінансовий відділ обирає платіж і відкритий рахунок, а потім проводить розрахунок між ними.

00:08:08.200 --> 00:08:11.180
Після проведення операції рахунок більше не відображається як неоплачений.

00:08:11.340 --> 00:08:12.400
Платіж закрив його.

00:08:12.660 --> 00:08:14.960
Баланс клієнта зменшується на ту саму суму.

00:08:15.080 --> 00:08:20.560
Це важливо, оскільки платіж без розрахунку може залишити відкритий рахунок на балансі, хоча ви вже отримали гроші.

00:08:20.560 --> 00:08:25.360
Це призводить до помилкових звітів, зайвих запитів і незручних розмов із клієнтами, які вже заплатили.

00:08:25.520 --> 00:08:27.700
Іноді платіж не покриває всю суму рахунку.

00:08:27.900 --> 00:08:31.440
Можливо, Носвінд сплатить частину суми зараз і погодиться виплатити решту пізніше.

00:08:31.600 --> 00:08:36.300
Dynamics 365 може зарахувати отриману суму в рахунок інвойсу, залишаючи несплачену частину відкритою.

00:08:36.460 --> 00:08:38.900
Інвойс не зникає лише тому, що надійшли певні кошти.

00:08:39.060 --> 00:08:41.420
Фінансовий відділ може чітко бачити, яка сума залишається.

00:08:41.420 --> 00:08:44.420
Це значно краще, ніж помилково позначити інвойс як повністю сплачений,

00:08:44.520 --> 00:08:47.260
а потім намагатися згадати про залишок у примітках чи окремій таблиці.

00:08:47.420 --> 00:08:50.420
Для багатьох компаній банківські платежі надходять у великій кількості.

00:08:50.560 --> 00:08:53.860
Ручна перевірка кожного переказу та кожного відкритого інвойсу забирає час,

00:08:53.980 --> 00:08:58.800
особливо коли клієнти оплачують кілька рахунків разом або вказують не зовсім зрозуміле призначення платежів.

00:08:58.940 --> 00:09:02.860
Dynamics 365 має журнал узгодження платежів для такої роботи.

00:09:02.860 --> 00:09:09.060
Команда може імпортувати дані банківських виписок і використовувати їх для зіставлення вхідних платежів із відкритими клієнтськими інвойсами.

00:09:09.220 --> 00:09:15.080
Призначення платежів, суми, дані клієнтів та правила зіставлення допомагають системі пропонувати, до чого відноситься платіж.

00:09:15.200 --> 00:09:17.980
Ви все одно перевіряєте результат, ця частина важлива.

00:09:18.240 --> 00:09:23.980
Автоматизація зменшує пошук, але фінансовий відділ залишається відповідальним за те, щоб платіж закрив правильний інвойс.

00:09:23.980 --> 00:09:29.360
Якщо клієнт надсилає один платіж за кілька інвойсів, відповідальний працівник може розподілити його між цими рахунками.

00:09:29.520 --> 00:09:33.320
Якщо в призначенні платежі вказано не той документ, його можна виправити перед проведенням.

00:09:33.440 --> 00:09:39.360
Мета – не усунути людське судження, а звільнити людей від потреби проводити день у пошуках банківських файлів та списків інвойсів.

00:09:39.500 --> 00:09:43.340
Тепер уявіть, що Носвінд працює через кілька компаній в одній бізнес-групі.

00:09:43.500 --> 00:09:48.620
Одна юридична особа може продавати обладнання, тоді як центральна фінансова компанія отримує платежі для всієї групи.

00:09:48.620 --> 00:09:52.460
Dynamics 365 підтримує централізовані платежі для таких ситуацій.

00:09:52.580 --> 00:09:55.860
Платіж можна зареєструвати в одній юридичній особі від імені іншої.

00:09:56.020 --> 00:10:01.280
Компанії не потрібно вдавати, що гроші спочатку надійшли на рахунок продавця або керувати цим процесом поза системою.

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

00:10:05.600 --> 00:10:10.460
Це робить спільну фінансову роботу прозорішою, особливо коли кілька компаній використовують одну центральну касу.

00:10:10.460 --> 00:10:14.060
Отже, повний процес оплати – це більше, ніж просто реєстрація грошей у банку.

00:10:14.060 --> 00:10:21.920
Dynamics 365 пов'язує клієнта, платіж та інвойс, доки баланс не буде закрито або доки залишок суми не вкаже фінансовому відділу, що потрібно здійснити ще один платіж.

00:10:22.020 --> 00:10:23.740
Це закриває сьогоднішній платіж.

00:10:23.900 --> 00:10:26.220
Наступне питання виникає перед наступним продажем.

00:10:26.340 --> 00:10:29.200
Чи варто дозволяти клієнту мати ще більшу заборгованість?

00:10:29.320 --> 00:10:32.980
Четверте, управління кредитами – прийняття рішення про продовження продажу.

00:10:33.140 --> 00:10:35.940
Отже, ви отримали платіж і він закрив старий баланс.

00:10:35.940 --> 00:10:37.420
Досить просто чи не так?

00:10:37.420 --> 00:10:40.880
Але ось що запитує відділ управління кредитами перед тим, як замовлення піде далі.

00:10:41.000 --> 00:10:42.940
На який ще ризик ваш бізнес готовий піти?

00:10:43.140 --> 00:10:45.020
Згадайте стійку реєстрації в готелі.

00:10:45.180 --> 00:10:50.640
Гість хоче залишитися ще на ніч, тому персонал перевіряє бронювання, статус оплати та правила, перш ніж видати нову картку від номера.

00:10:50.860 --> 00:10:53.600
Саме це робить керування кредитами для замовлення на продаж.

00:10:53.780 --> 00:10:57.060
Воно не оцінює, чи є носвінд-аквіпмент хорошим клієнтом загалом.

00:10:57.060 --> 00:11:01.100
Воно просто звіряє їхнє поточне фінансове становище з правилами, встановленими вашою компанією.

00:11:01.220 --> 00:11:03.040
Одним із таких правил є кредитний ліміт.

00:11:03.180 --> 00:11:06.740
Кредитний ліміт – це максимальна сума, яку клієнт може заборгувати в будь-який момент часу.

00:11:06.860 --> 00:11:12.860
Тож, якщо носвінд має ліміт 50 тисяч доларів і вже винен 45 тисяч, нове замовлення на 20 тисяч доларів потребує уваги.

00:11:12.980 --> 00:11:16.980
Клієнт все ще може зробити замовлення, але ваш бізнес не повинен залишити це рішення без нагляду.

00:11:17.160 --> 00:11:20.240
Dynamics 365 може перевіряти більше, ніж один показник.

00:11:20.240 --> 00:11:26.000
Вона аналізує відкриті рахунки, терміни прострочення, вартість нового замовлення та кредит, що ще доступний для клієнта.

00:11:26.140 --> 00:11:32.960
Клієнт, який платить вчасно, може мати місце для додаткового кредиту, тоді як інший клієнт може бути в межах ліміту, але мати серйозно прострочений рахунок.

00:11:33.100 --> 00:11:34.340
Це різні рівні ризику.

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

00:11:42.260 --> 00:11:48.580
Відділ продажів бачить блокування, фінансовий відділ бачить причину, і ніхто не дізнається про проблему лише після того, як склад відправив чергову поставку.

00:11:48.720 --> 00:11:53.980
Кредитне блокування не означає, що замовлення відхилено назавжди. Це означає, що хтось має його переглянути.

00:11:54.180 --> 00:12:03.140
Можливо, Носвінд надіслав підтвердження оплати, або фінансовий менеджер знає про помилку в рахунку, чи клієнт попросив тимчасове збільшення ліміту через великий проєкт.

00:12:03.280 --> 00:12:06.900
Уповноважені співробітники можуть розблокувати замовлення за наявності вагомої причини.

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

00:12:15.820 --> 00:12:25.380
Саме тут відділ продажів і фінансовий відділ повинні діяти узгоджено. Продажі хочуть працювати з клієнтом, особливо коли замовлення важливе, а фінанси повинні захистити компанію від накопичення боргів, які можуть не повернутися.

00:12:25.380 --> 00:12:31.900
Жодна зі сторін не повинна перемагати в суперечці. Їм просто потрібно бачити замовлення, суму заборгованості та кредитні правила в одному місці.

00:12:32.060 --> 00:12:40.660
Багато хто чує керування кредитами і думає, що це означає відмовляти клієнтам. Це не так. Це означає узгодження безпечних меж, перш ніж прострочений платіж перетвориться на набагато більшу проблему.

00:12:40.820 --> 00:12:44.620
Ви все ще можете підтримувати хороших клієнтів, затверджувати винятки та продавати з упевненістю.

00:12:44.780 --> 00:12:47.860
Ви просто припиняєте збільшувати борг, не перевіривши факти заздалегідь.

00:12:47.860 --> 00:12:51.720
Коли термін оплати рахунку спливає, профілактика поступається місцем супроводу.

00:12:51.860 --> 00:12:56.140
5. Дебіторська заборгованість та суперечки. Стягнення платежів без втрати клієнта.

00:12:56.260 --> 00:13:01.080
Після закінчення терміну оплати завдання змінюється. Бізнес більше не вирішує, чи надавати кредит.

00:13:01.200 --> 00:13:04.520
Потрібен чіткий і шанобливий спосіб запитати про кошти, термін оплати яких уже минув.

00:13:04.660 --> 00:13:08.100
Dynamics 365 Finance переносить цю роботу на сторінку «Колекторська діяльність».

00:13:08.100 --> 00:13:11.520
Уявіть це як спільний робочий стіл для облікових записів клієнтів із простроченою заборгованістю.

00:13:11.660 --> 00:13:15.400
Замість того, щоб одна людина вела нотатки в пошті, інша відстежувала дзвінки в таблиці,

00:13:15.480 --> 00:13:19.180
а ще хтось перевіляв рахунки у фінансах, команда з роботи з дебіторською заборгованістю

00:13:19.180 --> 00:13:21.720
бачить баланс клієнта та всю історію дій в одному місці.

00:13:21.880 --> 00:13:23.540
Це змінює характер розмови.

00:13:23.680 --> 00:13:27.000
Агент з роботи з дебіторською заборгованістю працює зі списками клієнтів,

00:13:27.000 --> 00:13:29.780
з формованими за критеріями, які дозволяють знайти рахунки,

00:13:29.880 --> 00:13:33.360
прострочені на певну кількість днів на суму, що перевищує встановлений ліміт,

00:13:33.480 --> 00:13:36.140
або такі, що потребують уваги згідно з правилами компанії.

00:13:36.300 --> 00:13:39.160
Тож команді не потрібно вгадувати, з ким зв'язатися першим.

00:13:39.160 --> 00:13:42.520
Щодо кожного клієнта агент може вжити заходів, надіслати нагадування,

00:13:42.640 --> 00:13:46.900
створити лист простягнення, написати електронного листа або додати завдання на телефонний дзвінок.

00:13:47.060 --> 00:13:49.080
Мета – не розсилати гнівні повідомлення.

00:13:49.080 --> 00:13:51.800
Більшість затримок платежів починаються з будинних речей.

00:13:51.940 --> 00:13:55.020
Наприклад, рахунок потрапив не в ту скриньку, клієнту потрібна копія,

00:13:55.140 --> 00:13:57.080
або їхній платіжний відділ пропустив термін.

00:13:57.240 --> 00:13:59.460
Спокійне нагадування може вирішити багато проблем.

00:13:59.460 --> 00:14:02.700
Іноді клієнт відповідає обіцянкою заплатити наступної п'ятниці.

00:14:02.860 --> 00:14:06.180
Dynamics 365 може зафіксувати це як обіцянку платежу,

00:14:06.300 --> 00:14:09.660
щоб команда знала про домовленість і могла перевірити, чи надійшли кошти вчасно.

00:14:09.800 --> 00:14:13.420
Без цього запису наступний агент може зателефонувати тому ж клієнту наступного ранку,

00:14:13.420 --> 00:14:15.100
не знаючи, що дата вже узгоджена.

00:14:15.280 --> 00:14:17.660
Суперечки потребують такого ж уважного підходу.

00:14:17.800 --> 00:14:21.560
Суперечка означає, що клієнт оскаржує рахунок повністю або частково.

00:14:21.560 --> 00:14:26.560
Можливо, через неправильну ціну, недоставлений товар або рахунок за роботу, яку вони не затверджували.

00:14:27.320 --> 00:14:30.780
Найгірша реакція – дозволити цій проблемі загубитися в поштовій скринці.

00:14:30.940 --> 00:14:33.600
Dynamics 365 дозволяє позначити рахунок як спірний

00:14:33.600 --> 00:14:35.800
і бачити його під час роботи з дебіторською заборгованістю.

00:14:35.940 --> 00:14:38.480
Команда може відстежувати статус і необхідні кроки для вирішення,

00:14:43.420 --> 00:14:44.880
помічати повторювані проблеми.

00:14:45.020 --> 00:14:47.560
Якщо кілька клієнтів оскаржують один і той самий тип нарахувань,

00:14:47.660 --> 00:14:50.560
фінансовий відділ дізнається про проблему глибшу, ніж просто затримка оплати.

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

00:14:53.560 --> 00:14:55.780
можливо, доведеться виправити процес, що породжує ці суперечки.

00:14:55.900 --> 00:14:57.840
Також використовуються звіти про старіння заборгованості,

00:14:57.940 --> 00:15:00.780
які сортують неоплачені суми за часом їх перебування у статусі «відкритих».

00:15:00.780 --> 00:15:02.680
Ви можете переглянути суми, що підлягають оплаті зараз,

00:15:13.420 --> 00:15:15.180
той, що не оплачувався три місяці.

00:15:15.340 --> 00:15:18.080
Фінансовий відділ також може використовувати прогнози платежів,

00:15:18.200 --> 00:15:21.520
якщо вони доступні, щоб оцінити, чи надійдуть відкриті рахунки вчасно

00:15:21.520 --> 00:15:25.620
із запізненням чи із великою затримкою, спираючись на історію оплат та дані клієнтів.

00:15:25.760 --> 00:15:28.100
Звіт про заборгованість показує те, що вже сталося,

00:15:28.180 --> 00:15:30.920
але прогноз допомагає команді вирішити, на чому засередитися,

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

00:15:33.340 --> 00:15:35.080
Це не замінює здорового глузду.

00:15:35.240 --> 00:15:37.600
Це дає команді зі стягнення боргів додатковий сигнал,

00:15:37.600 --> 00:15:40.680
коли їм потрібно обирати пріоритети серед довгого списку рахунків.

00:15:40.820 --> 00:15:43.620
Мета проста – збирати кошти стабільно та прозоро,

00:15:43.780 --> 00:15:47.060
ставлячись до клієнта як до людини, а не як до номера справи.

00:15:47.300 --> 00:15:50.280
Тепер розглянемо весь цей шлях на простому прикладі.

00:15:54.920 --> 00:15:57.900
Отже, простежмо, що відбувається, коли Носвінд робить замовлення,

00:15:58.040 --> 00:16:01.040
ваша система обробляє його, і як тільки настає узгоджений термін

00:16:01.040 --> 00:16:03.100
виставлення рахунку, документ надсилається.

00:16:03.240 --> 00:16:05.320
У картці клієнта вже вказані умови оплати,

00:16:05.320 --> 00:16:08.800
тому Dynamics 365 автоматично обчислює термін платежу

00:16:08.800 --> 00:16:10.760
згідно з правилами, узгодженими з Носвінд.

00:16:10.880 --> 00:16:12.660
Фінансовий відділ бачить суму до оплати,

00:16:12.760 --> 00:16:14.720
а клієнт отримує чіткий запит на платіж.

00:16:14.840 --> 00:16:16.100
Це початок процесу.

00:16:16.240 --> 00:16:18.440
Через кілька тижнів Носвінд надсилає банківський переказ

00:16:18.440 --> 00:16:19.700
із посиланням на номер рахунку.

00:16:19.860 --> 00:16:22.520
Фінансовий відділ зіставляє платіж із рахунком і закриває його.

00:16:22.700 --> 00:16:25.360
Відкритий баланс закривається, і в картці клієнта відображається,

00:16:25.480 --> 00:16:26.960
що ця частина розрахунків завершена.

00:16:26.960 --> 00:16:28.860
Жодної ручної перевірки не потрібно.

00:16:28.980 --> 00:16:30.760
Але що стається, коли все йде інакше?

00:16:30.900 --> 00:16:32.340
Якщо Носвінд пропускає термін оплати,

00:16:32.440 --> 00:16:34.280
рахунок потрапляє до відділу стягнення заборгованості.

00:16:34.400 --> 00:16:36.620
Оператор надсилає нагадування, Носвінд відповідає,

00:16:36.740 --> 00:16:39.120
що частина нарахувань помилкова, і команда реєструє спір,

00:16:39.220 --> 00:16:41.620
замість того, щоб вважати це просто неочікуваною затримкою.

00:16:41.760 --> 00:16:44.240
Усі бачать однаковий статус і знають, що робити далі,

00:16:44.320 --> 00:16:46.100
оскільки все зберігається в одному місці.

00:16:46.260 --> 00:16:48.940
Ось у чому різниця з Dynamics 365 Finance

00:16:48.940 --> 00:16:50.660
нічого не залишається відокремленим.

00:16:50.820 --> 00:16:53.760
Замовлення, рахунки, платежі, перевірки кредитоспроможності

00:16:53.760 --> 00:16:56.820
та робота зі стягнення – усе це прив'язано до одних відносин з клієнтом,

00:16:56.940 --> 00:16:59.340
тож вам не доводиться шукати інформацію в різних системах.

00:16:59.460 --> 00:17:01.820
Це означає швидші рішення та менше помилок.

00:17:01.980 --> 00:17:04.660
За старого підходу історія була розсіяна по електронних таблицях,

00:17:04.780 --> 00:17:07.280
папках листів, паперових нотатках та банківських виписках,

00:17:07.380 --> 00:17:09.960
і люди витрачали час, з'ясовуючи, яка версія правильна.

00:17:10.100 --> 00:17:12.620
Dynamics 365 підтримує цілісність історії,

00:17:12.620 --> 00:17:15.060
надаючи єдине уявлення про клієнта від початку до кінця.

00:17:15.180 --> 00:17:16.920
Дебіторська заборгованість – це розуміння того,

00:17:17.060 --> 00:17:20.320
хто винен вам гроші, терміни оплати, поточний стан справ і ваші подальші дії.

00:17:20.500 --> 00:17:23.220
Якщо бракує хоча б однієї ланки, компанія може багато продавати,

00:17:23.320 --> 00:17:24.900
але все одно не розуміти, де її гроші.

00:17:25.020 --> 00:17:27.240
Ось чому цей зв'язний процес такий важливий.

00:17:27.580 --> 00:17:30.360
Висновок. Тримайте внутрішні кошти під контролем.

00:17:30.540 --> 00:17:32.840
Рахунок фактура лише започатковує процес.

00:17:32.840 --> 00:17:35.620
Чи відстежує ваш відділ дебіторської заборгованості кошти,

00:17:35.620 --> 00:17:38.840
доки баланс не закриється або хтось не вживе заходів щодо несплати.

00:17:38.980 --> 00:17:42.520
Контроль за внутрішніми коштами є критично важливим для здоров'я бізнесу.

00:17:42.720 --> 00:17:43.680
Я Мірко Петерс.

00:17:43.780 --> 00:17:46.580
Підписуйтеся на Магніти Знань Майкрософт на М365FM,

00:17:46.660 --> 00:17:49.820
а потім подивіться відповідний епізод про Dynamics 365 Finance на екрані,

00:17:49.900 --> 00:17:51.980
щоб продовжувати прояснювати ситуацію простими словами.