• ____
• SL-Trade
• Manufacture
• SL-Building
• SL-Finance
• SL-Insurance
• SL-RedCross
• 

Общие положения
Репликация информации между территориально удаленными базами данных SL-REP
Система управления взаимоотношениями с клиентами SL-CRM
Подсистема работы с графикой SL-Graphics

Общие положения
(Примеры работы с системой)

Принципы построения SL, в общем виде, объясняются двумя схемами, приведенными ни-же.

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

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

Система SL реализует объектно-ориентированную модель деятельности предприятия.

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

А именно:

1. Система позволяет произвольному количеству различных субъектов спланировать свою деятельность по преобразованию или возмездной передаче друг другу произвольного числа объектов материального мира (или их частей) в рамках дерева договоров и учесть реализацию этих планов путем ведения журнала первичных документов.
   
   
2. Все субъекты, известные системе, сведены в единый иерархический справочник контрагентов, но отличаются друг от друга классом. Таким образом, с одной стороны достигается унификация использования информации о контрагентах разных типов там, где тип контрагента не имеет значения (например, можно одинаково просто заключить договор как со сторонним юр.лицом, так и со своим наемным рабочим). С другой имеется возможность корректно проводить обработку специфической для каждого типа контрагентов информации (например, у физ.лица есть удостоверение личности, а у собственного подразделения нет).
   
   На данный момент SL делит всех контрагентов на следующие:
   • Внешние контрагенты:
     • Физические лица;
     • Юридически Лица;
     • Индивидуальные Предприниматели;
     • Сотрудники собственных фирм (пользователи ИС);
   • Собственные подразделения:
     • Фирмы собственные;
     • Группы собственных фирм;
     • Кассы;
     • Банки;
     • Склады;
     • Отделы;
     • Бригады;
   • Должности в собственных подразделениях (с возможностью настройки прав доступа);
   
   
   
3. Любой контрагент имеет свой учетный регистр, и может содержать на подотчете как товарные, так и денежные средства (выступать в виде импровизированного склада). Следовательно, по каждому контрагенту, можно иметь баланс взаиморасчетов с фирмой по различным видам взаимодействий.
   
   
4. Описание всех объектов учета, имеющих материальную ценность, вне зависимости от их сложности и структуры, хранится в едином иерархическом номенклатурном справочнике. Поскольку объекты могут иметь колоссальную разницу по своим физическим свойствам, мы разработали уникальную структуру данных (иерархический классификатор объектов), позволяющую делить объекты на различные классы и задавать собственный набор свойств, - для каждого из таких классов.
   
   
5. Товарно-денежные отношения между контрагентами, как правило, оформляться договорами/контрактами. Договора «рамочного» типа (планы/бюджеты) могут включать поддоговора, т.е. имеют иерархическую структуру. На нижних уровнях дерева договоров всегда размещаются фактические (юридические) договора между контрагентами. Все взаиморасчеты между контрагентами учитываются только в рамках фактических договоров; Способ построения дерева договоров произвольный и зависит, по большей части, от выбранной модели Управленческого учета заказчика. Например, можно строить дерево по административному принципу, когда для каждой собственной фирмы создается отдельное поддерево, а можно по функциональному, когда сначала создаются узлы, разделяющие договора на функциональные группы, а ниже, под ними идет разделение договоров по разным фирмам..
   
   
6. Каждое парное товарно-денежное взаимодействие контрагентов (передача денег и/или товара) обязательно оформляется отдельным первичным документом в рамках некоторого фактического договора (в документ автоматически вносится ссылка на фактический договор). Документы всех типов хранятся в едином журнале документов с возможностью быстрой фильтрации требуемого документа по виду, дате, контрагенту, статусу, номеру, договору и т.д. из списка разрешённых пользователю.
   
   
7. В системе создается и хранится необходимое число элементарных таблиц-справочников, позволяющее без многократного дублирования хранить единицы измерения, валюты, и прочие атрибуты, встречающиеся в документах, договорах и т.д.
   
   

