1С *

Собрали новую подборку заказов с Биржи Инфостарта. В этот раз в списке — задачи, которые появились с 4 по 9 июня: отчеты, обновления, интеграции, синхронизация, аналитика и проектная работа по 1С.

Есть как небольшие разовые задачи, так и заказы, где нужно глубже погрузиться в проект. На этой неделе заказчики ищут аналитиков, разработчиков и консультантов 1С. Встречаются задачи по ERP, БП, УНФ, УТ, «Управлению холдингом», MDM/Data Quality, обменам и внешним интеграциям.

Среди новых заказов:

• Нужен аналитик 1С (MDM/Data Quality), проект в энергетике

• Рекомендации клиентов для B2B IT-сервисов

• Окно авторизации с подключением хранилища (БД)

• Обновить ERP до актуальных релизов

• 1С БП: разработать отчет «Маржинальность продаж»

• Доработать «Управление торговлей» 10.3: подключение к «Честному знаку»

• Исправить ошибку синхронизации 1С:УНФ (УПО) и БП через универсальный формат

• Аналитик 1С:Управление холдингом для проекта автоматизации бухучета и блока расходов

• Интеграция с fedresurs: доработка под физических лиц

• Доработка «Интеграция с fedresurs»

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

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

Для работы через Биржу доступны:

• 0% комиссии площадки;

• прямой обмен контактами;

• исполнители разного масштаба — от частных специалистов до ИТ-команд;

• безопасная сделка по желанию;

• рейтинги, кейсы и история откликов.

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

Написали мы с ИИ расчёт себестоимости, который 1С не снился.На реальных данных клиента считает месяц за...Готовы?Точно готовы?

За 2.5 секунды 😱🥳🔥😏🎊

Считает и прямые, и косвенные.
2-3 тысячи номенклатур в выпуске, среднее количество переделов - 6.3, максимум - 10.

Мало того, ещё и структуру затрат сразу собирает.
Т.е. на выходе мы имеем не только с/с выпуска, но видим:
1. Отдельно - "материальную" себестоимость;
2. Из каких материалов она сложилась - материалы собраны по всем переделам и положены в готовую продукцию;
3. Отдельно - видимо "косвенную" себестоимость;
4. И косвенная тоже разузлована:
- отдельно, по статьям - что упало прямо на готовую;
- отдельно, по статьям же - что пришло со всех полуфабрикатов.

Короче, структура затрат - мечта. Собрано всё со всех переделов и положено на готовую продукцию.

Отдельный бонус - структура затрат не по выпуску, а по реализации.
Показывает с/с реализации, разложенную по структуре затрат.

И всё это - за 2.5 секунды.

Я сильно захотел уронить этот расчёт, и дал ему данные не месяц, а за год.
Считает помесячно, передавая между месяцами остатки. Короче, всё как надо.
Год считается за 35 секунд.

Все расчёты выполнял на реальных данных.
В 1С у клиента расчёт одного месяца идёт 15-40 минут.

https://t.me/another1C

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

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

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

• Добавить в готовую форму допсоглашения все виды и значения надбавок сотрудника.

• Настроить софтфон и Рарус Альфа-Авто 6.1.

• Помочь настроить кластер PostgreSQL и 1С:Фреш.

• Настроить доступ к справочнику на уровне групп.

• Выполнить перенос данных из 1С:Розницы базовой 2.3 в 1С:Розницу базовую 3.0.

• Оптимизировать обмен между базами «Торговое Предприятие 7».

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

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

На Бирже доступны:

• работа без комиссии площадки;

• прямой обмен контактами между заказчиком и исполнителем;

• исполнители разного масштаба — от частных специалистов до ИТ-команд;

• безопасная сделка по желанию сторон;

• рейтинги, кейсы и история откликов, которые помогают выбрать подрядчика.

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

