Предпосылки
SAP окончательно уходит из России и перестает поддерживать ранее проданные локальные продукты
Смотря на движения в корпоративном софте в России ввиду последних событий большие компании стали явным образом задумываться о том, что бы слезть с таких продуктов как SAP, Oracle E-Business Suite, Microsoft Axapta и тд, и кажется движение вроде как верное, но куда же зарулят наши корпорации и зарулят ли туда?
Объясняя ход мыслей скажу, что почти все компании на текущий момент решают просто заменить шило на мыло, те слезть с одних, и пойти к другим, я имею ввиду нашу православную 1с.
Какие есть варианты
На самом деле вариантов не так и мало.
Ну первым пунктом действительно 1с.
Посмотреть на рынок помимо 1с, а на нем действительно есть open source решения, которые не плохо себя показывают в хороших руках.
Написать свою.
Вот данная статья как раз о том, можно ли написать свою и вообще как выглядит система управления/ учета предприятия изнутри, можно ли вообще ее взять и написать силами внутренней/внешней команды?
Спойлер - да.
Продумываем архитектуру системы
Давайте возьмем за основу некую компанию ООО Рога и копыта, которая занимается продажей к примеру мебели, а так же ее немного и производит. Так же у компании есть несколько складов, и несколько торговых точек и компания поделена на несколько юр лиц для оптимизации налоговой нагрузки.
С чего начать?
Сама по себе задача создать систему с нуля и охватить все аспекты компании выглядит довольно сложно, поэтому давайте произведем дифференциацию задачи на некие сферы применения.
Закупки - нам нужен функционал закупки сырья или товаров для последующего потребления в производстве или сразу на продажу,
Создавать контрагентов,
Создавать заявки на закупку (например от производства),
Создавать заказы на закупку поставщику разных типов,
отрытое предложение,
тендер,
другое.
Вести контракты/договора,
Вести прайс листы поставщиков,
Вести товары аналоги,
Формировать отчеты в разных разрезах.
Сбыт - нам нужно продавать, поэтому модуль сбыта нам так же необходим,
Создавать и вести клиентов,
Создавать сбытовые заказы,
Вести прайс листы поклиентно или клатерами,
Формировать отчеты в разных разрезах.
Ввод первичных документов - нужен модуль ввода первичных документов и выставлений счетов клиентам,
Вводить первичные документы от поставщиков,
Выставлять счета клиентам и принимать оплаты,
Производить сверки с контрагентами.
Запасы - как писалось выше в нашей компании несколько физических обьектов,
Вести товарный учет уровня организационной единицы компании,
Уметь перемещать товары между орг единицами компании,
Производство - компания производит мебель, а значит ей необходим функционал учитывающий потребление сырья и деталей, а так же планирование производства,
Уметь формировать BOM для производства,
Создавать производственные заказы,
Создавать и вести ресурсы (станки, люди),
Производить теоретический расчет по выпуску готовой продукции,
Создавать заявки на закупку на основе производственной потребности,
Уметь вести сложный цикл производства- Линяя1 --> Линяя2 ...
Персонал - как говорили "кадры решают все" и тут так же, нужно вести кадровый и табельный учет в компании.
Создавать сотрудников,
Создавать должности,
Создавать иерархию сотрудников (отделы, команды),
Вести табель учета рабочего времени,
Вести договор с сотрудником,
Производить расчет заработной платы,
Создавать и вести отпуска и отгулы сотрудников,
рассчитывать плановую потребность сотрудников на смену.
Склад - нам так же нужно управлять складом, производить приемку и отгрузку товаров.
Уметь выполнять внутрискладские операции:
Приемку,
Отгрузку,
Перемещения,
Снабжение производства,
Инвентаризация,
..... .
Учет и себестоимость - компании важно понимать реальную себестоимость производимой или закупаемой продукции, что бы выставлять клиентам адекватную цену, но в тоже время зарабатывать,
Уметь учитывать каждую хозяйственную деятельность в компании,
Уметь расчитывать себестоимость в каждый момент времени.
Согласно пунктам выше можно поразмыслить и понять, что между этими направлениями общего?
Учет - данный модуль по своей сути является общим для всех,
При закупке нам нужно вводить счет фактуру.
При производстве мы так же должны произвести нужные проводки для постановки на баланс готового изделия и списания сырья.
При продаже нам нужно выставить счет клиенту и получить оплату, или касса.
На складе мы так же производит учетные операции, такие как списания или инвентаризации.
Какой из этого вывод?
А вывод в том, что прежде чем нам тратить ресурсы на все модули нам нужно грамотно продумать учет (Я сейчас не про бухгалтерский учет).
В данном случае под учетом подразумевается некая система записей, которая будет отражать реальные хозяйственные операции компании, который будут понятно расшифровываться на уровне данных и возможность при необходимости переводить их в бухгалтерский учет.
![](https://habrastorage.org/getpro/habr/upload_files/9bc/0d1/e06/9bc0d1e066a9d9b7e641f3e2ef4ffbbd.png)
![](https://habrastorage.org/getpro/habr/upload_files/085/b5f/d61/085b5fd61af255e868464ac06caf60b7.png)
![](https://habrastorage.org/getpro/habr/upload_files/f9d/b0a/c01/f9db0ac01aa88bc590f0f9a5582e1091.png)
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.
Физические локации можно создавать внутри организационно единицы сколь угодно много, что бы например обозначить разные помещения или здания, или по другому логическому смыслу,
Виртуальные это локации отражающие так же необходимые действия такие как:
Потеря или находка товара,
Товары в пути и еще физически не находятся в организационной единице,
Товар производится.
Мы описали примерную структуру модуля логистики, если общими словами описать, то можно его описать так:
Что бы произвести логистическую операцию нужен документ основания, который создаст заказ на перемещение, в котором обьединяются движения, которые нужно исполнить исполнителем(кладовщиком), что бы появились записи о движениях.
ВАЖНО! помнить, что любое логистическое движение должно нести за собой транзакционные записи, то есть не бывает логистических движений без записей, это одно из важнейших правил, иначе все развалится.
Согласно нашему примеру компании, организационная и логистическая схема нашего ООО Рога и Копыта будет выглядеть примерно так:
![](https://habrastorage.org/getpro/habr/upload_files/ea3/3fd/da7/ea33fdda7f97174d619ae21d5537056a.png)
Есть сама ООО Рога и Копыта, а так же под ней есть несколько юр лиц:
ООО Верткий прыткий - это организационная единица РЦ, на который производится закупка и происходит снабжение готовой продукцией все остальные филиалы,
ООО Кручу верчу - это организационная единица с производством,
ООО Подай продай - это торговый дом, с которого происходит продажа,
ООО Рога и копыта - главный офис компании, у которого так же есть какие то помещения с товарами.
Промежуточные результаты
Мы описали учетную и логистическую архитектуру,
Давайте в теории произведем процесс закупки например, кока-колы для работников одного из наших ООО.
Сценарий выглядет примерно так:
Мы заказали у поставщика 5 банок кока колы по цене 5,25$ и приняли на склад, после этого мы продали 1 шт, одна оказалась бракованной и мы ее списали. После этого мы ввели счет фактуру поставщика и оказалось, что цена 1й банки 5$, а количество и вовсе 4шт.
![](https://habrastorage.org/getpro/habr/upload_files/386/36f/f9a/38636ff9ab241aa9ec68e10315bb0e84.png)
Транзакционный результат такого процесса будет выглядеть примерно так:
![](https://habrastorage.org/getpro/habr/upload_files/cdc/cbb/6c8/cdccbb6c81ab9f4ce7f0b8e478d7db0e.png)
ХТ - это физическая локация.
СР - склад разниц.
Пояснения
Из та того, что в инвойсе цена уменьшилась с 5,25$ до 5$, но при этом склад уже успел продать 1 штуку и списать 1 штуку по цене 5,25$ себестоимость остатка уменьшилась с 5$ (из инвойса) до 4,75$ до покрытия ценовой разницы,
Так же ввиду того, что фактически пришло 5шт, а отфактурировали мы только 4, появилась проводка, которая отражает разницу
Заключение по первой части
В первой части мы проговорили цели и упорядочили потребность, сделали правильные выводы и дифференцировали задачу на более мелкие блоки,
В данной части мы успели затронуть 2 модуля
Транзакционный модуль - который ведет записи по всем хозяйственным действиям в компании,
Запасы - модуль описывающий логистическую структуру компании, с помощью которой можно организационно поделить компанию на разные организационные единицы, а так же логические блоки внутри этих единиц(локации).
В дальнейших частях разберем модуль закупок и производства.