Пункты 2-4 заметно отличают нашу систему от КОНКУРИРУЮЩИХ.

Репликация информации между территориально удаленными базами данных SL-REP

Поскольку предприятие-заказчик может иметь территориально удаленные подразделения, SL предлагает гибкий сервис по обмену и совмещению данных между распределенными БД SL-REP. Термин «гибкий» в данном контексте означает, что заказчик может получить как 100% репликацию удаленных баз (во всех базах будет одинаково храниться вся информация), так и выборочный одно/двунаправленный обмен между каждой парой БД (например, все справочники экспортируются из центральной корпоративной базы в периферийные, а документы наоборот).

В процессе реализации подсистемы совмещения данных, приходящих из разных БД, перед разработчиками всегда встает вопрос – как обеспечить уникальность и, следовательно, распознаваемость данных в условиях одновременного создания документов в разных базах?

Вопрос может решаться по-разному. Например, встроенная в Microsoft SQL подсистема совмещения данных основана на 40-байтном ключе, заносимом в каждую строку данных. Такой ключ гарантирует уникальность записи при любых размерах базы, но он обрабатывается в несколько раз медленней, чем 4-байтный стандартный ключ СУБД, накладывая жесткие требования на аппаратную мощность сервера, либо работает весьма медленно. Но все-таки быстрее, чем функция импорта данных, входящая в стандартную конфигурацию фирмы 1С, которая откровенно тормозит, причем импорт 30000 записей в товарный каталог (из текстового файла) может идти более 8 часов и закончиться зависанием программы, а уникальность данных при многократной закачке одних и тех же данных (например, по ошибке) не гарантируется вообще и приводит к дублированию информации…

SL-REP использует оригинальный алгоритм, позволяющий добиться уникальности стандартных 4-х байтовых ключей. Ключи в каждой базе выбираются из отдельного диапазона значений. Таким образом, мы добились эффективного способа совмещения данных, созданных в разнесенных БД, а пользователи SL могут иметь многократную экономию при подборе серверного оборудования, необходимого для ее эксплуатации.

Система управления взаимоотношениями с клиентами SL-CRM
(Примеры работы с системой)

В условиях жесткой конкуренции предприятиям приходится бороться за каждого клиента – повышать уровень обслуживания, предлагать все новые и новые услуги. У крупной компании может быть много клиентов реальных и потенциальных. Но не всегда очевидно, кто выгоден для компании, а кто - нет, с кем надо работать по одной схеме, а с кем – «по другой».

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

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

Одной из отличительных особенностей подсистемы SL-CRM является возможность массовой рассылки информационных SMS, e-mail, ICQ сообщений подписчикам компании.

Подсистема работы с графикой SL-Graphics
(Примеры работы с системой)

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

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

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

Уникальность SL графических модулей состоит в тесной интеграции с другими подсистемами SL. Например, изменение положения стены дома в плане, автоматически приводит к пересчету строительной ресурсной сметы и стоимости помещений выбранного дома. А изменение сметы сразу влияет на план проведения строительных работ и т.д. Такой подход возможен по отношению к любому объекту номенклатурного справочника, но наиболее эффективен для действительно сложных изделий штучного или серийного производства – дом, судно, самолёт, станок…

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

В стадии разработки находится трехмерный модуль SL-3D представления строительного объекта. Модуль использует международный стандарт OpenGL (Open Graphics Library) для отображения 3D объектов. Что дает возможность заказчику посмотреть весь объект целиком – как снаружи, так и изнутри, «походить» по этажам, отсекам, подвигать стены, поменять элементы обшивки, на ходу посмотреть выполнение этапов работ, визуально оценить степень готовности объекта.

В настоящий момент в проектах заказчиков используются только SL-2D объекты, дающие более «привычное» и понятное современным строителям представление. Для работы с 3D представлением необходима специальная подготовка персонала.