Имя: Пароль:
1C
 
Использование ИД для связки таблиц, что лучше использовать?
0 spiller26
 
09.07.18
09:18
Есть РС: Предложения (подчинен регистратору), ПроработкаПозиций (независимый), СтатусыПозиций (переодический).
Суть такова.
1. Заполняется РС "Предложения".
   Измерения:
              СтрокаИД (УИ, связка1)
              НоменклатураЗапрос (строка)
   Ресурсы:
              КоличествоЗапрошено (число)
2. На основании Предложений несколько пользователей, обрабатывают строки предложений. Запись ведется в РС "ПроработкаПозиций"
   Измерения:
              СтрокаИД (УИ, связка1)
              Номенклатура (ссылка)
   Ресурсы:
              КоличествоПредложено (число)
   Реквизиты:
              СтрокаИДПроработки (УИ, связка2)
3. При изменении информации по проработанной позиции отразить информацию в переодический РС "СтатусыПозиций"
   Измерения:
              СтрокаИДПроработки (УИ, связка2)
   Реквизиты:
              СтатусПозиции (Перечисление)

Пока использую тип "Уникальный Идентификатор", но закрадываются сомнения правильности использования.
1 spiller26
 
09.07.18
09:50
Реально никто не использовал такую связку?
2 Nikoss
 
09.07.18
09:55
(1) она не типична для 1С, где зачастую оперируют ссылочными типами данных
3 Cool_Profi
 
09.07.18
09:56
(0) А чем тебе не нравится ГУИД??
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 spiller26
 
09.07.18
10:15
(7) Предложения - документ, который связан с РС "Предложения"
Ситуация:
Покупатель хочет заказать товар, не одну позицию, а хоть сто.
Мы ему обрабатываем позиции, и предлагаем. Может быть ситуация, когда предполагаемая позиция может биться, в зависимости от многих факторов (поставщик, аналоги.)
Покупатель хочет:
                "Резистор 0,5Ом" = 100 шт.
Мы ему можем привести:
                "Резистор 0,5Ом партномер 5234" = 50 шт.
                "Резистор 0,5Ом партномер 3265" = 50 шт.
9 ice777
 
09.07.18
10:17
(8) бить морду таким надо.
разные партнамберы должны быть разными позициями в прайсе.
10 spiller26
 
09.07.18
10:22
(9) Они и будут разными позициями потом в Заказе, когда покупатель согласиться, а на этапе предложений это не нужно, это просто записки.
11 mistеr
 
09.07.18
10:25
(8) OK, сделай иерархию: первый уровень - позиции заказанные, второй - позиции предложенные.
12 spiller26
 
09.07.18
10:27
(11) Это Документ.
13 mistеr
 
09.07.18
10:32
(12) Предложение пусть будет документом, а позиции - справочник.

Заодно можно будет использовать проработанные позиции в других заказах.
14 spiller26
 
09.07.18
10:40
(13) не хочется плодить "чебурашек" если использовать  справочник.
На этапе Предложения это просто строки, на этапе обработки только появляются справочники.
15 mistеr
 
09.07.18
10:44
(14) Не понял про чебурашек.
16 D3O
 
09.07.18
10:57
(1) используем УИ. удобно. не надо заморачиваться как с ИД типа Число. там каждый раз надо опредлить максимальное для области уникальности значение. с УникальныйИдентификатор просто генеришь новый.
17 D3O
 
09.07.18
10:59
(16) ну и небольшое неудобство таки есть - в запрос нельзя подсунуть параметр типа УникальныйИдентификатор )
платформа ругается, что не понимает такого типа ;)
18 spiller26
 
09.07.18
11:05
(16) Вот что и хотел услышать, думал про свой генератор, но это утопия мне казалось.
В запросе вот уже опробовал, пока терпимо. Буду преобразовывать в строку для связей в запросе.
(15) Много предложений фейковых или дубли.
19 d4rkmesa
 
09.07.18
11:22
(18) "Буду преобразовывать в строку для связей в запросе"

Зачем? Разве и так не работает?
20 Buster007
 
09.07.18
11:24
исходя из условий задачи УИД вообще не нужны
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 mistеr
 
09.07.18
13:59
(21) Если на позиции нельзя будет ссылаться, все это не взлетит.
23 spiller26
 
09.07.18
14:06
(22) позиции заявок или проработанные позиции?
У Позиции заявки свой УИД. "СтрокаИД"
У проработанной позиции свой УИД. "СтрокаИДПроработки", есть "СтрокаИД"
Связь по "СтрокаИД".

"СтрокаИДПроработки" для связки Статусов.
24 Buster007
 
09.07.18
14:08
Проработка идет номенклатуры. Следовательно, если и нужна связь, то ее можно и нужно делать по номенклатуре
25 Nikoss
 
09.07.18
14:09
(21) а почему не сделать как в 1С принято?
Поступившие запросы в документ "Заказ"-> движение по РН "Заказы". Далее какой-нибудь документ "ПроработкаЗаказа", где на основании данных остатков РН "Заказы" делаются движения в этом же РН "ЗАказы". Статусы проработана,отказ и т.п. ставить на документ "ПроработкаЗаказа".
26 mistеr
 
09.07.18
14:20
(23) И то, и другое. См. (11)
27 d4rkmesa
 
10.07.18
10:13
(21) Джойнится по УИД-у нормально, без разницы ВТ или нет, проверено на 8.3.11.