Опыт настройки проводки 10 -> 20 с помощью профилей в AX2009

[EVGL]

После 4 часов борьбы с системой и проклиная тот день, когда я стал консультантом, я настроил проводку СКЛАД -> НЗП как это принято в России. Как обычно, без дебаггера не обошлось. Думаю, мой опыт будет интересен.

Идея проста: есть склад "СКЛАД" и склад "ПРОИЗВ"одство. Физически они разделены. Надо соединить склад СКЛАД с профилем "10", а склад ПРОИЗВ - с профилем "20". На этом месте сразу же сталкиваемся с доработкой #1: профиль по умолчанию хорошо присоединяется в модулях заказов и закупок, однако в журналах склада и производства профиль каждый раз надо указывать руками. Казалось бы, в записи склада есть поля для профиля по умолчанию, но его указание не приводит к автоматическому выбору профиля в журналах. Лечится тремя строками в методе \Data Dictionary\Maps\InventStorageDimMap\Methods\initFromInventLocation:

    if (_inventLocation.InventProfileId_RU && (! dimSearch || dimSearch.findActive(_dimGroupId, fieldnum(InventDim, InventProfileId_RU))))
    {
        this.InventProfileId_RU = _inventLocation.InventProfileId_RU;
    }

Хорошо. Берем наше сырье, которое лежит на палетах, переносим со склада на склад. Смотрим проводки ГК - тишина. Пусто. Все ясно: генерирование проводок не предусмотрено русскими для модуля управления складом и переноса палет в нем.

Не беда: создаем классический журнал переноса, указываем палету, склад С и склад По, нажимаем разноску и испытываем шок: система не может разнести журнал перноса, в котором палета перемещается из точки А в точку Б. "Используйте функцию переноса палет." Круг замкнулся.

Слава богу, замечательная компания FWI, в которой я имею честь работать, обладает доработанным журнала переноса, который умеет перемещать палеты. Активизировав ее, я, наконец, получил желаемое
Дхх - К10
Д20 - Кхх,
где хх - некий клиринговый счет. Нельзя сказать, что он мне особо нужен, но и не мешает.

Резюме: идея работает, однако
1) удобство работы с профилями оставляет желать лучшего
2) если используются палеты и управление складом, то без доработок не обойтись.

[BOAL]

Я еще на АХ30 написал мод для разноски номенклатур от нужного набора слк аналитик.
От склада - просто напрашивалось и было остро необходимо (в комплекте с генерированием проводки при переносе).
Но введя еще аналитику Состояние и разноску от пары Склад+Состояние, стало возможным не делать Склады по числу перестановок от состояний на них, а например, использовать их по назначению - реальной географии склада (филиал и тп).
Делать же Склад_хранение, Склад_производство, Склад_монтаж, Склад_брак и тп можно, только если складов 2-3
А вот если их 30? То в списке их нужно делать 120? Это уже жесть!
Мы ж для чего учет ведем по складам, чтоб понимать, где что лежит в реальности по оборотке складской - на то она и аналитика, чтоб срезы давать.
Когда появился штатный мод разноски от профиля и сайты, то это вызвало некий скепсис, а по коду все эти "160 мест в коде, где нужно было тянуть аналитику" совпали с моим же модом и он свелся к паре методов всего. Ну а профили вырубаются конфиг ключом, за что огромное мерси.
И можно пользовать удобную настройку, таскаемую по разным версиям АХ

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

Все это суровое ИМХО, тк логистикой в чистом виде не занимался оч давно и просто не осознал всю прелесть нововведений профилей и сайтов, тогда как старое, проверенное, работает и позволяет настраивать любую нужную разноску по номенклатуре вообще без затыков.

[EVGL]

Цитата:

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

    if (_inventLocation.InventProfileId_RU && (! dimSearch || dimSearch.findActive(_dimGroupId, fieldnum(InventDim, InventProfileId_RU))))
    {
        this.InventProfileId_RU = _inventLocation.InventProfileId_RU;
    }

Update: тут не хватало проверки this.TableId == tableNum(InventDim)

[lev]

см. так же тему "Склад, Профиль учета, Складские аналитики"

[lev]

Цитата:

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

...
Слава богу, замечательная компания FWI, в которой я имею честь работать, обладает доработанным журнала переноса, который умеет перемещать палеты. Активизировав ее, я, наконец, получил желаемое
Дхх - К10
Д20 - Кхх,
где хх - некий клиринговый счет. Нельзя сказать, что он мне особо нужен, но и не мешает.
...

А как бухгалтера восприняли эти фин проводки? не просили оставить одну проводку Д20 - К10? без всяких там транзитных счетов?
И если просили, то как Вы смогли их убедить, что им это не мешает?
Поделитесь опытом please

[EVGL]

Цитата:

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

А как бухгалтера восприняли эти фин проводки? не просили оставить одну проводку Д20 - К10? без всяких там транзитных счетов?
И если просили, то как Вы смогли их убедить, что им это не мешает?
Поделитесь опытом please

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

[lev]

Цитата:

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

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

Повезло Вам
у меня видимо будет более сложная дорога...

[Bega]

Цитата:

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

Повезло Вам
у меня видимо будет более сложная дорога...

Нам пришлось делать доработки, чтобы не было проводок через транзитный счет, в переносе остается только одна проводка ГК, которая генерится для расходной складской проводки. Это касалось у нас только журналов переносов, в заказах на перемещения слава Богу не пришлось делать.

Если интересно, могу сказать что нужно модифицировать.

[lev]

Цитата:

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

Нам пришлось делать доработки, чтобы не было проводок через транзитный счет, в переносе остается только одна проводка ГК, которая генерится для расходной складской проводки. Это касалось у нас только журналов переносов, в заказах на перемещения слава Богу не пришлось делать.

О! Скорее всего мне это и предстоит! Сильно много убили времени на модификации?

[lev]

Цитата:

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

Если интересно, могу сказать что нужно модифицировать.

Было бы интересно!
Заранее спасибо!

[CDR]

Цитата:

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

Нам пришлось делать доработки, чтобы не было проводок через транзитный счет, в переносе остается только одна проводка ГК, которая генерится для расходной складской проводки. Это касалось у нас только журналов переносов, в заказах на перемещения слава Богу не пришлось делать.

Если интересно, могу сказать что нужно модифицировать.

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

На вскидку, модифицируется семейство классов InventMovement.

Хотя я бы сто раз подумал, стоит ли переписывать складскую разноску, только для того чтобы получить правильную корреспонденцию в ГК. К тому же при неаккуратном изменении можно еще поиметь проблемы с коррекциями при закрытии склада.

[lev]

Цитата:

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

Нам пришлось делать доработки, чтобы не было проводок через транзитный счет, в переносе остается только одна проводка ГК, которая генерится для расходной складской проводки. Это касалось у нас только журналов переносов, в заказах на перемещения слава Богу не пришлось делать.

Если интересно, могу сказать что нужно модифицировать.

немного уточню, на вскидку понятно что и где придется допиливать, хочется узнать были ли какие либо подводные камни, и на что особо обратить внимание!

[lev]

Цитата:

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

... На этом месте сразу же сталкиваемся с доработкой #1: профиль по умолчанию хорошо присоединяется в модулях заказов и закупок, однако в журналах склада и производства профиль каждый раз надо указывать руками. Казалось бы, в записи склада есть поля для профиля по умолчанию, но его указание не приводит к автоматическому выбору профиля в журналах. Лечится тремя строками в методе \Data Dictionary\Maps\InventStorageDimMap\Methods\initFromInventLocation:

    if (_inventLocation.InventProfileId_RU && (! dimSearch || dimSearch.findActive(_dimGroupId, fieldnum(InventDim, InventProfileId_RU))))
    {
        this.InventProfileId_RU = _inventLocation.InventProfileId_RU;
    }

на мой взгляд тут доработка немного посложней, а именно:
1. В map InventStorageDimMap добавляем поле InventProfileId_RU.
2. В mappings для таблиц: CustTable, InventDim, PurchTable, SalesTable, VendTable добавляем соответствующие связи полей.
3. В map InventStorageDimMap изменяем методы:
1. modifiedField(). А именно добавляем в case по изменению поля InventLocationId проверку на незаполненность профиля учета. В результате этот case будет выглядеть так:

    if (this.InventLocationId && (!this.InventSiteId    || // No site. Hence default site might be applicable
                                          !this.InventProfileId_RU)) // Добавлена проверка профиля
            {
                if (this.isFormDataSource())
                {
                    this.InventStorageDimMap::modifiedInventLocationFromParent(this.InventStorageDimMap::formDataSourceJoinParent());
                }
            }

2. modifiedInventLocationFromParent(). А именно добавляем переменную InventJournalTrans (строки складских журналов), и в switch по parent.TableId добавляем новый case. В итоге этот метод будет выглядеть так:

    fieldId             fieldId;
    ProdJournalProd     prodJournalProd;
    ProdJournalRoute    prodJournalRoute;
    InventJournalTrans  inventJournalTrans; // Добавлена переменная строк складских журналов
    ;

    if (parent.TableId && parent.TableId != tablenum(Common)) // A parent is found
    {
        switch (parent.TableId)
        {
            case tablenum(InventItemLocation):
                break;

            case tablenum(ProdJournalProd):
                prodJournalProd = parent;
                this.InventStorageDimMap::initFromInventLocation(this.InventStorageDimMap::inventLocation(),
                                                                 prodJournalProd.prodTable().inventTable().DimGroupId);
                break;

            case tablenum(ProdJournalRoute):
                prodJournalRoute = parent;
                this.InventStorageDimMap::initFromInventLocation(this.InventStorageDimMap::inventLocation(),
                                                                 prodJournalRoute.prodTable().inventTable().DimGroupId);
                break;

            // Добавлен case по строкам складских журналов -->
            case tablenum(InventJournalTrans)   :
                inventJournalTrans  =parent;
                this.InventStorageDimMap::initFromInventLocation(this.InventStorageDimMap::inventLocation(),
                                                                 inventJournalTrans.inventTable().DimGroupId);
                break;
            // Добавлен case по строкам складских журналов <--
            default:
                fieldId = fieldname2id(parent.TableId,fieldstr(InventTable,ItemId));
                if (fieldId)
                {
                    this.InventStorageDimMap::initFromInventLocation(this.InventStorageDimMap::inventLocation(),
                                                                     InventTable::find(parent.(fieldId)).DimGroupId);
                }
                else
                {
                    this.InventStorageDimMap::initFromInventLocation(this.InventStorageDimMap::inventLocation());
                }
                break;
        }
    }
    else // No parent exist
    {
        this.InventStorageDimMap::initFromInventLocation(this.InventStorageDimMap::inventLocation());
    }

3. initFromInventLocation(). А именно в конце метода добавляем проверку активности аналитики "Профили учета", и инициализацию профиля (собственно те две строки, про которые говорил EVGL):

    if (!dimSearch || dimSearch.findActive(_dimGroupId, fieldnum(InventDim, InventProfileId_RU)))
    {
        this.InventProfileId_RU = _inventLocation.InventProfileId_RU;
    }

[EVGL]

На самом деле, проще всего в \Data Dictionary\Tables\InventDim\Methods\modifiedField засандалить. Это я так, слишком красиво сделать хотел.

[lev]

Цитата:

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

На самом деле, проще всего в \Data Dictionary\Tables\InventDim\Methods\modifiedField засандалить. Это я так, слишком красиво сделать хотел.

Нее, это на первый взгляд самый простой способ, но как там проверить активна ли аналитика в группе аналитик номенклатуры, и надо ли её вообще заполнять?

Конечно можно что нибудь придумать, ну уж лучше сделать красиво!