|
Вынос мозга - оперативное планирование в 1С | ☑ | ||
---|---|---|---|---|
0
jsmith82
28.10.11
✎
14:06
|
Вазюкаюсь с темой уже несколько дней, не могу понять, то ли ума не хватает, то ли разума.
Тема такая. Необходимо оперативное планирование движения ресурсов внутри компании в разрезе КОМПАНИИ ЛОКАЦИИ МЕСТА ХРАНЕНИЯ в заказе покупателя можно указать локацию и место хранения, а можно и не указывать, можно сделать это потом можно запланировать на основании одного заказа поступление на две локации, а по каждой локации ещё на два склада фактически же может получиться вообще по-другому задумок пока две 1. заказ шлёпает данные в плановый регистр по компании 2. план по локации хранятся в регистре сведений. там две колонки (запланировано по заказу и запланировано в локацию) 3. план по складу хранится в регистре сведений по складу. там две колонки (запланировано по локации и запланировано на склад) если заказ корректируется, то летят ко всем джексонам первые колонки в регистрах сведений и надо вновь сверять данные лучшего решения пока не нашёл хотел в одном заказе это делать, но пока не соображу как спасибо за советы и за сарказм заранее |
|||
1
Fragster
гуру
28.10.11
✎
14:07
|
и правда вынос мозга. особенно слово ЛОКАЦИИ
|
|||
2
and2
28.10.11
✎
14:08
|
лАкации
|
|||
3
Fish
28.10.11
✎
14:10
|
(1) Видимо имелось в виду, что у одной компании может быть несколько локаций, а внутри одной локации - несколько мест хранения?
|
|||
4
jsmith82
28.10.11
✎
14:10
|
(3) да. локация это город якобы так называется. а в городе несколько складов
|
|||
5
fgaabbb
28.10.11
✎
14:11
|
хе... (1) у нас это РАЗМЕЩЕНИЯ, ОФСКЛАДЫ, ПОДСКЛАДЫ, СКЛАДЫ... уф... геморрой.
|
|||
6
BoCh
28.10.11
✎
14:11
|
(0) Если внутри компании несколько локаций, а внутри локации несколько мест хранения, тогда достаточно указать только место хранения.
|
|||
7
jsmith82
28.10.11
✎
14:11
|
в таб. части заказа указывать нельзя. это условие
решение в (0) не правильно, сам вижу |
|||
8
BoCh
28.10.11
✎
14:11
|
+ (6) или локацию.
|
|||
9
jsmith82
28.10.11
✎
14:12
|
(6) иногда неизвестен склад, только локация
|
|||
10
jsmith82
28.10.11
✎
14:13
|
(6) (8) согласен. можно остановить планирование на локации
но иногда нужно и по складам то ли жёстко вырубить склады из планирования, но проблема остаётся |
|||
11
Fish
28.10.11
✎
14:13
|
А одна компания может быть в нескольких локациях? :))
|
|||
12
tdm
28.10.11
✎
14:13
|
(0)
>>в заказе покупателя можно указать локацию и место хранения, а >>можно и не указывать, можно сделать это потом >>можно запланировать на основании одного заказа поступление на две >>локации, а по каждой локации ещё на два склада >>фактически же может получиться вообще по-другому ИМХО пока "фактически же может получиться вообще по-другому" чтот запланировать и свести с фактом сложно; над как-то ограничить - а то прям "кручу верчу запутать хочу" |
|||
13
Fish
28.10.11
✎
14:14
|
+11 Точнее в одной локации несколько компаний :))
|
|||
14
BoCh
28.10.11
✎
14:14
|
(10) Так можно же или локацию или склад указать.
|
|||
15
jsmith82
28.10.11
✎
14:15
|
(13) нет. обычная иерархия
|
|||
16
jsmith82
28.10.11
✎
14:18
|
вся проблема из-за трёх уровней планирование
Логист компании решает куда отправить товары. Он видит остатки только по локации Логист локации видит остатки по локации и складам. Он решает на какие склады отправить товары. |
|||
17
Fish
28.10.11
✎
14:19
|
Тогда все было бы просто, если бы не фраза в "0": "фактически же может получиться вообще по-другому". Тук ИМХО только корректировки заказа отдельным документом делать.
|
|||
18
Fish
28.10.11
✎
14:19
|
* Тук -> Тут :)
|
|||
19
jsmith82
28.10.11
✎
14:19
|
(17) Думаю, конечно, о супер-форме заказа с синхронизирующимися таблицам, пока что просто визуально не вижу этого
|
|||
20
jsmith82
28.10.11
✎
14:21
|
В типовой конфе 1С есть только реквизиты ТЧ и там корректировка происходит в заказе
Но условие таково, что таб. часть не должна расплываться. Ключ таб. части = номенклатура + цена. |
|||
21
Fish
28.10.11
✎
14:24
|
(20) Вообще-то в типовых сам заказ не корректируется (см. документы): КорректировкаЗаказаПокупателя, КорректировкаЗаказаПоставщику и т.п.
|
|||
22
jsmith82
28.10.11
✎
14:25
|
(21) ну это да, я имею в виду что корректируется сам ЗАКАЗ как документ, а не его отдельные подчинённые документы или связанные регистры сведений
|
|||
23
jsmith82
28.10.11
✎
14:26
|
тема такая. логист компании видит потребности локаций. фигась, фигась, фуры поехали в два города. чувачки в городах видят поступления. фигась, фигась, замутили плановые движухи по складам
может, просто так нельзя работать? |
|||
24
Fish
28.10.11
✎
14:27
|
(22) Это как? Есть документ Заказ, а есть документ Корректировка заказа. Док.Корректировка просто изменяет регистры как нужно, не меняя сам заказ. В чем проблема? Посмотри внимательно типовую УТ, например. Там система заказов и резервов довольно мощная.
|
|||
25
jsmith82
28.10.11
✎
14:27
|
(24) я типовую знаю как облупленную, просто не так выразился
|
|||
26
tdm
28.10.11
✎
14:27
|
(23) уменьшить кол-во степеней свободы нельзя ?
например справочник складов - элементы склады а локации это группы этоже справочника или чтот подобное |
|||
27
jsmith82
28.10.11
✎
14:28
|
(26) вышка пошла )
|
|||
28
jsmith82
28.10.11
✎
14:29
|
(26) с иерархией боюсь связываться. думаю, что модель должна быть канонична и проста
|
|||
29
Fish
28.10.11
✎
14:29
|
(26) Проще подчиненными справочниками - Локации подчинен организации, а места хранения подчинены локации. И тогда все просто :)
|
|||
30
Fish
28.10.11
✎
14:31
|
(25) Если бы типовую знал, как облупленную, то таких вопросов, как в (0), не возникало бы :))) Еще раз повторю - в УТ все это давно реализовано, надо просто уметь это использовать :))
|
|||
31
jsmith82
28.10.11
✎
14:33
|
(30) я повторюсь, типовую знаю как облупленную, вплоть до участков кода
я просто неверно сформулировал мысль подчёркиваю. в УТ хрень делается посредством редактирования таб. частей (реквизит склад например или дата отгрузки в УТ 11) в этой задаче таб. часть использовать нельзя |
|||
32
jsmith82
28.10.11
✎
14:34
|
видимо, просто условия задачи не соответстсвуют реальности
|
|||
33
Allexe
28.10.11
✎
14:34
|
(28) Можно без иерархии, вместо локация=группа, сделать отдельный склад с названием склад-локация, а потом с этого склада раскидывать на склады внутри локации
|
|||
34
tdm
28.10.11
✎
14:35
|
(28) на этапе построения простым переносом элементов можно перестраивать систему) пока чтото не нарисуется... упрощайте тогда на этапе постановки задачи
(31) почему нельзя таб часть использовать ? |
|||
35
jsmith82
28.10.11
✎
14:35
|
(34) таб. часть использовать нельзя, чтобы она не расплывалась по локациям и складам
как вариант был способ просмотра свёрнутой таб. части, но это неубедительно |
|||
36
jsmith82
28.10.11
✎
14:38
|
пока что ясно вижу только одно
планирование работает на одном уровне. сделал план в локацию, оприходовал факт если факт другой, редактируешь план, чтобы факт всегда вводился на основании и не редактировался ручками в УТ 11 есть такая фича, что нельзя увеличивать количества, если реализация введена на основании заказа |
|||
37
Fish
28.10.11
✎
14:41
|
(31) В УТ все делается не так :))) И заказы учитываются не в регистрах сведений, а в регистрах накопления. Знатоки, мля :))
|
|||
38
Fish
28.10.11
✎
14:46
|
+(37) И табличные части никуда не "расплываются" :))) А вместо локаций можно указать другие организации и у них указать головную организацию - и все заработает. Есть такое понятие - "холдинги", так вот, в типовых это давно уже реализовано, и не надо изобретать велосипед. Тем более, кто мешает взять из типовой идею учета заказов, а документы нарисовать самому?
|
|||
39
jsmith82
28.10.11
✎
14:49
|
(37) слуш. чо к словам привязался. лучше скажи мне в лицо, что я лжец, чем издалека свой сарказм мутить
|
|||
40
Fish
28.10.11
✎
14:50
|
(36) "если факт другой, редактируешь план, чтобы факт всегда вводился на основании и не редактировался ручками" - жесть и полный бред :))))
План - это план, а факт - это ФАКТ, он потому и факт, что формируется из ФАКТИЧЕСКИ пришедшего/оприходованного товара, а не вводится на основании плана :))) |
|||
41
Fish
28.10.11
✎
14:52
|
(39) Я не говорю, что ты лжец, просто я никогда не делаю заявлений типа "типовую знаю как облупленную, вплоть до участков кода" :))) А именно с учетом заказов и резервов в УТ я довольно серьезно разбирался и дорабатывал его под свои нужды, поэтому представляю, о чем говорю, хотя не заявляю, что я "великий знаток складского учета" :)))
|
|||
42
jsmith82
28.10.11
✎
14:53
|
(40) мне опыт не позволяет продолжать с тобой беседу после того, как ты скрыто назвал меня лжецом, разве только цинизм и убеждённость в печальной гибели человечества
вот возьми хоть таб части. ты говоришь, они не расплываются. если я разбиваю строку на несколько складов, как это называется. может, я про одно, а ты про другое? |
|||
43
tdm
28.10.11
✎
14:54
|
(36) спасет только - "Мультииерархия" от Гений 1С - Решил писать РУМ - убийцу википедии, вопросов.ру и флудофорумов
|
|||
44
jsmith82
28.10.11
✎
14:55
|
говоря про план-факт я имею в виду не тупо план, а скорее распоряжение
когда один человек планирует, а другой исполняет в компании так и происходит. менеджер запланировал расход со склада, а складской работник отпустил, и он не может править расходный ордер |
|||
45
jsmith82
28.10.11
✎
14:55
|
в общем, ладно, вижу тема завязла
закрывайте |
|||
46
tdm
28.10.11
✎
15:01
|
(44) зачем тога регистры сведений и прочее ? либо оборотный регистр с соотв-ми измерениями, либо по документам запросом собирать данные - это же переодическая разовая операция
|
|||
47
jsmith82
28.10.11
✎
15:02
|
(46) да, что-то типа такого
|
|||
48
Bell
28.10.11
✎
15:18
|
(0) Русского языка не хватает! Заимствования пошли...
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |