Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ ) - Страница 12 - DAX: Функционал

Jabberwocky · 06.04.2012, 19:56

Цитата:

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

Для исправительных это смысл имеет, но видимо разработчики поленились писать дополнительную логику в зависимости от указанного типа корректировка-исправление и оставили выбор корректируемой строки на откуп пользователю...

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

EVGL · 06.04.2012, 21:44

Еще один дискуссионный вопрос - это принцип подстановки самой первой фактуры для корректировки, когда в форме разноски фактуры по заказу я выбираю "Исправление". Система ничтоже сумняшеся подбирает первую фактуру этого клиента, что есть абсурд. Это притом, что пользователь будет чаще всего пользоваться функций "Создать кредит-ноту", т.е. по лоту возврата и/или сопоставлению можно однозначно понять, что именно он собирается корректировать.

Чтобы подсластить пилюлю: в целом сделано все хорошо, в особенности мне понравилась таблица FactureHeader_RU и способ ее заполнения. Элегантно. Есть, куда подсоединить свой код. Единственно, что "забыли" о том, что все адреса, имена можно менять на уровне заказа, т.е. есть вероятность того, что фактура и накладная покажут разные реквизиты. На практике эта вероятность стремится к нулю. Характерно, что теперь фактуре совершенно плевать на адрес доставки, хотя в предыдущей версии адрес грузополучателя брался именно оттуда. Выпрямили логику грузополучателей, так сказать.

Jabberwocky · 07.04.2012, 12:56

Цитата:

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

Еще один дискуссионный вопрос - это принцип подстановки самой первой фактуры для корректировки, когда в форме разноски фактуры по заказу я выбираю "Исправление". Система ничтоже сумняшеся подбирает первую фактуру этого клиента, что есть абсурд. Это притом, что пользователь будет чаще всего пользоваться функций "Создать кредит-ноту", т.е. по лоту возврата и/или сопоставлению можно однозначно понять, что именно он собирается корректировать.

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

Для примера, см. методы
\Forms\SalesEditLines\Data Sources\SalesParmTable\Methods\initCorrectedInvoiceValues_RU
\Forms\SalesEditLines\Data Sources\SalesParmTable\Methods\setCorrFacture_RU

gl00mie · 07.04.2012, 22:36

Опять куча бизнес-логики на формах, прелестно...

PS. Извините, наболело.

vanokh · 09.04.2012, 05:05

Цитата:

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

Нет, не поленились. Просто немного изменился механизм линковки исходных и корректирующих строк накладных (линки, сделанные старым механизмом новым алгоритмом поддерживаются).

Только строк? А шапки и фактуры по-прежнему в цепочке? Что-то я совсем запутался, пойду разбираться...

vanokh · 10.04.2012, 09:29

Уф, разобрался!

Действительно, теперь строки все на исходную, а шапки по цепочке как и были.
Джоб по заполнению RefOriginalInvoice очень даже полезен)

Мой коммент про "поленились" можно считать бредом )))

EVGL · 17.04.2012, 17:18

С первого апреля у нас появилась еще одна проблема. Как указано в пресловутом постановлении, счета-фактуры по договорам в УЕ должны быть выражены в рублях. Т.е. при ведении задолженности в валюте "УЕ" счет-фактуру надо печатать в режиме "В основной валюте". С поправкой на известную ошибку в копейку (которую в AX2009, как мне сегодня сообщили, исправлять не будут), исходящие фактуры формировать можно.

Проблема пришла с нежданной стороны: системы поставщиков, присылая счета по договорам в УЕ, округляют иногда так же, как и наша Аксапта: как бог на душу положит, от суммы, так что ни при каком фиксированном курсе при разноске входящей накладной/фактуры невозможно добиться совпадения трех величин: суммы задолженности в УЕ, суммы фактуры в рублях и суммы НДС в рублях. Характерно, что даже первые две вывести сложно, поскольку у бухгалтера нет простой возможности отрегулировать рублевую составляющую НДС: НДС считается в УЕ, округляется в УЕ, и в рублях заведомо отличается до 39 копеек.

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

.............
Кстати, беру свои слова обратно по поводу FactureHeader_RU: этот класс не обрабатывает фактуры по ГТД, соотв. строчки в книге покупок остаются безымянными. Типа забыли. Господи, за что такое наказание...

Logger · 24.04.2012, 17:32

Цитата:

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

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

