Я втомився шукати шаблони рахунків, тому я побудував API, який генерує п'ять типів документів

Пошук "безплатний шаблон рахунку" проводився стільки разів на стільки браузерів, що це, мабуть, повинно кваліфікуватися як діагностичний показник власництва малого бізнесу. Закономірність завжди однакова. Новий клієнт реєструється, або починається новий проект, або настає квартальний цикл виставлення рахунків, і хтось сідає виготовляти рахунок. Існуючий шаблон, якщо він існує, або загублений в структурі папок, яку ніхто не пам'ятає, або був створений у версії Microsoft Word, яка більше не відображається правильно, або належить іншій комерційній організації і потребує значних змін, перш ніж його можна буде використовувати. Пошук починається знову. "Професійний шаблон рахунку." "Безплатний шаблон рахунку PDF." "Шаблон рахунку з розрахунком податків." Сторінка за сторінкою результатів, що пропонують шаблони, які майже підходять, але ніколи не повністю підходять, кожен з яких потребує двадцяти хвилин коригування, перш ніж його можна буде насправді використовувати.

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

Альтернатива, яка в кінцевому підсумку виникла, полягала в припиненні розглядання рахунків як документів, які потребують розроблення, і почати розглядати їх як дані, які потребують відображення. Дані, тобто хто, що, коли та скільки щодо кожної події виставлення рахунків, вже відомі на час, коли рахунок повинен бути виготовлений. Чого не вистачає, так це лише відображення: перетворення цих даних у професійний документ з правильною розкладкою, розрахунками та форматуванням. Це відображення - це саме те, що може зробити API, і це можна зробити послідовно, правильно та миттєво для кожного рахунку, у всій кожній компанії, без жодного шаблону.

П'ять типів документів та чому кожен існує

API виставлення рахунків на yeb.to генерує п'ять окремих типів документів, кожен служить конкретній цілі у робочому процесі виставлення рахунків та обліку. Розуміння того, чому необхідно п'ять типів, а не лише один, багато говорить про те, як насправді функціонує комерційне виставлення рахунків на практиці.

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

Стандартний рахунок - це основний документ виставлення рахунків, той, який більшість людей мають на увазі, коли чують слово "рахунок". Він фіксує завершену транзакцію, вказує суму, яка повинна бути сплачена, та служить юридичною основою для запиту на оплату. Податкові рахунки включають розрахунки НДС або податку на продажу, а API обробляє кілька ставок податків в одному рахунку для юрисдикцій, які застосовують різні ставки до різних категорій продуктів. Це тип документа, який використовується найчастіше і який шукають більшість пошуків шаблонів.

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

Від пошуку шаблонів до корисного навантаження JSON

Різниця у робочому процесі між виставленням рахунків на основі шаблонів та API є драматичною. Із шаблонами виготовлення рахунку означає відкриття файлу документа, заміну тексту плацехолдера фактичними деталями клієнта та виставлення рахунків, перевірку того, що формули все ще працюють після додавання або видалення позицій, коригування форматування, якщо щось зсунулося, збереження результату як PDF-файлу та архівування як редагованого джерела, так і выводу PDF. За допомогою API виготовлення рахунку означає складання корисного навантаження JSON з даними виставлення рахунків та відправлення його на кінцеву точку. Відповідь - це готовий PDF. Немає шаблону для відкриття, немає формули для перевірки, немає форматування для коригування, немає управління файлами для виконання.

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

Для компаній, які видають рахунки програмно, можливо, з платформи електронної комерції, засобу управління проектами або спеціального CRM, інтеграція API є простою. Система, яка знає, що потребує виставлення на рахунок, конструює корисне навантаження JSON зі своїх власних даних і викликає API. Між моментом виникнення подій виставлення рахунків та моментом існування професійного документа рахунку не потрібна людська участь. Для компаній, які видають рахунки вручну, корисне навантаження JSON може бути зібрано через простий інтерфейс форми, який відображає структуру входу API, все ще швидше та надійніше, ніж редагування шаблону текстового редактора.

Немає шаблонів, які можна знайти, та немає форм, які потрібно заповнити

Глибша користь API-виставлення рахунків - це не лише швидкість, але й усунення цілої категорії робіт з обслуговування. Шаблони старіють. Адреса компанії змінюється, і комусь потрібно оновити кожен шаблон. Набирає чинності нова ставка податку, і кожна формула потребує перегляду. Логотип компанії переробляється, і кожен шаблон потребує нового зображення, вставленого в правильну позицію. Це малі завдання окремо, але серед трьох компаній з кількома варіантами шаблонів, вони становлять постійний фон осушування часу та уваги.

При підході на основі API такого обслуговування не існує. Деталі емітента зберігаються як дані та включаються в корисне навантаження JSON. Коли адреса змінюється, дані змінюються в одному місці, і кожен подальший рахунок автоматично відображає оновлення. Коли ставка податку змінюється, параметр ставки в корисному навантаженні змінюється, і API розраховує правильно з першого рахунку за новою ставкою. Коли логотип змінюється, URL-адреса зображення в конфігурації змінюється, і кожен майбутній документ несе нове брендування. Немає файлу шаблону, щоб знайти, редагувати, перевірити та розповсюджувати. Існують лише дані, а дані легко оновити.

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

Чому це почалось з трьох компаній, а не з однієї

Один бізнес з простими потребами в закупівлях може обійтися шаблонами. Розчарування керується, коли існує лише один набір шаблонів для обслуговування, один стандарт брендування для дотримання та одна податкова юрисдикція для обробки. Підхід на основі шаблонів розпадається, коли складність збільшується, а управління трьома окремими компаніями надало саме складність, необхідну для викриття кожної слабкості в традиційному підході.

Кожна компанія працювала в дещо іншому контексті. Один видав рахунки-послуги міжнародним клієнтам у кількох валютах, вимагаючи гнучкої обробки валют та міжнародних деталей банківської справи на кожному документі. Інший видав рахунки продуктів на внутрішньому рівні з болгарськими розрахунками НДС, які потребувало дотримання вимог податкового органу щодо форматування. Третій працював за гібридною моделлю, видаючи як рахунки на послуги, так і рахунки на продукти для комбінації внутрішніх та міжнародних клієнтів. Три різні шаблони, три різні вимоги до розрахунків, три різні стандарти форматування нормативних актів. Збереження всього цього у файлах текстового редактора було не просто неефективним; це був схильний до помилок способ, який мав справжні наслідки для обліку.

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