|
11.07.2006, 17:21 | #1 |
Участник
|
Глюк автоматическое рассопопоставление
Обнаружил глюк при автоматическом рассопопоставлении.
Если по клиенту есть достаточное большое количество сопоставленных проводок, ну например около 100 и одновременно с нескольких рабочих мест запустить автоматическое рассопопоставление, то могут возникать задваивания и затраивания рассопоставления. т.е. SettleAmountCur в проводке CustTrans уже не в пределах от 0 до AmountCur, а вообще может иметь противоположный знак. Аналогично кривятся поля в таблице CustTransOpen Вследствие такой фигни при попытке сопоставления могут возникать ошибки с сообщением что сумма слишком велика. (Что понятно, так как система при сопоставлении ориентируется на несопоставленный остаток, а он у этих проводок кривой) У нас Axapta 3/0 SP3 База Oracle Как лечить : в методе \Classes\CustVendReversePosting\canBeReversed_RU поставить проверку для переданного _custVendSettlement PHP код:
И еще, судя по всему глюк вызван тем что при разработке не учли версионность оракла, так что под MS SQL все нормально должно быть, глюк не должен проявляться. Для автоматического сопоставления возможность "двойного сопоставления" не проверял, но возможно тоже глючит. У нас не воспроизводилось. Интересно мнение коллег... Последний раз редактировалось Logger; 11.07.2006 в 17:26. |
|
|
За это сообщение автора поблагодарили: chel (1). |
12.07.2006, 11:53 | #2 |
NavAx
|
В сервис паках не исправили. Думаю, и в 4ке - тоже.
Не сталкивались - рассопоставление изначально доступно малому кол-ву пользователей и довольно редкая операция.
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты... |
|
12.07.2006, 15:09 | #3 |
Участник
|
Вопроизводилось дважды на рассопоставлении, за период в два года
Насколько потом мучительно больно восстанавливать корректность трех таблиц (еще и CustSettlement слетает), особенно если рассопоставляют клиентов по маске, да еще ошибку не замечают, и продолжают вести по ним сопоставление Мега-респект за находку |
|
12.07.2006, 15:31 | #4 |
Участник
|
Цитата:
Сообщение от chel
Насколько потом мучительно больно восстанавливать корректность трех таблиц (еще и CustSettlement слетает)
Реально побольше будет. CustTrans CustTransOpen CustSettlement CustVendTransPostingLog_RU LedgerTrans подозреваю что это еще не все... |
|
14.07.2006, 10:09 | #5 |
Участник
|
Цитата:
Сообщение от chel
Вопроизводилось дважды на рассопоставлении, за период в два года
Насколько потом мучительно больно восстанавливать корректность трех таблиц (еще и CustSettlement слетает), особенно если рассопоставляют клиентов по маске, да еще ошибку не замечают, и продолжают вести по ним сопоставление Мега-респект за находку - возможность рассопоставить дана только 2 людям. - повесили проверку на количество рассопоставляемых операций, не больше двух. Это решило все проблемы. При чем мы работаем на чистой 3 без SP |
|
Теги |
ax3.0, баг, сопоставление |
|
Похожие темы | ||||
Тема | Ответов | |||
Глюк с RecId | 20 | |||
Автоматическое резервирование: на тропе войны | 11 | |||
Глюк формы | 9 | |||
Резервирование в заказанных -глюк??? | 1 | |||
автоматическое резервирование с учетом отборочной накладной | 1 |
|