На Бирже заказов появились новые задачи для разработчиков и консультантов 1С. В подборке — заказы, размещенные с 20 по 27 мая: доработки обработок, настройка обменов, интеграция с «Честным Знаком», задачи по маркировке, ЗУП, УТ, ERP, КА и даже 1С 7.7.

Заказы недели:

• Доработка «Печать договора поставки из справочника Договоры с контрагентами (ERP 2, КА 2, УТ 11)».

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

• Доработка «Загрузка из Гранд-Смета».

• Интеграция УТ 11.3.218 к Честному Знаку.

• 1с розница 2.3. Продажа остатков новый рмк. Ошибка «Штрихкод не соответствует товару».

• Свернуть или перенести остатки и документы на указанную дату.

• Настройка и доработка синхронизации УТ 11.4 и БП 3.0 с нуля через EnterpriseData (сворачивание номенклатуры, фильтры)

• Консультации по 1с ут 11.5.22.134.

• Доработка «Расчет накопленных дней отпуска за работу с ядохимикатами за фактически оплаченные/отработанные часы во вредных условиях труда».

• Доработка «Реестр документов для 1С:ERP 2, КА 2, УТ 11».

Биржа заказов Инфостарта помогает быстро найти исполнителя под задачи по 1С: от разовой консультации до доработки конфигурации, настройки обмена, интеграции с внешними сервисами или сопровождения проекта.

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

Вебинар уже завтра: как 1С-специалисту получать больше заказов через Инфостарт

Завтра, 28 мая в 11:00 мск, проведем вебинар для 1С-специалистов, которые хотят получать больше заказов через Биржу заказов Инфостарт и выстроить стабильный поток клиентов.

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

Поговорим о том:

— как искать перспективные заказы;
— как оформлять профиль и повышать конверсию откликов;
— как оценивать стоимость работ;
— как получать обращения напрямую через профиль;
— как использовать публикации и форум для привлечения клиентов.

Также обсудим безопасную сделку, бесплатные отклики, стартмани, подписку PRO и экономику работы на площадке.

Спикеры:

Алена Солохина — руководитель отдела маркетинга Инфостарт,
Антон Репин — руководитель группы аналитиков 1С Инфостарт.

В конце — Q&A-сессия с ответами на вопросы участников. Вопросы можно оставить заранее при регистрации.

📅 28 мая, 11:00 мск
⏱ Длительность: 1 час

1С как центр бизнес-экосистемы: зачем разработчику разбираться в обмене данными

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

На курсе «Обмен данными в системе 1С:Предприятие» мы разбираем, как проектировать и реализовывать такие интеграции на практике: от обменов между конфигурациями до API, JSON, XML, HTTP- и WEB-сервисов.

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

Обмен данными — не просто техническая настройка. Это способ связать отдельные участки бизнеса в единый процесс.

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

После этого обмен перестает быть простой синхронизацией. Разработчику нужно понимать, какие данные передавать, какая база является источником истины, как сопоставлять объекты и что делать, если данные не совпали. Если в одной базе номенклатура ведется по артикулу, а в другой — по внутреннему коду, без правил сопоставления быстро появятся дубли.

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

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

Для обменов в 1С используются файлы, XML, JSON, XDTO, HTTP- и WEB-сервисы, внешние источники данных, COM- и OLE-технологии, планы обмена. Но выбор технологии — только часть задачи. Гораздо важнее понять логику процесса: откуда берутся данные, куда они должны попасть, кто отвечает за их актуальность и как система ведет себя при сбое.

Иногда достаточно файлового обмена. Иногда нужен HTTP-сервис. Иногда проще использовать готовую интеграцию, а иногда без собственной разработки не обойтись. Решение зависит от процесса, надежности и объема данных.

Хороший обмен понятен в сопровождении. По нему можно увидеть, когда прошла последняя загрузка, сколько объектов обработано, какие ошибки возникли и что нужно исправить. Его можно безопасно повторить. Он не создает дубли и не прячет проблемы в техническом логе.

