Як я розробляю власний продукт для автоматизації діяльності бізнесу на заміну 1С

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

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

1. Суть проблематики

Про необхідність заміни російського програмного забезпечення сказано й написано багато. В сегменті автоматизації діяльності бізнесу в Україні безумовним лідером є лінійка продуктів 1С (в тому числі з новим брендом BAS).

Статей та обговорень можливості заміни даного програмного забезпечення теж чимало (ось деякі приклади: Що таке 1С і чому її важко (але потрібно) замінити в Україні. Думка, Чи існує заміна 1С в Україні, або Варіант докорінного рішення проблеми).

Сам 20 років займався автоматизацією різних видів бізнесу за допомогою 1С. З 24.02.22 вирішив спробувати знайти альтернативну систему розробки застосунків для автоматизації управління та обліку бізнесу.

Так як основна моя спеціалізація — розробка ПЗ під індивідуальні вимоги конкретного бізнесу, при пошуку керувався наступними основними критеріями:

  • можливість вносити зміни в існуючі продукти та можливість розробляти продукти «з нуля» (обов’язково);
  • умовно допустима собівартість розробки (щоб не виходило набагато дорожче чим на 1С);
  • враховувались технологічні можливості та обмеження побудови продуктів на платформі (що є «в коробці» платформи, з чим буде важко в розробці) — знову ж таки, в порівнянні з платформою 1С;
  • відносно невисокий поріг перекваліфікації для програмістів 1С, які окрім 1С не володіють технологіями розробки на інших мовах програмування (один в полі не воїн — послідовників в основному надіюсь знайти з програмістів 1С).

Пів року активно шукав і знайомився з різними системами, які могли б стати заміною 1С. Розглядав як вітчизняні продукти (A2V10, A5 (Unity Base), IT-Interprise, відносно недавно познайомився з Вправно), так і іноземні (Oddo, SAP, Microsoft Dynamics).

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

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

На початок розробки даного продукту в мене практично не було ні досвіду, ні знань технологій, які планував використовувати (20 років майже тільки 1С, навіть SQL не вмів користуватись). Розробку вів частково своїми силами (паралельно вивчаючи технології), а частково наймав спеціалістів (деякі технології виявилось освоїти важко).

Протягом перших двох місяців взагалі у всіх, кого можна питав, на яких технологіях краще будувати свої ідеї — рекомендації були досить різні. Деколи мені говорили, що «це працювати не буде», «так ніхто не робить».

Але пройшло 8 місяців розробки, і я готовий показати проміжні результати. Буду вдячний за об’єктивну критику та рекомендації — саме їх хочу почути в першу чергу.

2. Про ідею та на кого орієнтований продукт (програмісти/ кінцеві клієнти)

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

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

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

3. Загальна структура платформи та готового бізнес-застосунку та які технології використовуються

Готовий бізнес-застосунок на даній платформі — це фактично WEB-сайт в форматі SPA-застосунку (односторінковий WEB-сайт). Архітектура готового бізнес-застосунку, можна сказати, стандартна — трирівнева:

  • клієнт (браузер);
  • сервер (застосунок ASP.NET Core на IIS);
  • СКБД (система керування базами даних).

Рис. 1. Загальна архітектура системи

Кінцевий користувач працює в браузері, браузер відправляє запити серверу, сервер їх обробляє, при потребі звертається до конфігурації та/або до СКДБ. Після цього потрібні дані у зворотному порядку відправляються браузеру, який відображає їх в потрібному форматі.

Технічно бізнес-застосунок (готове для використання програмне забезпечення для кінцевого клієнта) — це конфігурація плюс база СКБД (або декілька баз СКБД).

Конфігурація — це папка з певною структурою підлеглих папок, в якій містяться файли з правилами та кодом для роботи даного бізнес-застосунку (правила обміну даними між клієнтом та СКБД за допомогою сервера). Як правило, це файли в текстовому форматі: json, html+js, sql.

Одне з ключових питань кінцевих клієнтів, коли приймається рішення, чи підходить технологія для заміни 1С: де будуть знаходитись дані? Тому уточню можливі варіанти щодо розміщення бізнес-застосунків (СКБД з даними, сервер платформи та конфігурації) по серверам:

  • все розміщується на серверах клієнта (класичний варіант розміщення баз 1С);
  • на серверах клієнта зберігається СКБД з даними, а сервер з конфігурацією — на серверах компанії, яка надає IT-послуги (може бути актуально при розробці додаткового WEB-інтерфейсу для баз 1С);
  • все розміщується на серверах компанії, яка надає IT-послуги (класичні online-сервіси).

4. З чого складаються платформа та конфігурація та які технології використовуються

