Pull to refresh

Как нам обустроить альтернативу 1С

Reading time 8 min
Views 41K
Поскольку задача написания «аналогов» и «альтернатив» 1С нетривиальная, есть смысл изложить свое видение и ключевые моменты на основе опыта написания своей наколенной поделки. Ну и как бонус услышать критику и вовремя переделать где промахнулся.

По факту, на данный момент 1С занимает подавляющий сегмент в нише учетных систем. Это объясняется рядом причин, в том числе и агрессивным маркетингом. Напомню техническую сторону. 1С в общем виде, состоит как бы из двух физически отдельных частей — собственно платформы (ядра, движка) и так называемой конфигурации.

Конфигурация — это та часть, где собственно и реализуется прикладная бизнес-логика. Платформа предоставляет персистентное хранилище, бизнес-объекты высокого уровня, всякого рода конструкторы и построители отчетов, и специальный язык программирования. Но сама по себе технологическая платформа, даже с такими возможностями, не имела бы успеха. Поэтому конфигурация поставляется с уже написанной логикой — бухучет, торговля, склад и т.д. с учетом действующего законодательства. Это достаточно объемный труд, но в результате пользователь получает готовое законченное решение. А поскольку код самой конфигурации открыт, то остается возможность, как угодно корректировать бизнес-логику и подстраивать под свой бизнес.

Это плюсы. Но есть и масса минусов. Чтобы не описывать тут можно почитать например здесь.

Попыток вытеснить 1С предпринимается великое множество. Большинство проектов пытается переплюнуть плюсы 1С. Тягаться с огромной корпорацией дело малоперспективное. Продукты, писанные на Делфи или .NET, то есть требующие перекомпиляции, вообще неконкурентные, те, кто пытаются прикручивать в качестве DSL движки javascript или VBA выглядят чуть получше, но в любом случает такие решения могут использоваться в основном если есть штатный программист, чего малый бизнес, как правило, позволить себе не может.

Попробуем подобраться с другой стороны. Не пытаться переплюнуть достоинства 1С а предложить решения тех проблем где 1С имеет минусы.

Поскольку минусы где то уравновешивают плюсы а у нас этих минусов не будет то, даже если у нас не будет плюсов на уровне 1С, сальдо примерно будет такое же.

Итак, какие характеристики должны быть у создаваемой системы.

Open source. Кросплатформенность.

Тут объяснений не требуется.

Веб приложение.

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

PHP

Язык с низким порогом вхождения, знакомый большинству веб разработчиков. Для внесения изменений требуется только текстовый редактор. Веб приложение легко обновляется заменой отдельных файлов (привет конфигуратору 1С). Скриптовый слаботипизированный язык в сочетании с набором высокоуровневых бизнес-объектов хорошо подходит для написания бизнес-логики.

Казалось бы, что еще нужно для счастья. Тем не менее, в реальности опенсорс учетные системы — это, как правило, кривое портирование забугорных разработок.

Причем кривое не только локализацией. Для приведения к отечественному законодательству требуется немалый труд. Но и это не все. Бухгалтер, глядя на страницу такой системы, не будет понимать для чего половина полей и вообще как тут работать. Не забываем, что пользователь наверняка уже имеет опыт с 1С и наверняка это его единственный опыт работы с учетной системой. Это означает, что из сотни способов сделать макет страницы ввода накладной и подписать элементы ввода нужно выбирать тот, который по максимуму напоминает 1С (а значит, надо перелопатить все страницы забугорного творения).

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

Более распространенная проблема — переусложнение системы. Думаю, это основная причина, из-за которой проекты не доводятся до ума.

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

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

Примером является и сама 1С — от версии 2.0, где бухгалтера действительно вводили формулы на специальном «птичьем» языке до монстра 8.3. Попробуйте дать мануал непосвященному и посчитайте с какой попытки он врубится в витиеватую словесную конструкцию «план видов характеристик».

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

Поясню на примере. План счетов бухучета. Меняется крайне редко. Настраивается один раз при внедрении программы и, как правило, не меняется в процессе работы (напоминаю, речь не о энтерпрайз системах). Возможно, когда-то и понадобится добавить какой субсчет. Но под него наверняка надо скорректировать и код, а значит, звать программиста. Но программист за две секунды воткнет новую запись в план счетов с помощью обычного phpMyAdmin и незачем писать редактор плана счетов а юзера вынуждать указывать указывать наперед неизвестные счета в формах ввода первичных документов.

Аналогичным образом можно оставить только реально нужные и, главное понятные пользователю, настройки бизнес-логики — адреса, ставки налогов и т.д.

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

А теперь некоторые общие технические идеи, которые могут пригодиться «велосипедистам» при написании собственного «убийцо» 1С.

Хранение документов

Типичный вопрос на форумах, задаваемый писателями CRM, учетных, складских систем и систем документооборота. Как хранить документы, которые очевидно, имеют разнородную структуру. Отдельная таблица под каждый тип документа, общая таблица с кучей универсальных полей, модные нынче NoSQL хранилища…
Предлагается хранить все документы в одной таблице в блобе, упакованными в XML. Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус. Упаковка в XML имеет преимущество перед сериализацией или json — каждое значение обрамлено именованным тегом, а значит, можно выполнять сквозной поиск, не натыкаясь не лишние строки. То есть найти ссылку на контрагента по
<contragent>12</contragent>

