Проблема изменения номера партии в складской аналитике

[wit]

Есть задача изменить номер партии в во всех складских аналитиках где он
присутствует.

При попытке использовать код :

inventBatch = InventBatch::find('000000120','50.07.00002',true);
if (inventBatch)
{
inventBatch.inventBatchId = '000001241';
inventBatch.renamePrimaryKey();
}
выдается сообщение - что обновлены такие то таблицы : .....
Но при этом никакой замены не происходит.

В чем могут быть проблемы. Если кто-нибудь решал такую задачу - поделитесь
опытом.

[Vals]

Номенклатура/Функции/Редактирование кодов аналитики

[wit]

Цитата:

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

Номенклатура/Функции/Редактирование кодов аналитики

Задача ставится - заменить во всех складких аналитиках номер партии, но при этом код аналитики должен остаться прежним

[raz]

А так не подходит?

update_recordset InventDim setting InventBatchId = "Новая" where InventDim.InventBatchId = "Старая"

[Vals]

Хм, а чем отличается Номер партии от Кода аналитики?

[kashperuk]

Может вот это пригодится.

Переименование поля

[glibs]

raz, у вас плохая идея.

wit, проблема в том, что в классе InventDimRenameDimValue Микрософт зарыл очередную дурацкую багу.

Перерисуйте в нем один метод примерно вот так.

InventDim parmInventDimOrig(InventDim _inventDimOrig = inventDimOrig)
{
;
// GLIBS: Bug fix -->
inventDimOrig = _inventDimOrig.data();
// inventDimOrig = _inventDimOrig;
// GLIBS: Bug fix <--
return inventDimOrig;
}

Потом откройте форму InventBatch и перетащите туда (output) пункт меню InventDimRenameDimValue, заполнив свойство с DataSource.

И можно клацать.

[Vadik]

Цитата:

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

wit, проблема в том, что в классе InventDimRenameDimValue Микрософт зарыл очередную дурацкую багу

она там не одна
вводная: СУБД - MSSQL, регистронезависимая кодовая страница (это важно)
переименовываем конфигурацию с "КоНфИгУрАцИя" на "конфигурация" - все, нет больше остатков по этой аналитике

\Classes\InventDimRenameDimValue\handleTable_InventSum

PHP код:

    while select forupdate inventSum
        where inventSum.ItemId      == itemId
        #InventDimJoin(inventSum.inventDimId, inventDimJoin, inventDimOrig, inventDimParm)
    {
        inventDimThis = InventDim::find(inventSum.InventDimId);
        inventDimThis.(dimFieldId) = inventDim.(dimFieldId);
        inventDimThis = inventDim::findOrCreate(inventDimThis);
        inventSumExisting = InventSum::find(itemId, inventDimThis.inventDimId, true);
        // Vadim, lost onhand bugfix -->
        // if (inventSumExisting)
        if (inventSumExisting && inventSumExisting.RecId != inventSum.RecId)
        // Vadim, lost onhand bugfix <-- 


[glibs]

А если хотите, чтобы заработал тот код, который написали вы, то подправьте на таблице InventBatch метод примерно так.

void renamePrimaryKey()
{
InventDimRenameDimValue inventDimRenameDimValue = InventDimRenameDimValue::newInventBatch(this);
;
ttsbegin;
inventDimRenameDimValue.run();
if (this.isFormDataSource())
inventDimRenameDimValue.updateCallerForm(this.dataSource());
ttscommit;
// GLIBS: Bug fix -->
this.update();
// GLIBS: Bug fix <--

}

И убедитесь, что тот код, который вы написали, находится в транзакции.

Дело в том, что он обновляет все, кроме самой партии. Т.е. в проводках, например, у вас уже другой номер партии после запуска джоба. А в справочнике партий — старый.

[wit]

Glibs спасибо. Все заработало.
Но есть проблема. Возникла ситуация. При использовании стандартных функций копирования закупки - копируются строки, где в аналитике остается номер партии от
прежней строки закупки. Как указать(восстановить) новый номер партии для закупок которые уже обработаны.

[RVS]

Цитата:

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

При использовании стандартных функций копирования закупки - копируются строки, где в аналитике остается номер партии от
прежней строки закупки. Как указать(восстановить) новый номер партии для закупок которые уже обработаны.

Это потому, что номер партии, вообще говоря, может присутствовать не только в InventDim (как ни странно).

Недавно решал аналогичную задачку, только вместо Номера партии был номер ГТД.
Решилось примерно так :
1. Поиск по всем таблицам Ax - где есть поля типа ItemId и InventGTDId_RU (так, по-моему), запоминание списка таблиц и полей (опционально, чтобы каждый раз не ждать долго ).
2. Поиск по найденным таблицам - полям пары значений (ItemId, для которого изменяем ГТД + старое значение ГТД). При нахождении - замена старого ГТД на новый.

Вроде работает, клиент претензий не заявлял

2 glibs :

Цитата:

Я никогда не указываю партию или ГТД, например, в строках закупки.

... и это правильно

Только, насколько я понял, там УЖЕ указали?

[glibs]

wit, только сейчас заметил ваше сообщение, прошу прощения.

Я никогда не указываю партию или ГТД, например, в строках закупки. Для указания партии, ГТД, серийного номера я рекомендую использовать регистрацию (а если закуплено Управление складом 2, то журнал прибытия товаров) при закупке (в заказах можно использовать резервирование/авторезервирование или комплектацию (а если закуплено Управление складом 2, то отгрузки)).

В таком случае проблем с партиями не будет. Да и работать так удобнее. Что вы будете делать, если у вас по одной номенклатуре несколько партий поступит? Строку закупки разбивать? А кто это будет делать? Кладовщик?

Или у вас Аксапта внедрена в режиме 1С (сам себе хозяин — как нравится, так и пишу).