Для примера, см. методы
\Forms\SalesEditLines\Data Sources\SalesParmTable\Methods\initCorrectedInvoiceValues_RU
\Forms\SalesEditLines\Data Sources\SalesParmTable\Methods\setCorrFacture_RU

Редактировать ссылки после разноски накладной все-таки не разрешили.
Жаль.

maldini · 04.05.2012, 12:58

Добрый день.
Ax2009 RollUp 7 установлены все последние патчи кроме тех что идут на RollUp 8

При попытке закрыть книгу продаж возникает ошибка, не найдено значение в карте соответствия.

Посмотрел код, наткнулся на то что есть Map в котором записаны строки из FactureTrans
с ключом [tax,dim,inventTransId,internalInvoiceId,invoiceId,numberSequenceGroupId], а ошибка возникает когда в этом map из журнала восстановления НДС ищутся значения, но вот только ключ из журнала восстановления НДС приходит с пустым inventTransId и конечно возникает ошибка.

Подскажите, что может быть?

Sada · 04.05.2012, 14:43

влепить проверку для начала есть ли такое значение в мапе

maldini · 04.05.2012, 14:50

Я смотрел нет ни одного значения без InventTransId

Sada · 04.05.2012, 14:52

Ну тогда найти место где заполняется этот мап, и поставить if (imventTransId == "") breakpoint; И курить код, почему пусто.

TravellerInTime · 05.05.2012, 09:15

Цитата:

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

Ax2009 RollUp 7 установлены все последние патчи кроме тех что идут на RollUp 8

При попытке закрыть книгу продаж возникает ошибка, не найдено значение в карте соответствия.

Тоже столкнулись с подобным. Насколько я понимаю, чтобы работал русский функционал книг покупок и продаж, необходимо включать "Группировать по номеру лота" в настройках поставщиков - закладка "Главная книга и налог" группа "Книга покупок". Без включения этой галки заставить работать акс без ошибки нам не удалось.

maldini · 12.05.2012, 11:26

Цитата:

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

Тоже столкнулись с подобным. Насколько я понимаю, чтобы работал русский функционал книг покупок и продаж, необходимо включать "Группировать по номеру лота" в настройках поставщиков - закладка "Главная книга и налог" группа "Книга покупок". Без включения этой галки заставить работать акс без ошибки нам не удалось.

Проблемма где то в другом месте, если при закрытии книги продаж в журнале восстановления НДС есть суммы больше 0, то код идет по другой ветке, в которой и возникает ошибка.
Вот фрагмент кода

X++:

