Расчет конечного сальдо

[axalex]

Здравствуйте!
Необходимо:
1. Рассчитать сальдо конечное кредитовое по счету 62.2.1 на дату (по данному контрагенту, договору, ставке НДС);
2. Рассчитать сальдо конечное дебетовое по счету 76.АВ на дату (по данному контрагенту, договору, ставке НДС);

Для дальнейшего вывода в Excel и построения отчета.

Не получается найти подходящий класс. Или у кого нибудь есть мысли на эту тему. Смотрел похожие темы, класс Ledger Balance и его наследников.

[twilight]

Расчеты с клиентами / Запросы / Оборотно-сальдовая ведомость
смотрели?

[axalex]

Цитата:

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

Расчеты с клиентами / Запросы / Оборотно-сальдовая ведомость
смотрели?

Заглянул, но у меня она в очень мощном апгрейде, очень долго разбираться в коде, не успеваю.. Проще просто класс подобрать наверное, чем разобрать ОСВ.. Вот и спрашиваю совета..

[axalex]

Просмотрев различные формы и классы, решил написать свои функции по расчету сальдо.
Вышло примерно так:

Amount getBalanceCred(CustTrans _custTrans)
{
    CustTrans    custTransCursor;
    LedgerTrans ledgerTransCursor;
    str 100         accountNum;
    ;
    select sum(AmountCur) from ledgerTransCursor
        where ledgerTransCursor.Dimension[7] == _custTrans.Dimension[7]
            && ledgerTransCursor.Dimension[8] == _custTrans.Dimension[8]
            && ledgerTransCursor.Dimension[9] == _custTrans.Dimension[9]
            && ledgerTransCursor.AccountNum == "62.02.1"
            && ledgerTransCursor.TransDate <= TransDate
            && ledgerTransCursor.Crediting  == true;
         // && ledgerTransCursor.TransType == 15

    return ledgerTransCursor.AmountCur;
}

И так:

Amount getBalanceDeb(CustTrans _custTrans)
{
    CustTrans    custTransCursor;
    LedgerTrans ledgerTransCursor;
    str 100         accountNum;
    ;
    select sum(AmountCur) from ledgerTransCursor
        where ledgerTransCursor.Dimension[7] == _custTrans.Dimension[7]
            && ledgerTransCursor.Dimension[8] == _custTrans.Dimension[8]
            && ledgerTransCursor.Dimension[9] == _custTrans.Dimension[9]
            && ledgerTransCursor.AccountNum == "76.АВ"
            && ledgerTransCursor.TransDate <= TransDate
            && ledgerTransCursor.Crediting  == false;
         // && ledgerTransCursor.TransType == 15

     return ledgerTransCursor.AmountCur;
}

Считал сальдо по аналитикам. Понимаю, что с точки зрения системы это не правильно.
Но, всё же, возникают ошибки в выводе. По моим предположениям я не учёл что-либо..

[mazzy]

вы суммируете amountCur, но не учитываете валюту. в результате у вас доллары складываются с евро и с остальными валютами. amountCur можно суммировать только в пределах одной валюты.


кроме того, вы получаете дебетовое сальдо.
но не учитываете поле correction.
аксапта умеет работать с красным сторно. в этом случае поле correction = true.

[Владимир Максимов]

Стандартные отчета Axapta основаны на суммировании клиентских проводок (CustTrans), поскольку именно в них указывается код клиента. Бух.счетов в клиентских проводках нет. Но в них есть такое понятие, как "Профиль разноски". В свою очередь, справочник профилей разноски содержит ссылку на бух.счета.

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

1. По справочнику профилей разноски отбираются все профили разноски имеющие связь с нужным бух.счетом
2. Суммируются все клиентские проводки нужного клиента у которых указан профиль разноски из списка, отобранного на первом этапе

Ну, есть еще некоторые тонкости какие именно бух.счета из профиля разноски используются для фильтрации, но это сами разберетесь...

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

Проблема здесь в том, что связь таблицы клиентских проводок и бух.проводок организована по коду ваучера. А подобная связь - не однозначна. Может быть несколько бух.проводок с одним и тем же номером ваучера, но не все из них относятся к нужному клиенту. Следовательно, попытка просуммировать бух.проводки по конкретному клиенту всегда будет не вполне корректна. Всегда будет содержать некую неопределенность.

Как следствие, если Вам нужен баланс по клиенту, то классы Ledger... для этой задачи - бесполезны. В них просто нет ссылок на клиентов. Нужно "копать" в сторону классов вроде CustVend... А как их использовать, смотрите в отчете "Оборотно-сальдовая ведомость"

[CDR]

Цитата:

Сообщение от Владимир Максимов

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

1. По справочнику профилей разноски отбираются все профили разноски имеющие связь с нужным бух.счетом
2. Суммируются все клиентские проводки нужного клиента у которых указан профиль разноски из списка, отобранного на первом этапе

Ну, есть еще некоторые тонкости какие именно бух.счета из профиля разноски используются для фильтрации, но это сами разберетесь...

При этом следует иметь ввиду одну неприятную особенность такого подхода (характерную, кстати, и для стандартной ОСВ по контрагентам). Если бух. счет в профиле разноски изменяется, то все проводки, выполненные ранее автоматом "перескакивают" на новый бух. счет.