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

Почему люблю?
Во-первых, потому что от решения задачи сразу виден результат, его можно легко измерить. Было 40 часов, стало 4.
Во-вторых - частенько можно уберечь клиента от покупки нового сервера или апгрейда старого, к чему настойчиво склоняет сисадмин (особенно если это аутсорс, который и продаст новую железяку). Это, опять же, вполне понятный, ощутимый результат, только уже в деньгах. Узнав, что можно не отдавать несколько сотен тысяч, клиент расплывается в улыбке и облегчённо вздыхает.
В-третьих, потому что решаю задачи не так, как знакомые эксперты по производительности. Те сразу лезут в СУБД, планы запросов, неэпические аудиты производительности и прочие шибко умные штуки. Я смотрю код (даже если он типовой) и данные - решение всегда находится там.

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

Состоялась вторая встреча, на этот раз - со старым знакомым. Разбередил старые раны, блин.

Первая - он ушёл и работает на себя. Опять думаю, чё я в Бите делаю 😢.
Вторая - я давно не занимался реально полезными проектами, когда смешиваются консалтинг и автоматизация. Типа дефициты устранить, затраты сократить, людей лишних уволить, от неликвидов избавиться, системы мотивации менять. А ведь умел, блин. Но в Бит за такими проектами не ходят, даже в голову никому не придёт.

Поговорили за переходы с УПП на ЕРП. Оказывается, по этой теме жопка немного. Большие Дяди заряжают за проекты перехода по 40-50 млн. - просто потому, что рынок перегрет. И сидят куча несчастных клиентов, которые ещё не сошли с ума такие деньги отдавать.

Да блин, даже 20 млн. - это дохренища. Я-то переживаю, когда в КП пишу "до 9 млн. руб". Как бы щас ещё в демпинге не обвинил кто-нибудь.

А, ну и много говорили про разницу УПП и ЕРП, как экономить при внедрении, моделировать быстро, программировать без ТЗ, затраты клиента размазывать равномерно и т.д.

Очень, очень, очень было интересно и полезно. Жду следующих встреч.

Так, по производительности - просили написать каких-нибудь примеров. Начну с сааааааааааамого элементарного.
Но, блин, встречается у 50% клиентов из среднего бизнеса, которым кто-то запустил ЕРП и ушёл.

Симптомы: ааааааааа у нас 1С тормозит, под вечер вообще невозможно работать.
Админ честно утверждает, что сервер настроен отлично, там всё чики-чики.
Скидывает параметры сервера - ну там, 16 ядер, 128 или даже 164 Гб ОЗУ, SSD.
А пользователей в ЕРП 20-50, половина из которых делает пару документов в день - типа менеджеры, которые только заказы оформляют.

Админ молодец, только в настройки сервера 1С не посмотрел. Конечно, там у всех лицензия ПРОФ, и выбор доступных настроек весьма скуден, но количество соединений на процесс мурыжить ещё не запретили.

У клиента всегда стоит значение по дефолту - не помню, сколько там сейчас, то ли 128, то ли 256. Вот и висит один процесс-супергерой rphost, занимает 20+ Гб памяти ОЗУ и едва ворочается.

Меняешь количество соединений на процесс - например, на 8 или 16 - и о чудо!, получаем все преимущества наших 16 ядер и 164 Гб ОЗУ.

А админ хотел сервер новый купить.

Ещё по производительности, тоже достаточно распространённая проблема - поднастроенные пользователями динамические списки.

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

А бывает пользователь говорит "документ записывается 5 минут", заказ какой-нибудь. Хотя на самом деле, пользователь нажал в документе "Провести и закрыть", документ провёлся быстро, форма документа закрылась и началось тормознутое обновление списка документов - те самые 5 минут. Просто всё это время на экране продолжает торчать форма документа - пользователь и думает, что проведение медленно идёт.

В первый раз, столкнувшись с проблемой, провозился часа два - думал, дело в доработках или РЛС (ограничении прав доступа на уровне записей). Особо напрягало то, что тормозила Бухгалтерия, и это был список то ли платёжек, то ли чеков - ну вот хрена там может тормозить вообще?

Думал - наверное, список доработан, как-нибудь через задницу, и выводит что-то вроде остатка взаиморасчётов к каждой платёжке, или остаток денег на р/с. Или вообще - забубенили что-нибудь наподобие автоматической связи с банком при обновлении дин. списка, вроде автовыписки. Ну, мало ли, всякое же бывает.

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

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

Тогда я просто шваркнул типовую форму списка и создал через расширение новую. Проблема сразу ушла. Стало понятно, что дело в настройках. Вернул типовую форму, сбросил настройки списка к дефолтному состоянию, и всё заколосилось.

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

А для пользователей - магия.