не представляет труда, тем более большинство серверов БД поддерживают XPath. Упаковка-распаковка происходит автоматически в базовом классе, например, Document который содержит два предопределенных ассоциативных массива — header и details (массив массивов для табличной части) и которые заполняются дочерними классами — первичными документами как им по кайфу. Ключ ассоциативного массива становится тегом, значение — содержимым.

Функции упаковки и распаковки вызываются соответственно перед записью и после чтения документа из БД.
Кроме того, рекомендуется использовать денормализацию. Например, в документ пишется не только id контрагента а и его наименование, которое предъявляется пользователю. Много есть не просит, зато позволяет обойтись без джойнов к другим таблицам и использования «исторических» атрибутов.

Аналогично можно хранить справочники — контрагенты, сотрудники и т.д. Отдельно, в соответствующих таблицах, только поля идентификаторов, наименований, типов. То есть то по чем может понадобится сортировка или отбор. Остальное пакуется в XML. Такой подход, кроме всего прочего, позволит избежать необходимости изменения структуры БД при внесении изменений в систему (например появление нового атрибута справочника).
В идеале структура Бд должна меняться только при появлении в системе каких то совершенно новых бизнес-сущностей.

Печатные формы документов и отчетов.

Просто HTML. Плюс несложный шаблонизатор, например, Fenom.

Преимущества очевидны — можем создать любую печатную форму без всяких построителей, отобразить ее в браузере или распечатать. Кроме того, HTML экспортируется в Word и Excel. Делается это просто — HTML сохраняется с расширением docx или xslx. При открытии файла офис (во всяком случае, майкрософтовский) сам сконвертит в нужный формат. Да, убого. Но зато просто, универсально и не требует специального кодирования. В крайнем случае, всегда можно подправить руками в том же екселе.

При желании можно конвертить и в pdf но библиотеки типа TCPDF чувствительны к верстке и стилизации посему, кому надо, поставит PDFCreator и будет ему счастье.

Впрочем, с введением электронной отчетности и обмена электронными документами на первый план выходит экспорт-импорт а не печать на бумаге, поэтому смысл печатных форм в основном — оперативный просмотр документов а экране.

Хранение аналитики

Аналитические данные, связанные с синтетическими счетами в проводках. Субконто в терминах 1С. Реализация — одна таблица, по сути представляющая собой таблицу фактов в ROLAP типа звезда. Ссылка на документ, синтетический счет (отдельная запись на каждый корреспондирующий счет -типа полупроводки), количество, сумма. Дополнительные измерения — ссылки на основные бизнес сущности — контрагенты, партии товаров, сотрудники, денежные счета. Количество и сумма (отмасштабированные в целые числа) для дебета пишутся с плюсом для кредита — с минусом. Это позволяет простым суммированием путем полного пересчета получать остатки и обороты на любой период в разрезах основных бизнес-сущностей без необходимости хранить промежуточные итоги. Так же просчитываются и синтетические счета в проводках.

Такая схема позволяет удалять, проводить и перепроводить документы задним числом без пересчета итогов. А также проводить передним числом, например, реализовывая резервирование товаров.

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

Модульность

То, отсутствием чего страдает 1С. В некотором смысле систему можно разделить на условные «платформу» и «конфигуратор». Собственно структуру сайта, системные объекты и страницы можно считать платформой (ядром). Объекты бизнес логики — справочники, документы, отчеты и т.д могут быть подключены в произвольном сочетании. По сути каждый объект реализуется несколькими файлами. Для самого сложного — документа это 4 файла: шаблон страницы ввода, php файл — класс страницы ввода (бек-енд), файл шаблона печатной формы и php файл персистентной сущности (Entity), отвечающий за сохранение документа в хранилище. Файлы и классы PHP в них должны иметь общее «родовое» имя. Например, invoice или goodsissue. Файлы копируются в предопределенные папки. Затем в админпанели добавляется новый пункт меню со ссылкой на это имя и наименованием пункта меню, соответственно Счет или Накладная. При открытии основной страницы меню генерится автоматически, группируется, если указано, и получаем как бы “конфигурацию”. При выборе пункта меню система находит заведомо незнакомый файл страницы по «родовому» имени а дальше подтягиваются шаблоны и печатные формы…

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

Кстати, для одиночных пользователей, не умеющих разворачивать сайты, не проблема сделать сборку на основе WAMP сервера.

Может показаться, что предлагается какое-то низкоуровневое программирование — все захардкодить. Но ведь язык 1С по сути ничем не высокуровневее того же PHP. Просто там манипуляция бизнес-данными производится с помощью высокоуровневых бизнес-объектов (документов, справочников) что предлагается делать и здесь.

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

Разумеется, система, сделанная таким образом вряд ли подойдет для серьезных решений. Но большинство потребителей 1С — мелкий бизнес и вряд ли возникнет ситуация что сервер не справляется с обработкой данных, зато саппорт системы на порядок проще и дешевле. А труд программиста нынче гораздо дороже куска памяти или процессора.
Tags:
Hubs:
+3
Comments 434
Comments Comments 434

Articles