Менеджер 1с что это

Обновлено: 05.07.2024

Ветка "Справочники".
Справочник "Номенклатура". ("лист ветки")
Записи в справочнике "Номенклатура".

Менеджеры существуют у веток, "листьев", каждой записи (хотя странно)?

нет, менеджеры существуют только у "объектов". У справочника нет ни "листьев", ни "веток", ни "записей" (записи - это в регистрах), а есть только элементы.
Вы пытаетесь с понятиями настоящего ООП подойти к "объектам" 1С: "ага, если есть объект СправочникиМенеджер - значит, он автоматически содержит объекты "Справочник" (пусть и "СправочникМенеджер" - может, 1с его просто так обозвала?!), СправочникСсылка (запись справочника - т.е. элемент справочника), и "СправочникВыборка"; если объект Регистр - автоматически содержит объект "Запись" и т.д.
Тут, конечно, можно поговорить об так называемом "разъименовании" объектов (получении данных объекта по ссылке через точку),

но это именно и есть "получение данных объекта по ссылке": формирование запроса на получение данных и соединение нескольких таблиц для вывода искомого. Откуда и тормоза в запросах (и не только - в частности, при использовании в тех же Выборках) при разъименовании, и категорический запрет на использование в запросах "двойного разъименования" (Объект.Свойство<содержащее СсылкуНаДругойОбъект>.СвойствоДругогоОбъекта) - а только явное соединение таблиц через СОЕДИНЕНИЕ.
А на самом деле в 1С нет настоящих "объектов" ООП (с чем я и пытаюсь бороться постоянно - чтобы не путали и не называли одним и тем же словом совершенно разное, или, хотя бы, понимали, что объекты в ООП и в 1С - это не одно и то же, а лишь названо одним термином; а для 1С, видимо, выгоднее, чтобы путались, и думали: "объекты" же есть, - значит - ООП!). В 1С, собственно, и введено внутренее понятие КоллекцияЗначений - а это не есть аналог контейнера объектов из ООП (который и сам определяет поведение входящих объектов, и дает доступ напрямую к ним - к их свойствам, методам, данным, событиям и т.д.), а набор ссылок на другие объекты, и из коллекции, если не получен "вложенный" элемент-объект (например, через метод НабораЗаписей "НаборЗаписей.Прочитать()" ), нельзя напрямую получить свойства и методы элементов коллекции, а только - получить "объекты" коллекции, и уже обходом или обращением к элементу коллекции - работать со свойствами и методами "вложенных" объектов. Объект РегистрСведений не содержит объект РегистрСведенийНаборЗаписей, а НаборЗаписей не содержит объекты РегистрСведенийЗапись. Для работы с каждым вложенным уровнем так называемых "объектов" - нужно получать объекты этого нового уровня вложенности.
Собственно, вся канитель "не могу получить данные объекта там-то", "не могу получить доступ к процедуре тут-то", "не видна переменная экспортная такая-то" и прочие невообразимые и множественные ограничения платформы - именно из-за наборов не связанных напрямую друг с другом "объектов", которых нужно каждый раз "получать", извлекать данные, и которым нужно каждый раз указывать - что мы от них хотим.
Возратимся к МенеджеруСправочников.
МенеджерСправочников ничего не делает, кроме как дает доступ к МенеджеруСправочника, который управляет объектом Справочник (но это не объект "СправочникОбъект"!).
А СправочникОбъект - это отдельный объект, не упомянутый выше объект Справочника целиком - как мы можем подумать, прочитав про "объект" (тот, выше упомянутый, просто предоставляет доступ к объекту конфигурации Справочник<такой-то> (т.е., можно сказать, к "описанию типа" справочника в конфигурации) - и здесь мы можем, например, создать Элемент справочника или группу, а вот СправочникОбъект - возвращает нам непосредственно конкретный созданый объект Справочник<такой-то> для работы с ним: удалить элемент, редактировать, прочитать свойства, обработать события), а объект Справочник (МенеджеруСправочника) является лишь "частью" общего формального понятия "Объект" (только лишь понятия, а не реализации такового в 1С!), если так можно сказать, оформленная в виде отдельного "объектика", и уже некоторые из них - собраны в "коллеции".
Надеюсь, что за "объектики" и как они "часть целого понятия" - я объяснил доступно: например, создаем новый элемент справочника в его "формальном" описании - в СправочникМенеджер, а вот работаем с конкретными элементами "как с настоящим объектом" - увы, уже в СправочникОбъект.
Есть еще и СправочникСсылка - еще один "объект", хоть и предоставляющий (как бы "содержащий") ссылку на конкретный объект СправочникОбъект, но сам являющийся отдельным и "независимым" объектом конфигурации со своими свойствами, методами и конструктором.

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

