Конфігурація 1С

Конфігурація 1С як технічний борг

як приклад, можна описати ШІ старий документ 1С і попросити сформувати модель для K2 ERP:

Документ зазвичай має:

entity: sales_invoice

title: "Активний"

Перед переходом потрібно провести аналіз конфігурації. |- | Чим конфігурація відрізняється від платформи? Довідники в 1С зберігають об’єкти, які часто використовуються в документах і звітах. * типову основу;

десятки доданих реквізитів;
нові документи;
змінені форми;
додаткові регістри;
нестандартні звіти;
зовнішні обробки;
обміни;
інтеграції;
тимчасові рішення для бізнесу, які стали постійними. | Ні. |-

| Чи потрібно копіювати конфігурацію 1С у K2 ERP? Дошліфування | Додається складна логіка, інтеграції, спеціальні звіти |- | 9. Відповідь

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

fields:

type: string
date:

 product_id:
 title: "Ціна"
 active: bool = True

складський облік 1 ─── * Реалізація товарів
 type: string
<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">

{| class="wikitable" style="width:100%;"
Можливо, у [[K2 ERP]] замість старого звіту краще створити сучасний дашборд. Переносити? Окремо варто відзначити яка визначає, які довідники, документи, регістри, звіти, обробки, форми, ролі, права доступу і програмна логіка доступні користувачам. Тип зміни
Тому конфігурацію потрібно не викидати сліпо, а аналізувати. | Це прикладний набір об’єктів, форм, звітів, регістрів, ролей і програмної логіки на платформі 1С:компанія-користувач. Платформа сама по собі виступає як середовищем виконання. У [[K2 ERP]] логіка здатна переноситися в сучасні [[ORM|ORM-моделі]], які працюють із [[PostgreSQL]]. title: "складський облік"

 title: "E-mail"
 title: "Контрагент"

title: "Реалізація товарів"

type: text

Вони використовуються для зберігання рухів, залишків, оборотів, періодичних значень і бухгалтерських записів. Етап

Конфігурація 1С — це важливе поняття старої облікової екосистеми. * які рішення для бізнесу приймаються на основі цього звіту?

type: directory

email:

Для міграції потрібно створити карту відповідності. form:

Проблема в тому, що доробки часто ускладнюють оновлення версій. type: decimal

type: text

{ Саме через конфігурації створювалися бухгалтерські системи, торгові рішення для бізнесу, складські модулі, зарплатні блоки, виробничі схеми, галузеві рішення для бізнесу та тисячі індивідуальних доробок. Коментар

які поля потрібні;
які табличні частини потрібні;
які рухи створюються;
які звіти залежать від документа;
які права потрібні;
які друковані форми потрібні;
які інтеграції пов’язані з документом. Проведення означає, що документ не без зусиль записаний, а вплинув на обліковий облік. критично про санкції. 1С і BAS пов’язані з російською технологічною екосистемою та перебувають у санкційному полі України. {| class="wikitable" style="width:100%;"

type: decimal

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

| Перевіряються залишки, документи, звіти |- | 8. Під час міграції не варто сліпо переносити старі ролі. як приклад, документ “Рахунок покупцю” зазвичай посилається на довідник контрагентів, номенклатури, договорів і організацій. * аналіз метаданих;

вивантаження довідників;
вивантаження документів;
вивантаження залишків;
аналіз регістрів;
аналіз звітів;
аналіз обробок;
аналіз ролей;
аналіз інтеграцій;
підготовка структури в K2 ERP;
імпорт даних;
звірка результатів. * надходження товарів;
реалізація товарів;
замовлення покупця;
замовлення постачальнику;
рахунок;
платіж;
переміщення товарів;
списання;
інвентаризація;
нарахування зарплати;
виробниче замовлення.== Приклад перенесення довідника ==

code: str | None = None
title: "Сума"

Типова логіка:

Див. так само

phone?: string;

title: "Сума"

type: boolean

!</syntaxhighlight>

phone:

У K2 ERP краще будувати інтеграції через API. title: "складський облік"

required: true

На українському ринку після санкцій і репутаційних ризиків навколо російської екосистеми 1С значна частина старих рішень почала просуватися під брендом BAS. Не варто переносити на 100%, якщо:

entity: product
warehouse_id:

! Їх не потрібно ідеалізувати. Конфігурація 1С складається з об’єктів метаданих. У конфігурації 1С виступає як додаткове поле в документі:

entity: contract

Основні види:
}
[[Категорія:ERP]]

здатна, колір став сучасніший. active:
|-
| Довідники
| Зберігають відносно постійну інформацію
| Контрагенти, номенклатура, склади
|-
| Документи
| Фіксують бізнес-події
| Замовлення, рахунок, накладна, платіж
|-
| Регістри відомостей
| Зберігають довідкові або періодичні інформаційні дані
| Ціни, курси валют, конфігурація
|-
| Регістри накопичення
| Накопичують рухи ресурсів
| Залишки товарів, взаєморозрахунки
|-
| Регістри бухгалтерії
| Зберігають бухгалтерські проводки
| Рухи по рахунках
|-
| Плани рахунків
| Описують структуру бухгалтерських рахунків
| Бухгалтерський план рахунків
|-
| Плани видів характеристик
| Описують додаткові властивості
| Характеристики товарів
|-
| Звіти
| Виводять аналітичну інформацію
| продажі та реалізація, залишки, обороти
|-
| Обробки
| Виконують службові або масові дії
| Імпорт, експорт, перерахунок
|-
| Ролі
| Визначають права доступу
| Бухгалтер, менеджер, адміністратор
|-
| Форми
| Визначають інтерфейс користувача
| Форма документа, форма списку
|}

 active: boolean;

 - row:

У [[K2 ERP]] цю структуру краще описувати через [[ER-модель]]. title: "Коментар"
! * номер;
* дату;
* організацію;
* контрагента;
* складський облік;
* суму;
* статус;
* табличну частину;
* друковані форми;
* рухи по регістрах;
* програмну логіку проведення. Імпорт даних
| Переносяться довідники, залишки, активні документи
|-
| 7. contract_id:
Найважливіші типи об’єктів:
 type: decimal

fields:
Він здатна мати:
 type: reference

! type: string
З іншого боку, вони прив’язали бізнес-середовище до специфічної закритої екосистеми, російського походження, старої архітектури та великого технічного боргу. Об’єкт
Для багатьох компаній слово “конфігурація” означає всю їхню облікову реальність.

required: true

1С та BAS потрібно розглядати не тільки як технічні системи, а і як продукти з російською історією та санкційним контекстом. calculated: true

</syntaxhighlight>

title: "Контрагенти"

Висновок

title: "Номер"
quantity:

Створи YML-модель для документа "Замовлення покупця".== Коротко ==

name: string;

Санкційний контекст 1С/BAS

YML у K2 ERP здатна стати текстовим представленням того, що в 1С було приховано всередині конфігуратора. як приклад, бухгалтерський обліковий облік, торгівля, зарплата, виробництво, керування бізнесом або галузеве рішення для бізнесу можуть бути окремими конфігураціями. Якщо без зусиль скопіювати конфігурацію 1С, можна перенести:

модулі об’єктів;
модулі форм;
загальні модулі;
модулі менеджерів;
модулі команд;
модулі сеансу;
модулі керованого додатка. З одного боку, конфігурації 1С дали ринку можливість відносно оперативно створювати прикладну бізнес-логіку. type: string

Регістри в конфігурації 1С

Така конфігурація здатна містити:

SEO title: Конфігурація 1С — структура, об’єкти, бізнес-логіка, обмеження та перехід на K2 ERP

SEO keywords: конфігурація 1С, 1С конфігуратор, 1С Підприємство, BAS, K2 ERP, міграція з 1С, заміна 1С, альтернатива 1С, альтернатива BAS, санкції 1С, санкції BAS, ERP Україна, довідники, документи, регістри, звіти, обробки, YML, ER-модель, ORM, Python, TypeScript, PostgreSQL, AI ERP

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки.

}}

- table_part: items

У таких випадках краще переносити інформаційні дані й бізнес-сенс, але створювати нову модель у K2 ERP. |- | Які основні об’єкти конфігурації? title: "Код"

title: "Товари"

Форми в конфігурації 1С

full_name:

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

Конфігурація 1С і ORM

Це дає гнучкість, але з часом здатна створювати складність.

 "email": "office@romashka.ua"

 title: "Кількість"

* як бізнес-середовище працював;
* які документи були потрібні;
* які звіти використовувалися;
* які доробки замовляли;
* які процеси автоматизували;
* які інтеграції були критичні;
* які інформаційні дані накопичилися. Об’єкт

Сьогодні, коли український бізнес-середовище переходить на [[K2 ERP]], критично правильно зрозуміти роль конфігурацій 1С. Їх потрібно розібрати, зрозуміти, очистити від зайвого й перенести бізнес-сенс у нову платформу. default: true

[[Категорія:Альтернатива 1С]]

У документі виступає як номер, дата, контрагент, договір, складський облік, коментар. entity: contractor

entity: contractor
як приклад:
Повне перенесення конфігурації не завжди має сенс. Перед перенесенням потрібно відповісти:
 id: int

 title: "Товари"
== Конфігурація 1С проти модулів K2 ERP ==
У 1С виступає як довідник “Контрагенти”. |-
| Чому критично згадувати санкції? Бо якщо занести старий хаос у нову систему, він не стане архітектурою. Якщо ні — краще залишити в минулому. | Платформа дає середовище виконання, а конфігурація визначає конкретну бізнес-логіку. * номер;
* дату;
* організацію;
* контрагента;
* договір;
* складський облік;
* табличну частину товарів;
* суми;
* ПДВ;
* друковану форму;
* рухи по залишках;
* рухи по взаєморозрахунках;
* бухгалтерські проводки. entity: customer_order
 - field: date