Ещё про производительность. ЕРП, родимая, отражение документов в рег. учёте. За ночь отражение не успевает отрабатывать - то потухнет, то погаснет, то аварийное завершение процесса. Особенно в "тяжёлые" месяцы, типа марта, когда под отражение может попадать сразу 2 квартала.

Клиент переживает, материт ЕРП, особенно релиз 2.5 - до перехода на него "всё работало". Днём запустишь отражение - всё колом встаёт, да и закрытие надо делать. Короче, полный ахтунг.

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

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

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

В реальности, на всё решение, от анализа до результата, ушло, наверное, часа 4. Итоговое решение воспроизводится минут за 15, я даже видос снял - https://www.youtube.com/watch?v=cbwg15QMSY0

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

А проблема шибко разросшейся базы - наверное, у подавляющего большинства УППшников.

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

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

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

Дальше - фоновая свёртка. Опять же, индивидуально пишется.
Можно, например, "чистить" старые документы - фоновое задание пачками, штук по 100-1000, удаляет всё внутри старых документов, чтобы уменьшить занимаемое ими место в базе. Чистит табличные части и т.д. Движения документа при этом остаются на месте.
Другая обработка удаляет обороты по остаточным регистрам, если на сегодня нет остатков. Обычно так можно чистить регистры с заказами - если заказ полностью закрыт уже давно, приход и расход по нему никому не нужен, а место в базе занимает.
Много места занимают регистры, которыми не пользуются, но отключить их нельзя. Например, незавершенное производство в упр.учёте, если не делать расчёт себестоимости - будет пухнуть годами, а таблица остатков - она ведь лежит отдельно, и место тоже занимает, иногда очень приличное.
Ну и т.д.

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

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

Ещё про производительность - повторяющиеся кейсы с картинками, которые хотят вывести в печатные формы.
Обычно это какие-нибудь прайсы, изредка - внутренние документы предприятия, вроде сменных заданий, схем сборки заказов и т.п.

Симптомы:
1. Медленно печатается, или всегда, или на определённых (больших) документах;
2. Вообще не печатается и выдаёт какую-нибудь дичь, по-английски, от чего становится похоже на ошибку операционной системы, сервера 1С и т.п.

Когда медленно печатается, встречал две причины.

Сама распространённая - слишком большие картинки загрузили, bmp или просто огромного размера.
Лечится легко - отчётом (даже "Универсальный отчет" подойдёт) выводим картинки, отсортированные по размеру, говорим перезалить.
Ну а чтобы больше не ошибались - ставим проверку на запись картинок (присоединенные файлы), и там прям размер максимальный вбиваем (например, 1 Мб). Вроде есть возможность ограничить размер картинок типовыми методами, но они не работали (может, сейчас уже работают).
Иногда модифицируем печ. форму, чтобы не выводила большие картинки - вместо них вылезает какой-нибудь Большой Крестик.

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

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

Один раз была какая-то жуть - при печати выдавалось сообщение, ведущее в snccntx, у многих разработчиков 1С от этого названия коленки дрожать начинают - это ж "что-то на сервере". Поиск в интернете даёт немного, но всё касается сервера - перезагрузить, переустановить, почистить кеш.

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

Полечили так же, как большие картинки - из-за них, собственно, размер печатной формы и вышел за мыслимые пределы.

Опять заявку на менторство получил, на этот раз шикарную - помочь с разработкой системы мотивации, причём - снабженцев.
Я такие делал, когда на заводе работал. Вообще, очень люблю системы мотивации придумывать. Это реально продукт инженерной мысли, да если ещё с автоматизацией, да с "лидерскими" вкладками - ой, хлебом не корми, дай порисовать.

Есть ещё порох консалтерский, прям как бальзам на душу. А то всё 1С, часы, деньги, программисты.
Если захотите поменториться, я тут - https://getmentor.dev/mentor/ivan-belokamencev-2844
С Битом эта деятельность не связана, это моё личное хобби.

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

Распространённая ситуация - серийное позаказное производство. Есть перечень номенклатуры, которую регулярно берут несколько клиентов. Чётких долгосрочных контрактов нет - клиенты берут по потребности. Конечно, очень хотят получать сразу, со склада. Заранее сказать потребность не могут - это розничные сети.

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

Короче, спонтанный рваный спрос. Потребности оформляют заказами покупателей (УПП). В производство отправляют заказы на производство - то под конкретный заказ покупателя, то сборные по нескольким заказам, то "для пополнения склада".

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

Конечно, склад не затаривать, деньги не замораживать.

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

Из чего понятно - типовая конфигурация так, увы, не умеет. Ни УПП, ни ЕРП.

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

Буду через УМП (универсальный механизм планирования) делать. Выглядит на полдня, максимум - на день.

Почему доработки ЕРП дороже, чем УПП?

