Предпосылки

SAP окончательно уходит из России и перестает поддерживать ранее проданные локальные продукты

Смотря на движения в корпоративном софте в России ввиду последних событий большие компании стали явным образом задумываться о том, что бы слезть с таких продуктов как SAP, Oracle E-Business Suite, Microsoft Axapta и тд, и кажется движение вроде как верное, но куда же зарулят наши корпорации и зарулят ли туда?

Объясняя ход мыслей скажу, что почти все компании на текущий момент решают просто заменить шило на мыло, те слезть с одних, и пойти к другим, я имею ввиду нашу православную 1с.

Какие есть варианты

На самом деле вариантов не так и мало.

  • Ну первым пунктом действительно 1с.

  • Посмотреть на рынок помимо 1с, а на нем действительно есть open source решения, которые не плохо себя показывают в хороших руках.

  • Написать свою.

Вот данная статья как раз о том, можно ли написать свою и вообще как выглядит система управления/ учета предприятия изнутри, можно ли вообще ее взять и написать силами внутренней/внешней команды?

Спойлер - да.

Продумываем архитектуру системы

Давайте возьмем за основу некую компанию ООО Рога и копыта, которая занимается продажей к примеру мебели, а так же ее немного и производит. Так же у компании есть несколько складов, и несколько торговых точек и компания поделена на несколько юр лиц для оптимизации налоговой нагрузки.

С чего начать?

Сама по себе задача создать систему с нуля и охватить все аспекты компании выглядит довольно сложно, поэтому давайте произведем дифференциацию задачи на некие сферы применения.

  • Закупки - нам нужен функционал закупки сырья или товаров для последующего потребления в производстве или сразу на продажу,

    • Создавать контрагентов,

    • Создавать заявки на закупку (например от производства),

    • Создавать заказы на закупку поставщику разных типов,

      • отрытое предложение,

      • тендер,

      • другое.

    • Вести контракты/договора,

    • Вести прайс листы поставщиков,

    • Вести товары аналоги,

    • Формировать отчеты в разных разрезах.

  • Сбыт - нам нужно продавать, поэтому модуль сбыта нам так же необходим,

    • Создавать и вести клиентов,

    • Создавать сбытовые заказы,

    • Вести прайс листы поклиентно или клатерами,

    • Формировать отчеты в разных разрезах.

  • Ввод первичных документов - нужен модуль ввода первичных документов и выставлений счетов клиентам,

    • Вводить первичные документы от поставщиков,

    • Выставлять счета клиентам и принимать оплаты,

    • Производить сверки с контрагентами.

  • Запасы - как писалось выше в нашей компании несколько физических обьектов,

    • Вести товарный учет уровня организационной единицы компании,

    • Уметь перемещать товары между орг единицами компании,

  • Производство - компания производит мебель, а значит ей необходим функционал учитывающий потребление сырья и деталей, а так же планирование производства,

    • Уметь формировать BOM для производства,

    • Создавать производственные заказы,

    • Создавать и вести ресурсы (станки, люди),

    • Производить теоретический расчет по выпуску готовой продукции,

    • Создавать заявки на закупку на основе производственной потребности,

    • Уметь вести сложный цикл производства- Линяя1 --> Линяя2 ...

  • Персонал - как говорили "кадры решают все" и тут так же, нужно вести кадровый и табельный учет в компании.

    • Создавать сотрудников,

    • Создавать должности,

    • Создавать иерархию сотрудников (отделы, команды),

    • Вести табель учета рабочего времени,

    • Вести договор с сотрудником,

    • Производить расчет заработной платы,

    • Создавать и вести отпуска и отгулы сотрудников,

    • рассчитывать плановую потребность сотрудников на смену.

  • Склад - нам так же нужно управлять складом, производить приемку и отгрузку товаров.

    • Уметь выполнять внутрискладские операции:

      • Приемку,

      • Отгрузку,

      • Перемещения,

      • Снабжение производства,

      • Инвентаризация,

      • ..... .

  • Учет и себестоимость - компании важно понимать реальную себестоимость производимой или закупаемой продукции, что бы выставлять клиентам адекватную цену, но в тоже время зарабатывать,

    • Уметь учитывать каждую хозяйственную деятельность в компании,

    • Уметь расчитывать себестоимость в каждый момент времени.

