Ошибки в русских накладных, фактурах итп.

[Ivanhoe]

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

[EVGL]

Действительно, и мы это уже сделали для себя.

[propeller]

RU7, обновление с корр. фактурой стоит.
репорт CustVendFacture_RU не изменен на user слое.
печатаю фактуру в которой строк больше чем на 5 листов (например) и ужасаюсь:
1. Не на каждом листе есть шапка таблицы.
2. Некоторые листы пустые, только с одной строкой сверху "Итого по листу"
В чем дело?

[EVGL]

Цитата:

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

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

Как мило, что все мы наступаем на одни и те же заботливо расставленные мины. Предлагаю следующий код, сделано в Австрии:

//BP deviation documented
display str getPaymentInfo()
{
    Object              factureCalcAdj;
    RecordSortedList    rst;
    CustInvoiceJour     invoiceJour;
    CustTrans           custTrans, custTransPayment;
    CustSettlement      custSettlement;
    str                 txt, ret;
    date                d;

    if (classidget(caller) == classnum(FactureCalcAmountAdjustments_RU))
    {
        factureCalcAdj = caller;
        return factureCalcAdj.getPaymentInfo();
    }
    else
    {
        rst = factureJour.invoiceJourSortedList_CustVend();
        while (rst.next(invoiceJour))
        {
            custTrans = invoiceJour.custTrans();
            while select custSettlement
                where custSettlement.TransCompany   == custTrans.dataAreaId
                   && custSettlement.TransRecId     == custTrans.RecId
                   && custSettlement.AccountNum     == custTrans.AccountNum
            {
                while select custTransPayment
                    where custTransPayment.AccountNum   == custSettlement.OffsetAccountNum
                       && custTransPayment.Voucher      == custSettlement.OffsetTransVoucher
                {
                    txt += ((txt ? ', ' : '') + custTransPayment.Txt);
                    d    = max(d, custTransPayment.TransDate);
                }
            }
        }
        ret = strfmt("%1: %2 %3: %4",
                     element.txtInLanguage(literalStr("@SYS2060")), txt,
                     element.txtInLanguage(literalStr("@SYS77627")), d);
    }

    return ret;
}

[EVGL]

Дамы и господа, историю с Номер накладной = Фактура = ТТН они классифицировали как Nice to have, создав предложение на сайте Connect:

Цитата:

Russian functionality- Invoice number= Facture number= Bill of lading number (ТТН)

The requirement is that in accordance with Russian realities should be a possibility to have the same Invoice number= Facture number= Bill of lading number (ТТН), i.e. must be a mechanism of inheritance, control and tracking numbers of Factures, created on the basis of the Invoice.

The Russian law allows for cumulative VAT factures sent up to 5 days after delivery, but nearly nobody does it this way. Having a truck loaded with goods, the obvious procedure would be to print all the 3 documents at once – the invoice (delivery note), the VAT facture and the bill of lading – and give them all to the truck driver. I.e. in most deliveries the invoice equals facture equals BoL.
Keeping this in mind the wish for a single number for all 3 documents, it facilitates the tracking of documents. Even worse, the customers – the recipients of goods - e x p e c t them to be the same.

Убедительно прошу всех заинтересованных проголосовать по ссылке

https://connect.microsoft.com/dynami...-lading-number

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

[EVGL]

Очень хорошо, с 9 голосами мы уже на 7 месте среди всех запросов.

[EVGL]

Ну что, прошло полгода, можно подвести некоторые итоги (Update 29.05.2012):