Создать менеджер регистра сведений достаточно просто, например:

Хочу заметить, что работать с менеджером регистра сведений можно или в толстом клиенте, или в серверном контексте. В тонком клиенте код, написанный в этой статье работать не будет!

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

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

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

Переменные, которые присваиваются полям регистра в моем случае это реквизиты управляемой формы 1С.

Относительно периода замечу, что платформа самостоятельно изменит текущую дату на дату начала периода, который установлен в свойстве периодичность регистра сведений (если периодичность месяц, а в период передана дата 21.12.2017, то запишется 01.12.2017).

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

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

В этом случае наш код изменится.

В этом случае мы присваиваем значения ключевым полям (измерениям) и периоду. А после применяем метод Прочитать. Данный метод считывает записи с регистра по указанным ключевым полям (измерениям) и периоду. Если есть записи с данным набором полей, то метод Выбран возвращает Истину, иначе – Ложь. В Вашем примере, если метод Выбран вернул значение Ложь (записей нет), то мы присваиваем значения измерениям и ресурсу и записываем.

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

Отличное пособие по разработке в управляемом приложении 1С, как для начинающих разработчиков, так и для опытных программистов.

Очень доступный и понятный язык изложения
Книга посылается на электронную почту в формате PDF. Можно открыть на любом устройстве!
Поймете идеологию управляемого приложения 1С
Узнаете, как разрабатывать управляемое приложение;
Научитесь разрабатывать управляемые формы 1С;
Сможете работать с основными и нужными элементами управляемых форм
Программирование под управляемым приложением станет понятным

Если Вам помог этот урок решить какую-нибудь проблему, понравился или оказался полезен, то Вы можете поддержать мой проект, перечислив любую сумму:

можно оплатить вручную:

СправочникМенеджер - что это такое, никак не могу привыкнуть в синтакс-помощнике к такой формулировке. Что это означает если по простому?

СправочникМенеджер это просто указатель на элемент метаданных справочник.

(3) Как мне это ипользовать для работы?
Например,
СправочникМенеджер.Ссылка = Номенклатура.Ссылка? Так?

(4) нет, слова "Менеджер" вообще нету. Просто для себя условься, что слово "менеджер" означает, что можешь использовать определенные функции

(5) То есть Справочник.Ссылка? Справочник.Выборка? Так? А "менеджер" опускаем? Верно?

(7) КонстантаМенеджер.<Имя константы> (ConstantManager.<Имя константы>)
Вот эта запись равна записи такой:
Константы.НаименованиеОрганизации.Получить() ?

Константы.НаименованиеОрганизации - вот это менеджер в данном случае.

(10) Читай, читай доукментацию, описалово, учебники. ОдинСэ это как бы предполагается среда более высокого уровня чем те, которым в ВУЗе учили, ну и с поправкой на область, естественно. Есть специфические моменты и допущения.

(0) понять сие невозможно. Можно только привыкнуть.
СправочникМенеджер - это класс. Который как бэ есть, но конректно по этому имени обратиться к нему нельзя.
СправочникМенеджер это Справочники["МойСправочник"]
СправочникОбъект это МойЭлементМоегоСправочника.ПолучитьОбъект()
Все.

(8) Нет.
Константа.НаименованиеОрганизации - это объект.
А когда .Получить() - получаешь то значение, которое глубоко в душе хранит этот объект.

(0) Пройдите (хотя для начала полистайте) курс "Основные объекты" или нулевой блок на известном ресурсе, он там бесплатный

(0) Менеджер справочника позволяет проводить с ним манипуляции, как с множеством (правда, с некоторыми ограничениями)

(17) Класс - модель общего поведения множества объектов. Например, класс справочники. Объект класса - справочник.

