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

[Logger]

Вот здесь все ссылки есть
http://blogs.technet.com/b/rumicroso...3/3472709.aspx

вторая часть там включена

[Zabr]

Если вы хотите упростить себе жизнь с исходящими сч/фактурами, можно использовать вот этот нюанс. Фактически, под техническую ошибку можно подвести любой случай. А если вы сумеете договорится об этом со своими поставщиками, то и входящие корректирующие счета фактуры вам вводить не потребуется.

Письмо Минфина России от 30.11.2011 № 03-07-09/44. Для исправления технических ошибок корректировочный счет-фактура не требуется.
В соответствии с п. 3 ст. 168 и п. 10 ст. 172 НК РФ корректировочный счет-фактура выставляется покупателю при изменении стоимости отгруженных товаров, в том числе в случае изменения цены (тарифа) и (или) уточнения количества отгруженных товаров, при наличии документа, подтверждающего согласие покупателя на такое изменение.
Если же изменения произошли в результате исправления технической ошибки или арифметической неточности, корректировочный счет-фактуру выставлять не нужно.
Исправления в данном случае вносятся в счет-фактуру, выставленный при отгрузке товара в порядке, установленном п. 29 Правил ведения журналов учета полученных и выставленных счетов-фактур, книг покупок и книг продаж, утвержденных Постановлением Правительства Российской Федерации от 02.12.2000 N 914.

[Logger]

Разбираю последнее обновление по фактурам.
Менюитемы отчетов изменили. Теперь там подложены классы, выводящие отчет в Excel.

От обычных репортов custVendFacture_RU решили отказаться что ли ?

[EVGL]

Угу. По-моему, крыша у кого-то поехала и творцы перестали чувствовать разницу между новым документом и обновлением.

[Logger]

Да не. Штука очень удобная, особенно с учетом того что стандартные отчеты не умеют выгружаться в Excel. Но заменять стандартный отчет наверно все же не стоило.Лучше и то и то оставить.

[Logger]

Вот тут
http://blogs.technet.com/b/rumicroso...3/3472709.aspx
буквально сказано

Цитата:

Вышли новые законодательные изменения по формированию корректирующих фактур и новый формат оригинального счета фактуры для версии Microsoft Dynamics АХ2009

Кто-нибудь может прокомментировать - то что выпущено по новому формату оргинального счета фактуры - окончательная версия или там есть еще нереализованные вещи, по которым будут дальнейшие обновления ?

[Logger]

Добрый день.
При работе лукапа в строках используется запрос
custVendInvoiceTrans::queryCorrectedTrans_RU()

В нем есть условие по SalesParmLine и SalesParmTable c фильтром по статусу - ParmJobStatus::Waiting

Разработчики, подскажите, какой смысл у этого фильтра ?
Это защита от того чтобы одновременно не сделать с разных рабочих мест одну и ту же корректировку ?

Мне показалось что она не всегда корректно работает. Если начать обработку документа, открыв форму SalesEdiLine, указать все корректируемые параметры, а потом отказаться от проведения документа, то при попытке повторной обработки искомые записи в фильтр уже не попадают из-за того что остались записи в parm табличках. Приходится их вычищать. Есть ощущение, что это баг. Либо я не до конца понимаю задумку.

[Jabberwocky]

Цитата:

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

Добрый день.
При работе лукапа в строках используется запрос
custVendInvoiceTrans::queryCorrectedTrans_RU()

В нем есть условие по SalesParmLine и SalesParmTable c фильтром по статусу - ParmJobStatus::Waiting

Разработчики, подскажите, какой смысл у этого фильтра ?
Это защита от того чтобы одновременно не сделать с разных рабочих мест одну и ту же корректировку ?

Мне показалось что она не всегда корректно работает. Если начать обработку документа, открыв форму SalesEdiLine, указать все корректируемые параметры, а потом отказаться от проведения документа, то при попытке повторной обработки искомые записи в фильтр уже не попадают из-за того что остались записи в parm табличках. Приходится их вычищать. Есть ощущение, что это баг. Либо я не до конца понимаю задумку.