На случай, если вы этого не знали: да, доработки ЕРП дороже, чем УПП. Примерный коэффициент, выведенный статистически и подтверждённый другими партнёрами - 3. Доработки ЕРП, в среднем, втрое дороже, чем доработки УПП.

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

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

Вторая - архитектура в ЕРП сильно мудрёнее, чем в УПП. Тут и архитектура объектов (документы, регистры), и архитектура кода (модули, вызовы, повторное использование).

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

Четвёртая - ЕРП постоянно меняется. И в мелочах, и по-крупному. Бывает, целую функциональную область перекроят, создавая отдельные объекты (документы, например). УПП никогда так сильно не менялась. Архитектура, код, взаимосвязи, функциональность ЕРП меняются постоянно. Это приходится учитывать в доработках.

Пятая, как следствие четвёртой - из-за постоянных изменений ЕРП, в конкретный момент времени по ней нет специалистов, аналитиков или программистов. Специалистов уровня "я знаю, как тут чё, щас скажу где что доработать". Только человек разобрался в каком-то механизме до такого уровня - механизм поменялся. Человек уже не может дорабатывать не глядя - надо снова садиться и разбираться, что же там изменилось.

Это не хорошо и не плохо. Просто факт.

Вы как хотите, а у меня третья заявка на менторство
https://getmentor.dev/mentor/ivan-belokamencev-2844

Ой, нас тут уже 100 человек. Всех поздравляю 🥳

Я тут задумал рассылку по клиентам Бита сделать, предложить две штуки:
1. Анализ доработок конфигурации;
2. Оценка перехода с УПП на ЕРП.

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

Оценка перехода - относительно новое для меня развлечение, хотя занимаюсь этими оценками пару лет. Не проектами, а оценками. Проектами дольше.

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

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

Так вот, к чему я: пока там идёт согласование рассылки в Бите, может кому-то из вас такая штука нужна? Анализ конфигурации или оценка перехода. Раз мы тут все такие друзья.

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

Раз бесплатно, вроде нужен только NDA.

Если интересно - пишите в почту, она написана в информации о канале.

Есть у меня такая штука – СИФА (Статистика Использования Функционала Автоматизации). Делал когда-то на УПП, потом на ERP воспроизвёл, как расширение.

Это подсистема, которая записывает, сколько времени люди проводят в документах, справочниках, отчётах и т.д., просто пялятся или записывают в итоге, создали новый или «потрогали» старый.

Обычно используется для контроля и сравнения показателей по вводу первички, вроде заказов клиентов и поставщикам, работа бухгалтера и т.д. Применяется, обычно, когда кто-то из пользователей заявляет, что у него много работы и надо денег добавить. Сравниваешь с другими - оказывается, что просто в 2-3 раза медленнее нытик оформляет документы.

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

А ещё мы так вычисляли, каким функционалом не пользуются. Особенно эффектно получалось вываливать эти данные вкупе с суммой затрат на этот функционал – когда люди заказывали автоматизацию, потому что «иначе просто невозможно», компания тратила несколько сотен тысяч, а кроме 1-2 тестовых документов так ничего в итоге и не появилось.

Недавно ещё одно применение нашлось. Клиент готовится перейти с УПП на ЕРП, есть миллион внешних обработок и отчётов, и надо было понять, какие переносить в ЕРП. Спрашивать долго и нудно, поэтому просто включили СИФУ на несколько месяцев – она сама собрала данные, кто чем пользуется.

Картинка с примером отчёта будет следом.

Пример отчёта на основе данных СИФА

Неожиданно завершился проект перехода с УПП на ЕРП, который по экспертной технологии делали.
Подбиваю стоимость: 1600 часов. Часовую ставку клиента говорить не буду - нельзя поди. Умножьте на известную вам, получите стоимость проекта.

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

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

В экспертной технологии не принято впихивать в проект какое-либо "развитие" - нахрена оно там сдалось? Делаем только то, что нужно для перехода. Чтобы оказаться в ЕРП, имея, как минимум, те же возможности, что были в УПП. Ну и плюс доп. возможности типовой ЕРП, которых не было в УПП.

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

На ОПЭ ушло 500 часов, это за 2 месяца. Основная часть, конечно, в январе.

Я, честно, думал, что проект, как положено, продлится до апреля. Но команда и заказчик решили, что, походу, всё - переехали. Пользователи работают, все освоились, поддержка налажена, проблемы решаются. Закрытие января сделали. Остальные закрытия, в т.ч. квартала - уже в рамках сопровождения. Собственно, как и все остальные клиенты на ЕРП, которых давно сопровождаем. Сами знаете, что в ЕРП закрытие бывает каждый раз, как в первый раз.

Ну разве не прелесть?

