Эта статья будет рассказывать как организовать легкое проектирование бизнес логики веб-сервиса в базе данных на встроенном PL-SQL.

Я расскажу как сделать простой сервис ретранслятор для фронтенда (пример будет на php), а так же как легко проектировать в базе аналог API и регистрировать это для ретрансляции фронтенду.

Недавно у меня возник вопрос, насколько законно передать автоматизированной системе право подписи документов от лица генерального директора.

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

Графики работ сотрудников неотъемлемая часть любой CRM системы. Но в зависимости от специфики бизнеса клиента они могут очень отличаться. В клинике это графики приема пациентов, в телекоме – графики подключения клиентов, в школе – графики занятий. Все они отличаются по структуре и сути. У них разные шапки, разный набор полей, разные сетки.

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

До этого графики были некой штукой разработанной на php. Но боже! Карл! Каждый раз, когда нужен новый график под какое-то нишевое решение, надо этот код копировать, перерабатывать. Индивидуальность графиков не позволяла что-то централизованно изменить. Да и в целом подрывало концепцию нашей облачной платформы в том, что клиент может самостоятельно ее конфигурировать.

В этой статье я расскажу про функциональные классы ERP-CRM систем, постараюсь описать, что же такое система ERP-Платформа, какую занимает нишу и как же правильно организовать структуру системы.



В статье я будут рассказывать только об облачных системах. Где пользователь зашел, зарегистрировался, и пользуется. Коробочные системы — отдельная тема.
Облачные системы популярны, доступны. С ними просто знакомиться, ежемесячные платежи небольшие.
Для некоторых компаний облако неприемлемо. Они хотят работать на своем оборудовании, в своей закрытой сети. Так спокойнее. Но знакомятся с системой перед покупкой опять же в облаке. Из облачной всегда можно сделать коробку, а вот из коробки облачную не всегда.

Различных облачных ERP-CRM систем много. Я бы все разделил на 4 типа:
1) Статичные
2) Статичные+
3) Полу динамичные
4) Динамичные

Поступил от клиента запрос: «xотим конфигуратор отчетов».Чтобы простые сотрудники, далекие от SQL, могли составлять всевозможные, необходимые для них отчеты, по любым данным в системе.
Абстрактно идея понятна. Но вот как же конкретно это должно выглядеть?

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

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

Идеальный конфигуратор отчетов будет понятен простому пользователю и при этом поддерживает создание отчетов любого уровня сложности.

Цель написания статьи – популяризировать использование Простой электронной подписи (пЭП) в документах. Чем больше людей пользуется, тем более популярен механизм, тем меньше у всех страхов, подозрений и вопросов. Очень удобно, подписал счет и акты пЭП и передал по email в бухгалтерию контрагента.

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


Более того, при наличии своего сервиса проверки, пЭП гарантирует достоверность подписи, в отличии от собственноручной подписи. Например третьему лицу, взявшему в руки документ, неизвестно, закорючка напротив ФИО это реальная подпись того человека или нет. А здесь зашел на указанный сервис, вбил номер подписи и ты точно знаешь, что именно данный документ подписал именно данный человек.

Как сделать такой сервис проверки, и как организовать свою пЭП и будет описано в данной статье.

Уважаемые читатели. Это третья статья из цикла по базам данных.

Оглавление:

1. Как сделать разный часовой пояс в разных базах данных на одном сервере.
2. Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных (чтобы база основная база данных не забивалась мусором и не росла)
3. Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно. Вопросы эффективности хранения файлов (как получить максимальное быстродействие и при этом минимальное занимаемое место)

Данный способ – способ реализации хранения файлов, приложенных пользователем на сайте, через веб интерфейс. Это не будет “файловой системой” в том понимании как это организовано в операционной системе.

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

Сразу замечу, что данный способ, с точки зрения быстродействия, менее эффективен простого сохранения файлов на веб-сервере. Но он имеет определенные преимущества, которые в моем случае перевесили недостатки потери скорости загрузки.

Уважаемые читатели. Это вторая статья из цикла по базам данных. Решил сделать некоторое оглавление по планируемым статьям этого цикла:

1. Как сделать разный часовой пояс в разных базах данных на одном сервере.
2. Как вести логи изменений данных пользователями в базе данных, сохраняя их в другой базе данных, для того чтобы основная база данных не забивалась мусором и не росла.
3. Как создать свою файловую систему на основе blob полей в базе данных. Почему это удобно. Вопросы эффективности хранения файлов: как получить максимальное быстродействие и при этом минимальное занимаемое место.

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

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

Итак начнем.

База данных firebird 3.

Формулировка задачи следующая: необходимо писать подробные логи изменений данных пользователями в базе данных (insert, update, delete), но при этом писать их в другой базе данных на другом сервере. Необходимо это для того чтобы размер основной базы данных не рос как на дрожжах, ее удобно было бекапить, ресторить, чтобы она работала быстро, не накапливала мусора, не содержала лишней и редконужной информации.

Уважаемые Хабравчане, решил поделиться с Вами техническим решением некоторых интересных и на первый взгляд не очевидных проблем. Всю жизнь я в основном только черпал информацию, читал замечательные статьи (в том числе на Хабре) очень помогавшие мне в решении тех или иных технических проблем. Но в последние 2 года, занявшись разработкой своей облачной платформы для автоматизации предприятий, мне пришлось решать довольно много задач “впервые”, т.е. которые если кто-то и решал, то описания (даже близко) я не находил. В связи с этим я решил написать 3 цикла статей: цикл по базам данных, цикл по безопасности и цикл по системам автоматизации. Эта статья — первая статья первого цикла.

Краткая формулировка задачи: каким-то образом current_date, current_time и current_timestamp должны выдавать дату-время в зависимости от настроек в аккаунте пользователя и при этом на самом сервере будет стоять московское время.

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