Опыт настройки проводки 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

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

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

[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 засандалить. Это я так, слишком красиво сделать хотел.

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

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

[Bega]

Цитата:

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

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

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

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

[lev]

Цитата:

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

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

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

[lev]

Цитата:

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

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

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

[CDR]

Цитата:

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

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

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

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

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

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

[lev]

Цитата:

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

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

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

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

[Bega]

Цитата:

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

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

Цитата:

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

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

1. В классе InventMov_Jour_TransferReceipt метод mustBeBookedFinancially() должен возвращать false.
2. В классе InventMov_Jour_Transfer создать метод, возвращающий расход это или приход с учетом сторно:

private boolean isIssue(boolean _checkStorno = true)
{
    boolean issue = (this.transQty() <= 0);
    ;
    if (_checkStorno&&inventJournalTrans.Storno_RU)
    {
        issue = !issue;
    }

    return issue;
}

3. В классе InventMov_Jour_Transfer изменить метод accountOperations():

LedgerAccount accountOperations()
{
    if (! cacheAccountOperations)
    {
        if (this.isIssue())
            cacheAccountOperations = InventPosting::item(InventAccountType::InventReceipt,this.itemId(),this.inventTable().ItemGroupId, this.inventDim());
        else
            cacheAccountOperations = InventPosting::item(this.assetId() ? InventAccountType::InventIssueFixedAsset : InventAccountType::InventIssue,
                                                            this.itemId(), this.inventTable().ItemGroupId, this.inventDim()) ;
    }

    return cacheAccountOperations;
}

4. В классе InventMov_Jour_Transfer изменить метод postingOperations():

LedgerPostingType postingOperations()
{
    if (this.isIssue())
        return LedgerPostingType::InventReceipt;
    else
        return (this.assetId()) ?   LedgerPostingType::InventIssueFixedAsset :
                                    LedgerPostingType::InventIssue;
}

[CDR]

В дополнение к методу mustBeBookedFinancially() стоит также по аналогии перекрыть методы mustBeBookedBalanceSheet() и mustBeBookedOperations(), что бы в InventTransPosting не проставлялись левые счета/разноска.

А вы тестировали эти модификации на предмет коррекций при закрытии склада?

[gene]

Цитата:

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

1. В классе InventMov_Jour_TransferReceipt метод mustBeBookedFinancially() должен возвращать false.
<и т.д.>

Два вопроса:
1. Вы тестировали это совместно с профилями учета? Есть подозрение, что могут быть проблемы в случае, если в переносе меняется профиль учета и, соответственно, номенклатурный счет.
2. Вы тестировали это с закрытием склада, если при закрытии меняется себестоимость расходной проводки по переносу? Что будет с коррекцией прихода?

[Bega]

Цитата:

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

Два вопроса:
1. Вы тестировали это совместно с профилями учета? Есть подозрение, что могут быть проблемы в случае, если в переносе меняется профиль учета и, соответственно, номенклатурный счет.
2. Вы тестировали это с закрытием склада, если при закрытии меняется себестоимость расходной проводки по переносу? Что будет с коррекцией прихода?

С этими модификациями мы живем с начала 2010 года. Склад закрываем каждый месяц. У нас активно используются профили учета для НЗП, есть переносы со сменой профиля учета. Особых проблем не замечено - копейки отваливаются из-за округлений, это как всегда. Если бы был транзитный счет, копейки были бы на нем, а у нас - на 20-ке, 10-ках и т.п. Но это мелочи. Те модификации, которые перечислил, я собрал из большого проекта, надеюсь ничего не забыл.

[gene]

Цитата:

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

С этими модификациями мы живем с начала 2010 года. Склад закрываем каждый месяц. У нас активно используются профили учета для НЗП, есть переносы со сменой профиля учета. Особых проблем не замечено - копейки отваливаются из-за округлений, это как всегда. Если бы был транзитный счет, копейки были бы на нем, а у нас - на 20-ке, 10-ках и т.п. Но это мелочи. Те модификации, которые перечислил, я собрал из большого проекта, надеюсь ничего не забыл.

Спасибо за информацию, интересно, попробую поиграть с вашим кодом.