Записи в SalesParmLine со статусом ParmJobStatus::Waiting при отмене обработки очищаются, поэтому при повторном заходе в форму обработки соответствующие строки накладных доступны для выбора из лукапа (см. \Classes\SalesFormLetter\cleanupDialog и далее по стеку вызовов). Данный фильтр решает несколько иную проблему - при возникновении ошибки при обработке в SalesParmLine остаются записи со статусом ParmJobStatus::ContainErrors, но этот фильтр как раз позволяет выбрать такие записи повторно, без очистки SalesParmLine. Уточните пожалуйста действия, после которых такие записи остаются заблокированными.

[Daiver]

Заказы на продажу. Создали кредит-ноту штатными средствами. При обработке Накладной на закладке Дополнительно ставим галку Корректирующий документ. Аксапта подвисает на долго
Стал разбираться, дошел SalesParmLine::initCorrectedInvoiceLines_RU() от туда вызывается CustVendInvoiceTrans::queryCorrectedTrans_RU() для формирования query.
Получаем такой запрос:

SELECT FIRSTFAST * FROM CustInvoiceTrans 
	WHERE ((ItemId = N'item1')) AND ((SalesUnit = N'шт')) AND ((TaxGroup = N'НДС')) AND ((TaxItemGroup = N'18')) 
NOTEXISTS JOIN FIRSTFAST * FROM CustInvoiceTrans 
	WHERE CustInvoiceTrans.RecId = CustInvoiceTrans.RefAdjustedInvoiceTrans_RU 
NOTEXISTS JOIN FIRSTFAST * FROM SalesParmLine 
	WHERE CustInvoiceTrans.RecId = SalesParmLine.RefAdjustedInvoiceTrans_RU 
EXISTS JOIN FIRSTFAST * FROM SalesParmTable 
	WHERE SalesParmLine.ParmId = SalesParmTable.ParmId AND SalesParmLine.TableRefId = SalesParmTable.TableRefId AND ((ParmJobStatus = 2)) 
EXISTS JOIN FIRSTFAST * FROM CustInvoiceJour 
	WHERE CustInvoiceTrans.SalesId = CustInvoiceJour.SalesId AND
 CustInvoiceTrans.InvoiceId = CustInvoiceJour.InvoiceId AND CustInvoiceTrans.InvoiceDate = CustInvoiceJour.InvoiceDate AND
	CustInvoiceTrans.numberSequenceGroup = CustInvoiceJour.numberSequenceGroup 
AND ((CurrencyCode = N'RUR')) AND ((RefOriginalInvoice_RU = 5637447983)) 
EXISTS JOIN FIRSTFAST * FROM InventDim 
	WHERE CustInvoiceTrans.InventDimId = InventDim.inventDimId AND ((configId = ' ')) AND ((InventSizeId = ' ')) AND ((InventColorId = ' '))

У всех быстро отрабатывает данный запрос? Может кто-то сталкивался с этой проблемой?

[Logger]

Подниму тему еще раз.
Рассмотрим ситуацию.
(ниже в описании все цены с НДС, как если бы галка salesTable.inclTax взведена, а в фактурах на скриншотах выведены цены без НДС)
Отгружена накладная вариант 1.
1. номенклатура Item 1. Количество 20. Цена 10
2. номенклатура Item 2. Количество 30. Цена 15

Далее пользователи просят исправить её на вариант 2
1. номенклатура Item 1. Количество 20. Цена 12
2. номенклатура Item 2. Количество 30. Цена 18

Потом еще спустя несколько дней они еще раз меняют свою просьбу и хотят получить вариант 3
1. номенклатура Item 1. Количество 10. Цена 13
2. номенклатура Item 2. Количество 20. Цена 19

Как корректно было бы провести документы ?
Мы попробовали следующим образом :
1. Оформили вариант 1.
2. Сделали по нему СФ1.
3. Оформили кредит-ноту, занулив отгрузку.
4. Оформили накладную по варианту 2.
5. Сделали СФ2 сразу по двум накладным (кредитноте из п.3 и накладной из п.4). Пока все красиво печатается в корректировочнй фактуре.
6. Сделали еще одну кредитноту занулив отгрузку.
7. Оформили накладную по варианту 3.
8. Сделали СФ3 сразу по двум накладным (кредитноте из п.6 и накладной из п.7). При обработке счета фактуры указали в качестве корректируемой фактуры - СФ2. (Если попытаться указать СФ1, то Аксапта пошлет - и это правильно)

Но теперь при печати корректирующей фактуры по СФ3 - строки в ней не схлопываются. Т.е. каждая номенклатура повторяется 2 раза. Напрашивается группировка строчек пономенклатурно.
Я уже приготовился вносить исправления, но возникли сомнения, может быть это и правильно ?

вот скриншоты :
(колонки с акцизами скрыты для удобства восприятия)

[Jabberwocky]

Общие принципы следующие:

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

Коррекция цены - через общий журнал ГК с созданием фактуры с типом "Коррекция налога" и распределения суммы коррекции на строки оригинальной фактуры.

При формировании корр. фактуры необходимо указать корректируемый документ, со ссылкой на последнюю коррекцию, выстраивая цепочку коррекций (по сути, система сама будет предлагать последнюю фактуру в качестве корректируемой). При одновременной корректировке и кол-ва, и цены, потребуется последовательно создать две фактуры соот-но с типами "накладная" и "коррекция налогов". Более подробно читайте в документации к обновлениям.

Для данного примера потребуется создать 4 фактуры: Ф1 (ориг.) <- КФ1 (корректировка цены, тип = "коррекция налога") <- КФ2 (корректировка цены, тип = "коррекция налога") <- КФ3 (корректировка кол-ва, тип = "накладная"). Печать КФ3 должна учесть все корректировки при наличии корректных ссылок/распределений налога.

[Logger]

Цитата:

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

Общие принципы следующие:
...
Более подробно читайте в документации к обновлениям.
...

Спасибо.
Вы не подскажете где об этом можно прочитать в документации ?

Перерыли весь сайт на CustomerSource - доступно только описание по 1-й части корректировочных фактур. А также описание по новому формату фактур. Описания по 2-й части корректировочных фактур найти не удалось.

Это только для партнеров ?

[Logger]

Цитата:

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

Общие принципы следующие:

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

Коррекция цены - через общий журнал ГК с созданием фактуры с типом "Коррекция налога" и распределения суммы коррекции на строки оригинальной фактуры.

При формировании корр. фактуры необходимо указать корректируемый документ, со ссылкой на последнюю коррекцию, выстраивая цепочку коррекций (по сути, система сама будет предлагать последнюю фактуру в качестве корректируемой). При одновременной корректировке и кол-ва, и цены, потребуется последовательно создать две фактуры соот-но с типами "накладная" и "коррекция налогов". Более подробно читайте в документации к обновлениям.

Для данного примера потребуется создать 4 фактуры: Ф1 (ориг.) <- КФ1 (корректировка цены, тип = "коррекция налога") <- КФ2 (корректировка цены, тип = "коррекция налога") <- КФ3 (корректировка кол-ва, тип = "накладная"). Печать КФ3 должна учесть все корректировки при наличии корректных ссылок/распределений налога.

Скажите, а с какой целью было сделано такое разделение корректировок отдельно для количества и отдельно для цены ? Это как-то обусловлено требованиями законодательства к документам, журналам документов, книгам покупок и продаж или просто особенности реализации ?

Если последнее, то я считаю, что это слишком жесткое ограничение и лучше было бы от него уйти.

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

2. Обязательное указание дельты приводит к неоправданным трудозатратам. Например, отгрузили товар по неверному прайсу.
Раньше было просто:
а. сторнируем (как правило, это простая операция по кнопке - у всех кто не ленится так сделано на проектах),
б. правим параметр (прайс) в заказе,
в. аксапта автоматом ( !!! ) ставит цены.
г. закатываем заново.

(и подобный алгоритм был практически для любого исправления).