Для пользователя важен не сам факт передачи JSON или XML, а результат: заказ попал в учет, остатки обновились, документы сформировались, отчетность не разъехалась. Поэтому разработчик 1С все чаще работает не только внутри конфигурации. Он связывает 1С с внешними сервисами, настраивает двусторонний обмен, проектирует API и помогает бизнесу избавиться от ручных операций.

Старт курса «Обмен данными в системе 1С:Предприятие» — 5 июня 2026 года.

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

Собрали часть актуальных заказов, которые можно взять в работу.

Новые задачи недели

• Шаблоны претензий и писем-уведомлений в 1С Бухгалтерия предприятия КОРП, редакция 3.0 (3.0.195.40);

• Доработка «Счет на оплату покупателю с QR кодом для Управление торговлей, редакция 11 (11.5.17.201);

• Доработка «Стоимость материалов и работ по ресурсной спецификации»;

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

Заказы, которые еще доступны

• Заказ по статье «Векторный поиск в 1С без облаков: локальный AI-сервис для прайсов поставщиков»;

• Апгрейд 1С УТ 11.5 до 1С: Управление торговлей и взаимоотношениями с клиентами (блок CRM)»;

• Обработка 1С УНФ – зачет авансов;

• УНФ 3.0 создать внешнюю печатную форму спецификации.

Инфостарт Биржа заказов — площадка для поиска исполнителей под задачи по 1С: от небольших доработок до проектной разработки и внедрений.

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

Если начальство пристаёт и требует BI-систему, а в наличии только 1С и нет бюджета - можно взять бесплатное расширение "Рабочий стол" и нарисовать диаграммы в нём.

Видео - https://vkvideo.ru/video-208482299_456239497?list=ln-BKsiW5Xfu9tyPmSipy

Расширение здесь - https://t.me/another1C/48

Демонстрация low-code коннектора к «1С:Шине» от «Денвик»

На связи Сергей Скирдин, технический директор ИТ-интегратора «Белый код». Пока «Фирма 1С» не выпустила поддержку «1С:Шины» в БСП, мы тестируем партнерские решения. Недавно в статье на Хабре я пригласил к сотрудничеству компании, у которых уже есть готовый коннектор, и первым откликнулся «Денвик».

«Денвик» — российский продукт для автоматизированной выгрузки данных из 1С во внешние аналитические базы и BI-системы. Кроме экстрактора есть инжектор — инструмент обратной загрузки данных в 1С. Оба инструмента имеют low-code интерфейсы. За счет этого типовые сценарии выгрузки из 1С и загрузки в 1С можно настраивать через интерфейс, без привлечения разработчика.

Можно ли экстрактор и инжектор использовать в качестве коннектора к «1С:Шине»? Да, можно. На вебинаре в этот четверг вместе с product owner «Денвик» Степаном Пыстиным покажем, какие задачи решаются с помощью инструментов «Денвика».

Спикеры:
— Сергей Скирдин, технический директор «Белого кода»
— Степан Пыстин, product owner «Денвик»

📅 Дата: 14 мая
🕛 Время: 12:00 МСК
📍 Формат: онлайн

➕ Для участников вебинара команда «Денвика» предоставит бесплатный тестовый доступ.

Регистрируйтесь на вебинар и приходите!

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

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

Один из таких инструментов - Инфостарт-бонусы при покупке решений 1С.

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

• обучение сотрудников;

• участие в профильных конференциях;

• доступ к базе знаний;

• покупку готовых инструментов и расширений;

• ускорение внутренних задач автоматизации.

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

До 31 мая на Инфостарте действует повышенный процент — до 20% при покупке конфигураций и лицензий 1С.

Если закупки уже запланированы, их можно провести сейчас и вернуть больше средств в развитие команды. Разница между стандартными 15% и повышенными 20% особенно заметна при крупных закупках.

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

Потихоньку расскажу, как сильно ускорять тяжёлые обновления 1С. Сегодня - про ускорение отложенных обработчиков.

