65
Данная ситуация сложилась в силу того, что по факту до недавнего времени
в ООО «Агронефтепродукт» по факту существовала лишь система автоматизации
ведения бухгалтерского и кадрового учета. Вся остальная информация собиралась
буквально в произвольной форме и никаким образом, кроме ручного ввода, не
могла быть внесена и использована для формирования документов,
сопровождающих сделку в существующую ИС предприятия.
В упрощенном виде схема любого из двух отделов продаж компании
выглядела следующим образом:
Рисунок 15. Дерево функций между отделами
Как можно увидеть из схемы, при такой организации процесса, основная
нагрузка приходилось на бухгалтерию, зачастую вынуждая бухгалтеров
заниматься абсолютно не свойственным им задачами.
Роль менеджеров сводилась, помимо привлечения новых клиентов, лишь
приемке заказа от клиента и передачи информации в бухгалтерию (зачастую
путем звонка). Проверка контрагента, внесение информации о клиенте в ИБ и
подготовка пакета документов, в том числе путевых листов для логиста или
водителя оставалась на бухгалтере.
Внедрение нового продукта ведения комплексного учета, позволит
организовать более четкое и прозрачное протекание процесса сделки, при этом
четко разделив функции между участниками процесса, оставив бухгалтерии лишь
66
контролирующую функцию и окончательное проведение сделки в рамках
бухгалтерского учета.
Это позволит кардинально переосмыслить процесс работы отделов продаж
и взаимодействие вспомогательных служб между собой:
Рисунок 16. Сценарий диалога
Таким образом, благодаря появлению системы CRM, интегрированной в
комплексное решение новой ИС, контроль сделки полностью возлагается на
менеджера (от момента приема заказа, до непосредственно завершения сделки и
получения оригинала закрывающих документов от клиента, а также возможность
контроля логистики в случае необходимости). Модуль УТ (управление
торговлей), по факту позволяет оперативно проводить хозяйственные операции и
операции по товародвижению, в идеале, без участия бухгалтерии в формировании
первичных документов. Роль бухгалтера в данной схеме сводится к контролю
правильности оформления хозяйственной операции и отражении ее в
бухгалтерском учете. Модуль «Доставка» позволяет задействовать для работы с
ИС отделы логистики, тем самым частично или полностью автоматизируя
создание сопроводительных документов для службы доставки.
Как итог основной силой сопротивления среди сотрудников при внедрении
нового продукта будут являться сотрудники отделов продаж (в том числе и
руководство), так как степень их вовлеченности в процесс сопровождения сделки,
67
как и ответственность значительно возрастает, по сравнению со сложившимся
укладом.
Плюсом решения «Комплексная автоматизация 2.0» является тот факт, что
модули CRM, УТ, Доставка, Бухгалтерия, ЗУП и Финансовый мониторинг
интегрированы в рамках одной конфигурации платформы, что в свою очередь
позволяет организовать сквозное движение документов в рамках компании и
возможность контроля всех этапов сделки как со стороны руководства отдела, так
и непосредственно руководителем компании, в случае необходимости.
Но из этого вытекает главный минус данного решения: в случае
необходимости внесения изменений непосредственно в модули конфигурации,
значительно усложняется процесс обновления конфигурации, а сбой в одном из
модулей может парализовать работу всей системы. В силу данного недостатка
было принято решение о минимизации модификаций базовой конфигурации. Все
доработки стремится реализовать через механизм «Расширения конфигурации», а
также при помощи дополнительных внешних печатных форм и обработок.
В ходе общения с руководителем департамента ГСМ были выявлены
следующие основные потребности:
• Необходимо реализовать механизм учета плотности нефтепродукта в
документах «Заказ клиента», «Реализация товаров и услуг»;
• Реализовать механизм учета плотности в модуле ордерного склада;
• Реализовать механизм формирования путевых листов и ТТН;
• Реализовать формирование типовых печатных форм дополнительных
соглашений на поставку топлива в вариантах «по плотности», «по весу» и
«по плотности и весу»;
После анализа данных потребностей был сделан вывод о том, что все основные
потребности департамента ГСМ могут быть реализованы через механизм
«Расширения конфигурации» и внешних печатных форм и обработок:
• Учет плотности реализовать как справочный реквизит, путем добавления
двух дополнительных полей «Объем» и «Плотность» в табличную часть
документа через механизм расширений. «Объем» вычисляемая величина.
• ТТН и «Путевой лист» реализованы как дополнительная печатная форма к
документам «Реализация товаров и услуг» и «Задание на перевозку»
68
соответственно. Данные для заполнения формы подтягиваются
непосредственно с документа-основания и со связанного с ним «Заказ
клиента» или «Реализация товаров и услуг». Агрегирование необходимых
данных для заполнения формы так же реализовано через механизм
расширений конфигурации.
• Механизм формирования печатных форм с возможностью произвольного
редактирования для возможно реализовать через механизм «Расширения
конфигурации» и API Open Office (в идеале следовало реализовать через
MS Office, но кризис и санкции сделали свое дело).
В результате анализа потребностей департамента по работе с
сельхозпродукцией и консультации с руководством отдела бы сделан вывод, что
в целом, ввиду отсутствия специфики учета продаж, доработки требуются только
в модуле «Доставка»:
• Требуется реализовать деление автотранспорта на «Собственный» и по
перевозчикам.
• Выявлен серьезный недостаток в базовой конфигурации: по каким-то
причинам разработчиками конфигурации не была реализована
возможность отгрузки «Заказа поставщику» несколькими заданиями на
перевозку, хотя «Заказ покупателя» без проблем можно было разбить и
на несколько заданий на перевозку.
По итогам анализа потребностей пожеланий сельхозблока и консультацией с
партнерами компании 1С были сделаны следующие выводы:
• Реализовать механизм деления автотранспорта на собственный и
поставщиков без внесения изменений в базовую конфигурацию
невозможно. Для реализации подобного роду группировки необходимо
добавление нового реквизита в справочник. Добавление новых
реквизитов через механизм «Расширения конфигурации» на данный
момент невозможно. Доработка отправлена на согласование с
директором компании, а также сделан запрос стоимости подобной
доработки у фирмы-партнера 1С.
• После общения с техподдержкой фирмы 1С, выяснилось, что они не в
курсе подобных проблем и потребностей (во что слабо верится, так
69
деятельность ООО «Агронефтепродукт» далеко не уникальна в своем
роде, а фирма 1С крупнейший поставщик решений для автоматизации
учета, в том числе узкоотраслевых компаний в странах бывшего СНГ
да и само решение «Комплексная автоматизация» продвигается как
одно из «флагманских», наряду с ERP 2.0). Но проблему признали, так
же ее внесли в разряд приоритетных (то есть посчитали что данный
функционал необходим-таки большинству существующих и
потенциальных клиентов), что подразумевает ее бесплатное решение в
будущем крупном обнулении (но это не точно). Было принято решение
пока на данном этапе доставку груза от поставщика регистрировать
одним заданием на перевозку, с указанием особенностей погрузки в
комментарии к документу.
Так же в рамках перехода на новый продукт была поставлена задача
адаптации обработки загрузки данных из системы «Топаз-Офис» в 1С:
Предприятие "Комплексная автоматизация 2.0". Краткое описание функций
обработки:
Отчеты в системе «Топаз-Электро» формируются в XML-формате. Было
запрошено описание формата отчета у разработчиков «Топаз». В ходе анализа
файла было выявлено следующие:
• Данные отчета содержат общее количество проданного топлива каждого
вида для каждой АЗС
• Данные отчета содержат сумму реализации за каждую смену, разделенную
по типам расчетов.
• В случае использования расчетных карт компании по соответствующему
виду расчета в файл добавляется детализированная информация о
контрагенте:
o ИНН
o ID карты
o Вид топлива
o Количество отпущенного топлива
С учетом данной информации было предложено следующее решение:
реализовать обмен данными через XML файл и внешнюю обработку.
70
Реализацию по видам расчета «Наличные» и «Банковский терминал»
отражать в бухучете документом «Отчет по розничным продажам» в
соответствующих разделах данного документа.
Данные по виду расчета «Топливные карты» отражать документом
«Реализация товаров и услуг»:
• Идентификацию контрагента проводить по ИНН
• Данные по типу топлива количеству переносить в соответствующие поля
документа «Реализация товаров и услуг»
• Ввиду наличия системы учета цен номенклатуры появилась возможность
установки индивидуального вида цены для каждого клиента средствами
1С: Предприятие "Комплексная автоматизация 2.0".
• Была произведена доработка формы договора с покупателем контрагента,
где добавилась ссылка на справочник «Виды цен номенклатуры»
Исходя из сопоставления ИНН и договора с контрагентом, теперь
«подтягивается» и вид цены. Часть исходного когда (исходный код модуля
формы) приведен в Приложении 1.
2.3.2. Характеристика базы данных
База данных с модифицированной конфигурацией и подключенными
расширениями, и обработками размещена на СУБД PostgreSQL.
Основа PostgreSQL составляет серверный процесс базы данных. Он
выполняется на одном сервере.
Доступ из приложений к данным базы осуществляется посредством
процесса базы данных. Клиентские программы не могут получить доступ к
данным самостоятельно, даже если они работают на том же компьютере, на
котором выполняется серверный процесс.
Такое разделение клиентов и сервера позволяет построить распределенную
систему. Можно отделить клиентов от сервера посредством сети и разрабатывать
клиентские приложения в среде, удобной для пользователя. Например, можно
реализовать базу данных под UNIX и создать клиентские приложения, которые
будут работать в системе Microsoft Windows.
71
Приведенная ниже схема (рис. 21) показывает типичную модель
распределенного приложения PostgreSQL:
Рисунок 21. Работа 1С: Предприятие "Комплексная автоматизация 2.0" в СУБД
PostgreSQL
Несколько клиентов подсоединяются к серверу по сети. PostgreSQL
ориентирован на протокол TCP/IP — это может быть локальная сеть или
Интернет. Каждый клиент соединяется с основным серверным процессом базы
данных (Postmaster), который создает новый серверный процесс специально для
обслуживания запросов на доступ к данным конкретного клиента.
Благодаря тому, что манипулирование данными сосредоточено на сервере,
СУБД не приходится контролировать многочисленных клиентов, получающих
доступ в совместно используемый каталог сервера, и PostgreSQL может
поддерживать целостность данных даже при одновременном доступе большого
количества пользователей.
2.3.3. Структурная схема пакета (дерево вызова программных модулей)
Дерево вызова стандартное для продуктов 1С.
72
Рисунок 21. Дерево вызова программных модулей
2.3.4. Описание программных модулей
Описание программных модулей включает блок-схемы программных
модулей и описание блок-схем алгоритмов основных расчетных модулей. В
качестве примера рассмотрим программный модуль InvoiceForPaymentRPT «Счет
на оплату».
При вызове модуля производится формирование и вывод на экран отчета
«Счет на оплату», который предназначен для выставления клиенту суммы на
оплату за покупку товара по заявке. Руководитель или бухгалтер, ознакомившись
с документом, может его распечатать или сохранить на жесткий диск в формате
Microsoft Excel. Развернутая блок-схема работы данного модуля представлена на
Рисунке 22.
73
Рисунок 22. Блок-схема работы с заявками клиента
Начало
Установка соединения с сервером
БД
Открытие таблиц Clients, Orders, Items
Создание представления для
списка клиентов VIEWCLIENTS
Сортировка по Name и Orders
Цикл по клиентам
j=1;
j<COUNT(ViewClients);
j++
Sum = 0
Sum = Sum + ViewClients[j].sum
Внесение Sum в макет отчета
Sum = 0
Конец цикла по
клиентам
Закрытие таблиц и представления
ViewClients
Конец
74
Структура представления VIEWCLIENTS, предназначенного для временного
хранения и обработки сумм оплаты клиентами за выполненные работы,
представлена в таблице 24.
Таблица 24. Структура записи представления VIEWCLIENTS («Денежные
выплаты клиентами за товар по заявке»)
Наименование показателя
Идентификатор
Тип
Код строки
ID
Int
Код клиента
ClientsID
Int
ФИО клиента. Формируется из поля Name
справочника Clients
Name
Nvarchar(600)
Заказ клиента, по которому были
оплачены выполненные работы (берется
из поля «Num» таблицы Orders
NumOrders
Int
Сумма оплаты по заказу (берется как
сумма полей «Price» из таблицы Items)
Sum
Money
2.4. Контрольный пример реализации проекта и его описание
Основой проекта является внедрение в организации доработанного
продукта 1С: Предприятие "Комплексная автоматизация 2.0". Проведем обзор
модификаций конфигурации.
При запуске программы необходимо ввести имя и пароль для авторизации
в данной программе (см. рис. 23).
Рисунок 23. Вход в систему регистрации и обработки заявок в ООО
«Агронефтепродукт»