техническое задание на доработку программы образец

Договор на разработку программного обеспечения

Договор на разработку программного обеспечения Как составить договор на разработку программного обеспечения Образец и комментарии 1. Предмет договора на создание программ

1.1. Разработчик обязуется создавать (в том числе модифицировать) и передавать Заказчику программы для ЭВМ и/или базы данных (далее по тексту – «Продукт» или «Продукты») с одновременным отчуждением Заказчику исключительного права на такие Продукты в полном объеме, а Заказчик обязуется принимать Продукты и исключительное право на них и оплачивать на условиях настоящего Договора.

Такой предмет договора на разработку программного обеспечения позволяет его использовать не только в случае создания программ для ЭВМ и баз данных в полном объеме одним разработчиком, но и для привлечения разработчика на определенном этапе работ совместно с другими авторами, изменения программного обеспечения, дополнения его отдельными модулями расширения или компонентами.

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

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

Далее решается вопрос, под каким наименованием разрешается использовать Продукт, должно ли указываться имя автора Продукта при всяком его использовании.

Поскольку работы по созданию программного обеспечения облагаются НДС в отличие от предоставления права использования программного обеспечения на основании чистого лицензионного договора или договора отчуждения исключительного права на ПО. которые освобождены от НДС на основании пп.26 ст.149 НК РФ, в предмет настоящего договора также необходимо включить пункт, что договор на разработку программного обеспечения является смешанным, а потому к нему не применяется норма о льготе по НДС.

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

2. Порядок сдачи-приемки программного продукта

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

2.1. Заказчик вправе ознакомиться у Разработчика с ходом работ на любом этапе создания Продукта.

Для обеспечения качества работ необходимо обеспечить контроль со стороны Заказчика.

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

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

2.3. По завершении работ и/или отдельного этапа работ Разработчик предоставляет Заказчику исходный текст и объектный код Продукта (в том числе его части) на оптическом диске или посредством сети связи с сопутствующей технической документацией и руководствами по использованию.

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

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

Пункт важен в первую очередь для Разработчика.

2.5. После принятия Заказчиком решения о соответствии Продукта требования задания Стороны составляют акт сдачи-приемки выполненных работ. В случае мотивированного отказа Заказчика подписать акт сдачи-приемки Сторонами составляется двусторонний акт с указанием необходимых доработок и сроков их выполнения.

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

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

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

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

3. Цена договора и порядок расчетов

Данный раздел договора имеет существенное значение для обеспечения качества и сроков выполнения работ, обоснования расходов Заказчика для целей налогообложения и обеспечения полной и своевременной оплаты работ в интересах Разработчика.

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

• в твердой сумме

• в виде процентов с дохода от последующего использования

• на основе почасовых ставок сотрудников разработчика.

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

4. Ответственность сторон

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

5. Разрешение споров

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

6. Конфиденциальность

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

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

Техническое задание 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С. Далее изложены возможные требования к составу и оформлению технического задания.

Основание для разработки.
Назначение разработки.
Методологические основы решения задач.
Функциональные спецификации и описание алгоритмов.
Условия эксплуатации.
Порядок контроля работоспособности программ и их приемка.
Этапы разработки.

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

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

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

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

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

описание плана счетов
описание справочников
описание субконто
описание документов
описание отчетов
параметры адаптации

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