Платформа складається з:

  • сервер (на C# ASP.NET Core);
  • клієнтська частина (JavaScript + в деякій мірі фреймворк Vue).

В перспективі до складових платформи варто було б додати умовний «Конфігуратор» (як в 1С, але зі значно меншим функціоналом). На початку проєкту навіть запустив процес розробки конфігуратора, але потім заморозив (трудоємко, дорого і малоефективно). Тому вирішив до питання розробки конфігуратора повернутись пізніше.

Функціонал платформи (серверна та клієнтська частини) реалізований відносно на базовому рівні. Далі коротко перерахую реалізований функціонал на момент написання статті.

4.1. По роботі з СКБД

  • Як основну СКБД можна використовувати або MS SQL, або базу 1С 8 (в останньому випадку бізнес-застосунок фактично буде альтернативним інтерфейсом роботи з базою 1С, для 1С 7.7 підключення не розробляли, але при потребі можна доробити);
  • при роботі з MS SQL рекомендується використовувати певну конфігурацію базових таблиць (спрощується в деякій мірі розробка).

Використання postgree поки не реалізовано (планується реалізувати в майбутньому).

4.2. По роботі сервера

  • Можливість одного сервера паралельно обслуговувати декілька бізнес-застосунків (за аналогією з сервером/службою 1С, яка обслуговує різні бази);
  • можливість запускати декілька «серверів платформи» на одному WEB-сервері — кожен сервер обробляє свій список баз (декілька сайтів ASP.NET на одному WEB-сервері IIS).
  • «гаряче» (без зупинки сервера і бази) перезавантаження конфігурації конкретної бази (дана можливість вмикається для кожної бази окремо);
  • можливість для декількох баз використовувати одну конфігурацію — кожна база використовує одну й ту ж саму конфігурацію, але СКБД у кожної бази своя (в логіці 1С — це коли б декілька баз використовували б один *.cf — відпадає потреба переносити зміни конфігурацій з однієї бази на іншу, доволі зручно при розробці і тестуванню);
  • можливість працювати з різними СКБД (поки тільки MS SQL та 1С);
  • можливість в одній базі підключатись до додаткових СКБД: додатково до основної СКБД можна підключати довільну кількість інших баз СКБД в різних форматах (поки тільки MS SQL та 1С);
  • при використанні 1С як основної СКБД для доступу користувачів (логіни/ паролі) може використовуватись один конкретний обліковий запис 1С, або персональні (в останньому випадку будуть автоматично використовуватись доступні в 1С логіни/ паролі, на рівні бізнес-застосунку логіни/ паролі доступу до 1С не зберігаються, на рівні 1С використовується повноцінний механізм прав по ролям та RLS);
  • реалізовано декілька варіантів підключення до 1С:
    — http-запити;
    — підключення через COM-об’єкт;
    — підключення напряму до MS SQL (не рекомендується, відповідальність за цілісність бази залишається за розробником бізнес-застосунку);
  • сервер приймає запити від клієнта (браузера), і в залежності від параметрів запиту відправляє відповідні запити до потрібної СКБД в потрібному форматі.
    При використанні MS SQL — це повноцінний код на T-SQL з можливими параметрами.
    При використанні 1С — це назва методу з можливими параметрами, а сам код повинен бути написаний вже в 1С (загальний модуль з певною назвою та однією точкою входу).

Окремої своєї «серверної мови» поки немає (по даному питанню поки рішення не прийнято і навіть серйозно не займався цим питанням).

4.3. По роботі клієнта

  • Базовий каркас інтерфейсу складається з меню (+можливість перемикатись між різними варіантами меню, в логіці 1С — між «інтерфейсами») та робочої області.
  • робоча область використовується для розміщення «вікон» (вікно — форма/ інтерфейс відображення об’єкту довідника/документа, форма списку, форма звіту, довільна форма тощо);
  • для зручної навігації реалізована технологія «панелі вікон»;
  • вікна працюють на розробленій технології «локального url» — аналог рядка url в браузерах (відповідно є можливість обмінюватись між користувачами локальними url в текстовому форматі для швидкого відкриття конкретних вікон);
  • розробка самих «вікон» полягає в написанні html-коду вікна з прив’язкою до даних, які отримані з серверу (або будуть отримані пізніше) та, при необхідності, написанні допоміжного коду на JavaScript;
  • як правило форми вікон будуються з використанням фреймворка Vue.js (на стороні серверу реалізований механізм підключення даного фреймворка до кожного окремого вікна);
  • для спрощення розробки конфігурацій розроблений список методів на JavaScript. Це умовна стандартна бібліотека методів «високого рівня», щоб розробнику бізнес-застосунку максимально не потрібно було опускатись в низькорівневе програмування (в логіці 1С — це методи з синтаксис-помічника). Розширення даного стандартного списку методів являється одним з пріоритетних напрямків в розвитку платформи. Це важливо для прискорення розробки готових бізнес-застосунків та зменшення порогу входу для розробників, які не знайомі з JavaScript/html/css;
  • частково реалізовані базові класи css для елементів діалогу (таблиці, поля вводу/вибору тощо).

Дизайном (CSS) серйозно не займались — так що виглядає не дуже красиво (зараз не варто витрачати енергію на критику кольорів, розмірів тощо). Для приведення дизайну в порядок планую знайти окрему людину, яка вміє цим займатись.

5. Вигляд бізнес-застосунку (приклади)

Рис. 2. Вигляд бізнес-застосунку

Рис. 3. Вигляд ієрархічного довідника

Рис. 4.1. Вигляд простої таблиці

Рис. 4.2. Вигляд коду html+js для вікна на рис. 4.1.

6. Які вимоги до програмістів для написання бізнес-застосунків

Потрібні як мінімум базові знання наступних технологій:

  • HTML (хоча б базовий рівень);
  • СSS (бажано хоча б базовий рівень);
  • JavaScript (хоча б базовий рівень);
  • T-SQL та Microsoft SQL Server Management Studio (або якийсь аналог) — якщо в якості СКБД буде використовуватись MS SQL;
  • Розробка в 1С­ — якщо в якості СКБД буде використовуватись 1С.

При всьому бажанні зробити розробку бізнес-застосунків простою, швидкою та зручною — поки не можу сказати, що розробку по даним параметрам можна порівнювати з розробкою в конфігураторі 1С. Поки в цьому напрямку потрібно ще багато працювати.

Є багато ідей, але їх розробка (аналіз, дослідження та реалізація) потребує чималих ресурсів. Але «все життя спереду ж» )

7. Доступ до демо

Окрім скрінів в статті можна спробувати глянути на інтерфейс на демо-базі (логін: Test1, пароль: 123). Доступ до демо пізніше відключу, так що посилання може не працювати.

8. Переваги та недоліки системи (в порівнянні з 1С)

Переваги:

  • швидша робота готового бізнес-застосунку (в першу чергу порівняно з роботою 1С через браузери);
  • повноцінний WEB-сайт, з меншими обмеженнями побудови інтерфейсу (в 1С свій обов’язковий каркас інтерфейсу);
  • можливість використовувати всю силу JavaScript та CSS для побудови інтерфейсу (в тому числі розподіл процесу розробки на програміста та верстальника/дизайнера, що в 1С не звично).

Недоліки:

  • швидкість розробки значно нижча;
  • використання JavaScript та CSS (навіть в базовому варіанті) окрім гнучкості та широких можливостей вимагає відповідних знань (JavaSript ще так собі, а от CSS — магічна технологія, від якої я постійно втікаю);
  • набагато складніший процес відладки (точки зупину тільки в браузері — не звично й відповідно не комфортно, відладка часто через повідомлення);
  • поки немає звичного конфігуратора з деревом метаданих (я за рік так і не звик до розробки в файлах);
  • платформа в розробці, тому часто буде змінюватись (перероблятись) існуючий функціонал;
  • на даний момент відсутня інформаційна підтримка (навчальні матеріали, в гуглі нічого не знайдеш, немає можливості поставити питання й отримати відповідь).

9. Деякі плани на майбутнє щодо технологічного розвитку платформи

Як вже раніше писав — ідей по модернізації системи багато. Коротко озвучу основні:

  • інтерфейс під планшети/смартфони;
  • конфігуратор;
  • робота з postgree;
  • серверна мова (розробити технологію, або відмовитись зовсім);
  • розробка готових бізнес-застосунків (типових рішень).

10. Стан проєкту на зараз та можливі організаційні плани розвитку проєкту

На даному етапі система знаходиться в стані постійних експериментів, доробок та переробок. Зараз активно проєктом займаюсь я та допомагає ще один програміст — Олександр (окрема подяка йому за його вклад як програміста і особливо за консультації — без нього набагато довше блукав би в невідомих мені технологіях).

Я переважно займаюсь ідеологією системи, розробкою серверу, всіма питаннями по роботі з СКБД, частково розробкою клієнтської частини, розробкою бізнес-застосунків. Олександр займається розробкою клієнтської частини (як правило базові низькорівневі технології на JavaScript, базовий CSS, консультує мене по WEB-технологіям).

Не дивлячись на те, що продукт дуже «сирий» — вже розробляється перший робочий проєкт для клієнта (зараз цей проєкт на стадії впровадження та робочого тестування). Планую десь за місяць-другий запустити базовий функціонал й перейти до постійного вдосконалення бізнес-застосунку (цим займався 20 років і мені це подобається).

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

