22.02.2005, 11:02 | #1 |
Участник
|
Такая ситуация:
1) 30.06.2004 приход на склад в количесве 590 шт. себестоимостью 106,44 2) в течении 2004 года расход 578 шт. на себестоимость 104,27 3) проведено закрытие по 31.12.2004 по этой партии товара, закрытие никаких коррекций не сделало. т.е. просто сопоставило без изменения себестоимости. В проводке прихода ()пункт 1 записано: финансовой закрытие - пусто закрытое количество - 578 расчитанная сумма - 104,27 4) в январе 2005 прошел расход двумя проводками на оставшиеся 12 шт на себестоимость 2,17 5) проведен пересчет за январь 2005 В результате пересчета, скорректировалась себестоимость одной из продаж на 1 копеку (наверно из-за округления) и... САМОЕ ИНТЕРЕСНОЕ - скорректировался приход (пункт 1) на туже копейку только с другим знаком!!!! Понятно что: 104,27 (2004) +2,17 (2005) = 106,44 (общий приход) и понятно что раз расход на одну копейку скорректировался то мы уже не выходим на нулевую сумму, но тогда вопрос почему скорректировался приход, а не еще один расход. Итак господа, вопрос: ПОЧЕМУ СКОРРЕКТИРОВАЛСЯ ПРИХОД!!!! |
|
22.02.2005, 19:59 | #2 |
Участник
|
интересный вопрос.
Какая версия? какой сервис-пак? Двухвалютный склад? Физическая разноска установлена? Я правильно понимаю, что фраза "578 шт. на себестоимость 104,27" означает, что аксапта выполнила проводку с общей суммой 104.27? Теперь общие соображения. Аксапта может корректировать приходы. Например, проводки перемещения будут корректироваться, если сумма в исходом приходе имзенилась (например, накладными расходами). Т.е. теоретически такая ситуация возможна. Вы можете протестировать на демобазе и дать пример по демобазе? Заведите новую номенклатуру. Скажите какую группу номенклатуру, группу моделей и складской аналитики вы делаете. Желательно не трогать курсы. Заведите нового поставщика и клиента для чистоты эксперимента. Заведите новую закупку. Скажите какой датой вы делаете закупки и продажи. Тогда и мы постараемся воспроизвести данный эффект. |
|
23.02.2005, 11:36 | #3 |
Участник
|
Договорились. Я сделаю чистейший эксперемент. Все настройки Вам выложу. Все результаты подробно зафиксирую.
|
|
23.02.2005, 11:42 | #4 |
Участник
|
Да. И еще: скорректировались некоторые расходы!!!
|
|
23.02.2005, 15:49 | #5 |
Участник
|
спасибо.
|
|
23.02.2005, 18:48 | #6 |
Участник
|
Уважаемый Mazzy, я подготовил пример как и договаривались. Но мне неохота было выписывать настройки, поэтому я сделал вырезки форм и оформил все в вордовском документе. Базу взял с нуля. Воспроизвел пример, результат получился ожидаемым - проблема осталась. Ох, будет обидно, если это из-за какой-нибудь галочки Убил пол рабочего дня на этот пример Одно но - файл получился 300 кил, поэтому отправляю его Вам на е-мэйл. Очень хотелось бы чтобы Вы посмотрели...
|
|
24.02.2005, 08:16 | #7 |
Участник
|
Спасибо.
Вот этот пример. Постараюсь посмотреть ближе к вечеру. |
|
24.02.2005, 13:47 | #8 |
Участник
|
Вобщем-то разобрались где, что и как считается.
Итак есть класс InventCostItemDim и у него есть метод метод CreateErrorAdjustment. Этот метод исполняется до пересчета расходных проводок. И делает проводку по сопоставлению, на проводку прихода. Сумму для проводки он получает так: сначала пересчет вычисляет следующую дельту для складского прихода (из примера в ворде): дельта = (1009,33/101)*39 - 389,7 дельта = 0,04 (т.е. вычисляется стоимость прихода за единицу, умножается на уже сопоставленное количество, из этого всего вычитается уже сопоставленная сумма) затем вычисляется такая же дельта для каждого складского сопоставления отдельно и суммируется. затем находится разница этих дельт и делается: CreateErrorAdjustment(разница дельт). Говоря по простому, пересчет сравнивает два параметра: 1. Ошибку округления общим скопом (проводка прихода) 2. Суммарную ошибку округления отдельно по проводкам И если они не равны то делает коррекцию прихода. В чем проблема с нашим примером: Вычисляя ошибку округления по проводкам, он каждое полученное значение, перед суммирование округляет, а так как значения там очень маленькие то суммируется каждый раз 0. Сейчас мы "убрали" это округление и пытаемся пересчитать заново. Ждем результата. Если че не понятно - спрашивайте. |
|
24.02.2005, 19:26 | #9 |
Участник
|
Спасибо.
"Убрали округление" - это наверное неправильно. Еще не взялся за разбор. Можно вопросы? Я правильно понимаю, что ошибка округления возможна только до тех пор, пока все количество не будет списано? А при списании всего, что оприходовано, будет еще одна коррекция на -1 копейку? Возникнет ли коррекция, если сразу спишется все оприходованное количество? |
|
24.02.2005, 19:56 | #10 |
Участник
|
Так. Разгрести эту проблему "с наскоку" не получилось. Вы были правы - "убрать округление" не правильно. Хотя это я так просто выразился туманно. Но всетаки - результат получился не тот который ожидался.
Ошибка, очевидно, будет возникать ВСЕГДА!!! Если списать оставшиеся количество и склад не закрывать, он все равно скорректирует приход (так как останется вся таже формула (1009,33/101)*39 - 389,7). Но еще он и скорректирует на туже сумму с другим знаком и последний расход. И даже при закрытии склада он опять споткнется на этом приходе... т.к. я уже говорил что эту процедуру дооценки проходов он делает до!!! сопоставления!!! А следовательно всегда будет выходить сначала на формулу (1009,33/101)*39 - 389,7 !!! Естественно, что он перестанет делать коррекцию, когда все сопоставит ) Ваш вопрос: "Возникнет ли коррекция, если сразу спишется все оприходованное количество?", вроде бы имеет очевидный ответ - "нет". Но я проверил на всякий случай. Если вы имели ввиду сделать такой же приход, и потом сделать расход одной проводкой, то в этом случае ничего не корректируется. |
|
24.02.2005, 20:29 | #11 |
Участник
|
Да.
Странно. Источник странного поведения - понятен. Вроде бы. Непонятно только зачем этот "источник" сделали? В чем его сермяжный смысл? Может чего-то не до конца понимаем? |
|
24.02.2005, 20:30 | #12 |
Участник
|
Цитата:
Сообщение от slava09
Естественно, что он перестанет делать коррекцию, когда все сопоставит )
|
|
24.02.2005, 20:41 | #13 |
Участник
|
"Перестанет делать коррекицю или скорректирует обратно?" - ничего назад не скорректирует!!! Просто перестанет делать коррекцию!!!
Я вообще не понимаю, как это люди живут с такой аксаптой!!! Почему ни у кого не возникло еще таких проблем!!! Почему все молчат!!! Да, я забыл указать Аксапта 3.0 СП 2 билд 9.1 25.12.2003 чтобы это не значило Да... да... да... нужно этот смысл устранить |
|
24.02.2005, 20:44 | #14 |
Участник
|
Цитата:
Сообщение от slava09
Да... да... да... нужно этот смысл устранить
|
|
24.02.2005, 20:45 | #15 |
Участник
|
Цитата:
Сообщение от slava09
Да, я забыл указать Аксапта 3.0 СП 2 билд 9.1 25.12.2003
чтобы это не значило Про билды здесь Версии и билды Аксапты а где у вас пишется "9.1 25.12.2003"? |
|
24.02.2005, 20:50 | #16 |
Участник
|
"а где у вас пишется "9.1 25.12.2003"?" в смысле где?
Справка\О системе Navision Axapta увидел: Российская версия продукта Navision Axapta 3.0 CIS SP2 Build #9.1 on 25.12.2003 Системная версия продукта Navision Axapta 3.0 Build #1951.2410/514-90 SP2/OP023-19 Да... и не скопируешь же... |
|
24.02.2005, 20:54 | #17 |
Участник
|
На сегодня я думаю достаточно. Поехал домой. Надеюсь до завтра что-то умное придет в голову
Желаю и Вам того же |
|
24.02.2005, 21:00 | #18 |
Участник
|
А... ну да. Понял. Спасибо.
Надо попробовать сделать тоже самое на #1951.2410/514-90 SP3/OP023-71 CIS SP3 Build #9.2 on 28.04.2004 |
|
25.02.2005, 14:51 | #19 |
Участник
|
А есть в классе InventCostItemDim такой метод updateReceiptAdjustmentTrans
в котором есть следующий код: <div class='XPPtop'>X++</div><div class='XPP'> [color=:blue]if[/color] (settleValue != 0) { [color=:blue]if[/color] (mapInventTrans && mapInventTrans.[color=:blue]exists[/color](settlementIssue.TransRecId)) issue = mapInventTrans.lookup(settlementIssue.TransRecId); [color=:blue]else[/color] issue = settlementIssue.inventTrans([color=:blue]true[/color]); [color=:blue]if[/color] (! issue.recId) { this.createErrorAdjustment(_receipt,-settleValue); } [color=:blue]else[/color] { [color=:blue]if[/color] (issue.costValue() - settleValue > 0) { errorAmount = issue.costValue() - settleValue; this.createErrorAdjustment(_receipt,errorAmount); settleValue -= errorAmount; } _receipt.costAmountSettled += settleValue; issue.costAmountSettled -= settleValue; issue.costAmountAdjustment -= settleValue; this.updateInventTrans(issue); [color=:blue]if[/color] (settlementReceipt.transDate [color=:blue]==[/color] inventClosing.transDate && settlementReceipt.voucher [color=:blue]==[/color] inventClosing.voucher) { settlementReceipt.costAmountSettled += settleValue; settlementReceipt.update(); settlementIssue.costAmountSettled -= settleValue; settlementIssue.costAmountAdjustment -= settleValue; settlementIssue.update(); } [color=:blue]else[/color] { this.updateSettlementReceipt(settlementReceipt,settleValue); this.updateSettlementIssue(settlementIssue,settleValue); } this.updateTrans(issue,-settleValue); } }</div> так в чем же сермяжная правда этих: _receipt.costAmountSettled += settleValue; issue.costAmountSettled -= settleValue; issue.costAmountAdjustment -= settleValue; или этих строк: settlementReceipt.costAmountSettled += settleValue; settlementReceipt.update(); settlementIssue.costAmountSettled -= settleValue; settlementIssue.costAmountAdjustment -= settleValue; settlementIssue.update(); как мы видим, пара проводок по сопоставлению обновняется, но... приходные проводки не обновляют коррекцию, а расходные обновляют! Где он смысл то? Для меня это еще одна загадка. |
|
25.02.2005, 14:56 | #20 |
Участник
|
Цитата:
Сообщение от mazzy
А... ну да. Понял. Спасибо.
Надо попробовать сделать тоже самое на #1951.2410/514-90 SP3/OP023-71 CIS SP3 Build #9.2 on 28.04.2004 |
|