Поскольку задача написания «аналогов» и «альтернатив» 1С нетривиальна, имеет смысл изложить свое видение и ключевые моменты, основанные на опыте написания собственной поделки.
Ну и как бонус, это бонус услышать критику и вовремя переделать то, что упустили.
Фактически на данный момент 1С занимает подавляющий сегмент в нише учетных систем.
Это связано с рядом причин, в том числе с агрессивным маркетингом.
Напомню о технической стороне.
1С вообще состоит из двух физически отдельных частей — самой платформы (ядра, движка) и так называемой конфигурации.
Конфигурация — это часть, в которой фактически реализуется прикладная бизнес-логика.
Платформа предоставляет постоянное хранилище, бизнес-объекты высокого уровня, всевозможные дизайнеры и построители отчетов, а также специальный язык программирования.
Но сама технологическая платформа, даже обладая такими возможностями, не будет успешной.
Поэтому конфигурация идет с уже написанной логикой - учет, торговля, склад и т.д. с учетом действующего законодательства.
Это довольно большая работа, но в результате пользователь получает готовое законченное решение.
А поскольку код самой конфигурации открыт, остается возможность настроить бизнес-логику по своему желанию и адаптировать ее под свой бизнес.
Это преимущества.
Но есть и много недостатков.
Чтобы не описывать здесь, можно почитать например Здесь .
Попыток вытеснить 1С очень много.
Большинство проектов пытаются переплюнуть преимущества 1С.
Конкурировать с огромной корпорацией не очень перспективно.
Продукты, написанные на Delphi или .
NET, то есть требующие перекомпиляции, как правило, неконкурентоспособны; те, кто пытается присоединить javascript или VBA-движки в качестве DSL, выглядят немного лучше, но в любом случае такие решения можно использовать в основном при наличии штатного программиста, что малому бизнесу, как правило, не по карману.
Попробуем перейти на другую сторону.
Не пытайтесь переплюнуть преимущества 1С, а предложите решения тех проблем, где у 1С есть недостатки.
Так как минусы где-то уравновешивают плюсы, и этих минусов у нас не будет, даже если у нас не будет плюсов на уровне 1С, то баланс будет примерно такой же.
Итак, какими характеристиками должна обладать создаваемая система? Открытый источник.
Кроссплатформенность.
Никаких пояснений здесь не требуется.
Веб приложение.
Многопользовательский режим с возможностью прямого доступа с мобильных устройств без необходимости написания специальных клиентов, синхронизации каталогов и т.д. PHP Язык с низким порогом входа, знакомый большинству веб-разработчиков.
Для внесения изменений требуется только текстовый редактор.
Веб-приложение легко обновляется путем замены отдельных файлов (привет конфигуратору 1С).
Слабо типизированный язык сценариев в сочетании с набором бизнес-объектов высокого уровня хорошо подходит для написания бизнес-логики.
Казалось бы, что еще нужно для счастья.
Однако на самом деле системы учета с открытым исходным кодом представляют собой, как правило, кривое портирование зарубежных разработок.
Причем кривая – это не только локализация.
Внесение этого во внутреннее законодательство требует большой работы.
Но это не все.
Бухгалтер, заглянув на страницу такой системы, не поймет, для чего нужна половина полей и вообще как здесь работать.
Не забывайте, что у пользователя наверняка уже есть опыт работы с 1С и это, пожалуй, единственный его опыт работы с учетной системой.
Это значит, что из сотен способов сделать макет страницы ввода счета-фактуры и подписать элементы ввода нужно выбрать тот, который больше всего напоминает 1С (а значит, нужно пройти все страницы зарубежного творения).
Когда я давал фрилансерам наполнять свою систему демо-данными (типа демо-конфигурации в 1С), ни разу не возникал вопрос — как здесь работать.
Более распространенной проблемой является то, что система становится слишком сложной.
Я думаю, это основная причина, по которой проекты не доводятся до конца.
Программист обычно делает систему максимально гибкой (а как же иначе!) две трети своего времени тратит на написание многочисленных настроек, мастеров, генераторов или, того хуже, инструментов для командной строки и т.п.
Пользователь, бухгалтер, не будучи ИТ-специалистом, с тоской смотрит на все это добро, не понимая, почему он не может просто установить пару кнопок.
Потом вызывает программиста, чтобы тот пришёл и настроил программу после очередного приказа Минфина.
Программист искренне возмущается, что за тупой пользователь, неужели сложно справиться с парой десятков шашек и комбобоксов? Правда, его страсть утихает, когда оказывается, что конфигурации недостаточно и теперь нам предстоит пробираться через дебри инфраструктурного кода, обеспечивающего пресловутую гибкость.
Примером может служить сама 1С — от версии 2.0, где бухгалтеры фактически вводили формулы на специальном «птичьем» языке, до монстра 8.3. Попробуйте дать пособие непосвященному и посчитайте, насколько трудно ему уловить витиеватую словесную конструкцию «план видов характеристик».
Это приводит к следующей идее.
Поскольку пригласить программиста все равно и стоимость работы этого программиста пропорциональна сложности системы, то зачем с этим заморачиваться.
Не проще ли выкинуть всё от лукавого и дать программисту возможность работать только с бизнес-логикой, ведь реализация бизнес-логики — это собственно задача программы.
Позвольте мне объяснить на примере.
Бухгалтерский план счетов.
Меняется крайне редко.
Он настраивается один раз при внедрении программы и, как правило, не меняется в процессе работы (напоминаю, речь не идет о корпоративных системах).
Возможно, в какой-то момент вам понадобится добавить субаккаунт. Но код, вероятно, нужно подкорректировать под него, а это значит вызвать программиста.
Но новую запись в план счетов программист вставит за две секунды с помощью обычного phpMyAdmin и нет необходимости писать редактор плана счетов и заставлять пользователя заранее указывать неизвестные счета в формах ввода первичных документов.
Аналогично можно оставить только те настройки бизнес-логики, которые действительно необходимы и, главное, понятны пользователю — адреса, налоговые ставки и т. д. Это основная идеология, которая, на мой взгляд, должна присутствовать при реализации данного класса задач.
А теперь несколько общих технических идей, которые могут пригодиться «велосипедистам» при написании своего «убийцы» 1С.
Хранение документов Типичный вопрос на форумах, который задают авторы CRM, систем бухгалтерского учета, склада и документооборота.
Как хранить документы, которые заведомо имеют неоднородную структуру.
Отдельная таблица для каждого типа документа, общая таблица с кучей универсальных полей, модное нынче NoSQL-хранилище.
Все документы предлагается хранить в одной таблице в виде блоба, упакованного в XML. Отдельно — только общие поля, которые отображаются в списках и журналах — номер документа, дата создания, автор, статус.
Упаковка в XML имеет преимущество перед сериализацией или json — каждое значение окружено именованным тегом, что означает, что вы можете выполнять сквозной поиск, не натыкаясь на ненужные строки.
То есть найти ссылку на контрагента по
несложно, тем более что большинство серверов баз данных поддерживают XPath. Упаковка и распаковка происходит автоматически в базовом классе, например, Document, который содержит два предопределённых ассоциативных массива — заголовок и реквизиты (массив массивов для табличной части) и которые заполняются дочерними классами — первичными документами по своему усмотрению.<contragent>12</contragent>
Ключ ассоциативного массива становится тегом, значение становится содержимым.
Функции упаковки и распаковки вызываются соответственно перед записью и после чтения документа из базы данных.
Дополнительно рекомендуется использовать денормализацию.
Например, в документ прописывается не только идентификатор контрагента, но и его имя, которое представляется пользователю.
Многого от него не требуется, но позволяет обойтись без объединений с другими таблицами и использования «исторических» атрибутов.
Аналогично можно хранить справочники - контрагенты, сотрудники и т.д. Отдельно в соответствующих таблицах только поля идентификаторов, названий, типов.
То есть что-то, благодаря чему может потребоваться сортировка или отбор.
Остальное упаковано в XML. Такой подход, помимо прочего, позволит избежать необходимости изменения структуры базы данных при внесении изменений в систему (например, появлении нового атрибута каталога).
В идеале структура базы данных должна меняться только тогда, когда в системе появляются совершенно новые бизнес-сущности.
Печатные формы документов и отчетов.
Просто HTML. Плюс простой шаблонизатор, например, Феномен .
Преимущества очевидны – мы можем без всяких конструкторов создать любую печатную форму, отобразить ее в браузере или распечатать.
Кроме того, HTML экспортируется в Word и Excel. Делается это просто — HTML сохраняется с расширением docx или xslx. Когда вы откроете файл, офис (по крайней мере Microsoft Office) сконвертирует его в нужный формат. Да, это плохо.
Но он прост, универсален и не требует специального кодирования.
В крайнем случае, вы всегда можете исправить это вручную в Excel. При желании можно конвертировать в pdf, но такие библиотеки, как TCPDF, чувствительны к верстке и стилизации, так что кому нужно, тот установит PDFCreator и будет рад. Однако с внедрением электронной отчетности и обмена электронными документами на первый план выходит экспорт-импорт, а не печать на бумаге, поэтому назначением печатных форм является главным образом быстрый просмотр документов на экране.
Хранилище аналитики Аналитические данные, связанные с синтетическими счетами в транзакциях.
Субконто в рамках 1С.
Реализация — одна таблица, которая по сути является таблицей фактов в ROLAP типа «звезда».
Ссылка на документ, синтетический счет (отдельная запись для каждого соответствующего счета - вид полупроводника), количество, сумма.
Дополнительные измерения – ссылки на основных хозяйствующих субъектов – контрагентов, партии товаров, сотрудников, кассовые счета.
Количество и сумма (в целых числах) по дебету пишутся с плюсом; за кредит - с минусом.
Это позволяет простым суммированием путем полного пересчета получить остатки и обороты за любой период в разрезе основных хозяйствующих субъектов без необходимости хранения промежуточных итогов.
Синтетические счета в проводках также рассчитываются.
Данная схема позволяет удалять, проводить и репроводить документы задним числом без пересчета результатов.
А также осуществлять авансирование, например, осуществив резервирование товара.
Отмечу, что хардкод синтетических счетов позволяет не отображать их номера на формах ввода первичных документов.
То есть, если пользователю нужен только складской учет, он может игнорировать учет или использовать его для управленческого учета.
Модульность То, чем страдает 1С.
В некотором смысле систему можно разделить на условную «платформу» и «конфигуратор».
Реальную структуру сайта, системные объекты и страницы можно считать платформой (ядром).
Объекты бизнес-логики – справочники, документы, отчеты и т.п.
можно подключать в любой комбинации.
Фактически каждый объект реализуется несколькими файлами.
Для самого сложного документа это 4 файла: шаблон входной страницы, php-файл — класс входной страницы (бэкенд), файл шаблона печатной формы и php-файл постоянной сущности (Entity), которая отвечает для сохранения документа в хранилище.
Файлы PHP и классы внутри них должны иметь общее «общее» имя.
Например, счет-фактура или отпуск товара.
Файлы копируются в заранее определенные папки.
Затем в админку добавляется новый пункт меню со ссылкой на это имя и название пункта меню соответственно Счет или Счет. При открытии главной страницы меню генерируется автоматически, группируется, если указано, и мы получаем своеобразную «конфигурацию».
При выборе пункта меню система находит заведомо незнакомый файл подкачки по его «родовому» названию, а затем подтягиваются шаблоны и печатные формы.
То есть прикладная часть программы собирается и пересобирается как конструктор Лего.
Воровать из офиса может даже непрограммист. сайт или любой ресурс, исправленный документ или отчет и загрузить его на сайт. Ну технически нет проблем с организацией автообновления.
Кстати, для одиночных пользователей, не умеющих разворачивать сайты, не проблема создать сборку на базе WAMP-сервера.
Может показаться, что предлагается какое-то низкоуровневое программирование — все жестко закодировать.
Но язык 1С по сути не более высокого уровня, чем PHP. Просто там манипулирование бизнес-данными осуществляется с помощью бизнес-объектов высокого уровня (документов, каталогов), что и предлагается сделать здесь.
Итак, суть в том, чтобы выкинуть по возможности все, что не связано с бизнес-логикой, сделать простым и универсальным все, что можно сделать просто и универсально.
На мой взгляд, этот подход является единственно конкурентоспособным, в отличие от попыток создания прямых функциональных аналогов 1С.
Конечно, созданная таким образом система вряд ли подойдет для серьезных решений.
Но большинство потребителей 1С — малый бизнес и вряд ли возникнет ситуация, что сервер не справится с обработкой данных, а поддержка системы гораздо проще и дешевле.
А работа программиста сейчас намного дороже, чем кусок памяти или процессор.
Теги: #php #открытый код #учетные системы #ERP #erp #1с #Разработка сайтов #открытый код #php #1С-Битрикс
-
Windows 8: Нравится Вам Это Или Нет!
19 Oct, 24 -
Ноутбук Thinkpad-Nv32Ttx От Lenovo
19 Oct, 24 -
«Теперь Каждый Может Стать Инвестором»
19 Oct, 24 -
Постиндустриальный Или Продакшн 2.0
19 Oct, 24 -
Geek Picnic — Пленэр Для Айтишников
19 Oct, 24 -
Javarss Взломан
19 Oct, 24 -
Милый И Умный Робот Apripoko От Toshiba.
19 Oct, 24 -
Хабр-Организм (Философский)
19 Oct, 24