Чтобы понять, какие обработчики долго выполняются, достаточно обновить копию и посмотреть. В форме выполнения обработчиков прям время будет написано, в днях/часах, сколько выполнялся обработчик. А сколько ему надо было объектов промурыжить - видно в отчёте “Прогресс отложенного обновления”.

Например, у нас сильно тормозил обработчик регистра сведений “РеестрДокументов” - выполнялся больше суток. Ему надо было перезаписать 9 млн. записей (столько в базе было документов).

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

Дальше идём в три процедуры модуля менеджера обновляемого объекта:

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

2. Процедура регистрации (обычно ЗарегистрироватьДанныеКОбработке). В ней надо забрать запрос, который формирует данные к обработке. Обычно там всё несложно - запрос, выборка результата и его складывание в план обмена (ОбновлениеИнформационнойБазы.ОтметитьКОбработке). Нам нужен только запрос и выборка данных, в план обмена ничего писать не нужно.

3. Процедура выполнения обработчика (обычно ОбработатьДанныеДляПереходаНаНовуюВерсию). Там лежит код обработки. В нём много лишнего (обвес для типовых процедур обновления), но суть обычно понять несложно - читаются данные, сформированные п.2, и что-то с ними делается. Бывает, ещё один-два запроса делаются. Берём вот эту содержательную часть и забираем себе. Не забываем заменить ОбновлениеИнформационнойБазы.ОтметитьВыполнениеОбработки на обычную запись - нам не надо регистрировать обработку в плане обмена.

Дальше нужно написать обработку, которая запустит энное количество ФЗ, каждому скормит массив данных к обработке (из п.2), и ФЗ выполнит адаптированный код из п.3. Мы делали расширение, в него складывали процедуру ФЗ, на входе - массив (обычно это массив ссылок). В процедуре - код из п.3. И обработку внешнюю, в которой мы указываем количество потоков, она выполняет большой запрос из п.2, делит результат на потоки, и запускает кучу ФЗ. И всё.

Контролировать прогресс выполнения можно разными способами. Первый, который я использовал - просто выполнял запрос из п.2. Подавляющее большинство запросов в обработчиках обновления написано так, что возвращают только необработанные данные. Соответственно, их в процессе выполнения становится всё меньше. Но этот запрос может выполняться сильно долго. Потом я сделал несложный регистр сведений, и в каждое ФЗ положил пару строк записи в этот РС - после обработки каждого объекта ФЗ “отчитывалось”, и в регистре было видно общий прогресс.

При наличии нормального объёма ОЗУ запускать такие обработчики можно и в 16, и в 32, и в 48, и даже в 100 потоков (проверено). Это количество ФЗ на один обработчик. А вообще мы в это распараллеливание вывели 22 обработчика из 4 редакций.

Ускорение получается очень существенное - тот, который выполнялся сутки, стал выполняться за 4 часа.

https://t.me/ywhite

Про типичный паттерн, который помогает решать задачи по производительности в 1С.

Оптимизировали как-то мы обмен (как начало сказки звучит 😁). Вообще, началось не с обмена, а с “иногда 1С внезапно начинает тормозить”. Посмотрели журнал регистрации, выполнение регламентных и фоновых - увидели, что обмен идёт.

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

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

Второй подозреваемый - количество выгружаемых данных. Здесь важно понимать паттерн - он часто помогает при оптимизации даже типовых 1Сных решений. Паттерн такой: разработчик почти всегда тестирует на ограниченных данных и в идеальной среде (если не было задачи именно оптимизированный алгоритм написать). Если он пишет обмен, то проверяет на 1-2-10 объектах. И на идеальной среде - в которой нет никого, кроме него. Если разрабатывает планирование, то для 2-3 заказов. И там, где он один. И т.д.

Вообще, это всё ежу понятно. Но когда дело доходит до проблем с производительностью, то почему-то паттерн этот часто забывается. Забывание выражается в том, что все исходят из предпосылки “там всё правильно сделано”. А это не всегда так. Оно сделано правильно, но для небольшого объёма данных и для среды, где нет пользователей и другой нагрузки.