Окрім використання платформи у власних розробках, в процесі обов’язково враховував те, щоб дану платформу змогли б використовувати інші розробники. Якщо робити доступною платформу для широкого кола розробників — потрібно додатково чимало зробити для того, щоб освоєння розробки на ній було реальним для пересічного 1С-програміста.

Для популяризації системи потрібні:

  • технічна документація;
  • детально описаний процес створення та запуску мінімального бізнес-застосунку;
  • сайт з прикладами вирішення елементарних задач;
  • організувати підтримку розробників (відповіді на питання в чаті, а краще в форматі форума);
  • приймання інформації про помилки та побажань з розвитку платформи.

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

Також поки немає прийнятого рішення щодо фінансової моделі використання системи — поки продукт (платформа) розглядається як комерційний.

11. Подяка та зворотній зв’язок

Всім, хто осилив прочитати все до кінця — дякую. Окремо буду вдячний за оцінку ідеї/ реалізації, побажання та рекомендації. Все це краще писати знизу в коментарях.

Щодо якихось суто технічних питань — краще в групі телеграму їх ставити: Група в Telegram для обговорення технічних питань. Намагатимусь відповідати оперативно.

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному1
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Головне чого не розуміють автори, принаймі не бачу в спробах:

1С насамперед це платформа для — РОЗРОБНИКІВ.
Вони с самого початку зрозуміли що успіх продукту — це люди, ком’юніті, а тому відразу почали розвивати мережу франчайзі та зробили акцент на зручності=швидкості — розробки.
«А франчі собі клієнта самі знайдуть. Ну і наш продукт продадуть»

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

Наприклад існує думка:

але з того що знаю, то основною їх фічею було слідування законодавству.

Саме так. Але ж — хто саме підтримує актуальність законодавствам? Сама 1С? ні.
Франчі і підтримують. Їм в цілому без різниці — на чому, хоч на «С++».
Але їм критична — «собівартість експлуатації», і от тут виявляється що підтримувати рішення на платформі 1С вимагає набагато менших витрат, аніж на «С++».

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

Кажуть ще — а чого ж на Заході 1С не взлетіла? Відповідь — там інший тип, філософія обліку для малих та середніх підриємств. Такі складні рішення, які дозволяє швидко робити платформа 1С там не потрібні. Достатньо «Oracle APEX» та подібних.

Із цікавих конкурентів 1С, які розуміють в чому кілер-фіча 1С бачив бєларуську lsFusion (з декларативною аля SQL мовою) або «Вправно» (Low-Code платформа Codejig www.codejig.com/uk/platform/ з візуальним програмуванням із дитячного Scratch)
Навожу як приклади що думати треба не про «бухглатера» а про — розробника. Тоді є шанс на успіх.

Тобто треба — ідея радикально зменшуюча складність розробки «прикладним програмістом», а не чергове
сервер (на C# ASP.NET Core);
клієнтська частина (JavaScript + в деякій мірі фреймворк Vue).

Помилка, роками у спробах (скільки вже їх не перебачив ще з часів коли сам був 1Сником)
Переплутана цільова аудіторія.

Платформа розробки бух обліків потрібна програмістам а не «бухгалтерам».
Або — консалтерам, як SAP.
Самі голі SAP, 1С, Odoo, ... «бухгалетрам» не потрібні.

І тепер питання до автора, любої такої платформи:
Кому «продаєте» результат своєї праці?
Хто ваш customer?

І виходячі з відповіді — що кращого ви пропонуєте цьому кастомеру аніж «продукт Х»?

Подивіться на Oracle APEX. Якщо поєднати його з безкоштовною автономною базу в хмарі Oracle — виглядає як системне рішення. Я 10 років для своїх клієнтів впроваджував заміну 1С на цій платформі.

1991 рік. Торвальдс запостив свою першу версію Лінукс.
— Подивіться на MS DOS, я вже 10 років його використовую, та продаю його своїм клієнтам. Виглядає як системне рішення.
— Виділити папка з лінукс. Ctrl+A, Ctrl+D.
Дякую, дуже дякую!

Чому за 10 років дана технологія не набула популярності?
Які більш конкретні Ваші успіхи за 10 років роботи з технологією?
Які слабкі сторони даної технології?
Чи зможе дана технологія успішно конкурувати в Україні (в сегменті 1С)?
dou.ua/forums/topic/24441 проглянув.

Чому за 10 років дана технологія не набула популярності?

— Чому не набула? 500к розробників, всі хто працює з Ораклом про неї знають, зараз це флагманська технологія Оракл. Якщо ви про неї не знаєте, то це не всі. І технології вже скоро 20 років :)

Мав на увазі популярності як конкурента 1С.
Не піддаю сумнівам поширеності світових популярних технологій, але поки розглядаю саме через призму конкуренції з 1С.
Оракл, САП, Динамікс — не розглядаю як ефективних конкурентів 1С (для дрібного, малого та середнього бізнесу)

Саме для мілкого бізнесу і використовував. Писав самостійно невеличкі конфігурації для торгівлі або послуг за 1-2 місяці під ключ. Для великих проєктів також але там вже була команда.

Які більш конкретні Ваші успіхи за 10 років роботи з технологією?

— я впевнений що ви точно отримували послугу з продуктів які я написав :)

Які слабкі сторони даної технології?

Основна проблема — це пропріорітарне рішення яке працює тільки з Oracle. Тут або заробляти гроші, або іти в опенсорс і стати популярним — Oracle вибирає перше.

Чи зможе дана технологія успішно конкурувати в Україні

— може. Але потрібно вкласти купу грошей і створити конфігурації оптимізовані під наше законодавство

Підключати ШІ К8Т і на хмарний сервіс

Основное преимущество 1С — быстрая разработка. Вот на это нужно давить в первую очередь.
У вашего решения затрудненная отладка, html, css — т.е. даже в перспективе это не будет быстрее чем 1С.

Неполучится просто решить сложную проблему.

По вказаним перевагам 1С — згоден.
І по умовним своїм «проблемам» (отладка, html, css) — важко не погодитись.
Але в 1С є не тільки сильні сторони, а й слабі: в браузері працювати далеко не комфортно (як по інтерфейсу, так і по швидкості), і вирішити ці проблеми команія 1С поки не в змозі.
В мене немає ілюзії, що можна по всім параметрам так просто догнати й перегнати 1С.
Але зробити продукт, який зможе в якійсь мірі успішно конкурувати в кастомних розробках — можливо, я в це вірю.
Правда потрібно ще багато зробити.
Наприклад — візуальний редактор форм, щоб не потрібно було вмирати на html та css (це не легко, але реально).
Що стосується зручності відладки — я поки не розумію як організовуються механізми відладки з точками зупину на низькому рівні. Тому поки немає розуміння як покращити ситуацію по даному питанні — поки повідомленнями й точками зупину через браузер.