• все банковские реквизиты выглядят отвратительно во всех документах: не содержат пробелов, обрезаются, не содержат город банка улучшено в самом последнем хотфиксе с фактурами для RU8: KB2677302
• при определении "нашего" банка игнорируется способ оплаты будет в AX2012
• в накладных в графах "итого вес" подставляется код ЕИ вместо текста ЕИ исправлено в KB2702744
• в счете-фактуре КПП берется с плательщика, а не с грузополучателя не нужно - см. ниже
• работать с грузополучателем невозможно, поскольку как минимум нет грузополучателя по умолчанию (как максимум - вся концепция неверна) исправлено в KB2719350! Теперь система реагирует на адрес доставки как на грузополучателя!
• все документы принципиально игнорируют настройку форм "Печать номенклатурных аналитик" исправляют
• настройка "Внешнее описание номенклатуры" игнорируется. Режима "Перезаписать" невозможно добиться никакими настройками. исправлено в KB2707411 с оговорками
• для счета-фактуры не предусмотрено "Управление печатью", и вывести более одной копии невозможно. сделано в AX2012
• если активировано управление складом, то в полях "кол-во мест" и "в одном месте" должно подставляться количество палет и количество штук в одной палете, соответственно думают
• фактура формируется из строк накладной. При наличии округления в заголовке накладной она и фактура расходятся на несколько копеек за счет того, что в накладной округление начинает пропорционально разбрасываться на строки. решения в AX2009 не будет; в AX2012 проблема решена
• в соответствии с русскими реалиями должен быть режим номер накладной = номер фактуры = номер ТТН, т.е. должен быть механизм наследования, контроля и отслеживания номеров СФ, созданных на основании накладной классифицировано как nice to have и выложено в Connect, где благодаря вам, коллеги, был замечен
• в графе накладной "Транспортная накладная" никогда не выводится номер ТТН, хотя мог бы (в режиме генерации ТТН из журнала накладных) будет в AX2012
• Если не заполнено сокращенное наименование частей валюты, то не надо выводить запятую после сокращенного наименования единиц в заголовке таблицы исправлено в KB2710840
• поле "К расчетно-платежному документу" должно заполняться автоматически на основании сопоставлений. Если сопоставлений несколько, то должно выводиться несколько документов с датами через запятую. исправлено в KB2716554
• акт на услуги нежизнеспособный: он не содержит строк классифицировано как nice to have и будет рассмотрено в AX2012
• акт на услуги составлен так, что вывод реалистичного адреса с реквизитами длиной в 300 символов вызывает ошибку "... is too long". исправлено
• проблемы с печатью через Office на Citrix". усердно работают третий год подряд. Окончательного решения нет
• В счете на оплату показывается адрес доставки вместо адреса плательщика, "Накладная акцептован", "Наименование товара (описание выполненных работ, оказанных", отсутствует наш КПП исправлено в самом последнем хотфиксе с фактурами: KB2677302
• ТТН старого образца, сделанный из отгрузки нескольких палет и/или серийных номеров, не суммируется по лоту, в результате чего получается неимоверное количество строк, а из-за ошибок округления ТТН расходится с накладной думают
• Принцип заполнения полей (название компаний, вес) на второй странице ТТН старого образца не выдерживает критики исправляют
• По тому, как в стандарте заполняется новая ТТН, ее можно выбросить в корзину еще не знают

[Firelight]

Цитата:

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

Ну что, прошло полгода, можно подвести некоторые итоги:

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

Это не ошибка. Вот комментарий Минфина:

Вопрос: О порядке заполнения в целях НДС счетов-фактур, выставляемых поставщиками при реализации головной организации товаров (работ, услуг), предназначенных для обособленных подразделений этой организации, а также при реализации товаров (работ, услуг) обособленными подразделениями.

Ответ:

МИНИСТЕРСТВО ФИНАНСОВ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПИСЬМО
от 26 января 2012 г. N 03-07-09/03

В связи с письмом по вопросам заполнения счетов-фактур, выставляемых поставщиками при реализации головной организации товаров (работ, услуг), предназначенных для обособленных подразделений этой организации, а также при реализации товаров (работ, услуг) обособленными подразделениями Департамент налоговой и таможенно-тарифной политики сообщает следующее.
Согласно п. 3 ст. 169 Налогового кодекса Российской Федерации обязанность составлять счета-фактуры, вести журналы учета полученных и выставленных счетов-фактур, книги покупок и книги продаж возложена на налогоплательщиков налога на добавленную стоимость.
Обособленные подразделения российских организаций налогоплательщиками налога на добавленную стоимость не являются. Поэтому в случае, если товары (работы, услуги) реализуются организацией через свои подразделения, счета-фактуры по отгруженным товарам (работам, услугам) могут выписываться этими подразделениями покупателям только от имени организаций. При этом при заполнении счетов-фактур по товарам (работам, услугам), реализованным подразделениями указанной организации, в строке 2б "ИНН/КПП продавца" указывается КПП соответствующего подразделения.
В случае приобретения товаров (работ, услуг) головной организацией для своих подразделений по строке 6б "ИНН/КПП покупателя" указывается КПП головной организации.
Настоящее письмо не содержит правовых норм или общих правил, конкретизирующих нормативные предписания, и не является нормативным правовым актом. В соответствии с Письмом Минфина России от 07.08.2007 N 03-02-07/2-138 направляемое письмо имеет информационно-разъяснительный характер по вопросам применения законодательства Российской Федерации о налогах и сборах и не препятствует руководствоваться нормами законодательства о налогах и сборах в понимании, отличающемся от трактовки, изложенной в настоящем письме.