Вот и в нашем случае, первые мысли были - переписать весь обмен. Вообще уйти от XML и правил, написать сервис. Потом немного одумались, вспомнили паттерн, и пошли проверять файл с сообщением обмена.

Ну и да, он оказался несколько великоватым. Потом что по умолчанию, вместе с установкой цен, тащил за собой все реквизиты всех номенклатур, упомянутых в документе. А номенклатур там много. И ещё запросом добавлялись штрихкоды.

Дальше понятно. Просто убрали лишние данные из выгрузки (они и правда были лишними, ненужными - номенклатура обменивалась в другом контуре). Файл обмена уменьшился более чем вдвое, в правилах стало меньше запросов, и всё заколосилось.

https://t.me/another1C

Кто съедает ресурсы сервера 1С? Находим за несколько минут с помощью «Монитора»

Покажем, как за 5–10 минут найти процессы, которые тормозят систему.

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

2 апреля в 12:00 Андрей Бурмистров, эксперт в сфере оптимизации производительности 1С, покажет, как находить такие проблемы за несколько минут с помощью «Монитора».

Что будет на вебинаре:

• как увидеть, какие процессы нагружают CPU и память в 1С;

• как находить долгие запросы, блокировки и взаимоблокировки без «танцев с логами»;

• как отследить проблему до того, как пользователи начнут писать в чат «у нас всё зависло».

Спикер вебинара — Андрей Бурмистров

Эксперт в сфере оптимизации производительности 1С, более 10 лет в сфере разработки на платформе «1С:Предприятие 8», автор курса «Ускорение и оптимизация систем на 1С:Предприятие 8.3. Подготовка на 1С:Эксперт по технологическим вопросам». 

Кому будет полезно:

— ИТ-директорам и руководителям ИТ;

— администраторам 1С;

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

Бонус для участников:

дадим доступ к триал-версии «Монитора» на 30 дней + поможем с установкой.

👉 Регистрируйтесь на вебинар

Правило "Как для себя".

Приветствую!

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

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

Но почему же тогда встречались "затычки", которые ни со стороны регламентов проектов, ни со стороны даже разума недопустимы?

Покажется неожиданным, но авторы "затычек" не нарушают этого правила! Они и для себя делают так же.Что за этим стоит? Нежелание? Неумение? Бывает и так. Но чаще причина иная.

У каждого свой уровень потребностей, вот в чём дело.

Лет 30 назад я для себя всё делал по минимуму. Красота? Роскошь, слова такого не знаю. Удобство? Забудем! Функциональность? Самая необходимая. Цена? Главный критерий.

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

Так как же делать правильно?

Истина обычно где-то посередине. Но бывают и необходимые отклонения от этой середины. Во времена Отечественной войны вместо разбитых рельс, бывало, клали брёвна или даже дрова - чтобы один раз, и медленно - но проехать! А без высоких планок и требований мы не знали бы Эрмитажа.

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

ВАЖНО: часто ругаются, что заказчик сам не знает, чего хочет. И я тоже далеко не всегда знаю, чего хочу. В силу квалификации, например. Я не строитель - и я не знаю, какие бывают разновидности фундаментов, в лучшем случае 2-3 варианта в общих чертах. Я не смогу спорить со строителем, выложившим десятки фундаментов. Я не смогу сказать, какой именно мне нужен, не потратив массу времени на самообучение. Но я могу сказать, например, хочу фундамент на сваях, поскольку прочитал где-то, что это лучшее в моём случае.

Так вот, хороший подрядчик должен в случае моей ошибки/незнания:

• Объяснить, что я неправ, и почему.

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

• Предоставить всю необходимую информацию для выбора варианта.

То есть мой выбор должен быть осознанным, я - информирован, всё понял и сделаю взвешенный выбор (или доверю его подрядчику).