Особисто в мене багато питань.
Найголовніше-шоб займатися такого роду системами треба мати в штаті десятки(якщо не сотні співробітників) -хто за це буде платити ?
Думаю, чимало людей пам’ятають як до масового приходу 1с були сотні саморобних систем на всіляких ФоксПро, Дельфі та тому подібному. І де вони зараз ? А сталося це тому що розробникам було цікаво «пиляти» формочки а на маркетинг та продаж забивали. Та й власне грошей таких не було. Не треба повторювати помилки 25 річної давнини. Декілька чоловік в вільний від основної роботи час чогось проривного навряд чи створять.
Стосовно технологічного стеку: натякну що якщо вже створюєте щось з нуля в 2023 році то на мою думку є сенс звернути увагу на Флаттер. Там мова програмування схожа на Джаваскрипт (але як на мене -краща) і щоб робити чудові форми не потрібен ні html ні css.
Программа буде працювати скрізь — і на Windows на мобілках і в Веб. І ії-ж можна використовувати для бек-енду. Її навіть можна транслювати в джаваскрипт.
І до речі — не розділяю вашу прив’язку до Веб -платформи. Якщо ми говоримо про невеликий магазин — навіщо їм Веб і взагалі бекенд ? Там все вміститься в локальній БД на плашеті, максимум бекапи в мережу скидувати будете... Зате така система буде стійка до відключень світла/інтернету.
В тій-же 1С веб-режим мало де використовуєтся. Так, фішка для реклами не більше.
Всі як сиділи в звичайній программі під сервером терміналів так і сидять. Але 1С можливо без проблем запустити на локальній БД без всіляких серверів та інтернетів, а у вашому варіанті -навряд.

1. Не поділяю погляди в обов’язковості десятків/сотень розробників, хоча й розумію що просто так «за вечір» таки системи не робляться. Час покаже що вийде.
2. Про Flutter — поки не знайомий, короткий огляд зацікавив, попробую глибше розібратись — дякую.
3. Продукт більш орієнтований на малий та середній (не дрібний) бізнес. Мобільні додатки — не сегмент даного продукту.
4. 1С в вебі не популярний, тому що тугодумний по швидкості й більш обмежений по функціоналу чим та сама 1С через RDP.
5. Десктопні програми доволі обмежені в масштабуванні. Це може бути цікаво для дрібного бізнесу. Я не бачу перспектив для десктопних додатків в цій сфері. Те що 1С використовують десктопно — це більш пережиток та «історично склалось», тому що 1С — практично монополіст.

1.Я мав на увазі не зовсім розробників а саме співробітників.
Для серьозної розробки вам для початку потрібні бізнес аналітики які визначаться що саме повинне бути зроблене, програмісти які це все зроблять, тестувальники які все це перевірять і підтвердять що все норм, адміни що будуть дивитися за вашими серверами, окремий відділ маркетингу та продаж щоб про вас взгалі знали и хтось міг проявити зацікавленність.
Само -собою -техпідтримка -люди які будуть піднімати слухавки і розбиратися що там юзери понаробляли.
Окремо- адмін.персонал та бухгалтер.
Я про те що це все доволі вартісний проект і у 1С штат більше тисячі співробітників не просто так. І декілька програмістів +декілька БА та тестерів (кожен з яких може заробити 1-5куе десь на стороні якщо чогось вартий) це вже десятки тисяч долларів ЗП на місяць і проект не на один рік. Тобто якщо є зайвих сотні тисяч (а краще пару млн.$). яких не жалко втратити -можна пробувати. А на голому ентузіазмі воно далеко не заїде.
3. (Про мобільні додатки).Я їх привів не просто так. І на великих підпрємствах керівництво хоче бачити у себе в мобільці якісь дешбоарди по діяльності свого підприємства і на маленьких магазинчиках на планшеті/мобільці можливо вести якийсь облік — власникам можливо продати пограму, а купляти якісь додаткові комп’ютери воні не будуть. Питання в тому що все потрібно обмірковувати заздалегіть. Якщо ви будете використовувати якісь кросплатформенні засоби то у вас буде:
1. Перевикористання коду. Те що написано під Веб без змін працює на мобільці. Зрозуміло що прийдеться адаптувати UI але це відносно невелика частина роботи.
2. Універсальні програмісти які уміють робити все на вашому проекті(прямо як на 1С).

Я колись взявся на свою голову трохи доробити проект де мобілка на андроід -java, веб на html+css+javasript і бек на ПХП — то це був жах. Чим менше мов використовується-тим краще.

1. Я так зрозумів, що Ви маєте на увазі розробку та підтримку готових типових бізнес-рішень. Для них звісно потрібно багато ресурсів. Дана стаття тільки про технологію платформи, як інструмента для розробки готових бізнес-рішень. Розробкою й підтримкою своїх рішень можуть займатися окремі компанії (так в 1С було 20 років тому, і ці компанії між собою конкурували своїми продуктами, написаними на 1С). Ці ресурси потрібні не залежно від платформи (в тому числі і для розробки/підтримки конфігурацій 1С).
3. Реалізувати альтернативний інтерфейс для планшетів/смартфонів — задача актуальна, але все таки другорядна. Варіантів вивести на смартфони не один (починаючи від налаштувань css основного додатка, до окремих мобільних додатків).
Що стосується «універсальної мови/технології» для бекенда, фронтенда та з автоматичним нормальним відображенням на ПК та на смартфоні й без кучі додаткових «але» — поки не зустрів такої технології.

якщо вже створюєте щось з нуля в 2023 році то на мою думку є сенс звернути увагу на Флаттер

Flutter — це Dart.
Дивимось рейтинг мов програмування на доу: JavaScript перший, Dart в жопі. А якщо завтра гугл передумає і скаже «Щось наш дарт непопулярний, ми закриваємо проект» (як було з Google+), а ви вже проект допиляли до якогось релізу і навіть комусь продали — будете підтримувати, як зараз прогери на бейсіку сидять? А спеціалістів де будете шукати? Зараз жуніор фронт-ендерів повно, багато хто може й зацівавитись, в т. ч. і допомогти автору, з Flutter — не знаю.

Программа буде працювати скрізь

Тоді вже ReactNative запропонуйте

навіщо їм Веб і взагалі бекенд

А чому б і ні? Фронт на 10 касах працює, бек десь один стоїть на умовному Raspberry Pi чи Пк на вінді і нема гемору з синхронізацією даних. Зник зв’язок? Синхронізуємось, коли з’явиться. Накрився планшет? Взяли новий і за 3 хв налаштували робоче місце (залишки по касі і ціни підтягнулись з бека). Веб-платформа всього лише метод реалізації клієнт-серверної архітектури.

В тій-же 1С веб-режим мало де використовуєтся.

Сам режим — так. Але веб-сервер багато де. Будь який обмін зі сторонніми сервісами. Нестандартний обмін між різними конфігураціями і версіями.

ле 1С можливо без проблем запустити на локальній БД без всіляких серверів та інтернетів

тут взагалі не зрозумів. пан знає, що клієнт-серверна архітектура — це не лише про інтернет?

