Советы: Выравнивание кодов "вправо" в Axapta

[mazzy]

Цитата:

Сообщение от lastelf

Нашел. У нас EDT VendAccount унаследован от собственного EDT. Наверно, было умышленно сделано для корректной сортировки поставщиков ;-)

Пять баллов!

Мультик вспоминается. Про медведя, вершки и корешки...

[lastelf]

Цитата:

Сообщение от mazzy

Цитата:

Сообщение от lastelf

Нашел. У нас EDT VendAccount унаследован от собственного EDT. Наверно, было умышленно сделано для корректной сортировки поставщиков ;-)

Пять баллов!

Мультик вспоминается. Про медведя, вершки и корешки...

Ладно-ладно. Не показывайте пальцем. Что посоветуете? Убрать с таблиц, использующих EDT CustVendAC для записи данных из двух источников, ссылку на EDT и выравнивание? (будет писать в таблицу код ASIS) Или еще что?

[mazzy]

уже боюсь что-либо советовать удаленно.
обратитесь к специалистам.

Но по идее выравнивание у поставщиков и клиентов должно быть одинаковым... Как это сделать у Вас, что бы не навредить - не знаю. Надо смотреть.

[Yprit]

Хм, а вот при обратной операции - выравнивании кодов вправо (было влево) приходится быть осторожным. В частности, при выравнивании кодов номенклатуры вправо перестал работать в запросах join с PriceDiscTable, т.к. EDT itemRelation остался "выровненным влево". После изменения у него выравнивания все заработало.

[glibs_imported]

Есть уточнение по поводу расширенного типа Num.

В коде встречаются сортировки по полям, которые заполняются номерными сериями, унаследованными от этого типа. Например,

NumberSeq.getNumInternal()
...
select forupdate firstonly numberSequenceList
index hint StatIdx
...

или

NumberSeq_RU.getNumFromList()
...
select forupdate list
order by num desc
where list.numberSequence == _table.numberSequence &&
list.status == NumStatus::Free;
...

Если Num выровнять влево и не использовать префикс (он обеспечивает одинаковую длинну кода, что приводит к "правильной" сортировке с т.з. входящего в номер числа), то работа некоторых процедур в Аксапте может стать неадекватной или непредсказуемой.

Второй пример относится к номеру фактуры. Далеко не всегда для номеров фактуры используют префикс. Подбор номера из списка освободившихся номеров для фактур специфичен. Если Num сдвинуть влево и не добавить к формату префикс, то задумка авторов по подбору номера будет работать некорректно.

Аналогичный пример есть в номерах кассовых ордеров (это по памяти, чтобы не рыться специально в АОТе).

Так что я бы посоветовал так. Если сдвигать Num влево, то для номеров в номерных сериях префиксы использовать ОБЯЗАТЕЛЬНО (по умолчанию, т.е. если вы не доказали обратного).

[komar]

Как-то раз смена выравнивания на базе, заполненной данными (под любимым Ораклом, конечно) привела к тому, что в части таблиц часть данных так и осталась выровненной по-старому. Что, в общем, не мешало системе работать дальше, но напрочь вырубало любой поиск по ссылкам :-) Закономерность, по которой часть таблиц с одним и тем же полем изменила свои свойства, а другая - нет, обнаружить так и не удалось. А еще говорят - барабашки нет!

[glibs_imported]

Мне удавалось добиться такого эффекта.

По-моему, выравнивание нужно менять на рабочей базе в "монопольном" режиме. Если подложить под базу приложение с выровненным влево типом, то синхронизация пробелы уже сносить не будет, а будет считать их данью.

Можно попробовать поставить выравнивание вправо назад, а потом снова влево. Не пробовал, но теоретически может помочь.

[Wamr_imported]

При смене выравнивания ранее введенные данные обновляются автоматически?

[mazzy]

Цитата:

Сообщение от Wamr

При смене выравнивания ранее введенные данные обновляются автоматически?

Да.