|  06.10.2010, 11:06 | #1 | 
| Участник | Не работает корректировка налога в стандартной AX2009 
			
			Попробуйте создать Заказ на продажу, в котором будет 2 номенклатуры т.е. 2 строки, облагаемые налогом. Затем перейдите в Настройка->Налог и откорректируйте общий налог на какую-нибудь сумму. Нажмите кнопку "Применить". Закройте форму корректировки налога. И посмотрите Запрос->Итоги или опять откройте форму корректировки налога и там и там Налог будет уже другой. В классе TaxRegulation в методе saveTaxRegulation вместо X++:         if (taxWorkRegulation)
        {
            taxWorkRegulation.HeadingTableId                = headingTableId;
            taxWorkRegulation.HeadingRecId                  = headingRecId;
            taxWorkRegulation.TaxCode                       = tmpTaxWorkTrans.TaxCode;
            taxWorkRegulation.vatDueDate_W                  = _dateOfVatRegister;
            taxWorkRegulation.VatExchRate_W                 = _exchRateSales;
            taxWorkRegulation.TaxDirection                  = tmpTaxWorkTrans.TaxDirection;
            taxWorkRegulation.ManualInsertedTax             = tmpTaxWorkTrans.ManualInsertedTax;
            taxWorkRegulation.TaxRegulationAmountCur        = tmpTaxWorkTrans.SourceRegulateAmountCur;
            taxWorkRegulation.SourceBaseAmountCurRegulated  = tmpTaxWorkTrans.SourceBaseAmountCurRegulated;
            taxWorkRegulation.SourceRegulateAmount_W        = tmpTaxWorkTrans.SourceRegulateAmount_W;
            taxWorkRegulation.SourceBaseAmountRegulated_W   = tmpTaxWorkTrans.SourceBaseAmountRegulated_W;
            taxWorkRegulation.update();
        }X++: if (taxWorkRegulation) { taxWorkRegulation.HeadingTableId = headingTableId; taxWorkRegulation.HeadingRecId = headingRecId; taxWorkRegulation.TaxCode = tmpTaxWorkTrans.TaxCode; taxWorkRegulation.vatDueDate_W = _dateOfVatRegister; taxWorkRegulation.VatExchRate_W = _exchRateSales; taxWorkRegulation.TaxDirection = tmpTaxWorkTrans.TaxDirection; taxWorkRegulation.ManualInsertedTax = tmpTaxWorkTrans.ManualInsertedTax; // kos 3 - 2009 taxWorkRegulation.TaxRegulationAmountCur += tmpTaxWorkTrans.SourceRegulateAmountCur; // kos 3 - 2009 taxWorkRegulation.SourceBaseAmountCurRegulated = tmpTaxWorkTrans.SourceBaseAmountCurRegulated; taxWorkRegulation.SourceRegulateAmount_W = tmpTaxWorkTrans.SourceRegulateAmount_W; taxWorkRegulation.SourceBaseAmountRegulated_W = tmpTaxWorkTrans.SourceBaseAmountRegulated_W; taxWorkRegulation.update(); } | 
|  | |
| За это сообщение автора поблагодарили: EVGL (3), M.Ruslan (1), raz (5), Кирен (1), Logger (1). | |
|  07.10.2010, 14:00 | #2 | 
| Microsoft Dynamics | 
			
			Зарегистрируйте, пожалуйста, ошибку в службе поддержки, на текущий момент это единственный способ добиться её исправления в текущей версии. Сделать это можно по ссылке: https://mbs.microsoft.com/support/newstart.aspx Дополнительную информацию/контакты можно найти по ссылкам: https://mbs.microsoft.com/partnersou...pport+Contacts (для партнеров) https://mbs.microsoft.com/customerso...ntacts_eng.htm (для клиентов) 
				__________________ You should use Bing before asking dumb questions. | 
|  | 
|  18.11.2010, 15:55 | #3 | 
| Участник | 
			
			Да. Есть еще маленький нюанс. Если в форме корректировки налога кнопку "Применить" нажать 2,3.. раза, то код увеличит откорректированный налог в 2,3.. раза.Т.е. Работает неправильно. Гайку для запрета двойного нажатия кнопки "Применить" я закрутил в самой форме корректировки налога TaxTmpWorkTrans. В методе формы setAllowEdit() в самом конце надо поставить if (taxRegulation.taxRegulationTotal()) Apply.enabled(false); В методе clicked() кнопки Apply в самом конце надо поставить Apply.enabled(false); В методе clicked() кнопки Reset в самом конце надо поставить Apply.enabled(true); Т.е. нажал один раз Применить и кнопка для нажатия больше не доступна. Нажал Сброс - снова доступна. | 
|  | 
|  18.11.2010, 16:15 | #4 | 
| Участник | 
			
			В описании 6-го роллапа как раз было упомянуто про исправление расчета налогов. Вы на какой версии все пробовали ? | 
|  | 
|  25.11.2010, 21:25 | #5 | 
| Участник | 
			
			да, вчера тестировали это на 6-ке все исправлено. Но это вещи, которые нельхзя прощать, люди из-за таких вот ошибок теряют премии.Сколько простите времени прошло от начала продаж 9-ки 5-го роллапа и выпуска 6-го?....
		 | 
|  | 
|  26.11.2010, 11:01 | #6 | 
| Участник | |
|  | 
|  27.11.2010, 20:51 | #7 | 
| Участник | 
			
			да все исправилось, на 6-м роллапе работает корректно
		 | 
|  | 
|  27.11.2010, 21:33 | #8 | 
| Участник | 
			
			Когда вы переходили на RU-6, случайно, не обратили внимание на то, что изменилось в иерархии классов InventSumDate. Просто по теме: Epic Fail Остатки на дату InventSumDateValueReportDim Вроде бы как должна быть ошибка, но у нас она не проявляется. Хотелось бы выяснить что там за причина ошибки и способ её устранения (вдруг у нас ошибка не проявляется не из-за того, что мы такие хорошие, а из-за того, что у нас не было такого сочетания данных, в которых она проявляется). | 
|  | 
|  15.04.2011, 16:50 | #9 | 
| Участник | Цитата: Мы не переходили на RU6. Мы это загрузили на тестовую стандартную базу без модификаций, и я занимался изучением только корректировкой налога. Не только конечно, но именно получением остатков на дату - нет. Хотя меня тоже пугает этот вопрос, может быть и у нас сформируется такая комбинация данных, которую Аксапта не поймет. 
				__________________ -Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. | 
|  | 
|  14.12.2011, 17:15 | #10 | 
| Участник | 
			
			Спасибо, всем за предоставленную информацию. Я тут еще один глюк нашел. Проверял на RU5 и на RU7 с установленным хотфиксом по корректировочной накладной (KB2620178). Похоже при расчете суммы налога по строке заказа - величина налога зависит от других строчек в заказе  Пример : Создаем заказ на продажу. Параметр salestable.inclTax = 0 Создаем 2 строки. 1. Номенклатура 1. Количество 3 Цена 131,84 Чистая сумма по строке 395,52 2. Номенклатура 2. Количество 12 Цена 175,95 Чистая сумма по строке 2111,40 Смотрим Настройка - Налог - по второй строке сумма налога 380,06 Далее удаляем 1-ю строку. Смотрим по второй строке сумма налога 380,05 Т.е. сумма налога посчитанного по номенклатуре 2 зависит от того, есть ли в заказе строки по другой номенклатуре или нет. Похоже что при расчете налогов не затираются внутренние переменные и ошибки округления переходят с одной строки на другую (это только предположение, - ошибку пока не нашел) При тестировании мне встретились случаи когда сумма расхождения по одной строке была не 1 копейка как в этом простом примере, а 21 копейка. Но в таком заказе было много строк, из чего я и сделал предположение о накоплении ошибок округления. Кто нибудь с таким встречался ? Может уже известно исправление ? | 
|  | |
| За это сообщение автора поблагодарили: Pustik (5). | |
|  14.12.2011, 17:41 | #11 | 
| Участник | 
			
			Чего прелесть ?  Скажите хоть глюк воспроизводится или нет. Еще есть слабая надежда, может это я проглючил, а не Аксапта.   | 
|  | 
|  14.12.2011, 17:49 | #12 | 
| Участник | 
			
			В ax 3.0 то же самое.
		 | 
|  | 
|  14.12.2011, 18:32 | #13 | 
| Участник | 
			
			Похоже этой мой глюк. Судя по всему алгоритм расчета пытается скомпенсировать ошибки округления сумм налога в строках. Собирает их все и относит на строку с самой большой суммой. В итоге получается что в целом по документу ошибка округления минимальна. Но по одной строке расхождение может получиться значительным. Например если в накладной 1000 строк, то 0,5 копейки * 1000 = 5 рублей | 
|  | |
| За это сообщение автора поблагодарили: Aquarius (1). | |
|  14.12.2011, 20:16 | #14 | 
| Участник | 
			
			Под рукой с обеда нет Аксапты чтобы проверить. Верю Вам на слово  . Цитата: 
		
			Сообщение от Logger
			   Похоже этой мой глюк. Судя по всему алгоритм расчета пытается скомпенсировать ошибки округления сумм налога в строках. Собирает их все и относит на строку с самой большой суммой. В итоге получается что в целом по документу ошибка округления минимальна. Но по одной строке расхождение может получиться значительным. Например если в накладной 1000 строк, то 0,5 копейки * 1000 = 5 рублей 
				__________________ -Ты в гномиков веришь? -Нет. -А они в тебя верят, смотри, не подведи их. | 
|  | 
|  11.02.2012, 12:02 | #15 | 
| Administrator | 
				__________________ Возможно сделать все. Вопрос времени | 
|  | |
| За это сообщение автора поблагодарили: Pustik (2). | |
|  27.07.2012, 14:15 | #16 | 
| Участник | 
			
			Добрый день. Заметил сегодня еще одну ошибку с налогами. Например, если в заказе 100 строк. Помечаем одну позицию как "Немедленная поставка". Смотрим итоги по заказу, выбрав в поле "Количество" = "Немедленная поставка", видим что Сальдо верное для одной строки, а вот сумма налога все равно рассчитывается для всех открытых строк, соответственно и плывет при этом "Сумма накладной". Разносить не пробовал, но предварительная печатная форма накладной показала тот же неверный результат. (AX2009Ru8) | 
|  | |
| За это сообщение автора поблагодарили: Logger (3). | |
|  27.07.2012, 14:27 | #17 | 
| Участник | 
			
			Вот чертовщина, Дожили до 8-го роллапа и не избавились от детских болезней системы.    | 
|  | 
|  23.11.2012, 15:00 | #18 | 
| Читатель |  Фактуры опасносте 
			
			Вот еще результаты раскопок по этой теме - есть в системе такой класс CalcPostedTaxes_RU. Метод calc: X++: taxCur_* += taxTrans.taxAmountCur_W(); taxBaseCur_* += taxTrans.SourceBaseAmountCur; X++: taxCur_* += taxTrans.TaxAutogenerated ? taxTrans.SourceTaxAmountCur : taxTrans.SourceRegulateAmountCur; taxBaseCur_* += taxTrans.TaxAutogenerated ? taxTrans.SourceBaseAmountCur : taxTrans.SourceBaseAmountCurRegulated; | 
|  | |
| За это сообщение автора поблагодарили: Pustik (5), Logger (10). | |