(21) Я просто после 7 сразу 8.2 изучаю, подумал, что менеджеров только в 8.2 ввели.

Это наподобие абстрактного метода который относится к классу в целом а не к конкретному экземпляру объекта.
наподобие
public abstract void <имя метода>()

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

> Класс - модель общего поведения множества объектов. Например, класс справочники.

Справочники это же метаданные. Значит класс это метаданные, понятно.

Откуда это все пошло? С западной части США. Почему оттуда? Потому что именно там, в Юте, был утвержден Agile Manifesto с его «product owner» в 2001-м. Потому что именно благодаря Сан-Франциско и его «Силиконовой долине» в начале 21 века стало широко распространено понятие «стартап», и именно в стартапах возникла глобальная потребность в «product managers». И именно там находится штаб-квартира «Яблока», продемонстрировавшего миру, что может случиться, если продуктом займется хороший product manager.

Ладно, так кто же такой менеджер продукта?

Согласно Википедии – «…человек, отвечающий за создание новых продуктов, анализ рынка, ассортиментную политику и бла-бла-бла…». Или вот еще: «…задача продукт-менеджера — определить концепцию продукта и стратегию его развития. Продукт-менеджер задает критерии успеха и принимает решения…». Уже лучше, но все еще водянисто. Нужно проще.

Смотрим в историю. Когда появились продукт менеджеры? Тогда, когда очевидные потребности людей уже были удовлетворены и необходимо было найти или создать новые. Когда тысячи стартапов пробовали делать десятки тысяч разных продуктов и никто не мог сказать, какой из них будет нужен потребителю. Они даже не знали, кто их потребитель. Короче, всем нужен был ответ на вопрос «ЧТО делать?». И менеджеры продуктов его дали.

Итак, менеджер продуктов — это про «ЧТО». Если смотреть через призму проектного управления, то это про содержание. Например, в PMBoK разделяют project scope и product scope , потому что первое, это все-таки про «как», а вот второе, это как раз «что». Кстати, про проектное управление…

Чтобы никто не путался, сразу определим разницу между менеджером продукта и менеджером проекта:

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

Часто говорят, что менеджер продукта отвечает за то, чтобы «делать правильные вещи», т.е. за результат, а менеджер проекта за то, чтобы «делать эти вещи правильно», т.е. за эффективность. Ну че тут сказать, правильно говорят, чертяги.

Как правило, эти двое, если они работают вместе, балансируют на грани того, чтобы навалять друг-другу, потому что один всегда хочет сделать лучше, а другой – быстрее и дешевле. Но это, в целом, не мешает им делать хорошие продукты.

Для закрепления образа менеджера продукта вспомним еще одного крутого типа:

А вот реально, что? И как этому научиться? Вот тут появляются проблемы. Менеджер продукта – это созидатель, человек творческий. Как можно научиться творчеству? Очень долго время люди считали, что способность творить – это дар, ему невозможно научиться. Сейчас процесс творчества стал лучше детализирован, появились определенные технологии сбора информации с потребителей, людям помогают развивать эмпатию, благодаря которой они могут лучше понять потребителя. Т.е., в-принципе, тут есть чему поучиться.

И все же это далеко не Body of Knowledge, как PMBok. Есть ощущение, что такого свода знаний для менеджеров продуктов не появится, и искать идеальный набор скиллов для менеджера продукта придется каждому самостоятельно, ну или в небольших кучках. А это уже сам по себе творческий процесс. Поэтому если Вы не можете по достоинству оценить Бетховна, Курта Кобейна,и Эминема (именно всех троих) - не мучайтесь, в Вас нет чувства прекрасного, и менеджером продукта, Вам, скорее всего, быть не удастся.

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

И все-таки попробуем определить, что должен делать менеджер продукта, чтобы успешно отвечать на вопрос «Что?».

Так что же должен делать менеджер продукта?

c. Точно определять, что именно должно быть сделано (еще раз, для быстрых, «ЧТО», а не «КАК»), причем выражать свою мысль письменно; d. Описывать требования к продукту и всегда держать это описание в актуальном состоянии; e. Разрабатывать презентации и инструкции для тех, кто продает продукт, помогать им продавать.