Согласно пунктам выше можно поразмыслить и понять, что между этими направлениями общего?

Учет - данный модуль по своей сути является общим для всех,

  • При закупке нам нужно вводить счет фактуру.

  • При производстве мы так же должны произвести нужные проводки для постановки на баланс готового изделия и списания сырья.

  • При продаже нам нужно выставить счет клиенту и получить оплату, или касса.

  • На складе мы так же производит учетные операции, такие как списания или инвентаризации.

Какой из этого вывод?

А вывод в том, что прежде чем нам тратить ресурсы на все модули нам нужно грамотно продумать учет (Я сейчас не про бухгалтерский учет).

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

Valuation layer - транзакционный учет

Ядровый модуль системы должен в себе содержать все необходимые сведения необходимые для правильного и всеобъемлющего учета каждой хозяйственной операции компании. Так же для того, что бы система была аудируемой нужно сделать так, что бы номера транзакций в рамках одной организационной единицы не повторялись, а так же не имели пропусков, что бы было гарантировано, что никто не мог создать какую либо транзакцию задным числом.

Так же каждую транзакцию нужно разделить по типу хозяйственной операции.

Общий набор данных транзакции должен выглядеть примерно так:

номер транзакции nogap:
тип транзакции:
	INBOUND: #товар/услуги пришел физически на склад,
	S_INBOUND: #сторно приходя товара/услуги на склад,
	INVOICE: #фактурирование товара или услуг,
	S_INVOICE: #сторно фактурирования товара или услуг,
	SHIP_OUT: #отгрузка товара во вне (другой unit или покупателю),
	SHIP_IN: #приход товара извне (так же является сторнирующим движением для SHIP_OUT,
	WRITEOFF: #списание товара (сломался, испортился и тд),
	RECALC_OUT: #пересчет товара в меньшую сторону на локации,
	RECALC_IN: #пересчет товара в большую сторону,
	SALE_OUT: #продажа товара внешнему поставщику,
	SALE_IN: #возврат товара внешнему поставщику (сторно),
	RECLASS_OUT: #Пересортица товара -,
	RECLASS_INN: #Пересортица +,
	И так далее: #но важно сохранение принципа двойной записи, позже будет 
  #описано
группа транзакций: #для того, что бы обьединять транзакции в группу по смыслу
	PURCHASE: #обьединяет транзакции,
	SALE: #Сбыт,
	PRODUCTION: #Производство.
локация организационной единицы: 
	WH: #Физический склад,
 	DIFF: #Склад разниц, куда уходят/приходят разницы в процессах рабоыт склада
 	TRANS: #Склад транзаит, отвечает за товары в пути
 	PRODUCTION: #Склад куда в процессе производтсва уходят ингридиенты, 
  #и из него появляется готовое изделие,
организационная единица: #Единица компании (магазин, склад, офис и проч.),
документ: #Документ основание хозяйственной операции
дата и время хозяйственной операции: #Время проведение операции,
тип цены: #Данное поле отражает какая цена была выбрана в транзакции
	цена из документа закупки: #Цена взятая из заказа на закупку,
  цена из прайс листа: #Цена из прайс листа закупки,
  среднескользящая цена: #Те цена из предыдущей транзации
цена за единицу товара: #Цена за 1шт,
количество: #Количество в транзакции,
стоимость: #Стоимость товара/услуги в транзакции,
количество после транзации: #Количество товара в рамках локации после
#транзакции
стоимость после транзации: #Стоимость товара после транзакции
движение: #логистическое движжение.

Это не полная но отражающая суть структура обьекта, которая достаточно для того, что бы учесть любую хозяйственную операцию в рамках компании, то есть все без исключения бизнес процессы в компании должны нести создавать транзакции:

  • Приемка товара на склад,

  • Продажа товара,

  • Производство,

  • Списания,

  • ..... .