Надо ли объяснять, сколько подрядчиков такие объяснения делают? А из оставшихся есть те, кто подсунут либо самый дорогой вариант, либо тот "тяп-ляп", который сделают без затрат. Но мне приходилось встречаться с подрядчиками, которые всё объясняли, и я их очень ценил.

Мой вывод: как для себя - это по осознанным и взвешенным требованиям Заказчика. Ни в коем случае не хуже. Как это достигается - тема отдельного поста.

Пишите в комментариях свои мнения, тут есть о чём поговорить.

Съездил на прошлой неделе на конференцию Инфостарта, доклад читать.
Каждый раз, возвращаясь оттуда, думаю — больше не поеду. А через год забываю, почему так решил. Попробую тут записать, может тогда не забуду 😁 Или Инфостарт включит меня в чёрный список.

Всё, что пишу — рациональный взгляд со стороны старого докладчика. Я ездил на конференции Инфостарта с 2015 года.

Первое — я долго ездил туда по инерции, руководствуясь старыми причинами, которые не актуальны уже лет 10. Раньше Инфостарт (и сайт, и конференция) был главным местом тусовки 1Сников. Не единственным, но главным. Не было кучи блогеров, альтернативных каналов и ресурсов, где 1Сники тусуются, онлайн и вживую.

Соответственно, у выступлений на конференциях Инфостарта была высокая конверсия.
Выступить тогда на Инфостарте — всё равно, что попасть на Первый канал в 90-е. Тебя увидят и услышат все. И на выступлении всё не закончится — оно продолжится на сайте Инфостарта, так как сообщество и конференции синергично связаны.

Сейчас Инфостарт перестал быть главной тусовкой, а стал одной из. Возможно, на данный момент — самой крупной. Но точно не единственной. Дальше — простая неумолимая математика. Твой доклад увидит столько же людей, что и 10 лет назад — столько, сколько придёт в зал. Даже при битком набитом зале будет несколько сотен человек.
Если выложить своё выступление в блог или видеоканал — получишь больше просмотров, при несопоставимо более низких затратах.

Инфостарт тоже выкладывает видео выступлений, и раньше это было существенным преимуществом — во времена, когда у 1Сников не было блогов. Но сейчас это преимущество растаяло.

Ну и третья часть конверсии — в узнаваемость в сообществе, то есть на сайте Инфостарта.
Она нивелировалась вслед за развитием других тусовок 1Сников — блогов, сообществ, конференций.

Вот такая математика. Из‑за неё каждый раз и собираюсь больше не ехать.

Но всё равно еду :)

Если смотреть с точки зрения участника, а не докладчика — конференции Инфостарта действительно с каждым годом становятся лучше, удобнее, организованнее, интереснее.
Команда Инфостарта растёт в профессиональном плане, это очевидно. С учётом их опыта, частоты и количества проведённых конференций — они точно лучшие по части их организации (в среде 1С).

Для тех, кто не выступает — конференции Инфостарта очень хороши. Это действительно так.

Для начинающих же докладчиков конференции Инфостарта — по‑прежнему лучшая точка старта, на мой взгляд.

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

А у Инфостарта продуктовая линейка докладчиков сейчас хорошо разделена. Есть хэдлайнеры и конкурсный отбор, через который прогоняют и новичков, и докладчиков с опытом (это некое «среднее звено»). Через конкурсный отбор точно можно пройти. И точно можно не пройти, даже будучи докладчиком с опытом (я однажды не прошёл 😂).

Короче, кто хочет попробовать себя в роли докладчика — вам точно на Инфостарт.
Кто хочет посмотреть/послушать/поучаствовать — вам точно на Инфостарт.
Кто старый прагматик, как я — тому дома на диване сидеть 😊.

Телеграм

Один хороший человек, зовут Руслан, в своём тг‑канале написал небольшой текст про мой «Универсальный механизм планирования» (УМП). Руслану можно верить — он несколько раз внедрял УМП. На практике знает, насколько сложно решать реальные задачи планирования в 1С.

