Разработка (адаптация) ИС в среде пакета 1С

 

Программы 1С в значительной степени автоматизируют задачи, базирующиеся на нормативных документах по организации бухгалтерского учета, мало зависят от вида деятельности, что позволяет им стать универсальными и применяться с незначительной адаптацией. В то же время в учете имеется множество задач, отражающих специфику видов деятельности, предполагающих многовариантность организации и методов ведения учета. Задач такого рода в программах 1С значительно меньше, чем унифицированных, высока вероятность, что их надо дорабатывать при привязке к предприятию (организации).

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

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

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

Работы по привязке и внедрению распределяются на следующие этапы:

· обследование объекта

· организационные мероприятия

· разработка технического задания

· адаптация и доработка программ 1С к специфике предприятия (организации)

· внедрение программного продукта

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

Состав технического задания

· Основание для разработки.

· Назначение разработки.

· Методологические основы решения задач.

· Функциональные спецификации и описание алгоритмов.

· Условия эксплуатации.

· Порядок контроля работоспособности программ и их приемка.

· Этапы разработки.

Разделы технического задания

Основание для разработки.

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

· наименование работы, краткое ее содержание, условное обозначение, если имеется;

· наименование организации заказчика;

· перечень документов, на основании которых ведется разработка с указанием полного названия этих документов и данных об их утверждении;

· наименование программы 1С и ее условное обозначение, принятой для проведения привязки к объекту;

· перечень исходных материалов, использованных при разработке технического задания,

в том числе материалы обследования, нормативно-технические документы, рекомендованные

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

· место проведения работ по привязке программ 1С.

Назначение разработки

В разделе указывается функциональное назначение разработки. Программы 1С имеют определенное функциональное назначение. Они ориентированы на реализацию регламентированного состава учетных задач с фиксированными алгоритмами решения. В разделе приводятся наименования задач в составе программ 1С, которые будут переработаны. Здесь же перечисляются задачи, которые будут дополнительно разработаны и включены в состав программ 1С. Указываются отклонения от программ 1С по содержанию задач. Поясняется, каким образом будут использоваться результаты решения переработанных задач.

Методологические основы решения задач

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

Функциональные спецификации и описание алгоритма

Раздел должен включать подробное описание изменений в программе 1С. Он может включать следующие основные спецификации:

· описание плана счетов

· описание справочников

· описание субконто

· описание документов

· описание отчетов

· параметры адаптации

На каждую спецификацию открывается отдельный подраздел.

Описание плана счетов.

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

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

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

Описание справочников.

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

· идентификатор,

· комментарии,

· длина кода и наименования,

· подчиненность,

· количество уровней,

· серии кодов,

· тип кода.

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

· наименование,

· идентификатор,

· периодический,

· тип значения,

· длина.

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

Описание субконто.

Необходимая информация об организации аналитического учета приводится в подразделе "План счетов". В данном подразделе приводятся специальные сведения о свойствах вида субконто.

Описание документов.

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

· наименование функциональной задачи

· назначение

· функциональное содержание

· периодичность решения

· дополнительные сведения

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

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

· наименование элемента диалога,

· порядок обхода элементов,

· пояснение по вводу реквизитов.

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

· наименование реквизита

· идентификатор

· тип значения

· длина

· точность

· пояснение

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

При изложении алгоритма решения следует приводить:

· описание логики решения задачи и способа формирования результатов решения с указанием последовательности этапов счета;

· расчетные и логические формулы, используемые в алгоритме;

· указания о точности вычислений;

· соотношения, необходимые для контроля достоверности вычислений;

· указания о порядке расположения строк или значений в документе.

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

· наименование формируемого реквизита

· идентификатор формируемого реквизита

· идентификаторы исходных реквизитов

· порядок расчета реквизита

· дополнительные пояснения

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

· идентификатор документа

· комментарий

· журнал

· нумератор

· периодичность

· длина кода

· тип кода

· используемый компонент

Описание отчетов.

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

В диалоге обычно указываются следующие параметры отчета:

· период, за который формировать отчет (задается выбором даты начала периода и даты окончания периода или выбором "круглого периода");

· счет, по которому формировать ведомость;

· виды субконто, по которым ведется аналитический учет по счету;

· значение субконто

В диалог могут быть включены и другие специальные параметры, вытекающие из особенностей формирования отчета. Алгоритм формирования реквизитов отчета можно описать с помощью двух таблиц. В первой таблице описывается порядок формирования реквизитов, независимо от того, в какой строке отчета они отражаются. Например, "Сумма за период" - обороты по кредиту реквизита "Сумма" за указанный период. В этой же таблице указываются длина и точность реквизита. Во второй таблице описывается порядок формирования строк отчета. Для этого предварительно идентифицируются все строки отчета, а в таблице по каждой строке приводится порядок ее формирования. Примерный вид строки: Итоги по субконто 1. Порядок формирования: Наименование субконто; итоговые данные по значению субконто 1;

формируется при изменении субконто 1.

Параметры адаптации.

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

Условия эксплуатации

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

· обновление технических средств по составу и характеристикам;

· наличие необходимого системного программного обеспечения;

· обслуживание технических средств;

· подготовка персонала.

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

В разделе следует привести:

· перечень задач, подлежащих проверке на контрольном примере;

· объем контрольного примера;

· содержание контрольного примера (состав первичных документов, справочники и т.д.);

· выполнение контрольного примера;

· порядок отражения результатов испытаний;

· оформление приемки работ.

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

Этапы разработки

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

Разработка Intranet-систем

Информационная Intranet-система - это информационная система, в которой используются методы и средства Internet. Такая система может быть локальной, изолированной от остального мира Internet, или опираться на виртуальную корпоративную подсеть Internet. Для функционирования Intranet-системы достаточно иметь настроенный Web-сервер и стандартный браузер на стороне клиента.

Несмотря на ряд недостатков таких систем (отсутствие прикладной обработки данных, трудно модифицируемые гипертекстовые структуры и т.д.), в настоящее время существует большое количество развитых механизмов Web-технологии, позволяющих решать в Intranet-системах практически любые задачи из любой области. Указанные механизмы непрерывно совершенствуются, что положительно отражается на возможностях Intranet-систем, но в тоже время негативно сказывается на документировании таких систем из-за отставания стандартизации новых механизмов, которые де-факто могут морально устареть еще до того, как производители программных средств придут к согласию по поводу стандартов.

Этапы и технологии проектирования и разработки информационной системы на базе архитектуры Internet/Intranet принципиально отличаются от проектирования и разработки информационной системы на базе классической архитектуры клиент-сервер.

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

Во вторую очередь разработка Intranet-систем уделяет внимание техническим вопросам и проблемам, которые при разработке систем на базе других архитектур не представляются важными. Так, например, при разработке клиент-серверной архитектуры основное внимание акцентируется на проектировании логического и физического уровня БД и прописыванию возможных запросов к БД в терминологии SQL, оставляя логику выполнения бизнес-процессов на совесть СУБД, ограничиваясь лишь настройкой ее клиентской и серверной части. При разработке же информационной системы на базе архитектуры Internet/Intranet изначально выбирается способ реализации бизнес-логики (на стороне клиента или на стороне сервера), после чего выбирается технология и пишутся сторонние процедуры для доступа к базам данных, а уже на основе выбранных технологий выбирается СУБД и проектируется логический и физический уровень БД. Если выбран способ реализации бизнес-логики на стороне клиента, то используются технология java-апплетов, если на стороне сервера, то технологии CGI или ISAPI/NSAPI. Intranet-система может быть реализована на платформах ASP, PHP или копирующие их JSP, CFML, PSP.