1. Людина яка знає Javascript без проблем перейде на Дарт. Там практично все те-ж саме але в дещо інщому синтаксисі та трохи повикушували деяку дурню.
2. Флаттер -це опенсоурс проект. Просто взяти і закрити його Гугл не зможе. В самому гіршому варіанті він буде драйвитися коммюніті.
2. РеактНейтів -можливий варіант але гарно працює коли у вас вже є якесь рішення під Веб на реакт. Якщо писати щось з нуля — я-б такого не робив. На Віндовс та Мас ви таке запустите тількі в браузері. Крім того якщо мова йде про перенавчання 1С-в то їм прйдеться ставати повноцінними фронтендерами, вивчати хтмл, цсс, джаваскрипт, реакт чи ангуляр. Щось мені підказує що 99% цього зробити не зможуть.
3. Тримати повноцінний сервер можна, але якщо об’єми невеликі — не зрозуміло для чого, якщо все поміститься в якомусь SQLlite чи чомусь подібному прямо на пристрої.
4. Так, пан знає що таке клієнт-серверна архітектура і для чого вона потрібна, але дуже значна кількість місць де стоїть 1С це один єдиний комп’ютер на якому один бухгалтер щось там робить. 1С дозволяє «легким рухом» руки встановити туди файлову базу, чому нове рішення повинно бути гірше ?

Моя думка:
1. Всім хочеться відійти від зоопарку в ІТ.
2. Бух облік та управлінський облік має сенс вести в одній системі (щоб не дублювати проводки).
3. Жоден самопис, як і 1С не пройдуть зовнішній аудит.

Зовнішній аудит-це про великі компанії які можуть дозволити собі витратити мілліони долларів на SAP чи подібне. І там де це потрібне він вже є.
А 1С використовуєть компаниї які рахуюють кожну копійку. Впевнений що 90% компаній які її зараз використовують як почують що треба витратити хоча-б 100 т.грн. на заміну російської 1С скажуть: «працює ? — не чіпайте».

Не тільки великі. Це може бути і середній бізнес, що хоче торгувати закордон в ЄС, наприклад.
Нажаль, навіть великий бізнес часом веде звітність в excel.
В Германії навіть у антикварного магазину може стояти SAP business one. Це більше звичка користуватись легальним софтом та платити за нього.

1. «Всім хочеться відійти від зоопарку в ІТ» — логічно.
2. «Бух облік та управлінський облік має сенс вести в одній системі (щоб не дублювати проводки)» — повністю згоден, але на перших порах занадто складна задача. В майбутньому так і буде.
3. «Жоден самопис, як і 1С не пройдуть зовнішній аудит» — вимоги пройти зовнішнішній аудит в Україні — це для великих компаній. Поки це стане стандартом в Україні — багато води ще витече.

З точки зору розробника 1С які я тут бачу проблеми.
1. Рішення про покупку приймає власник бізнесу. І для нього у тому числі актуальне питання підтримки. 1С підтримується величезною компанією, кількість розробників велика, коштують вони недорого. Хто буде підтримувати ваш продукт?
2. Ви перерахували що треба знати SQL, CSS, JavaScript, HTML. Але же це арсенал фронт-енд розробника. Навіщо з цим знанням пхатися у сферу такої розробки, коли можна піти у фронт-енд з перспективою більших заробітків. Тут вже не буде відносно легкого входу, як у 1С.

Як на мене, не треба вигадувати велосипед. Розробка продукту рівня 1С коштує дуже дорого. І самотужки ви просто зробите черговий продукт для себе. Тому я вважаю, що простіше за все було б спробувати домовитися з одним з великих розробників аналогічних продуктів для бізнесу: SAP, Mircosoft, Saleforce і т.д., для того, щоб вони трохи вклалися у українську економіку, а саме: зробити ціна на ліцензії такі, щоб їх продукти могли конкурувати з 1С. Вклалися у навчання спеціалістів і користувачів. Зробили прості і недорогі типові рішення для бухгалтерії, зарплати, складу, як це є у 1С. Особливо рішення для малого бізнесу. За моїм досвідом у 1С десь 80% користувачів не вимагають ніяких дописувань.
Ринок України не такий маленький і 1С займає у ньому величезну частку, тому якщо зайняти цю нішу, то далі можна заробляти, а ще виростити купу людей, які зможуть працювати на закордон тим сами популяризуючи їх продукт.
Але для цього потрібна участь держави і треба переконати ті компанії, що варто наразі вкластися в наш ринок. Тим більше ці вкладення будуть не такі і великі.

1. По підтримці продукту: надіюсь досягти такої простоти роботи з платформою, що частина існуючих програмістів 1С (і компаній, які зараз обслуговують 1С) зможуть перекваліфікуватись на цю систему розробки. На них і надія.
2. Надіюсь, що знання SQL, CSS, JavaScript, HTML для розробки готових рішень потрібні будуть не глибокі, інакше, згоден, просто це не витримає конкуренції по зарплаті з класичною WEB-розробкою.
3. Вартість продуктів SAP, Mircosoft (про Saleforce не скажу) настільки висока, що навіть з наданою для України знижкою в 80% (на 2 роки, залишився рік мабуть) це набагато дорожче 1С. Я не вірю в цей напрямок як мінімум по ціновій політиці. Не думаю що ці компанії змінять свою політику. Поширенням SAP, Mircosoft займаються інші компанії (не дуж численні, я так зрозумів, коли рік тому шукав альтернативи). Я не знайомий з цими продуктами й відмовився йти в цьому напрямку.
4. Я орієнтуюсь на управлінський та оперативний облік, а не на бухгалтерський. А в цій сфері немає загально прийнятих стандартів — часто індивідуальна розробка. Тому 80% користувачів — це скорше офіційна бухгалтерія. Для офіційного бухгалтерського обліку є чимало готових рішеннь українських компаній. Стати черговим аналогом — точно не моя ціль, хоча в перспективі (мабуть не близькій) можуть бути рішення й для офіційної бухгалтерії.
1С просували програмісти, такі як я, тому моя ціль — зробити платформу, конструктор.
Якщо це мені не вдасться, то готові рішення не допоможуть у досягненні цілей.

Почему бы не сделать просто клон 1С, с очень похожим синтаксисом?

1. Повторити весь функціонал 1С в точності (конфігуратор, звичйні й тонкі форми, робота в браузері тонких форм) — не берусь навіть оцінити на скільки це реально, скільки потрібно ресурсів (календарного часу та фінансів).
2. Копія як правило завжди гірше за оригінал — малоймовірно, що копію будуть серйозно розглядати як заміну оригіналу, якщо оригінал дешевий. Бізнесу це непотрібно. Бізнес буде розглядати тільки краще для себе (політичні гасла «не 1С» більш працюють в на публіку, чим на справді).
3. Варіант реалізувати тільки серверну мову взявши за основу синтаксис 1С (практично мова Basic на кирилиці) — мною розглядається як один з варіантів.
4. Реалізувати мову для клієнта на основі синтаксису 1С теж поки не відкидаю (практично буде конвертація в JavaScript), але поки що вважаю, що сумнівна користь.
Вважаю що у нового продукту більше шансів на розвиток, чим у копії з багажем «так історично склалось».