Это если коротко. Заметьте, тут достаточно много скиллов, которые могут быть оценены только субъективно. Как, например, понять, слышит этот чел потребителя или нет? Как вообще отличить хорошего менеджера продукта от плохого, например, на собеседовании? Тут сильно поможет обращение к прошлому опыту:

Какие продукты у него были ранее?
Были ли они успешны?
Если нет, то почему?
Что он про это говорит?
Ищет он проблему в себе, или списывает на обстоятельства?

Но давайте, все-таки, разберем эти 5 пунктов. По буковкам.

Тут все просто. Чтобы ответить на вопрос ЧТО, нужно знать, для КОГО, а также понимать, чего им пока не предложили остальные. Найти, у кого проблема, понять, кто его проблемы пытается решать, и почему у них не получается.

Не нужно быть богом, нужно быть чиновником. Нет, не в том плане, что бюрократом, хотя об этом еще будет дальше, а в том, что чиновник, по замыслу – слуга народа. По-английски, кстати, так и звучит: «civil servant». Нужно быть гипервнимательным к тому, что говорят потенциальные клиенты, и реально хотеть им помочь. Нужно слышать, что говорят продажники, и помогать им тоже. Нужно учитывать, что говорят разработчики. Помогать не обязательно. Шутка.

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

Точно определять, что именно должно быть сделано.

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

Если в требованиях есть какие-то неопределенности, которые нужно снять – нужно снять их. Не можете сами – попросите кого-нибудь поработать аналитиком.

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

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

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

Разрабатывать презентации и инструкции для тех, кто продает продукт

Если Вы не можете продать этот продукт, то, наверно, никто не сможет. Но, даже если Вы его продаете, нужно еще научить этому продажников. Часто это напоминает обучение обезьянок тому, как носить очки. Представляю, как обучал продажников Форд:

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

Так что дружимся, учим, помогаем. Да и если приглядеться, продажники – классные ребята, хоть и другие.

Каким командам нужен менеджер продукта?

От красивых сказок идем ближе к реальности. Где будет востребован такой герой? Смотрим исключительно на рынок 1С.

a) 1С и партнеры-разработчики.

Точно не будет лишним в продуктовой разработке. Думаю, если бы у каждого продукта, выпускаемого 1С и партнерами, был хороший продукт-менеджер, они бы не выглядели так:

Ведь можно делать так:

Да и сами продукты были бы более сфокусированы на проблемах клиента. Ведь проблема существующих продуктов 1С и Ко именно в этом – не всегда понятно, для кого они сделаны. Достаточно часто на партнерском форуме приходится слышать от разработчиков 1С ответ «Мы учтем ваши пожелания, но непонятно, когда мы это сможем сделать». И такой ответ встречается на вполне разумные пожелания, поддерживаемые множеством участников форума.

Одна из основных сложностей 1С в этом плане – необходимость разрабатывать максимально широко применимые продукты. Очень сложно угодить толпе, и уж тем более утопично пытаться прислушиваться к ней. В итоге, если попробовать нарезать разработку продукта слоями, в случае с 1С получится модель «Анархия разработчиков»:

Многие партнеры 1С, кстати, наоборот, неплохо понимают потребности их клиентов. Их продукты более узкоспециализированы, а значит, понять, что именно должен давать продукт пользователю, существенно проще. Но у них, к слову, есть другая проблема, приводящая к модели «Красиво, но опасно»:

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

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

b) Проектные команды.

Казалось бы, а зачем оно им? Они же не разрабатывают продукты.

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

Во-вторых, в проектах, независимо от того, по какой технологии они выполняются, должен быть кто-то, ответственный за систему, за то, чтобы она удовлетворяла требованиям, снятым с заказчика. И это точно не РП. Этот кто-то – не совсем менеджер продукта. Он еще не говорит самостоятельно, ЧТО должно быть сделано, он, как правило, узнает это у клиента, у одного конкретного клиента. Но может повлиять на это решение, подсадив клиенту пару идей, или высказав свое авторитетное мнение. Этакий эксперт-методолог. Это и есть будущий менеджер продукта.

c) Продавцы и разносчики ~~пиццы~~ ИТС и коробок 1С.

Им не нужно. Точка.

Вместо красивого конца:

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

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

Читайте также: