Договір як дані: дивись

Договір це поля

1. Новий договір, рахунок чи довіреність рідко пишуть з нуля: беруть попередній документ, зберігають копію і замінюють у ній назви, суми й дати. Десь при цьому лишається стара сума, а підсумок цифрами перестає збігатися з підсумком прописом. У таких помилок спільна причина: дані документа перемішані з його текстом. На прикладі договору поставки видно, як їх розділити і які помилки після цього зникають.

2. У договорі поставки на кілька сторінок від угоди до угоди змінюється небагато: назва сторони, її код, кількість, ціна, дата, строк і рахунок. Це дані, тобто значення, які описують саме цю угоду. Решта - текст: формулювання пунктів, які юрист погодив один раз і які переходять з договору в договір без змін. На сторінці одне від другого не відрізнити, бо надруковані вони однаково.

3. Щоб розділити дані й текст, кожне значення виносять в окреме поле. Поле - це комірка з назвою для одного значення: назва «ціна за тонну» і саме значення, 12 400,00. За назвою значення можна знайти й підставити, не перечитуючи текст. Зберігається воно в одному місці, тому назву сторони, яка стоїть і на початку договору, і біля підпису, виправляють один раз, і розбіжностей між сторінками не буває.

4. Кожне поле має ще й тип, тобто позначку, що саме в ньому лежить: текст, число, гроші чи дата. Із типу програма знає, що зі значенням можна робити: числа перемножити, до дати додати дні. І знає, чого в полі бути не може, тому 31 квітня чи код із семи цифр відхиляє ще під час введення. У суцільному тексті таку помилку помітив би хіба уважний читач.

5. У тексті на місці винесених значень лишаються пропуски, і кожен підписано назвою свого поля. Такий сталий текст із пропусками називають шаблоном. Він потрібен, щоб формулювання не набирати й не правити щоразу: їх погоджують один раз, і далі їх ніхто не чіпає. Тож замінюючи ціну, уже не можна випадково стерти слово в пункті про відповідальність, а в новому договорі не лишається нічого від попереднього.

6. Поля теж неоднакові, і різнить їх те, звідки береться значення. Змінне поле для кожної угоди вводить людина: сторону, ціну, строк. Похідне поле ніхто не вводить, його обчислюють з інших полів, як-от суму чи ПДВ. Ще два види стосуються тексту: фіксований текст, однаковий у всіх договорах, і опція, тобто вибір із кількох готових формулювань, наприклад передоплата або оплата після поставки.

7. З чотирьох видів похідне поле найбільше важить для помилок: власного значення воно не зберігає, його щоразу обчислюють з інших полів. Кількість 15, помножена на ціну 12 400,00, дає 186 000,00. ПДВ 20 % від цієї суми становить 37 200,00, а разом виходить 223 200,00. Суму прописом програма складає з того самого числа, тому слова й цифри розійтися не можуть, а якщо змінити ціну, перерахується весь ланцюжок.

8. Без похідних полів той самий ланцюжок набирає людина, і тримається він лише на її уважності. У рядку суми стоїть 168 000,00 замість 186 000,00, бо дві цифри помінялися місцями. У сумі прописом людина пропустила слово «три», тож словами вийшло 220 200, а цифрами 223 200. Сторінка виглядає охайно, і під час читання такі розбіжності здебільшого минають непоміченими. Коли ж числа рахує програма, такій помилці нема звідки взятися.

9. Готовий договір збирає програма: бере шаблон і на місце кожного пропуску ставить значення поля з такою самою назвою, а похідні поля дораховує сама. Для «Зерно-Трейд» це 15 тонн по 12 400,00 і підсумок 223 200,00. Людині лишається заповнити картку із семи полів і перевірити саме її, а не перечитувати кілька сторінок у пошуках того, що змінилося.

10. З одного шаблону виходить стільки договорів, скільки є наборів полів: тут їх три, для трьох різних угод. Текст у всіх однаковий, а підсумок у кожному програма рахує з його власних кількості й ціни. Коли формулювання треба змінити, його змінюють у шаблоні, і всі наступні договори виходять уже з новим. У вправі до цієї частини можна розкласти десять фрагментів одного договору за видами полів.

Хто ловить помилку

1. Договір приходить по-різному: кривим сканом із печаткою, файлом Word або охайним PDF з таблицею. У кожному є значення, від яких залежать гроші і строки: код компанії, номер рахунку, сума, дата. На трьох таких договорах видно, якими способами перевіряють значення в документі і яку помилку ловить кожен спосіб. Звідси ж зрозуміло, чому охайний файл заслуговує на довіру не більше, ніж скан.