Описание плана счетов.
Появление новых синтетических счетов (в сравнении с типовой конфигурацией) происходит крайне редко. Это может быть связано с отраслевыми особенностями и регулируется инструкциями. Что же касается появления новых субсчетов, то это наблюдается значительно чаще и связано с необходимостью аккумулирования хозяйственных операций определенного вида. Например, для сельскохозяйственного предприятия счет 20 " Основное производство", как минимум, имеет три субсчета "Растениеводство", "Животноводство", "Промышленное производство". Для предприятий (организаций) со значительными отклонениями от типовой конфигурации приводится полный план счетов. Указываются наименования счетов и их свойства: признак ведения валютного учета, признак ведения количественного учета, признак забалансового счета, признак активный - пассивный. Обязательно перечисляются счета, субсчета, которые увязаны с формированием отчетности и подлежат обязательному применению. Для предприятий, где действующий план счетов мало чем отличается от принятого в типовой конфигурации, следует привести фрагмент плана счетов, по которому имеется расхождение. В любом случае, следует перечислить программы, которые предстоит корректировать в связи с изменением плана счетов. Например, документы, где производится генерация проводок, а также формы отчетности. По вновь введенным счетам обязательно приводится возможная корреспонденция. По счетам типовой конфигурации, которые используются на предприятии, пояснения не приводятся. В подразделе следует описать изменения в системе аналитического учета. На этапе обследования устанавливается соответствие действующей на предприятии системы аналитического учета, предусмотренной в типовой конфигурации. Известно, что настройку аналитического учета типовой конфигурации рекомендуется сохранять, так как она используется при генерации проводок в документах и в алгоритмах форм отчетности. Конечно, следует добиваться минимально возможных изменений настройки, они могут повлечь увеличение трудоемкости и сложности привязки. В подразделе технического задания следует привести структуру аналитических разрезов по тем счетам, где имеют место отклонения от типовой конфигурации. Это относится и к субконто типа Перечисление. В отдельный фрагмент целесообразно выделить перечень программ (документы, формы отчетности), которые подлежат корректировке в связи с изменением системы аналитического учета. Изменения по системе аналитического учета могут быть оформлены в виде таблицы, где на одной ее стороне приводится перечень счетов, а на другой стороне - наименования аналитических разрезов.

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

идентификатор,
комментарии,
длина кода и наименования,
подчиненность,
количество уровней,
серии кодов,
тип кода.

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

наименование,
идентификатор,
периодический,
тип значения,
длина.

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

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

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

наименование функциональной задачи
назначение
функциональное содержание
периодичность решения
дополнительные сведения

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

наименование элемента диалога,
порядок обхода элементов,
пояснение по вводу реквизитов.

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

наименование реквизита
идентификатор
тип значения
длина
точность
пояснение

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

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

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

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

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

идентификатор документа
комментарий
журнал
нумератор
периодичность
длина кода
тип кода
используемый компонент

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

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

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

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

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

обновление технических средств по составу и характеристикам;
наличие необходимого системного программного обеспечения;
обслуживание технических средств;
подготовка персонала.

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

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

Контрольный пример должен охватывать ошибочные ситуации, которые могут возникнуть при эксплуатации программ 1С в результате некорректности исходной информации. Для этого следует использовать искусственно подобранные ошибочные данные для проверки работоспособности программ.
После завершения этапа контроля работы и приемки работ, программы могут быть использованы при внедрении. После того, как установлен весь состав доработок, составляется план работ. Целесообразно учетным работникам предварительно рассмотреть его и дать свои замечания и рекомендации. Специально должен быть рассмотрен вопрос очередности внедрения. При наличии значительного количества доработок, может быть установлен порядок, при котором первоочередное внедрение одних задач сочетается с проведением привязки по другим задачам. Таким образом, будет установлена последовательность работ по привязке и внедрению.
При выборе очередности привязки и внедрения следует учитывать актуальные потребности заказчика (объем, качество выполнения работ), подготовленность заказчика к переходу на автоматизированный учет, информационные взаимосвязи задач, трудоемкость внедрения той или иной группы задач, технологию обработки, предусмотренную технической документацией программ 1С.
Несмотря на то, что в описании этого раздела темы привязки и внедрения пересекаются, детально вопросы внедрения не рассмотрены. Техническое задание - основной документ. регламентирующий процесс привязки, проведение внедрения должно сопровождаться иными документами. Это позволит разделить различные, по существу, работы по привязке и внедрению и более формально подойти к каждой из них.
В этом же разделе должна быть предусмотрена возможность уточнения и дополнения технического задания в ходе разработки по согласованию между заказчиком и исполнителем. Дополнения оформляются в установленном порядке и являются неотъемлемой частью технического задания.
Этапы работ оформляются в виде таблицы и включают реквизиты:

Наименование этапа
Срок выполнения
Наименование документа, завершающего этап

Руководства, Инструкции, Бланки

Поиск

Новые файлы