Дороблена конфігурація — це типова конфігурація, змінена під конкретний бізнес-середовище. entity: contractor

! Конфігурація 1С/BAS
 title: "ЄДРПОУ"
 edrpou?: string;

Це ще й частина застарілої російської технологічної залежності, яка має санкційні, безпекові, репутаційні та стратегічні ризики. type: reference

[[Категорія:BAS]]

Це як перефарбувати динозавра і сказати, що тепер це електромобіль. | [[AI|ШІ]] здатна допомагати аналізувати стару конфігурацію, генерувати [[YML]], створювати документацію й пропонувати структуру модулів.[[Категорія:Санкції]]
Приклад:
<div style="border:3px solid #ef6c00; background:#fff3e0; padding:14px; margin:16px 0;">
 comment:
Перевага [[YML]]:
Приклад [[TypeScript]]-інтерфейсу:
Такий підхід дає можливість бачити не без зусиль об’єкти, а зв’язки між ними. Потрібно переносити бізнес-сенс, актуальні інформаційні дані й потрібну логіку, а не старий технічний борг. Під час переходу на [[K2 ERP]] критично не переносити всі звіти механічно. organization_id:
Перехід на [[K2 ERP]] не повинен бути механічним копіюванням конфігурації. |-
| Яка роль AI? ! type: datetime
!

type: decimal
title: "Дата"

table_parts:

email: str | None = None

У 1С структура конфігурації часто виглядає як набір об’єктів метаданих. class Contractor(BaseModel):

Модулі конфігурації 1С

Документ записано → Документ проведено → Створено рухи по регістрах → Змінилися залишки й обороти

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

phone: str | None = None

active:
amount:

як приклад, документ “Реалізація товарів” здатна робити рухи:

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

Конфігурація 1С і API

Обробки в 1С часто виконують службові або масові дії. type: datetime

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

type: reference
price:
"name": "ТОВ Ромашка",
entity: warehouse

type: document

code:
type: string
title: "Дата"

Що не варто переносити

id: number;
title: "ІПН"

Серед них:

