Разбиение проводок поставщика

[kashperuk]

Добрый день, уважаемое сообщество.

Не поделится кто-то процедуркой для разделения проводок поставщика? (VendTrans)
Может кто-то ткнет в нужном направлении хотя бы?
Облегчается совсем немного задача тем, что разбивается проводка только в том случае, если она полностью открыта (то есть по ней еще не было сопоставлений)

Спасибо

[Sada]

Кроме как класса InventSplitTrans и его потомков ничего на ум не приходит...
Но это наверно не подойдет...

[kashperuk]

Цитата:

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

Кроме как класса InventSplitTrans и его потомков ничего на ум не приходит...

При чем здесь InventSplitTrans? Это складские проводки.
А у меня проводки по поставщику VendTrans

При разбиении должно тронуть таблицы:
VendTrans,
VendTransOpen,
LedgerTrans,
SpecTrans,
(в OriginalDocuments классе тоже надо чтоб нормально отработало), но при этом таблицы
VendSettlement,
LedgerJournalTrans,
LedgerJournalTable
изменять не нужно.

VendTransCashDisc вроде тоже не нужно
Вот такую вот процедурку хочу.

[Vadik]

а можно полюбопытствовать, зачем это нужно?

[Sada]

Цитата:

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

При чем здесь InventSplitTrans? Это складские проводки.
А у меня проводки по поставщику VendTrans

Я вкурсе. Но какую то аналогию может и можно подсматреть.

[kashperuk]

Цитата:

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

а можно полюбопытствовать, зачем это нужно?

Можно, наверное.

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

Что-то в таком роде.

[Sada]

А сопоставление счет фактур с оплатами?

[kashperuk]

Цитата:

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

А сопоставление счет фактур с оплатами?

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

[mazzy]

VendTrans разбивать не надо. Что-то с задачей не так.

Цитата:

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

При разбиении должно тронуть таблицы:
VendTrans,
VendTransOpen,
LedgerTrans,
SpecTrans,
(в OriginalDocuments классе тоже надо чтоб нормально отработало), но при этом таблицы
VendSettlement,
LedgerJournalTrans,
LedgerJournalTable
изменять не нужно.

Ужос нах.

Для разбиения VendTransOpen есть стандартная процедура
Расчеты с поставщиками \ Поставщики \ Функции \ Сопоставление открытых проводок \ Кнопка Перераспределение проводок

Эта функция позволяет разбить одну открытую (несопоставленную) проводку на несколько и для каждой открытой задать свои ожидаемые даты платежа.

VendTrans и LedgerTrans создаются в момент платежа или закупки.
Я не понимаю при каких условиях эту информацию может потреоваться разбивать.

[mazzy]

Цитата:

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

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

Это только vendTransOpen. vendTrans - не трогай.

[Sada]

Ну вот и я почти про тоже

[Vadik]

Странная все-таки постановка

Вам нужно иметь возможность сопоставлять с этой оплатой несколько закупок ? (Закупка / Функции / Сопоставление открытых проводок)
Если нет - чем не устраивает стандартное перераспределение проводок?

Цитата:

То есть проводка перестанет быть полностью открытой

а что в этом криминального?

[MironovI]

Вот я тоже не понимаю, что из того что проводка перестанет быть полностью открытой?..
А разбивая vendTransOpen учтите, что сопоставить эти две проводки с ОДНИМ платежем потом не выйдет, без перепиливаяния конечно Поскольку есть табличка CustVendTransPostingLog_RU (проводки по сопоставлению), в которой записи привязаны к паре проводок Vend(cust)Trans а не к vendTransOpen.

[kashperuk]

Уточнил только что у консультанта:

"Рег.номер в оплате поставщику не указан.
По каждой накладной свой рег.номер.
Для нормальной работы оборотно-сальдовой ведомости (по договорам) необходимо, чтобы у оплаты и отгрузки был один и тот же номер договора.

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

Поэтому все-таки видимо придется бить проводки.

[KiselevSA]

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

[kashperuk]

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

[MironovI]

Цитата:

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

Уточнил только что у консультанта:

"Рег.номер в оплате поставщику не указан.
По каждой накладной свой рег.номер.
Для нормальной работы оборотно-сальдовой ведомости (по договорам) необходимо, чтобы у оплаты и отгрузки был один и тот же номер договора.

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

Поэтому все-таки видимо придется бить проводки.

Уж не проще-ли отчет переписать чем функционал-то ломать?

[glibs]

Ага. Переписать отчет будет разумнее, чем ломать Аксапту.

Аксапта ориентируется на то, что комбинация поставщик-ваучер-дата-инвойс уникальна в проводке по поставщику. Для оплаты инвойс пустой. Хотите генерить новый ваучер? Не сработает.

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