Накладные на перемещение, нарушено ограничение целостности (SUPERMAG.SMCSPECCAUSE) : Супермаг Плюс (Супермаг 2000)

Связывать для того. что-бы иметь определенную себестоимость! Если привязывать к выходу с производства, то еще хлеще выходит...
----- Ошибка приема -----
Пакет: 210523135907_3604613_4.SVP
Тип объекта: Выход из производства
Идентификатор объекта: ВыП29000798
-- Уровень вложения 0 --
Сообщение: Невозможно записать в БД объект «PO, ВыП29000798», таблица «SMDOCPRODOUT»
Исключение: Sm.Core.BaseException
Источник: Sm.Post.DbLoader
Метод: Void WriteNewObject(System.Data.OracleClient.OracleTransaction)
-- Уровень вложения 1 --
Сообщение: ORA-02291: integrity constraint (SUPERMAG.SMCDOCPRODOUT_ZONE) violated - parent key not found

Исключение: System.Data.OracleClient.OracleException
Источник: System.Data
Метод: Int32 UpdatedRowStatusErrors(System.Data.Common.RowUpdatedEventArgs, BatchCommandInfo[], Int32)
Данные:
параметры: pID=«ВыП29000798»; pDOCTYPE=«PO»; pSTORELOC=«29»; pZONEID=«2»
соединено с: База даных="MIDEL"; Пользователь="Supermag"
текст команды: Insert into Supermag.SMDOCPRODOUT(ID,DOCTYPE,STORELOC,ZONEID) values(:pID,:pDOCTYPE,:pSTORELOC,:pZONEID)
тип команды: Text

Что то вроде этого должно быть?
ALTER TABLE supermag.SMSPEC
ADD CONSTRAINT SUPERMAG.SMCSPECCAUSE
UNIQUE pCAUSEID DISABLE NO VALIDATE;

Ну в общем да, SMCSPECCAUSE в disable в подчиненных базах и забыть! :)))


(0,13Мб)

Все констрэинты указаны в документации структуры БД:
constraint SMCSpecCause foreign key(CauseType,CauseID,CauseSpecItem)
references SMSpec(DocType,DocID,SpecItem)

У вас проблемы либо с типом основания, либо с его номером, либо с номером позиции из этого основания. Ну или со всем сразу. Более детально вы можете увидеть причину в журнале приема почтового сервера - там будет конкретная строка.

Хех, неплохо я "занекропостил". Ну у вас причина аналогичная и искать выход следует тем же способом)

СМ очень любит виснуть намертво, если в его таблицах появляется некорректные значения. Крайне не рекомендую.

Я не замечал! :) И в моем случае некорректного значения не будет! Просто будет ссылка в основании в подчиненной базе «в никуда»... Супермаг радостно ругнётся, что нет прав на доступ к документу и отстанет... :))) Нет, ну я впринципе его первично заставил все рассылать «штатно», и все работало! НО, на кой чёрт мне лишние места хранения (не локальные) в подчиненных базах, и куча документов от этих мест... Ведь первично то задача стояла получить правильный расчёт себестоимости в ЦО!!!! А там связи по основаниями документа ведут ровно куда надо! :)

В моем случае проблема в том, что во первых у меня в подчиненных базах ТОЛЬКО свои локальные места хранения, и ЦС грубо говоря! А перемещения идут с других локальных МХ, о которых место получение и не знает вовсе! Плюс к этому бизнес процессы построены так, что одно подчиненное МХ может принять товар, и потом часть его отдать на ЦС, а ЦС в свою очередь отдаст другому подчиненному МХ... ЦО то основания для товародвижения найдёт! А вот когда этот товар пойдёт с ЦО в другое подчиненное МХ, то основания товародвижение надо толкать руками, либо ставить настройку «Всем» в админ модуле, что до конца не разобрал (всем это во все подчиненные МХ улетит, либо только прицепом к основному документу, где оно основанием). В общем в моем случае ручное выключение проверки в подчиненных МХ самое правильное решение задачи!

Ну реляционные БД ведь для того и реляционные, чтобы там не было ссылок "в никуда", правда ведь?) Я полагаю, что 99% этих ограничений прописаны не с точки зрения какой-то логики товародвижения (которой можно поступиться), а скорее с точки зрения инженерной. И вот с инженерной точки зрения вы такими действиями наверняка блокируете корректное выполнение каких-либо конкретных расчетов или общих регламентов.

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