Итак разобрались и придумали по какому принципу будет формироваться финансовый лог хозяйственных действий, теперь стоит подойди к логистическому.

Stock - логистический учет (Запасы)

Вторым по значимости с точки зрения общих функциональностей между сферами применения системы(модулями) является логистический модуль, те модуль который управляет операциями(движениями) с товаром, не на уровне склада, а на уровне организационной единицы компании:

  • Приемка,

  • Отгрузка,

  • Перемещения,

  • Списания,

  • Производство,

  • Снабжение производства,

  • .... .

В данном модуле нужно описать товаро-материальную схему учета

Основываясь на транзакционном учете можно уже сейчас предположить, что у нас будут такие обьекты как:

Товар: #Обьект в системе хранящий характеристики товаров и услуг, которыми 
			 #оперирует система, основные характеристики
	код: #код товара, артикул,
  баркоды: #набор штрихкодов товара,
  тип: #тип товара,
  	товар:
    улуга:
    потребляемое:
    основное средство:
  категория:
  вес:
  обьем:
  единица измерения:
#----------------------------------------------------------------------
	Категория: #Товары с похожими свойствами, например "Смеси",
		код: #код категории
    тип категории: #см. товар,
    родитель: #категории могут быть иерархичными
#______________________________________________________________________
Организационная единица компании: #Обьект в системе определяющий территориальную 
#единицу
	код: #сокращенный код внутри компании,
  тип: #тип органиционной единицы
  	склад:
    распределительный центр:
    офис:
    магазин:
    представительство:
	наименование:
#_______________________________________________________________________
Локация: #Обьект в системе определяющий логическую или физическую локацию 
#внутри организационной единицы, так же локации могут быть виртуальные и 
#служить как двойная запись для совершения движений товаров и услуг, 
#например общая локация разниц или списаний
	код: #сокращенный код внутри компании,
	организационная единица:
  тип: #Тип локации
  	хранение: #физическое размещение товаров,
    cклад разниц: #сумируются разницы в рамках организационной единицы
    транзитный склад: #отражает товары в пути
    склад производства: #склад для списаний ингридиентов и оприходывания
    #готовой продукции.
	наименование:
  родитель: #физические локации могут быть вложенными
#_________________________________________________________________________
Движение: #Основной документ системы отражающий в себе изменение состояния
#запаса, те смена локации, приемка товара, отгрузка товара и проч.
	локация источник: #из какой локации перемещяется товар,
  локация назначения: #куда перемещается товар,
  тип перемещения:
  	приемка:
    отгрузка:
    списание:
    производство:
    .........: 
	планируемое количество:
  фактическое количество:
  статус: 
  	черновик:
    в процессе:
    завершено:
	исполнитель: #Пользователь, который исполнил движение,
  родитель: #родительский документ движения,
  задание: #задание,
  транзакционные записи: #Запись в транзакционном слое valuation layer.
__________________________________________________________________________
Задание на движение: #Документ, обьединяющий разные движения по смыслу, 
#например нужно переместить много товаров из одного перемещения в другое, 
#или скомплектовать отгрузку.
	документ основание: #Это может быть Заказ на закупку, или Задание на производство
	локация источник: #из какой локации перемещяется товар,
  локация назначения: #куда перемещается товар,
  тип задания:
  	отгрузка:
    приемка:
    снабжение производства:
    .....:
	статус:
  исполнитель:
  родитель:

Немного подробнее о обьектах:

Организационная единица компании - это единица с точки зрения компании, которая достаточно автономна, что бы производить отдельный товарный учет для нее, а так же делить на логические структуры

Локация - локация это логическое деление организационной единицы с точки зрения складского учета, а так же отражения потерь и находок, локации бывают:

  • Физические WH;

  • Виртуальные DIFF, GIT, PRODUCTION.

Физические локации можно создавать внутри организационно единицы сколь угодно много, что бы например обозначить разные помещения или здания, или по другому логическому смыслу,

Виртуальные это локации отражающие так же необходимые действия такие как:

  • Потеря или находка товара,

  • Товары в пути и еще физически не находятся в организационной единице,

  • Товар производится.

