14.01.2004, 17:00 | #1 |
Участник
|
Сообщение об ошибке
При учете заказа продажи выдается следующее сообщение об ошибке:
Cust. Ledger Entry Но. '132' уже существует. Учетная функция не менялась. Чем может быть вызвана ошибка и как ее исправить? |
|
14.01.2004, 18:07 | #2 |
Участник
|
по Аттейну я могу ошибаться, но это сообщение значит, что вы пытаетесь сгенерировать из модуля Продажи & Клиенты документ. Финансовые проводки с таким номером уже существуют.
войдите в навигатор и сделайте поиск по документу 132. скорее всего у вас уже будут финансовые проводки с таким номером. для того, чтобы решить проблему надо изменить нумерацию для документа, который вы пытаетесь создать. |
|
14.01.2004, 18:32 | #3 |
Участник
|
Несколько уточнений:
Речь идет о таблице Клиент книга операций (Table 21 Cust. Ledger Entry), там уже есть запись с этим номером. Хотя вроде как не должно такого быть, может кто вручную в таблице правил? Не уверен, что в данном случае речь идет о номере документа, скорее о номере операции. Если так, то поиск в навигаторе не даст результатов (или даст неправильные). Лучше все-таки заглянуть в эту таблицу.
__________________
Александр Игнатьев |
|
14.01.2004, 18:47 | #4 |
Участник
|
Выяснилось, что по каким-то причинам при учете предыдущего заказа в Клиент Книга Операций (Table 21 Cust. Ledger Entry) возникла запись, которой не было соответсвия в других регистрах.
Последствия проблемы исправлены, эта строка в Клиент Книге Операций удалена. Причины сбоя остались неизвестны. |
|
14.01.2004, 18:52 | #5 |
Участник
|
Спасибо.
|
|
14.01.2004, 18:54 | #6 |
Участник
|
Спасибо Вам и всем участникам форума.
|
|
14.01.2004, 18:54 | #7 |
Участник
|
На самом деле это серьезно. Принцип целостности данных был нарушен (если это вина Navision)
Надеюсь, что это просто кто-то вручную правил.
__________________
Александр Игнатьев |
|
14.01.2004, 19:00 | #8 |
Участник
|
Никто вручную не правил, это исключено. Работа велась на одном компьютере, в локальной версии.
Я занимался тестированием функциональности применения авансов к заказам, может, там какой баг? Но это так, догадки. |
|
15.01.2004, 02:37 | #9 |
Аксакал в отставке
|
Может быть правили серию номеров? Откатили следующий номер?
__________________
Девочка, никогда не произноси слова только за то, что они такие длинные и красивые; говори только то, что знаешь. (Л.Кэрролл "Алиса в стране чудес"). |
|
16.01.2004, 14:34 | #10 |
Участник
|
в 31 таблице не задается серия номеров, там просто подряд операции идут (1,2,3,4,5...)
__________________
Александр Игнатьев |
|
16.01.2004, 18:24 | #11 |
Участник
|
Серию номеров, во-первых, не трогал, во-вторых, она тут ни при чем.
Все же спасибо за отклик. |
|
17.01.2004, 00:24 | #12 |
Аксакал в отставке
|
А накладную случайно не удаляли?
__________________
Девочка, никогда не произноси слова только за то, что они такие длинные и красивые; говори только то, что знаешь. (Л.Кэрролл "Алиса в стране чудес"). |
|
19.01.2004, 16:43 | #13 |
Участник
|
Накладную не удалял.
Похоже, сбой вызывается следующей последовательностью операций: - учитывается аванс поставщику; - учитывается заказ покупки с нулевой суммой; - учитывается следующий заказ - и обнаруживается нарушение целостности данных. Будет время, еще потестирую. |
|
21.01.2004, 10:51 | #14 |
Участник
|
Это косяк навижена.
Как вы, наверное, знаете, программа, перед тем, как постить проводки в ledger entry, пишет их в фин. журнал. И если сумма в фин. журнале по каким-либо причинам оказывается равной нулю, то проводка не постится (так как смысла в проводке с нулевой суммой нет - не моё утверждение). Это во-первых. Во-вторых, если раньше нумерация операций (но не транзакций) велась для каждой таблички отдельно, то теперь все операции нумеруются на основании соответствующих записей general ledger. То есть, нумеруются записи только в gl, а в остальные таблицы номера просто копируются. Следствие: если вы учитывете документ с нулевой суммой, который формируют записи в нескольких ledger entry, то в gl записи не попадут, но зато попадут в другие таблички. При учёте следующего документа программа опять попытается пронумеровать очередную операцию на основе максимального номера из gl entry и не станет смотреть, что в других ledger entry такой номер уже есть. Мы запостили этот баг в кейсовую систему мелкософт бизнес солюшнз, будем надеяться, что к следующему сп они это исправят. |
|
21.01.2004, 16:06 | #15 |
Участник
|
Да, похоже, все так и есть. Спасибо!
Будем надеяться, что удаляя этот баг, разработчики не внесут в систему два новых. |
|
21.01.2004, 16:12 | #16 |
Участник
|
Можете не надеяться. У Microsoft так не бывает.
|
|