M_MNPLAN
Краткое описание :
Алг. 153 Размер сумм оплаты в оборотной стороне наряда при
ненулевых часах "фактОписание :
по 153-му системному алгоритму "Формирование нарядов "Что измененно :
Алг. 153 Размер сумм оплаты в оборотной стороне наряда при
ненулевых часах "факт"
По инциденту 2.29308
На текущий момент алгоритм в оборотной стороне наряда рассчитывает и
распределяет сумму оплаты по каждому сотруднику в наряде. Если по сотруднику в
оборотной стороне наряда есть несколько записей (имеются переходы в межпериод),
то сумма оплаты распределяется между этими записями пропорционально значению в
поле "Часы факт" в оборотной стороне наряда.
Но бывают ситуации, когда данное значение равно нулю - сотрудника вызвали,
например, из отгула поработать, оплату необходимо провести, но в табеле часы
факт не отмечается. В этом случае алгоритм выводит нулевое значение по оплате.
Необходимо, чтобы при распределении суммы оплаты для позиций оборотной стороны
наряда, где значение в поле "Часы факт" равно нулю, алгоритм задействовал
ненулевое значение.
В оборотной стороне наряда часы изменять не надо - как был ноль в поле часы
"факт", так он и должен остаться. А алгоритм должен только распределить сумму
для этой позиции.
Для этого он должен брать вместо ноля более реальное значение - плановые
часы для этой позиции оборотной стороны. В то же время плановые часы также
могут быть равны нулю - если сотрудник работал в выходной по табелю, то часы
план будут нулевыми. В таком случае (когда и "факт" и "план" нулевые)
предлагается делать так:
1. Если у конкретного сотрудника только одна позиция в оборотной стороне
наряда, и часы "факт" и "план" по этой позиции равны нулю, тогда в качестве
оплаты нужно просто брать его долю от суммы из лицевой стороны. Если сотрудник
один в наряде - вся оплата по лицевой стороне наряда его. Если их трое, то
треть оплаты и т.д.
Пример:
Оплата по наряду - 1000.00р
Иванов - 8ч(ф) - 333.33р
Петров - 11ч(ф) - 333.33р
Сидоров - 0ч(ф) - 333.33р Треть оплаты от суммы в лицевой стороне.
2. Если у конкретного сотрудника несколько позиций в оборотной стороне
наряда, и по некоторым позициям часы "факт" и "план" равны нулю, тогда в
оборотной стороне наряда:
- из позиций по сотруднику выделять ту, которая имеет наименьшие ненулевые
часы (в примере - 2 часа по сотруднику Сидоров)
- брать сумму оплаты этой позиции и распределить ее равномерно по этой
позиции и всем тем позициям, по которым ненулевые часы для распределения
определить не удалось (в примере - на 3 позиции).
Пример:
Оплата по наряду - 1000.00р
Иванов - 8ч(ф,п) - 333.33р (1000.00/3)
Петров - 11ч(ф,п) - 333.33р (1000.00/3)
Сидоров - 6ч(ф,п) - 250.00р (1000.00/3/8*6)
Сидоров - 2ч(ф,п) - 27.78 (1000.00/3/8*2/3) Сумму за 2 часа
распределяем на 3 позиции
Сидоров - 0ч(ф,п) - 27.78 (1000.00/3/8*2/3)
Сидоров - 0ч(ф,п) - 27.78 (1000.00/3/8*2/3)
(ф) - значение часы факт
(п) - значение часы план
(ф,п) - значение часы факт или часы план
Смысл в том, что с одной стороны не должно быть начислений с нулевыми
суммами, с другой стороны - убрать из наряда их тоже нельзя.
С заказчиком (Алтайвагон) этот вопрос обсуждался - в табеле они факт
работы отражать никак не желают, хотят видеть только сумму, начисленную за
выполнение работы с нулевыми часами.
Можно создать новые настройки:
- "Использовать плановые часы при нулевом факте" = да/нет
- "Проводить распределение по нулевым позициям оборотной стороны" = да/нет
Как измененно :
Реализовано в рамках проекта Алтайвагон (настройка алгоритма
153 "Использовать справочник норм времени и расценок, как источник для расчета
затрат" = "нет" )
M_MNPLAN
Краткое описание :
Множественный выбор подразделений с использованием
системной настройки "ПомечатьОписание :
по 153-му системному алгоритму "Формирование нарядов "Что измененно :
Множественный выбор подразделений с использованием системной
настройки "Помечать вложенные подразделения" модуля "Зарплата"
По инциденту 2.29310
В процессе работы алг. 153 открывается окно "Выбор подразделения", которое
позволяет сделать единичный выбор подразделения. Возможность выбора появляется
при настройке алгоритма "Способ выбора подразделения" = "Запрашивать при
запуске".
Необходимо обеспечить возможность множественного выбора подразделений. При
этом при выборе подразделения должны автоматически выбираться все вложенные
подразделения, например все участки выбранного цеха.
Такую возможность обеспечивает применение системной настройки Управление
персоналом => Расчеты с персоналом => Выбор работников => Помечать вложенные
подразделения = "да" и связанного с ней функционала. Настройка игнорируется,
если список подразделений отображается в виде плоского дерева.
Настройка "Помечать вложенные подразделения" является пользовательской
настройкой (то есть у каждого пользователя может быть свое значение) и влияет
на пометку в интерфейсах выбора подразделений. Вряд ли ее значение
анализируется при расчете зарплаты (А. Капустин).
Для перманентного отображения списка подразделений в виде иерархического
дерева должна быть включена системная настройка Настройки Галактики => Общие
настройки системы => Интерфейсы выбора => Представлять каталог подразделений в
виде дерева = да.
Как измененно :
реализовано
M_MNPLAN
Краткое описание :
Настройка группировки работ по сотруднику в лицевой стороне
нарядаОписание :
по 153-му системному алгоритму "Формирование нарядов "Что измененно :
Настройка группировки работ по сотруднику в лицевой стороне
наряда
По инциденту 2.29313
Необходима еще одна настройка группировки данных по СЗ. Данная настройка
должна принимать 2 значения:
- Группировать работы по сотруднику/бригаде в один наряд = да - так сейчас
работает алгоритм, формируя один наряд на сотрудника/бригаду за указанный
период.
- Группировать работы по сотруднику/бригаде в один наряд = нет - в этом случае
алгоритм должен формировать на каждое СЗ, где сотрудник/бригада
задействован(а), отдельный наряд. При этом работы по сотруднику/бригаде
группируются в рамках каждого СЗ и записываются в лицевую сторону наряда.
Как измененно :
Реализовано в рамках проекта Алтайвагон (настройка алгоритма
153 "Использовать справочник норм времени и расценок, как источник для расчета
затрат" = "нет" )
M_MNPLAN
Краткое описание :
Настройка метода определения вхождения в текущий периодОписание :
по 153-му системному алгоритму "Формирование нарядов "Что измененно :
Настройка метода определения вхождения в текущий период
По инциденту 2.29311
Необходимо добавить значение в настройку алгоритма "Метод определения
вхождения в текущий период" = "По начальной дате". Т.о. должна быть возможность
собирать данные по ССЗ, попадающим датой начала в период, указанный при запуске
алгоритма.
Как измененно :
реализовано
M_MNPLAN
Краткое описание :
Ввести настройку для выбота типа маршрута при формировании
нарядаОписание :
по 153-му системному алгоритму "Формирование нарядов "Что измененно :
Ввести настройку для выбота типа маршрута при формировании
наряда
По инцидентам 2.29314 и 2.29315
Описание во вложении.
Как измененно :
реализовано
M_MNPLAN
Краткое описание :
Динамическая настройка ШПЗ и ПОЗ при формировании нарядовОписание :
по 153-му системному алгоритму "Формирование нарядов "Что измененно :
Динамическая настройка ШПЗ и ПОЗ при формировании нарядов
По инциденту 2.29317
Необходимо добавить возможность указания шифра производственных затрат (ШПЗ)
и подразделения отнесения затрат (ПОЗ) при запуске алгоритма формирования
наряда.
Подробное описание во вложении.
Как измененно :
реализовано
M_MNPLAN
Краткое описание :
8.10 алг 103(5) Не корректный расчет c учетом предыдущих
позицийОписание :
по 103-му алг "Формирование журнала резервирования по плановым документам"Что измененно :
8.10 103(5) Не корректный расчет c учетом предыдущих позиций:
т.е настройка
Учитывать зависимость позиций документа-источника при расчете сроков выполнения
операций Да
при такой настройке не выполняется разузлование.
Как измененно :
Для параметра "Учитывать зависимость позиций
документа-источника при расчете сроков выполнения операций" добавлено описание:
"Если значение да, то расчет идет только по нулевому уровню".
M_MNPLAN
Краткое описание :
8.10 ПП АлтайВагон 135 алг. Лишнее сообщениеОписание :
по 135-му системному алгоритму " Получение остатков для плановых документов..."Что измененно :
8.10 ПП 135 алг. Лишнее сообщение
Открыл окно на редактирование и тут-же ничего не делая закрываю
появляется сообщение
---------------------------
Подтверждение
---------------------------
Параметры настройки алгоритма были изменены.
Сохранить изменения?
---------------------------
Да Нет Отмена
---------------------------
Это сообщение вводит в заблуждение.
Как измененно :
Исправлено. Если настройки не редактировались, сообщение
выводится не будет.
M_MNPLAN
Краткое описание :
Ошибка обнуления наличия остатков в 135 алгоритме при
расчете на фиксированную датуОписание :
Алгоритмы расчетаЧто измененно :
Ошибка обнуления наличия остатков в 135 алгоритме при расчете
на фиксированную дату,
Если было значение в поле >0, а текущий остаток 0, то не корректирует запись.
Если было значение 0 или >0, а текущий остаток >0, то поле корректируется верно.
Как измененно :
Исправлено
M_MNPLAN
Краткое описание :
8.10 ПП 103(5) в режиме Учитывать зависимость позиций
документа-источника при расчете сроков выполнения операцийОписание :
по 103-му алг "Формирование журнала резервирования по плановым документам"Что измененно :
8.10 ПП 103(5) в режиме
Учитывать зависимость позиций документа-источника при расчете сроков
выполнения операций -да
Учет длительности выполнения операции, при отсутствии записей ЖР
-да
на корректный расчет фактических дат например:
тест: N:\LIBAQATEST\810\REL+OBNOVL\PROIZV\Satin\TestDirectSql\
сегмент:
см также вложение
Как измененно :
Теперь длительность позиций без МК при расчете вперед
(сокращении времени производства) учитывается корректно.
M_MNPLAN
Краткое описание :
8.10 ПП 103(5) Не корректный расчет дат при групповом
выполнении 103(5)Описание :
по 103-му алг "Формирование журнала резервирования по плановым документам"Что измененно :
8.10 ПП 103(5) Не корректный расчет дат при групповом
выполнении 103(5)
в режиме:
Учитывать зависимость позиций документа-источника при расчете сроков выполнения
операций -да
Учет длительности выполнения операции, при отсутствии записей ЖР
-да
Как измененно :
Теперь при распределении позиций без МК не учитываются графики.
M_MNPLAN
Краткое описание :
8.1УПЛ. Алг57.Сообщение об ошибке при создании нового
шаблонаОписание :
по 57-му системному алгоритму "Работа с таблицами расчета количеств "Что измененно :
При создании нового шаблона ТРК (или изменении по F4)
появляется сообщение об ошибке
"Ошибка!!! prTypeDoc = 37 prNumAnl_Doc = 1 prcTmpl_Doc = 0, 1 ф.
GetcKatRole_HeadDoc"
Как измененно :
Исправлено
M_MNPLAN
Краткое описание :
Не отрабатывает настройка шаблона при выборе документов из
входящихОписание :
по 74-му системному алгоритму "Агрегация в период"Что измененно :
Не отрабатывает настройка шаблона при выборе документов из
входящих: Заданы настройки: "шаблон документа-источника" = ПЗ конкретный шаблон
и "Режим поиска документа-источника" = "Входящие для документа-приемника" В
протоколе указывается перечень обработанных документов, который включает как ПЗ
других шаблонов, так и ПП. При этом в спецификацию приемника попадает 4 позиции
вместо нескольких сотен.
Как измененно :
Исправлено
M_MNPLAN
Краткое описание :
HELP. Не подключен топик к окнуОписание :
Не знаю, какая именно часть производственого контура, научитеЧто измененно :
HELP. Не подключен топик к окну подтвердите значение к выбору.
Попадаю из документов логистики по ФЛМ Планирование - входящие документы:
в средней панели выбор производственного заказа ....
Как измененно :
Подключен топик с идентификатором D_GetFormNa к окну
"Подтвердите значение к выбору"
M_MNPLAN
Краткое описание :
Не рассчитывает если Расчет на основе = Выбор из спискаОписание :
по 13-му системному алгоритму "Расчет плана по заявкам"Что измененно :
Не рассчитывает если Расчет на основе = Выбор из списка
В настройке алгоритма было указано Расчет на основе = по входящим,
Фильтр на позиции спецификации = Обрабатывать По группам МЦ- ЧЕРНЫЕ
МЕТАЛЛЫ.
Изменяю Расчет на основе , указываю = Выбор из списка. В этом случае
фильтры уже недоступны. Произвожу расчет, План сбыта не формируется.
Для того чтобы формировался, перед изменением опции Расчет на основе
нужно убрать фильтры.
DataBaseName=D:\DN_91, План сбыта Шаблон План Сбыта(№ 0001),
п. мепню Расчет по заявкам Плана сбыта (верт.),при выборе из списка
указать заявку 000387.
Как измененно :
Т.к. при значении настройки "Выбор из списка" фильтры
недоступны, то учитывать их нет никакой необходимости.
M_MNPLAN
Краткое описание :
Неверное сообщение при запуске алгоритмаОписание :
Шаблоны регламента документовЧто измененно :
Неверное сообщение при запуске алгоритма
База \\By01-796\d\DN_91 Заявка снабжения.
В регламенте документа для состояния Утверждена указано разрешение на
смену статуса,
а разрешение на выполнение действий отсутствует.
Запускаю алгоритм из заявки в статусе утвержденный.
Сообщение "Разрешение на изменение статуса документа отсутствует".
Должно быть "на выполнение действий".
Как измененно :
Изменено сообщение "Разрешение на изменение статуса документа
отсутствует" на "Разрешение на выполнение действий отсутствует" при запуске
алгоритма из заявки в статусе утвержденный
M_MNPLAN
Краткое описание :
По инциденту 2.42551 22-й Не совпадают типы статусов
позиций документа и статусов фильтра по позициямОписание :
по 22-му системному алгоритму "Копирование и агрегация документов"Что измененно :
Выбранные пользователем статусы в настройках алгоритма для
фильтра по спецификации не являются разрешенными к выбору и использованию в
спецификации документов планирования производства. Из-за чего при отработке
алгоритма все позиции спецификации оказываются заведомо не попадающими под
ограничения фильтра данного алгоритма. Данная ошибка возникает из-за того, что
при выборе списка возможных значений статусов не определен тип документа, с
которым будет работать данный алгоритм. Необходимо разрешить определение типа
документа (поле "Тип документа" на закладке "Документ") вне зависимости от
значений остальных настроек алгоритма чтобы значение данной настройки могло
быть использовано при выборе списка статусов.
Как измененно :
Сделано
M_MNPLAN
Краткое описание :
9.1 ПП Планирование производства | Настройка | Регламенты |
Регламент документов | Шаблоны регламентов и состояний документов планированияОписание :
Шаблоны регламентов и состояний документов планированияЧто измененно :
9.1 ПП Планирование производства | Настройка | Регламенты |
Регламент документов | Шаблоны регламентов и состояний документов планирования
При выполнении функции F7 (добавить состояние) в правом среднем окне,
происходит выход в режим корректировки первого по списку состояния,
а не в режим корректировки добавленного.
Как измененно :
Исправлено.
& УНАСЛЕДОВАННЫЕ ИЗМЕНЕНИЯ ШАБЛОНОВ:
NARREP.XLT
M_MNPLAN
Краткое описание :
9.1 ПП 103(5) Не выполняется расчет ЖР по Графику выпуска
готовой продукции (ПП)Описание :
по 103-му алг "Формирование журнала резервирования по плановым документам"Что измененно :
9.1 103(5) Не выполняется расчет ЖР по Графику выпуска готовой
продукции (ПП)
тест : n:\LIBAQATEST\910\REL+OBNOVL\PROIZV\Satin\AltayVagon\
сегмент: 021_ПП_103(5) алг Расчет ЖР по Графику выпуска готовой продукции (ПП)
AQA_StrMessage('Ошибка при формировании первых операций: код = 904 Вышлите
файл ora90drv.log разработчикам.',cmOK);
Как измененно :
Исправлено падение на оракле
M_MNPLAN
Краткое описание :
инц. 2.44423 АТС Проджект 22-й Если кол-во выбранных полей
более одного, то при повторных запусках алгоритм добавляет, а не замещает
значение для поля отличного от первогоОписание :
по 22-му системному алгоритму "Копирование и агрегация документов"Что измененно :
инц. 2.44423 АТС Проджект 22-й Если кол-во выбранных полей
более одного, то при повторных запусках алгоритм добавляет, а не замещает
значение для поля отличного от первого
Подробности см вложение
Как измененно :
Алгоритм замещает значения.
M_MNPLAN
Краткое описание :
алг. 37 Добавить значение настройки выбора поля "не
заполнять"Описание :
по 37-му системному алгоритму "Заполение цен"Что измененно :
алг. 37 Добавить значение настройки выбора поля "не заполнять"
На вкладке "Документ" при выборе значения "Поле" в список выбора добавить
"не заполнять".
На данный момент если значение поля не выбрано - заполняется поле по
умолчанию шаблона документа "Плановое количество", то есть происходит затирание
ценой планового количества.
Как измененно :
Добавлена настройка выбора поля для цены "не заполнять".
Реализована поддержка в функциональности алгоритма.
M_MNPLAN
Краткое описание :
Не работает фильтр в закладке Роли и датыОписание :
по 35-му системному алгоритму "Агрегирование количеств по позициям"Что измененно :
Не работает фильтр в закладке Роли и даты .
В группе кнопок "При поиске позиций в
документе-источнике проводить сравнение по" устанавливаю
Check-button "дате начала фактической " = True и значения
для нее. Однако при расчете фильтрации позиций по дате не
происходит.
Как измененно :
Фильтр работает
M_MNPLAN
Краткое описание :
алгоритмы и корпоративные планыОписание :
Календарный планЧто измененно :
алгоритмы и корпоративные планы
Как измененно :
Теперь ошибка не возникает.
M_MNPLAN
Краткое описание :
Непонятное сообщение при прерывании расчетаОписание :
по 103-му алг "Формирование журнала резервирования по плановым документам"Что измененно :
Непонятное сообщение при прерывании расчета
В процессе расчета появляется сообщение "Ошибка создания записи журнала!
Не определен Производственный центр для Энергоцех. Прервать ?" . Отвечаю "Да",
после чего странное сообщение - "Не определен ListOper при подтягивании"
Как измененно :
Доработан алгоритм № 103 - 3. При расчете убрано сообщение"Не
определен ListOper при подтягивании"
M_MNPLAN
Краткое описание :
Не убрано отладочное сообщениеОписание :
по 103-му алг "Формирование журнала резервирования по плановым документам"Что измененно :
При отработке алгоритма сообщение о том, что не задан
производственный центр. На вопрос Прервать? отвечаю Нет, после чего окно
отладки - "Ошибка в функции Limit.GetOborPlExt"
Как измененно :
Доработан алгоритм №103-3. При расчете убрано отладочное
сообщение "Ошибка в функции Limit.GetOborPlExt"
M_MNPLAN
Краткое описание :
Требует расширенной лицензии на Управление производственной
логистикой : странное поведение системы лицензированияОписание :
ЗаявкиЧто измененно :
Требует расширенной лицензии на Управление производственной
логистикой : странное поведение системы лицензирования.
Заявка вызывается из модуля Планирование производства (ПП) и/или из
Входящих/Изходящих ПЗ.
Пример: Пользователь вошел в ПП открыл Заявку, Перешел в УПЛ, что-то посмотрел,
вернулся в Заявку,
вызвал из Заявки алгоритм расчета трудовых потребностей, пытается войти в
ПотрТр.
Появляется сообщение об отсутствии лицензии (см. вложение).
Клиент утверждает, что сообщение возникает даже если предварительно закрыть все
интерфейсы УПЛ.
Проверить нет возможности: у нас нет лицензий с такими ограничениями.
Как измененно :
Доработано: из модуля "Управление производственной логистикой"
редактировать документ "Потребность в трудовых ресурсах" можно только при
наличии свободной лицензии "Планирования производства", либо расширенной
лицензии "Управление производственной логистикой"
M_MNPLAN
Краткое описание :
При выполнении алгоритма (вкладка Спецификации и позиции)
общая пометка (+,-) не учитывает прадварительно наложенный фильтр по Alt+BОписание :
Системный алгоритм 203Что измененно :
При пометке всех позиций в интерфейсе выбора с помощью клавиш
<+>/<-> оказывается помеченной спецификация, которая не попадает под
ограничения наложенного на данный список фильтра. В данной ситуации необходимо
ограничить пометку отображаемыми позициями в списке.
Как измененно :
Ошибка исправлена. При наложенном фильтре пометка всех позиций
с помощью клавиши <+> не распространяется на позиции, которые не попадают по
действие ограничений данного фильтра.
M_MNPLAN
Краткое описание :
Некорректная последовательность данных, после Репликации.Описание :
Шаблоны плановЧто измененно :
После Corpo-обмена, данные внедряются в обратном порядке.
Например создаем в плане снабжения по порядку Фильтр1, а потом Фильтр2. После
Corpo, данные внедрятся в базу приемник с последовательностью - Фильтр2,
Фильтр1, т.е. в обратном порядке (данная ситуация не так критична).
Большие сложности вызывает следующая ситуация:
Модуль МТО => Настройка => Шаблоны планов => "по F7 cоздаем шаблон плана" =>
Параметры авт. Формирования => Доп. алгоритмы. На данной вкладке указываем
несколько нужных алгоритмов, которые будут автоматически запускаться (выбираем
алгоритмы в строго определенном порядке, т.к. иначе алгоритмы просто не будут
верно отрабатывать). Так вот после репликации, данные внедряются так же в
обратном порядке. У клиента 12 филиалов и в каждый филиал приходится заходить и
вручную исправлять неправильный порядок данных.
Подобные ошибки внедрения замечали в разных местах. Например в Шаблоне плана на
вкладке Представления создавали несколько представлений и после Корпо эти
представления так же отображались в базах приемниках в неправильном порядке.
Как измененно :
1)Сортировка для отображаемого списка представлений и списка
алгоритмов не может быть реализована на текущем словаре Галактики 810.
Рекомендуется перейти на Галактику 910.
2)Для списка алгоритмов(окно редактирования шаблона документов планирования
производства закладка "Параметры авт.формирования\Доп.Алгоритмы") добавлено
поле с порядковым номером. При запуске на выполнение данного списка алгоритмы
будут обрабатываться в порядке возрастания этого значения.
При выводе на экран интерфейса редактирования шаблона для позиций из данного
списка с нулевым значением порядкового номера не нулевое значение будет
сформировано программой автоматом. Перед конвертацией рекомендуется открыть
интерфейс редактирования шаблона документов планирования производства(при этом
программа должна сформировать нумерацию для списка алгоритмов если она еще не
сформирована) и убедиться что данная нумерация соответствует порядку выполнения
алгоритмов.
M_MNPLAN
Краткое описание :
Алгоритм 170. Формирование пустой потребности на сменуОписание :
Не знаю, какая именно часть производственого контура, научитеЧто измененно :
Обнаружили ошибку в работе 170 алгоритма. Если по сменному
заданию, по которому еще не было выпуска и нет документов в исходящих
сформировать документы по выпуску с помощью 138 алгоритма в режиме формирование
документов по ССЗ то в некоторых случаях формируется Пустая Потребность в
материалах на смену, с заполненным заголовком и не связанная со сменным
заданием. После тестирования выяснили, что такое происходит когда по указанным
полуфабрикатам нет сырья, кроме полуфабрикатов предыдущего уровня. Просьба
исправить данную ошибку.
Как измененно :
Теперь не создается пустой документ.
M_MNPLAN
Краткое описание :
Алгоритм 138. В режиме корректировки неверно выбираются
нормы из МКОписание :
по 138-му системному алгоритму "Формирование сопроводительных документов модуля УПЛ "Что измененно :
Алгоритм 138. В режиме корректировки неверно выбираются нормы
из МК: берутся нормы на текущую дату, а не на дату начала ССЗ.
Как измененно :
Доработано. Алгоритм 138. В режиме корректировки нормы из МК
берутся на дату начала ССЗ (Потребность в трудовых ресурсах)
M_MNPLAN
Краткое описание :
Берутся не текущие, а сальдовые остаткиОписание :
№7001 "Текущее наличие на складе для заданной МЦ"Что измененно :
Если в настройке алгоритма указано "Учитывать складские
остатки" или "Учитывать производственные остатки", то при расчете берутся не
текущие, а сальдовые остатки
Как измененно :
Сделано
M_MNPLAN
Краткое описание :
Планирование производства. Алгоритм 79. Расчет цены.Описание :
по 79 -му системному алгоритму "Алгоритм формирования складских ордеров..Что измененно :
В режиме формирования ордеров "По готовой продукции" не
производится расчет цены в соответствии с настройкой.
Как измененно :
Цена рассчитывается
M_MNPLAN
Краткое описание :
Номер смены для ССЗ не соответствует графику ПЦОписание :
по 117-му системному алгоритму " Состояние производства и формирование ССЗ"Что измененно :
При включении в ССЗ нескольких позиций, и ошибках при создании
операций ЖР выдается сообщение для каждой позиции.
Как измененно :
Теперь сообщение об ошибке выдается один раз, после чего
выполнение прекращается.
M_MNPLAN
Краткое описание :
HELP. Не подключен топик к интерфейсуОписание :
Оперативные планы заказовЧто измененно :
HELP. Не подключен топик к интерфейсу, см. вложение.
Как измененно :
Подключен топик "Оперативный план заказов"
M_MNPLAN
Краткое описание :
Управление производством. Ал.57 Настройка выгрузки в новый
документОписание :
по 57-му системному алгоритму "Работа с таблицами расчета количеств "Что измененно :
В окне настроек выгрузки данных в производственные спецификации
поля для ввода наименования создаваемых ПС открываются не сразу после установки
режима "Документ-приемник" - "Новый документ", а только после того как
пользователь перейдет с поля "Документ-приемник" на другое поле окна настроек.
Как измененно :
Исправлено
M_MNPLAN
Краткое описание :
Алгоритм 57. Не заполнять аналитику "Потребитель"Описание :
по 57-му системному алгоритму "Работа с таблицами расчета количеств "Что измененно :
Алгоритм 57. При формировании производственных спецификаций
значение для поля "Изготовитель" шапки документа выгружается также в поле
"Потребитель" спецификации данного документа.
Как измененно :
Исправлено
M_MNPLAN
Краткое описание :
8.10.УПЛ.Алгоритм 57.Настройка "Шаблон для нового
документа" не доступна.Описание :
по 57-му системному алгоритму "Работа с таблицами расчета количеств "Что измененно :
При установке значения для настройки "Входные/выходные данные
\Приемники данных\Приемник по данных сырью\Документ-приемник" - "Новый
документ" настройка алгоритма "Шаблон для нового документа" становится
доступной после сохранения параметров.
Как измененно :
Исправлено
M_MNPLAN
Краткое описание :
8.10.УПЛ.Ал57. Выгрузка данных по сырью.Описание :
по 57-му системному алгоритму "Работа с таблицами расчета количеств "Что измененно :
В процессе обработки ПС с помощью ТРК, при выгрузке в
документ-владелец данных по готовой продукции происходит также выгрузка данных
по сырью. Необходимо исправить ошибку чтобы при запуске функции "Сохранить
данные"\"По готовой продукции" выгружались данные только по готовой продукции,
а для функции "Сохранить данные"\"По сырью" выгружались данные соответственно
только по сырью.
Как измененно :
Ошибка исправлена.