Comments 18
Для большой компании, у которой есть возможность инвестировать в развитие своего продукта, это выглядит оптимальным вариантом в плане именно получения функциональности для конечного пользователя. Так или иначе любая коробка в крупной компании превращается в самописное решение рано или поздно, особенно когда речь заходит о каком-то большом объеме данных и сложных процессах внутри бизнеса. Статью на мой взгляд стоит именно рассматривать в разрезе крупной компании. Для небольшого и среднего бизнеса это скорее все же будет слишком дорого.
Пример с какой-то непрозрачной арифметикой.
Мне кажется есть просто арифметические ошибки.
Очень странно складывать результаты, полученные по неверной предварительной себестоимости и исправленной. Это логическая ошибка.
В итоге у вас отражено списание недостач и списание на продажу неверной себестоимости. Как следствие - неверный анализ прибыльности продажи. Это следствие неверного учёта.
Спасибо, действительно ошибка арифметическая была, поправил
По поводу продажи и списания с неверное себестоимостью, это нормально если учетный центр это допускает, тк в итоге как можете видеть данная ошибка в дальнейшем компенсируется за счет оставшегося товара, если бы продажи и списания не было, то себестоимость была 5, но из за компенсации она стала 4,75, а если бы сложилась ситуация, что неосталось товара на складе для компенсации, то создалась бы проводка корректировки себестоимости, такое случается)
Это всё конечно интересно, но может оказаться, что этой продаже не повезло. И если мотивация у менеджера от этого зависит, то ему такой факт не понравится. Ну или примут ошибочное решение, что направление не приносит прибыли. А всего лишь ошибочная себестоимость
На примерах всё просто. Но будет накапливаться ошибка.
Много слов о транзакциях - в итоге так и не увидел как вы будете в параллель обрабатывать туже покупку товара с учетом что точно будут множество таблиц , и не известно разделено это на микросервисы . И главное учесть что в паралель может быть один и тотже человек. В общем очень всё абстрактно.
Ох. автору предостоят многия многия трудности, и их надо будет преодолевать. Желательно на берегу.
Кроме того. Печатные формы. Их бывает много. Бывает так, что разные клиенты хотят видеть разный УПД (Универсальный передаточный документ).
Отчёты. Да так, чтобы пользователь смог сгруппировать данные как он хочет. По разным критериям, добавляемым по ходу дела.
Хотелось бы забежать вперёд. Если вы заменяете 1С, то у вас будет бухгалтерский и налоговый учёт? За сколько лет будете брать законодательную базу?
-- Куда вы меня тащите?? Борис Григорьевич, отпустите меня... Аааа!!!
в любом случае описанная концепция позволит точно спрогнозировать затраты на внедрение, может быть даже и время, если уже описаны процессы, а также наверно позволит не зависеть от единственного поставщика решения в РФ. К тому же, любой не 1С ный код легче в поддержке, CI/CD попроще тоже.. Бух отчетность останется за один эс, конечно. Тема аналитики не раскрыта, но решения сбоку есть и их больше, чем один эс))) Надо про производство поподробнее в след. части
Ядровый модуль системы выглядит многообещающим, но ещё неочевидно как другие модули ERP-системы (например, Pricing или Purchase) будут воздействовать на него. Также интересно как по мнению автора это можно будет реализовать в коде с обеспечением согласованности данных в распределенном приложении.
Уделяя внимание цели статьи "Вот данная статья как раз о том, можно ли написать свою [систему]". Какое преимущество мы получим от этого с учётом больших затрат на разработку с точки зрения времени и финансов? Хочется наглядно впоследствии видеть пользу от собственной системы, а не радоваться изобретенному велосипеду. По крайней мере что вижу я - компания должна обладать специфичными бизнес-процессами, где работы происходят не по канону ради быстроты.
Отдельно лайк автору за применение диаграмм для иллюстрации идей.
Как не странно, но практически все системы в крупных компаниях, и не важно на основе чего созданные 1с, SAP, Oracle в долгосроке превращаются в собственный велосипед, те вряд ли система в РЖД подойдет к системе в Лукоил и тд))
Основные преимущества, которые вижу я:
Независимость от платформы, те в коробочных решениях ты ограничен данной платформой, ну например:
Сделать собственную авторизацию (на подобии yandex.passport) внутри компании, где все сервисы компании не требуют пароля и это невероятно удобно для сотрудников компании.
Единая репликация данных компании, если кто то когда то реплицировал 1с знает о чем я говорю).
Выбор стека, который доступен на рынке, те компания имея например кучу разработчиков на python вынуждена либо нанимать консалтинг и платить какое то невероятное количество бабла за внедрение или искать на рынке специалистов для данной коробки.
CI-CD для всех продуктов компании, ни одна коробка не поддерживает нормальный CI-CD, или делают какие то невероятные костыли для этого.
Новые фичи, которые в open source выходят почти каждый день, тебе приходится ждать, когда производитель коробки включит ее в новую версию, да притом еще тебе придется обновить свою коробку до этой версии, что для некоторых компаний весьма проблематично. привет json в 1с.
Защита от ухода с рынка компании разработчика - привет SAP, Oracle, Manhattan и прочие.
Международные специалисты - специалисты в коробках очень зависимы от страны происхождения системы, например найдите во вьетнаме или в малазии пару 1сников).
Своя архитектура и быстродействие - при грамотной архитектуре продукты, и применяя такие технологии как:
Асинхронность,
Шардирование,
Кеши,
Репликации,
Чтение данных из репликаций,
Вы не ограничены в быстродействием платформой(коробкой) и можете создавать сервис для любой нагрузки, и забыть уже о костылях типа мы делаем 2 базы а потом их синхронизируем по ночам :)
Независимость от лицензий,
Еще в коробках есть интересный нюанс), например у вас есть интернет магазин на Vue.js, а товары и остатки хранятся у вас в 1с, и вам нужно поддерживать кеш остатков для интернет магазина и контролировать резервирование, так вот забавное то, что в 1с есть другая коробка для работы с кешом, а вот во vue,js вам придется писать свой коннектор и блевать переодически программисту), вместо того, что бы воспользоваться тем же стандартом в opensource Redis, ну или замечательный tarantul от ребят из mail.ru.
Инфраструктура - это отдельная боль, имея штат замечательных ребят из devOps они все равно будут страдать, потому как никакая коробка не вписывается в нормальную инфраструктуру, и требует отдельного подхода
Ну и самый главный - НЕЗАВИСИМОСТЬ от разработчика например SAP, который просто ушел с рынка и послал вас к чертовой бабушке все ваши мечты о развитии вашей коробочки.
Но! справедливости ради добавлю, если компания не большая или средняя и ей в целом достаточно коробочного функционала той же 1с, то делать что то свое не имеет смысла.
Как я сказал выше, в долгосрочной перспективе, например 3-5 лет, разница между коробкой + допиливанием и созданной своей + допиливанием сводится с финансовой точки зрения к погрешности, но при этом все преимущества описанные выше своей системы сохраняются.
P.S. - на счет 1с, в целом никто не даст гарантии, что через какое то количество лет сама головная компания не исчезнет просто, всякое же может случится))
Системы превращаются в собственный велосипед, не подходящий другим, по двум причинам:
Не выделена общая логика учета - которая, в принципе, одинакова для всех предприятий.
Система планируется от выполняемых операций, а не от модели - поэтому опять же получается недостаточно абстрактной в основе.
Та же 1С позволяет создавать системы учета для самых разных предприятий - именно потому, что в ней заложена универсальная модель. Другой вопрос, что некоторые вещи там плохо реализованы - почему и приходится делать что-то свое.
Можно обсудить отдельно.
Как-то путано, на мой взгляд.
Непонятно, почему первичные документы выделены, они относятся и к закупкам, и к сбыту, и - внезапно! - к производству.
Непонятно, почему счета-фактуры относятся к учету, а не к первичным документам.
Почему касса вынесена в учет, а не в отдельный модуль типа закупок или продаж? Может быть, просто потому, что по ней мало операций?
Я сам занимался созданием учетных систем, и я бы создание учетной системы описал по-другому, может, поэтому мне данное описание кажется сумбурным, этакий черновой набросок.
Ну, можно обсудить, если есть желание.
Прошу, не называете это "Системой управления предприятием", так как вы находитесь "в километре от" задач управления предприятием и копаете не туда. Рекомендую задуматься над самим понятием "управление".
Для большой компании, у которой есть возможность инвестировать в развитие своего продукта, это выглядит оптимальным вариантом в плане именно получения функциональности для конечного пользователя. Так или иначе любая коробка в крупной компании превращается в самописное решение рано или поздно, особенно когда речь заходит о каком-то большом объеме данных и сложных процессах внутри бизнеса. Статью на мой взгляд стоит именно рассматривать в разрезе крупной компании. Для небольшого и среднего бизнеса это скорее все же будет слишком дорого.
Создание бизнес системы с самого нуля часть 1