while select restoredVATLogTransOper
            where restoredVATLogTransOper.Include
        exists join restoredVATLogTrans
            where restoredVATLogTrans.TransDate             == restoredVATLogTransOper.TransDate            &&
                  restoredVATLogTrans.ProcessLogTransRecId  == restoredVATLogTransOper.ProcessLogTransRecId &&
                  restoredVATLogTrans.InvoiceRecId          == vendTrans.RecId                              &&
                  restoredVATLogTrans.FactureId             == factureJour.FactureId                        &&
                  restoredVATLogTrans.FactureModule         == factureJour.Module
        exists join restoredVATLogTable
            where restoredVATLogTable.TransDate == restoredVATLogTransOper.TransDate &&
                  restoredVATLogTable.Approved
        {
            if (restoredVATLogTransOper.TaxAmount          +
                restoredVATLogTransOper.TaxAmountNotLiable +
                restoredVATLogTransOper.TaxAmountWrittenOff == 0)
            {
                continue;
            }
            key = [restoredVATLogTransOper.TaxCode,
                   restoredVATLogTransOper.Dimension,
                   restoredVATLogTransOper.InventTransId,
                   vendInvoiceJour.InternalInvoiceId,
                   vendInvoiceJour.InvoiceId,
                   vendInvoiceJour.NumberSequenceGroup];
            addRestoredAmounts(SalesBookVATRestoringType_RU::Export);
            addRestoredAmounts(SalesBookVATRestoringType_RU::NotLiableToVAT);
            addRestoredAmounts(SalesBookVATRestoringType_RU::AssetDisposal);

Вот тут если сумма не равна 0 то заполняется Map который потом в цикле проходит, но возникает ошибка так как в строках фактуры не находится ни одно значение без inventTransId, по какой то причине в таблице restoredVATLogTransOper пустой inventTransId

maldini · 12.05.2012, 14:27

Извиняюсь.

Да действительно дело в этой настройке, после того как установлена эта галка "группировка по номеру лота" в параметрах РсП, обработка входящего НДС производится в разрезе лота, и все прекрасно работает.
Но вот только если обработка входящего НДС была произведена без галки, а затем её установить, то в журнал обработки входящего НДС станет вновь как быдто его не обрабатывали. Если же галку убрать все опять вернется
Спасибо!!!

Logger · 20.05.2012, 20:53

Интересный глюк обнаружился при печати корректировочных СФ.
Допустим есть отгрузка :
Номенклатура1, количество 10
Номенклатура2, количество 20
Номенклатура3, количество 30

К ней оформлен возврат
Номенклатура3, количество -30

Т.е. итоговая отгрузка по Номенклатура3 равна 0.

В этом случае при печати корректировочного СФ напечатается фактура, содержащая позиции
Номенклатура1
и
Номенклатура2
с нулевыми изменениями, а Номенклатура3 вообще не будет упомянута. Ошибка воспроизводится именно в случае когда из-за возвратов обнуляется отгруженное количество.

Исправление во вложении.
см. методы
getCorrOrigTrans
GRD_fillDifference

Logger · 20.05.2012, 21:15

Только после исправления обнаружил, что той же цели можно было добиться, убрав вызов

X++:

        if (empty)
        {
            factureTransOrig.delete();
        }

в методе
\Classes\FactureTaxCorrectionEngine_RU\calcCorrections

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

duz · 28.05.2012, 16:58

Подскажите пожалуйста как реализовать исправительную фактуру по цене в закупках?(цена увеличена)
У нас установлено АХ2009 RU8+ xpo - CorrectingFactures_WithID
Имеем исходную накладную на сумму 4720
Выполняем след.действия:
кредит нота на исходную накладную по старой цене и кол-ву(с минусом) -4720
кредит нота на исходную накладную по новой цене и кол-ву(с плюсом) 5900
Обрабатываем 2 накладные для получения корректных бух.проводок
Обрабатываем общую сф на 2 накладные
Обработали входящее НДС - 3 строки

При обновлении строк книги покупок получили неверный результат - 5 строк в книге:
исходную сф со старой суммой 4720
исправительную на 1-ю кредит ноту с 0 суммой ( 4720+(-4720)=0
исправительную на 1-ю кредит ноту с суммой -4720 установлен флаг аннулирование
исправительную на 2-ю кредит ноту с 0 суммой ( 4720+5900=10620
исправительную на 2-ю кредит ноту с суммой -4720 установлен флаг аннулирование

Как получить 3 строки в книге покупок?
4720
-4720
5900

duz · 28.05.2012, 17:00

Подскажите пожалуйста как реализовать исправительную фактуру по цене в закупках?(цена увеличена)
У нас установлено АХ2009 RU8+ xpo - CorrectingFactures_WithID
Имеем исходную накладную на сумму 4720
Выполняем след.действия:
кредит нота на исходную накладную по старой цене и кол-ву(с минусом) -4720
кредит нота на исходную накладную по новой цене и кол-ву(с плюсом) 5900
Обрабатываем 2 накладные для получения корректных бух.проводок
Обрабатываем общую сф на 2 накладные
Обработали входящее НДС - 3 строки

При обновлении строк книги покупок получили неверный результат - 5 строк в книге:
исходную сф со старой суммой 4720
исправительную на 1-ю кредит ноту с 0 суммой 4720+(-4720)=0
исправительную на 1-ю кредит ноту с суммой -4720 установлен флаг аннулирование
исправительную на 2-ю кредит ноту с суммой 4720+5900=10620
исправительную на 2-ю кредит ноту с суммой -4720 установлен флаг аннулирование

Как получить 3 строки в книге покупок?
4720
-4720
5900

vanokh · 29.05.2012, 05:48

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

Похожие темы
Тема	Автор	Раздел	Ответов	Посл. сообщение
Счет фактура по строке общего журнала	Starling	DAX: Функционал	2	28.09.2011 18:31
Счет-фактура по авансовой разнице	Andrux	DAX: Функционал	2	11.04.2011 10:32
Сторно накладных? Счет-фактура с минусом? Проводки по отборочной накладной?	Geo	DAX: Функционал	16	24.11.2010 10:18
Не разносится счет-фактура!	Verena	DAX: Функционал	3	21.11.2008 10:14
DAX 4 SP1 Счет-фактура не может включать различные ставки НДС	Daiver	DAX: Функционал	3	01.10.2007 15:31