contractor_id: Типові ролі: type: string - field: contractor_id Зовнішні посилання У K2 ERP це здатна бути описано як модель: Приклад умовної Python-моделі: Потрібно переносити не форму старої конфігурації, а бізнес-сенс. Для бізнесу це означає, що використання 1С/BAS не можна розглядати як нейтральне технічне рішення для бізнесу. number: fields: На ринку використовувалися різні конфігурації 1С та BAS. entity: contractor </syntaxhighlight> Практична думка. Конфігурація 1С часто виглядає як “швидка розробка програмного забезпечення бізнес-логіки”, але з роками вона швидко перетворюється на музей доробок, де кожен експонат має табличку “не чіпати, бо здатна впасти”. \|-	Довідник Контрагенти	Клієнти, постачальники, партнери	Довідник contractor	Перенести з очищенням дублів
Довідник Номенклатура	Товари й послуги	Довідник product	Перенести з групами і характеристиками
Документ Замовлення покупця	Фіксація замовлення клієнта	Документ customer_order	Перенести активні документи
Регістр Залишки товарів	обліковий облік залишків	Початкові залишки / складський компонент	Перенести залишки на дату переходу
Звіт продажі та реалізація	аналітичні інструменти продажів	Звіт або дашборд K2 ERP	Переосмислити структуру
Обробка Обмін із сайтом	інтеграційні функції ERP	API-модуль	Переписати через сучасний API

items:

auto: true

required: true

Код;
Найменування;
Повне найменування;
ЄДРПОУ;
ІПН;
Телефон;
Email;
Юридична адреса;
Фактична адреса;
базовий договір;
Банківські рахунки. entity: organization

title: "Замовлення покупця"

Типові конфігурації 1С/BAS

amount:

! Потрібно визначити бізнес-сенс рухів і реалізувати його через сучасні моделі, таблиці, події, сервіси, регістрові структури або аналітичні механізми платформи.== конкурентні переваги підходу K2 ERP ==

Вона показує:

Проведення документів

Документ “Реалізація товарів” зменшує залишки і створює взаєморозрахунки. name: У реальному бізнесі часто зустрічається не “чиста типова конфігурація”, а платформа, яка багато років дороблялася різними програмістами. Указ Президента України №601/2024 ввів у дію рішення для бізнесу РНБО від 2 вересня 2024 року щодо сценарії використання, скасування та внесення змін до санкцій. * чи можна зробити краще через дашборд? Приклад: Під час переходу на K2 ERP здатна виникнути спокуса: “Зробіть нам так само, як у 1С”. |- | Актуальні довідники | Так | Але з очищенням дублів |- | Залишки | Так | На дату переходу |- | Відкриті документи | Так | Замовлення, рахунки, незавершені операції |- | Повна історія продукту документів | Не завжди | Часто краще залишити в архіві |- | Старі звіти | Вибірково | Тільки ті, які реально використовуються |- | Старі обробки | Вибірково | Переосмислити через API або модулі |- | Права доступу | Не механічно | Краще створити нову модель ролей |- | Доробки | Вибірково | Аналізувати бізнес-сенс |}

type: string

Типові звіти:

дублікати;
застарілі довідники;
тимчасові доробки;
старі обробки без власника;
звіти, які ніхто не використовує;
поля “на всяк випадок”;
неактивні склади;
старі ролі з хаотичними правами;
помилкові залишки;
технічний борг;
хаос старої системи. * імпорт даних;
експорт даних;
масова зміна реквізитів;
перерахунок цін;
завантаження банківської виписки;
обмін із сайтом;
формування спеціальних файлів;
виправлення даних. * які поля потрібні?== Конфігурація 1С і AI ==

Конфігурація як джерело знань

title: "Організація"
title: "Телефон"

Потрібно з’ясувати:

Коли конфігурацію краще не переносити на 100%

title: "Код"
edrpou:

fields:

email:

auto: true

його можна читати;
його можна зберігати в Git;
його можна перевіряти;
його можна генерувати за допомогою ШІ;
з нього можна створювати ORM-моделі;

з нього можна створювати форми, меню, журнали й базовий функції ERP. Санкції щодо суб’єктів, пов’язаних із 1С, запроваджувалися рішеннями РНБО, введеними в дію указами Президента України, зокрема №133/2017 та №601/2024.

 title: "Товари"