Думаю, опубликовать его текст будет уместным. Тем более, что УМП я распространяю бесплатно (прям здесь). Кстати, Руслан когда‑то тоже скачал УМП бесплатно, внедрил, и только через несколько лет я об этом узнал:)

Итак, текст Руслана.

«Как же долго я тебя искал…»

Знакомьтесь — УМП, универсальный механизм планирования. Когда я впервые про него узнал, радости было ещё больше, чем от автозадач.

Почему? Потому что он умеет делать главное, что должно уметь любое планирование — распределять ограниченные ресурсы (деньги, товары, время работы оборудования и так далее) на потребности (планы оплат, заказы клиентов, планы производства…). И, что важнее всего, делать это гибко, по любым условиям.

Разработал, кстати, всё тот же Иван Белокаменцев (подписывайтесь, если еще не). Не буду подробно рассказывать про техническую часть, это все можно прочитать в описании. Расскажу про свой опыт.

Пример из практики
Производственное предприятие, которое работает в основном под заказ. Главный вопрос от менеджеров:

«Сможем ли сделать и отгрузить к нужной дате?»

В 90% случаев ответ упирается в одно — наличие сырья. А тут всё сложно:

• ассортимент продукции большой

• сырьё может лежать на складе

• а может быть «в пути» от поставщика

Посчитать это в типовой ERP — задачка не из простых. И тут на сцену выходит УМП.

Что мы сделали

1. Разузловали спецификации готовой продукции до конечных материалов и храним их в специальном регистре — это ускоряет расчёт.

2. В УМП распределили материалы на складе и «материалы в пути» (с учётом даты поступления и времени, необходимом на изготовление продукции) на заказы покупателей.

3. Каждый заказ получил статус:

• обеспечен

• обеспечен частично

• не обеспечен

4. В отчёте видно какого именно сырья не хватает и под какие изделия.

5. В журнале заказов добавили светофор, чтобы статус был виден сразу.

6. В АРМ «Формирование заказов по потребностям» диспетчер видит этот же статус и понимает — включать заказ в производство или нет.

В итоге

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

В следующей части расскажу про автоматизацию планирования в производстве.

На одном из проектов перехода с УПП на ЕРП возник неожиданный субподрядчик, который добавил приключений и нам, и заказчику.

Заказчик работает с сетями, а где сети — там какой‑нибудь хитровыдуманный электронный документооборот.

В основе — просто модуль/обработка, написанная какой‑нибудь известной компанией, но обязательно — доработанная на месте под требования сети.

И вроде бы — что может случиться, если мы переходим с УПП на ЕРП, и для обеих конфигураций есть версия модуля ЭДО?
Код модуля — открыт, доработки под сеть — известны. Что может пойти не так?

Первое, что пошло не так — разработчики модуля сказали, что ни нам, ни заказчику нельзя его дорабатывать. А кто там его доработал несколько лет назад для УПП — уже никто и не помнит. Ну, ладно, хозяин‑барин — нельзя так нельзя. Спрашиваем — так, а можете нашему заказчику‑то доработать? Хотя, чего нашему — он и ваш заказчик.

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

В декабре ребята честно что‑то дорабатывали, под конец года отдали результат, и все торжественно ушли Новый Год встречать. В январе, на каникулах, мы запускаем ЕРП, ну и... Доработанные ребятами модули, конечно, не работают. Ну ладно, думаем, ничего страшного = серьёзные штуки никогда с первого раза не работают. Сейчас напишем ребятам, они помогут.

Пишем ребятам, и оказывается... Тех.поддержка не работает (в первые дни каникул).
А заказчику уже отгружать надо — сети, они такие. Там нельзя не отгрузить.
Что делать? Или самим‑таки доработать (но разработчики ЭДО грозили штрафами), или из УПП отгрузки делать. Выбрали второе — сели несчастные люди и вбили реализации в УПП, просто чтобы выгрузить в ЭДО.