2. Вигляд документа залежить від того, як його виготовили, а не від того, чи правильні в ньому дані. PDF зазвичай зберігають із того самого файлу Word, а скан - це роздрукований і сфотографований аркуш. Код, суму й дату в усіх трьох хтось набрав на клавіатурі або переніс із попереднього договору. Помилка набору переходить у будь-який формат без змін, тому перевірка для всіх трьох однакова.

3. Перша перевірка не потребує нічого, крім самого значення. Код ЄДРПОУ, за яким компанію записано в державному реєстрі, має вісім цифр, і остання з них контрольна: її обчислено з попередніх семи, щоб помилку набору було видно одразу. Кожну із семи цифр множать на свою вагу, добутки додають і суму ділять на 11. Для коду 31316718 сума дорівнює 96, остача 8, і восьма цифра теж 8.

4. У сканованому договорі той самий код записано як 31361718: дві сусідні цифри помінялись місцями. Добутки стали іншими, сума тепер 91, остача 3, а восьма цифра лишилась 8. Така розбіжність означає, що в коді, найімовірніше, помилка, і його звіряють із реєстром. Одну хибну цифру формула майже завжди ловить так само. Для остачі 10 правило окреме: рахунок повторюють з іншими вагами.

5. Таку перевірку називають алгоритмічною: вона можлива всюди, де значення має формулу. Рахунок IBAN містить дві власні контрольні цифри, і в скані він їх не проходить. У договорі з Word добуток 15 на 12 400 записано як 168 000 замість 186 000, а в PDF стоїть дата 31 квітня, якої немає в календарі. Проте код 47645196 з того самого PDF формулу проходить: вона перевіряє форму запису, а не існування компанії.

6. На питання, чи існує компанія, відповідає тільки реєстр. ЄДР - це державний реєстр юридичних осіб із відкритим пошуком, де за кодом видно назву, адресу й керівника. За кодом 47645196 з охайного PDF реєстр запису не знаходить. Це ще не означає, що компанії немає: помилка могла бути в самому коді, тому пошук повторюють за назвою. У покупця запис є, але в договорі будинок 6-Б, а в реєстрі 6-К.

7. Лишаються помилки, яких не бачить ні формула, ні реєстр: кожне значення окремо правдоподібне, а суперечать вони одне одному. Їх знаходить перехресне читання, коли людина звіряє різні місця одного документа. Договір датовано 21 травня, а додаток посилається на договір від 12 травня. У преамбулі директор має ініціали О. С., а під підписом стоять О. В. Гарантія в пункті 6.1 становить 12 місяців, у додатку 24.

8. ШІ-асистент, тобто програма, яка відповідає на запит текстом, прискорює всі три перевірки, але результат залежить від формулювання. На загальне «перевір договір» він відповідає впевнено і може написати «помилок не знайдено», не звіривши дат. На точний запит «звір дату договору з датою в додатку 1» він наводить обидві дати й показує розбіжність. Упевнений тон відповіді не свідчить про те, скільки він перевірив.

9. У кожній із трьох перевірок асистент має свою частину роботи і свою межу. Для формул він виписує коди, суми й дати в таблицю, а рахувати краще формулою, бо в обчисленнях модель помиляється. У реєстрі він шукає лише тоді, коли продукт дає йому такий доступ; без доступу відповідь буде здогадом. Під час читання він знаходить парні місця, а яке з двох значень правильне, вирішує людина.

10. Три перевірки ловлять різні помилки, тому жодна не замінює інших. Починають із формул, бо це швидко й нічого не коштує, далі йде запит до реєстру, а найповільніше, читання звʼязків між пунктами, лишається людині. Скан, файл Word і охайний PDF проходять цей шлях однаково. В охайному PDF з цього прикладу знайшлися і дата, якої немає в календарі, і код, якого немає в реєстрі.

Від пункту до дати

1. Сторони підписали договір поставки і з цього дня мають зобовʼязання одна перед одною: сплатити аванс, привезти товар, прийняти його, доплатити решту. Строки цих дій розкидані по тексту, і майже жоден не записаний готовою датою. Фільм показує, як із пунктів договору скласти перелік того, що і до якого числа треба зробити, і чому частину дат неможливо вписати заздалегідь.

2. Перелік складають по одному пункту. За пунктом 3.1 Покупець сплачує аванс 40 % ціни, тобто 120 000,00 грн, протягом 5 банківських днів з дати підписання Договору. Це речення розкладають на пʼять полів: хто виконує, що саме, строк, тип днів і тригер, тобто подія, від якої починають рахувати строк. Окремо їх записують тому, що кінцеву дату визначають три останні поля, і помилка в будь-якому її зсуває.

3. Тип днів визначає, які дні входять у рахунок. Календарні дні йдуть поспіль, разом із суботою й неділею, а робочі вихідних не включають. Рахувати починають з наступного дня після події, тож від підписання в четвер 10.09.2026 пʼять календарних днів закінчуються у вівторок 15.09, а пʼять робочих - у четвер 17.09. Той самий строк дає дві різні дати, тому тип днів переписують із пункту дослівно.

4. Пункт 3.1 називає дні банківськими, а закон не визначає, що таке банківський день. Зміст цього терміна задає сам договір, а якщо визначення в ньому немає, останній день строку стає предметом спору. Для цього прикладу припустімо, що банківські дні - це дні з понеділка по пʼятницю. За такого припущення в рахунок потрапляють 11, 14, 15, 16 і 17 вересня, і останній день оплати авансу - четвер 17.09.2026.

5. Тригер так само беруть із тексту пункту, а не з позначок на папері. На скані цього договору стоїть вхідний штамп із датою 11.09.2026: того дня примірник надійшов до канцелярії. Якщо рахувати від штампа, пʼять банківських днів закінчаться в пʼятницю 18.09, на день пізніше від справжнього строку. Пункт 3.1 привʼязує відлік до підписання, тож правильною лишається дата 17.09.2026.

6. Договір привʼязує строк поставки до події, якої в день підписання ще не було. За пунктом 4.1 Постачальник поставляє товар протягом 14 календарних днів з дня, коли банк зарахував аванс на його рахунок. Покупець може заплатити в перший день свого строку, в останній або із запізненням, і наперед цього ніхто не знає. Тому в полі дати пишуть «чекає на подію»: дата, порахована від очікуваного дня оплати, була б здогадом.

7. Дату тригера беруть із документа, який підтверджує подію. Для зарахування авансу це банківська виписка Постачальника: за нею 120 000,00 грн надійшли у вівторок 15.09.2026. Від цього дня відлічують 14 календарних днів, тепер уже разом із вихідними, і останнім днем поставки стає вівторок 29.09.2026. Рядок отримує дату лише зараз, а поруч записують документ, з якого взяли день події.

8. Поставка, своєю чергою, стане тригером для наступних строків. Від її дня Покупець має 5 робочих днів на приймання товару за якістю, і від нього ж рахують гарантію, 12 місяців. Підписана видаткова накладна запускає оплату залишку: 180 000,00 грн протягом 10 банківських днів. Виходить ланцюг, у якому кожна дата чекає на попередню подію, тому наперед відома тривалість строків, а не числа в календарі.

9. Є й зобовʼязання, тригер яких може не настати взагалі. Їх називають умовними: обовʼязок виникає лише тоді, коли сталася подія, названа в пункті. Товар із дефектами замінюють за 10 календарних днів після акта, про форс-мажор повідомляють протягом 10 календарних днів, аванс у разі відмови від Договору повертають за 5 банківських днів. У перелік їх вносять без дати, і якщо договір виконають без порушень, дата так і не зʼявиться.

10. Розібрані пункти зводять в одну таблицю, яку називають трекером зобовʼязань. Кожне зобовʼязання займає в ній рядок, а стовпці повторюють поля: пункт, хто, що, тригер, дата і статус. Потрібна вона тому, що в договорі строки розташовані за розділами, а не за календарем, і найближчої дати з тексту не видно. Дата стоїть лише в рядках, де тригер уже настав: аванс не пізніше 17.09.2026, поставка не пізніше 29.09.2026.

11. Трекер переглядають після кожної події. Припустімо, товар був на складі, і його привезли вже в середу 16.09.2026, а Покупець того ж дня підписав накладну. Три рядки, які чекали на це, отримують дати: приймання до середи 23.09.2026, залишок до середи 30.09.2026, гарантія до 16.09.2027. Умовні рядки лишаються порожніми. Спробуйте так розібрати один свій договір: пʼять полів із кожного пункту зі строком і позначка, чи настав тригер.