17.07.2008, 17:59 | #21 |
Участник
|
Второй цикл разве идёт по ВСЕМ складским аналитикам?
|
|
17.07.2008, 18:10 | #22 |
Участник
|
Цитата:
Сообщение от mazzy
Bega, немножко вмешаюсь как администратор.
Коммерческие предложения разрешены только в разделе рынок, поэтому не провоцируйте людей нарушать правила, запрашивая здесь коммерческие предложения. Создайте ветку поиска коммерческих партнеров в разделе http://axforum.info/forums/forumdisplay.php?f=62 Если хотите сделайте ссылку на эту ветку. Этот раздел назвается "DAX: Функционал". Здесь обсуждаются вопросы функционала и возможные способы решения задач. Отмечу особо - некоммерческие вопросы и некоммерческие способы решения. |
|
17.07.2008, 18:21 | #23 |
Участник
|
Мы уже сделали макет, который нам планирует переносы и представляем настройки и общую логику, поэтому обсуждать абстрактно все возможные настройки не имеет смысла, да и на форуме это все уже неоднократно обсуждалось.
|
|
17.07.2008, 18:38 | #24 |
Аманд
|
Цитата:
Мы уже сделали макет
|
|
17.07.2008, 18:57 | #25 |
Участник
|
Первое сообщение.
Цитата:
Цитата:
Или вы таким замысловатым образом продавать свое пытаетесь? |
|
18.07.2008, 09:43 | #26 |
Участник
|
|
|
18.07.2008, 12:03 | #27 |
Участник
|
Вот.
Попытался по проще, серовно сложно получилось, но понять можно. Рассмотрим простейший случай в системе запасы нулевые. И 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 надо всегда подменять на склад заказа и соответственно количество тоже подменять нужно, а остальное как есть оставить. Ну это очень упрощено. Я только стержень объяснил. Последний раз редактировалось miklenew; 18.07.2008 в 12:42. |
|
|
За это сообщение автора поблагодарили: Wamr (2), Bega (1). |
18.07.2008, 16:57 | #28 |
Участник
|
Да, получается, что внутри метода covCreatePlannedOrder должен быть цикл, который создает несколько планируемых переносов.
|
|
18.07.2008, 19:55 | #29 |
Участник
|
Цитата:
Ввёл это слово(гашение) - потому что наиболее полно отражает то что внутри происходит. Хотя может кто лучше предложит. Что-то возникает, гасим, снова что-то возникает, снова гасим и т.д. Поэтому циклами я бы не стал делать. Это задача очень интересна в плане ООП. Вы всё равно будете наследник создавать от ReqCalcScheduleItemTable, а следовательно у вас появиться очень сильный козырь, можно почти всё подменять. Скорее всего вам прийдёться вводить несколько дополнительный map-ов в этом наследнике, для хранения промежуточных результатов. Вот подменой в нужных моментах вы сможете получить то что нужно. А все циклы как шли пусть так и идут. А вообще мне кажется, что решив эту задачу вы должны получить из этого кода в качестве дополнительного приза ещё разные вкусняшки. Самое сложное в этой задачи. Что расчёт сам по себе долго идёт. Даже если максимально облегчить компанию и настройки. Я когда то делал задачу по гашению заказа и журнала проводка. Т.е. в шапке заказа и журнале проводка была кнопка покрыть. Она запускала сводное планирование по тем номенклатурам, которые входят в эти документы. А проводки покрывала только те которые создавали эти документы. Но всё равно, если не подводит память, секунд 20 занимало. Да, кстати, если со временем терпит, могу через неделю(отпуск начнётся) заняться этой задачей. Дня три думаю займёт. 5 000 р\за день. После контроля качества пришлю реквизиты карточки для перевода. Если не терпит, пишите в ветке, можно и совместно через форум решать, я думаю это задача вызвет интерес не только у вас. Интересно же. Последний раз редактировалось miklenew; 18.07.2008 в 20:32. |
|
18.07.2008, 21:04 | #30 |
Участник
|
|
|
19.07.2008, 07:52 | #31 |
Moderator
|
А мне вот интересно - а как вы будете считать предполагаемые остатки на некотором складе на некоторую дату из будущего ? Представим себе что у вас есть популярный склад пополнения. Сейчас там 500 штук материалов. При планировании n потребностей переносами с этого склада напокрывали. Соответственно при планировании n+1 потребности, необходимо из текущего остатка вычесть сумму покрытых со склада потребностей. То есть - нужно написать что-то типа функции InventOnHand, только учитывающей не текущие складские остатки, а складские остатки на некую предполагаемую дату в будущем (с учетом покрытия из текущего плана). Причем в первом приближении, эта функция должна вообще работать не с данными из inventSum/InventTrans, а только с данными из reqTrans (поскольку туда при планировании и складской остаток и все предполагаемые движения попадают).
Вам явно понадобится подобная информация, чтобы оценить - с каких складов пополнять... В общем - я верю что можно такую задачу решить, но у меня лично в свое время руки так и не дошли. Так что не пишите в личку, пишите в форум - мне тоже интересно Последний раз редактировалось fed; 19.07.2008 в 07:55. |
|
19.07.2008, 17:06 | #32 |
Участник
|
fed, в определении остатка на дату строки документов по предложениям не участвуют.
А это своего рода такие же предложения. |
|
21.07.2008, 11:40 | #33 |
Аманд
|
Цитата:
Я когда то делал задачу по гашению заказа и журнала проводка.
Т.е. в шапке заказа и журнале проводка была кнопка покрыть. Она запускала сводное планирование по тем номенклатурам, которые входят в эти документы. А проводки покрывала только те которые создавали эти документы Последний раз редактировалось Vals; 21.07.2008 в 12:02. |
|
21.07.2008, 11:53 | #34 |
Пенсионер
|
Интересно, а нельзя ли эту задачу решить организационно, например все склады к одному, а территориальную разрозненность осуществить через зоны одного склада (ячейки)?
__________________
Законы природы еще никто не отменял! А еще у меня растет 2 внучки!!! Кому интересно подробности тут: http://www.baby-shine.com/ |
|
21.07.2008, 12:47 | #35 |
Участник
|
Цитата:
Но, не я заказчик модификации. Мне сказали я сделал. Там всего то два метода в наследнике перекрыл. Плюс дополнительные проверки и удаление старых документов сделал, если уже утверждено. Оказывается зря эти два метода перекрывал. Нужно было лишь подсунуть нужные данные. А вообще спасибо. |
|