А теперь что делаем ?
а. Смотрим правильный прайс.
б. вычисляем дельты (вручную ( !!! ), либо придется писать инструмент для этого)
в. формируем накладную на услуги, проставляя ссылки построчно ( !!! ) с нужными дельтами.
г. разносим.

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

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

Поэтому, мне кажется, что описанная мною ситуация
Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ )
очень часто возникает на практике (люди могли не сами цены или количества править, а что-нить другое, мало ли параметров в заказе, а изменение количества или цены появилось как побочный эффект .

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

Исправление в XPO. Сделаны с учетом последних изменений :
http://blogs.technet.com/b/rumicroso...0/3476459.aspx

[dgon]

Цитата:

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

Общие принципы следующие:

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

Коррекция цены - через общий журнал ГК с созданием фактуры с типом "Коррекция налога" и распределения суммы коррекции на строки оригинальной фактуры.

При формировании корр. фактуры необходимо указать корректируемый документ, со ссылкой на последнюю коррекцию, выстраивая цепочку коррекций (по сути, система сама будет предлагать последнюю фактуру в качестве корректируемой). При одновременной корректировке и кол-ва, и цены, потребуется последовательно создать две фактуры соот-но с типами "накладная" и "коррекция налогов". Более подробно читайте в документации к обновлениям.

Для данного примера потребуется создать 4 фактуры: Ф1 (ориг.) <- КФ1 (корректировка цены, тип = "коррекция налога") <- КФ2 (корректировка цены, тип = "коррекция налога") <- КФ3 (корректировка кол-ва, тип = "накладная"). Печать КФ3 должна учесть все корректировки при наличии корректных ссылок/распределений налога.

Здравствуйте, возник вопрос по формированию корр. счф при изменении цены: если создавать корр счф на основании корректирующих проводок налога тогда мы скорректируем только проводку по книге покупок, а каким образом корректируются проводки по поставщику и номенклатуре пока не понятно.

[Jabberwocky]

Цитата:

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

Здравствуйте, возник вопрос по формированию корр. счф при изменении цены: если создавать корр счф на основании корректирующих проводок налога тогда мы скорректируем только проводку по книге покупок, а каким образом корректируются проводки по поставщику и номенклатуре пока не понятно.

Отвечу словами наших постановщиков/методологов - текущее законодательство не предусматривает коррекции задолженности по контрагенту или себестоимости номенклатуры при создании корректирующих фактур при изменении цены. К примеру, вы можете корректировать цену товара, которого у вас на складе уже давно нет и за закрытый период.

[Logger]

Цитата:

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

Отвечу словами наших постановщиков/методологов - текущее законодательство не предусматривает коррекции задолженности по контрагенту или себестоимости номенклатуры при создании корректирующих фактур при изменении цены. К примеру, вы можете корректировать цену товара, которого у вас на складе уже давно нет и за закрытый период.

Я не проверял как оно будет работать при коррекции цен для поставщиков, но по идее при разноске строки LedgerJournalTrans с типом Vend должна сформироваться проводка в VendTrans - а это и есть изменение кредиторки. Разве не так ?

[Jabberwocky]

Цитата:

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

Я не проверял как оно будет работать при коррекции цен для поставщиков, но по идее при разноске строки LedgerJournalTrans с типом Vend должна сформироваться проводка в VendTrans - а это и есть изменение кредиторки. Разве не так ?

Так. Только на основании этой операции корр. фактуру с типом "Коррекция налога" вы не сформируете.

[Jabberwocky]

http://blogs.technet.com/b/rumicroso...7/3472996.aspx

Да, похоже ссылка на русскую документацию только на партнерский ресурс. Обратитесь в поддержку, думаю, они вам без проблем ее предоставят.

[Logger]

Коллеги, кто будет поднимать
http://blogs.technet.com/b/rumicroso...0/3476459.aspx
аккуратнее.
Сравнение слоев не показывает отличия в ресурсах, а оно есть.
Глюк утилиты сравнения.

[AvrDen]

Коллеги, добрый день!

Не подскажите где, кроме Parther Sourse можно скачать обновления формирования корректирующих фактур для AX 4.0

http://blogs.technet.com/b/rumicroso...7/3472996.aspx