Мы описали примерную структуру модуля логистики, если общими словами описать, то можно его описать так:

Что бы произвести логистическую операцию нужен документ основания, который создаст заказ на перемещение, в котором обьединяются движения, которые нужно исполнить исполнителем(кладовщиком), что бы появились записи о движениях.

ВАЖНО! помнить, что любое логистическое движение должно нести за собой транзакционные записи, то есть не бывает логистических движений без записей, это одно из важнейших правил, иначе все развалится.

Согласно нашему примеру компании, организационная и логистическая схема нашего ООО Рога и Копыта будет выглядеть примерно так:

Есть сама ООО Рога и Копыта, а так же под ней есть несколько юр лиц:

  • ООО Верткий прыткий - это организационная единица РЦ, на который производится закупка и происходит снабжение готовой продукцией все остальные филиалы,

  • ООО Кручу верчу - это организационная единица с производством,

  • ООО Подай продай - это торговый дом, с которого происходит продажа,

  • ООО Рога и копыта - главный офис компании, у которого так же есть какие то помещения с товарами.

Промежуточные результаты

Мы описали учетную и логистическую архитектуру,

Давайте в теории произведем процесс закупки например, кока-колы для работников одного из наших ООО.

Сценарий выглядет примерно так:

Мы заказали у поставщика 5 банок кока колы по цене 5,25$ и приняли на склад, после этого мы продали 1 шт, одна оказалась бракованной и мы ее списали. После этого мы ввели счет фактуру поставщика и оказалось, что цена 1й банки 5$, а количество и вовсе 4шт.

Транзакционный результат такого процесса будет выглядеть примерно так:

ХТ - это физическая локация.

СР - склад разниц.

Пояснения

Из та того, что в инвойсе цена уменьшилась с 5,25$ до 5$, но при этом склад уже успел продать 1 штуку и списать 1 штуку по цене 5,25$ себестоимость остатка уменьшилась с 5$ (из инвойса) до 4,75$ до покрытия ценовой разницы,

Так же ввиду того, что фактически пришло 5шт, а отфактурировали мы только 4, появилась проводка, которая отражает разницу 

Заключение по первой части

В первой части мы проговорили цели и упорядочили потребность, сделали правильные выводы и дифференцировали задачу на более мелкие блоки,

В данной части мы успели затронуть 2 модуля

  • Транзакционный модуль - который ведет записи по всем хозяйственным действиям в компании,

  • Запасы - модуль описывающий логистическую структуру компании, с помощью которой можно организационно поделить компанию на разные организационные единицы, а так же логические блоки внутри этих единиц(локации).

В дальнейших частях разберем модуль закупок и производства.

