Чому на це переходять

У перший день у вас робоча ERP і право її змінювати. Коробкові продукти й більшість хмарних сюїт ці дві речі разом не продають.

Коробка, яку не можна змінити. Хмара, яку не можна розширити. Замовна розробка на два роки. ZuloOne — облікова платформа, яка вже працює, і в яку все одно можна додати об'єкт, якого немає в нікого іншого: без форку і без очікування екрана від вендора.

• Описали — воно є.

  Довідник або документ — це метадані. За секунди є таблиця, API, список і картка. Ніхто не відкриває заявку на екран. Ніхто не чекає реліз заради колонки.

• Один офіс. Усі контури.

  Продажі, склад, податок, зарплата й книга — один вхід, одна стрічка, один тенант. Проведена реалізація пише залишок і книгу в ту саму секунду. Польовий застосунок говорить з тими самими API — це не другий продукт.

• Справжній облік, не поле «статус».

  Регістри тримають залишки й датовані ставки. Наступний документ і звіт читають ту саму пам'ять. Другої бази «для аналітики» немає, і таблиця Excel — не система обліку.

• Ваш процес — повноцінний об'єкт.

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

Підсумок: новий процес — це новий об'єкт на тій самій платформі, а не другий продукт, не рік екранів і не форк, який потім доведеться зливати.

Об'єкти метаданих

Бізнес-застосунок у ZuloOne — метадані плюс скрипти. З них платформа генерує таблиці, класи сутностей, REST API і весь інтерфейс.

Нижче — види об'єктів, які ви описуєте. Дванадцять модулів — комбінації цих об'єктів, а не окремі програми. Якщо модуль вас не покриває, ви додаєте той самий вид об'єкта, з якого зроблені модулі, — і в нього одразу є список, картка, API й місце на стрічці.

Довідник

Каталог записів одного виду: номенклатура, контрагенти, склади, податкові коди. Ієрархічний (групи номенклатури) або плоский. Список і картка. Посилальні поля на інших об'єктах вказують сюди — так записи пов'язані. Платформа нумерує ID, тримає переклади підпису й збирає грід і форму зі списку полів.

Документ

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

Зберегти пише запис. Склад, дебіторка й книга від цього не рухаються. Після збереження селект підтипу на картці заморожено. Наступний підтип ставить лише команда — кнопка, яка може перевірити залишок, рядки й відкритий період. Якби стан був випадаючим списком, кожна з цих перевірок була б в одному кліку від пропуску.

Цільовий підтип запускає проводки: рухи по регістрах. Одна реалізація може зняти товар з полиці, визнати виручку, нарахувати дебіторку й покласти все це в головну книгу. У підтипу може бути кілька транзакційних скриптів — за обліковою задачею: склад, собівартість, податок, GL — а не один скрипт «на все».

Сторно — теж команда, на проведеному підтипі. Рухи знімаються; правити їх руками не можна і не потрібно.

Проводки беруть дату документа, а не момент натискання кнопки. Документ заднім числом потрапляє в період своєї дати.

Що	Що це	Де
Межа проведення	Одна відсічка на весь тенант: раніше не провести й не сторнувати. Це не календар облікових місяців.	Адміністратор
Фіскальні періоди	Календар облікових періодів, у кожного свій статус. Книга вибирає період за датою документа; закритий місяць тут — не те саме, що межа проведення.	Облік

Форма

Екран довідника або документа, зібраний із полів об'єкта. Розкладку все одно можна змінювати: поля тягаються, збираються в картки й вкладки, змінюються підписи й ширини. Розкладка особиста, спільна (права розробника) або автоматична. Спільна їде разом із моделлю. Enter ходить полями, Ctrl+S зберігає, Ctrl+K шукає об'єкти й записи.

Команда

Кнопка на формі або в списку: провести, підтвердити, перерахувати, сторнувати, перетворити. Може спочатку перевірити умови, потім змінити підтип, викликати сервіс або записати регістр. Підтип зі скриптами проведення без команди переходу з UI провести не можна — так задумано.

Меню

Як об'єкти з'являються на стрічці. У моделі своє дерево: групи довідників, документів, підсумків, звітів, потім пункти. Свою гілку можна прищепити в групу моделі нижнього шару. Права ховають вкладку: немає вкладки — немає права, а не немає функції.

EDT і номерні серії

Поле типізується EDT: рядок, число, дата, булеве або посилання на довідник. Переліки — цілі. Номерна серія ставить людиночитний ID нового запису; якщо свою не оголосити, платформа заведе. Це теж об'єкти метаданих — не колонки, які ви вигадуєте в SQL.

Сервіс

Логіка, потрібна більш ніж одному скрипту: ціна, підбір, генерація наступного документа, податковий рушій. Тіла скриптів тонкі: перевірити, викликати сервіс, повернути результат. Кілька моделей можуть обгорнути один контракт сервісу через Chain of Command.

Регістри: пам'ять компанії

Регістр — не таблиця, яку заповнюють руками. Це облікова пам'ять: залишки, рухи й датовані факти. Документи пишуть, звіти й інші документи читають.

Тому не купують окремо склад, окремо дебіторку й окремо «аналітику». Товар, гроші й податок живуть тут. Наступний документ бачить те, що провів попередній.

Регістр накопичення

