D_07-02-67.gif' alt='Образец Приказа На Приобретение Программного Продукта' title='Образец Приказа На Приобретение Программного Продукта' />Оформляем внутреннюю разработку как программный актив в пять шагов Блог компании Softline Хабрахабр. Привет, Хабр. Меня зовут Владимир Разуваев, я руководитель департамента бизнес консалтинга. Наша команда занимается тем, что помогает клиентам понимать значимость программных активов и управлять ими. В этом посте я предлагаю поговорить о внутренних разработках, которые в той или иной мере есть практически в любой компании. Текст разделен на три части. Образец Приказа На Приобретение Программного Продукта' title='Образец Приказа На Приобретение Программного Продукта' />В первой я расскажу о пяти важных шагах по формализации таких разработок. Эта формализация поможет не только закрепить за компанией права на эти разработки, но и сократить юридические риски, связанные с перехватом прав на ПО бывшими сотрудниками, а также экономические риски неправильного учта ПО как актива. Из второй части станет понятно, какими правами на программный продукт, созданный для компании, обладают непосредственно программисты. И в третьей части я поясню, почему так важно правильно оформлять документы и с какими рисками может столкнуться компания разработчик. Образец Приказа На Приобретение Программного Продукта' title='Образец Приказа На Приобретение Программного Продукта' />После приказа по организации о том, что продукт введен в. Акт приемки программного продукта к эксплуатации в компании. При приобретении компьютерной программы заключается договор с. Начало использования программного продукта считается согласием на. ФЗФорма приказа приведена в Приложении Покупка ПО с приобретением неисключительных прав на его. Расходы на покупку подобного программного обеспечения могут. Этот срок необходимо закрепить в учетной политике или отдельным приказом. Образец Приказа На Приобретение Программного Продукта' title='Образец Приказа На Приобретение Программного Продукта' />Опыт последних трх лет показывает, как изменилось отношение компаний ко внутренним разработкам. Даже простой, созданный на коленке софт, воспринимается как некая сущность, имеющая свою ценность. В некоторых компаниях ценность внутренних разработок увеличилась еще и под влиянием политики импортозамещения для них написанное собственной командой программистов ПО альтернатива зарубежным продуктам, часто уже достаточно близкая к ним по функциональности. Как бы то ни было, организации стремятся формализовать внутренние разработки мы видим это по количеству соответствующих обращений в наш департамент. Пять шагов к формализации внутренних разработок. Под формализацией мы имеем в виду прежде всего надлежащее документальное оформление созданного результата интеллектуальной деятельности. Нужно чтко понимать, что в соответствии с действующим законодательством авторское право на программу для ЭВМ возникает с момента ее создания в силу самого факта е создания. Rashody-budushih-periodov3.jpg' alt='Образец Приказа На Приобретение Программного Продукта' title='Образец Приказа На Приобретение Программного Продукта' />Справедливо, что если сотрудник, работающий в организации по трудовому договору, занимается разработкой программного продукта для компании, то данный программный продукт должен принадлежать компании, поскольку это относится к его обязанностям, и именно за это он получает заработную плату и иные виды компенсации премии и другие выплаты компенсационного характера. Однако крайне важно понимать, что в авторском праве разграничены две вещи авторское право нематериальное и т. И если авторское право возникает в силу создания и принадлежит физическим лицам, создавшим продукт, то материальное право подлежит тонкой документальной настройке. Механизм по защите внутренних разработок включается в пять шагов. Шаг первый. В рамках трудового договора формализуйте функции сотрудников и подчеркните, что в обязанности сотрудника входит разработка служебных произведений, программ для ЭВМ, баз данных и т. Также проверьте тот трудовой договор, который уже подписан сторонами это может быть типовой документ, в котором пункты о разработке служебных произведений могут быть не указаны. В этом случае заключите с разработчиком дополнительное соглашение, в котором следует сделать акцент на функциональных задачах специалиста, а также прописать принадлежность возникающих исключительных прав компании нанимателю. Также в договоре обязательно должен быть указан порядок уплаты авторского вознаграждения за созданные программы ЭВМ. Авторское вознаграждение может быть включено в заработную плату, премирование, либо иные виды материального поощрения. Шаг второй. Всегда составляйте служебное задание на разработку программы для ЭВМ. Строго говоря, с него должна начинаться любая разработка. Служебное задание готовится в свободной форме. Оно содержит цели конкретного проекта, разработку которого планируется начать, а также некое краткое описание функциональности либо задач, которые создаваемое приложение будет решать. Совсем идеально, если служебные задания будут готовиться под конкретные модули разрабатываемого решения и содержать в себе полное и чткое техническое задание на каждый модуль. Если такой документ отсутствует, рекомендуется его разработать для текущих проектов, либо составить новый на развитие ранее разработанного продукта, в котором следует дополнительно прописать принадлежность исключительных прав компании. Своим заказчикам мы упрощаем жизнь и предлагаем им готовые шаблоны, но вы можете написать и в свободной форме. Не страшно, если вы не составляли служебное задание на предыдущих этапах разработки. Ваш продукт наверняка дорабатывается, и начать практику заданий имеет смысл при развитии продукта. В этом случае сформулируйте задание так, чтобы из контекста было понятно дорабатывается именно существующее решение, работа над которым велась и ранее. Если служебные задания так или иначе были сформулированы, нелишним будет провести их аудит либо самостоятельно, либо с помощью привлеченного консультанта. Это позволит понять, все ли в порядке с документами, если нет, то привести их в порядок. Нужно понимать, что собственный софт, не имеющий документов, проверяющими органами будет восприниматься как пиратский. А это лишние риски, которые ни к чему любой компании. Шаг третий. Сделайте так, чтобы разработчик если он один или тим лидер если у вас отдел разработки подготовили вам докладную записку о выполнении служебного задания. В ней содержится информация о функциональности разработанного модуля, либо о функциональности продукта в целом. Также в обращении должен быть тезис о том, что программный продукт к эксплуатации готов. Прошивка Модуля Связи Moly Wr8 W1315 Md. Фактически докладная записка фиксирует документально факт выполнения служебного задания и представляет собой аналог акта прима передачи. Шаг четвертый. На основании докладной записки специально назначенная комиссия производит анализ возможности приема программного продукта в тестовую или промышленную эксплуатацию, после прохождения которой на основании акта приемки формируется приказ по организации о переводе данного ПО в промышленную эксплуатацию. Шаг пятый. После приказа по организации о том, что продукт введен в эксплуатацию, следует подготовить распоряжение о постановке ПО на бухгалтерский баланс, определить его начальную стоимость, полезный срок использования и пр. Как это сделать Необходимо создать экспертный совет, который в рамках обсуждения функциональности ПО выдаст рекомендации и оценки, связанные со стоимостью программного обеспечения. Рекомендации экспертов лучше формулировать в виде протокола, который затем должен быть передан в бухгалтерию. Начальная стоимость определяется самостоятельно компанией разработчиком и чаще всего включает в себя непосредственно прямые затраты. Не стоит завышать стоимость ПО, т. Подробные правила формирования в бухгалтерском учете и бухгалтерской отчетности информации о нематериальных активах организаций устанавливает ПБУ 1. Положение по бухгалтерскому учету Учет нематериальных активов, приложение к приказу Минфина РФ от 2. Служебное задание. Докладная записка о выполнении задания. Акт приемки программного продукта к эксплуатации в компании. Распоряжение о постановке программного обеспечения на бухгалтерский баланс. Толково и правильно проведенный процесс формализации превращает внутреннюю разработку в программный актив. Говоря юридическим и бухгалтерским языком, таким образом получается нематериальный актив, повышающий капитализацию компании. Несмотря на нематериальный статус, у программного актива много общего с обычными активами, но, прежде всего, это его стоимость. Компания может зарабатывать, например, передавая неисключительные права на программный продукт другим компаниямпользователям или использовать его в организации, оптимизируя расходы на задачи, которые ранее не были автоматизированы, сокращая трудозатраты на их выполнение. Если данная разработка является дорогостоящим продуктом, она существенно увеличит капитализацию компании. На Хабре неоднократно поднимался вопрос о важности регистрации приложений в Роспатенте.