Комментарии (17)


  1. Naf2000
    27.06.2022 20:00

    Пример с какой-то непрозрачной арифметикой.

    1. Мне кажется есть просто арифметические ошибки.

    2. Очень странно складывать результаты, полученные по неверной предварительной себестоимости и исправленной. Это логическая ошибка.

    3. В итоге у вас отражено списание недостач и списание на продажу неверной себестоимости. Как следствие - неверный анализ прибыльности продажи. Это следствие неверного учёта.


    1. zambas Автор
      27.06.2022 22:13

      Спасибо, действительно ошибка арифметическая была, поправил

      По поводу продажи и списания с неверное себестоимостью, это нормально если учетный центр это допускает, тк в итоге как можете видеть данная ошибка в дальнейшем компенсируется за счет оставшегося товара, если бы продажи и списания не было, то себестоимость была 5, но из за компенсации она стала 4,75, а если бы сложилась ситуация, что неосталось товара на складе для компенсации, то создалась бы проводка корректировки себестоимости, такое случается)


      1. Naf2000
        27.06.2022 23:52

        Это всё конечно интересно, но может оказаться, что этой продаже не повезло. И если мотивация у менеджера от этого зависит, то ему такой факт не понравится. Ну или примут ошибочное решение, что направление не приносит прибыли. А всего лишь ошибочная себестоимость


      1. MaximRV
        28.06.2022 05:40

        На примерах всё просто. Но будет накапливаться ошибка.


  1. makar_crypt
    27.06.2022 21:08
    +2

    Много слов о транзакциях - в итоге так и не увидел как вы будете в параллель обрабатывать туже покупку товара с учетом что точно будут множество таблиц , и не известно разделено это на микросервисы . И главное учесть что в паралель может быть один и тотже человек. В общем очень всё абстрактно.


    1. zambas Автор
      28.06.2022 08:12

      Статья и служит абстракцией технического задания, а создать можно как на микросервисах так и на монолите, продумывать параллелизацию и прочие вещи нужно уже после


  1. MaximRV
    28.06.2022 05:39
    +2

    Ох. автору предостоят многия многия трудности, и их надо будет преодолевать. Желательно на берегу.
    Кроме того. Печатные формы. Их бывает много. Бывает так, что разные клиенты хотят видеть разный УПД (Универсальный передаточный документ).
    Отчёты. Да так, чтобы пользователь смог сгруппировать данные как он хочет. По разным критериям, добавляемым по ходу дела.


  1. Dddn
    28.06.2022 10:20

    Хотелось бы забежать вперёд. Если вы заменяете 1С, то у вас будет бухгалтерский и налоговый учёт? За сколько лет будете брать законодательную базу?


    1. zambas Автор
      28.06.2022 11:53

      В статье не идет речь о замене бухгалтерского учета, речь о создании в системе единой транзакционной логике, из которого можно уже данные передавать в бухгалтерский учет, если это необходимо


  1. Sergio73
    28.06.2022 10:32

    -- Куда вы меня тащите?? Борис Григорьевич, отпустите меня... Аааа!!!


  1. Coolspawn
    28.06.2022 11:51
    +2

    в любом случае описанная концепция позволит точно спрогнозировать затраты на внедрение, может быть даже и время, если уже описаны процессы, а также наверно позволит не зависеть от единственного поставщика решения в РФ. К тому же, любой не 1С ный код легче в поддержке, CI/CD попроще тоже.. Бух отчетность останется за один эс, конечно. Тема аналитики не раскрыта, но решения сбоку есть и их больше, чем один эс))) Надо про производство поподробнее в след. части


  1. Sombrero1
    28.06.2022 13:32
    +1

    Ядровый модуль системы выглядит многообещающим, но ещё неочевидно как другие модули ERP-системы (например, Pricing или Purchase) будут воздействовать на него. Также интересно как по мнению автора это можно будет реализовать в коде с обеспечением согласованности данных в распределенном приложении.

    Уделяя внимание цели статьи "Вот данная статья как раз о том, можно ли написать свою [систему]". Какое преимущество мы получим от этого с учётом больших затрат на разработку с точки зрения времени и финансов? Хочется наглядно впоследствии видеть пользу от собственной системы, а не радоваться изобретенному велосипеду. По крайней мере что вижу я - компания должна обладать специфичными бизнес-процессами, где работы происходят не по канону ради быстроты.

    Отдельно лайк автору за применение диаграмм для иллюстрации идей.


    1. zambas Автор
      28.06.2022 13:52

      Как не странно, но практически все системы в крупных компаниях, и не важно на основе чего созданные 1с, SAP, Oracle в долгосроке превращаются в собственный велосипед, те вряд ли система в РЖД подойдет к системе в Лукоил и тд))

      Основные преимущества, которые вижу я:

      1. Независимость от платформы, те в коробочных решениях ты ограничен данной платформой, ну например:

        1. Сделать собственную авторизацию (на подобии yandex.passport) внутри компании, где все сервисы компании не требуют пароля и это невероятно удобно для сотрудников компании.

        2. Единая репликация данных компании, если кто то когда то реплицировал 1с знает о чем я говорю).

        3. Выбор стека, который доступен на рынке, те компания имея например кучу разработчиков на python вынуждена либо нанимать консалтинг и платить какое то невероятное количество бабла за внедрение или искать на рынке специалистов для данной коробки.

        4. CI-CD для всех продуктов компании, ни одна коробка не поддерживает нормальный CI-CD, или делают какие то невероятные костыли для этого.

        5. Новые фичи, которые в open source выходят почти каждый день, тебе приходится ждать, когда производитель коробки включит ее в новую версию, да притом еще тебе придется обновить свою коробку до этой версии, что для некоторых компаний весьма проблематично. привет json в 1с.

      2. Защита от ухода с рынка компании разработчика - привет SAP, Oracle, Manhattan и прочие.

      3. Международные специалисты - специалисты в коробках очень зависимы от страны происхождения системы, например найдите во вьетнаме или в малазии пару 1сников).

      4. Своя архитектура и быстродействие - при грамотной архитектуре продукты, и применяя такие технологии как:

        1. Асинхронность,

        2. Шардирование,

        3. Кеши,

        4. Репликации,

        5. Чтение данных из репликаций,

        Вы не ограничены в быстродействием платформой(коробкой) и можете создавать сервис для любой нагрузки, и забыть уже о костылях типа мы делаем 2 базы а потом их синхронизируем по ночам :)

      5. Независимость от лицензий,

      6. Еще в коробках есть интересный нюанс), например у вас есть интернет магазин на Vue.js, а товары и остатки хранятся у вас в 1с, и вам нужно поддерживать кеш остатков для интернет магазина и контролировать резервирование, так вот забавное то, что в 1с есть другая коробка для работы с кешом, а вот во vue,js вам придется писать свой коннектор и блевать переодически программисту), вместо того, что бы воспользоваться тем же стандартом в opensource Redis, ну или замечательный tarantul от ребят из mail.ru.

      7. Инфраструктура - это отдельная боль, имея штат замечательных ребят из devOps они все равно будут страдать, потому как никакая коробка не вписывается в нормальную инфраструктуру, и требует отдельного подхода

      8. Ну и самый главный - НЕЗАВИСИМОСТЬ от разработчика например SAP, который просто ушел с рынка и послал вас к чертовой бабушке все ваши мечты о развитии вашей коробочки.

      Но! справедливости ради добавлю, если компания не большая или средняя и ей в целом достаточно коробочного функционала той же 1с, то делать что то свое не имеет смысла.

      Как я сказал выше, в долгосрочной перспективе, например 3-5 лет, разница между коробкой + допиливанием и созданной своей + допиливанием сводится с финансовой точки зрения к погрешности, но при этом все преимущества описанные выше своей системы сохраняются.

      P.S. - на счет 1с, в целом никто не даст гарантии, что через какое то количество лет сама головная компания не исчезнет просто, всякое же может случится))


      1. Severn
        28.06.2022 14:41

        Системы превращаются в собственный велосипед, не подходящий другим, по двум причинам:

        1. Не выделена общая логика учета - которая, в принципе, одинакова для всех предприятий.

        2. Система планируется от выполняемых операций, а не от модели - поэтому опять же получается недостаточно абстрактной в основе.

        Та же 1С позволяет создавать системы учета для самых разных предприятий - именно потому, что в ней заложена универсальная модель. Другой вопрос, что некоторые вещи там плохо реализованы - почему и приходится делать что-то свое.

        Можно обсудить отдельно.


  1. Severn
    28.06.2022 14:32

    Как-то путано, на мой взгляд.

    Непонятно, почему первичные документы выделены, они относятся и к закупкам, и к сбыту, и - внезапно! - к производству.

    Непонятно, почему счета-фактуры относятся к учету, а не к первичным документам.

    Почему касса вынесена в учет, а не в отдельный модуль типа закупок или продаж? Может быть, просто потому, что по ней мало операций?

    Я сам занимался созданием учетных систем, и я бы создание учетной системы описал по-другому, может, поэтому мне данное описание кажется сумбурным, этакий черновой набросок.

    Ну, можно обсудить, если есть желание.


  1. gimatdinov
    29.06.2022 00:05

    Прошу, не называете это "Системой управления предприятием", так как вы находитесь "в километре от" задач управления предприятием и копаете не туда. Рекомендую задуматься над самим понятием "управление".


    1. zambas Автор
      29.06.2022 08:06
      +1

      Просьбу услышал)