<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Очень интересно. Не так давно сделал собственный расчет дефицита с учетом аналогов с приоритетами по датам запуска заказа. Также сделал регистр отслеживающий изменение дефицита ежедневно.
У тебя реализован универсальный расчет — это конечно сильно расширяет горизонт применяемости.
Не очень понял как с помощью твоего инструмента рассчитать дефицит, если есть несколько аналогов с разными приоритетами использования. Видимо, чтобы понять нужно попробовать. Буду ждать примеров реального использования.
Пара вопросов:
1. Почему не пошли по пути ключей аналитики, вместо создания реквизитов типа Аналитика потребности 1, Аналитика потребности 2?
2. Нужно ли что-либо дорабатывать, чтобы учесть нереализованный спрос (например, неотгруженные позиции по уже закрытым заказам, по которым нет остатка на складе)?
эээ… как-то слабо понял (не спец) — планирование — это же оптимизационная задача?
есть вот куча потребнсотей, есть куча ресурсов — как распределить ресурсы на потребности для достижения максимального результата…
?
(1)
Элементарно, см. раздел про сложное сопоставление.
Ты должен написать такой запрос, который соединит ресурсы с регистром аналогов, и отсортирует их по приоритету использования аналога.
Это фишка, которую я хотел раскрыть в следующей публикации — при использовании сложного сопоставления ресурсы можно пересортировывать так, как тебе нужно. Я так сделал когда-то планирования работы программистов в две стороны сразу — asap и alap.
да, с УМП это главное.
(2)
пошел когда-то, было такое заказное ответвление УМП — «Распределение ресурсов». Там не было аналитик, были ключи с жесткими реквизитами — номенклатура, характеристика, чего-то еще.
Отчеты писать проще, но свобода очень сильно ограничена, потому что регулировать состав ключей неудобно, где бы он ни хранился — в реквизитах ключа, в ТЧ ключа, в РС.
В общем, основное — из-за ограничения свободы.
Ничего дорабатывать не нужно, нужен лишь запрос, который эти данные достанет. Это вроде несложно — это расход по регистру ЗаказыПокупателей с отбором по типу регистратора (ЗакрытиеЗаказовПокупателей).
Вы хотите это в качестве потребностей использовать? Напрашивается что-то вроде буфера по таким позициям. Задача ровно для УМП, типовые такого не умеют.
(3)
вот тут сразу две задачи — распределить и достичь результата.
В типовых конфигурациях первая задача не решена — распределить. Куда уж до оптимального результата.
(5) Понятно, тоесть в качестве потребности тоже может выступать любой запрос. Попробую на досуге прикрутить для маленького интернет-магазинчика на УТ 11.3 в качестве бэка.
(7) любой запрос в качестве потребности, любой запрос в качестве ресурса, любой запрос их соединяющий.
Можно распределять товары по кассе, заказы понедельника по 13-й зарплате, приходы денег больше 100 тыс.р. на женскую часть коллектива и т.д.
Неплохо. Интересный подход.
Сюда прикрутить еще механизм внешних «внеплановых» событий, которые влияют на логику и приоритеты расчетов (в виде отдельного регистра, например, и отдельный запрос к нему + сложное сопоставление).
Плюс реализовать какой-нибудь движок процессного типа (блок схема, идем от начала до конца, в точках обращаемся к УМП-движку и в зависимости от фактов, делаем дела — стартуем процессы, рассылаем задачи и т.п.)
Получиться автоматическая аналитическая система принятия решений и исполнения на их основе задач (предложения, закупки, резервирования, продажи, пополнение складов и тп.)
В целом, я например уже вижу, как с помощью этого можно автоматизировать процесс расчета Мотивации сотрудникам.
На входе номинальные цифры, планы на год (месячные), обороты продаж с накоплением в разрезе чего-угодно (филиалы, подразделения, сотрудники) + схемы расчетов (коэффициенты, пороги отношений (план/факт)) + схемы KPI.
На выходе: расчеты из фактических цифр относительно планов и логики расчетов бонусов и автоматические ведомости в бухгалтерию на выплату бонусной части )))
Easy
(6)
Но простейшие варианты возможно тут реализовать — например, рассчитывать маржинальность заказов покупателя на основании плановой себестоимости (или с/с на складе, сумм в заказе поставщика, ценах поставщика и т.п.) и сортировать источники потребностей по этой маржинальности, добавив сроки отгрузки, политических клиентов и т.п. в условия сортировки.
Я верно идею понял?
(9)
да, мы так делали. Например, регистр с приоритетами заказов, который Важный Человек мог двигать.
Единственное, что он внешний и внеплановый только для типовых объектов, а для УМП все равны. Она под конец научилась и из внешних источников данных читать.
да, именно так. Мы делали через и рабочий стол (не опубликован).
(11) верно. Именно с этих идей начинался УМП в далеком 2006 году — «набрать» план производства из заказов на производство, максимизируя прибыльность, сумму реализации и загрузку оборудования.
Уважаемый CheBurator, вероятнее всего, имел в виду задачу оптимизации, когда подбирается оптимальное решение с учетом всех ограничений. Такое делают симплекс-методом или генетикой.
УМП работает проще и, как мне кажется, в итоге эффективнее. Ребята, которые заморачиваются генетикой, когда не умеют еще задницу подтирать, результата не достигают.
Нисколько не умаляю достижения оптимизации, но ее место обычно на цеховом уровне, вроде оптимизации раскроя, а не составления производственной программы в условиях постоянной, ежедневной неопределенности всех видов ресурсов.
Мну мучают задачи распределения складских ресурсов (человеко-время исполнителей) на складские задачи передвижения объектов по складу…
(14) мучают — в смысле решить не можете?
Можете поподробнее рассказать?
(14) А вы уже отнормировали все складские операции?
(15) Например, на разгрузке стоит 10 фур, в них 200 тонн товара, за сколько с таким объемом справится 10 человек.
(17) Кстати, правильный ответ — какого хрена все эти 10 фур приперлись в одно время 🙂
(16) отнормировать более-менее правильно — не проблема, статистика есть
(17) это более-менее тривиальная задача, так как нет конкуренции за ресурсы.
а вот если есть два погрузчика кооторые должны обслужить и фуру и отборы, причем отборы разной важности и разного объема, причем вместо погрузчика если что можно задействовать штабелер, который должен еще и заниматься подпиткой и размещением и все это дышит — тут сразу все непросто становится…
я пробовал решить даже более простую задачу — не сам, а челловека привлек — но заглохло, отчасти и по моей вине.
для начала хорошо бы спланировать возможность выполнения совокупности заказов к установленным временам готовности в условиях появления новых заказов и известной емкости ресурсов на задачу обслуживания заказов…
(19) Хорошо вам, а тут пришло 20 тонн конфет 150 наименований и 20 тонн муки в мешках по 50 кг, попробуй отнормируй, чтобы у людей зарплата более-менее одинаковой на сделке получилась…
(20) Задачи интересные конечно, а если получится, что в результате расчетов при увеличении количества заказов на 10% надо еще один погрузчик покупать — его купят, или нормативы времени на обработку заказов уменьшат?
(21) нормируйтесь по временным затратам.
Внятный механизм и определения стоимости и определения ресурсов — см.у Перова Д.
(23) Не все так просто, ну да ладно, не для этой темы разговор.
мда с ходу не осилить …..
Заинтриговало еще больше
скачал — для работы Вам требуется платформа не меньше 8.3.9
Текущая версия 8.2.19.90
Печально — а есть ли под 8.2.19.90
(26) упс, не поставил режим совместимости, когда сохранял УМП отдельно от УПП. Исправлю.
Пока можете поправить сами — загрузить конфигурацию в пустую базу, поставить режим совместимости, сохранить в файл и пользоваться.
А можно ли сделать так, чтобы УМП кроме изменения дефицита, отслеживала ещё и изменение потребности? Если скажем потребность не статична и может меняться. Например отмена заказа покупателя или изменение норм в результате конструкторских доработок?
(3) Суть решение задачи нахождения локального оптимума =)
(24) в WMS подход немного другой — там больше комбинаторика нужна + здоровая статистика + фактические свойства склада/варианты отгрузок/единицы хранения
(17) ну тут простая математика — достаточно знать (замерить тестами) за сколько выполняет одну полную операцию 1 человек над одной (максимально возможной для человека) порцией груза, а также комбинации 2-3 человека совместно за сколько могут выполнить одну полную комбинацию разгрузки. Все это сложить и варианты разделить на общее кол-во груза. и получим ответ =) Но незабываем про обеды, перекуры и передышки..
(30) суть — внедрение внешних событий, отельный запрос к ним. И «рассмотр» этих событий как таблицу, которая «отдает» изменения в потребностях относительно базового плана (по потребности)
(33) Это все в теории просто, на практике все несколько сложнее, и сильно зависит от конкретного склада. Еще раз повторю — этот инструмент не для WMS (и обсуждение не для этой темы соответственно)
(30) Хотя все зависит от сложности учета. Если отмена Заказа подразумевает Отмену резерва товара (управленческого), отмена движений по запланированным отгрузкам, отмена
складского резервирования. Были ли внедрены по данному заказу Наряды на отгрузку, возможно от этого тронулось перемещение между складами (пополнение под заказ), а также задачи связанные с будущей необходимостью закупки новой партии товара (в заказе).
В общем не всегда все можно просчитать глубоко вперед. Есть «предел видимости» просчета, в которых он точно будет исполнимым до конца. Но есть внешние факторы, не привязанные к ресурсам и/или количественным показателям. Необходимо их во-первых учитывать, во вторых «трансформировать» к вычислимым значениям (в цифры), чтобы система смогла строить по ним связи/сравнения.
(25) все проще, чем кажется. Главное — начать.
(30) да, конечно. УМП итак отслеживает именно изменение потребностей.
Дефицитные они или нет — решает разработчик.
Если хочешь именно отслеживать потребности, без учета их обеспеченности — просто скопируй профиль и убери оттуда ресурсы и сопоставление. У тебя будет профиль, который знает только ресурсы. И будет писать их в регистр, и красиво изо дня в день делать приход и расход по регистру, отражая динамику.
(36) Я не использую резервирование, остатки при расчете дефицита распределяются динамически. Поэтому мне и необходимо отслеживать изменения потребностей. «Передел видимости» в данном случае — определяется открытыми заказами на производство.
(38) Тогда получается мне необходимо вести две настройки УМП? Одну для отслеживания обеспеченности, другую для отслеживания изменений базовых потребностей. Именно не остатка потребностей, а прихода.
Также, хочется попробовать эту подсистему для оценки производства. У меня есть план производства, его могу расписать по операциям и трудоемкости. Если завести таблицу доступности фонда рабочего времени для каждой операции, то УМП сможет просчитывать и отслеживать дефицит фонда рабочего времени по открытым заказам.
Это возможно? Вести отслеживание нескольких разных расчетов?
(40)
Да. Одна делается копированием другой.
да.
да, это одна из главных особенностей УМП — многовариантность. Делаешь сколько надо профилей, каждый живет своей жизнью.
Впечатляет — наконец-то руки дошли
(42) по-настоящему впечатлит, когда пользоваться начнете, особенно на реальной бизнес-задаче.
(43) применяли для расчета потребностей-обеспечения в производстве?
(44) конечно, много раз.
(45) разузлование спецификаций тоже в запросе делали?
(46) нет. Делал два варианта.
Первый — УМП позволяет после выполнения запроса выполнять произвольный код. Я делал разузлование типовыми средствами, в документ попадало уже разузлованное.
Но это хреновый способ, т.к. требует много времени.
Поэтому придумал второй — кеширование разузлования. В отдельном регистре сведений лежат результаты разузлования по всем номенклатурам, имеющим спецификации. При изменении спецификаций или номенклатур регл.задание делает пересчет.
К такой структуре легко и удобно обращаться запросом. Эту штуку тоже хотел опубликовать, но отдельно, т.к. она только для УПП и КА 1.
(47) Плох тот программст 1С, который не делал разузлование запросом :). Решение с регистром видел в УПП на предыдущей работе, может, и вашими идеями было вдохновлено.
(48) возможно и нашими — первый вариант кеширования даже в ПМК 1С:Машиностроение вошел. См . Я эту какашку делал.
(48) а если мотнете на слайды 37-38, то увидите первый вариант УМП 🙂
Эх, ностальгия накатила. 11 лет прошло.
(47) нет доверия к перерасчету
таким образом можно и сервер положить
(51) Именно поэтому перешли на запросы, что в общем стало возможно благодаря тому, что максимальная глубина была известна и не превышала 7…
(51) нет, если нормально отрегулировать расписание и очередь пересчета.
НСИ меняется не так часто. Проблема возникает только в том случае, если кто-то перезаписывает всю номенклатуру групповой обработкой. Но это не проблема нагрузки, а проблема длинной очереди. Если очередь обрабатывается не вся сразу, а, например, по 5 позиций, то сервер не ляжет.
(52) для использования запросов, есть много ограничений (
(53) достаточно поменять несколько раз основную спецификацию — и я не уверен в корректном результате )
(53) так и не понял — а причем справочник номенклатура к разузлованию ….
что можно поменять в номенклатуре, что бы пересчитывать разузловку?
(55) учет по доп.характеристикам, вид воспроизводства, вид номенклатуры.
Но вообще это вроде не важно. Подписаться можно на то, что нравится.
приступил к освоению
потребности, ресурсы заполнил
а вот настройкой сопоставления — встрял
если шаблон указываешь и жмешь выполнить
Справочник.ИсточникиДанныхУМП.Форма.ФормаЭлемента.Форма(73)}: Ошибка при вызове метода контекста (Вывести)
ПроцессорВывода.Вывести(ПроцессорКомпоновки, Истина);
по причине:
Ошибка вывода результата
по причине:
Ошибка при выводе результата
по причине:
Ошибка получения данных
по причине:
Ошибка создания набора данных «НаборДанных1»
по причине:
Ошибка при исполнении запроса набора данных
по причине:
{(8, 35)}: Не задано значение параметра «ДокументПланирования»
ДанныеУМП.ДокументПланирования = <<?>>&ДокументПланирования
а его вроде как и должно быть
(57) настройку сопоставления выполнять смысла нет — ей нужны на вход данные, которые есть только в момент планирования. Указывайте настройку в профиле и пробуйте запустить планирование.
В частности, параметр ДокументПланирования заполняется при выполнении планирования.
угу вроде что-то начинает получаться — цифирки только не идут
выборку делал по оборотам
по остаткам не информативно
Добавил в конце статьи три кейса — стандартные ситуации закупа, и как их решать с помощью УМП.
(60) Неплохо было бы сделать демобазу с какой-нибудь из этих настроек.
(61) да, надо.
Сделаю, когда у публикации +100 будет.
(62) Фи, как меркантильно :)))
Друзья, прошу прощения за спам — поучаствуйте в .
Можете подсказать можно ли настроить УМП в след ситуации (разделка и продажа мяса): Есть план на неделю какие запчасти туши получить: например вт окорок, лопатка и тд в каких то количествах. Среда тоже какие то материалы. и т/д. Материала из которого будут производить пока нет либо он в заказе поставщику едет. Но хотят уже резервировать заказами покупателя и ставить в резерв (по сути воздух). Но когда будет реальный выпуск (ОПзС) товар появится на складе и в заказах нужно будет подменить склад (с вируального на реальный). Как то так. Понятно что не все можно сделать УМП, но не могу понять нужна ли тут УМП?
(65) всю задачу УМП не решит, т.к. не лезет в типовые документы и не делает резервирования.
Но задачу распределения между потребителями решит:
1. Покажет, какому заказу покупателя из какого заказа поставщику что достанется;
2. Когда будет ОПзС, и произойдет выпуск, раздаст тем же заказам покупателя остатки склада (только что нарезанные туши);
3. В процессе будет показывать лишние части туши, которые никем не востребованы.
Нужно будет только изготовить обвязку, которая информацию из УМП подставит в резервы. На одном из внедрений местные программисты написали для этих целей обработку — она несложная, т.к. вся информация в УМП есть.
В том числе, резервирование может выступать источником данных для УМП, т.е. получается система с обратной связью:
1. Первый раз, когда резервов нет, а есть только заказы (покупателей и поставщикам), раздаст виртуальные части туши;
2. Вы обработкой раздадите резервы;
3. В следующей итерации УМП эти резервы будут учтены.
(43) Иван, а как передать параметры в СКД?
Допустим, у меня потребность — план продаж.
Мне надо выбрать обороты за определенный месяц
(67) какой-то конкретный месяц? Или типа «следующий», «текущий»?
По логике, такие параметры надо прям в СКД вычислять — либо используя стандартные периоды («Этот месяц» и т.д.), либо вычисляя значения параметров кодом (типа ТекущаяДата()).
Для крайнего случая есть параметр ДокументПланирования, в него передается ссылка на док, выполняющий расчет.
(68) Месяц даты документа планирования, например.
(69) вообще, предполагается, что документ планирования — всегда сегодняшний, поэтому дата всегда известна. Просто используйте тек.дату.
Исключение составляют ретроспективные пересчеты, но у вас, вроде, не тот случай.
(70)У меня потребность в оборотном регистре (план продаж), поэтому я не могу просто взять текущую дату.
(71) так вы в запросе к ней НачалоПериода и КонецПериода приделаете, и будет вам текущий месяц.
(72)Спасибо, тупанул)
upd: разобрался. Дата потребности — это параметр
Иван, подскажите еще.
Не понял как сделать сопоставление:
С заказами поставщикам – через СКД, в отборе указать Дата потребности ≥ Даты доступности.
В запросе настройки сопоставления из потребности есть только идентификатор строки.
(74) так, что в итоге? На какой вопрос ответ нужен?
(75) пока разобрался, спасибо