Программное изменение "Счет на" в заказе

[Antant]

Подскажите джобик для программного изменения "Счет на" в отфактурованном заказе

Axapta 3.0 sp3 oracle

[Sada]

А как то по расширеннее можно суть проблемы?
А то если Вам просто джобик по изменению счета на.... то это 4 строчки. Но чую дело не в этом

[Antant]

Отфактуровали огромные заказы, потребовалось значительное время. Потом выяснилос, что в клиенте не стоял "счет на", соотвественно проводки для оплаты сформировались по коду клиента.
Сейчас нужно срочно, подходит время оплаты, поменять "счет на" в этих заказах. Я посмотрел, там он проставлен и в фактуре, и в накладной, и в проводках. Я думаю, если буду писать сам, могу не учесть парочку таблиц.
Вот может кто-то сталкивался с такой проблемой и у кого-то есть готовый вариат джобика?

[Sada]

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

[Antant]

Уйдет слишком много времени... у нас сейчас столько его нет

[Sada]

Тогда ждите...
ПС: Но времени на это не так уж и много.

[mazzy]

Цитата:

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

Подскажите джобик для программного изменения "Счет на" в отфактурованном заказе

Вы абсолютно неправильно ставите задачу.
От поля "Счет на" зависит на кого будет выписываться накладная и с кого будет браться профиль разноски. Следовательно при "изменении Счета на в ОРФАКТУРОВАННОМ заказе" по идее должны изменится проводки в CustTrans (задолженность) и проводки в LedgerTrans. А также taxTrans. Ну, и если вы занимаетесь книгами продаж, то и они тоже

В свою очередь, проводки в CustTrans могут быть:
1. переоценены
2. сопоставлены с платежами
3. влиять на прогноз дивжения денежных средств

Т.е. по идее вам придется изменять и переоценки, сопоставления и прогнозы.

Ну, а проводки в LedgerTrans могут влиять... на все что угодно

Т.е. задача в вашей формулировке превращается в: подскажите джобик(!) который сторнирует уже существующие проводки и переразносит заново. Особенно умиляет уменьшительно-ласкательная форма "джобик".

Читайте про удаление, сторно проводок на форуме.
Читайте про разноску из кода.

Ну, а изменить одно поле, не занимаясь последствиями? Это действительно дело пяти минут. Тут я согласен с Sada.

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

[mazzy]

Цитата:

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

Уйдет слишком много времени... у нас сейчас столько его нет

Что думать?! Трясти надо!

[Antant]

Цитата:

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

В свою очередь, проводки в CustTrans могут быть:
1. переоценены
2. сопоставлены с платежами
3. влиять на прогноз дивжения денежных средств

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

[mazzy]

Цитата:

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

Суммы при переходе с клиента на клиента в этом случае остаются теми же

И что? Проводки то будут другими.

Цитата:

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

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

"планета шелезяка" какая-то...

при чем здесь оплаты по фактурам?
впрочем, как скажете.

[pitersky]

Цитата:

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

Ну, а проводки в LedgerTrans могут влиять... на все что угодно

Гм... А можно поподробнее по поводу? Я как-то думал, что в стандартной аксапте LedgerTrans это хранилище данных для отчётов по ГК и не более того.

[mazzy]

Цитата:

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

Я как-то думал, что в стандартной аксапте LedgerTrans это хранилище данных для отчётов по ГК и не более того.

Так и есть.
А отчеты по ГК ни на что не влияют?

[pitersky]

Цитата:

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

Так и есть.
А отчеты по ГК ни на что не влияют?

Ну это влияние уже выходит за рамки Аксапты