Через пару дней начала работать тех.поддержка, но вот незадача... Они ничем не могли помочь с нашим доработанным модулем. Потому что помочь может только разработчик, который с их стороны модули допиливал. А он — на законных каникулах до 12 января. И связаться с ним нельзя никак и ни за какие деньги. А документации он никакой не передал, тех.поддержке ничего не объяснил, поэтому помочь они ничем не могут.

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

По окончании каникул подрядчик, конечно, всё быстренько починил.
Претензий нет, если что. Просто не знал, что так бывает :)
Теперь знаю. Придётся учитывать этот риск в следующих проектах.

Телеграм

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

Проблема была такая. Есть КА1, в ней — дофигищща чеков. В чеке есть цена продажи, но нет себестоимости. Можно получать какую‑то себестоимость, если включить оценку стоимости списания при проведении документа (фифо, средняя), но это замедлит проведение документов (а их очень много).

К тому же, себестоимость не будет актуальной — документы поступления, как положено, вводятся с опозданием. Соответственно, чтобы актуализировать с/с по чекам, надо или документы перепроводить (а их, напомню, слишком много), или расчёт себестоимости ежедневно или ежечасно делать (не вариант).

У клиента уже было своё технико‑методическое решение — считать себестоимостью цену последнего закупа номенклатуры.

Но тут две проблемы. Если определять цену при проведении чека, то получаем обозначенную выше проблему — поступления вводят с опозданием, поэтому с/с при проведении чека не будет актуальной. Если же брать с/с не при проведении чека, а на лету, отчётом, то тормозит и запрос неприятный получается — кто писал запросы получения среза последних на дату документа, знает, о чём речь.

Ну я и сделал интервальный регистр сведений с ценами. Измерения — номенклатура, дата начала, дата окончания, ресурс — цена. Обращаться запросом к такому регистру — одно удовольствие. И работает сильно быстрее, чем срез последних.

Обновление интервального регистра делается рег.заданием — это быстро, где‑то одна минута на всю номенклатуру. Но всю номенклатуру обновлять надо редко. Я сделал регистр с очередью обновления, туда попадают номенклатуры из поступлений, которые записываются. Провели поступление с сотней номенклатур — сотня записей в очереди появилась. Рег.задание зашло и актуализировано интервальный регистр с ценами по сотне позиций.

Хорошая штука эти интервальные регистры. Рекомендую.

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

В основном такие переходы - вынужденные, вроде отказа от УПП.
Заказчику всё нравится в его УПП, но так уж вышло, что её больше не поддерживают, и придётся переходить.
Поэтому хочется всё сделать с минимальными затратами. Это один из ключевых критериев.

Понятно, что недорогие переходы - не единственный формат проекта, и не всегда лучший.
Но спрос на него есть, вот мы его и придумали.

На данный момент мы сделали 6 таких проектов:

1. Два перехода УПП - ЕРП;

2. Два перехода УПП - КА2;

3. Один переход УНФ - КА2;

4. Один переход УПП - Аренда (там БП внутри).

Ещё два проекта в процессе, их рано включать в статистику.

Средний чек проекта - 1274 часа.

https://t.me/another1C

P.S. Думаю, надо статью написать, предметную - как такие проекты делать, чтобы экономить на переходе.

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

Перевёл потому, что один потенциальный клиент попросил - хотел посмотреть, что за штука это управление задачами Flowcon.

На момент публикации оно там сыровато всё, конечно, но пользоваться уже можно. Постепенно стабилизирую релиз.

Детальное описание всего Flowcon - https://infostart.ru/marketplace/976048/
В данном расширении - часть "Управление задачами". Ещё включил "Управление компетенциями", но пока не тестировал - сделаю это позже.

А вот на что точно стоит обратить внимание - на часть про регулярный менеджмент. Это штука, которой я сам пользуюсь каждый день. Что это, зачем, и как - описано в отдельной статье - https://infostart.ru/pm/998824/

Расширение можно скачать в тг-канале: t.me/another1C