Лист требований 1с это
Длительное судебное разбирательство закончилось, и вы, наконец, имеете на руках исполнительный лист, который можно предъявить в службу судебных приставов для принудительного исполнения. Теперь вы из истца превратились во взыскателя.
Прежде всего, получив исполнительный лист в суде, в обязательном порядке проверьте наличие всех необходимых реквизитов, которые содержатся в статье 13 ФЗ «Об исполнительном производстве» (далее по тексту статьи – «Закон»).
В том случае, если какого-то реквизита не будет в исполнительном листе, можете не сомневаться, судебный пристав-исполнитель откажет в возбуждении исполнительного производства на основании п.4 ст. 31 Закона.
Наиболее часто на практике не указывают год рождения должника, место рождения должника, либо место рождения должника указывается неполно (напр. Московская обл., Московский район – без указания конкретного населенного пункта). В случае неполного указания места рождения, судебный пристав-исполнитель считает, что данный обязательный реквизит не указан в исполнительном документе.
Рекомендуется при получении исполнительного листа в суде проверить все его необходимые реквизиты (цитирую ст. 13 Закона):
1) наименование и адрес суда или другого органа, выдавшего исполнительный документ, фамилия и инициалы должностного лица;
2) наименование дела или материалов, на основании которых выдан исполнительный документ, и их номера;
3) дата принятия судебного акта, акта другого органа или должностного лица;
4) дата вступления в законную силу судебного акта, акта другого органа или должностного лица либо указание на немедленное исполнение;
5) сведения о должнике и взыскателе:
а) для граждан - фамилия, имя, отчество, место жительства или место пребывания, а для должника также - год и место рождения, место работы (если оно известно);
б) для организаций - наименование и юридический адрес;
в) для Российской Федерации, субъекта Российской Федерации или муниципального образования - наименование и адрес органа, уполномоченного от их имени осуществлять права и исполнять обязанности в исполнительном производстве;
6) резолютивная часть судебного акта, акта другого органа или должностного лица, содержащая требование о возложении на должника обязанности по передаче взыскателю денежных средств и иного имущества, либо совершению в пользу взыскателя определенных действий или воздержанию от совершения определенных действий;
7) дата выдачи исполнительного документа.
На практике могут возникнуть вопросы о подпункте «б», части 5 статьи 13 Закона – требование указать юридический адрес.
Законодательство не содержит такого понятия как юридический адрес, а оперирует термином местонахождение юридического лица. Чтобы не забивать себе голову, необходимо знать, что в исполнительном листе должен быть указан просто адрес юридического лица, а уж как он там называется, юридический, фактический или почтовый это не имеет никакого практического значения.
Весьма полезной и важной новеллой Закона является возможность взыскателя самостоятельно предъявить исполнительный лист о взыскании периодических платежей (напр. алименты), а также любой другой исполнительный документ на взыскание суммы не свыше 25 тыс. руб. непосредственно в организацию, где должник получает заработную плату, пенсию или иной периодический доход.
Это нововведение позволяет:
- взыскателю оперативно получать взысканное по исполнительному документу. Например, вам известно, место работы должника. Теперь нет никакой необходимости «сдавать» исполнительный лист на взыскание алиментов судебному приставу-исполнителю, для того чтобы он переправил его для удержания по месту работы должника;
Представьте себе такую ситуацию. Через суд вы взыскали с должника 10 тыс. руб. Ваш должник работает в банке «Русский кредит».
Очевидно, что у должника имеется заработная плата. Вы предъявляете исполнительный лист в банк со своим заявлением, в котором просите банк производить удержания с должника по 50% (максимальный размер удержаний) от его дохода. Весьма вероятно, что свои десять тысяч вы получите за одно удержание. Предъявлять в организацию исполнительный лист необходимо нарочным (т.е. под роспись секретарю организации или непосредственно руководителю), либо заказным письмом с уведомлением.
Важно отметить, что взыскателю не надо знать конкретный номер расчетного счета, достаточно знать только банк, где находится расчетный счет должника.
Одновременно с исполнительным листом, взыскатель представляет в банк заявление, в котором указывает:
- реквизиты банковского счета взыскателя, на который следует перечислить взысканные денежные средства;
- фамилия, имя, отчество, гражданство, реквизиты документа, удостоверяющего личность, место жительства или место пребывания, идентификационный номер налогоплательщика (при его наличии), данные миграционной карты и документа, подтверждающего право на пребывание (проживание) в Российской Федерации взыскателя-гражданина;
- наименование, идентификационный номер налогоплательщика, государственный регистрационный номер, место государственной регистрации и юридический адрес взыскателя - юридического лица.
При этом составление инкассового поручения юридическим лицам (в том случае если взыскатель юридическое лицо) не требуется, достаточно одного заявления (п. 2 ст. 70 Закона).
Банк обращает взыскания на денежные средства в порядке, установленном ст. 70 Закона. В соответствии с п. 5 ст. 70 Закона в течение трех дней со дня получения банк исполняет требования и, в том случае, если денежных средств недостаточно, банк продолжает исполнять по мере поступления до полного погашения.
Банк прекращает исполнение только в трех случаях (п. 10. ст. 70 Закона):
- после перечисления денежных средств в полном объеме;
- по заявлению взыскателя;
- по постановлению судебного пристава-исполнителя о прекращении (об окончании, отмене) исполнения.
Вопрос обращения взыскания на денежные средства более подробно будет рассмотрен ниже.
Также у взыскателя всегда есть безусловное право предъявить исполнительный лист судебному приставу-исполнителю, не проходя предварительно вышеописанные процедуры.
Кому и как направлять исполнительный лист на принудительное исполнение? Судебные приставы-исполнители осуществляют свою деятельность по территориальному принципу, а именно по месту жительства должника.
То есть исполнительный лист, по общему правилу, необходимо предъявлять в тот территориальный отдел, который обслуживает район, в котором проживает должник. Например, должник проживает в Ленинском районе г. Тверь, исполнительный лист необходимо предъявлять в Ленинский территориальный отдел судебных приставов г. Твери.
Аналогичным образом следует поступать, если должником является юридическое лицо. В том случае, если вы хотите предъявить исполнительный лист по месту нахождения филиала юридического лица и адрес этого филиала не содержится в исполнительном документе, необходимо приложить доказательства о наличии такого филиала по указанному адресу (такой способ предъявления актуален при взыскании со страховых компаний, банков, других организаций, имеющих многофилиальную сеть по всей Российской Федерации). В противном случае в возбуждении исполнительного производства будет отказано.
В соответствии со ст. 33 Закона «Место совершения исполнительных действий и применение мер принудительного исполнения» у взыскателя имеется возможность предъявить исполнительный лист по месту нахождения имущества должника.
Делать это целесообразно, если большая часть имущества должника, в особенности недвижимое имущество, находится на отдаленном расстоянии от места жительства должника. О наличии имущества должника на другой территории необходимо указать в заявлении о возбуждении исполнительного производства и приложить соответствующие доказательства (например, копия свидетельства о государственной регистрации права на недвижимое имущество и т.п.). В противном случае делопроизводители территориальных отделов судебных приставов будут вас «отфутболивать по инстанциям», а в возбуждении исполнительного производства может быть отказано.
Если речь идет об исполнении требований о совершении определенных действий (например «… обязать Иванова А.П. не чинить препятствия в пользовании водопроводом, расположенным по адресу такому-то. »), то исполнительный лист необходимо предъявлять по месту совершения данных действий. Об этом также необходимо указать в заявлении о возбуждении исполнительного производства.
Возбуждение исполнительного производства возможно только на основании письменного заявления взыскателя, либо его представителя.
Полномочия представителя оформляются в обычном порядке – доверенностью, только важно отметить одну особенность – в доверенности помимо обычных правомочий представителя должно быть специально оговорено правомочие на предъявление исполнительного документа к исполнению.
Данное требование содержится в п. 3 ст. 57 Закона «Полномочия представителей сторон исполнительного производства». Специально также должны быть оговорены следующие правомочия представителя в исполнительном производстве:
- предъявление и отзыв исполнительного документа;
- передача полномочий другому лицу (передоверие);
- обжалование постановлений и действий (бездействия) судебного пристава-исполнителя;
- получение присужденного имущества (в том числе денежных средств и ценных бумаг);
- отказ от взыскания по исполнительному документу;
- заключение мирового соглашения.
Доверенность (а не его копия - п.2 ст. 30 Закона) прилагается к заявлению о возбуждении исполнительного производства. Пример заявления о возбуждении исполнительного производства приведен в приложении.
Полезно в заявлении о возбуждении исполнительного производства ходатайствовать наложении ареста на имущество должника в целях обеспечения исполнения требований исполнительного документа. Это позволит судебному приставу-исполнителю наложить арест на имущество должника в т.ч. в срок, установленный для добровольного исполнения должнику, прямо одновременно с вручением постановления о возбуждении исполнительного производства.
Кроме того, можно указать на применение к должнику временного ограничения на выезд из Российской Федерации (ст. 67 Закона).
К слову сказать, данное исполнительное действие традиционно для Российского законодательства, так в дореволюционном праве, судебный пристав мог запретить должнику покидать свое место жительства (а не границы Российской Империи вообще – примечание автора)
Если у вас есть какая-то ценная дополнительная информация о должнике, то ее необходимо указать в заявлении о возбуждении исполнительного производства. Еще лучше, если есть возможность с судебным приставом-исполнителем составить план совместных действий, а также, если у вас есть возможность оказать содействию судебному приставу в совершении исполнительных действий и применении мер принудительного исполнения (предоставление автотранспорта для транспортировки арестованного имущества, места для хранения имущества, грузчики и.т.д.). Вероятность быстрого и полного исполнения требований исполнительного документа в таких случаях существенного повышается.
Взыскателю надо всегда помнить одну простую вещь – его роль во взыскании долга должна быть предельно активна.
Если вы являетесь должником, то вам необходимо также знать несколько важных правил. Каждый долг возвращается ®. Естественным ходом вещей является тот факт, что должник не горит желанием заплатить долг, иначе дело бы не дошло до судебных приставов. Встречаются случаи, когда должник занимает принципиальную позицию не платить, т.к. считает решения суда незаконным и несправедливым. Данная категория должников является наиболее сложной для судебного пристава-исполнителя.
Самая простая тактика, которую может избрать должник – тактика пассивной защиты. В чем она заключается? Не получать корреспонденцию, не открывать дверь судебному приставу-исполнителю, скрываться, «переписать» все имущество на других лиц.
Однако, применение данной тактики эффективно лишь на каком-то этапе. Новая редакция закона об исполнительном производстве закрыла многие лазейки для должника.
В главе IV Закона «Извещение и вызовы в исполнительном производстве» имеется комплекс норм права, который делает тактику неполучения корреспонденции неэффективной.
В соответствии с п.3. ст. 24 Закона, извещение направляется по адресу, указанному в исполнительном производстве или по месту работы.
То есть, если должник официально трудоустроен, то уклоняться от получения корреспонденции у него не получится. В случае уклонения от явок по вызову, должник может быть доставлен принудительным приводом (согласитесь, что это малоприятная процедура, когда вас «уведут» люди в форме в присутствии коллег по работе).
Лицо, участвующее в исполнительном производстве (в т.ч. и должник), в соответствии с п.2 ст. 29 Закона, считается извещенным, если:
- адресат отказался от получения повестки, иного извещения;
- несмотря на получение почтового извещения, адресат не явился за повесткой, иным извещением, направленными по его адресу.
То есть, во время исполнительного производства, получение корреспонденции является проблемой должника, и если он ее просто не получает, то это не дает ему никаких преимуществ.
«Переписывание» имущества других лиц, разумеется, создает невозможность обращения на него взыскания. Однако здесь должник получает другую группу рисков – насколько надежны лица, на которых переоформлено имущество. На практике встречаются случаи, когда люди, таким образом, отдавали свое имущество фактически даром.
Кроме того, в настоящее время судебными приставами-исполнителями активно используются процедуры признания сделок по «переписыванию» имущества недействительными (мнимыми).
В Ленинский (Фрунзенский и.т.д.) РОСП
г. Москва ул. Багаева д.27
от Иванова Ивана Ивановича
прож. г. Москва ул. Ивановская д.1 кв.1
Заявление
о возбуждении исполнительного производства
Прошу принять к принудительному исполнению исполнительный лист, выданный на основании решения Ленинского районного суда г. Москвы от 01.01.2001г. по делу №1-11, о взыскании с должника Петрова Петра Петровича, проживающего по адресу: г. Москва, ул. Петровская, д.1, кв.1, денежной суммы в размере 1000 рублей в мою пользу, и возбудить исполнительное производство.
Одновременно с возбуждением исполнительного производства прошу наложить арест на имущество должника в целях обеспечения исполнения требований исполнительного документа.
Дата 01.01.2010 г. ________________________ (Иванов И.И.)
Примечание
1. Исполнительный документ предъявляется взыскателем. При этом лицо, принимающее исполнительный документ, проверяет личность предъявляющего путем проверки документов, удостоверяющих личность (паспорт; для военнослужащих - удостоверение личности). Водительские права, различного рода удостоверения не являются документами, удостоверяющими личность.
2. В случае предъявления исполнительного документа представителем взыскателя необходимо наличие подлинной доверенности, оформленной в соответствии с действующим законодательством.
Что важно для руководителя IT.
За чем нужно следить ведущему программисту.
Что будет помогать программисту.
Что сэкономит вам массу времени.
Что сделает вашу работу профессиональнее.
Идея - Константин Илларионов, Глеб Дунаев
Краткая предыстория
В 2012 году мне досталась в наследство база с сильно измененной конфигурацией УТ 10.3. Эта база дорабатывалась в течении нескольких лет многими программистами (и штатными, и франчайзи). Документации практически никакой не велось, комментарии в коде были скудны и неинформативны, пользователи внедряющие тот или иной функционал уже давно уволились, спросить было не у кого. В некоторых случаях было совершенно непонятно что и для чего делалось и как это работает. И мы решили это прекратить. Были сделаны первые шаги, которые в дальнейшем привели к созданию небольшой системы оформления разработки. Данная система уже два с лишним года успешно функционирует в нашем холдинге и с лихвой окупает время потраченное на нее.
Из чего состоит эта система?
1. Комментарии в коде
2. Справочная информация
3. Цифровые обозначения отчетов/обработок
4. Добавление/изменение объектов
5. Контроль за исполнением
А теперь детально, по пунктам:
1. Комментарии в коде
О чём пойдёт речь. Комментарии в коде делают практически все программисты. Думаю всем понятно для чего они нужны. Комментарий - это признак произведенного изменения и описание этого изменения.
В чём проблема. Часто по комментарию можно понять только одно, то что было сделано изменение :) При этом искать описание этого изменения крайне проблематично (имеется ввиду описание доработки, техзадание), я думаю многие с этим сталкивались: кто-то его сделал и где-то сохранил. надо знать это место. потом умудриться найти нужную информацию. суметь увязать с тем что фактически есть в конфигурации. а может описание и не сохранилось. плюс исполнители часто забывают обновлять информацию об изменениях и она становится неактуальной. В итоге, все эти факторы мешают быстро понять кто, что, когда делал, и что нужно сделать сейчас (и в каком месте!). А если посмотреть на проблему глобально, то выяснится что подобное ведение дел не позволяет быстро оценить отличия вашей конфигурации от типовой, какие контуры затронуты, насколько серьёзны эти изменения и т.д.
Как обычно решается. Смотрим код, пытаемся понять отличия от типовых механизмов, пытаемся понять зачем они сделаны, а если изменения сложны и непонятны - ищем у кого бы спросить (это обычно проще чем самому заниматься исследованиями!), либо сами разбираемся. В итоге на эти "разбирательства" уходит от нескольких часов до нескольких дней, и появляется очень большая вероятность совершить ошибку!
Наше решение. Сначала прошу сравнить комментарии трех программистов (примеры из рабочей базы):
Пример 1:
Пример 2:
Пример 3 (наше решение):
Проанализируем:
1. В первом примере видно:
- где начинается комментарий и где заканчивается
- кто сделал изменения
- когда сделаны изменения (правда ошибка в дате)
2. Во втором примере видно:
- кто сделал изменения
- когда сделаны изменения
3. В третьем примере (наше решение) видно:
- где начало комментария и где он заканчивается
- кто сделал изменения
- когда сделаны изменения
Очевидно что третий пример содержит более информативный комментарий, который в полной мере выполняет свою функцию. И самое главное, для чего собственно это всё нужно, оформляя внесенные изменения подобным образом, вы сохраняете их в одном месте. В самом надежном и доступном. В базе данных. Не в файликах Word и Excel, не в сторонних программах типа Итилиума, не в головах пользователей и программистов, а ВМЕСТЕ с вашей базой данных. И даже по прошествию нескольких лет, можно легко извлечь все изменения, провести "инвентаризацию" системы и понять как сейчас она работает!
Как реализовать:
1. Все комментарии делаем однотипными и начинаем строго с символов "//начало-" ( //начало-ДГ ). Таким образом можно легко найти комментарии ВСЕХ программистов. Если нужно найти комментарии только ОДНОГО программиста - в поиске задаётся "//начало-ДГ". "ДГ" - это инициалы фамилии и имени программиста.
(Примечание: а теперь представьте ситуацию где один программист пишет "begin-end", другой пишет "начало-конец", а третий вообще рисует символы ">> <. будет очень сложно их найти.)
2. Указываем дату изменения ( 08.04.2014 .) Иногда приходится доказывать пользователям что изменения начали работать с начала апреля, а не середины мая как они думают. Или нужно понять в какой последовательности изменения появлялись.
3. Указываем кто заказывал это изменение ( Заказчик Пономаренков П. ). По прошествии времени, очень часто забывается кто и зачем придумал это, указание заказчика поможет восстановить в памяти эту задачу. А если вы совсем забыли, или не участвовали в её реализации, можно получить дополнительную информацию непосредственно у заказчика :)
4. Даём краткое название задаче ( Запись реквизита ДД_Наименование_для_сайта_прайса ). Нужно для краткого указания того что делалось, какие были изменения (1) и для идентификации задачи (2). В этом примере, по краткому названию, видно что изменения касаются определенного реквизита (а не движений по регистру накопления например). А также краткое название позволяет найти ВСЕ места, где код менялся по этой задаче (используем копирование при вставке комментария).
5. Делаем подробное описание задачи ( //Нужно чтобы при любой записи элемента, в этот реквизит . и далее). Нужно для понимания того, что и для чего делалось. Для каждого изменения делается свой комментарий (но первая строка у всех одинаковая!), если требуется сделать общее описание, то оно делается в одном месте. Например:
2. Справочная информация
О чём пойдёт речь. Польза от справочной информации думаю также для всех очевидна. Есть только две маленькие проблемы: обычно справка либо не информативна, либо ее попросту нет :) В нашей фирме, справочная информация делается всегда, подробно, и чаще всего ей пользуются. программисты :)
В чём проблема. У пользователей очень часто возникают вопросы типа: "откуда берет данные отчет", "как считает эта обработка", "что проверяется в документе" и т.д. А самое интересное то, что они уже не первый раз работают с этим отчетом/ обработкой/документом. они просто забыли. или сделали вид что забыли.
Как обычно решается. Что в таких случаях делает программист? Начинает вспоминать или лезет в конфигуратор. И хорошо если это делалось недавно, или алгоритм расчета какой-то простой. А если делалось давно, например несколько месяцев назад? Сколько времени надо потратить, чтобы полностью вспомнить реализованный функционал? Иногда до нескольких часов.
Наше решение. В каждом добавленном или измененном объекте есть нами добавленная справочная информация, и именно она позволяет быстро и красиво (прям на глазах у пользователя) ответить на все интересующие вопросы!
Как реализовать. В типовые объекты (справочники и документы) мы вставляем справку выше одинэсовской. Во внешних отчетах и обработках справка содержится как в самом объекте, так в специальном txt-файле (нужен для просмотра справки без конфигуратора). См. скриншоты:
Справка в программе
Справка внешней обработки
3. Цифровые обозначения отчетов/обработок
О чём пойдёт речь. Поговорим о удобстве работы с внешними отчетами и обработками.
В чём проблема. В один прекрасный день мы поняли что у нас в базе содержится огромное количество обработок и отчетов непонятно кем и для кого написанных, и главное, непонятно что они делают. И кроме этого, с ними крайне неудобно работать. Например: звонит пользователь и говорит что у него в отчете (далее следует какое-то название, что-то вроде с продажами) не появляются какие-то данные. Ваши действия: 1. найти отчет 2. вникнуть в то как он работает 3. понять что дальше делать (менять настройки, доработать его, ничего не трогать или что-то еще).
Как обычно решается. На первом же пункте возникает ступор, понять какой из отчетов "по продажам. " (вроде это слово прозвучало) использует пользователь, иногда очень проблематично, особенно в понедельник утром :) Вы начинаете его искать, попутно еще раз пять уточняя название, потому что оказывается что подобных отчетов несколько, а еще пользователь прочёл название отчета на форме, а в программе он называется немного по-другому. В итоге вы наконец находите нужный отчет и переходите к пункту 2.
Тут начинается самое интересное, хорошо если отчет типовой или написан вами, вы хоть будете знать что он делает, а если нет? Нужно как то быстро вникнуть в его суть, можно конечно спросить у пользователя, но пользователь вдруг оказался финансовым директором и ему некогда рассказывать вам об этом отчете, и скорее всего придется лезть в конфигуратор. Открыв отчет в конфигураторе вы вдруг понимаете что. ничего не понимаете. а комментариев в коде как правило немного. А иногда чтобы ответить на вопрос пользователя - нужно очень хорошо понять принцип работы отчета, а это значит досконально вникнуть в его содержимое. И тут многим (особенно начинающим программистам) приходит в голову достаточно простое решение - взять и переписать этот отчет. Но это не всегда возможно, а иногда просто невозможно (поэтому то и ценится умение читать чужой код). В общем решение вопроса начинает затягиваться на неопределенный срок. А тут еще пользователь вас торопит. Наконец-то разобрались, но это еще не всё, нужно еще третий пункт отработать. А через месяц. вам опять звонит этот пользователь и снова задает этот же вопрос, и вы снова проходите по этому кругу. Да-да, так к сожалению очень часто бывает.
Наше решение.
1. Чтобы быстро и дентифицировать отчет (или обработку) мы присваиваем ему трехзначный цифровой код, где первая цифра закреплена за программистом, а две последующие - номер по порядку. А также присвается буквенное наименование показывающее назначение отчета. И когда пользователь говорит вам: "Посмотрите пожалуйста 516 отчет". Вы моментально находите его по цифре "516" и при этом знаете что под цифрой "5" у вас разработку ведет программист Иванов, к которому можно при случае обратиться за разъяснением.
2. Для понимания того как работает отчет, существует справочная информация, она записывается в сам отчет, а также в txt-файл. Файл этот нужен для просмотра справки без открытия отчета в 1С. В справке подробно описывается: принцип работы отчета (1), откуда берет данные (2), как их выводит (3), какие настройки нужно сделать (4), обязательные для заполнения поля (5), различные нюансы (6). В 90% случаев справочная информация позволяет дать ответ пользователю не прибегая к открытию отчета в конфигураторе.
Как реализовать:
1. Название (1), синоним (2), имя на форме (3), название каталога (4) и название txt-файл а (5) всегда должны быть одинаковы. Например: DD_UT_741_Установка_доп_прав_у_пользователей. Где: DD – название компании, UT – название конфигурации, 741 – цифровой код отчета/обработки, «Установка_доп_прав_у_пользователей» - что делает данная обработка. Для удобства копирования слова разделены не пробелами, а нижними дефисами (всё название выделяется одним кликом мыши).
2. Цифровой код состоит из двух частей: 7 – цифра закрепленная за определенным программистом, 41 – номер обработки/отчета по порядку. 1С-вские обработки (измененные типовые) начинаются с «0», обработки неизвестных программистов – начинаются с «8».
3. В каждой обработке/отчете должна быть справочная информация, которая должна быть описана в txt-файле. Также создан специальный каталог для разработчиков где хранятся каталоги с отчетами/обработками. См. скриншот:
Каталог с внешними отчетами и обработками
4. Добавление/изменение объектов
1. При разработке стараемся по максимуму использовать типовой функционал, но при этом стараясь не менять его существенно, чтобы избежать ошибок и проблем с обновлением.
2. Все новые объекты (и реквизиты) добавляются с префиксом. Префикс всегда один и тот же и не привязан к программисту, нас это сокращенное название фирмы - "ДД_" . Например: «ДД_Заявка_покупателя». Благодаря префиксу мы сразу понимаем какой функционал задействован, наш или типовой. Измененные и добавленные объекты добавляются в отдельную подсистему.
3. После изменения типовых объектов (или добавления новых) , таких как справочники, документы – в них добавляется справочная информация с описанием произведенных изменений. Желательно вставлять их выше типовой справки, чтобы в первую очередь читались наши изменения.
5. Контроль за исполнением
Контроль осуществляется периодически, раз в два - три месяца. Для этого выборочно открываются объекты (документы, справочники, обработки), смотрится:
- названия отчетов/обработок в каталоге
- запускается глобальный поиск инициалов/ФИО программистов
Но лучший контроль - это конечно совесть исполнителя поэтому желательно работать с людьми ответственными, за которыми не надо следить!
Ну и напоследок, вернемся к началу:
Нужно ли это руководителю IT. Что будет если уйдут программисты (или пользователи) "носители знаний"? Если возникнет разбирательство кто, зачем, когда внедрил функционал? Если нужно быстро провести ревизию конфигурации? Как быстро передать информацию другим специалистам?
Нужно ли это ведущему программисту. Что будет когда пользователи начнут задавать вопросы по тому функционалу который писал не он, а молодые специалисты или франчайзи? Сможет он быстро ответить на эти вопросы? А если это его доработки, то сможет ли он вспомнить то что делал полгода назад?
Нужно ли это программисту. Есть мнение что чем больше информации скрыто, тем больше ценность человека как специалиста. На деле же получается наоборот, чем больше человек скрывает информации, тем меньше с ним хотят работать, ведь быть зависимым никому не хочется, а при случае - постараются избавиться от этой зависимости. Да и профессионализм этого специалиста явно под вопросом.
Нужно ли это пользователю. Как свести к минимуму количество обращений к программистам если у пользователя элементарно нет справочной информации? Как ему максимально быстро получить ответ на свой вопрос если программисту надо много времени на то чтобы найти его?
Мы для себя давно ответили на эти вопросы. Теперь ваша очередь по новой взглянуть на них :)
Для того, чтобы Вам как заказчику, консультанту или методологу понять, что нужно разработчику 1С для того, чтобы доработать Вашу систему или разработать новую, нужно понимать, какими категориями информации он оперирует в ходе своей работы. Это сильно упростит программисту понимание того, что же от него хотят.
В данной статье я постараюсь кратко и, при этом, достаточно полно объяснить, что Вам нужно написать в техническом задании помимо общих разделов с глоссарием, титульным листом и описанием бизнес-требований.
Данные правила легко соблюдать даже при написании кратких пользовательских историй, если Вы создаете их в рамках проекта SCRUM / Agile.
Итак, приступим.
Для начала вы должны понимать, что же на самом деле в 90% случаев программирует программист 1C:
- Формы ввода информации
- Контрольные процедуры
- Модель данных
- Алгоритмы автоматического заполнения данных
- Формы вывода информации
Формы ввода информации
Это могут быть как формы ввода в систему какой-либо информации (документы, элементы справочников, таблицы с данными), так и формы загрузки этих данных откуда-нибудь по шаблону (например, Excel или XML и другие форматы для интеграции с другими системами).
Не забывайте указывать перечень кнопок-команд, которыми пользователь должен командовать Вашей системой.
Если техническое задание не содержит продуманного Вами заранее прообраза таких форм или шаблонов, то программист будет придумывать их по своему усмотрению, а Вы будете жаловаться, что вам это неудобно в работе.
Контрольные процедуры
В бизнес-процессах эти процедуры являются предварительными контролями, чтобы вам было понятно. Т.е. это такие контроли, которые система делает сама в тот момент, когда пользователь с той или иной ролью пытается работать с системой, и выдает предупреждение или намеренно прерывает работу пользователя, не позволяя ему выполнить задуманное.
В эту категорию попадают:
- Матрицы ролевого доступа
- Правила предоставления доступа к полям форм и данных
- Проверки корректности заполнения данных в формах ввода
- Процедуры сверки данных
Модель данных
Конечно, программист сделает модель данных так, как ему подскажет его опыт на текущий момент. Если программист опытный, он сделает эффективную структуру данных. А если не очень — то не очень.
Если Вы тоже «не очень» программист, то единственное полезное, что Вы сможете в этой части написать для программиста, это будут базовые характеристики модели данных:
- Перечень бизнес-объектов, с которыми имеет дело пользователь и отношения между ними, ссылки на какие объекты в каких объектах должны храниться
- Состав полей данных (табличка в эксель) по каждому бизнес-объекту, у которого есть форма ввода
- Поддержка иерархичности — нужна или нет
- Сколько данных планируется хранить
- Регулярность ввода и изменения этих данных
- Нужно ли хранить в одном объекте несколько таблиц данных, и если да, то с какими аналитиками, будет ли какой-либо другой объект ссылаться на записи этих таблиц
- Поддержка хранения данных с историей по датам — нужна или нет
- Поддержка расчета итогов на какую-либо дату, или оборотов за период — нужна или нет
- Поддержка двойной бухгалтерской записи — нужна или нет
- Поддержка вытесняющих графиков величин во времени — нужна или нет
- Поддержка процессов взаимодействия пользователей по объекту — нужна или нет
Алгоритмы автоматического заполнения данных
Если у Вас формы ввода содержат много полей или таблиц, Ваши пользователи вряд ли захотят каждый раз заполнять все поля с чистого листа.
Здесь Вы должны продумать, какие поля или таблицы могут быть заполнены по другим полям или таблицам этого или других бизнес-объектов.
Так же, здесь Вы продумываете зависимые автоматические заполнения форм ввода в зависимости от только что измененных полей пользователем. Например, после выбора номенклатуры пользователю не надо выбирать ее основную единицу измерения, система подставит ее по-умолчанию сама.
Формы вывода информации
В эту категорию попадают отчеты и формы объектов «на просмотр» или «выбор». Понятное дело, программист не должен сам придумывать форму отчета, которую Вы представляете себе совершенно определенным образом.
Нарисуйте прообраз такого отчета в Excel, желательно, с формулами и комментариями, откуда брать информацию, и вложите в ТЗ. Этого достаточно.
Так же сюда попадают формы выгрузки данных в Excel или XML и другие форматы для интеграции с другими системами.
Формы ввода и вывода часто могут объединяться с алгоритмами заполнения данных и контрольными процедурами в функциональные интерактивные АРМы пользователей, дополняться кнопками, вызывающими определенные действия и события в системе. Тем не менее, к ним применимы те же самые принципы написания технического задания, с учетом этих особенностей.
Обеспечив программиста этим нехитрым набором сведений в техническом задании, вы на 90% застрахуете себя от того, что он сделает что-то не то.
Рассмотрим основные нормы применения и оформления программного кода 1С. Соблюдение данных правил обязательно для получения сертификата 1С:Совместимо.
Общие требования к конфигурации
Для типизированных объектов метаданных, хранящихся в информационной базе, настоятельно рекомендуется не использовать тип ЛюбаяСсылка. Состав типов того или иного типизированного объекта должен определяться явным образом.
Для типизированных объектов метаданных строкового типа рекомендуется использовать переменную длину строки. Свойство «Фиксированная длина» может устанавливаться только в тех случаях, когда действительно необходимо при манипуляции этими данными иметь гарантию, что строка имеет определенную длину, даже несмотря на наличие концевых пробелов.
Подчиненные объекты метаданных, такие как реквизиты, измерения, формы, располагаются в дереве метаданных в соответствии с проектной логикой.
Для оптимизации тех или иных отчетов или для оптимизации выполнения отбора и сортировки в формах списков возможно использование индексирования. При этом индексирование следует использовать сдержанно, так как увеличение числа индексов приводит к дополнительной нагрузке на систему при записи данных и увеличивает объем базы данных.
Имя, синоним комментарий
Многократное выполнение запросов
Если вы только начинаете программировать в 1С или просто хотите систематизировать свои знания - попробуйте Школу программирования 1С нашего друга Владимира Милькина. Пошаговые и понятные уроки даже для новичка с поддержкой учителя.
Попробуйте бесплатно по ссылке >>
Рекомендуется получать все необходимые однотипные данные одним запросом вместо выполнения серии запросов.
Проверка на пустой результат выполнения запросов
Проверку того, что результат выполнения запроса не содержит строк, следует выполнять с помощью метода Пустой(). Поскольку на получение выборки из результата запроса (выгрузка его в таблицу значений) будет затрачиваться дополнительное время.
Оформление текстов запросов
Использование строк неограниченной длины
Для хранения строк, максимально возможная длина которых заведомо известна, используются строковые реквизиты с длиной, равной максимально возможной.
Когда максимально возможная длина строки неизвестна, для хранения используются строковые реквизиты неограниченной длины.
При этом следует помнить о некоторых ограничениях, возникающих при использовании полей неограниченной длины в языке запросов.
Программное управление формой
В разделе инициализации модуля формы запрещается открывать другие формы или диалоги (например, операторами Вопрос(), Предупреждение() и т. д.).
Программное управление формой из других модулей производится через присвоение её реквизитам (свойствам) значений и через вызов её методов или экспортных процедур (функций).
Не допускается делать предположения о свойствах реквизитов формы.
Обращение к данным информационной базы в обработчиках часто вызываемых событий
Следует минимизировать обращение к данным информационной базы в обработчиках событий, приведенных ниже, поскольку это может существенно замедлить интерактивную работу.
События табличного поля:
В качестве средств минимизации в зависимости от ситуации могут быть:
Требования по локализации модулей
Для этого необходимо применять функцию НСтр() вместо прямого использования строковых литералов. Иное использование строк, предназначенных для пользовательского интерфейса, не допускается.
В том случае, если строка является составной и включает в себя части, зависящие от тех или иных условий, настоятельно рекомендуется использовать логически завершенные, целостные фразы. Для формирования переменной составляющей строки при этом необходимо применять замену подстрок по определенным правилам. При этом можно использовать как функцию СтрЗаменить, так и предусмотреть в конфигурации специально предназначенную для этого функцию.
В функции НСтр() строка ограничивается символами одинарных кавычек.
Такое требование обусловлено частым использованием двойных кавычек в строковых литералах.
В том случае, если все же применяется не замена строк в строке-шаблоне, а сложение строк, то неязыковые символы (пробелы, табуляция и пр.) в начале и конце строк необходимо выделять в отдельные строковые литералы.
Правильно:
В редких случаях строковые литералы из текстов запросов также могут оказаться частью пользовательского интерфейса. В таких случаях строковые литералы необходимо выносить из текста запроса в параметры.
Тексты модулей
Тексты модулей должны быть написаны на русском языке.
Размер табуляции стандартный (4 символа).
Программные модули не должны иметь неиспользуемых процедур и функций.
Программные модули не должны иметь закомментированных фрагментов кода.
Текст модуля должен быть оформлен синтаксическим отступом. Для синтаксического отступа используется табуляция.
С крайней левой позиции должны начинаться только:
Процедуры НачатьТранзакцию() и ЗафиксироватьТранзакцию() не являются операторными скобками, поэтому текст внутри этих процедур не сдвигается.
При длине строки более 120 символов следует использовать переносы. Строки более 120 символов делать не рекомендуется, за исключением тех случаев, когда перенос невозможен.
Тексты модулей должны содержать комментарии.
Небольшие комментарии пишутся в конце строки, которую комментируют, например:
Большие комментарии или комментарии к фрагменту кода пишутся перед комментируемым кодом в отдельной строке.
Структура модулей
В программном модуле в общем случае могут присутствовать следующие разделы в приведенной ниже последовательности:
- заголовок модуля;
- раздел описания переменных;
- процедуры и функции модуля;
- обработчики событий элементов формы;
- обработчики событий;
- раздел инициализации.
Некоторые разделы могут присутствовать только в модулях определенного вида. Например, обработчики событий элементов форм могут присутствовать только в модулях форм, а раздел описания переменных и раздел инициализации не могут быть определены в неглобальных общих модулях, модулях менеджеров объектов, наборов записей, значений констант и модуле сеанса.
Заголовок модуля
Заголовок модуля представляет собой комментарий в самом начале модуля.
В заголовке модуля приводится его краткое описание и условия применения.
Для общих модулей заголовок является обязательным.
Раздел описания переменных
Экспортные переменные модуля должны быть снабжены комментарием, достаточным для понимания их назначения. Для не экспортных переменных наличие комментария желательно, но не обязательно.
Комментарий рекомендуется размещать в той же строке, где объявляется переменная.
Процедуры и функции модуля
Процедуры и функции, которые не являются обработчиками событий, размещаются сразу же после описания переменных. Процедуры и функции, связанные между собой по характеру работы или логике работы, рекомендуется располагать вместе.
Обработчики событий элементов формы
После процедур и функций в модуле формы располагают обработчики событий элементов формы. Рекомендуется обработчики одного элемента формы располагать вместе, придерживаясь при этом порядка их следования в описании встроенного языка.
У каждого события должен быть свой обработчик. Если одинаковые действия должны выполняться при возникновении событий в разных элементах формы, следует:
- создать отдельную процедуру (функцию), выполняющую необходимые действия;
- для каждого элемента формы создать отдельный обработчик с именем, назначаемым по умолчанию;
- из каждого обработчика вызвать требуемую процедуру (функцию).
Обработчики событий
Последними из процедур располагаются обработчики событий модуля (формы, объекта, менеджера объекта и т.д.). Для них также рекомендуется придерживаться порядка следования, приведенного в описании встроенного языка.
Раздел инициализации
Раздел инициализации содержит операторы, инициализирующие переменные модуля или объект (форму).
Описание процедур и функций
Процедуры и функции рекомендуется комментировать.
Обязательного комментирования требуют экспортные процедуры и функции.
Прочие процедуры и функции, в том числе обработчики событий, рекомендуется комментировать, если требуется пояснить назначение процедуры (функции) или особенности её работы. Если процедура (функция) не сложна для понимания и ее назначение и порядок работы следуют из ее названия и имен формальных параметров, комментарий можно не писать. Следует избегать комментариев, не дающих дополнительных пояснений о работе процедуры (функции).
Комментарий размещается перед объявлением процедуры(функции) и имеет следующий формат:
Содержит словесное краткое описание назначения и/или принципов работы процедуры(функции).
Исключение составляют функции, которые предназначены только для проверки истинности некоторого факта и которые возвращают в качестве результата проверки значение типа Булево.
Имена таких функций образуются из написания проверяемого факта.
Например, если функция должна проверить, что в переданной строке присутствуют только цифры, то она может называться ТолькоЦифрыВСтроке().
Описание процедур и функций должны отделятся друг от друга в тексте модуля пустыми строками.
Правила образования имен переменных
Имена переменных следует образовывать от терминов предметной области таким образом, чтобы из имени переменной было понятно ее назначение.
Имена следует образовывать путем удаления пробелов между словами. При этом каждое слово в имени пишется с прописной буквы. Предлоги и местоимения из одной буквы также пишутся прописными буквами.
Имена переменных запрещается начинать с подчеркивания.
Имена переменных не должны состоять из одного символа. Использование коротких имен переменных допускается только для счетчиков циклов.
Переменные, отражающие состояние некоторого флага, следует называть так, как пишется истинное значение этого флага.
Перенос выражений
Длинные арифметические выражения переносятся следующим образом:
- в одной строке может находиться более одного операнда;
- при переносе знаки операции пишутся в начале строки (а не в конце предыдущей строки);
- операнды выравниваются по началу первого операнда, без учета знаков операций.
При необходимости параметры процедур, функций, методов могут переноситься следующим образом:
Сложные логические условия в Если…ИначеЕсли…КонецЕсли могут переноситься следующим образом:
- каждое элементарное условие может начинать новую строку:
- логические операторы И, ИЛИ ставятся в начале строки, а не в конце предыдущей строки;
- все условия выравниваются по началу первого условия, без учета логического оператора;
- ключевое слово Тогда пишется на той же строке, что и последнее условие.
Определение типа значения переменной
Определение типа значения переменной необходимо выполнять путем его сравнения с типом, а не каким-либо другим методом.
Правильно:
Получение метаданных объектов
Сортировка таблиц значений
В тех случаях, когда для таблицы значений применяется сортировка по колонкам, содержащим ссылочные значения, необходимо учитывать, что при этом для каждой из этих колонок для всех строк таблицы значений системой будет выполнено обращение к информационной базе за представлением этой ссылки.
Поэтому для таблиц с большим количеством (несколько сотен и тысяч) строк, особенно в алгоритмах, критических ко времени исполнения, рекомендуется сразу, на этапе заполнения, добавлять в таблицу дополнительные колонки с представлениями и сортировку выполнять уже по ним. Если, конечно, это не вызовет аналогичных многократных обращений к информационной базе.
Использование объекта РегистрСведенийМенеджерЗаписи
Чтение записи (набора записей) из регистра сведений без последующей модификации необходимо выполнять запросом.
Во всех остальных случаях объект РегистрСведенийМенеджерЗаписи следует применять только тогда, когда выполнение операций с регистром сведений требует использования отбора одновременно по всем измерениям. При этом менеджер записи использует для выполнения записи два набора записей, устанавливая им соответствующие значения отборов. Поэтому обработчики событий набора записей вызываются и тогда, когда для записи данных используется менеджер записи.
Копирование строк между таблицами значений произвольной структуры
При копировании строк между различными таблицами значений (табличными частями и т.п.) со схожим составом колонок следует использовать метод глобального контекста ЗаполнитьЗначенияСвойств().
Алгоритмы, использующие данный метод, значительно эффективнее, например, многократного перебора колонок таблицы значений, выполняемого для получения их состава.
Получение представлений для ссылочных значений в табличном документе
Поэтому в качестве параметров следует указывать сами представления.
Исключением могут быть случаи, когда для получения представлений придется выполнять аналогичное многократное обращение к базе данных.
Это может приводить к увеличению времени выполнения запроса (и как следствие, общего времени формирования итогового документа), а при большом количестве типов – к невозможности его выполнения в клиент-серверной версии из-за ограничения Microsoft SQL Server, по которому в запросе не может участвовать больше 256 таблиц. Такие случаи также могут быть исключением для данного правила, в них представления для ссылочных значений допускается получать в момент их вывода в табличный документ.
Поскольку однозначно рекомендовать, какой из способов получения представлений следует выбрать, нельзя, такой выбор должен делаться разработчиком самостоятельно, на основании данных, полученных экспериментально.
Программное создание прикладных объектов
Для программного создания прикладных объектов следует использовать методы соответствующих менеджеров (СоздатьЭлемент(), СоздатьДокумент(), СоздатьНаборЗаписей() и т.д.)
Для программного создания прикладных объектов, у которых существует соответствующие менеджеры объектов, использование конструктора (оператор встроенного языка Новый) запрещается.
Особенности контекстного выполнения на сервере и в режиме внешнего соединения
При разработке кода общего модуля и модулей объектов, которые должны быть доступны на сервере и во внешнем соединении, следует соблюдать следующие правила:
1. Запрещено использование объектов, имеющих тип данных, недоступный на сервере и во внешнем соединении:
- ТабличныйДокумент
- ТекстовыйДокумент
- ДиалогВыбораФайла
- все другие типы, использование которых невозможно на сервере 1С:Предприятие и во внешнем соединении.
2. Запрещено использование средств, отвечающих за диалог с пользователем:
- Предупреждение()
- Вопрос()
- методы работы с формами и прочие, для которых специально указано (в документации), что они не доступны на сервере и/или во внешнем соединении.
3. Запрещается вызов экспортных процедур других общий модулей, у которых не установлен признак компиляции на сервере и/или во внешнем соединении.
4. Участки кода, в которых используются конструкции, не доступные на сервере или во внешнем соединении, должны выделяться соответствующими инструкциями препроцессору, например:
5. При написании кода модулей объектов, которые исполняются на сервере или доступны во внешнем соединении, недопустимо использовать переменные, процедуры и функции, которые определены в модуле обычного приложения и в модуле управляемого приложения.
6. Для сервера: Надо учитывать, что при передаче управления с клиента на сервер, а также в обратную сторону, существует ограничение на тип передаваемых параметров. Поэтому в качестве параметров процедур (функций), а также возвращаемых значений функций, выполняемых на сервере, следует использовать значения примитивных типов, ссылки на объекты базы данных, системные перечисления, уникальный идентификатор, результат запроса, хранилище значения, таблицу значений, массив, структуру и соответствие, при этом состав передаваемых коллекций также должен удовлетворять приведенным выше ограничениям.
7. Для внешнего соединения: Текст модулей объектов следует писать таким образом, чтобы при работе во внешнем соединении (в частности, при работе WEB-приложения), обеспечивалась работоспособность всей прикладной логики с учетом того, что часть объектов недоступна для использования во внешнем соединении, например, использование средств диалога с пользователем. Недопустимо размещать в общих модулях процедуры и функции, которые недоступны во внешнем соединении и без которых невозможна запланированная методика использования и работы объектов.
Читайте также: