Имя: Пароль:
1C
1С v8
Вынос мозга - оперативное планирование в 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) Русского языка не хватает! Заимствования пошли...
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn