Одна проводка в двух валютах

[Aleks_K]

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

Это можно реализовать 2-мя строками журнала, но система не может откорреспондировать такую проводку. Вручную также откорреспондировать невозможно - "Некритическая ошибка корреспонденции: остались неоткорреспондированные проводки. Установлена неверная корреспонденция. Корреспонденция будет отменена."

Кто сталкивался с подобной проблемой? Напишите, пожалуйста, варианты решения.

Спасибо

[mazzy]

Цитата:

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

Напишите, пожалуйста, варианты решения.

прогать

[Aleks_K]

Цитата:

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

прогать

А хоть в какую степь (класс ) идти, часом не подскажете?

[mazzy]

не помню уже. вроде все в тот же LedgerVoucher

как искать источник ошибки
http://axapta.mazzy.ru/lib/exploreerror/

или так
http://axapta.mazzy.ru/lib/xref/#060

[wef]

Цитата:

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

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

...
Спасибо

А нельзя сделать двумя проводками?
С банковского счета на промежуточный в одной валюте, а с промежуточного на поставщика в другой?

[Raven Melancholic]

А что это за операция с финансовой точки зрения?
Исходя из описания в топике это обычные расчеты в УЕ. При платеже будет закрытие задолженности перед поставщиком в рублях, а в момент сопоставления закроется сумма в валюте с начислениями курсовых.
Или описание в топике не полное и это что-то другое?

[Mabo]

Aleks_k
вы не упомянули еще о паре возникших с этой ситуацией проблем))

При совершении этой операции, еще бывают случаи отведения курсовой разницы

Операция возникает, когда при совершении банковской операции, один из банков автоматически выполнят перевод из одной валюты в другую.

для решения, мы использовали промежуточного поставщика "конвертация" с профилем разноски на 57 счете (денежные средства в пути). и далее как и прочие операции конвертации.

Во время импорта банковской выписки проводка разносится на поставщика конвертация, а уже с него бухгалтера растаскивают операции в нужной валюте

мое мнение: Корреспондирование разновалютных проводок ни к чему хорошему привести не может.

[Alexanderis.ua]

Вдруг кому интересно - проблему победили (еще тогда, все никак руки не доходили написать).
Насколько правильно вообще использовать такие проводки и степень полезности такого функционала оставим за кадром.

Проблема, как и можно было догадаться - в классах LedgerBond*
Есть такая табличка, TmpLedgerBondWorkTable_RU, которая собирает информацию о всех проводках к корреспонденции.
Так вот у нее есть поля сумм для дебета и кредита в валюте. Т.е. корреспонденция в разных валютах предполагалась изначально. Но по какой-то причине в классе LedgerBondServer_RU в методе splitTrans об этом забыли.

В результате внутренний метод doSplit содержит строку

    amountCur = resSign * abs(tmpBond.AmountCurDebit);

т.е. на кредитовую валютную сумму просто забили

Перепишем метод следующим образом

// SOI -->
/*
void doSplit
*/
void doSplit(DebCredUnknown_RU _direction = DebCredUnknown_RU::Unknown)
// SOI <--
{
    // ... // 

    // SOI -->
    /*
    amountCur = resSign * abs(tmpBond.AmountCurDebit);
    */
    switch(_direction)
    {
        case DebCredUnknown_RU::Credit:
            amountCur = resSign * abs(tmpBond.AmountCurCredit);
            break;
        case DebCredUnknown_RU::Debit:
        default:
            amountCur = resSign * abs(tmpBond.AmountCurDebit);                    
    }
   // SOI <--

    // ... //
}

Ну и везде по методу splitTrans добавляем передачу соответствующего параметра (4 вызова - по 2 на дебет и кредит).
Это решает проблему подсчета сумм корреспонденции при проверке.

Далее, в том же методе splitTrans производим замену

    // SOI -->
    /*
     _ledgerTrans.calcCrediting();
    */
    _ledgerTrans.calcCreditingBond();
    // SOI <--
// SOI <--

где

public void calcCreditingBond()
{
    Amount tmpAmount = this.AmountCur ? thisAmountcur : 
                                                   this.AmountMST ? this.AmountMST :
                                                   this.AmountMSTSecond;
    ;
    
    this.Crediting = (tmpAmount < 0);
}

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

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

Подсчет сумм для контроля в случае одной валюты даст 0 UAH (дебет = кредит). И сколько бы раз мы его не запускали, будет 0 (при условии если в самом деле суммы совпадают, конечно).
В случае с разными валютами, получаем -200 UAH, +20 EUR. После непосредственно корреспонденции проверка запускается еще раз (на той же мапе) и получаем +200 UAH, -10 EUR, что в сумме дает те же нули.

А вот ручная корреспонденция запускает проверку 3 раза . До, после корреспонденции. И еще раз явно - при загрузке проводок в форму корреспонденции. Зачем - неясно, но это порождает ошибку расхождения сумм. Убираем.
LedgerBondServerManual_RU.loadUnbondedTrans

    this.insTransList(originalTransList, ledgerTrans);
    // SOI -->
    /*
    this.addCheckBalance(ledgerTrans);
    */
    // SOI <--

В результате ошибок нет. Все корреспондируется, все счастливы.