Фотозагадка - складские журналы

[mpa]

В Axapta 3.0 имеется "технологическую особенность", которая приводит в системному переименованию номера складского журнала.
Решение уже найдено, как стандартное, так и с использованием "напильника".
Но перед тем, как опубликовать решение хочется узнать, сможете ли вы повторить данную ситуацию?
Итак, внимание на экран...

[Twin]

старо как мир - паспорт записи, только зачем это нужно?

[mpa]

При переименовании через "Паспорт записи" тип изменения RenameKey, а не Update.

[Twin]

А можно этим секретным способом поменять не код разнесенного журнала, а скажем название журнала или автора модификации?

[VadimVN]

Более того, эта "фича" работает ещё и в клиентах поставщиках, что куда как смешнее.

Создаем новый журнал, ему присваивается номер, тут же удаляем созданный журнал, тут же в форме идем на любой существующий журнал, изменяем любое поле и сохраняем. Любуемся результатом.
Ax 3.0 SP1 RU.

[mpa]

Цитата:

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

Создаем новый журнал, ему присваивается номер, тут же удаляем созданный журнал, тут же в форме идем на любой существующий журнал, изменяем любое поле и сохраняем. Любуемся результатом.
Ax 3.0 SP1 RU.

На Axapta 3.0 CIS SP3 HF2 такого повторить не получилось, а SP1 далеко. На самом деле по описанию очень похоже, и я готов в это поверить.

Молодца VadimVN!!!

Чего сделать, чтобы это повторить?
Последовательность на примере журнала с типом "Проводка":

1. Создаем новый журнал с типом «Проводка», поле «Название» не заполняем.
2. Не удаляя нового журнала, переходим на существующий журнал (в журнале есть строки).
3. Нажимаем кнопку "Сохранить"... и получаем сообщение Неправильная спецификация 'Журнал', Номерная серия '<Код ном.серии>' не допускает изменение на меньшее значение., где <Код ном.серии> - номерная серия для нумерации журналов.

Далее получается то, что отражено на рисунке выше. При этом строки из существующего журнала остаются ссылаться на на него, а фактически он теперь с другим номером.

Чего сделать, чтобы этого не повторялось?
Вариантов может быть два:

1. Без "напильника" - в настройках номерной серии <Код ном.серии> указать галку "Уменьшение номера" на закладке "Разное".
2. С "Напильником" - в классе JournalFormTable в методе datasourceActivePre после скобки добавить проверку
   

   void datasourceActivePre()
   {
       // ---> Добавить сюда
       if (numberSeqFormHandler)
           numberSeqFormHandler.formMethodDataSourceLinkActive();
       // <---
   
       if (journalTableData.canBeAutoUnlocked())

Спасибо Борисову Николаю за помощь в исправлении ошибки.

[андрей]

а в AX30SP2 добавление указанной проверки проблемы не решает (

[mpa]

Пожалуйста, протестируйте данную ситуацию на других сервис-паках, в том числе и без CIS.

Тестировалось (были ошибки):

• Axapta 3.0 CIS SP3 HF2
• Axapta 3.0 CIS SP3 HF2 + CU1 (пререлиз).

[Firestarter]

А все же:
1. как попасть в форму, приведенную в начале топика?
2. как поменять название уже разнесенного журнала?

[raz]

Вот и мы встали на эти грабли.

Ошибка все еще присутсвует в системе вплоть до SP4.

Чтобы быстро воспроизвести ошибку надо:
в складских журналах создать строку и не сохраняя ее перейти на другую строчку и нажать сохранить, этой строке присвоиться новый № от созданной строки, т.е. в результате строки потеряют шапку.

Я нашел где ее исправить, но немного сомневаюсь, давайте коллективно подумаем.

\Classes\NumberSeqFormHandler\formMethodDataSourceValidateWrite

PHP код:

        curRecord = this.curRecord();
        if (curRecord.(fieldIdNum) != LastNumber && !this.checkChangeNumber(lastNumber,curRecord.(fieldIdNum)))
        {
            // BugFix -->
            //curRecord.(fieldIdNum) = lastNumber;
            // зачем изменять поле в записи, если мы возвращаем ошибку записи?
            // BugFix <--
            if (formDataSource)
                formDataSource.refresh();

            // SYP-Modification SP3 - Begin
            validateWriteFailed = false;
            // SYP-Modification SP3 - End
            return false;
        } 


[Wamr]

raz
думаю, что твое исправление в качестве заплатки вполне сгодиться для складских журналов, у которых номер генерится автоматом.
Однако, предположим, что пользователю разрешено менять номера журналов в бОльшую сторону, а юзер взял и сменил номер в меньшую, тогда исправленный метод ругнется, но оставит номер введенный пользователем.

Мне кажется, что для нормальной работы надо менять логику работы класса NumberSeqFormHandler
1. при перемещении по списку журналов LastNumber соответствовал текущему положению (сохраненные - "", а созданные = номер журнала).
2. Проверку на изменение номера журнала ручками надо делать не в момент сохранения, а сразу по изменению.
3. Номерная серия (класс NumberSeq) тоже должна отслеживать перемещения по списку журналов, чтобы занимать и освобождать соответствующие номера.
4. И все это должно работать во всех формах.
Так что, задачка по масштабам для фанатов или M$BS