|
Использование ИД для связки таблиц, что лучше использовать? | ☑ | ||
---|---|---|---|---|
0
spiller26
09.07.18
✎
09:18
|
Есть РС: Предложения (подчинен регистратору), ПроработкаПозиций (независимый), СтатусыПозиций (переодический).
Суть такова. 1. Заполняется РС "Предложения". Измерения: СтрокаИД (УИ, связка1) НоменклатураЗапрос (строка) Ресурсы: КоличествоЗапрошено (число) 2. На основании Предложений несколько пользователей, обрабатывают строки предложений. Запись ведется в РС "ПроработкаПозиций" Измерения: СтрокаИД (УИ, связка1) Номенклатура (ссылка) Ресурсы: КоличествоПредложено (число) Реквизиты: СтрокаИДПроработки (УИ, связка2) 3. При изменении информации по проработанной позиции отразить информацию в переодический РС "СтатусыПозиций" Измерения: СтрокаИДПроработки (УИ, связка2) Реквизиты: СтатусПозиции (Перечисление) Пока использую тип "Уникальный Идентификатор", но закрадываются сомнения правильности использования. |
3 7 |
||
1
spiller26
09.07.18
✎
09:50
|
Реально никто не использовал такую связку?
|
2 16 |
||
2
Nikoss
09.07.18
✎
09:55
|
(1) она не типична для 1С, где зачастую оперируют ссылочными типами данных
|
|||
3
Cool_Profi
09.07.18
✎
09:56
|
(0) А чем тебе не нравится ГУИД??
|
5 |
||
4
Nikoss
09.07.18
✎
09:56
|
интересно было бы для начала узнать, как в БД хранится этот самый тип - "Уникальный Идентификатор"
|
|||
5
spiller26
09.07.18
✎
10:03
|
(3) При переносе базы или разворачивании ГУИДы не полетят?
|
|||
6
Вафель
09.07.18
✎
10:05
|
в ут используется код строки - число, чтоб можно было глазами проверить
|
|||
7
mistеr
09.07.18
✎
10:07
|
(0) Предложения - справочник, Позиции - подчиненный ему справочник. Те же УИДы, только без онанизма.
Это же азбука 1С. |
8 |
||
8
spiller26
09.07.18
✎
10:15
|
(7) Предложения - документ, который связан с РС "Предложения"
Ситуация: Покупатель хочет заказать товар, не одну позицию, а хоть сто. Мы ему обрабатываем позиции, и предлагаем. Может быть ситуация, когда предполагаемая позиция может биться, в зависимости от многих факторов (поставщик, аналоги.) Покупатель хочет: "Резистор 0,5Ом" = 100 шт. Мы ему можем привести: "Резистор 0,5Ом партномер 5234" = 50 шт. "Резистор 0,5Ом партномер 3265" = 50 шт. |
9 11 |
||
9
ice777
09.07.18
✎
10:17
|
(8) бить морду таким надо.
разные партнамберы должны быть разными позициями в прайсе. |
10 |
||
10
spiller26
09.07.18
✎
10:22
|
(9) Они и будут разными позициями потом в Заказе, когда покупатель согласиться, а на этапе предложений это не нужно, это просто записки.
|
|||
11
mistеr
09.07.18
✎
10:25
|
(8) OK, сделай иерархию: первый уровень - позиции заказанные, второй - позиции предложенные.
|
12 26 |
||
12
spiller26
09.07.18
✎
10:27
|
(11) Это Документ.
|
13 |
||
13
mistеr
09.07.18
✎
10:32
|
(12) Предложение пусть будет документом, а позиции - справочник.
Заодно можно будет использовать проработанные позиции в других заказах. |
14 |
||
14
spiller26
09.07.18
✎
10:40
|
(13) не хочется плодить "чебурашек" если использовать справочник.
На этапе Предложения это просто строки, на этапе обработки только появляются справочники. |
15 |
||
15
mistеr
09.07.18
✎
10:44
|
(14) Не понял про чебурашек.
|
18 |
||
16
D3O
09.07.18
✎
10:57
|
(1) используем УИ. удобно. не надо заморачиваться как с ИД типа Число. там каждый раз надо опредлить максимальное для области уникальности значение. с УникальныйИдентификатор просто генеришь новый.
|
17 18 |
||
17
D3O
09.07.18
✎
10:59
|
(16) ну и небольшое неудобство таки есть - в запрос нельзя подсунуть параметр типа УникальныйИдентификатор )
платформа ругается, что не понимает такого типа ;) |
|||
18
spiller26
09.07.18
✎
11:05
|
19 |
|||
19
d4rkmesa
09.07.18
✎
11:22
|
21 |
|||
20
Buster007
09.07.18
✎
11:24
|
исходя из условий задачи УИД вообще не нужны
|
21 |
||
21
spiller26
09.07.18
✎
13:49
|
(19) Читал что во временной таблице нельзя использовать, но это не проверено пока.
(20) А как вы будете связывать таблицы то? Поступил запрос: 1. "Резистор 0,5Ом" (строка) 100 шт. назначен на обработку Квотре1 2. "Резистор 0,6Ом" (строка) 50 шт. назначен на обработку Квотер2 Квотер1 и Квотер2 работают параллельно, т.е. в один момент могут обрабатывать запросы. Квотер1 при обработке нашел 2х поставщиков, которые могут предоставить по 50шт. (ну нет больше у них) Квотер2 при обработке нашел 10-ть поставщиков, которые могут поставить нужное количество. При обработке они ставят статусы позиций (в проработке, проработана, отказ, закуплено у поставщика и т.д.) на каждую позицию в проработке. Далее выставление коммерческого предложения. Менеджеры, которые работают с этим контрагентом, смотрят проработаны все позиции запроса (статус "Проработана"). Проставляют цены и отправляют Заказчику. Заказчик просмотрел, дал добро допустим. Менеджер ставит добро на закупку. Менеджеры по закупкам, "дербанять" позиции и заказывают, ставят статусы и т.д. Вот примерно так всё и выглядит. |
22 25 27 |
||
22
mistеr
09.07.18
✎
13:59
|
(21) Если на позиции нельзя будет ссылаться, все это не взлетит.
|
23 |
||
23
spiller26
09.07.18
✎
14:06
|
(22) позиции заявок или проработанные позиции?
У Позиции заявки свой УИД. "СтрокаИД" У проработанной позиции свой УИД. "СтрокаИДПроработки", есть "СтрокаИД" Связь по "СтрокаИД". "СтрокаИДПроработки" для связки Статусов. |
26 |
||
24
Buster007
09.07.18
✎
14:08
|
Проработка идет номенклатуры. Следовательно, если и нужна связь, то ее можно и нужно делать по номенклатуре
|
|||
25
Nikoss
09.07.18
✎
14:09
|
(21) а почему не сделать как в 1С принято?
Поступившие запросы в документ "Заказ"-> движение по РН "Заказы". Далее какой-нибудь документ "ПроработкаЗаказа", где на основании данных остатков РН "Заказы" делаются движения в этом же РН "ЗАказы". Статусы проработана,отказ и т.п. ставить на документ "ПроработкаЗаказа". |
|||
26
mistеr
09.07.18
✎
14:20
|
||||
27
d4rkmesa
10.07.18
✎
10:13
|
(21) Джойнится по УИД-у нормально, без разницы ВТ или нет, проверено на 8.3.11.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |