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

[Zabr]

В переданном партнёром XPO - ровно 100 объектов АОТ. Пока поостерегся переносить...

[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

[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

[Logger]

Еще небольшой добавление :
Судя по коду, мы можем задавать ссылки (correctedInvoiceID, CorrectedInvoiceDate) на корректируемый документ только в момент создания корректирующего документа. А как быть, если дрогнула рука и проставила неверное значение ? (будьте уверены, рука рано или поздно дрогнет, пользователям свойственно ошибаться).

Я не нашел штатного инструмента для исправления этих ссылок. Написали свой.

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

[dgon]

Цитата:

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

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

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

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

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

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

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

[Logger]

Проводки по поставщику скорректируются автоматически при разноске LedgerJournalTable/LedgerJournalTrans, по клиенту - при разноске CustInvoiceTable/CustInvoiceLine

InventTrans для отгрузок трогать не надо. А для приходов наверно придется вручную скорректировать.

Кстати, вот еще один аргумент в пользу удобства исправления цен через сторнирование документов. Там себестоимость в InventTrans ляжет автоматом.

[Jabberwocky]

Цитата:

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

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

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

[Logger]

Цитата:

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

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

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

[Jabberwocky]

Цитата:

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

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

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

[Demetrio]

Цитата:

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

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

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

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

Да, было бы здорово если бы по этой ссылке действительно был аттач с .xpo-ником для 4-ки. А так - там те же ссылки на Parther Sourse

[Rezervforall]

хочу огорчить многих...
согласно последнему постановлению правительства счет фактура (форма) снова изменилась.

ПОСТАНОВЛЕНИЕ
от 26 декабря 2011 г. N 1137

обратите внимание на Приложение 2 и на то как расположены изменения. В колонку а не в строку.

http://www.consultant.ru/law/hotdocs/16726.html

[Rezervforall]

Есть повод пообсуждать это еще листов на 7

[Logger]

Цитата:

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

хочу огорчить многих...
согласно последнему постановлению правительства счет фактура (форма) снова изменилась.

Так это уже тут
http://blogs.technet.com/b/rumicroso...0/3476459.aspx
реализовано.

[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]

Создайте индекс по полю
CustInvoiceTrans.RefAdjustedInvoiceTrans_RU
Ну и аналогичный для VendInvoiceTrans

[Logger]

Также не помешает заполнить ссылочные поля по умолчанию:
Например во всех компаниях выполнить такой запрос :

    update_recordSet custInvoiceJour
    setting RefOriginalInvoice_RU = custInvoiceJour.RecId
    where
        custInvoiceJour.RefOriginalInvoice_RU == 0
    ;

Иначе, например, при попытке скорректировать цену при заполнении custInvoiceTable / custInvoiceLine - все сильно подвисает.

[Logger]

Цитата:

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

Также не помешает заполнить ссылочные поля по умолчанию:
Например во всех компаниях выполнить такой запрос :

    update_recordSet custInvoiceJour
    setting RefOriginalInvoice_RU = custInvoiceJour.RecId
    where
        custInvoiceJour.RefOriginalInvoice_RU == 0
    ;

Иначе, например, при попытке скорректировать цену при заполнении custInvoiceTable / custInvoiceLine - все сильно подвисает.

уточнение :
правильнее использовать джоб
Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ )

но если поля corrected* у вас нигде не заполнены, то мой вариант эквивалентен, только работает быстрее.

[vagon]

А нет ли проектика для 3,0?

[Flomik]

Делаю возврат по Заказу на продажу, указываю ссылку на возвращаемую накладную и СФ.

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

Кто-нибудь сталкивался с этой проблемой?