AX2012. Ошибка при отмене закрытия склада.

[Товарищ ♂uatr]

Добрый день!
Подскажите, пожалуйста, при закрытии склада в 2012 Аксапте создались записи с некорректными значениями в GeneralJournalAccountEntry.
Инфолог журнала закрытия пестрит записями:
Себестоимость ед. изм. 0,00 может быть ошибочной, поскольку проводка не может быть полностью сопоставлена.
После этого склад был открыт и, по идее, должны были создаться сторно записи в том же количестве, с противоположными знаками дающими 0(?) в сумме. Но они создались только частично.
С InventSettlement всё хорошо, количество записей идентичное (закрытие=открытию).
В итоге, в форме ручная корреспонденция фигурируют записи по сторнированному закрывающему ваучеру, которые даже после сопоставления дают больший результат (количество дебетовых строк не соответствует количеству кредитовых).
Видимо, необходимо самостоятельно создать сторно записи для GeneralJournalAccountEntry.
Кто-нибудь это уже делал?
Раз такое произошло, то проблему не решить только созданием сторно проводок, а она есть еще где-то(или это заблуждение?), какие есть соображения по этому поводу?

[Raven Melancholic]

Ну сообщение:

Цитата:

Себестоимость ед. изм. 0,00 может быть ошибочной, поскольку проводка не может быть полностью сопоставлена.

Еще и до 2012 говорило о том, что для расходной проводки нет соответствующих приходных проводок в ТОМ ЖЕ периоде или ранее. Например, выполнили разноску заказа на покупку в декабре с указанием даты разноски 15/12/2014, после этого разнесли накладную по продажам в декабре с указание даты разноски 30/11/2014. В результате приход позже расхода.
Это пример по моделям, относящимся к месяцу, если в модели указано отношение по датам, то такое может происходить даже в пределах периода закрытия.
То же может происходить в случае, когда в группе складских аналитик установлен флаг финансовых остатков и даты прихода на склад позже, чем даты расхода со склада в разрезе комбинации финансовых аналитик. Точнее даже не соотношение дат прихода и расхода, а их соотношение по периоду проводок и настроек модели

[Raven Melancholic]

На самом деле, эти сообщения могут считаться ошибкой или не считаться зависит от того, ведете ли Вы учет именно в Аксе по РСБУ или не ведете.
Если есть такое отклонение по датам операции, то в следующем периоде (для упрощения будем считать, что период это месяц), операции с датой задним числом подхватятся для расчета себестоимости. По РСБУ это проблема, а для МФСО нормально.

[Maxim Gorbunov]

Выделил вопрос по AX2012 в новую тему

[Maxim Gorbunov]

Теперь по теме вопроса:
Как верно заметил Raven Melancholic, сообщения о том, что не все расходы удалось сопоставить, в принципе, ошибкой не являются, но с логической точки зрения это не очень хорошо. Стоит с этим разобраться потом.
Насколько я понял, сейчас главная проблема в том, что отмена закрытия склада не полностью разнеслась в ГК и балансы ваучеров по закрытию и отмене закрытия разные. Так? Ищите, какие именно реверсирующие InventSettlement не разнеслись в ГК, что у них общего. Отмечено ли поле Posted для всех реверсирующих InventSettlement. Не настроена ли асинхронная разноска документов в ГК? В общем, перед тем, как исправлять ошибку, найдите её причину.

[Logger]

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

Рекомендую проверить что InventSettlement по закрытию балансирует с ГК по закрытию.
Например в одной транзакции пометить его как неразнесенный (InventSettlement.posted = 0) разнести, вывести куда нить полученные проводки по ГК или сравнить с уже сделанными и откатить транзакцию.
Если не балансирует, то скорее всего все так и было.

Для защиты от удаления проводок поучаствовавших в закрытии / пересчете, можно сделать такую модифу (пример приводу для 2009-й аксапты) :
\Data Dictionary\Tables\InventTrans\Methods\delete

...
        if (this.isUpdatedFinancial())
        {
            // pkoz 19.03.2009 -->
            this.GRD_checkDeleteSettlement(); // перед удалением проверяем есть ли неотмененные сопоставления
            // - если есть то удалять нельзя нужно сперва отменить соответсвующее сопоставление, или коррекцию
            // если разрешить удаление без отмены как здесь, то тогда разъедется LedgerTrans и InventTrans
            // Дальнейшая отмена сопоставлений, коррекций, как я понимаю ситуацию уже не вылечит, так как
            // записи в inventSettlement по которым при отмене будут делать проводки по ГК уже будут удалены
            // т.е. нужно либо запретить удапение, либо при удалении делать сторнирующую проводку по ГК на
            // суммы удаляемых InventSettlement. Ну и просто - даже если проводок по ГК не было - InventSettlement
            // друг с дружкой связаны ссылками - поэтому просто удалять нельзя.

            // см. джоб GRD_6029_CancelSettlementPerInventTrans
            // pkoz 19.03.2009 <--

            delete_from inventSettlement
                index hint RecIdTypeIdx
                where inventSettlement.transRecId       == this.recId           &&
                      inventSettlement.itemId           == this.itemId;
        }
...

\Data Dictionary\Tables\InventTrans\Methods\GRD_checkDeleteSettlement

    // pkoz 19.03.2009
boolean GRD_checkDeleteSettlement(boolean _doThrow
    = true
//    = false
    )
{
    InventSettlement    inventSettlement;
    boolean             ret = true;
    InventClosing       InventClosing;
    str locGetErrorText()
    {
        return
        strFMT("По проводке Лот %1, recID %2, TransRefID %3, TransType %4 - есть неотмененные сопоставления/коррекции. Дата сопоставления/коррекции - %5",
                this.InventTransId,
                this.RecId,
                this.TransRefId,
                this.TransType,
                inventSettlement.TransDate //pkoz 31.07.2014
                );
    }
    ;
    if (this.isTmp())
        return true;

    ttsBegin;
    while
    select forupdate inventSettlement
    order by transDate //pkoz 31.07.2014
    where
        inventSettlement.transRecId       == this.recId           &&
//        inventSettlement.itemId           == this.itemId
        inventSettlement.Cancelled        == NoYes::No

    //pkoz 09.07.2012 -->
    /*
    // добавили такое условие потому что реально надо запрещать удаление InventTrans только если есть неотмененные сопоставления по
    // ваучеру отличному от ваучера из InventTrans
    // а именно этому случаю соответсвуют сопоставления от пересчетов, закрытий и коррекций
    // если же сопоставление возникло из-за накладных расходов при разноске закупки (markupTrans)
    // то там ...
    join InventClosing
    where
        InventClosing.Voucher   == inventSettlement.Voucher
     && InventClosing.TransDate == inventSettlement.TransDate
    */
    //pkoz 09.07.2012 <--

    {
        //pkoz 09.07.2012 -->
        if (     this.DateFinancial == inventSettlement.TransDate
             &&  this.Voucher       == inventSettlement.Voucher
             && !inventSettlement.inventClosing_GRD()
           )
        {
            // добавили такое условие потому что реально надо запрещать удаление InventTrans только если есть неотмененные сопоставления по
            // ваучеру отличному от ваучера из InventTrans
            // а именно этому случаю соответсвуют сопоставления от пересчетов, закрытий и коррекций
            // если же сопоставление возникло из-за накладных расходов при разноске закупки (markupTrans)
            // то там ...

            continue;
        }
        //pkoz 09.07.2012 <--

        if (_doThrow)
            throw   error(locGetErrorText());

        ret = checkFailed(locGetErrorText());
        break;
    }
    ttsCommit;

    return ret;
}