По идее материал должен был бы быть в хабе «Я пиарюсь» но я подумал что тру-программистов обычно интересует не чужой код а как написать свое.
Поскольку задача написания «аналогов» и «альтернатив» 1С нетривиальная, есть смысл изложить свое видение и ключевые моменты на основе опыта написания учетной системы ZippyERP.
Сразу уточню, что речь будет идти не об энтерпрайз решении а об автоматизации малого бизнеса. Это чтобы не возникали вопросы — отработает ли оно триллиард обращений в микросекунду.
По факту, на данный момент 1С занимает подавляющий сегмент в нише учетных систем. Это объясняется рядом причин, в том числе и агрессивным маркетингом. Напомню техническую сторону. 1С в общем виде, состоит как бы из двух физически отдельных частей — собственно платформы (ядра, движка) и так называемой конфигурации. Конфигурация — это та часть, где собственно и реализуется прикладная бизнес-логика. Платформа предоставляет персистентное хранилище, бизнес-объекты высокого уровня, всякого рода конструкторы и построители отчетов, и специальный язык программирования. Но сама по себе технологическая платформа, даже с такими возможностями, не имела бы успеха. Поэтому конфигурация поставляется с уже написанной логикой — бухучет, торговля, склад и т.д. с учетом действующего законодательства. Это достаточно объемный труд, но в результате пользователь получает готовое законченное решение. А поскольку код самой конфигурации открыт, то остается возможность, как угодно корректировать бизнес-логику и подстраивать под свой бизнес.
Это плюсы. Но есть и масса минусов. Чтобы не описывать тут можно почитать например здесь.
Попыток вытеснить 1С предпринимается великое множество. Большинство проектов пытается переплюнуть плюсы 1С. Тягаться с огромной корпорацией дело малоперспективное. Продукты, писанные на Делфи или .NET, то есть требующие перекомпиляции, вообще неконкурентные, те, кто пытаются прикручивать в качестве DSL движки javascript или VBA выглядят чуть получше, но в любом случает такие решения могут использоваться в основном если есть штатный программист, чего малый бизнес, как правило, позволить себе не может.
Попробуем подобраться с другой стороны. Не пытаться переплюнуть достоинства 1С а предложить решения тех проблем где 1С имеет минусы.
Поскольку минусы где то уравновешивают плюсы а у нас этих минусов не будет то, даже если у нас не будет плюсов на уровне 1С, сальдо примерно будет такое же.
Итак, какие характеристики должны быть у системы.
Тут объяснений не требуется.
Многопользовательский режим с возможностью прямого доступа с мобильных устройств без необходимости писать специальных клиентов, синхронизировать справочники и т.д.
Язык с низким порогом вхождения, знакомый большинству веб разработчиков. Для внесения изменений требуется только текстовый редактор. Веб приложение легко обновляется заменой отдельных файлов (привет конфигуратору 1С). Скриптовый слаботипизированный язык в сочетании с набором высокоуровневых бизнес-объектов хорошо подходит для написания бизнес-логики.
Казалось бы, что еще нужно для счастья. Тем не менее, в реальности опенсорс учетные системы — это, как правило, кривое портирование забугорных разработок.
Причем кривое не только локализацией. Для приведения к отечественному законодательству требуется немалый труд. Но и это не все. Бухгалтер, глядя на страницу такой системы, не будет понимать для чего половина полей и вообще как тут работать. Не забываем, что пользователь наверняка уже имеет опыт с 1С и наверняка это его единственный опыт работы с учетной системой. Это означает, что из сотни способов сделать макет страницы ввода накладной и подписать элементы ввода нужно выбирать тот, который по максимуму напоминает 1С (а значит надо перелопатить все страницы забугорного творения).
Когда я давал фрилансерам заполнять свою систему демо данными (типа как демо — конфигурация в 1С) ни разу не возник вопрос — а как тут работать.
Более глобальная проблема — переусложнение системы. Думаю, это основная причина, из-за которой проекты не доводятся до ума.
Программист обычно делает систему максимально гибкой (а как же иначе!) тратит две трети времени на написание многочисленных настроек, визардов, генераторов или того хуже тулсов для командной строки и т.д.
Пользователь, тетенька-бухгалтер, не будучи айтишницей, с тоской смотрит на все это добро, не понимая, почему нельзя просто поставить пару кнопок. Затем звонит программисту, чтобы он пришел, настроил программу после очередного приказа минфина. Программист искренне негодует, что за тупой пользователь, неужели сложно разобраться с парой десятков чекеров и комбобоксов. Правда его запал утихает, когда оказывается, что настройкой тут не обойдешься и теперь надо продираться сквозь дебри инфраструктурного кода, обеспечивающего пресловутую гибкость.
Примером является и сама 1С — от версии 2.0, где бухгалтера действительно вводили формулы на специальном «птичьем» языке до
монстра 8.3. Попробуйте дать мануал непосвященному и посчитайте с какой попытки он врубится в витиеватую словесную конструкцию «план видов характеристик».
Отсюда вытекает следующая идея. Раз уж все равно приглашать программиста и стоимость работы этого программиста пропорциональна навороченности системы то зачем ее наворачивать. Не проще ли выкинуть все, что от лукавого и дать возможность программисту работать только с бизнес-логикой, потому как реализация бизнес-логики собственно и есть задача программы.
Поясню на примере. План счетов бухучета. Меняется крайне редко. Настраивается один раз при внедрении программы и, как правило, не меняется в процессе работы (напоминаю речь не о энтерпрайз системах). Возможно, когда-то и понадобится добавить какой субсчет. Но под него наверняка надо скорректировать и код, а значит, звать программиста. Но программист за две секунды воткнет новую запись в план счетов с помощью обычного phpMyAdmin и незачем писать редактор и заставлять юзера указывать наперед неизвестные счета в формах ввода первичных документов.
Таким образом можно оставить только реально нужные и, главное понятные пользователю, настройки бизнес-логики — адреса, ставки налогов и т.д.
Вот основная идеология, которая, по моему мнению, должна присутствовать в реализации данного класса задач.
По такому принципу реализуется ZippyERP.
В основе проекта компонентный, а не MVC фреймворк, что позволяет программисту не заботиться о сохранении состояния страницы после перезагрузки, не думать как там происходит обмен данными между фронтэндом и бекэндом. Кто програмировал с WebForms тот помнит — на фронтэнде ссылка, на бэкенде событие по нажатию, в котором пишется бизнес-логика.
Высокоуровневые бизнес-объекты — документы, контрагенты и прочие бизнес-сущности реализованы на основе паттерна Active Record ( с некоторыми элементами ORM). SQL запросы генерятся автоматически с помощью библиотеки ADODB.
То есть, если например, нужно изменить имя контрагента код выглядит примерно так:
Получить список поставщиков
Минимальный код для обеспечения подобной функциональности
Иными словами, сделано все, чтобы программист работал с бизнес-логикой а не тратил время на рутинные задачи обмена данными с фронтэндом или с БД. То есть, по сути программируется примерно так же как и в модулях документов 1С, только на PHP.
А теперь некоторые общие технические идеи, которые могут пригодиться «велосипедистам» при написании собственного «убийцо» 1С.
Типичный вопрос на форумах, задаваемый писателями CRM, учетных, складских систем и систем документооборота. Как хранить документы, которые очевидно, имеют разнородную структуру. Отдельная таблица под каждый тип документа, общая таблица с кучей универсальных полей, модные нынче NoSQL хранилища…
ZippyERP хранит всю первичку в одной таблице в блобе, упакованными в XML. Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус. Упаковка в XML имеет преимущество перед сериализацией или json — каждое значение обрамлено именованным тегом, а значит, можно выполнять сквозной поиск, не натыкаясь не лишние строки. То есть найти ссылку на контрагента по
Кроме того, в системе широко используется денормализация. Например, в документ пишется не только id контрагента а и его наименование, которое предъявляется пользователю. Много есть не просит, зато позволяет обойтись без джойнов к другим таблицам и использования «исторических» атрибутов.
Просто HTML. Плюс простой, но функциональный шаблонизатор Fenom.
Преимущества очевидны — можем создать любую печатную форму без всяких построителей, отобразить ее в браузере или распечатать. Кроме того, HTML экспортируется в Word и Excel. Делается это просто — HTML сохраняется с расширением docx или xslx. При открытии файла офис (во всяком случае, майкрософтовский) сам сконвертит в нужный формат. Да, убого. Но зато просто, универсально и не требует специального кодирования. Была даже мысль конвертить в pdf но библиотеки типа TCPDF чувствительны к верстке и стилизации посему, кому надо, поставит PDFCreator и будет ему счастье.
Впрочем, с введением электронной отчетности и обмена электронными документами на первый план выходит экспорт-импорт а не печать на бумаге.
Аналитические данные, связанные с синтетическими счетами в проводках. Субконто в терминах 1С. Реализация — одна таблица, по сути представляющая собой таблицу фактов в ROLAP типа звезда. Ссылка на документ, синтетический счет (отдельная запись на каждый корреспондирующий счет), количество, сумма. Дополнительные измерения — ссылки на основные бизнес сущности — контрагенты, партии товаров, сотрудники, денежные счета. Количество и сумма (отмасштабированные в целые числа) для дебета пишутся с плюсом для кредита — с минусом. Это позволяет простым суммированием путем полного пересчета получать остатки и обороты на любой период в разрезах основных бизнес-сущностей без необходимости хранить промежуточные итоги. Так же просчитываются и синтетические счета в проводках.
Такая схема позволяет удалять, проводить и перепроводить документы задним числом без пересчета итогов. А также проводить передним числом, например, реализовывая резервирование товаров.
Замечу, что хардкод синтетических счетов позволяет не выставлять номера на формы ввода первичных документов. То есть, если пользователю нужен только складской учет он может не обращать внимания на бухгалтерию или использовать ее для управленческого учета.
То, отсутствием чего страдает 1С. В некотором смысле структура ZippyERP напоминает разделение на «платформу» и «конфигуратор». Собственно структуру сайта, системные объекты и страницы можно считать платформой (ядром). Объекты бизнес логики — справочники, документы, отчеты и т.д могут быть подключены в произвольном сочетании. По сути каждый объект реализуется несколькими файлами. Для самого сложного — документа это 4 файла: шаблон страницы ввода, php файл — класс страницы ввода (бек-енд), файл шаблона печатной формы и php файл персистентной сущности (Entity), отвечающий за сохранение документа в хранилище. Файлы и классы PHP в них должны иметь общее «родовое» имя. Например, invoice или goodsissue. Файлы копируются в предопределенные папки. Затем в админпанели добавляется новый пункт меню со ссылкой на это имя и наименованием пункта меню, соответственно Счет или Накладная. При открытии основной страницы меню генериться автоматически, группируется, если указано, и получаем как бы конфигурацию. То есть, прикладная часть программы собирается и пересобирается как конструктор Lego. Даже непрограммист может стащить с оф. сайта или какого ресурса исправленный документ или отчет и закинуть на сайт. Ну и технически нет проблем организовать автообновление.
Кстати, для одиночных пользователей, не умеющих разворачивать сайты, предусмотрена сборка на основе WAMP сервера.
Система пока в разработке но, поскольку задача публикации — предложить свое видение решения данного класса проектов, это не принципиально.
Собственно «платформа» готова, речь о добавлении кирпичиков «Lego» для формирования рабочей версии «конфигуратора». Добавление новых документов или отчетов не требует изменений в БД. Таблицы для основных бизнес-сущностей уже созданы, справочные данные запаковываются в XML аналогично документам а значит, добавление новых полей в справочник не требует изменения структуры БД.
Кому то может показаться, что где то неоптимизированно, что не хватает каких фич, что примитивно. Но в этом и смысл — выкинуть по возможности все, что не относится к бизнес логике, сделать простым и универсальным все, что можно сделать просто и универсально. На мой взгляд, такой подход единственно конкурентоспособен, в отличие от попыток создавать прямые функциональные аналоги 1С.
Поскольку система предназначена для малого бизнеса (большинство потребителей 1С) вряд ли возникнет ситуация что сервер не справляется объемом данных, зато саппорт системы на порядок проще и дешевле. А труд программиста нынче гораздо дороже куска памяти или процессора.
Домашняя страница здесь, репозитарий на гитхабе, демо страница (не последняя версия, но можно посмотреть в принципе как выглядит) здесь (admin admin).
Поскольку задача написания «аналогов» и «альтернатив» 1С нетривиальная, есть смысл изложить свое видение и ключевые моменты на основе опыта написания учетной системы ZippyERP.
Сразу уточню, что речь будет идти не об энтерпрайз решении а об автоматизации малого бизнеса. Это чтобы не возникали вопросы — отработает ли оно триллиард обращений в микросекунду.
По факту, на данный момент 1С занимает подавляющий сегмент в нише учетных систем. Это объясняется рядом причин, в том числе и агрессивным маркетингом. Напомню техническую сторону. 1С в общем виде, состоит как бы из двух физически отдельных частей — собственно платформы (ядра, движка) и так называемой конфигурации. Конфигурация — это та часть, где собственно и реализуется прикладная бизнес-логика. Платформа предоставляет персистентное хранилище, бизнес-объекты высокого уровня, всякого рода конструкторы и построители отчетов, и специальный язык программирования. Но сама по себе технологическая платформа, даже с такими возможностями, не имела бы успеха. Поэтому конфигурация поставляется с уже написанной логикой — бухучет, торговля, склад и т.д. с учетом действующего законодательства. Это достаточно объемный труд, но в результате пользователь получает готовое законченное решение. А поскольку код самой конфигурации открыт, то остается возможность, как угодно корректировать бизнес-логику и подстраивать под свой бизнес.
Это плюсы. Но есть и масса минусов. Чтобы не описывать тут можно почитать например здесь.
Попыток вытеснить 1С предпринимается великое множество. Большинство проектов пытается переплюнуть плюсы 1С. Тягаться с огромной корпорацией дело малоперспективное. Продукты, писанные на Делфи или .NET, то есть требующие перекомпиляции, вообще неконкурентные, те, кто пытаются прикручивать в качестве DSL движки javascript или VBA выглядят чуть получше, но в любом случает такие решения могут использоваться в основном если есть штатный программист, чего малый бизнес, как правило, позволить себе не может.
Попробуем подобраться с другой стороны. Не пытаться переплюнуть достоинства 1С а предложить решения тех проблем где 1С имеет минусы.
Поскольку минусы где то уравновешивают плюсы а у нас этих минусов не будет то, даже если у нас не будет плюсов на уровне 1С, сальдо примерно будет такое же.
Итак, какие характеристики должны быть у системы.
Open source. Кросплатформенность.
Тут объяснений не требуется.
Веб приложение.
Многопользовательский режим с возможностью прямого доступа с мобильных устройств без необходимости писать специальных клиентов, синхронизировать справочники и т.д.
PHP
Язык с низким порогом вхождения, знакомый большинству веб разработчиков. Для внесения изменений требуется только текстовый редактор. Веб приложение легко обновляется заменой отдельных файлов (привет конфигуратору 1С). Скриптовый слаботипизированный язык в сочетании с набором высокоуровневых бизнес-объектов хорошо подходит для написания бизнес-логики.
Казалось бы, что еще нужно для счастья. Тем не менее, в реальности опенсорс учетные системы — это, как правило, кривое портирование забугорных разработок.
Причем кривое не только локализацией. Для приведения к отечественному законодательству требуется немалый труд. Но и это не все. Бухгалтер, глядя на страницу такой системы, не будет понимать для чего половина полей и вообще как тут работать. Не забываем, что пользователь наверняка уже имеет опыт с 1С и наверняка это его единственный опыт работы с учетной системой. Это означает, что из сотни способов сделать макет страницы ввода накладной и подписать элементы ввода нужно выбирать тот, который по максимуму напоминает 1С (а значит надо перелопатить все страницы забугорного творения).
Когда я давал фрилансерам заполнять свою систему демо данными (типа как демо — конфигурация в 1С) ни разу не возник вопрос — а как тут работать.
Более глобальная проблема — переусложнение системы. Думаю, это основная причина, из-за которой проекты не доводятся до ума.
Программист обычно делает систему максимально гибкой (а как же иначе!) тратит две трети времени на написание многочисленных настроек, визардов, генераторов или того хуже тулсов для командной строки и т.д.
Пользователь, тетенька-бухгалтер, не будучи айтишницей, с тоской смотрит на все это добро, не понимая, почему нельзя просто поставить пару кнопок. Затем звонит программисту, чтобы он пришел, настроил программу после очередного приказа минфина. Программист искренне негодует, что за тупой пользователь, неужели сложно разобраться с парой десятков чекеров и комбобоксов. Правда его запал утихает, когда оказывается, что настройкой тут не обойдешься и теперь надо продираться сквозь дебри инфраструктурного кода, обеспечивающего пресловутую гибкость.
Примером является и сама 1С — от версии 2.0, где бухгалтера действительно вводили формулы на специальном «птичьем» языке до
монстра 8.3. Попробуйте дать мануал непосвященному и посчитайте с какой попытки он врубится в витиеватую словесную конструкцию «план видов характеристик».
Отсюда вытекает следующая идея. Раз уж все равно приглашать программиста и стоимость работы этого программиста пропорциональна навороченности системы то зачем ее наворачивать. Не проще ли выкинуть все, что от лукавого и дать возможность программисту работать только с бизнес-логикой, потому как реализация бизнес-логики собственно и есть задача программы.
Поясню на примере. План счетов бухучета. Меняется крайне редко. Настраивается один раз при внедрении программы и, как правило, не меняется в процессе работы (напоминаю речь не о энтерпрайз системах). Возможно, когда-то и понадобится добавить какой субсчет. Но под него наверняка надо скорректировать и код, а значит, звать программиста. Но программист за две секунды воткнет новую запись в план счетов с помощью обычного phpMyAdmin и незачем писать редактор и заставлять юзера указывать наперед неизвестные счета в формах ввода первичных документов.
Таким образом можно оставить только реально нужные и, главное понятные пользователю, настройки бизнес-логики — адреса, ставки налогов и т.д.
Вот основная идеология, которая, по моему мнению, должна присутствовать в реализации данного класса задач.
По такому принципу реализуется ZippyERP.
В основе проекта компонентный, а не MVC фреймворк, что позволяет программисту не заботиться о сохранении состояния страницы после перезагрузки, не думать как там происходит обмен данными между фронтэндом и бекэндом. Кто програмировал с WebForms тот помнит — на фронтэнде ссылка, на бэкенде событие по нажатию, в котором пишется бизнес-логика.
Высокоуровневые бизнес-объекты — документы, контрагенты и прочие бизнес-сущности реализованы на основе паттерна Active Record ( с некоторыми элементами ORM). SQL запросы генерятся автоматически с помощью библиотеки ADODB.
То есть, если например, нужно изменить имя контрагента код выглядит примерно так:
$customer = Customer::load(12);
$customer ->name ="Вася Пупкин";
$customer->save();
Получить список поставщиков
$customers = Customer::find("seller=1");
foreach($customers as $customer) {
}
Минимальный код для обеспечения подобной функциональности
/**
*
* @table=erp_customer
* @view=erp_customer_view
* @keyfield=customer_id
*/
class Customer extends \ZCL\DB\Entity
{
}
Иными словами, сделано все, чтобы программист работал с бизнес-логикой а не тратил время на рутинные задачи обмена данными с фронтэндом или с БД. То есть, по сути программируется примерно так же как и в модулях документов 1С, только на PHP.
А теперь некоторые общие технические идеи, которые могут пригодиться «велосипедистам» при написании собственного «убийцо» 1С.
Хранение документов
Типичный вопрос на форумах, задаваемый писателями CRM, учетных, складских систем и систем документооборота. Как хранить документы, которые очевидно, имеют разнородную структуру. Отдельная таблица под каждый тип документа, общая таблица с кучей универсальных полей, модные нынче NoSQL хранилища…
ZippyERP хранит всю первичку в одной таблице в блобе, упакованными в XML. Отдельно — только общие поля, которые показываются в списках и журналах — номер документа, дата создания, автор, статус. Упаковка в XML имеет преимущество перед сериализацией или json — каждое значение обрамлено именованным тегом, а значит, можно выполнять сквозной поиск, не натыкаясь не лишние строки. То есть найти ссылку на контрагента по
<contragent>12</contragent>Кроме того, в системе широко используется денормализация. Например, в документ пишется не только id контрагента а и его наименование, которое предъявляется пользователю. Много есть не просит, зато позволяет обойтись без джойнов к другим таблицам и использования «исторических» атрибутов.
Печатные формы документов и отчетов.
Просто HTML. Плюс простой, но функциональный шаблонизатор Fenom.
Преимущества очевидны — можем создать любую печатную форму без всяких построителей, отобразить ее в браузере или распечатать. Кроме того, HTML экспортируется в Word и Excel. Делается это просто — HTML сохраняется с расширением docx или xslx. При открытии файла офис (во всяком случае, майкрософтовский) сам сконвертит в нужный формат. Да, убого. Но зато просто, универсально и не требует специального кодирования. Была даже мысль конвертить в pdf но библиотеки типа TCPDF чувствительны к верстке и стилизации посему, кому надо, поставит PDFCreator и будет ему счастье.
Впрочем, с введением электронной отчетности и обмена электронными документами на первый план выходит экспорт-импорт а не печать на бумаге.
Хранение аналитики
Аналитические данные, связанные с синтетическими счетами в проводках. Субконто в терминах 1С. Реализация — одна таблица, по сути представляющая собой таблицу фактов в ROLAP типа звезда. Ссылка на документ, синтетический счет (отдельная запись на каждый корреспондирующий счет), количество, сумма. Дополнительные измерения — ссылки на основные бизнес сущности — контрагенты, партии товаров, сотрудники, денежные счета. Количество и сумма (отмасштабированные в целые числа) для дебета пишутся с плюсом для кредита — с минусом. Это позволяет простым суммированием путем полного пересчета получать остатки и обороты на любой период в разрезах основных бизнес-сущностей без необходимости хранить промежуточные итоги. Так же просчитываются и синтетические счета в проводках.
Такая схема позволяет удалять, проводить и перепроводить документы задним числом без пересчета итогов. А также проводить передним числом, например, реализовывая резервирование товаров.
Замечу, что хардкод синтетических счетов позволяет не выставлять номера на формы ввода первичных документов. То есть, если пользователю нужен только складской учет он может не обращать внимания на бухгалтерию или использовать ее для управленческого учета.
Модульность.
То, отсутствием чего страдает 1С. В некотором смысле структура ZippyERP напоминает разделение на «платформу» и «конфигуратор». Собственно структуру сайта, системные объекты и страницы можно считать платформой (ядром). Объекты бизнес логики — справочники, документы, отчеты и т.д могут быть подключены в произвольном сочетании. По сути каждый объект реализуется несколькими файлами. Для самого сложного — документа это 4 файла: шаблон страницы ввода, php файл — класс страницы ввода (бек-енд), файл шаблона печатной формы и php файл персистентной сущности (Entity), отвечающий за сохранение документа в хранилище. Файлы и классы PHP в них должны иметь общее «родовое» имя. Например, invoice или goodsissue. Файлы копируются в предопределенные папки. Затем в админпанели добавляется новый пункт меню со ссылкой на это имя и наименованием пункта меню, соответственно Счет или Накладная. При открытии основной страницы меню генериться автоматически, группируется, если указано, и получаем как бы конфигурацию. То есть, прикладная часть программы собирается и пересобирается как конструктор Lego. Даже непрограммист может стащить с оф. сайта или какого ресурса исправленный документ или отчет и закинуть на сайт. Ну и технически нет проблем организовать автообновление.
Кстати, для одиночных пользователей, не умеющих разворачивать сайты, предусмотрена сборка на основе WAMP сервера.
Система пока в разработке но, поскольку задача публикации — предложить свое видение решения данного класса проектов, это не принципиально.
Собственно «платформа» готова, речь о добавлении кирпичиков «Lego» для формирования рабочей версии «конфигуратора». Добавление новых документов или отчетов не требует изменений в БД. Таблицы для основных бизнес-сущностей уже созданы, справочные данные запаковываются в XML аналогично документам а значит, добавление новых полей в справочник не требует изменения структуры БД.
Кому то может показаться, что где то неоптимизированно, что не хватает каких фич, что примитивно. Но в этом и смысл — выкинуть по возможности все, что не относится к бизнес логике, сделать простым и универсальным все, что можно сделать просто и универсально. На мой взгляд, такой подход единственно конкурентоспособен, в отличие от попыток создавать прямые функциональные аналоги 1С.
Поскольку система предназначена для малого бизнеса (большинство потребителей 1С) вряд ли возникнет ситуация что сервер не справляется объемом данных, зато саппорт системы на порядок проще и дешевле. А труд программиста нынче гораздо дороже куска памяти или процессора.
Домашняя страница здесь, репозитарий на гитхабе, демо страница (не последняя версия, но можно посмотреть в принципе как выглядит) здесь (admin admin).