Сопоставление невозможно из-за нарушения процедуры управления книгой продаж/покупок.

[maxkov]

Проблема в следующем:

Накладная разбита по графику оплаты на 2 открытых проводки

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

При попытке сопоставления вылетает ошибка: "Сопоставление невозможно из-за нарушения процедуры управления книгой продаж/покупок"

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

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

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

Есть ли другие решения этой проблемы?

[d&m]

версия системы?

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

возможно, есть смысл "разрешить" такие сопоставления - взяв за образец решение из 2009 версии.

[maxkov]

Цитата:

Сообщение от d&m

версия системы?

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

возможно, есть смысл "разрешить" такие сопоставления - взяв за образец решение из 2009 версии.

Поставили 2009 ошибка сохранилась. 2 разбитые по графику проводки не сопоставляются с одним платедом.

МОжет там что-то надо настроить?

[d&m]

Цитата:

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

Поставили 2009 ошибка сохранилась. 2 разбитые по графику проводки не сопоставляются с одним платедом.

МОжет там что-то надо настроить?

в очередной раз проверил - отлично сопоставляется. Напишите подробнее - что вы сопоставляете.

[maxkov]

Цитата:

Сообщение от d&m

в очередной раз проверил - отлично сопоставляется. Напишите подробнее - что вы сопоставляете.

В конфигурации у нас включена журнализация и обработка предоплаты - нам нужна данная шняга.

Далее разнесена закупка с графиком платежей - в итоге в форме сопоставления отражено 3 проводки, порожденные разноской накладной.

В журнале платежей сделан платеж.

Валюта платежи и накладной - доллар.
Даты различаются - соответственно будут сформированы курсовые разницы при сопоставлении.

Далее в форме сопоставления фактур с оплатами выделяю проводку оплаты и 2 проводки задолженности, относящиеся к разнесенной накладной.

КОрректирую сумму сопоставления в обеих проводках задолженности - ставлю по 10 долларов.

Нажимаю обновить - ошибка книги покупок и продаж.

[d&m]

Цитата:

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

Валюта платежи и накладной - доллар.
...
ошибка книги покупок и продаж.

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


если есть активная поддержка - зарегистрируйте эту ошибку, авось исправят...

[Maximin]

Отключить можно, кроме книги покупок/продаж ничего не отвалится.

[maxkov]

спасибо отключил функционал

а 2009 искать надо, у нас 4

[Ivanhoe]

В 4.0 была бага при сопоставлении / рассопоставлении - не очищалась история и возникала указанная ошибка. Есть возможность посмотреть в коде откуда именно возникает ошибка?

[Geo]

Та же ошибка вылезла сегодня у нас. АХ 2009, 5.0.1500.2116.
Пытаемся сопоставить возврат предоплаты клиенту (текущий период) с самой предоплатой (тот период уже закрыт). Предоплата эта уже была с чем-то сопоставлена в своем периоде, только что их рассопоставили текущим периодом.

Доступ к коду имеется. Ошибка возникает в классе CustVendSettle, метод settleNow, код:

if (! this.isBadDebtAmortisation_RU() && ! this.checkIfCanBeSettled_RU(transactionDate))
{
   throw error("@GEE8080");
}

В том же классе есть упомянутые методы isBadDebtAmortisation_RU и checkIfCanBeSettled_RU. Они таковы:

private boolean isBadDebtAmortisation_RU()
{
    return (custVendTransDebit.TransType  == LedgerTransType::RTax25_BadDebtDebitAmortisation    ||
            custVendTransDebit.TransType  == LedgerTransType::RTax25_BadDebtCreditAmortisation   ||
            custVendTransCredit.TransType == LedgerTransType::RTax25_BadDebtDebitAmortisation    ||
            custVendTransCredit.TransType == LedgerTransType::RTax25_BadDebtCreditAmortisation);
}

protected boolean checkIfCanBeSettled_RU(TransDate _settlementDate)
{
    return true;
}

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

[Ivanhoe]

В таблице CustVendTransPostingLog_RU случайно не остались "лишние" строки, привязанные к предоплате?

Встречал такие ошибки, когда у "начисления" (оно же накладная), сделанного через журнал ГК, не было заполнено поле Invoice. А при очистке указанной мной таблицы (при рассопоставлении) начисление ищется с учетом заполненности этого поля.

[Geo]

По совету Ivanhoe стал копать таблицу CustVendTransPostingLog_RU. Там было две пары записей по этому клиенту: одна по действующему сопоставлению, другая по отмененному. Рассопоставил оставшуюся операцию по клиенту - записи по (бывшему) действующему исчезли из CustVendTransPostingLog_RU, а те, что были по ранее отмененному - остались.

То есть получилось, что действующих сопоставлений по клиенту нет, отмененных много, а пара записей в таблице - всего одна, для одного конкретного прошлого сопоставления. Действительно, на правду это как-то мало похоже.

Решился их удалить (сохранив в Excel'е, мало ли что). Сопоставление заработало.

Большое спасибо!

[Ivanhoe]

Поле "Накладная" было заполнено у исходной проводки по клиенту (не оплата)?

[Geo]

Цитата:

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

Поле "Накладная" было заполнено у исходной проводки по клиенту (не оплата)?

Нет, не было. Проводка делалась через ГК, входила в нач. сальдо.
Ты был целиком прав

[Ivanhoe]

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

Ну а заливщику начального сальдо - отдельный привет

[glibs]

Ошибка есть в 5-ке. Сам видел. Если по проводке по накладной по поставщику есть две открытые проводки с одинаковой датой, то при сопоставлении действительно возникает ошибка. Если в открытых проводках даты разные, то ошибки при сопоставлении не будет.

[d&m]

Цитата:

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

. Если по проводке по накладной по поставщику есть две открытые проводки с одинаковой датой, то при сопоставлении действительно возникает ошибка. .

под датой тут понимается "Срок выполнения" (DueDate) ?

Если да, какой смысл в открытых проводках с одинаковой датой? открытые проводки как раз и нужны для разных дат (сроков погашения задолженностей)

[Jabberwocky]

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

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

[d&m]

Цитата:

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

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

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

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

Но если проводки валютные - то валится ерор.

[maxkov]

Цитата:

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

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

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

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

Не представляю что там чему противоречит. Просто если отключить функционал книги покупок, то система прекрасно формирует курсовые разницы и сопоставляет как угодно.

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