Почему бы тогда не сделать клон не 1С, а SAP R3? Потому что 1С это не только синтаксис.

Наверное потому что автор ищет альтернативу 1с, а не сап.

Я к том, что сделать «клон 1С» это задача не одного человека, а большого коллектива разработчиков. И это только про сделать платформу. А если мы говорим ещё и повторить все типовые решения, то это отдельная задача.

Повторюсь, що не роблю клон 1С.
Звичайно мій досвід 20-ти років досвіду як розробника/інтегратора 1С й лідируючі позиції 1С в Україні не можуть не впливати на те що роблю.
В своїх планах не планую клонувати типові рішення 1С, тим більше всі.
Я не вірю в перспективи клонів, в клони типових конфігурацій в тому числі.
Хоча при розробці, звичайно, багато чого буде подібне на 1С, так як це потрібно буде продавати користувачам, які зараз знають 1С.

У вас є уникальний шанс виправити помилки 1С, які вони вже виправити не зможуть через зворотну сумісність.

З SAP R3 технічно не знайомий.
На скільки реально зробити клон SAP R3?
Скільки потрібно ресурсів для цього (календарного часу та фінансів)?
Скільки будуть коштувати готові рішення на такому продукті?
Наскільки просто буде просувати даний продукт-копію, якщо оригінал на Україні не дуже популярний?
Чому цього ніхто ще не зробив?

Я думаю всі свідомі 1с-ки тільки за появу такого продукту. Адже в наш тяжкий час, свічнутись з 1с на інший стек технологій не всім вдається. Та й необхідність підтримувати клієнтів, перед якими ми маємо зобов’язання, теж накладає відбиток. А якщо буде стабільна та документована платформа, на якій 1с програміст з базою по html, css, js, php чи С# зможе відносно швидко розробити конфігурацію під своїх клієнтів, з використанням вже готових механізмів платформи, перевести їх та супортити — це хоч потроху, маленькими кроками зможе зрушити процес переходу з рос.софта. Але, на мою думку для того щоб заохотити програмістів почати користуватись продуктом, необхідно все ж допиляти юзерфрендлі інтерфейс та базовий функціонал. І відповідно на певний час зробити платформу безкоштовною для розробиників. А коли вже платформа буде стабільною та набереться певна кількість розроблених конфігурацій та впроваджених проектів, можна вже подумати й про комерцію.

Спочатку використання платформи буде однозначно безкоштовним.
Але поки не готовий робити продукт опенсорсним (можливо й передумаю).
Розглядаю в майбутньому початок монетизації одним з двох способів:
1. З якоїсь конкретної версії вся платформа перестає бути безкоштовною.
2. З якоїсь конкретної версії за використання частини функціоналу потрібно буде заплатити (безкоштовний та платний функціонал).
При цьому старі версії платформи в любому випадку повністю залишаться безкоштовними (і відповідно написані на них готові рішення).

Як буде більш менш готова платформа свистіть. Якщо до того часу не запиляю якийсь свій бек то з радістю візьму участь в розробці та тестуванні)

Поточну версію платформи з базою на якій експерементую можу надати.
Правда документації поки немає — розкажу як встановлювати і як розробляти індивідуально.
Якщо такий варіант цікавий — дайте знати в телеграм-групі вказаній в статті: t.me/ Eoa_g4uTipA3OTFi

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

Платформа 1С ніяк не прив’язана до законодавства якоїсь країни.
До вимог законодавства прив’язуються готові рішення на платформі («конфігураці» в 1С).
На даний момент інші аналогічні готові рішення на інших система наче б то теж забезпечують оперативні зміни у відповідність до законодавства — але цього явно не достатньо для того щоб змінити ситуацію на користь цих інших систем.
Реалізація готових рішень для повноцінного офіційного бухгалтерського обліку на загальних засадах (форми ТОВ, ПП, облік ПДВ з реєстрацією податкових, здача різномінітної звітності в податкову та фонди) — доволі складна задача, яка, згоден, ускладнюється постійними змінами закондавства.
Колись починав я саме з обслуговування офіційної бухгалтерії. На даний момент я спеціалізуюсь на управлінському та оперативному обліку, на управлінні бізнесом, а не на регламентному обліку.
В планах розробки своїх готових рішень (не платформи, а саме готових бізнес-рішень) на найближчий рік а то й два не планував розробляти продукти для повноцінного ведення регламентованого обліку.
На першому етапі планую реалізовувати механізми обміну з існуючими системами ведення офіційного обліку інших компаній-розробників, які вже це вміють й добре роблять (наприклад bookkeeper.kiev.ua на тій же A2V10, Мастер-бухгалтерія, А5, Деловод, та навіть та ж 1С, якщо буде вимога клієнтів — всіх систем вже й не пам’ятаю).
Практично систему регламентного обліку буде вибирати кінцевий клієнт, з моєї сторони будуть тільки рекомендації (скорше всього клієнти навіть міняти не будуть системи бух.обліку, а будуть залишати існуючу на момент автоматизації).
Звичайно, вибрана система повинна мати повноцінне API для побудови обміну між системами.
В 1С теж є такі типові продукти: «Торгівля+Склад» (на 7.7), Управління торгівлею, Управління невеликою фірмою. Єдине, шо обмін в них тільки зі своїми 1С-бухгалтеріями.
Тому до розробки готових рішень з повноцінним веденням регламентного обліку планую повернутись значно пізніше.

Очень и давно одобряю Лет 15 себе сделал систему. Интересные идеи есть по построению и принципах конфигурации системы. Сам бы занялся. но есть другая тема. Обращайся. Вспомню.

А «Машіна Кузміна» вже працює?

Як завжди, подібні системи впираються у швидкодію на великих обсягах операцій. Яким чином ви робите мепінг об’єктів до вашої бази даних? Якщо напряму, наприклад, через EF Core, тоді будуть проблеми у розробників застосунків. Якщо через проміжний шар метаданих, то будуть проблеми з нормальною обробкою даних під час формування запитів. Бо прями запити при такому підході неможливі. Я добре знаю обмеження систем, подібних до 1С (і самої 1С) на практиці. Тому ще в 1998 році, перед розробкою ще першої версії нашої системи, було вирішено робити систему пряму, без проміжних платформ. І ця стратегія доволі успішна. Наші системи обробляють мільйони документів від мільйонів покупців без будь яких проблем вже багато років. З іншого боку, закривати фантазії власників невеличких бізнесів, які, зазвичай, не люблять навчатись, а люблять вигадувати велосипеди, така система непогано підійде, і дасть певну кількість робочих місць. Чому б ні. В будь якому випадку, бажаю успіху!

