Вазюкаюсь с темой уже несколько дней, не могу понять, то ли ума не хватает, то ли разума.
Тема такая. Необходимо оперативное планирование движения ресурсов внутри компании в разрезе
КОМПАНИИ
ЛОКАЦИИ
МЕСТА ХРАНЕНИЯ
в заказе покупателя можно указать локацию и место хранения, а можно и не указывать, можно сделать это потом
можно запланировать на основании одного заказа поступление на две локации, а по каждой локации ещё на два склада
фактически же может получиться вообще по-другому
задумок пока две
1. заказ шлёпает данные в плановый регистр по компании
2. план по локации хранятся в регистре сведений. там две колонки (запланировано по заказу и запланировано в локацию)
3. план по складу хранится в регистре сведений по складу. там две колонки (запланировано по локации и запланировано на склад)
если заказ корректируется, то летят ко всем джексонам первые колонки в регистрах сведений и надо вновь сверять данные
лучшего решения пока не нашёл
хотел в одном заказе это делать, но пока не соображу как
спасибо за советы и за сарказм заранее

и правда вынос мозга. особенно слово ЛОКАЦИИ

лАкации

(1) Видимо имелось в виду, что у одной компании может быть несколько локаций, а внутри одной локации - несколько мест хранения?

(3) да. локация это город якобы так называется. а в городе несколько складов

хе... (1) у нас это РАЗМЕЩЕНИЯ, ОФСКЛАДЫ, ПОДСКЛАДЫ, СКЛАДЫ... уф... геморрой.

(0) Если внутри компании несколько локаций, а внутри локации несколько мест хранения, тогда достаточно указать только место хранения.

в таб. части заказа указывать нельзя. это условие
решение в (0) не правильно, сам вижу

+ (6) или локацию.

(6) иногда неизвестен склад, только локация

(6) (8) согласен. можно остановить планирование на локации
но иногда нужно и по складам
то ли жёстко вырубить склады из планирования, но проблема остаётся

А одна компания может быть в нескольких локациях? :))

(0)
>>в заказе покупателя можно указать локацию и место хранения, а >>можно и не указывать, можно сделать это потом
>>можно запланировать на основании одного заказа поступление на две >>локации, а по каждой локации ещё на два склада
>>фактически же может получиться вообще по-другому

ИМХО пока "фактически же может получиться вообще по-другому" чтот запланировать и свести с фактом сложно; над как-то ограничить - а то прям "кручу верчу запутать хочу"

+11 Точнее в одной локации несколько компаний :))

(10) Так можно же или локацию или склад указать.

(13) нет. обычная иерархия

вся проблема из-за трёх уровней планирование
Логист компании решает куда отправить товары. Он видит остатки только по локации
Логист локации видит остатки по локации и складам. Он решает на какие склады отправить товары.

Тогда все было бы просто, если бы не фраза в "0": "фактически же может получиться вообще по-другому". Тук ИМХО только корректировки заказа отдельным документом делать.

* Тук -> Тут :)

(17) Думаю, конечно, о супер-форме заказа с синхронизирующимися таблицам, пока что просто визуально не вижу этого

В типовой конфе 1С есть только реквизиты ТЧ и там корректировка происходит в заказе
Но условие таково, что таб. часть не должна расплываться.
Ключ таб. части = номенклатура + цена.

(20) Вообще-то в типовых сам заказ не корректируется (см. документы): КорректировкаЗаказаПокупателя, КорректировкаЗаказаПоставщику и т.п.

(21) ну это да, я имею в виду что корректируется сам ЗАКАЗ как документ, а не его отдельные подчинённые документы или связанные регистры сведений

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

(22) Это как? Есть документ Заказ, а есть документ Корректировка заказа. Док.Корректировка просто изменяет регистры как нужно, не меняя сам заказ. В чем проблема? Посмотри внимательно типовую УТ, например. Там система заказов и резервов довольно мощная.

(24) я типовую знаю как облупленную, просто не так выразился

(23) уменьшить кол-во степеней свободы нельзя ?
например справочник складов - элементы склады а локации это группы этоже справочника или чтот подобное

(26) вышка пошла )

(26) с иерархией боюсь связываться. думаю, что модель должна быть канонична и проста

(26) Проще подчиненными справочниками - Локации подчинен организации, а места хранения подчинены локации. И тогда все просто :)

(25) Если бы типовую знал, как облупленную, то таких вопросов, как в (0), не возникало бы :))) Еще раз повторю - в УТ все это давно реализовано, надо просто уметь это использовать :))

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

видимо, просто условия задачи не соответстсвуют реальности

(28) Можно без иерархии, вместо локация=группа, сделать отдельный склад с названием склад-локация, а потом с этого склада раскидывать на склады внутри локации

(28) на этапе построения простым переносом элементов можно перестраивать систему) пока чтото не нарисуется... упрощайте тогда на этапе постановки задачи

(31) почему нельзя таб часть использовать ?

(34) таб. часть использовать нельзя, чтобы она не расплывалась по локациям и складам
как вариант был способ просмотра свёрнутой таб. части, но это неубедительно

пока что ясно вижу только одно
планирование работает на одном уровне. сделал план в локацию, оприходовал факт
если факт другой, редактируешь план, чтобы факт всегда вводился на основании и не редактировался ручками
в УТ 11 есть такая фича, что нельзя увеличивать количества, если реализация введена на основании заказа

(31) В УТ все делается не так :))) И заказы учитываются не в регистрах сведений, а в регистрах накопления. Знатоки, мля :))

+(37) И табличные части никуда не "расплываются" :))) А вместо локаций можно указать другие организации и у них указать головную организацию - и все заработает. Есть такое понятие - "холдинги", так вот, в типовых это давно уже реализовано, и не надо изобретать велосипед. Тем более, кто мешает взять из типовой идею учета заказов, а документы нарисовать самому?

(37) слуш. чо к словам привязался. лучше скажи мне в лицо, что я лжец, чем издалека свой сарказм мутить

(36) "если факт другой, редактируешь план, чтобы факт всегда вводился на основании и не редактировался ручками" - жесть и полный бред :))))
План - это план, а факт - это ФАКТ, он потому и факт, что формируется из ФАКТИЧЕСКИ пришедшего/оприходованного товара, а не вводится на основании плана :)))

(39) Я не говорю, что ты лжец, просто я никогда не делаю заявлений типа "типовую знаю как облупленную, вплоть до участков кода" :))) А именно с учетом заказов и резервов в УТ я довольно серьезно разбирался и дорабатывал его под свои нужды, поэтому представляю, о чем говорю, хотя не заявляю, что я "великий знаток складского учета" :)))

(40) мне опыт не позволяет продолжать с тобой беседу после того, как ты скрыто назвал меня лжецом, разве только цинизм и убеждённость в печальной гибели человечества
вот возьми хоть таб части. ты говоришь, они не расплываются. если я разбиваю строку на несколько складов, как это называется. может, я про одно, а ты про другое?

(36) спасет только - "Мультииерархия" от Гений 1С - Решил писать РУМ - убийцу википедии, вопросов.ру и флудофорумов

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

в общем, ладно, вижу тема завязла
закрывайте

(44) зачем тога регистры сведений и прочее ? либо оборотный регистр с соотв-ми измерениями, либо по документам  запросом собирать данные - это же переодическая разовая операция

(46) да, что-то типа такого

(0) Русского языка не хватает! Заимствования пошли...