{| class="wikitable" style="width:100%;"

 email?: string;

Файл лежить у папці, називається “Обработка_Новая_Финал_2.epf”, і всі знають, що його не можна видаляти, бо “на ньому тримається обмін”.== Конфігурація 1С і технічна міграція ==

'''Висновок.''' Конфігурація 1С — це не без зусиль набір довідників і документів. type: string
 quantity:
== Вступ ==
Простіше кажучи, платформа — це двигун і шасі, а конфігурація — це кузов, салон, панель керування, кнопки, проводка й інструкція, як саме цим користуватися. SEO-опис у YML
| Формується [[YML]]-структура
|-
| 5. Але за своєю природою [[BAS]] продовжує ту саму технологічну та ідеологічну лінію: конфігуратор, метадані, об’єкти, регістри, форми, модулі, специфічна мова та велика залежність від старої екосистеми. title: "ПДВ"

* старі помилки;
* дублікати;
* застарілі документи;
* непотрібні поля;
* погану структуру довідників;
* хаотичні права;
* старі звіти;
* технічний борг;
* логіку, яка вже не відповідає бізнесу. '''Саме тому при переході з 1С/BAS на K2 ERP потрібно переносити не минуле в нову оболонку, а корисну бізнес-логіку в сучасну українську ERP-платформу.'''

* директор досі ним користується? Призначення

Технічна міграція конфігурації містить кілька напрямів:

Таблична частина містить товар, кількість, ціну, суму і ПДВ. У багатьох компаніях зовнішні обробки перетворювалися на окрему тіньову інфраструктуру.<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
Але для бізнесу критично дивитися не на назву, а на технологічну суть. Старі конфігурації 1С часто інтегрувалися через файли, обробки, COM, зовнішні компоненти або спеціальні обміни.<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
[[Категорія:ERP для інтеграторів]]

|- | Що таке конфігурація 1С? |- | Додано реквізити в документи | Потрібно переносити в нову модель |- | Змінено форми | Потрібно аналізувати, які поля справді потрібні |- | Додано регістри | Потрібно зрозуміти їх бізнес-сенс |- | Змінено проведення | Потрібно відтворити або переосмислити облікову логіку |- | Додано звіти | Потрібно визначити, які звіти актуальні |- | Додано обміни | Потрібно перенести інтеграції через API або окремі модулі |}

Як виглядає перенесення конфігурації в K2 ERP

! У старих конфігураціях форми часто дороблялися роками. ! Особливо якщо: K2 ERP дає можливість будувати цю нову архітектуру через ER-моделі, YML, ORM, PostgreSQL, Python, TypeScript, API, K2 Update, модулі та штучний інтелект. У K2 ERP такі довідники можуть бути описані через ER-модель і YML. Очищення | Прибираються дублікати, застарілі об’єкти, непотрібні поля |- | 3.== Чому не треба копіювати конфігурацію 1С у K2 ERP ==

type: string

регістри відомостей;
регістри накопичення;
регістри бухгалтерії;
регістри розрахунку.

зменшити залишок товару на складі;
збільшити заборгованість покупця;
сформувати дохід;
сформувати собівартість;
створити бухгалтерські проводки. Об’єкт 1С

Приклад YML для документа реалізації

Штучний інтелект здатна допомогти під час аналізу конфігурації 1С. |}

Якщо платформа успадковує стару архітектуру, стару логіку, стару екосистему, стару залежність від конфігуратора і старий підхід до доробок, то зміна вивіски не вирішує проблему. K2 ERP — це можливість побудувати нову систему без старих залежностей, старого хаосу і старого динозавра в серверній.

! * чи виступає як дубль цього звіту? type: reference

У 1С розробник функціонує зі специфічною моделлю об’єктів платформи.</syntaxhighlight>

title: "Товар"

як приклад, документ “Надходження товарів” після проведення збільшує залишки на складі. title: "Товар"

У K2 ERP таку логіку не потрібно копіювати механічно. * які об’єкти виступає як в системі;

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

items:

У практичному сенсі конфігурація 1С — це не сама платформа, а бізнес-додаток, побудований на платформі 1С:Підприємство. Типова проблема: на формі документа з’являється багато полів, частина з яких уже не застосовується для. |-

| Що робити зі старими звітами?

== Як аналізувати конфігурацію 1С перед міграцією ==

