Форум OlegON > Программы и оборудование для автоматизации торговли > Системы автоматизации торговли > КИС Lack & УС Land

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

29.03.2024 9:34


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

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

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

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





Задача изначально была – пачкой пропорционально поменять веса сырья с целью понимания изменения дохода и наценки, но при уяснении задачи понял, что «вес это не обязательно количество единиц», например единица—кв.метр… Хотя при попытке «глубокого» выяснения по ключевым изделиям, правда после отработки пакетной правки веса и/или количества, выяснилось, что это несущественно. Далее как обычно: вызываем новый режим и получаем требуемый результат (оценки).
07.04.2022 17:54
AndreyZh
 
Цитата:
AndreyZh Задача изначально была – пачкой пропорционально поменять веса сырья с целью понимания изменения дохода и наценки
Как понимаю - в среде профессиональных разработчиков принято: новая задача => новый режим или отчет => новое финансирование? К сожалению в "УС Land" не так == стараюсь подцепить новую задачу к уже существующему режиму, как геморно это ни было, но зато пользователи не уходят от привычных технологий... В среду "сорвались":

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

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





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

Код:
                       Влияние цены сырья на стоимость Торт * Вдохновение 800гр       шт на 06.04.22                       Стр.  1
Цена по продаже сейчас     152.00 Наценка    70.11% Новая цена закупа       89.36 Новая цена продажи    152.00 Вес сырья     0.967
----------------------------------------------------------------------------------------------------------------------------------
Н/п|                    Наименование сырья            |КодА| Количество |Ц. закупа|СуммаПоСырью|ДоляВИзд| Вес cырья |ДоляВИзд|Пр.
   |                        1                         | 2  |      3     |    4    |     5      |    6   |     7     |    8   |   
----------------------------------------------------------------------------------------------------------------------------------
  1 00 бисквит круглый 260 гр крахм.(Турбо) шт         02BG     1.000000     19.11        19.11 21.3865%    0.260000 26.8868%
  2 Сахар                            кг                0005     0.180364     85.00        15.33 17.1572%    0.180364 18.6516%
  3 03 крем взб. сливки с подваркой  кг                02NA     0.135520     75.00        10.16 11.3748%    0.135520 14.0142%
  4 Т-212В                                             024M     1.000000     10.15        10.15 11.3591%    0.000279  0.0289%
  5 Т-212н                           шт                013X     1.000000      8.02         8.02  8.9754%    0.000129  0.0133%
...
 19 Вода                             лт                0046     0.255640      0.02         0.01  0.0057%    0.255640 26.4359%
… да и форма XLS данного отчета позволяет делать сколь угодно сложный анализ состава изделия исходя из любых бизнес-критериев
12.08.2022 09:21
AndreyZh
 
Никогда не нужно было, а вот потребовалось...

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

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

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

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

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

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

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

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

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

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

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

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





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





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





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





... так же пришлось "повоевать" с нюансом точности в системе, где количества в истории, остатках, производстве ведутся с точностью 6 знаков, а в детализации накладных и других документов с точностью 3 знака
04.01.2023 23:11
KirillHome
 
Не совсем по теме, но...
Цитата:
AndreyZh из него м/с накладную
Цитата:
AndreyZh перемещают м/с на склады-холодильники
А что такое "м/с"?
05.01.2023 07:45
AndreyZh
 
Цитата:
KirillHome А что такое "м/с"?
Междускладское перемещение... Стандартное и древнее сокращение во многих режимах программы
31.03.2023 08:41
AndreyZh
 
Недавно на Мисте началось и неспешно, видимо по неоднозначности реализации, обсуждение реальной задачи:
Цитата:
тут ко мне обратился знакомый с просьбой помочь в выборе программы для УПРАВЛЕНЧЕСКОГО учета (но с интеграцией в бухгалтерию). у них небольшое отверточное производство неких электронных приборов + продажа, данных пока у меня практически нет, только общее представление о ситуации. Основных целей которые ставятся четыре:

1. корректный складской учет комплектующих (номенклатура малюсенькая, около сотни), ну и готовой продукции.
2. расчет себестоимости (каким методом не знаю, но предположу из того, что знаю про "знакомого", что это будет прямые затраты + пропорциональное деление косвенных)
3. ведение взаиморасчетов (тут точно будут схемы более хитрые чем в бухгалтерии)
4. торговля, тут нужна будет ценовая политика и наверно частично всякая хрень вроде "воронки продаж"

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

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

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

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

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

Форум на базе vBulletin®
Copyright © Jelsoft Enterprises Ltd.
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.