Поки орієнтуюсь на роботу з базами, які не дуже великі.
Ймовірно система зможе нормально працювати й з великими обсягами даних, але потрібно буде тестувати.
На даний момент можна використовувати як прямі запроси, так роботу через метадані (правда метадані зараз на примітивному рівні).
Планував підключення різних форматів баз даних з різним підходом роботи з СКБД (в тому числі використання декількох баз СКБД різних форматів в одному додатку).
Роблю більш ставку на швидкість та простоту розробки для розробників.

Кроме EF Core есть еще Dapper. Связка Dapper для чтения, EF для записи/апдейтов весьма неплоха по производительности.

Що стосується EF Core — то й на читання там зараз все дуже непогано. В останній 7 (про 8 ще не говоримо, бо вона в розробці) вони непогано прискорились і на запит великих обсягів даних з контексту бази. Правда нормально воно запрацювало десь у січні. Але EF Core я цілком задоволений в плані швидкодії.

«і на запит великих обсягів даних» — пардон, «на запис». Помилився так, що повністю перевертається сенс написаного :)

Ну в принципе да, а если еще и предкомпилировать запросы — там производительность не сильно хуже даппера. Разница буквально в 10%.

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

Ну, тесты показывают что таки надо: www.youtube.com/...​4s&ab_channel=NickChapsas

Вообще очень рекомендую канал, там много интересных вещей есть.

Зразу не зрозумів що таке «EF Core», якщо це Entity Framework Core, то відмовився від його використання. Причина чому відмовився — планую роботу з метаданими, і структура баз СУБД буде прописуватись в метаданих. При цьому це відноситься тільки до баз в «рідному» для ситеми форматі. Що до довільних баз даних — це взагалі не буде регламентуватись платформою. Платформа просто буде транзитом передавати запроси й повертати результати, а розробник буде сам організовувати запроси й обробку результатів (наприклад: база SQL в довільному форматі).
Практично те ж актуально й до технології Dapper, згаданою в коментарі Антонтоном Касьяновим (хоча раніше й не був знайомий з даною технологією) — не бачу користі використання в своєму випадку.

«Причина чому відмовився — планую роботу з метаданими, і структура баз СУБД буде прописуватись в метаданих.» — ось про це слабке місце я й казав одразу. Практично нівелюється можливість працювати з великими обсягами даних через платформу. Що робити, якщо бізнес запросить у вас звіт з продажів, скажімо, за квартал. З за день в них іде 200 тис. чеків. І це я взяв нижню цифру. Тобто за квартал 20-30 мільйонів чеків. Вам обов’язково доведеться тягнути ці дані SQL-запитом. Тобто, всі переваги платформи нівелюються. Мало того, оскільки ви працюєте через проміжний шар метаданих, то в таблицях у вас буде щось типу Field001, Field002 і т.д. Тобто це ускладнює ще й побудову sql-запиту. Є третій підхід — накопичувати дані по звіту в окремій таблиці впродовж роботи системи. Але тоді втрачаємо будь яку гнучкість, коли звіт треба переробити, або створити новий. У разі нового повинен пройти час для накопичення нових даних. Тобто універсальність проміжного шару накладає насправді купу додаткових обмежень. В цьому випадку простіше сказати, що платформа вже давно існує. Це .NET, пиши все, що потрібно. Повна свобода. :)

В мене звичайно значно менший досвід в даному питанні, але:
1. «Тобто за квартал 20-30 мільйонів чеків. Вам обов’язково доведеться тягнути ці дані SQL-запитом» — не зрозумів чому «обов’язково все це тягнути». Якщо для користувача потрібні тільки підсумки (а не розшифровка в розрізі 20-30 мільйонів чеків) — на рівні SQL буде формуватись результат тільки з підсумками. Саму фізичну таблицю платформа ні в якому разі не буде переносити до себе. Платформа тільки компонує запит за допомогою метаданих, відправляє на SQL, отримує результат й відправляє цей результат клієнту.
2. Що до полів з назвами «Field001, Field002» — планую в майбутньому конфігураторі залишити можливість розробнику вказувати назву таблиць та полів в таблицях (якщо розробник не хоче — тоді вже по замовчуванню Field001, Field002).
3. Додаткові таблиці не планував використовувати. Можливо зміню свою точку зору тоді, коли глибше познайомлюсь з проблемами роботи з великими базами даних. В любому випадку, це не повинно буде вплинути на розробку зі сторони розробника кінцевого рішення (розробник працює з метаданими, формування запросів до SQL і можливість використання для оптимізації якихось додаткових таблиць — це проблема на рівні розробки платформи).
4. Розробку бізнес-застосунків в .NET не розглядаю принципово — як на мене це дуже низький рівень програмування. Десь навіть була стаття на DOU.ua що до переведення існуючих конфігурацій 1C на C# (під типи метаданих автор розробляв свої класи) — я не вірю в перспективи таких ідей. Ще більше свободи чим в .NET є в Асемблері, але мабуть недоречно пропонувати розробникам .NET переходити на Асемблер. Технологія розробки кінцевих бізнес-застосунків повинна бути високо рівневою, це моя точка зору, на істину не претендую.

Як колишній 1С-ник підтримую всі проєкти націлені на заміну цієї системи в Україні.
На поточний момент основна проблема яку я бачу в вашому та інших проєктах — складність вивчення для потенційного розробника. В 1С дуже легко почати, бо у тебе одна мова і для сервера і для клієнта, а дизайн взагалі в конструкторі.
Тут доведедеться вивчити доволі широкий стек для старту та і писати на доволі низькому рівні (звісно, в порівнянні з 1С).

Зараз як хобі вивчаю Vaadin — технологія яка інтерпретує java код в js. Тобто я пишу UI на чистій бекендовій джаві :)
Може і для вашого стеку є подібні фреймворки?

Повністю згоден, що основна проблема для 1С-ників при спробі перейти на іншу систему — це потреба вивчити декілька різних, але пов’язаних між собою технологій, кожна з яких сама по собі складніша чим одна технологія 1С.
Тому й написав вище, що поки що пріоритетом при розробці являються питання, що дозволять зменшити поріг входу для розробника.
Вважаю що дуже був би корисний «конфігуратор» хоча б для швидкого й зручного управління структурою бази СКБД й візуальної розробки форм. Але це доволі трудоємка задача.
Для створення умов для зручного навчання потрібно ще з пів року активної роботи саме в цьому напрямі (правда поки без конфігуратора — дуже трудоємко).
Цю статтю й написав, щоб визначитись, чи варто витрачати наступні пів року саме на цей напрямок, чи краще просто самому поки набивати досвід робочих запусків.

випадково натрапив на вашу статтю. І так само випадково побачив, що Кухтін пиляє «конфігуратор» про який йому пишуть більше року в телеграм чаті github.com/...​ex-kukhtin/AppBuilder2024 . Але, як завжди це робиться тихо та непомітно для співтовариства

Я б сказав що тут все навпаки. 1с була дуже нішева, а тут будь-який .net дев може сапортити (js теж не буде проблемою). Якщо вже хочеться однієї мови на фронті і беку, то є blazor у стеку .net.