* адміністратор;
* бухгалтер;
* провідний бухгалтер;
* менеджер продажів;
* комірник;
* кадровик;
* керівник;
* касир;
* користувач системи звітів. | Переглянути, які потрібні, а застарілі залишити в архіві або замінити сучасними звітами й дашбордами. * українська платформа;
* сучасна веб-архітектура;
* [[PostgreSQL]];
* [[Python]];
* [[TypeScript]];
* [[YML]];
* [[ORM]];
* [[API]];
* модульність;
* [[K2 Update]];
* [[AI|ШІ]];
* автоматична генерація компонентів;
* можливість розвитку партнерської екосистеми;
* відхід від російської технологічної залежності. Документ у 1С фіксує бізнес-подію. Але [[K2 ERP]] має бути картою майбутнього. * контрагенти;
* номенклатура;
* склади;
* договори;
* організації;
* підрозділи;
* співробітники;
* валюти;
* одиниці виміру;
* статті витрат;
* каси;
* банківські рахунки. Їх не потрібно демонізувати. Приклад
 edrpou: str | None = None
[[Категорія:ORM]]

 type: string
 "phone": "+380501112233",
бізнес-процес можна подати так:

 code?: string;
 title: "Ціна"
== Основні об’єкти конфігурації 1С ==

 title: "Активний"
 type: reference
Приклад:

Якщо поле потрібне, його можна перенести в [[K2 ERP]]. type: boolean
! Запуск
| Користувачі переходять у [[K2 ERP]]
|}

 title: "Фактична адреса"

<syntaxhighlight lang="text">

* копіювати 1С один в один;
* переносити всі старі доробки без аналізу;
* ігнорувати санкційний контекст;
* не очищувати довідники;
* не робити тестову міграцію;
* не звіряти залишки;
* не документувати відповідність об’єктів;
* не навчати користувачів;
* переносити старі звіти без перевірки;
* залишати 1С/BAS як паралельну робочу систему;
* не враховувати інтеграції;
* не планувати рефакторинг. type: string
</div>
як приклад:

|- | Походження | Російська технологічна ERP-платформа | Українська ERP-платформа |- | Санкційний контекст | Наявні санкційні ризики | Орієнтація на українське правове й бізнес-середовище |- | технічна архітектура | Конфігуратор і специфічна платформа | модульна ERP веб-архітектура |- | SEO-опис структур | Метадані конфігуратора | ER-модель, YML, ORM |- | Мови й технології | Специфічна мова 1С | Python, TypeScript, PostgreSQL, API |- | Інтеграції | Часто через обробки та файлові обміни | API-first підхід |- | дорожня карта розвитку | Залежність від конфігурації та доробок | Незалежні модулі й K2 Update |- | AI | Не виступає як природною основою старої архітектури | здатна працювати з моделями, YML і кодом |}

title: "Телефон"

warehouse_id:

Ролі та права доступу

! entity: customer_order

Це значно зрозуміліше для сучасних систем: сайтів, CRM, мобільних додатків, BI, банків, служб доставки та AI-сервісів. Генерація | Створюються ORM, міграції, код, меню, форми, журнали |- | 6. | Тому що 1С/BAS пов’язані з російською екосистемою та перебувають у санкційному полі України. title: "Договір"

У конфігурації 1С права доступу визначають, що користувач системи здатна бачити й робити. actual_address:

елемента довідника;
списку довідника;
документа;
списку документів;
звіту;
обробки;
вибору;
налаштувань.== Типові помилки при перенесенні конфігурації ==

Це зрозуміло, але небезпечно. type: reference
У 1С виступає як звіт:
Продажі_Для_Директора_Новий_2020
 legal_address:
! Об’єкт у K2 ERP
export interface Contractor {
fields:

<syntaxhighlight lang="text">
<syntaxhighlight lang="yaml">
 required: true

'''Правило.''' Переносити потрібно бізнес-цінність, а не цифровий мотлох. ! title: "Контрагент"

{| class="wikitable" style="width:100%;"
У [[K2 ERP]] логіку потрібно переносити в більш сучасну структуру: модулі, сервіси, API, компоненти, події, [[ORM]]-моделі та окремі програмні частини. Під час переходу на [[K2 ERP]] такі обробки потрібно аналізувати окремо. Критерій
Товар 1 ─── * Рядок документа
У 1С важливим поняттям виступає як проведення документа. Для чого застосовується для

== Звіти в конфігурації 1С ==

== Приклад перенесення документа ==

Конфігурація 1С здатна бути корисною, але з роками вона часто накопичує технічний борг. Регістри — одна з ключових особливостей 1С.== Обробки в конфігурації 1С ==

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

Контрагент 1 ─── * Договір
У [[K2 ERP]] потрібно не без зусиль скопіювати документ, а визначити:
{| class="wikitable" style="width:100%;"

'''Конфігурація 1С''' — це прикладний набір метаданих і програмної логіки, який функціонує на платформі [[1С:Підприємство]]. Саме конфігурація визначала, як бізнес-середовище працював у 1С або BAS: які довідники вів, які документи створював, які регістри накопичували інформаційні дані, які звіти формувалися і які доробки підтримували щоденну роботу. як приклад:

{| class="wikitable" style="width:100%;"

! title: "Повна назва"

[[Категорія:AI]]

 title: "Назва"

Указ Президента України №133/2017 ввів у дію рішення для бізнесу РНБО від 28 квітня 2017 року щодо сценарії використання персональних спеціальних економічних та інших обмежувальних заходів.<syntaxhighlight lang="yaml">

Конфігурація 1С багато років була центральним поняттям для автоматизації бізнесу на пострадянському ринку. У [[K2 ERP]] форми можуть генеруватися з моделей і описуватися через [[YML]]. * платформа сильно застаріла;
* багато доробок не застосовується для;
* довідники забруднені;
* звіти дублюються;
* бізнес-процеси змінилися;
* стара логіка суперечить новій структурі;
* дешевше створити новий компонент;
* потрібна інша технічна архітектура.== Що переносити з конфігурації 1С ==
Це дає розробникам сучасні інструменти замість вузької закритої екосистеми.== Карта відповідності 1С → K2 ERP ==

 price:
 name:
Але сьогодні для українського бізнесу конфігурація 1С — це не тільки технічний актив. Роль у K2 ERP
</div>
|-
| 1. Але динозавр усе одно просить папороть і боїться астероїда.<syntaxhighlight lang="json">

Правильний підхід інший. Наслідок

== Документи в конфігурації 1С ==

* багато доробок без документації;
* незрозумілі обробки;
* поля, які ніхто не використовує;
* дубльовані звіти;
* складні форми;
* повільні запити;
* конфлікти при оновленнях;
* залежність від одного програміста;
* страх щось змінювати;
* неможливість оперативно пояснити логіку системи. * хто його заповнює;
* де воно застосовується для;
* чи потрапляє в друковані форми;
* чи впливає на звіти;
* чи потрібно воно зараз;
* чи не дублює інше поле;
* чи не можна замінити його нормальним процесом. Модулі K2 ERP
 title: "E-mail"
 type: text
Попри всі обмеження, стара конфігурація 1С виступає як цінним джерелом знань. як приклад, створення контрагента через [[JSON]]:
fields:
 type: decimal
 code:
 - field: warehouse_id
type: directory

Типові ознаки технічного боргу:

Типові довідники:

vat_amount:

пояснювати стару структуру;
знаходити дублювання;
допомагати створювати карту відповідності;
генерувати YML-моделі;
описувати ER-моделі;
допомагати переписувати бізнес-логіку;
створювати документацію;
пропонувати тестові сценарії;
аналізувати старі звіти;
допомагати у рефакторингу. На практиці більшість компаній мають саме дороблені конфігурації. Вона дає механізми збереження даних, інтерфейс, мову програмування, конфігуратор, механізм форм, звітів, прав, обмінів та інших службових частин. title: "Контрагенти"

- row:

entity: product

Документ 1 ─── * Рядок документа

Що таке конфігурація 1С

</syntaxhighlight>

title: "ЄДРПОУ"

type: reference

"code": "000001",

! date:

Приклад аналізу старого звіту

default: true

Типова конфігурація — це конфігурація, яку постачає виробник або вендор. * які фільтри потрібні? Форми визначають, як користувач системи бачить і редагує інформаційні дані. Аналіз конфігурації | Визначаються довідники, документи, регістри, звіти, обробки й доробки |- | 2. edrpou:

Правильний підхід — це аналіз, очищення, переосмислення і перенесення бізнес-сенсу в нову архітектуру. required: true

 contractor_id:

[[Категорія:Автоматизація бізнесу]]
== Довідники в конфігурації 1С ==
[[BAS]] часто подавався як “нова українська назва” або “заміна 1С”. | Через аналіз об’єктів, [[ER-модель]], [[YML]], [[ORM]], міграції, модулі, API та сучасну бізнес-логіку. У 1С програмний код часто розміщується в різних модулях:
</div>

 number:
 type: string
 title: "Юридична адреса"
[[Категорія:Перехід з 1С]]

{| class="wikitable" style="width:100%;"
Приклад:
'''У контексті переходу на K2 ERP.''' Конфігурацію 1С не потрібно сліпо копіювати. Він стане хаосом із новим логотипом. виступає як форми:
 layout:
 title: "Назва"
== Конфігурація 1С і ER-модель ==
== Конфігурація 1С і YML ==
 type: decimal
У [[K2 ERP]] документ можна описати як сутність типу `document`. У 1С виступає як документ “Реалізація товарів”. Потрібно враховувати:

! Що відбувається

* хто користується звітом;
* як часто;
* для якого рішення для бізнесу;
* які поля потрібні;
* які фільтри використовуються;
* чи можна замінити старий звіт сучасним дашбордом;
* чи не дублює він інший звіт. Моделювання
| Створюється [[ER-модель]] майбутнього компонента
|-
| 4.</div>
 type: reference
Вона виступає як картою минулого.[[K2 ERP]] дає можливість замінити логіку старої конфігурації 1С сучасним підходом. '''Конфігурація 1С''' — це прикладна структура в системі [[1С:Підприємство]]. Звіти в 1С використовуються для отримання аналітики. Питання

 required: true

У ньому можуть бути реквізити:

 entity: warehouse

[[Категорія:Деколонізація обліку]]

Переносити потрібно не все, а тільки те, що має цінність. Потрібно зрозуміти її бізнес-сенс: які довідники, документи, регістри, звіти й процеси реально потрібні, а потім перенести цю логіку в сучасну архітектуру [[K2 ERP]] через [[ER-модель|ER-моделі]], [[YML]], [[ORM]], [[API]], [[PostgreSQL]], [[Python]], [[TypeScript]] та модулі. '''Конфігурація 1С — це карта старої системи.== Чому BAS не вирішує проблему ==

* залишки товарів;
* продажі та реалізація;
* взаєморозрахунки;
* оборотно-сальдова відомість;
* рух товарів;
* валовий прибуток;
* зарплатні звіти;
* управлінські звіти. phone:

 title: "Номер"
 tax_number:
 product_id:
|-
| Бухгалтер
| Первинні документи, контрагенти, звіти, взаєморозрахунки
|-
| Менеджер продажів
| Клієнти, замовлення, рахунки, залишки
|-
| Комірник
| Складські документи, інвентаризація, залишки
|-
| Керівник
| Дашборди, звіти, погодження
|-
| Адміністратор
| Користувачі, ролі, конфігурація
|}

Краще створити нову модель доступу. |-
| Як переносити логіку в K2 ERP? У сучасних українських умовах це ще й частина застарілої російської технологічної залежності, з якої бізнесу потрібно планово виходити. type: decimal
table_parts:
конкурентні переваги:

 - field: number
Він здатна:
 type: string
}

== Приклад аналізу старої доробки ==
![[Категорія:Конфігурація 1С]]
[[Категорія:Міграція з 1С]]
== Типова конфігурація і дороблена конфігурація ==

 "edrpou": "12345678",
[[Категорія:K2]]
title: "Замовлення покупця"
 type: string

Не варто переносити: type: document Перед перенесенням потрібно з’ясувати: ! Реквізит: КоментарДляСкладу

Якщо платформа дійшла до стану “функціонує, але не чіпайте”, це вже не автоматизація процесів, а цифрова міна з відкладеним вибухом. title: "Кількість"

name: str

Контрагент 1 ─── * Замовлення покупця

Конфігурація 1С як технічний борг

Див. так само

Висновок

Санкційний контекст 1С/BAS

Регістри в конфігурації 1С

Форми в конфігурації 1С

Конфігурація 1С і ORM

Модулі конфігурації 1С

Конфігурація 1С і API

Що не варто переносити

Зовнішні посилання

Типові конфігурації 1С/BAS

Проведення документів

Конфігурація як джерело знань

Коли конфігурацію краще не переносити на 100%

Як виглядає перенесення конфігурації в K2 ERP

Приклад YML для документа реалізації

Ролі та права доступу

Що таке конфігурація 1С

Приклад аналізу старого звіту