К сожалению доменная авторизация в мобильной платформе пока не поддерживается.
Есть обходной путь (не очень изящный), к которому прибегают некоторые.
Заводят в ДО пользователей с именами «домен+имя пользователя» и паролем, идентичным паролю соотв. пользователя в Windows.
Делают публикацию на веб-сервере (отличную от публикации для веб-клиента, если такая есть) с выключенной опцией «Идентификация ОС».
И подключают мобильных клиентов к этой публикации.
Возможности по дизайну интерфейсов настолько сильно ограничены
А чего именно вам не хватает в интерфейсе?
Понятно, что 3D-игру на мобильной платформе не написать, у нее другое предназначение.
Я до сих пор при создании мобильных приложений на 1С: Предприятии не сталкивался при создании интерфейса с непреодолимыми проблемами.
Давайте обсудим — чего, по вашему мнению, не хватает для написания конкурентоспособных приложений.
Быстродействие — от удовлетворительного до хорошего. По части обмена данными — хорошее. Подробнее об этом в следующей статье, так что пока вкратце: мобильное приложение «Торговый Агент», прайс-лист (20 000 элементов, 18 000 из них с фотографиями, 150 000 характеристик) грузятся на устройство по WiFi за 10 минут.
Работу со сканерами ШК, думаю, можно будет реализовать через внешние компоненты (будет реализовано в обозримом будущем).
А работа с FTP — с мобильных сильно востребована? Можете привести бизнес-кейс?
Спасибо!
Переводчик с русского на английский должен русский знать, поэтому не понятная сама постановка вопроса. Разобраться же с тем, что значит и для чего используется каждый параметр проще, если у параметров осмысленные названия, а не цифры. В приведенном примере, заменим все на цифры
(«ru = 'Номенклатура %1 %2 Превышен оперативный складской остаток на складе “%3 на %4 %5");
Вот смотрит переводчик на эту строку. Что может означает параметр 2? Нужно ли между параметром 1 и 2 вставлять какие-то предлоги, артикли и т.п… И вообще последовательность параметров в сообщении может зависеть от языка. То, что на русском корректно сначала назвать чего не хватает, а потом сказать где не хватает, не означает, что в другом языке это будет корректно, где-то более естественным будет определенный порядок. Значит переводчику может понадобиться параметры в сообщении перечислить в другом порядке. И ему, переводчику, будет легче оперировать осмысленными названиями.
Так же и разработчикам. Ошибку, что ты в сообщении неправильно сделал замену, и написал
%НоменклатураХарактеристика% заменить на Выборка.Склад
намного проще, чем проверить, что ты номенклатуру и склад при замене не перепутал местами.
Но это все, если мы говорим о переводе на другой язык только пользовательского интерфейса. Если же мы говорим о переводе на английский кода конфигурации, то тем боле вопрос не понятен — переводить нужно все, все имена переменных. В т.ч. переменную %НоменклатураХарактеристика%. Если будет решен вопрос, как переводить другие имена других переменных, то так же нужно будет поступать и с этими.
1. Кем она разрабатывается? Неужели вы ее разрабатываете в редакторе графических схем внутри СППР? Это ведь абсолютно неудобное средство, например по сравнению с BPWin. Как вы переносите элементы с уровня на уровень?
Разрабатывается отвественными за проекты и/или тим-лидами. Правим внутри СППР. Средство для редактирования схем действительно не самое удобно, но нам для схемы самое важное — это даже не графическое представление, а связи с объектами данных, которые мы храним в соотвествующем справочнике СППР. Можно, конечно, подумать об интеграции, скажем, BPWin и СППР, чтобы схемы править с помощью графического редактора BPWin и потом каким-то образом связывать элементы схемы со справочниками СППР, но не факт что эта связка будет хорошо работать, к тому же тогда СППР перестанет быть самодостаточным продуктом. Сейчас мы рисуем схемы в СППР, СППР же делает формальные проверки этих схем (ну, например, что связи родительской схемы и дочерней не противоречивы).
Вопрос по перенос элементов с уровня на уровень не понятен. В СППР есть средства для создания дочерних схем на основе родительских — см. контекстное меню в редактора схем в СППР.
2. Вы написали, что в СППР вносятся изменения на этапе 3, при этом на этапе 5 проект может быть не готов в включению в очередной релиз. То есть изменения вносятся в какую-то ветку СППР, а затем каким то образом переносятся в основную ветку?
В СППР нет веток. Информация, отраженная там соотвествует не выпущенной версии, а разрабатываемой. Справку мы пишем в СППР уже после заливки проекта в основное хранилище, поэтому по справке не опережения выпуска, а схемы актуализируем до заливки, поэтому выпущенные схемы могут опережать выпущенный функционал.
3. Кто пишет справку, сами разработчики или отдельные технические писатели. Как синхронизирована встроенная справка и документация?
Справку пишут разработчики в СППР в рамках этапа заливки в основное хранилище, технические писатели ее проверяют в СППР (являются согласующими всех технических проектов). Заливка справки из СППР в хранилище делается централизировано в процессе сборки релиза. Документацию пишут технические писатели.
4. Как разработчики ERP смирились с тем, что запись конфигурации после небольшого изменения занимает от 40 секунд (при работе на сервере приложений) до 3 минут при файловой базе?
«Привычка свыше нам дана...» Только у нас наблюдения другие — с файловой базой, размещенной локально, конфигуратор при разработке работает быстрее, чем с клиент-серверной. А цифры примерно те же.
5. Почему в состав конфигурации входит регламентированная отчетность, которая занимает огромную часть из указанного вами объема строк кода и которая может поставляться отдельной поставкой и также отдельно обновляться?
Обновления поставляются в виде одного файла. В него входит и регл. отчетность, и, например, драйверы оборудования. Раньше все поставлялось отдельно. Это единое решение для всех конфигураций нового поколения. Так проще с организационной точки зрения, а также уменьшает количество ошибок при обновлении: ну, скажем, раньше приходилось разбираться с ошибками, что комплект отчетности подключили к версии конфигурации, которая не может с ним работать. Вообще современная тенденция — программы обновляются автоматически, ничего у пользователя не спрашивая, поэтому вообще пользователю не принципиально, какими файлами это обновление приходит. Конечно, мы понимаем, для систем уровня ERP автоматическое обновление (по крайней мере пока) скорее утопия, чем реальность. Но стремиться к этому нужно.
Так же, при изменении отчетности достаточно часто меняется не только сама отчетность, но и учетные механизмы. Например, поменяли форму журнала учета счетов фактур. Но при этом ФНС поменяла не только форму, но и иструкцию по заполнению, поэтому пришлось дописывать не только «заполнялку» регл. формы, но и учетные механизмы.
6. В СППР есть поле оценка. Кто ее выполняет и контролирует. Есть ли анализ, почему оценка была превышена, есть ли какие-то штрафы для разработчика, регулярно превышающего оценку?
Не очень понятно, о какой оценке идет речь. В СППР есть задачи, в задачах есть трудоемкость. Трудоемкость согласует рукововодитель разработки. В конце месяца делается план-фактный анализ — сколько сотрудник трудоемкости согласовал и сколько реально потратил. Информация о том, сколько реально потратил берется из ежедневных отчетов, которые мы ведем в внутренней базе «1С: Документооборот» (кстати с 1С: Документооборот интегрирована не только ERP, но и СППР — можно не выходя из СППР делать замеры фактически потраченного времени на задачу, эта информация будет хранится в 1С: Документооборот).
7. По вашей оценке, если необходимо добавить в конфигурацию в какой либо справочник новый реквизит и вывести его на форму сколько человеко-часов это потребует (хотя бы приблизительно общее количество времени на обсуждение, прототип, разработка, тестирование, справка, внесение в СППР и т.п.) "
Нет такой задачи «добавить справочник». Мы задачу формулируем так: «реализовать в программе такой-то сценарий работы». Обсуждаем мы именно эту задачу, делаем для нее прототипы. Для реализации согласованного, может потребоваться добавить справочник, и это займет сколько-то времени — но это будет просто время на разработку.
По оценке — Вы же сами понимаете, что нельзя дать оценку абстрактному «добавить справочник». Если добавить справочник «Номенклатура» со всем ее обвесом — несколько человеко-лет. Если справочник — ДрагоценныеМатериалы — часа четыре (с учетом заполнения его из макета).
Спасибо за интерес! Попробую ответить — зачем мне этот блог.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.
Или на v8@1c.ru?
Есть обходной путь (не очень изящный), к которому прибегают некоторые.
Заводят в ДО пользователей с именами «домен+имя пользователя» и паролем, идентичным паролю соотв. пользователя в Windows.
Делают публикацию на веб-сервере (отличную от публикации для веб-клиента, если такая есть) с выключенной опцией «Идентификация ОС».
И подключают мобильных клиентов к этой публикации.
Работаем над этим.
Вы про внешние компоненты?
Или про что-то другое?
Пока могу только сказать, что архитектурная реализация как у внешних компонент на «большой» платформе.
Скоро будет.
В планах есть.
Сроки пока озвучить к сожалению не могу.
Есть — через фоновые задания.
А чего именно вам не хватает в интерфейсе?
Понятно, что 3D-игру на мобильной платформе не написать, у нее другое предназначение.
Я до сих пор при создании мобильных приложений на 1С: Предприятии не сталкивался при создании интерфейса с непреодолимыми проблемами.
Давайте обсудим — чего, по вашему мнению, не хватает для написания конкурентоспособных приложений.
Нет, не нужно.
Если вы про сканеры ШК — да, можно будет через внешние компоненты реализовать.
А работа с FTP — с мобильных сильно востребована? Можете привести бизнес-кейс?
Спасибо!
(«ru = 'Номенклатура %1 %2 Превышен оперативный складской остаток на складе “%3 на %4 %5");
Вот смотрит переводчик на эту строку. Что может означает параметр 2? Нужно ли между параметром 1 и 2 вставлять какие-то предлоги, артикли и т.п… И вообще последовательность параметров в сообщении может зависеть от языка. То, что на русском корректно сначала назвать чего не хватает, а потом сказать где не хватает, не означает, что в другом языке это будет корректно, где-то более естественным будет определенный порядок. Значит переводчику может понадобиться параметры в сообщении перечислить в другом порядке. И ему, переводчику, будет легче оперировать осмысленными названиями.
Так же и разработчикам. Ошибку, что ты в сообщении неправильно сделал замену, и написал
%НоменклатураХарактеристика% заменить на Выборка.Склад
намного проще, чем проверить, что ты номенклатуру и склад при замене не перепутал местами.
Но это все, если мы говорим о переводе на другой язык только пользовательского интерфейса. Если же мы говорим о переводе на английский кода конфигурации, то тем боле вопрос не понятен — переводить нужно все, все имена переменных. В т.ч. переменную %НоменклатураХарактеристика%. Если будет решен вопрос, как переводить другие имена других переменных, то так же нужно будет поступать и с этими.
Разрабатывается отвественными за проекты и/или тим-лидами. Правим внутри СППР. Средство для редактирования схем действительно не самое удобно, но нам для схемы самое важное — это даже не графическое представление, а связи с объектами данных, которые мы храним в соотвествующем справочнике СППР. Можно, конечно, подумать об интеграции, скажем, BPWin и СППР, чтобы схемы править с помощью графического редактора BPWin и потом каким-то образом связывать элементы схемы со справочниками СППР, но не факт что эта связка будет хорошо работать, к тому же тогда СППР перестанет быть самодостаточным продуктом. Сейчас мы рисуем схемы в СППР, СППР же делает формальные проверки этих схем (ну, например, что связи родительской схемы и дочерней не противоречивы).
Вопрос по перенос элементов с уровня на уровень не понятен. В СППР есть средства для создания дочерних схем на основе родительских — см. контекстное меню в редактора схем в СППР.
В СППР нет веток. Информация, отраженная там соотвествует не выпущенной версии, а разрабатываемой. Справку мы пишем в СППР уже после заливки проекта в основное хранилище, поэтому по справке не опережения выпуска, а схемы актуализируем до заливки, поэтому выпущенные схемы могут опережать выпущенный функционал.
Справку пишут разработчики в СППР в рамках этапа заливки в основное хранилище, технические писатели ее проверяют в СППР (являются согласующими всех технических проектов). Заливка справки из СППР в хранилище делается централизировано в процессе сборки релиза. Документацию пишут технические писатели.
«Привычка свыше нам дана...» Только у нас наблюдения другие — с файловой базой, размещенной локально, конфигуратор при разработке работает быстрее, чем с клиент-серверной. А цифры примерно те же.
Обновления поставляются в виде одного файла. В него входит и регл. отчетность, и, например, драйверы оборудования. Раньше все поставлялось отдельно. Это единое решение для всех конфигураций нового поколения. Так проще с организационной точки зрения, а также уменьшает количество ошибок при обновлении: ну, скажем, раньше приходилось разбираться с ошибками, что комплект отчетности подключили к версии конфигурации, которая не может с ним работать. Вообще современная тенденция — программы обновляются автоматически, ничего у пользователя не спрашивая, поэтому вообще пользователю не принципиально, какими файлами это обновление приходит. Конечно, мы понимаем, для систем уровня ERP автоматическое обновление (по крайней мере пока) скорее утопия, чем реальность. Но стремиться к этому нужно.
Так же, при изменении отчетности достаточно часто меняется не только сама отчетность, но и учетные механизмы. Например, поменяли форму журнала учета счетов фактур. Но при этом ФНС поменяла не только форму, но и иструкцию по заполнению, поэтому пришлось дописывать не только «заполнялку» регл. формы, но и учетные механизмы.
Не очень понятно, о какой оценке идет речь. В СППР есть задачи, в задачах есть трудоемкость. Трудоемкость согласует рукововодитель разработки. В конце месяца делается план-фактный анализ — сколько сотрудник трудоемкости согласовал и сколько реально потратил. Информация о том, сколько реально потратил берется из ежедневных отчетов, которые мы ведем в внутренней базе «1С: Документооборот» (кстати с 1С: Документооборот интегрирована не только ERP, но и СППР — можно не выходя из СППР делать замеры фактически потраченного времени на задачу, эта информация будет хранится в 1С: Документооборот).
Нет такой задачи «добавить справочник». Мы задачу формулируем так: «реализовать в программе такой-то сценарий работы». Обсуждаем мы именно эту задачу, делаем для нее прототипы. Для реализации согласованного, может потребоваться добавить справочник, и это займет сколько-то времени — но это будет просто время на разработку.
По оценке — Вы же сами понимаете, что нельзя дать оценку абстрактному «добавить справочник». Если добавить справочник «Номенклатура» со всем ее обвесом — несколько человеко-лет. Если справочник — ДрагоценныеМатериалы — часа четыре (с учетом заполнения его из макета).
Фотосессия "1С в облаках" в поддержку продукта 1cFresh.
Почти всю свою программерскую жизнь я занимался написанием платформ для ERP — iScala, Epicor, потом Microsoft Dymanix (тут правда писал больше прикладной код). В самом начале 2000-х, мы с коллегами в шведской компании Scala придумали новый фреймворк/платформу ERP, основанную на метаданных и облегчающую жизнь прикладного разработчика. Чуть позже вышли ранние версии Microsoft Business Framework и наш собственный проект заморозили, считая, что Microsoft Business Framework решит все наши задачи. Но MBF так и "не взлетел", а время для реализации своего фреймворка мы упустили.
Когда я в очередной раз оказался на профессиональном распутье (поработав разработчиком, тим-лидом, директором R&D и т.д.), фирма 1С сделала мне очень интересное предложение — заняться продвижением их платформы. Про 1С я всегда был высокого мнения (т.к. были знакомые, писавшие платформу 1С), но, познакомившись поближе с нынешней платформой, я понял, что примерно вот это мы с коллегами и хотели написать лет 15 назад. Но в силу ряда причин (в том числе и отсутствия ряда экспертиз в прикладных областях) не смогли.
А в сравнении с конкурентами (которых я немало повидал, а часть из них даже написал) платформа 1С обладает огромным числом преимуществ; главные из них (на мой взгляд) — продуманная объектная модель (не нагромождение классов и таблиц, а реальные объекты из мира учетных систем с минимумом программного кода), продуманная система обновления, кросс-платформенность (в особенности наличие веб-клиента "бесплатно", без единой строчки доп. кода, и мобильный фреймворк). Понятно, что у каждой системы есть баги, недостатки. Но концепт, зерно, заложенное в основу платформы 1С — самое, на мой взгляд, правильное, по сравнению с другими продуктами, представленными на рынке.
"А мужики-то не знают!". Вот я и пытаюсь донести это до ИТ-сообщества. Парадокс ситуации в том, что чтобы понять всю прелесть платформы 1С — надо написать на C++/Java/Delphi парочку учетных систем с нуля. Понаступать на грабли, поизобретать велосипеды. А потом написать учетную систему на платформе 1С. И оценить трудозатраты.
А у нас многие разработчики 1С кроме 1С ничего не щупали. Отсюда их избалованность и пресыщенность. А ведь полезно иногда посмотреть, как выглядят проблемы пользователей/разработчиков конкурирующих систем.
Хабр же считаю самым лучшим на сегодня IT-ресурсом. Не без недостатков, конечно.
Уф, много написал, но, надеюсь, мысль — зачем мне нужен этот блог — донес.
:)