Тормозное рассопоставление по клиентам

[gl00mie]

Пометка проводок для рассопоставления по клиентам в AX 2009 как-то очень уж тормозила. Оказалось, что дело было в двух э... особенностях локализации. Во-первых, метод \Data Dictionary\Tables\CustAdvanceInvoiceSettlement_W\Methods\existsCustSettlement слишком "расплывчато" понимает связь между строками и шапкой накладных:

if (custInvoiceJour && paymentVoucher && paymentDate)
{
    select sum(LineAmount) from salesLine join custInvoiceTrans
        where salesLine.RefReturnInvoiceTrans_W == custInvoiceTrans.RecId &&
              custInvoiceTrans.InvoiceId == custInvoiceJour.invoiceId;
    if (abs(salesLine.LineAmount) < abs(custInvoiceJour.InvoiceAmount))
    // ...

Из-за этого план запроса получается какой-то, мягко говоря, диковатый (не говоря уже про корректность выборки), но это быстро лечится "уточнением" связи согласно relation'у, чтобы начал хвататься и нормально использоваться подходящий индекс. Во-вторых, по CustSettlement потом уходил запрос, где не было упоминаний dataareaid, и ему очень подошел бы индекс OffsetTransIdx_RU (OffsetRecid, TransRecId), если бы не это поле на первом месте. Это вылечилось перемещением dataareaid в индексе на последнее место, что сделать оказалось совсем просто, см. эту тему.

AX 2009 SP1 EE RU5 (5.0.1500.2985)

[gl00mie]

Если кому интересно, запрос вызывался отсюда \Data Dictionary\Maps\CustVendSettlement\Methods\markOffsets:

while select crossCompany offset order by RecId desc
    where ((this.OffsetCompany == offset.TransCompany && this.OffsetRecId == offset.TransRecId) &&
        (this.TransCompany == offset.OffsetCompany && this.TransRecId == offset.OffsetRecId)) ||
        ((this.TransCompany == offset.TransCompany && this.TransRecId == offset.TransRecId) &&
        (this.OffsetCompany == offset.OffsetCompany && this.OffsetRecId == offset.OffsetRecId)) &&
        /* <SYS>
        (offset.CanBeReversed == true || _old)
        </SYS> */
        // <GEEU>
        (offset.CanBeReversed == true || _old)                                                  &&
        (offset.TransDate == this.TransDate || CompanyInfo::features_W() != CRSEFeatures_W::RU)
        // </GEEU>

[Daiver]

Цитата:

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

Если кому интересно, запрос вызывался отсюда \Data Dictionary\Maps\CustVendSettlement\Methods\markOffsets:

while select crossCompany offset order by RecId desc
    where ((this.OffsetCompany == offset.TransCompany && this.OffsetRecId == offset.TransRecId) &&
        (this.TransCompany == offset.OffsetCompany && this.TransRecId == offset.OffsetRecId)) ||
        ((this.TransCompany == offset.TransCompany && this.TransRecId == offset.TransRecId) &&
        (this.OffsetCompany == offset.OffsetCompany && this.OffsetRecId == offset.OffsetRecId)) &&
        /* <SYS>
        (offset.CanBeReversed == true || _old)
        </SYS> */
        // <GEEU>
        (offset.CanBeReversed == true || _old)                                                  &&
        (offset.TransDate == this.TransDate || CompanyInfo::features_W() != CRSEFeatures_W::RU)
        // </GEEU>

Столкнулись со странным поведением формы для рассопоставлений. Иногда при установке галки "Пометка" не помечается ответная часть сопоставленной проводки. Что в свою очередь создало проблемы после рассопоставления, сальдо и сальдо с учетом сопоставления не совпадают.
Это условие

(offset.TransDate == this.TransDate || CompanyInfo::features_W() != CRSEFeatures_W::RU)

показало, что в сопоставленных проводках разные даты CustSettlement.TransDate. (у нас CompanyInfo::features_W() == CRSEFeatures_W::RU)
Также есть метод в map CustVendSettlement.initFromCustVendTrans где строчка

    this.TransDate          = max(_custVendTrans.TransDate, _custVendTrans.LastSettleDate);

Не пойму где ошибка. Ошибка в условии метода markOffsets (если проверку на дату исключить, то галки проставляются корректно)? Или возникает ошибочная ситуация когда CustSettlement.TransDate (Дата сопоставления) не равна ответной части? Должны ли они совпадать или могут быть разные?

[gl00mie]

Коллеги столкнулись с этой проблемой и вроде как даже успешно с ней справились. Суть проблемы в том, что при сопоставлении пары проводок, одна из которых попадает в закрытый по ГК период, дата сопоставления CustVendSettlement.TransDate получается отличной от даты проводки CustVendTrans.TransDate. А локализаторы зачем-то приделали поиск парной записи сопоставления строго по дате проводки, вот она и не находится в таких ситуациях. Вылечилось тем, что тупо закомментировали это условие в \Data Dictionary\Maps\CustVendSettlement\Methods\markOffsets, вернув поведение к международному функционалу.

[Ivanhoe]

А можно чуть подробнее пример с разными датами?

[gl00mie]

Сопоставляется, допустим, поставка/отгрузка с датой проводки в периоде, который на момент сопоставления уже закрыт по ГК, с оплатой, дата которой на момент сопоставления - в открытом по ГК периоде. В результате формируются проводки сопоставления, в которых для оплаты CustVendSettlement.TransDate == CustVendTrans.TransDate, а для поставки/отгрузки CustVendSettlement.TransDate != CustVendTrans.TransDate. Кажется, как-то так получалось...

[Logger]

up-ну тему.
Вопрос собственно такой :
1. Для чего было добавлено условие

(offset.TransDate == this.TransDate || CompanyInfo::features_W() != CRSEFeatures_W::RU)

и какие риски отказа от него. Что из локализованной функциональности может поломаться.

2. Получается, что при рассопоставлении проводок возможна ситуация когда одна проводка из пары будет рассопоставлена, а другая нет. Аналогичная проблема с реверсом суммовых разниц при рассопоставлении. (Возможны случаи когда они не реверсируются)
Т.е. напрашивается некий механизм контроля, проверяющий перед рассопоставлением, что сумма по custVendTransSettlement, которые мы "нагалкали", в сумме дает 0. ( По аналогии балансировки дебета и кредита при разноске ГК ). Как-то странно что система позволяет такое "половинчатое" рассопоставление и никак не проверяет баланс по custVendTransSettlement.


Какие мысли есть ?