Корреспонденция

[Andrux]

Добрый день. Возникла такая ситуация (AX2009, RU5). Если по заказу на продажу в одной операции разносится и строка с положительной суммой и строка с отрицательной суммой (например, скидка) система "переворачивает" проводки сторно:

PHP код:

Дт 62.01  Кт 90.01  200 RUB
Дт 90.01  Кт 62.01  100 RUB 


По правилам БУ счет 90.01 - пассивный, т.е. система в таком случае должна в операции "сторно" поставить флаг коррекция:

PHP код:

Дт 62.01  Кт 90.01  200 RUB
Дт 62.01  Кт 90.01  -100 RUB 


Я смоделировал ситуацию в Job

static server void tutorialBondBatch_RU(Args _args)
{
    LedgerVoucher           ledgerVoucher;
    LedgerVoucherObject     ledgerVoucherObject;

    LedgerBondClient_RU     ledgerBondClient;

    NumberSeq               numberSeq;

    dimension               dimension;
    ;

    dimension = CustTrans::findFromInvoice('Нвт12/000916', 'К000001').Dimension;

    numberSeq = NumberSeq::newGetVoucher(
        LedgerParameters::numRefLedgerExchAdjVoucher());

    ledgerVoucher = LedgerVoucher::newLedgerPost(DetailSummary::Summary,
                                                 SysModule::Ledger,
                                                 numberSeq.parmNumberSequenceCode(),
                                                 TransactionLogType::LedgerJournal);


    ledgerVoucherObject = LedgerVoucherObject::newVoucher(numberSeq.voucher(),
                                                              systemDateGet(),
                                                              SysModule::Ledger,
                                                              LedgerTransType::Sales,
                                                              NoYes::No);

    ledgerVoucherObject.parmVoucherCheck(false);

    ledgerVoucher.addVoucher(ledgerVoucherObject);


    //ledgerVoucher.findLedgerVoucherObject().parmCorrection(true);

    ledgerVoucher.addTrans(                                       //Проводка реализации по строке сторно
        LedgerVoucherTransObject::newCreateTrans(
            ledgerVoucher.findLedgerVoucherObject(),
            LedgerPostingType::SalesDisc,
            '90.01.1',           // Ledger account
            dimension,
            CompanyInfo::find().currencyCode,
            300,              // Amount
            0,
            0)
            );



    //ledgerVoucher.findLedgerVoucherObject().parmCorrection(! ledgerVoucher.findLedgerVoucherObject().parmCorrection());

    ledgerVoucher.addTrans(                                      //Проводка реализации по строке продажи
        LedgerVoucherTransObject::newCreateTrans(
            ledgerVoucher.findLedgerVoucherObject(),
            LedgerPostingType::SalesDisc,
            '90.01.1',           // Ledger account
            dimension,
            CompanyInfo::find().currencyCode,
            -2000,              // Amount
            0,
            0)
            );

    ledgerVoucher.addTrans(                                    //Итоговая сумма задолженности
        LedgerVoucherTransObject::newCreateTrans(
            ledgerVoucher.findLedgerVoucherObject(),
            LedgerPostingType::CustBalance,
            '62.01.1',           // Ledger account
            dimension,
            CompanyInfo::find().currencyCode,
            1700,              // Amount
            0,
            0));

    ledgerBondClient =ledgerVoucher.findLedgerVoucherObject().ledgerBondClient_RU();


    if (ledgerBondClient &&                                       //корреспондируются реализация с проводкой с типом CustBalance
        ledgerBondClient.findVRefByPostingType(LedgerPostingType::CustBalance))
    {
         ledgerBondClient.bondVRef2Log(ledgerBondClient.findVRefByPostingType(LedgerPostingType::CustBalance));
    }

    ledgerVoucher.end();

Дело в том, что при разноске накладной, на каждую строку заказа формируется проводка реаоизации (Счет 90.01), а затем одна по задолженности клиента. Затем в методе SalesFormLetter_Invoice.postJournal() вызывается корреспонденция всех созданных операций с операцией типа CustBalance. Если у сторно принудительно поставить флаг коррекция, то корреспонденция не идет. Видимо проблема в методе LedgerBondServer_RU.splitTrans(), т.к. в этом случае не происходит разделение проводки по 62.01 с типом CustBalance.
Что делать? Подскажите..

[Alexanderis.ua]

попробуйте внести изменение в splitTrans как я писал тут.
(там где упомянут метод calcCreditingBond).

по идее после этого изменения, при признаке "коррекция" у сторно, корреспонденция должна пройти.

[Andrux]

В АХ2009 локализаторы уже внесли изменения в этот метод

public void calcCrediting()
// </GEEU>
{
    /* <SYS>
    this.Crediting = (this.AmountMST < 0 && this.Correct == 0) ||
                     (this.AmountMST > 0 && this.Correct == 1);
                     </SYS> */
    // <GEEU>
    Amount tmpAmount = this.AmountCur ? this.AmountCur :
                       this.AmountMST ? this.AmountMST :
                       this.AmountMSTSecond;

    this.Crediting = (tmpAmount < 0 && this.Correct == 0) ||
                     (tmpAmount > 0 && this.Correct == 1);
                     // </GEEU>
}

[Alexanderis.ua]

Внесли, но суть его осталась прежней и для корреспонденции он не подходит категорически.

Как раз по причине, по которой у вас она не срабатывает.
Он для определения признака Crediting, который не всегда соотносится с истинным знаком проводки (как раз таки из-за наличия флага "коррекция").

[Andrux]

Внес изменения, в моем случае так и не заработало. Кроме того, перестали корреспондироваться проводки, когда разносится операция с признаком коррекция (на все операции)

[Andrux]

Получается никак нельзя исправить разноску? Только потом, по факту, переворачивать проводки каким-нибудь Job?

[oip]

Подниму тему... Нам бухгалтера говорят, что это ошибка, такие проводки некорректны, противоречат принятой Минфином РФ методологии учета, поэтому требуется исправлять.Что скажете?

[belugin]

тут проблема не в корреспонденции, а в том, что надо выставить флаг коррекции при разноске этих операций

[oip]

Да, не в самой корреспонденции. Изначально проблема именно в "переворачивании" проводок. Как ты предлагаешь сделать, чтобы в заказах (и закупках) система не "переворачивала" проводки?

[belugin]

Вот это вот: "Проводка реализации по строке сторно" разносить с признаком коррекции и корреспондировать с дополнительным CustBalance на эту сумму которрый тоже с признаком коррекции или разбивать сторно и несторно на 2 накладных

[belugin]

См также http://blogs.technet.com/b/rumicroso...7/3546450.aspx

[oip]

Максим, спасибо. Действительно, судя по всему, данный хотфикс проблему решает.