Вопрос к знатокам алгоритма периодического сопоставления

[ATimTim]

В классе CustVendAutoSettlement_Cust_RU в методе query
существует код инициализации query:

protected Query query()
{
    Query                   query = new Query();
    QueryBuildDatasource    qbds;
    QueryBuildRange         qr;

    // CustTransOpen -->
    qbds = query.addDataSource(tableNum(CustTransOpen));
    qbds.addRange(fieldNum(CustTransOpen, DueDate)).value(SysQuery::range(dateFrom, dateTo));
    qbds.addRange(fieldNum(CustTransOpen, AccountNum));

    qbds.addSortField(fieldNum(CustTransOpen, AccountNum));
    qbds.addSortField(fieldNum(CustTransOpen, DueDate));
    qbds.orderMode(OrderMode::ORDERBY);

    // CustTrans -->
    qbds = qbds.addDataSource(tableNum(CustTrans));
    qbds.relations(true);
    qbds.joinMode(JoinMode::INNERJOIN);

    qr = qbds.addRange(fieldNum(CustTrans, Invoice));
    qr.value(SysQuery::valueNotEmptyString());
    qr.status(RangeStatus::LOCKED);

    qr = qbds.addRange(fieldNum(CustTrans, RContractCode));
    qr.status(autoSettleType == AutoSettleType_RU::Contract ? RangeStatus::OPEN : RangeStatus::LOCKED);

    qr = qbds.addRange(fieldNum(CustTrans, RContractAccount));
    qr.status(autoSettleType == AutoSettleType_RU::Contract ? RangeStatus::OPEN : RangeStatus::LOCKED);

    qr = qbds.addRange(fieldNum(CustTrans, AccountNum));
    qr.status(RangeStatus::HIDDEN);

    return query;
}

у меня возник вопрос к условию :

  qr = qbds.addRange(fieldNum(CustTrans, Invoice));
    qr.value(SysQuery::valueNotEmptyString());
    qr.status(RangeStatus::LOCKED);

Ведь если не указывать номера накладных, к примеру в общих журналах ГК,
по поступлениям и выбытиям ДС по конкретному клиенту, то периодическое сопоставление никогда не сопоставит такие проводки.
Мне интересно, какой потаенный смысл был заложен в это условие.

[Pavel Pustovalov]

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

[Logger]

Цитата:

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

Мне интересно, какой потаенный смысл был заложен в это условие.

Потаенный смысл мне тоже неясен :-)
Похоже Аксапта считает, что если Invoice заполнен то это накладная, если пуст - то платеж и пытается сопоставлять накладные с платежами и другимим накладными, а просто на платежи забивает.

Мы решили проблему сопоставления платежей с платежами тем что заполняли при разноске поле Invoice для тех платежей кторые должны быть сопоставлены с платежами (обычно это сторно было)

Сопоставление заработало - ничего не поломалось.

[glibs]

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

Если вы в журнале ГК не укажете номер накладной, значит вы разнесете оплату.

Это про смысл поля Код накладной.

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

[glibs]

Цитата:

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

...
Похоже Аксапта считает
...

Посмотрите

CustTrans.payment()
CustTrans.invoice()
CustTrans.exchAdjustment()

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

Цитата:

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

...
Мы решили проблему сопоставления платежей с платежами тем что заполняли при разноске поле Invoice для тех платежей кторые должны быть сопоставлены с платежами (обычно это сторно было)
...

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

[zemlyn]

Цитата:

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

Потаенный смысл мне тоже неясен :-)
Похоже Аксапта считает, что если Invoice заполнен то это накладная, .

Наткнулся недавно на такой же "алгоритм" в акте сверки RLedgerSheetServer_ActAdjust*

[ATimTim]

Друзья, огромное спасибо!

Термин:
Технический инвойс - инвойс "от балды", по произвольному алгоритму

Т.к. поле инвойс в общих журналах ГК у в наших бизнес-процессах НЕ ИСПОЛЬЗОВАЛОСЬ (а другие журналы для отражения ДДС мы не используем), я пробежался джобиком и проставил у всех строк общих журналов ГК и связанных с ними клиентских проводок (аналогично и у проводок по поставщику) с пустыми инвойсами технические инвойсы (сделал их равными номеру общего журнала ГК ).
Причем проставил технические инвойсы у всех строк (поступления или выбытия не различал - проставил у всех)

Сделал что- то вроде

update vt
  set vt.invoice = ljt.journalnum
  from VendTrans vt
            inner join
         LedgerJournalTrans ljt 
           on vt.transdate = ljt.transdate 
               and vt.voucher = ljt.voucher
  where ljt.invoice = ''

    

p.s. T-SQL   ,

После этой нехитрой процедуры периодическое сопоставление сработало на 5 баллов
Вот такие дела...

Вывод следующий - если планируете использовать периодическое сопоставление, добивайтесь заполнения инвойсов (VendTrans.invoice и CustTrans.invoice). Делайте это поле обязательным для заполнения или заполняйте его автоматически по своему алгоритму (номерная серия или просто запись в CustTrans.invoice VendTrans.invoice номер накладной (в моем случае, к примеру CustTrans.invoice = LedgerJournalTrans.journalnum ) или voucher.
Или ..... правьте алгоритм периодического сопоставления... я не рискнул и выбрал меньшее из зол, на мой взгляд

[raz]

Цитата:

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

Причем проставил технические инвойсы у всех строк (поступления или выбытия не различал - проставил у всех)

Мы сделали проще - убрали накладную из запроса, чтобы сторно платежей тоже сопоставлялись.

[ATimTim]

raz
Мы сделали проще - убрали накладную из запроса, чтобы сторно платежей тоже сопоставлялись.

Именно это я и подразумевал под правкой алгоритма сопоставления. Но для себя решил, что лучше "накормить" аксапту тем что она хочет, нежели "убеждать" ее в том что она этого не хочет

[raz]

накормив, вы нарушили логическую целостность данных, т.е. данные теперь не соответсвуют реальности.

[ATimTim]

Цитата:

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

накормив, вы нарушили логическую целостность данных, т.е. данные теперь не соответсвуют реальности.

Согласен.
Поэтому почесав затылок и покусав ногти решил поправить алгоритм, закомментировав условие с инвойсами. Благо, что тренировался я до этого на тестовой базе

Спасибо!

[raz]

Мы для большей точности допилили сопоставление по аналитикам.

[ATimTim]

У нас сопоставление происходит в разрезе договоров.

P.S.
Все уже довольны

[Logger]

Цитата:

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

я пробежался джобиком и проставил у всех строк общих журналов ГК и связанных с ними клиентских проводок (аналогично и у проводок по поставщику) с пустыми инвойсами технические инвойсы (сделал их равными номеру общего журнала ГК ).

Любопытно все таки аксапту на проектах пилят.
Мы вот тоже придумали проставлять Voucher в поле Invoice (прямо при разноске)

схожие модифы родятся...

[ATimTim]

Цитата:

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

Любопытно все таки аксапту на проектах пилят.
Мы вот тоже придумали проставлять Voucher в поле Invoice (прямо при разноске)

схожие модифы родятся...

Да.

Меня в этом варианте не устроило, что в модулях Клиентов и Поставщиков создаются накладные.. Они нам не нужны на проекте.