Дививсь на blazor — відкинув можливість використання.
Не побачив перспектив використання для мого продукту.

Зараз як хобі вивчаю Vaadin — технологія яка інтерпретує java код в js. Тобто я пишу UI на чистій бекендовій джаві :)
Може і для вашого стеку є подібні фреймворки?

Проглянув суть технології Vaadin (раніше не знав про неї).
Звучить цікаво, правда я не використовую поки джаву.
І з «серверною мовою» для розробників — як писав в статті, в мене поки немає серверної мови для розробників готових рішень. На заміну є можливість написання запросів на T-SQL для баз на SQL та використання мови 1С для баз на 1С.
Дякую за інформацію — попробую ознайомитись детальніше з даною технологією, можливо буде корисно для мене.

Напиши в телеграм будь ласка (є в профілі). Поділюсь ідеями, якщо цікаво

Дизайном (CSS) серйозно не займались — так що виглядає не дуже красиво

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

Згоден.
Я десь це розумію.
Але поки ще не придумав як ставити технічне завдання щодо дизайну.
Тому постійно відкладаю пошук спеціаліста по дизайну.
А ще дизайн мабуть потрібно зразу робити з урахуванням під смартфони — теж в цьому поки не розбираюсь.
Можна сказати, що боюсь поки цієї теми, тому й уникаю )

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

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

Я б шукав ще інших спеціалістів з 1С в якості консультантів.

бажаю успіхів — будь-який ворог 1С — мій друг))

Задумка клонувати систему дуже цікава. В чому справа, тепер залишається вмовити ген директора та головного бухгалтера, тобто персон які приймають рішення — впровадити цю заміну у себе в компанії. Навчити бухгалтерів, адмінів та інших нею користуватись, можливо винайняти аутсорсингових спеціалістів які цю систему впровадять налаштують і т.д. тобто понести відносно суттєві витрати. Свого часу в 90-ті та початку нульових, 1С возили власним коштом якраз ППР на конференції по своїм продуктам на курорти в : Єгипет, Турцію та Черногорію. А хто відмовиться поїхати на конференцію, яка додатково стає відпускою — при чому за неї не треба платити з власного гонорару ? Таким маркетингом Борис Нуралиев перетворив по суті гаражний стартап на корпорацію з оборотом в мільярд долларів річних. Цей кейс розбирали мало не по усіх бізнес-тренінгах колишнього СРСР.

P.S. Цікаво подивитись на ринок Польщі та інших країн східної Європи, як там справи з такими продуктами і як вийти на цей ринок із чимось системним по типу 1С. Нажаль зараз заміна 1С, це приблизно те саме, що і ідея замінити усі камази та мази в країні — бо вони виготовляються у ворожих країнах. За короткі строки (меньше десяти років) це не реально зробити, навіть якщо вкласти багато мільярдів та днів роботи в розробку, підготовку персоналу, обслуги та маркетинг.

В Польщі є свій монополіст — Комарх

Ідея все таки не в «клонуванні» — не ставив собі ціль зробити копію чогось, а спроба враховувати сильні сторони існуючих продуктів при розробці нового продукту.
Що стосується процесу заміни однієї ІТ-системи управління підприємством на іншу — згоден, це дуже важко. Я не вірю, що існуючі підприємства будуть активно міняти свою існуючу систему на якусь іншу, хіба що вона їх дуже не влаштовує.
Тому на даному етапі й не розглядаю розробку на своїй платформі повноцінних систем на заміну будь яких існуючих — це тема «для політиків», я не вірю в результативність таким шляхом. Українських готових «аналогів 1С» чимало, але щось тотальної зміни ситуації не бачу.
З моїх клієнтів після початку війни тільки пару просто цікавилися чи є достойні аналоги 1С, про рельну заміну ні в кого питання не виникло (клієнтів в мене правда не багато).
Заміна будь-яких нормально працюючих систем на нові, навіть краші — дуже довгий процес на десятки років.
Повторювати «подвиг» 1С шляхом «поїздок на курорти» в мене немає ні бажання, ні можливості.
Я віддаю перевагу більш ринковим методам конкуренції й методи зацікавлення кінцевих клієнтів планую трохі інші. Зараз все-такти багато чого можно досягнути за допомогою інтернету, на відміну від «30 років назад».

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

Не думаю, що державу зацікавлять такі продукти зовсім на початковому стані.
Якщо державу й зацікавить участь в цьому питанні, то краще вже вибрати існуючі продукти (IT-Interprise, A5 взагалі спеціалізується на бюджетній сфері)

На A2v10 теж дивився, але бізнес логіку тримати в БД як по мені не варіант. Одоо досить непогано, навіть з пайтоном почав експериментувати, але архітектура не дуже сподобалась, та й самі розробники системи не дуже турбуються про зворотню сумісність. Не розглядали як варіант для серверу використовувати node.js ?

Ноду не вивчав.
Якщо буде логічна потреба змінити C# на ноду — перепишу.
Поки такої необхідності не бачу.
Це ніяк не вплине на розробку бізнес-додатку.

Ви пишете, що систему А2v10 розглядали як один з еталонів. Питаю без докору, просто цікаво дізнатись аргументацію. Чому ви вирішили робити свою платформу, а не контриб’ютити в А2v10? Наскілки я зрозумів то open source, і концептуально схожа на те що ви робите.

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

Вот-вот. Это вечная проблема продуктов Кухтина — они очень хороши в техническом плане, но ужасны в плане поддержки. Печально что за 20 лет, со времен Акцент 6.0, ничего толком не поменялось.

Рік назад пробував переконати Кухтіна, що потрібно змінити відношення що до просування його платформи A2V10 й займатись цим серйозніше, але не зміг.

Традиция. Пролюбили потенциал А4, пролюбили потенциал A6, пролюбили потенциал A7, сделали конструктор A10. Техническую часть пилить конечно забавно, но внезапно бизнес-пользователи хотят работать а не конструировать формочки.
А стандартная настройка в А6-А7 была тем еще уродством. Настолько уродством, что бухгалтера говорили что оно конечно красиво, но лучше мы по старинке на 1С. Потому что там все работает, хоть и корявенько.
Идея сделать простой товарно-кассовый учет для мелких магазинов (буквально десяток форм) и окучивать мелкие магазины Донецка, Макеевки и Авдеевки — не, для нас это тоже слишком мелко было. Ну как бы и черт с ним. Жаль конечно, что неплохая платформа так и осталась экспонатом в цирке уродцев.

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

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

const Країни = DataVue.tables...

Це саме той випадок, коли закинув комусь фотку і не заблюрив шось цікаве ;)

Впровадження Універсал EPR
ПЕРЕВАГИ ВПРОВАДЖЕННЯ
УНІВЕРСАЛ 7:ERP

ви якось визначіться — у вас EPR чи ERP?

Ми типу повинні були одразу повірити людині з одним коментом на форумі, яка дала посилання на сайт невідомої сумнівної контори.

Підписатись на коментарі