Виміри (номенклатура, склад, партія…) і ресурси (кількість, сума). Проведення пише рух, рушій тримає залишок. Склад, дебіторка, кредиторка, шари собівартості, податкові обороти — це регістри накопичення. Подвійний запис, FIFO і віртуальні підсумки живуть на цьому об'єкті. Рядок у нього ніхто не набиває.

Регістр відомостей

Значення, яке було правим у момент часу: ставка податку на дату, клас у журналі ABC, налаштування з історією. Один рядок на комбінацію вимірів у Period. Пізніший Period закриває попередній. SliceLast / SliceFirst відповідають «що діяло на цю дату». Це не інтервал з–по і не залишок.

Що це дає

Звіт за підсумками — початок, надходження, видаток, кінець, у розрізі аналітик регістра — без окремого аналітичного складу. Наступний документ читає той самий залишок або ту саму ставку, що записав попередній. Перерахунок і сторно — це рухи, а не правки рядків. Межа проведення діє і тут: Period за відсічкою відхиляється.

Робоче місце підсумків — цей регістр зі списком і фільтром, а не окремий продукт. Віртуальний підсумок — збережений зріз того самого регістра: групування, підпис, нульове вхідне — той самий рушій.

Робочі місця

Офіс — одне згенероване робоче місце. Стрічка, списки, картки й робочий стіл беруться з об'єктів вище, тож кожен модуль виглядає як один продукт — бо це один продукт.

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

Стрічка

Вкладки-області з командами й переходами. Типові: Робоча область, Розробник, Адміністратор. Набір — це права, а не інший застосунок.

Списки

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

Картки

Форма запису. Шапка й табличні частини на своїх вкладках. Кілька карток можуть бути відкриті одразу. Асистент стикується поруч і звужує картку, а не накриває робоче місце.

Розкладки

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

Віджети робочого стола

Плитки на домашньому робочому місці: лічильники, підсумки, короткий список, графік, скриптова плитка. Вони читають ті самі довідники, документи й регістри. Field Desk керівника — віджет, а не другий продукт.

Шари й розширення

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

System → Base → Solution → Customization → User

Модель бачить усе нижче себе і може розширювати. Чужий об'єкт на місці не править. Нове поле на довіднику нижнього шару оголошується у вашій моделі — платформа загортає його в розширення. Пункт меню можна прищепити в чужу групу. Кастомізація живе в моделі верхнього шару і їде з цією моделлю між середовищами.

Як працює розширення

На одному довіднику, документі чи сервісі живуть кілька обробників: власник у моделі самого об'єкта, потім кожен шар вище. Це Chain of Command — цибулина, не список підписок. Верхній шар стартує першим, кличе next() / nextAsync() вниз, а робота після next() бачить, що вже записали склад і книга.

Власник next не кличе. Розширення чужого об'єкта зобов'язане оголосити себе і кликати next з кожного override — інакше ланцюжок рветься. Replace ковтає решту ланцюжка навмисно. Кілька транзакційних скриптів на одному підтипі — горизонтальний список (склад, потім собівартість), не ця цибулина.

Країна — шар, не форк

Саудівський ПДВ, ZATCA, український ПДВ живуть у своїх моделях поверх Tax, Sales і книги. Вони додають ставки, звіти й вихідні канали. Спільні об'єкти вони не копіюють. Додавання країни нічого не змінює для решти.

Дванадцять модулів. Решту додаєте ви.

Модуль — довідники, документи й регістри на платформі плюс скрипти, які їх проводять. Його ставлять, розширюють своєю моделлю або не ставлять. Це не окрема програма і не окрема база.

Один проведений документ може писати регістри кількох модулів. Якщо дванадцять модулів процес не покривають, цей процес усе одно об'єкт того самого виду — не проєкт в іншій системі. Контур від початку до кінця — в темах документації (ABC/XYZ і далі).

Країнні локалізації

Країна — окрема модель поверх спільного ядра. Вона додає статутні ставки, звітність і державні інтеграції, не правлячи нічого знизу.

• LocalizationSaudiArabia

  Саудівська Аравія: ПДВ 15%, електронні рахунки ZATCA/FATOORA з підписанням і клірингом

• LocalizationUkraine

  Україна: ПДВ на продажах і відповідний регістр зобов'язань

Принцип

Бізнес-функція — глобальна. Країнний комплаєнс — локалізація. UI — з метаданих. Ціна — договір і правила, з поясненням.

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

SaaS — стенд, який ваш

ZuloOne продається як software-as-a-service. Ви не купуєте ліцензію, щоб ставити її в п'ятницю ввечері. Ви підписуєтесь на стенд: свій піддомен, свій контейнер, своя база — вже запущені.

Що входить у підписку

Хостинг, оновлення, резервні копії й люди, які відповідають, коли щось ламається. Одна ціна за стенд, а не стос ліцензій на базу, сервер застосунків і моніторинг. Плани й місця — на сторінці цін.

Не рядок у спільній базі

У кожного тенанта свій контейнер і своя база за спільним проксі. Навантаження сусіда — не ваш простій. Ваші дані ні з чиїми не змішані.

Оновлення, яке можна відкотити

Спочатку знімається снапшот, можна повернутися на попередній образ. Невдалий реліз — хвилина простою, а не відновлення з копії і не вихідні з вендором на майданчику.

Ніщо не замкнене в інстансі

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

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