Пополнение с нескольких складов

[Михаил Андреев]

Цитата:

Сообщение от Bega

А в чем? Я смотрю метод ReqCalc::covCalc - сначала цикл по номенклатурам, потом цикл по складским аналитикам, то есть по местам, где необходимо пополнение. Отдельно для каждой комбинации аналитик запускается расчет.

Второй цикл разве идёт по ВСЕМ складским аналитикам?

[Bega]

Цитата:

Сообщение от mazzy

Bega, немножко вмешаюсь как администратор.
Коммерческие предложения разрешены только в разделе рынок, поэтому не провоцируйте людей нарушать правила, запрашивая здесь коммерческие предложения. Создайте ветку поиска коммерческих партнеров в разделе http://axforum.info/forums/forumdisplay.php?f=62
Если хотите сделайте ссылку на эту ветку.

Этот раздел назвается "DAX: Функционал".
Здесь обсуждаются вопросы функционала и возможные способы решения задач. Отмечу особо - некоммерческие вопросы и некоммерческие способы решения.

Хорошо.

[Bega]

Цитата:

Сообщение от Михаил Андреев

Второй цикл разве идёт по ВСЕМ складским аналитикам?

Цитата:

Сообщение от Vals

В этом. Если галку снять, то система не учитывает аналитику при планировании. И покрытие считается Итого.
Из написанного, очевидность данного параметра не следует.

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

[Vals]

Цитата:

Мы уже сделали макет

А почему об этом не сказать в первом сообщении?

[mazzy]

Первое сообщение.

Цитата:

Сообщение от Bega

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

Последнее сообщение.

Цитата:

Сообщение от Bega

Мы уже сделали макет, который нам планирует переносы и представляем настройки и общую логику.

Непонятно в чем вопрос был.
Или вы таким замысловатым образом продавать свое пытаетесь?

[Bega]

Цитата:

Сообщение от mazzy

Непонятно в чем вопрос был.

Макет сделан на стандартном функционале. Кроме этого нам нужно пополнение с нескольких складов, пытаюсь выяснить, может его кто-то уже реализовал.

[miklenew]

Вот.
Попытался по проще, серовно сложно получилось, но понять можно.
Рассмотрим простейший случай в системе запасы нулевые.
И reqItemTable не заполнен. Он является всего лишь дополнительным поставщиком потребностей.
Создаём заказ. Строку заказа. Выбираем номенклатуру с настроенным складом по заказу первого уровня. Т.е. Склад1_1 - > Основной.
В строке заказа у нас появляется склад1_1.
Запускаем сводное планирование.
1) Класс ReqCalc
метод insertInventTrans – получаем из запроса inventTrans, который нужно гасить.
2) Класс ReqCalc
метод newQueryInventTransReceipt – формирование запроса для прихода по InventTrans
метод newQueryInventTransIssue – формирование запроса для расхода по InventTrans
Наш случай покрыть расходную проводку.
3) Класс ReqCalc метод initTransFromInventTrans
Берём расходную проводку InventTrans, которую нужно гасить и создаём из неё reqTrans.
Т.е. создаём ReqTrans тип заказ Склад1_1
4) Класс ReqCalc метод covCreatePlannedOrder
Теперь берём нашу reqTrans.
И создаём из неё заготовку для будущего документа ReqPo. (журнал перенос)
Т.е. создаём ReqPo для переноса на Склад1_1.
ReqTrans-ов у нас пока для него нет.
5) Таблица ReqTrans метод метод initFromReqPo
Создаём приходную проводку для ReqPo.
Т.е. создаём ReqTrans для переноса на Склад1_1
6) Таблица ReqTrans метод createTransferDemand.
Создаём расходную проводку для ReqPo.
Т.е. создаём ReqTrans для переноса со склада Основной.
7) Класс ReqCalc метод covCreatePlannedOrder
Теперь берём наш reqTrans созданный в (6) и гасим его приходным документом (в нашем случае закупкой).
Т.е. создаём ReqPo для закупки на склад Основной
8) Таблица ReqTrans метод метод insertFromReqPo
Создаём приходную проводку для закупки.
Т.е. создаём ReqTrans для закупки на склад Основной.
Таким образом у нас создалось в ReqTrans 4 записи
1) Историческая – от куда всё началось(заказ)
2) Будущая приходная проводка для журнала перенос
3) Будущая расходная проводка для журнала перенос
4) Будущая приходная проводка для закупки
А также создались две записи в ReqPo (заготовки для будущих документов)
1) Журнал перенос
2) Закупка
Если бы у нас был склад второго уровня для строки заказа, то было бы
2 журнала переноса и 1 закупка.
Т.е. получается для первого уровня.
Склад заказа – склад основной.
Для второго
склад заказа – склад уровнем ниже – склад основной
На концах этих цепочек потребность заказа и потребность закупки.
А чёрточки это переносы.
Схематично было бы лучше, но думаю понятно.
Человек же хочет что была не цепочка, как можно сделать в стандарте
Склад1 (склад заказа) – склад3 – склад4 - склад2(основной)
А было три цепоки, веер
склад1 – склад3
склад1 – склад4
склад1 – склад 2 (в самом конце, если ещё осталось что-нибудь)
Т.е.
2 переноса и одна закупка
Рассмотрим для наглядности большую цепочку
1-2-3-4-5-6-7-8.(Склады)
Как стандарт создаст ReqTrans-ы (16 шт)
1 – заказ
1-2 переносы
2-3 переносы
3-4 переносы
4-5 переносы
5-6 переносы
6-7 переносы
7-8 переносы
8 - закупка
Как человек хочет (те же 16, но другие)
1 – заказ
1-2 переносы
1-3 переносы
1-4 переносы
1-5 переносы
1-6 переносы
1-7 переносы
1-8 – закупка
8 - закупка
Т.е. первый ReqTrans надо всегда подменять на склад заказа и соответственно количество тоже подменять нужно, а остальное как есть оставить.
Ну это очень упрощено.
Я только стержень объяснил.

