25
- период выгрузки платежных документов. Для указанного периода
будут выгружены все платежные документы указанных видов по указанным
расчетным счетам. Период выгрузки целесообразно выбирать таким образом,
чтобы были выгружены все документы, введенные или измененные после
предыдущей выгрузки данных. Но если период охватит ранее выгруженные
документы, это не будет считаться ошибкой.
Результатом выгрузки данных является файл.
На втором этапе пользователь работает уже не с системой "1С", а с
модулем "Клиент-банк". В этом модуле пользователь запускает процедуру
загрузки данных из файла, созданного в системе "1С". Процедура загрузки
выполняет ряд проверок:
- если документ данного вида не может обрабатываться модулем
"Клиент-банк", то процедура загрузки информирует об этом пользователя;
- если загружаемый документ уже присутствует в системе и не
отличается по содержанию, то он не обрабатывается, а если документ
отличается по содержанию, то он перезаписывается;
- документ не обрабатывается, если в соответствии с логикой работы
"Клиент-банк" он не может быть передан в банк (просрочен и т. д.).
Затем модуль "Клиент-банк" по телекоммуникационным каналам
обменивается данными с модулем "Банк": туда передаются данные о
подготовленных документах, оттуда принимаются сведения о результатах
обработки переданных документов, выписки по счетам и т. д.
Данные из коммерческого банка принимаются также в два этапа по тому
же алгоритму. Отличие заключается в том, что системы меняются местами, а на
втором этапе выполняется другой ряд проверок:
- если загружаемый документ уже присутствует в системе "1С" и не
отличается по содержанию, то он не обрабатывается;
- если загружаемый документ уже присутствует в системе "1С", но
отличается по содержанию, то он считается исправленным. Процедура загрузки
26
информирует об этом пользователя и предлагает ему изменить существующий
документ.
Для электронного обмена финансовыми документами в системе
"1С:Предприятие" используется открытый стандарт, описывающий единые
правила обмена, разработанные фирмой "1С":
- имена файлов настраиваются в процедурах выгрузки и загрузки:
- при передаче – "1c_to_kl.txt"
- при приеме – "kl_to_1c.txt"
- формат файла – текстовый;
- кодировка настраивается в процедурах выгрузки: может быть
"DOS" и "Windows";
- в первой строке файла должна содержаться специальная
последовательность символов - внутренний признак файла обмена данными
между "1С" и "Клиент-банк";
- далее следуют строки, содержащие необходимую служебную
информацию;
- далее следуют строки, содержащие условия отбора документов
(интервал дат, расчетные счета, виды документов);
- далее (только при приеме данных из "Клиент-банк" в "1С") следуют
секции, содержащие остатки и обороты по расчетным счетам;
- внутри каждой секции следуют строки, содержащие необходимую
информацию о расчетном счете;
- далее следуют секции, содержащие информацию о документах;
- внутри каждой секции следуют строки, содержащие необходимую
информацию о документе;
- каждая секция начинается и заканчивается строкой
предопределенного вида;
- строки секции и служебные строки состоят из двух частей. Первое
поле "ИдентификаторРеквизита" описывает, какой реквизит записан в данной
27
строке, второе поле "ЗначениеРеквизита" содержит его значение. Поля
разделяются знаком равенства;
- идентификаторы не должны содержать пробелов и прочих
символов-разделителей. Перед идентификатором, перед знаком равенства и
после него (до первого значащего символа) не могут содержаться пробелы или
иные символы-разделители;
- реквизиты и строки могут быть обязательными и необязательными;
- идентификация документов производится по расчетному счету,
виду документа, дате и номеру. Предполагается, что по одному расчетному
счету не может быть нескольких исходящих документов одного вида за одну
дату с одинаковыми номерами. Для документов, передаваемых из "1С" в
"Клиент-банк" это обязательное правило.
Стандарт является открытым и предлагается всем разработчикам систем
дистанционного банковского обслуживания в качестве открытого стандарта,
что позволит взаимодействовать с системой "1С:Предприятие" и любой
учетной системой, поддерживающей стандарт.
Список банков, которые поставляют программы типа "Клиент-банк",
поддерживающие стандарт обмена данными "1С:Предприятие - Клиент банк".
Данный список содержит более одной тысячи наименований банков на
момент написания работы, и он постоянно пополняется.
Описанная система "Клиент-банк" является предшественником новой
системы автоматического обмена "DirectBank".
Технология "DirectBank" была разработана для того, чтобы облегчить
работу пользователей программ "1С:Предприятие" при взаимодействии с
банками.
Данная технология, позволяет отправлять документы в банк и получать
документы из банка непосредственно из программ системы "1С:Предприятие".
В отличие от технологии "Клиент-Банк" не требуется установка и запуск
дополнительных программ на компьютер. Технология позволяет избежать
выгрузки документов в промежуточные файлы.
28
Таким образом, все платежные поручения можно формировать и
подписывать электронной подписью в "1С:Предприятие", а затем отправлять
прямо на сервер банка.
Узнать о статусе платежа (проведен или нет), а также получить
банковские выписки, можно не выходя из программы "1С", в режиме онлайн.
Таким образом, прямо из программы "1С" можно отслеживать движение по
расчетному счету.
Используя технологию "DirectBank" можно напрямую отправлять в банк
реестры на открытие счетов и реестры на зачисление зарплаты работникам
предприятия в рамках зарплатных проектов банка.
В настоящий момент пользователи системы "1С" могут работать с
технологией "DirectBank" в рамках сервиса "1С:ДиректБанк".
Преимущества сервиса "1С:ДиректБанк":
- управление расчетными счетами прямо из "1С:Предприятие", без
установки системы "Клиент-Банк";
- отправка в банк заявки на открытие и закрытие счетов банковских
карт, реестра перечисляемой сотрудникам зарплаты на эти счета прямо из
"1С:Предприятие";
- единый пользовательский интерфейс для управления всеми
счетами, открытыми в разных банках;
- повышенный уровень безопасности - подписание электронных
документов проводится прямо в "1С:Предприятие" (для варианта с
использованием криптографии);
- высокая скорость обмена информацией с банком - отправка
платежного документа или получение выписки из банка выполняется по одной
команде пользователя;
- работа в одном окне.
Используемый стандарт, как и в случае с «Клиент-Банк», является
открытым и может быть использован любыми разработчиками систем
управления и учета.
29
Фирма "1С" открыла консультационную поддержку разработчиков при
реализации данного стандарта.
Исходя из описания сервиса, этот вариант должен полностью закрывать
требования нашей задачи. и он их закрывает, но в новых версиях поставки
конфигурации "1С:Управление Торговли 11", начиная с версии "11.4.1.241".
Версия конфигурации, которая используется в организации - "11.3.4.81". В
нашей версии конфигурации сервис "1С:ДиректБанк" не доработан до той
версии, которая полностью закроет требования задачи. Объясняется это тем,
что пользователю также придется выполнять определенный порядок действий
вручную (Рисунок 5). Это сокращает затрачиваемое время, но не является
решением задачи.
Рисунок 5. Алгоритм действий пользователя.
Для автоматизации данного процесса возможно два решения:
обновление конфигурации до последнего актуального релиза, где уже
автоматизирован этот процесс благодаря сервису "ДиректБанк", либо
доработать существующую конфигурацию под требования.
30
1.3.2 Выбор и обоснование стратегии автоматизации задачи
Из описанных в пункте 1.3.2 вариантов автоматизации делаем вывод,
что обновление конфигурации до нового релиза неуместно в текущих условиях,
так как конфигурация сильно доработана под нужды компании и обновление не
планируется в связи с большими трудозатратами и отсутствием необходимости.
Следовательно, доработка текущей версии конфигурации является
единственным верным решением.
Перейдем к выбору стратегии автоматизации и обоснованию. Хаотичная
стратегия не подходит, так как предполагаем использование информационной
системы в долгосрочной перспективе, расширение и добавление функционала
системы. Комплексная автоматизация предполагает полную автоматизацию
всех функциональных направлений деятельности компании, а также требует
больших временных и финансовых затрат, которые не может позволить
компания. Автоматизация по участкам предполагает автоматизацию отдельных
отделов компании, в данном случае предполагается автоматизация фрагмента
одного из процессов определенного участка, выполняемого каким-либо из
отделов компании.
В рамках выбранной нами задачи производится автоматизация
отдельного направления деятельности организации - отражение приема
платежей от покупателей. В данном случае уместнее использовать стратегию
автоматизации по направлениям, так как происходит автоматизация отдельных
групп бизнес-процессов компании.
Для решения описанной задачи дополнительных требований к
программному обеспечению нет, поскольку мы переводим ручные действия
пользователя в программные, что не несет дополнительные серьезные нагрузки
на систему.
31
II Проектная часть
2.1 Разработка проекта автоматизации
2.1.1 Этапы жизненного цикла проекта автоматизации
Понятие жизненного цикла является одним из базовых понятий
методологии проектирования информационных систем. Жизненный цикл
информационной системы представляет собой ряд событий, происходящих с
системой в процессе ее создания и дальнейшего использования. Говоря
другими словами, это время от начального момента создания какого-либо
программного продукта до конца его разработки и внедрения. Жизненный цикл
программного обеспечения можно представить в виде моделей.
Жизненный цикл информационной системы охватывает:
- исследование предметной области с последующим формированием
функциональной и информационной моделей объекта, для которого
предназначена информационная система;
- проектирование системы, заключающееся в разработке проектных
решений, удовлетворяющих всем требованиям технического задания;
- разработку системы (в том числе программирование и тестирование
прикладных программ на основании проектных спецификаций подсистем,
выделенных на стадии проектирования);
- тестирование информационной системы и выявление сбоев с
последующим их устранением;
- эксплуатацию системы и ее сопровождение;
- развитие системы.
Модель жизненного цикла программного обеспечения – это структура,
содержащая процессы последовательного действия и задачи, которые
осуществляются в процессе разработки, эксплуатации и дальнейшего
сопровождения программного продукта.
Эти модели можно разделить на три основные группы:
- инженерный подход;
- с учетом специфики задачи;
32
- современные технологии быстрой разработки.
Теперь рассмотрим существующие модели (подклассы) и оценим их
преимущества и недостатки.
1. Каскадная модель (водопад). В данной модели процесс разработки
идет поэтапно, шаг за шагом. Переход к следующему этапу происходит только
после завершения предыдущего (Рисунок 6). Относится к первой группе
моделей.
Рисунок 6. Каскадная модель.
Преимущества каскадной модели:
- последовательное выполнение этапов проекта в строго
фиксированном порядке;
- позволяет оценивать качество продукта на каждом этапе.
Недостатки:
- отсутствие обратных связей между этапами;
- не соответствует реальным условиям разработки программного
продукта.
Каскадная модель с промежуточным контролем (водоворот). Данная
модель является почти эквивалентной по алгоритму предыдущей модели,
однако при этом имеет обратные связи с каждым этапом жизненного цикла
(Рисунок 7).
33
Имеет очень весомый недостаток: десятикратное увеличение затрат на
разработку. Относится к первой группе моделей.
Рисунок 7. Каскадная модель с промежуточным контролем.
2. "V" модель (разработка через тестирование). Это улучшенная версия
классической каскадной модели. На каждом этапе происходит контроль
текущего процесса для того, чтобы убедится в возможности перехода на
следующий уровень. Данная модель имеет приближенный к современным
методам алгоритм, но имеет ряд существенных недостатков. Является одной из
основных практик экстремального программирования. Относится к первой
группе моделей.
Рисунок 7. "V" модель.
34
Преимущества "V" модели:
- строгая этапизация;
- тестирование и верификация системы производятся на ранних
этапах;
Недостатки:
- недостаточная гибкость модели.
3. Спиральная модель жизненного цикла программного обеспечения.
Представляет собой процесс разработки программного обеспечения,
сочетающий в себе как проектирование, так и поэтапное прототипирование с
целью сочетания преимуществ восходящей и нисходящей концепции. В данной
модели разработка происходит по нарастающей (Рисунок 8). На начальном
этапе разрабатывается система с высоким уровнем абстракции, а на
последующих витках эта разработка все больше и больше конкретизируется.
Рисунок 8. Спиральная модель.