Автоматизация производства при помощи универсальных учетных систем : КИС Lack & УС Land

Очередная ооочень срочная задача. Возможно вы слышали, что сейчас непрерывно растут цены, а «первичные» поставщики и производители сырья для бизнеса вообще «берега попутали»… за последний месяц дружно подняли цены сырья от 40% до 120%, пруфы от реального клиента имеются.

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

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

Внесено изменение в основной точный анализатор влияния цены сырья и сырьевого наполнения изделия – «Производство/Влияние цены сырья на цену изделия»





Задача изначально была – пачкой пропорционально поменять веса сырья с целью понимания изменения дохода и наценки, но при уяснении задачи понял, что «вес это не обязательно количество единиц», например единица—кв.метр… Хотя при попытке «глубокого» выяснения по ключевым изделиям, правда после отработки пакетной правки веса и/или количества, выяснилось, что это несущественно. Далее как обычно: вызываем новый режим и получаем требуемый результат (оценки).

Как понимаю - в среде профессиональных разработчиков принято: новая задача => новый режим или отчет => новое финансирование? К сожалению в "УС Land" не так == стараюсь подцепить новую задачу к уже существующему режиму, как геморно это ни было, но зато пользователи не уходят от привычных технологий... В среду "сорвались":

1. Для этикеток на изделия состав должен располагаться по мере убывания веса сырья в изделии;
2. Как изменяется доля сырья в себестоимости при резком изменении цен только на несколько видов сырья;
3. XLS вариант отчета по прогнозированию цен нельзя использовать для глубокого анализа... и так далее...

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





... и за что тут доплачивать - любой школьник за пару минут сделает? Однако все всплывшие задачи были решены. Форма отчета в сортировке по доле сырья в изделии по критерию веса - порядок наименования сырья на этикетке:

… да и форма XLS данного отчета позволяет делать сколь угодно сложный анализ состава изделия исходя из любых бизнес-критериев

Никогда не нужно было, а вот потребовалось...

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

Однако в среду озвучили проблемку при работе с технологическими (калькуляционными) картами. Массированно вводят, изготавливают, тестируют, изменяют потенциально новые изделия. У всех изделий разные наименования и всё надо делать очень быстро, т.е. забывая, что напридумывали, как следствие путаясь в списке ТК, т.к. дефолтно он сортирован только по наименованиям.

Индексов у таблицы шапок ТК реально два: по системному коду (порядке внесения в список) и по наименованиям изделий (тех.карт). Сейчас добавил и этот стандартный механизм системы в списков ТК, но так как его никогда не было, то для подсказки внес и в меню задач, а не только вызов кнопкой, как везде:

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

Захотел по маленькому, а вышло по большому - вот так и тщетны все планы наши

В срезе контура программы - "производство по заказам": https://olegon.ru/showthread.php?t=37616 мне была поставлена задача: автоматически вносить задание на производство в таблицу ведения производственных операций. В принципе логичное пожелание и только удивился, а что программа так не умеет? Сходу не нашел и записал, как домашнее задание... Изучил исходники, которые последний раз правил в 2019 году и ещё больше удивился: данное задание с количествами вносится в прогноз, количества в единицах техкарт вносятся автоматом при запуске производства. Начал изучать свои комментарии на предмет - почему раньше этого не сделал?

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

1. Сроки, по которым ещё не запускалось производство выделяются цветом;
2. В режимах добавления/изменения единичного производства можно сразу задавать точное или ориентировочное количество для производства;
3. При создании группового задания на производства задаётся альтернативная ветка для создания группового задания на производство. Если создаём из заказов, то сразу прописываются ориентировочные количества, которые можно поменять при "запуске" производства.

Все нюансы постарался отобразить на коллаже:

Недавно была поставлена логичная задача, связанная со спецификой ввода операций производства для разовых заказов, да и для серийных тоже пойдёт... Специфика:

1. Покупатель даёт разовый заказ;
2. По этому заказу делаю "прогноз", а из него м/с накладную на перемещение сырья в цех;
3. Изготавливают полуфабрикаты и готовую продукцию;
4. Изделия перемещают м/с на склады-холодильники для отпуска;
5. Создают расходную ТТН и при необходимости оплату.

Задача - по произвольному набору (группе) изготовленных изделий полуавтоматом делать м/с ТТН... извините звонок по работе ... вернусь

продолжаем... Произвольный набор объектов в системе реализуется через технику групп. В силу ненадобности в режиме производства его не было, т.е. нужно его создавать. Старый подход - внесение поля dGr в таблицу и использовать универсальную библиотеку работы с группами, но таблица производства большая, т.е. операции медленные, а так же вне задачи операторов врятли техника групп будет использоваться. Решил использовать изобретенную два года назад технику виртуального группирования. Её суть - уникальные коды объектов отобранных в группу храню в массиве памяти, а операции с группами изменяют данный массив. Время жизни групп - сеанс работы с программами. Оперативной памяти эти массивы занимают немного, но скорость работы с группами в сотни раз быстрее, чем обработка меток в таблицах БД... Кроме того и для этой техники уже создана библиотека универсальных функция. Решил - сделал:





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





Затем предварительно анализирует остатки по каждому блоку, выдавая сообщения типа:





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





... так же пришлось "повоевать" с нюансом точности в системе, где количества в истории, остатках, производстве ведутся с точностью 6 знаков, а в детализации накладных и других документов с точностью 3 знака

Не совсем по теме, но...
А что такое "м/с"?

Междускладское перемещение... Стандартное и древнее сокращение во многих режимах программы

Недавно на Мисте началось и неспешно, видимо по неоднозначности реализации, обсуждение реальной задачи:
… и тут выяснилось, что в рамках экосистемы "1С" данная задача плохо решается, а точнее, с оговорками наличия большого числа сообщений с самопиаром и "элементарно" по невозможным вариантам, по причинам:

1. 1С:Бухгалтерия - очень хорошая программа для бухгалтерского учета и отчетности, но "контуры" производства и торговли отрабатываются "декларативно";
2. 1С:УНФ - как бы решает задачи, но не для обычного небольшого производства и работать более чем одному грамотному пользователю довольно сложно;
3. УПП, ERP - слишком дорогие и сложные решения... Не трогаю "тему" пригодности.

Почитав обсуждения понял, что у нас, в связке "УС Лэнд" + "1С:Бухгалтерия" всё реализовано, так, как сформулировано в исходной задаче, да и стоимость решения низкая в сравнении с "альтернативами 1ц":

1. Банк автоматом вносится в бухгалтерию, там же определяются контрагенты. Затем через внешнюю обработку (ВО) выгружается в файл и автоматом банковские выписки и справочники 1С заносятся в УС;
2. Приход, продажи, счета-фактуры, преобразования сырья в готовую продукцию выгружаются в файл посылок, который через (ВО) загружается в 1С:Бух порождая документы и движения регистров... Раньше думал, что это сложная задача, но более понимая программирование в 1С, посмотрев обработку, понял, что это задача для "джуна" на месяц

Имея полностью автоматический обмен штат бухгалтерии 1.5 человека, который более занят "зарплатой и кадрами", а отчетность формируется автоматом, имеем:решение всех задач "автора" за "копейки" не раздувая штат предприятия и не кормя орду "франчей". Не удержался и упомянул "УС Лэнд" ожидаемо получив реакцию "фу, dos"...