02.03.2006, 07:25 | #1 |
Участник
|
Ошибка при создании проводок
Всем привет!
Работаем с виртуальными компаниями. Все таблицы модуля Invent входят в табличную коллекцию, относящуюся к виртуальной компании VIR. Когда я работаю в одной из компаний, входящих в виртуальную компанию Vir, возникает такая ошибка: открываю один из документов, содержащих складские проводки (например заказ, или журнал проводок, или журнал переноса), начинаю добавлять строки, при этом периодически выскакивает сообщение "Невозможно добавить запись в таблицу Складские проводки (InventTrans). Запись уже существует". Такую ошибку аксапта выдает, когда нарушается уникальность индекса. Но в таблице InventTrans уникальный индекс построен по трем полям: InventTransId, InventDimId, RecId. Плюс еще Аксапта автоматически добавляет поле Dataareaid. Теоретически уникальность по комбинации из этих четырех полей не может быть нарушена никак: RecId генерируется новый и уникальный в пределах компании. Выходит эта ошибка глюк Аксапты? Кто нибудь с такой уже сталкивался? Про виртуальные компании в начале сообщения я упомянул потому что без виртуальных компаний все работает без ошибок |
|
02.03.2006, 09:06 | #2 |
NavAx
|
Наверно дела в названии компании, Vir - система думает вирус.
На самом деле, проверьте номерные серии, во всех команиях они должны отличаться, скорее всего где то идет пересечение. |
|
02.03.2006, 09:24 | #3 |
Участник
|
Да, проверьте номерные серии inventdim (у нас из-за этого была такая же ошибка), ну, может, еще номера лотов.
|
|
02.03.2006, 09:27 | #4 |
Участник
|
Проводки используют следующие номерные серии:
- Номер лота - Инвент дим - Номер складских журналов - номер заказа - номер закупки все эти номерные серии абсолютно разные в компаниях, входящих в виртуальную |
|
02.03.2006, 09:47 | #5 |
NavAx
|
Цитата:
Сообщение от Натка
Проводки используют следующие номерные серии:
- Номер лота - Инвент дим - Номер складских журналов - номер заказа - номер закупки все эти номерные серии абсолютно разные в компаниях, входящих в виртуальную 1. Проверьте свои кастомизации. 2. Вы не "химичили" с таблицей SystemSequences? 3. Если используете АОС, то перезапусите его. |
|
02.03.2006, 10:12 | #6 |
Участник
|
Дело в том что мы трассировкой выяснили ошибка эта возникает в методе Insert таблицы InventTrans причем при вызове Super() в этом методе, т.е. непосредственно при вызове sql-ного метода Insert в таблицу InventTrans. Триггеров у таблицы InventTrans в базе данных нет, т.е. все остальные таблицы исключаются из рассмотрения. Для таблицы InventTrans я даже отключал индекс, по которому идет проверка на уникальность - ошибка возникает все равно. Я в полном замешательстве
|
|
02.03.2006, 10:36 | #7 |
NavAx
|
Цитата:
Сообщение от Sequel
Дело в том что мы трассировкой выяснили ошибка эта возникает в методе Insert таблицы InventTrans причем при вызове Super() в этом методе, т.е. непосредственно при вызове sql-ного метода Insert в таблицу InventTrans. Триггеров у таблицы InventTrans в базе данных нет, т.е. все остальные таблицы исключаются из рассмотрения. Для таблицы InventTrans я даже отключал индекс, по которому идет проверка на уникальность - ошибка возникает все равно. Я в полном замешательстве
ЗЫ. В InventTrans есть еще уникальный индекс по RecId, возможно в ней остались записи, внесенные до попещения таблицы в виртульную компанию, у которых совпадает RecId. Последний раз редактировалось raz; 02.03.2006 в 10:57. |
|
02.03.2006, 11:50 | #8 |
Участник
|
2 raz
Спасибо, действительно такой индекс есть. Ошибка оказалась в том что когда мы стали работать с виртуальной компанией мы еще и переколбасили все строки в таблицах модуля Invent - проставили у них в поле dataareaid виртуальную компанию. В результате - как только начали работать в виртуальной компании, нумерация стала снова с нуля, а записи с RecId выше чем 0 остались из предыдущей компании |
|