Опять согрешил - забрал у программиста задачу из разряда моих любимых. После отключения электричества стала жутко тормозить УТ 11. Перемещение проводилось 30-50 минут. С клиентом ранее не работал - смежники подкинули, сами не справились.

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

Ну, думаю, итоги сломались. Ручками удаляю, пересчитываю - не помогает.

Иду смотреть сервер 1С - настройки дефолтные. Распараллеливаю - так, на всякий случай.

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

Проверяю таблицы по отдельности. Запрос к регистру сведений - норм, 1.6 млн. записей. Запрос к таблице видов запасов - норм, 2 млн. записей. Соединяем - виснет на полчаса.

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

Проверяем с админом, где будет лагать на больших запросах. Ясно где - в СУБД (постгрес). Админ божится, что все регламенты обслуживания выполняются, в т.ч. выполнялись после сбоя.

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

Вечером останавливает сервер 1С, делает дамп базы, заводит сервер 1С, регистрирует базу заново, разворачивает из дампа, и... Вуаля! Работает, как до сбоя.

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

Решил нумеровать анализы конфигураций и/или баз, которые делаю. Лаборатория у меня будет 🤦‍♂️

За февраль была одна УПП и две УНФ. Две - по запросу из этого канала.
УПП анализировал, чтобы стоимость перехода на ЕРП посчитать, ну и доработки поглядеть и что-то про них написать.
Одну УНФ - из канала прислали, по акции (бесплатный анализ).
Ну и по одной УНФ был обычный платный анализ.

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

Важно, что это анализ № 33!

Как вам такое творчество? Года два назад писал, так никому и не отправил вроде.
Расчёт обеспеченности материалами

Проблема
Вам для производства нужны материалы и покупные полуфабрикаты. Возможно, и для перепродажи.

У вас в 1С, казалось бы, есть вся информация о потребности в материалах, товарах, полуфабрикатах – планы продаж и производства, заказы покупателей, спецификации с нормами потребления, внутренние заказы, неснижаемые и страховые уровни запасов.

Но если вы захотите собрать всю потребность воедино, придётся повозиться. В одном отчёте взять заказы клиентов, в другом – потребности заказов на производство, в третьем – материалы для планов на следующие три месяца, в четвёртом… Ну да, а что такого? Собрали из нескольких отчётов, вставили в эксель.

Допустим, потребность собрали. Теперь же надо понять, а что из этого огромного перечня у нас уже есть. На складах, в производстве, заказано у поставщиков или переработчиков. Что ж, путь известен – открываем 3-4 отчёта, в каждом – данные по одному разделу. Не забываем поставить отборы – не со всех складов можно брать, где-то резерв надо учесть, заказы поставщикам не очень-то актуальны. С горем пополам, собираем во вторую эксельку наши возможности, или ресурсы, или остатки – как вам удобнее. То, что у нас уже есть или через известное время появится.

Ну и всё, сводим вместе две эксельки, вычитаем одно из другого. Получаем, наконец, дефицитную ведомость («дефицитку»). Очень здорово, если не используем аналоги и замены материалов – делать это вручную при расчёте дефицитов почти нереально. Зачем только мучились, вбивали эти аналоги в 1С.

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

Полученная картина обеспеченности, конечно, определённой ценностью обладает – хоть что-то теперь известно, и на душе становится немного спокойнее. А что случилось с реальной обеспеченностью, пока все собирали дефицитку? Мягко говоря, она немного изменилась. Появились новые заказы от клиентов, часть планов производства была выполнена или отменена, поставщики сдвинули сроки или слились, груз завис на таможне и не приедет вовремя и т.д. Это жизнь.

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

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

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

Решение
Мы успешно решаем задачу расчёта обеспеченности с помощью инструмента собственной разработки. В любой конфигурации – УПП, ERP, КА, УНФ – не важно. Мы встраиваем инструмент в вашу программу, настраиваем чётко под вас – где какие потребности взять, чем они обеспечиваются, как отслеживать изменения – и создаём необходимые отчёты и контрольные точки.

Данные актуализируются в автоматическом режиме. Люди работают, как работали, от них ничего особенного не требуется. Система сама всё соберёт, посчитает, учтёт, и выведет в отчёт. Дефицитка и картина обеспеченности будет отставать от жизни минут на 15.

Изменил адрес электронной почты, по которому мне нужно писать.
Был корпоративный битовский, теперь личный.
Так удобнее, наверное.
Кто уже писал на корпоративную - можем там же и продолжать.

На анализ номер 34 попала база ЕРП с целым букетом проблем.

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

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

Из анализа доработок примерно понятно, почему возникли проблемы с закрытием - такого смелого вмешательства в ЕРП я ещё не встречал.

Сейчас середина процесса, что будет дальше - расскажу, когда сам узнаю.