[Bega]

Да, получается, что внутри метода covCreatePlannedOrder должен быть цикл, который создает несколько планируемых переносов.

[miklenew]

Цитата:

Сообщение от Bega

Да, получается, что внутри метода covCreatePlannedOrder должен быть цикл, который создает несколько планируемых переносов.

Нет, циклами тут не получиться, тут вся суть в том что идёт цепочка "гашения".
Ввёл это слово(гашение) - потому что наиболее полно отражает то что внутри происходит. Хотя может кто лучше предложит.
Что-то возникает, гасим, снова что-то возникает, снова гасим и т.д.
Поэтому циклами я бы не стал делать.
Это задача очень интересна в плане ООП.
Вы всё равно будете наследник создавать от ReqCalcScheduleItemTable, а следовательно у вас появиться очень сильный козырь, можно почти всё подменять.
Скорее всего вам прийдёться вводить несколько дополнительный map-ов в этом наследнике, для хранения промежуточных результатов.
Вот подменой в нужных моментах вы сможете получить то что нужно.
А все циклы как шли пусть так и идут.
А вообще мне кажется, что решив эту задачу вы должны получить из этого кода в качестве дополнительного приза ещё разные вкусняшки.
Самое сложное в этой задачи. Что расчёт сам по себе долго идёт. Даже если максимально облегчить компанию и настройки.
Я когда то делал задачу по гашению заказа и журнала проводка.
Т.е. в шапке заказа и журнале проводка была кнопка покрыть.
Она запускала сводное планирование по тем номенклатурам, которые входят в эти документы. А проводки покрывала только те которые создавали эти документы.
Но всё равно, если не подводит память, секунд 20 занимало.
Да, кстати, если со временем терпит, могу через неделю(отпуск начнётся) заняться этой задачей. Дня три думаю займёт. 5 000 р\за день. После контроля качества пришлю реквизиты карточки для перевода.
Если не терпит, пишите в ветке, можно и совместно через форум решать, я думаю это задача вызвет интерес не только у вас.
Интересно же.

[Bega]

Цитата:

Сообщение от miklenew

если со временем терпит

Пока терпит, об остальном - в личку.

[fed]

А мне вот интересно - а как вы будете считать предполагаемые остатки на некотором складе на некоторую дату из будущего ? Представим себе что у вас есть популярный склад пополнения. Сейчас там 500 штук материалов. При планировании n потребностей переносами с этого склада напокрывали. Соответственно при планировании n+1 потребности, необходимо из текущего остатка вычесть сумму покрытых со склада потребностей. То есть - нужно написать что-то типа функции InventOnHand, только учитывающей не текущие складские остатки, а складские остатки на некую предполагаемую дату в будущем (с учетом покрытия из текущего плана). Причем в первом приближении, эта функция должна вообще работать не с данными из inventSum/InventTrans, а только с данными из reqTrans (поскольку туда при планировании и складской остаток и все предполагаемые движения попадают).
Вам явно понадобится подобная информация, чтобы оценить - с каких складов пополнять...
В общем - я верю что можно такую задачу решить, но у меня лично в свое время руки так и не дошли.
Так что не пишите в личку, пишите в форум - мне тоже интересно

[miklenew]

fed, в определении остатка на дату строки документов по предложениям не участвуют.
А это своего рода такие же предложения.

[Vals]

Цитата:

Я когда то делал задачу по гашению заказа и журнала проводка.
Т.е. в шапке заказа и журнале проводка была кнопка покрыть.
Она запускала сводное планирование по тем номенклатурам, которые входят в эти документы. А проводки покрывала только те которые создавали эти документы

Если по строкам нажать Запросы/Развёртывание (Чистые потребности), затем Обработка (Обновление - Сводное планирование), то получим искомую функцию.

[blokva]

Интересно, а нельзя ли эту задачу решить организационно, например все склады к одному, а территориальную разрозненность осуществить через зоны одного склада (ячейки)?

[miklenew]

Цитата:

Сообщение от Vals

Если по строкам нажать Запросы/Развёртывание (Чистые потребности), затем Обработка (Обновление - Сводное планирование), то получим искомую функцию.

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