|
![]() |
#1 |
Участник
|
А тут https://www.theaxapta.com/2015/03/au...ice-in-ax.html иcпользуют custVendTransData
PS: Прошу прощения за опечатки. Впопыхах писала первое сообщение, и сейчас уже нельзя ни удалить, ни исправить |
|
![]() |
#2 |
Участник
|
Первая ссылка - маркирование проводок по документам, которые еще не разнесены в системе (в момент разноски сформируется проводка и она будет сопоставлена с той, по которой сделана маркировка перед разноской).
Ссылка из второго сообщения - сопоставление уже сформированных проводок (т.е. когда у вас уже есть в системе и накладная и оплата). Варианты реализации, которые видятся (оба варианта - что маркирование до разноски\что после для CustVend будут выглядеть +- одинаково (использование мапов CustVendTrans\CustVendTransOpen и т.д. думаю поможет сделать идентичным, пример из коробки CustVendAutoSettlement_RU), если не использовать markedInvoice или допилить его использование для поставщиков) : - Выполнить маркирование не разнесенной строки журнала с уже проведенной проводкой накладной (в момент создания\отдельным методом после создания всех строк). Пример как это сделать есть в первой ссылке. Для клиентов из коробки можно использовать поле markedInvoice (заполняем номер, код компании) и дополнительно вызываем код из DS write формы клиентов платежей - по сути он выполняет тоже самое, что и код маркирования, в случае оплаты для одной накладной, скажем так - код получается чуть проще. Для поставщиков не используется, только если допиливать для своих нужд. - Выполнить разноску строки журнала и уже после сопоставлять сформированные проводки оплаты и накладной (пример из второго сообщения). Я сейчас уже не вспомню всех нюансов, но о чем стоит подумать и посмотреть : - можно ли маркировать две разных строки журнала на одную накладную (т.е. у вас накладная на 200 руб, придет 2 оплаты по 100 рублей, не будет ли проблемы с маркированием второй проводки на 100, пока первая еще также помечена и не разнесена, кажется что не должно). Просто помню иногда из интерфейса открываешь проводки для сопоставления, а там проводка может быть помечена красной рукой и эту проводку выбрать для пометки уже нельзя. - если журналы большие - много строк, мало клиентов - то сопоставление в момент создания\разноски журнала, может стать узким местом и возможно имеет смысл сделать отдельную ПО для сопоставления уже в отдельной транзакции после разноски.
__________________
Sergey Nefedov |
|
|
За это сообщение автора поблагодарили: Lankey (1). |
![]() |
#3 |
Участник
|
Спасибо, Сергей! Да, мне нужно строку неразнесенного журнала промаркировать с разнесенной счет-фактурой. В отличае от 1го примера, у меня могут быть частичные оплаты. То есть, сумма оплаты меньше, чем сумма счет-фактуры. Поэтому,видимо, не нужно обновлять сумму на журнале,как в примере, а вызывать custvendopentransmanager.updateSettleAmount(myJourLinePaymAmount). Вопрос, нужно ли потом еще и taxWitholdTrans пересчитывать(. В примере этого нет, а вот в форме vendOpenTrans editSettleAmoutCur() вызывает такой пересчет)
Не понимаю, почему столько вариантов даже в стандарте для простого, казалось бы, сопоставления. Будто по минному полю ходишь (. Может, есть какая-то документация для разработчиков, где можно почитать о том, как правильно это делать, чтобы не наломать дров? Как Вы все с этим разбирались ? По коду или читали где-то док с архитектурой этого процесса (какие классы и таблицы за что отвечают и тд) |
|
![]() |
#4 |
Участник
|
Насчет обновления суммы в явном виде updateSettleAmount - насколько я понимаю, это нужно делать, если вам необходимо сопоставление только на часть суммы из каждой проводки (если же надо сопоставить всю сумму одной из проводок, можно не вызывать этот метод явно, т.к. сопоставление само разберется и сопоставит на меньшую сумму проводок, но возвращаясь к моменту - что у вас может быть несколько не обработанных оплат, которые надо сопоставить с одной накладной, этот метод вызывать придется).
Про taxWitholdTrans - зависит от конфигурации и используется ли у вас эта функциональность, не припомню, чтобы явно приходилось работать с обновлением данных после сопоставления проводок по поставщику. Думаю за базу можно взять метод в клиентах LedgerJournalEngine_CustPayment\updateMarkedInvoiceSpecTrans и сделать аналогично и для поставщиков. Я бы не назвал сопоставление простым - достаточно посмотреть на метод settleNow) Доков по архитектуре данного процесса я не видел (возможно они где то и есть), чата гпт не было, поэтому знания приходили либо от старших товарищей, либо через анализ кода, либо с форума.
__________________
Sergey Nefedov |
|
Теги |
ax2012 |
|
|