Заместитель директора
Департамента налоговой
и таможенно-тарифной политики
Н.А.КОМОВА

26.01.2012

[EVGL]

Последняя версия кода (для RU8 + KB 2677302):

\Data Dictionary\Tables\FactureJour_RU\Methods\document

server public container document()
{
    DocumentNum         docNum;
    DocumentDate        docDate;

    FactureTrans_RU     tmpFactureTrans;
    LedgerJournalTrans  ledgerJournalTrans;
    Set                 docNumSet = new Set(Types::String);

    switch (this.FactureType)
    {
        case FactureType_RU::TaxCorrection   :
            if (this.vatTaxAgent && !this.DocumentNum && !this.DocumentDate)
            {
                while select ledgerJournalTrans
                    group by DocumentDate, DocumentNum
                    join tmpFactureTrans
                        where tmpFactureTrans.MarkupRefRecId == ledgerJournalTrans.RecId &&
                              tmpFactureTrans.Module         == this.Module              &&
                              tmpFactureTrans.FactureId      == this.FactureId
                {
                    docNumSet.add(ledgerJournalTrans.DocumentNum);

                    if (docNumSet.elements() > 1)
                    {
                        docNum  = '';
                        docDate = dateNull();
                        break;
                    }
                    docNum  = ledgerJournalTrans.DocumentNum;
                    docDate = ledgerJournalTrans.DocumentDate;
                }
            }
            break;

       // begin
       case FactureType_RU::Invoice:
            [docNum, docDate] = this. getPaymentInfo();
            break;
       
    }

    return [ docNum, docDate ];
}

container getPaymentInfo()
{
    RecordSortedList    rst;
    CustVendInvoiceJour custVendInvoiceJour;

    CustVendTrans       custVendTrans, custVendTransPayment;
    CustVendSettlement  custVendSettlement;

    CustInvoiceJour     custInvoiceJour;
    VendInvoiceJour     vendInvoiceJour;
    CustTrans           custTrans, custTransPayment;
    VendTrans           vendTrans, vendTransPayment;
    CustSettlement      custSettlement;
    VendSettlement      vendSettlement;

    DocumentNum         docuNum;
    DocumentDate        docDate;
    ;

    switch (this.Module)
    {
        case FactureModule_RU::Cust :
            custVendInvoiceJour = custInvoiceJour;
            custVendTrans = custTrans;
            custVendTransPayment = custTransPayment;
            custVendSettlement = custSettlement;
            break;
        case FactureModule_RU::Vend :
            custVendInvoiceJour = vendInvoiceJour;
            custVendTrans = vendTrans;
            custVendTransPayment = vendTransPayment;
            custVendSettlement = vendSettlement;
            break;
        default                     :
            throw error(Error::wrongUseOfFunction(funcname()));
    }

    rst = this.invoiceJourSortedList_CustVend();
    while (rst.next(custVendInvoiceJour))
    {
        custVendTrans = custVendInvoiceJour.CustVendInvoiceJour::custVendTrans(custVendTrans);

        while select custVendSettlement
            where custVendSettlement.TransCompany   == custVendTrans.dataAreaId
               && custVendSettlement.TransRecId     == custVendTrans.RecId
               && custVendSettlement.AccountNum     == custVendTrans.AccountNum
        {
            while select custVendTransPayment
               where custVendTransPayment.AccountNum    == custVendSettlement.AccountNum
                  && custVendTransPayment.Voucher       == custVendSettlement.OffsetTransVoucher
                  && custVendTransPayment.Recid         == custVendSettlement.OffsetRecid
            {
                docuNum += ((docuNum ? ', ' : '') + custTransPayment.Txt);
                docDate = max(docDate, custTransPayment.TransDate);
            }
        }
    }

    return [docuNum, docDate];
}

