Как пометить платеж с несколькими заказами/журналами

[mazzy]

Тема родилась отсюда

Цитата:

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

А также надо учитывать, что один платеж а несколькими закупками (не накладными) нельзя сопоставить.

Цитата:

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

Как это нельзя?
Очень даже можно.

Цитата:

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

Хм, вопрос конечно не по теме, но можно поподробнее?

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

Для вопроса о сопоставлении важно понимать, что пометка на сопоставление с черновиком (заказом/закупкой/журналом) НЕ означает, что выполняется сопоставление (!). Поймите это.

Еще раз: заказы НЕ СОПОСТАВЛЯЮТСЯ с платежами.
Осознайте это: НИКОГДА!

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

Еще раз: сопоставление из заказа - это не сопоставление. это всего лишь пометка будущего сопоставления.
Это незавершенная операция!

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

См. скриншот



продолжение следует...

[Ark]

Хорошо, ладно. Неправильно выразился - не сопоставить, а ПОМЕТИТЬ к сопоставлению. Но все-таки не надо уж быть таким эмоциональным.

[mazzy]

Как же "сопоставить" несколько черновиков с платежом (несопоставленным)?

Другими словами, как сказать системе, что надо отметить несколько незавершенных сопоставлений с одним платежом?

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

В стандартном функционале нужно всего лишь:
0. зайти через клиента в функцию "Сопоставление открытых операций"
1. пометить открытую операцию, которую хочется разделить
2. нажать на кнопку "перераспределение операций"
3. ввести разные даты ожидаемого платежа и суммы.
4. убедится, что остаток равен 0 (появится кнопка Применить)
5. нажать на кнопку применить

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


так можно сделать и три строчки, и четыре, а лучше всего, пять звездочек (С) Карнавальная ночь

После чего открытые строки платежа можно с радостью сопоставлять с любым черновиком.

Надо помнить об особенностях, которые таятся в стандартном функционале.
Если строки платежа сопоставить с черновиками, выделить еще одну строчку и попытаться перераспределить, то Аксапта будет перераспределять не только выбранные явно, но и помеченные на сопоставление с черновиками.



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

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

[mazzy]

Цитата:

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

Но все-таки не надо уж быть таким эмоциональным.

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

[mazzy]

Цитата:

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

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

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

Вот только не надо говорить, что "нельзя сопоставить". Это неправда.

Цитата:

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

что один платеж а несколькими закупками (не накладными) нельзя сопоставить.

[Ark]

Про графики оплаты и сопоставление с открытыми операциями не забыл, а вот про "Перераспределение операций" - да.
Попутно возникли вопросы:
1. Тут: Разбиение проводок при сопоставлении по поставщикам написано, что платеж так разбить нельзя.
2. Ну и в стандартной документации не нашел про эту кнопочку ничего.

[mazzy]

Цитата:

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

1. Тут: Разбиение проводок при сопоставлении по поставщикам написано, что платеж так разбить нельзя.

Э-э-э... Блин. А я и забыл про эту фичу в стандартном функционале.
Мало того, сам сейчас нашотил, разбив накладную, а не платеж.

Я обычно импортирую патчик.
Чтобы в сумму попадали только явно отмеченные проводки.
Ну и заодно и платеж разбивать становится можно.


Мдя... может быть вы и правы - нельзя в стандартном функционале пометить на сопоставление ПЛАТЕЖ с несколькими черновиками. Накладную можно.
Можно только после применения совсем маленького патчика.

Приношу свои извинения.

[Ark]

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

И все-таки эта кнопочка какая-то странная - не для всех накладных почему-то у меня она активируется. В чем может быть причина?

[Ark]

Цитата:

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

И все-таки эта кнопочка какая-то странная - не для всех накладных почему-то у меня она активируется. В чем может быть причина?

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

[mazzy]

что-то я увлекся этим вопросом.
в ax3.0 все было просто. за проверку отвечал метод формы CustOpenTrans.chkCustVendTransReorg

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

В ax2009 стало гораздо интереснее.
там появился метод updateDesignDynamic и целый менеджер CustVendOpenTransManager.canReorganizeTrans()

во наворотили то...
но смысл тот же самый. только еще вексель проверяют.

[Ark]

Цитата:

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

Я обычно импортирую патчик.

Mazzy, может патчик пришлете, и тему можно переместить в Базу знаний и проекты

[mazzy]

Цитата:

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

Mazzy, может патчик пришлете, и тему можно переместить в Базу знаний и проекты

Проект без каких либо гарантий и обещаний работоспособности.
В частности никаких обещаний работоспособностии русского функционала. Особенно для всяких книг продаж и покупок, а также налогового учета.

В ax3.0 нужно закомментировать код в методе формы CustOpenTrans.chkCustVendTransReorg()

        //if (custTransLocal.amountCur <= 0)
        //{
        //    return false;
        //}

В ax4.0 нужно закомментировать код в методе таблицы CustTrans::chkCustTransReorg(...)

        //if (custTransLocal.AmountCur <= 0 || ! custTransLocal.Invoice)
        //{
        //    return  false;
        //}

В ax2009 нужно закомментировать код в методе таблицы
CustTrans::chkCustTransReorg(...)

        //if (!custTransLocal.Invoice && !custTransLocal.BillOfExchangeID)
        //{
        //    return false;
        //}

кстати, получился хороший пример хода мыслей у разработчиков на тему "что такое платеж"

[Maximin]

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

[mazzy]

Цитата:

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

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

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

[glibs]

Комментарий к названию темы.

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

Я нашел для себя оптимальным указывать в строке журнала платежей номер заказа, на который он должен быть отнесен. Если используются счета на оплату, то удобно их нумеровать также как и Confirmation (его печатный номер состоит из номера заказа и версии — удобно вводить потом).

При разноске платежа (каждой строки журнала платежей) сначала проверяется наличие не сопоставленных накладных по заказу. Если есть — то они помечаются на сопоставление. Это аналог ввода строки в журнале платежей пользователем и до разноски заглядывания в Функции\Сопоставление на предмет поиска уже разнесенных по заказу накладных и их пометки.

После разноски (а все собрано аккуратно в одном месте АОТ\Classes\CustVoucher.post()) уже ищется сам заказ, и если на нем осталось что-то открытое, то уже разнесенный платеж помечается на сопоставление с открытым заказом. Это аналог Функции\Редактирование открытых проводок в заказах или закупках.

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

На эту же тему делал еще такое. Если на заказ повесить предоплату через Функции\Редактирование открытых проводок, то при частичной отгрузке пометка на сопоставление слетит, а часть предоплаты отвяжется от заказа. В том же месте можно подшаманить, чтобы вернуть ее назад. Тоже автоматизация аналога рутинной работы оператора.

Что-то там еще хитрое было... но не делал пока.

[Maximin]

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

Желающим воспроизвести эти возможности, хочу сказать, что на display методы подсчетов сопоставленных сумм полагаться не надо. Мимо полей, хранящих суммы и статус оплаты заказа вы мимо никак не пройдете.