WEBVTT 00:00:01.460 --> 00:00:04.000 Рахунок від постачальника потрапляє на ваш стіл. 00:00:04.120 --> 00:00:08.780 Товар може вже бути на складі, а послуга надана, проте час на оплату починає спливати миттєво. 00:00:08.960 --> 00:00:11.860 Отже, що насправді відбувається до того, як гроші покидають компанію? 00:00:12.000 --> 00:00:14.760 Вітаємо у черговій порції знань від М365FM. 00:00:14.900 --> 00:00:19.500 Я Мір Пітерс, і сьогодні ми розглядаємо кредиторську заборгованість у Dynamics 365 простою мовою. 00:00:19.660 --> 00:00:22.240 Це не просто місце, де хтось вводить рахунки на екрані. 00:00:22.240 --> 00:00:28.440 Це фінансовий відділ компанії, що перевіряє кожен рахунок, хто його надіслав, що компанія погодилася купити і чи варто його оплачувати. 00:00:28.640 --> 00:00:30.060 Ось найпростіше визначення. 00:00:30.220 --> 00:00:34.680 Кредиторська заборгованість – це гроші, які ваша компанія винна постачальникам за товари чи послуги, які ви вже придбали. 00:00:34.820 --> 00:00:37.320 Уявіть це як розрахунковий відділ у великій будівлі. 00:00:37.440 --> 00:00:43.660 Рахунки надходять на стійку реєстрації, звіряються з документами компанії, проходять затвердження і лише тоді потрапляють до особи, яка проводить оплату. 00:00:43.660 --> 00:00:47.340 Ми простежимо цей шлях від запису про постачальника до фінальної відмітки про оплату. 00:00:47.460 --> 00:00:50.400 У Dynamics 365 це називається розрахунком. 00:00:50.520 --> 00:00:52.540 Чому існує кредиторська заборгованість? 00:00:52.680 --> 00:00:55.900 Уявіть, що ви керуєте невеликою компанією, яка продає офісні меблі. 00:00:56.040 --> 00:00:58.320 Вам потрібні столи, перш ніж ви зможете їх продати. 00:00:58.460 --> 00:01:03.800 А ще вам потрібні пакувальні коробки, послуги прибирання, інтернет, запчастини і, можливо, служба доставки. 00:01:03.980 --> 00:01:08.880 Якби вам доводилося платити кожному постачальнику в момент замовлення, купувати щось стало б дуже складно. 00:01:08.880 --> 00:01:12.400 Більшість підприємств купують спочатку, а платять згодом на узгоджених умовах. 00:01:12.500 --> 00:01:16.180 Постачальник доставляє товар або виконує роботу, а потім надсилає рахунок фактуру. 00:01:16.340 --> 00:01:20.380 Ваша компанія тепер винна цю суму, але вона не відправляє гроші, не перевіривши попередньо всі деталі. 00:01:20.500 --> 00:01:23.820 Ця неоплачена сума відображається в бухгалтерському обліку компанії як зобов'язання. 00:01:23.980 --> 00:01:29.700 Зобов'язання може звучати як страшний фінансовий термін, але значення просте – це сума, яку компанія винна комусь іншому. 00:01:29.700 --> 00:01:36.260 Якщо ваш бізнес отримує рахунок за офісне приладдя і ще не оплатив його, цей рахунок належить до кредиторської заборгованості, доки оплата його не закриє. 00:01:36.380 --> 00:01:39.980 Компанія все ще має готівку зараз, але в неї також є обіцянка, яку треба виконати. 00:01:40.140 --> 00:01:45.360 Це важливо, оскільки банківський рахунок бізнесу може виглядати здоровим, поки компанія накопичує купу неоплачених рахунків. 00:01:45.520 --> 00:01:47.960 Фінансовим командам потрібно бачити обидва боки. 00:01:48.140 --> 00:01:51.800 Скільки готівки лежить у банку і скільки з цієї суми незабаром доведеться витратити. 00:01:51.800 --> 00:01:55.920 До появи інтегрованих фінансових систем ця робота часто перетворювалася на паперову тяганину. 00:01:56.060 --> 00:02:02.660 Рахунок міг надійти поштою, лежати на чиємусь столі, потім подорожувати внутрішньою поштою на затвердження, тоді як інший рахунок чекав у поштовій скринці. 00:02:02.840 --> 00:02:07.720 Хтось міг вводити той самий рахунок у таблицю, тоді як інша особа вносила його в бухгалтерську систему. 00:02:07.900 --> 00:02:09.480 Це створює знайомі проблеми. 00:02:09.480 --> 00:02:17.000 Менеджер пропускає лист із запитом на погодження, рахунок оплачується із запізненням, або постачальник надсилає той самий рахунок ще раз, і ніхто не помічає, що він уже в фінансовому відділі. 00:02:17.140 --> 00:02:21.300 Гірше того, його можуть оплатити двічі, бо паперова та електронна копії виглядають як різні рахунки. 00:02:21.460 --> 00:02:25.100 Dynamics 365 надає компанії єдине місце для відстеження цієї роботи. 00:02:25.260 --> 00:02:30.760 Система фіксує заборгованість компанії, допомагає перевіряти рахунки та забезпечує чіткий шлях від отримання рахунку до його оплати. 00:02:30.760 --> 00:02:33.780 Це не означає, що кожен рахунок проходить без участі людини. 00:02:33.900 --> 00:02:40.460 Фінансовий відділ все одно вирішує, коли щось виглядає підозріло, але система надає їм записи та правила для прийняття рішень безбіганени з паперами. 00:02:40.640 --> 00:02:43.780 Можливо, ви також чули про дебіторську заборгованість у цій же розмові. 00:02:43.900 --> 00:02:47.180 Назви звучать майже однаково, але вони стосуються протилежних процесів. 00:02:47.300 --> 00:02:51.140 Кредиторська заборгованість відстежує кошти, що виходять із компанії, бо ви винні постачальникам. 00:02:51.140 --> 00:02:55.100 Дебіторська заборгованість відстежує кошти, що надходять до компанії, бо клієнти винні вам. 00:02:55.260 --> 00:02:59.120 Якщо ваша компанія купує принтери у постачальника, цей рахунок потрапляє до кредиторської заборгованості. 00:02:59.260 --> 00:03:03.960 Якщо ваша компанія продає столи клієнту і надсилає йому рахунок, цей рахунок потрапляє до дебіторської заборгованості. 00:03:04.080 --> 00:03:08.300 Отже, кредиторська заборгованість відстежує те, що ви повинні сплатити, а дебіторська – те, що мають сплатити вам. 00:03:08.460 --> 00:03:11.120 Мета кредиторської заборгованості – дуже практичний результат. 00:03:11.120 --> 00:03:14.220 Сплатити потрібному постачальнику потрібну суму в узгоджену дату. 00:03:14.380 --> 00:03:17.740 Сплатити занадто рано – компанія втрачає готівку раніше, ніж потрібно. 00:03:17.860 --> 00:03:22.300 Сплатити занадто пізно – постачальник може вимагати оплату або скасувати вигідні умови. 00:03:22.440 --> 00:03:28.120 Сплатити неправильну суму – і комусь доведеться виправляти помилку пізніше, часто з купою листів, кредитнот та розчарувань. 00:03:28.780 --> 00:03:36.620 Тому, перш ніж рахунок пройде через цей процес, Dynamics 365 має точно знати, хто є постачальником і які правила стосуються цих відносин. 00:03:36.820 --> 00:03:38.540 Створення бази постачальників 00:03:38.540 --> 00:03:43.480 Отже, перш ніж Dynamics 365 зможе опрацювати бодай один рахунок, вона має знати, хто його надіслав. 00:03:43.600 --> 00:03:45.520 Ось тут і з'являється картка постачальника. 00:03:45.720 --> 00:03:48.840 Без неї система не знає, кому платити або яких правил дотримуватися. 00:03:49.000 --> 00:03:52.620 Постачальник може надавати фізичні товари, як-от папір, ноутбуки чи запчастини. 00:03:52.800 --> 00:03:56.380 Вони також можуть надавати послуги, як-от бухгалтерський облік чи підтримку програмного забезпечення. 00:03:56.540 --> 00:03:58.880 Продукт змінюється, але роль залишається незмінною. 00:03:59.020 --> 00:04:01.620 Це сторона, який ваша компанія, можливо, має заплатити. 00:04:01.620 --> 00:04:05.180 Вважайте картку постачальника його особовою справою в Dynamics 365. 00:04:05.640 --> 00:04:10.460 Вона зберігає основні дані, потрібні фінансовому відділу, а також визначає правила, що регулюють подальші дії. 00:04:10.660 --> 00:04:15.500 Ви вносите назву постачальника, адресу та контактні дані, щоб компанія точно знала, з ким має справу. 00:04:15.620 --> 00:04:21.400 Ви також можете вказати валюту, що використовується для рахунків і платежів, що дуже важливо при закупівлях у постачальників з різних країн. 00:04:21.520 --> 00:04:25.660 Тепер щодо платіжних реквізитів, запис постачальника може містити умови оплати та спосіб розрахунку. 00:04:25.660 --> 00:04:29.480 Це можуть здатися лише маленькими полями на екрані, але вони дають відповіді на цілком практичні питання. 00:04:29.600 --> 00:04:31.300 Коли потрібно платити цьому постачальнику? 00:04:31.440 --> 00:04:33.240 І яким чином компанія має надіслати кошти? 00:04:33.360 --> 00:04:35.260 Умови оплати визначають правила щодо термінів погашення. 00:04:35.440 --> 00:04:38.000 Деякі постачальники дозволяють платити через 30 днів після дати виставлення рахунку. 00:04:38.180 --> 00:04:40.060 Інші вимагають оплату протягом 14 днів. 00:04:40.260 --> 00:04:42.400 Деякі навіть пропонують знижку за дострокову оплату. 00:04:42.400 --> 00:04:46.980 Dynamics 365 використовує введені вами умови, щоб автоматично розраховувати термін оплати кожного рахунку. 00:04:47.120 --> 00:04:49.260 Нікому не потрібно запам'ятовувати умови договору. 00:04:49.380 --> 00:04:50.880 Це забезпечує послідовність. 00:04:51.040 --> 00:04:55.380 Якщо п'ятеро різних людей обробляють рахунки одного постачальника, вони всі дотримуються однакових правил оплати. 00:04:55.540 --> 00:04:59.720 Нікому не потрібно шукати в старих електронних листах або телефонувати до відділу закупівель, щоб запитати, коли оплатити рахунок. 00:04:59.900 --> 00:05:02.420 Спосіб оплати описує, як саме кошти надходять отримувачу. 00:05:02.420 --> 00:05:06.120 Ваша компанія може платити одному постачальнику електронним переказом, іншому – чеком. 00:05:06.240 --> 00:05:09.200 У деяких випадках бізнес також може використовувати в екселі. 00:05:09.360 --> 00:05:14.840 Dynamics 365 дозволяє визначати власні способи оплати та за потреби пов'язувати їх із системними типами. 00:05:14.980 --> 00:05:17.480 Компанії зазвичай працюють не з одним постачальником. 00:05:17.660 --> 00:05:21.240 У компанії, що розвивається, їх можуть бути десятки, сотні або навіть тисячі. 00:05:21.440 --> 00:05:24.880 Налаштування кожного з них з нуля було б марнуванням часу та джерелом помилок. 00:05:24.980 --> 00:05:28.080 Ось чому в Dynamics 365 використовуються групи постачальників. 00:05:28.080 --> 00:05:31.640 Група постачальників об'єднує тих, на кого поширюються однакові загальні фінансові правила. 00:05:31.780 --> 00:05:36.320 Наприклад, ви можете додати місцевих постачальників офісного приладдя до однієї групи, а закордонних постачальників – товарів – до іншої. 00:05:36.460 --> 00:05:42.760 Група містить спільні налаштування для відображення транзакцій, порядку проведення платежів та взаєморозрахунків, а також звітності щодо залишків за цими постачальниками. 00:05:42.900 --> 00:05:45.800 Ви все одно зберігаєте окремий запис для кожного постачальника. 00:05:45.800 --> 00:05:50.400 Це важливо, оскільки кожен постачальник має власну назву, адресу, платіжні дані та історію. 00:05:50.540 --> 00:05:55.860 Група постачальників лише забезпечує спільну відправну точку, щоб фінансовому відділу не доводилося щоразу переналаштовувати одні і ті самі правила. 00:05:56.020 --> 00:05:59.220 За лаштунками є ще один елемент, який називається профілем обліку постачальника. 00:05:59.420 --> 00:06:02.240 Назва звучить технічно, тож давайте пояснимо її простішою мовою. 00:06:02.400 --> 00:06:07.640 Профіль обліку – це своє рідна карта, яка вказує Dynamics 365, до якого рахунку головної книги належать транзакції постачальника. 00:06:07.640 --> 00:06:10.660 Головна книга – це основний реєстр фінансових рахунків компанії. 00:06:10.780 --> 00:06:17.340 Коли рахунок проводиться в системі Dynamics 365, має зафіксувати як заборгованість компанії, так і те, до якої статті витрат це відноситься. 00:06:17.500 --> 00:06:23.380 Профіль обліку спрямовує бухгалтерське відображення операції з постачальником відповідно до правил, встановлених для постачальника або групи постачальників. 00:06:23.480 --> 00:06:26.980 Працівникам фінансового відділу не потрібно щоразу обирати ці рахунки з пам'яті. 00:06:26.980 --> 00:06:32.780 Натомість система використовує схему, що зменшує кількість суперечливих записів і надає фінансовій команді значно чіткіше уявлення про заборгованість перед постачальниками. 00:06:32.900 --> 00:06:35.500 Компанія також готує процес оплати ще до надходження рахунків. 00:06:35.640 --> 00:06:39.740 У модулі управління готівкою та банківськими операціями ви налаштовуєте банківські рахунки, з яких здійснюватимуться виплати постачальникам. 00:06:39.860 --> 00:06:44.560 Журнали платежів надають фінансовим працівникам робочий простір для підготовки та реєстрації цих платежів за допомогою затверджених методів. 00:06:44.560 --> 00:06:48.080 Отже, підсумуємо, картка постачальника визначає, хто отримує кошти. 00:06:48.200 --> 00:06:53.980 Умови оплати визначають термін платежу, а спосіб оплати та банківський рахунок, як саме кошти, залишають компанію. 00:06:54.140 --> 00:07:00.180 З готовими правилами рахунок може надійти до фінансового відділу та почати свій шлях від отримання до затвердження. 00:07:00.500 --> 00:07:05.820 За наявності картки постачальника, Dynamics 365 тепер знає, кому платити та за якими правилами. 00:07:05.960 --> 00:07:08.500 Отже, що відбувається, коли надходить фактичний рахунок. 00:07:08.500 --> 00:07:10.760 Іноді фінансовий працівник вводить його вручну. 00:07:10.760 --> 00:07:16.440 Це працює, коли рахунок надходить електронною поштою, на папері або через портал постачальника, і комусь потрібно ввести деталі в систему. 00:07:16.580 --> 00:07:24.400 Працівник обирає постачальника, вводить номер рахунку та дату, а потім додає рядки, суми, податки та будь-яке посилання на замовлення на закупівлю, що стосується цього рахунку. 00:07:24.580 --> 00:07:26.460 Номер рахунку заслуговує на увагу. 00:07:26.600 --> 00:07:30.740 Він надається постачальником, а не вашою компанією, і допомагає ідентифікувати конкретний рахунок. 00:07:30.740 --> 00:07:39.980 Якщо надходить рахунок на 1200 доларів відносвін до Office Supplies з номером N148, Dynamics 365 може використати цей номер разом із карткою постачальника, щоб виявити дублювання запису. 00:07:40.140 --> 00:07:41.960 Вкладення також належать до запису. 00:07:42.100 --> 00:07:47.280 Рахунок у форматі PDF, скануваний документ або супровідні папери можуть зберігатися разом із рахунком у Dynamics 365. 00:07:47.720 --> 00:07:54.560 Це означає, що особа, яка перевіряє запис, може бачити документ за цифрами, не перериваючи спільну поштову скриньку чи шафу з документами. 00:07:54.740 --> 00:07:57.800 Для більших обсягів рахунки можуть надходити в електронному вигляді. 00:07:57.800 --> 00:08:02.000 Dynamics 365 підтримує імпорт даних рахунків за допомогою об'єктів даних. 00:08:02.080 --> 00:08:07.800 Уявіть об'єкт даних як стандартну форму, яку інша система може заповнити перед надсиленням інформації до Dynamics 365. 00:08:08.280 --> 00:08:14.680 Зовнішній сервіс для отримання рахунків, наприклад, може надіслати заголовок рахунку, рядки та вкладений документ в одному пакеті даних. 00:08:14.820 --> 00:08:20.720 Заголовок містить основні дані рахунку, постачальника, номер рахунку, дати, валюту, загальну суму та посилання на замовлення на закупівлю. 00:08:20.860 --> 00:08:23.100 Рядки пояснюють, за що з вас стягується плата. 00:08:23.100 --> 00:08:27.020 Один рядок може стосуватися паперу для принтера, інший – тонера, а ще один – доставки. 00:08:27.140 --> 00:08:30.980 Розділення цих деталей допомагає фінансовим працівникам бачити саме те, що вони затверджують. 00:08:31.060 --> 00:08:33.340 Податкова інформація також супроводжує рахунок. 00:08:33.480 --> 00:08:38.220 Dynamics 365 потребує суми податку та відповідних даних, щоб компанія правильно зареєструвала рахунок. 00:08:38.340 --> 00:08:41.140 Кілька факторів можуть зупинити обробку рахунка до його перевірки. 00:08:41.280 --> 00:08:45.400 Відсутній постачальник, недійсна дата, повторний номер рахунка або невідповідна загальна сума. 00:08:45.520 --> 00:08:47.120 Ця пауза захищає компанію. 00:08:47.120 --> 00:08:51.700 Політика щодо рахунків постачальників перевіряє, чи відповідає рахунок правилам, встановленим вашою компанією. 00:08:51.820 --> 00:08:56.280 Перевірка на дублікати шукає знайомі рахунки, наприклад, коли такий самий постачальник і номер рахунка вже зареєстровані. 00:08:56.400 --> 00:08:58.820 Мета полягає не в тому, щоб звинуватити постачальника в помилці. 00:08:58.960 --> 00:09:01.700 Постачальники можуть надсилати рахунок повторно, бо не впевнені, чи він дійшов. 00:09:01.820 --> 00:09:04.420 Працівник може помилково ввести той самий PDF-файл двічі. 00:09:04.420 --> 00:09:07.640 У будь-якому разі подвійна оплата одного рахунка створює нікому непотрібну роботу. 00:09:07.780 --> 00:09:10.800 Як тільки Dynamics 365 приймає рахунок, виникає просте запитання. 00:09:10.960 --> 00:09:12.280 Хто має право його затвердити? 00:09:12.420 --> 00:09:14.220 Ось тут у гру вступає робочий процес Workflow. 00:09:14.400 --> 00:09:16.760 Робочий процес – це маршрут затвердження всередині системи. 00:09:16.880 --> 00:09:20.020 Замість того, щоб надсилати PDF-файл менеджеру і сподіватися на відповідь, 00:09:20.100 --> 00:09:24.840 Dynamics 365 надсилає рахунок особі або на посаду, визначену правилами вашої компанії. 00:09:24.840 --> 00:09:29.320 Кожна організація сама визначає ці правила, виходячи з того, як мають прийматися фінансові рішення. 00:09:29.460 --> 00:09:31.800 Невеликий поточний рахунок може пройти короткий шлях. 00:09:31.900 --> 00:09:35.180 Рахунок на суму, що перевищує певну межу, може потребувати підтвердження старшого менеджера. 00:09:35.300 --> 00:09:38.840 Рахунок, пов'язаний із конкретним відділом, може потрапити до керівника цього відділу. 00:09:38.960 --> 00:09:41.480 Ви можете створити різні шляхи затвердження для різних типів постачальників, 00:09:41.540 --> 00:09:43.720 наприклад, постачальників товарів, послуг або підрядників. 00:09:43.720 --> 00:09:46.040 Маршрут слідує правилам, а не чиїсь пам'яті. 00:09:46.180 --> 00:09:48.300 Це значно полегшує відстеження затверджень. 00:09:48.440 --> 00:09:53.140 Фінансовий відділ бачить, чи рахунок чекає на перевірку, чи вже затверджений, чи потребує додаткової інформації. 00:09:53.340 --> 00:09:58.020 Особа, що затверджує рахунок, може перевірити його, визначити, чи належить він до її відділу і чи коректна вказана сума. 00:09:58.160 --> 00:10:01.280 Деякі рахунки відповідають усім правилам і просуваються автоматично. 00:10:01.460 --> 00:10:05.400 Постачальник відомий імпортовані дані повні, а рахунок проходить перевірку політикою. 00:10:05.400 --> 00:10:08.980 Такі рахунки не потребують постійного повторення одних і тих самих базових перевірок. 00:10:09.080 --> 00:10:10.560 Інші рахунки стають винятками. 00:10:10.760 --> 00:10:12.660 Можливо, відсутній обліковий запис постачальника. 00:10:12.820 --> 00:10:14.580 Можливо, такий номер рахунка вже існує. 00:10:14.720 --> 00:10:16.700 Можливо, в імпортованому рядку є помилка. 00:10:16.880 --> 00:10:19.940 Dynamics 365 зберігає такі рахунки у списку помилок імпорту, 00:10:20.020 --> 00:10:24.300 де фінансовий персонал може побачити повідомлення про помилку та виправити проблему перед створенням рахунка до оплати. 00:10:24.480 --> 00:10:26.700 Документ залишається важливим під час перевірки. 00:10:26.700 --> 00:10:30.460 Dynamics 365 включає засіб перегляду вкладень на сторінках рахунків, 00:10:30.540 --> 00:10:34.260 тому фінансовий працівник може бачити зображення рахунка поруч із записом, який виправляє. 00:10:34.400 --> 00:10:37.020 Не потрібно перемикатися між екранами лише для того, щоб підтвердити, 00:10:37.140 --> 00:10:39.820 чи ввів постачальник 6 тисяч чи 8 тисяч в оригінальному рахунку. 00:10:40.260 --> 00:10:41.920 Автоматизація обробляє рутинні дії. 00:10:42.140 --> 00:10:43.320 Люди вирішують питання. 00:10:43.500 --> 00:10:46.020 Затвердження підтверджує, що потрібна особа погодила рахунок до оплати, 00:10:46.120 --> 00:10:49.540 але це ще не доводить, що постачальник виставив рахунок саме за те, що було замовлено або отримано. 00:10:49.540 --> 00:10:52.460 Для цього Dynamics 365 порівнює документацію. 00:10:52.600 --> 00:10:53.540 Звірка рахунків. 00:10:53.640 --> 00:10:57.520 Перевірка того, що компанія замовила, підтверджує, що потрібна особа ознайомилася з рахунком. 00:10:57.680 --> 00:10:59.600 Але звірка відповідає на інше запитання. 00:10:59.740 --> 00:11:02.660 Чи збігається рахунок із тим, що компанія справді погодилася купити? 00:11:02.820 --> 00:11:07.340 Коли закупівля починається із замовлення на купівлю, у Dynamics 365 є запис для перевірки. 00:11:07.460 --> 00:11:10.300 Уявіть замовлення на купівлю як внутрішній документ компанії. 00:11:10.460 --> 00:11:14.060 У ньому фіксується постачальник, запитані товари, кількість, ціна та умови. 00:11:14.060 --> 00:11:17.320 Хтось із відділу закупівель створює це замовлення до надходження будь-якого рахунку. 00:11:17.460 --> 00:11:18.380 Чому це важливо? 00:11:18.560 --> 00:11:21.440 Замовлення на купівлю фіксує домовленості ще до появи рахунку. 00:11:21.620 --> 00:11:24.380 Без нього фінансист бачить лише рахунок на ім'я постачальника. 00:11:24.600 --> 00:11:27.860 З ним він може порівняти нарахування постачальника з початковим запитом. 00:11:28.020 --> 00:11:30.320 Для фізичних товарів важливий ще один запис. 00:11:30.520 --> 00:11:33.880 Коли доставка прибуває, складська команда реєструє надходження продукції. 00:11:34.060 --> 00:11:38.140 Це доказ у Dynamics 365, що товар отримано разом із кількістю. 00:11:38.140 --> 00:11:42.260 Це не означає, що кожен товар ідеальний, але це фіксує отримане за цим замовленням. 00:11:42.360 --> 00:11:44.940 Уявіть, що компанія замовляє 10 офісних стільців. 00:11:45.080 --> 00:11:47.580 У замовленні вказано 10 стільців за узгодженою ціною, 00:11:47.680 --> 00:11:51.500 але коли прибуває вантажівка, на складі налічують лише 8, бо 2 на дозамовленні. 00:11:51.640 --> 00:11:54.640 Команда з приймання створює документ про отримання на 8 одиниць. 00:11:54.720 --> 00:11:56.800 Потім постачальник надсилає рахунок на 10 стільців, 00:11:56.920 --> 00:12:00.540 що може бути правильним з їхньої точки зору, якщо вони виставили рахунок до відправлення решти. 00:12:00.540 --> 00:12:02.860 Але тепер у вашій компанії виникла розбіжність. 00:12:03.020 --> 00:12:05.540 Замовлено 10, отримано 8, рахунок на 10. 00:12:05.740 --> 00:12:09.220 Dynamics 365 може виявити цю різницю через звірку рахунків. 00:12:09.400 --> 00:12:12.280 Двостороння звірка порівнює замовлення на купівлю з рахунком постачальника, 00:12:12.400 --> 00:12:15.260 перевіряючи, чи збігається рахунок із замовленням за ціною та кількістю. 00:12:15.400 --> 00:12:19.220 Це підходить для закупівель, де перевірки початкового замовлення достатньо для контролю. 00:12:19.400 --> 00:12:22.880 Вона виявляє завищену ціну або більшу кількість, ніж замовлено, 00:12:22.880 --> 00:12:27.740 але не перевіряє, чи прибув товар, бо порівнює лише два записи – замовлення та рахунок. 00:12:27.820 --> 00:12:30.660 Тристороння звірка додає документ про отримання продукції. 00:12:30.840 --> 00:12:35.440 Тож тепер Dynamics 365 порівнює замовлення, акт отримання та рахунок разом. 00:12:35.620 --> 00:12:40.620 У нашому прикладі зі стільцями система бачить замовлення на 10, отримання на 8 і рахунок на 10. 00:12:40.800 --> 00:12:45.320 І ця розбіжність стає причиною зупинити рахунок замість того, щоб проводити його далі. 00:12:46.020 --> 00:12:48.800 Для компаній, що купують запаси чи обладнання, 00:12:48.800 --> 00:12:55.080 ця перевірка дає фінансистам кращий контроль, допомагаючи уникнути оплати за неотримані чи зайві товари. 00:12:55.420 --> 00:12:57.780 Відділ закупівель підтверджує домовленості. 00:12:57.920 --> 00:13:01.480 Відділ прийому підтверджує отримане, а рахунок від постачальника вимагає оплати. 00:13:01.640 --> 00:13:04.420 Ой, усі три записи мають свідчити про одне і те саме. 00:13:04.540 --> 00:13:07.060 У реальному бізнесі трапляються невеликі розбіжності. 00:13:07.200 --> 00:13:11.980 Ціна може відрізнятися через округлення, або постачальник може внести незначно допустиму зміну в кількість. 00:13:11.980 --> 00:13:17.080 Якби кожна дрібна розбіжність зупиняла рахунок, фінансові команди витрачали б забагато часу на вирішення несуттєвих питань. 00:13:17.200 --> 00:13:21.940 Тому Dynamics 365 дозволяє компанії встановлювати політики зі ставлення та межі допустимих відхилень. 00:13:22.080 --> 00:13:29.680 Допустиме відхилення – це дозволена різниця, компанія сама вирішує, яку суму чи відсоток приймати для ціни, кількості, загального підсумку чи пов'язаних витрат. 00:13:29.860 --> 00:13:34.860 Все, що в межах цього ліміту, обробляється за правилами компанії, а все, що виходить за межі, позначається для перевірки. 00:13:34.860 --> 00:13:42.200 Компанія сама визначає ці ліміти. Бізнес може дозволити невелику різницю для дешевих офісних товарів, але встановити значно суворіші ліміти для дорогого обладнання. 00:13:42.400 --> 00:13:49.060 Система не вирішує, що є прийнятним. Фінансовий та закупівельний відділи встановлюють правила, а Dynamics 365 послідовно їх застосовує. 00:13:49.200 --> 00:13:55.820 Це змінює те, як фінансова команда витрачає свій час. Замість перевірки кожного безпроблемного рахунку рядок за рядком, вони можуть зосередитися на винятках. 00:13:55.820 --> 00:14:04.840 О, досліджуючи рахунок, де змінилася ціна, відсутній акт прийому або не сходиться кількість. Чисті рахунки все одно дотримуються правил, але люди приділяють увагу там, де потрібне рішення. 00:14:05.000 --> 00:14:11.000 У цьому справжня цінність зіставлення. Система бере на себе рутинні перевірки, тоді як люди вирішують питання, що потребують судження. 00:14:11.200 --> 00:14:15.600 Система не замінює людське судження. Вона відокремлює рутинні перевірки від справжніх питань. 00:14:15.600 --> 00:14:21.960 Один момент може викликати плутанину. Стандартне зіставлення у Dynamics 365 підтримує двостороннє та тристороннє звіряння. 00:14:22.100 --> 00:14:28.120 Якщо компанії потрібне чотиристороннє звіряння, наприклад, із додаванням акту перевірки, це потребує додаткової роботи через налаштування або інше рішення. 00:14:28.260 --> 00:14:30.020 Отже, у зіставлення чітке завдання. 00:14:30.180 --> 00:14:36.440 АУ. Воно порівнює рахунок постачальника з власними записами закупівель та отримання товарів компанії, вказуючи на прогалини перед оплатою. 00:14:36.440 --> 00:14:44.060 Як тільки рахунок проходить перевірку та зіставлення, він стає боргом, який компанія планує сплатити, розраховуючись із постачальниками та закриваючи звіти. 00:14:44.240 --> 00:14:49.060 Після того, як рахунок проходить необхідні компанії перевірки, Dynamics 365 може його провести. 00:14:49.260 --> 00:14:56.860 Проведення означає, що рахунок стає офіційним фінансовим записом і компанія фіксує борг перед постачальником, при цьому рахунок відображається як неоплачений до моменту виплати. 00:14:57.040 --> 00:15:00.080 Рахунок готовий, але це не означає, що гроші відразу йдуть з рахунку. 00:15:00.080 --> 00:15:03.600 Фінансові команди мають вирішити, які рахунки оплатити під час платіжного циклу. 00:15:03.740 --> 00:15:11.280 Dynamics 365 допомагає з пропозицією щодо оплати, яка переглядає рахунки до сплати та рекомендує, які з них включити у виплату згідно з правилами компанії. 00:15:11.420 --> 00:15:14.920 Пропозиція щодо оплати – це початковий список, який ще має перевірити відповідальна особа. 00:15:15.040 --> 00:15:20.300 Можливо, термін оплати рахунка від постачальника припадає на цей тиждень, тоді як інший може зачекати до кінця місяця згідно з узгодженими умовами. 00:15:20.300 --> 00:15:25.940 Фінансовий відділ перевіряє запропоновані рахунки, за потреби додає або видаляє позиції, а потім готує платіжний журнал. 00:15:26.080 --> 00:15:29.980 Таким чином платежі групуються та контролюються, замість того, щоб здійснюватися хаотично. 00:15:30.180 --> 00:15:33.320 Вважайте платіжний журнал робочим документом компанії для здійснення виплат. 00:15:33.480 --> 00:15:37.580 У ньому перелічено платежі постачальникам, які планує здійснити компанія, суми та реквізити платежів. 00:15:37.580 --> 00:15:43.460 Фінансові фахівці використовують його для підготовки контрольованого пакету платежів, замість надсилання грошей за кожним рахунком окремо без спільного запису. 00:15:43.560 --> 00:15:48.340 Як кошти виходять з рахунку? Це залежить від способу оплати, встановленого для постачальника та компанії. 00:15:48.520 --> 00:15:55.220 Dynamics 365 дозволяє компанії створювати власні методи оплати та пов'язувати їх із типами платежів, як от чеки, електронні перекази або векселі. 00:15:55.340 --> 00:15:59.960 Чек – це знайомий інструмент. Електронний платіж надсилає кошти через банківську систему компанії. 00:15:59.960 --> 00:16:03.500 Вексель фіксує офіційне зобов'язання щодо оплати на узгоджених умовах. 00:16:03.600 --> 00:16:08.900 Не кожен бізнес використовує всі методи, але Dynamics 365 надає компанії спосіб зафіксувати обраний маршрут платежів. 00:16:09.020 --> 00:16:12.620 Кожен метод оплати також повинен бути пов'язаний із правильним банківським рахунком компанії. 00:16:12.780 --> 00:16:18.040 Цей зв'язок важливий, оскільки бізнес може мати окремі рахунки для різних юридичних осіб, валют або цілий платежі. 00:16:18.200 --> 00:16:22.480 Коли фінансовий відділ готує платіж, системі потрібно знати, з якого банківського рахунку він здійснюється. 00:16:22.480 --> 00:16:26.140 Інакше персонал може створити правильний платіж, але списати його з неправильного рахунку. 00:16:26.280 --> 00:16:28.420 Час здійснення платежів також потребує уваги. 00:16:28.540 --> 00:16:32.940 Оплата після настання терміну може призвести до нагадувань, суперечок або пошкодження стосунків із постачальником. 00:16:33.120 --> 00:16:36.700 Занадто рання оплата виводить готівку з обороту тоді, коли в цьому ще немає потреби. 00:16:36.840 --> 00:16:42.540 Dynamics 365 відображає термін оплати рахунків, щоб фінансовий відділ міг планувати платежі відповідно до умов, 00:16:42.620 --> 00:16:46.520 узгоджених із кожним постачальником, надаючи компанії кращий контроль над відтоком коштів. 00:16:46.520 --> 00:16:49.820 Dynamics 365 має дати відповідь на просте запитання. 00:16:49.960 --> 00:16:51.960 Який саме рахунок покриває цей платіж? 00:16:52.080 --> 00:16:53.380 Відповідь – взаємозалік. 00:16:53.520 --> 00:16:57.420 Взаємозалік пов'язує платіж із конкретним рахунком або рахунками постачальника, які він оплачує. 00:16:57.580 --> 00:17:00.360 Уявіть це як відповідність чека рахунку, який він закриває. 00:17:00.520 --> 00:17:04.340 Без взаємозаліку компанія може бачити рахунок і платіж на одному рахунку постачальника, 00:17:04.460 --> 00:17:06.780 але не мати чіткого запису про те, що вони пов'язані. 00:17:06.900 --> 00:17:10.280 Повна оплата закриває рахунок повністю, але в бізнесі не завжди все так просто. 00:17:10.280 --> 00:17:13.540 Компанія може оплатити лише частину рахунка зараз, а решту – пізніше. 00:17:13.680 --> 00:17:16.320 Взаємозалік фіксує часткову оплату та залишає решту суми відкритою, 00:17:16.420 --> 00:17:18.940 щоб фінансовий відділ бачив, скільки компанія ще винна постачальнику. 00:17:19.060 --> 00:17:22.340 Ця прозорість є критично важливою для точного відображення заборгованості перед постачальниками. 00:17:22.460 --> 00:17:24.760 Один платіж також може покривати кілька рахунків. 00:17:24.900 --> 00:17:29.140 Можливо, компанія сплачує п'ять рахунків від одного постачальника одним електронним платежем. 00:17:29.140 --> 00:17:32.980 Взаємозалік пов'язує цю єдину суму виплати з кожним рахунком, який вона закриває. 00:17:33.140 --> 00:17:37.280 Якщо платіж не покриває кожен рахунок повністю, відкритий залишок залишається чітким, 00:17:37.380 --> 00:17:39.280 а не зникає у загальній заплутаній сумі. 00:17:39.420 --> 00:17:44.240 Це створює простежуваний запис, і ви можете простежити рахунок від його затвердження до результату зіставлення. 00:17:44.380 --> 00:17:49.120 Перегляньте платіж, підготовлений у журналі, і побачите, як саме цей платіж погасив заборгованість постачальника. 00:17:49.120 --> 00:17:51.300 Коли хтось запитує, чому кошти залишили компанію, 00:17:51.300 --> 00:17:55.180 Фінансовому відділу не потрібно відновлювати історію за електронними листами та банківськими виписками. 00:17:55.320 --> 00:17:58.720 Процес може відображатися на окремих сторінках у Dynamics 365, 00:17:59.240 --> 00:18:04.480 але кожен запис з'єднується з наступним як один контрольований потік – повна картина кредиторської заборгованості. 00:18:04.640 --> 00:18:07.720 Уявіть, що ви отримали один рахунок за канцелярські товари. 00:18:07.920 --> 00:18:13.060 Запис постачальника містить правила оплати, а імпортований рахунок додає деталі оплати та сам документ. 00:18:13.060 --> 00:18:15.460 Відділ закупівель надає замовлення на купівлю. 00:18:15.460 --> 00:18:19.540 Склад надає документ про отримання, тому процес зіставлення має реальні записи для порівняння. 00:18:19.660 --> 00:18:23.840 Тепер, за лаштунками, профіль проводки відносить заборгованість та витрати на правильні рахунки головної книги. 00:18:23.980 --> 00:18:28.880 Модуль управління грошовими коштами та банком контролює, який спосіб оплати ви використовуєте і з якого банківського рахунку надсилаються гроші. 00:18:29.020 --> 00:18:33.980 Вкладення залишається разом із транзакцією, тому ви завжди можете пізніше відкрити оригінал рахунку для перевірки. 00:18:33.980 --> 00:18:37.200 Автоматизація не замінює судження фінансової команди.