[EVGL]

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

[Raven Melancholic]

Цитата:

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

После выпуска RU8 разработчики активизировались и закрыли еще 3 проблемы.

А номера KB можно перечислить?

[EVGL]

Цитата:

Сообщение от Raven Melancholic

А номера KB можно перечислить?

См. выше.

[Raven Melancholic]

Цитата:

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

См. выше.

То есть все в одном? Спасибо.

[Ivanhoe]

Цитата:

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

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

Уточните, пожалуйста, это правильный номер статьи? Не могу найти.

[EVGL]

Цитата:

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

Уточните, пожалуйста, это правильный номер статьи? Не могу найти.

Ее еще не выпустили официально.
P.S. Теперь выпустили: KB2719350

[d&m]

Цитата:

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

Ее еще не выпустили официально.
P.S. Теперь выпустили: KB2719350

коллеги,
кому удалось скачать KB2719350? по приведенной в цитате ссылке - скачивается архив, которые при распоковке говорит, что это не едиственная часть архива.

дайте, пжл, ссылку именно на статью на Partnersource, а не на конечный файл.

Также вопрос - я правильно понимаю, что указанный хотфикс не входит в состав Rollup8?


upd: по другим хотфиксам аналогично - не могу найти их на партнерсурсе:
KB2702744
KB2716554
KB2710840
KB2707411

как правильно искать эти хот фиксы на партнерсурсе?

[Pustik]

Цитата:

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

Справедливо! (не могу больше редактировать свой список вверху)
Неоднозначно.
1) Нельзя быть святее папы (Microsoft), а названия компаний, собственное название и т.д. не хранятся в таблицах.
2) Ларец "должностные лица" пока не хочется открывать.

Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.

Извините, что поднял тему. EVGL, очень рад за Вас и Ваших клиентов. А у нас клиенты, отказываются платить просто за то, что в счет-фактуре почтовый индекс и наименование города не поменяны местами. И еще могу кучу вариантов отказа привести. Обосновано все тем, что налоговые органы недовольны.А теперь поди догадайся, правда это или очередная уловка отсрочить платеж?!!!!

[EVGL]

Почтовый индекс и наименование города?! Это же настраивается в формате адресов.

Кстати, через 32 дня в России начинается новая жизнь:
С 2013 года отменят унифицированные формы первичных документов

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

[Pustik]

Цитата:

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

Почтовый индекс и наименование города?! Это же настраивается в формате адресов.

Да знаем мы про форматы, на них все и держится. Я привел частный случай. Встречаются такие моменты, в которых никакой формат адресов не поможет. Я бы не поднимал тему, если бы буквально вчера не занимался идиотизмом. Вот не хочет платить клиент, ну не хочет и все. Напишите ему в разделе грузополучатель : Архангельская контора...., а между почтовым индексом и городом будьте, любезны добавьте всякой хрени, а вот в ТОРГ-12 мы уже Архангельский филиал..... и уберите оттуда лишнюю хрень, да, ну конечно же надо указать где-нибудь склады, куда приедет товар. Да и обязательно напечатайте старую ТТН, конечно же по другому формату. И вот такая переписка длится уже 2 недели. В конце месяца, начальство естественно попросит узнать, почему не поступили деньги от нашего всеми любимого клиента. Да это же бухгалтера не правильно выставляют пакет документов. Ай-яй-яй какие они не хорошие. А судебные издержки лишь дополнительный повод лишить кого-нибудь премии.

[George Nordic]

Цитата:

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

Кстати, через 32 дня в России начинается новая жизнь:

Женя, мы тут в России. Если ты считаешь, что так сделали для удобства людей, то я в этом сомневаюсь. Налоговая может не принять отчет в "непонятном формате". С другой стороны, каждая налоговая может делать свой удобный формат и требовать документы только в нем. Да, незаконно, но поди поспорь. Как-то так.

С Уважением,
Георгий