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

[EVGL]

Цитата:

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

1. Может, стоит все текстовые графы явно хранить в таблице накладной / фактуры (как в международной версии?), а то реквизиты берутся всегда текущие, что не есть хорошо.
2. В фактуре очень бы хотелось видеть информацию о платежках.
3. В накладной количество мест считается от какого-то поля в карточке товара (количество в упаковке что ли). Странно это
4. В идеале бы сделать возможность в авансовой фактуре выводить полноценный список товаров, а не в одно поле всё записывать.

1) См. выше.
2) Принято
3) См. мой пункт о "кол-во мест". В отсутствие модуля WMS количество в упаковке - не такое уж плохое поле, поскольку во внедрениях традиционно не используется, а пустая графа всегда лучше неправильной.
4) Полноценные фактуры, выставленные до отгрузки товара появились только в 2012. Для фактур на предоплаты делать список товаров, если это имеется в виду - это немного overkill. Или секрет твоего предложения заключается в формировании многострочного журнала с одним К и несколькими Д? Тоже жесть, не сделают они нам этого.

[Ivanhoe]

Цитата:

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

4) Полноценные фактуры, выставленные до отгрузки товара появились только в 2012. Для фактур на предоплаты делать список товаров, если это имеется в виду - это немного overkill. Или секрет твоего предложения заключается в формировании многострочного журнала с одним К и несколькими Д? Тоже жесть, не сделают они нам этого.

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

[mazzy]

Цитата:

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

(не могу больше редактировать свой список вверху)

Добавил к твоим правам модератора возможность модерировать раздел "DAX: Программирование".
редактируй на здоровье.

но технологически такие вещи лучше вести в своем блоге
http://axforum.info/forums/blog.php

[mazzy]

Цитата:

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

Гы, ты правда думаешь, что Microsoft будет что-то изменять в старой версии, тем более в отчетах, которых больше не будет?

Не имею права комментировать это. Извините.

[lvan]

Цитата:

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

Не имею права комментировать это. Извините.

Неужели в российской локализации сохранят старые отчеты?
лучше бы уж темплейты в екселе нарисовали ей богу

[EVGL]

Цитата:

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

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

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

[Alexius]

Цитата:

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

Сейчас уникальность определяется 4мя полями
SalesId, InvoiceId, InvoiceDate, numberSequenceGroup

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

Цитата:

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

нельзя делать CustInvoiceJour.InvoiceId уникальным

Я за уникальность этого поля и создание отдельного поля для печатных форм по аналогии с документами по поставщикам и фактурам.

PS. Для 2012 это скорее всего будет не актуально.

[egorych]

Цитата:

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

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

У нас кол-во точечек, черточек и т.п. иногда доходит до 8 !!! Так что хотса что-нибудь более прозрачное, что-ли.

[Logger]

Цитата:

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

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

EVGL, MAZZY - но ведь по сути это вариант 1, предложенный мной :

Цитата:

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

Самым безопасным, простым и дешевым способом на мой взгляд было бы сделать поле CustInvoiceJour.InvoiceId уникальным, а для печати использовать свое кастомизированное поле. Так безопаснее. По крайней мере большинство кода с вышеописанными косяками при этом условии выполняется правильно. Косяк не проявляется.

Ведь, по сути, что вы предлагаете:
а. Сделать поле InvoiceID де факто уникальным, за счет того что номера не повторяются из-за добавления несущественные постфиксы в виде точек, черточек, etc.
б. Сделать добавляемые постфиксы малозаметными для пользователя (точка, черточка), чтобы на печати номера были похожи.

То есть, вы хотите чтобы для пользователя номер выглядел неизменным !
Зачем же мучать себя и людей и ограничиваться полумерами ?

Не проще ли развести идентификатор на 2 :
1. внутренний служебный идентификатор (InvoiceId) - желательно уникальный.
2. внешний идентификатора для печати (для пользователя) - свое локализованное поле.

В фактурах так и сделано.
Внутренний ключ это пара : FactureId, Module
Внешний номер для печати : FactureExternalId

Всем удобно, никто не жалуется. Проблем с этим ни разу не встретили.

Или вы во что бы то ни стало хотите избежать модификаций ?
Чего их бояться-то

[EVGL]

Цитата:

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

EVGL, MAZZY - но ведь по сути это вариант 1, предложенный мной...
Или вы во что бы то ни стало хотите избежать модификаций ?

Все верно. Я боюсь другого: Microsoft классифицирует это как новое требование, отложит в долгий ящик и сделает лет через 5. Поэтому я стараюсь быть осторожен в своих желаниях.

[Logger]

Цитата:

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

Все верно. Я боюсь другого: Microsoft классифицирует это как новое требование, отложит в долгий ящик и сделает лет через 5. Поэтому я стараюсь быть осторожен в своих желаниях.

А, это да.
Соглашусь.

Надо требовать реальные вещи от людей.

Я вообще это обсуждение затеял чтобы определиться как лучше. Можно и вообще не регать - все равно понятно как самим исправлять.

[Pustik]

Полностью присоединяюсь к Alexius, Logger хотя бы потому, что это устраивает и налоговую, и пользователей, и программистов(когда им нужно найти ошибку, допущенную пользователем). А добавленное поле и вывод его на печать это (на мой взгляд) не плохое И НЕ СЛОЖНОЕ решение. В чем может быть беда? Кто объяснит интересно будет услышать?

[mazzy]

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

[Ivanhoe]

EVGL, удалось составить некий конкретный перечень замечаний? Хочу включить их в рассмотрение на предстоящей партнерской встрече по локализации.

[EVGL]

Нет еще, на следующей неделе сделаю. Добавилось еще пунктов. Самое вопиющее - в акте на услуги нет строк.

[Ivanhoe]

Там нужно ответить до 20-го. Включу тогда то, что тут на первой странице звучало.
По поводу акта - там же не акт, а бумажка для галочки на тендере

[EVGL]

Обновил список в начале темы. Надеюсь, он окончательный.

[EVGL]

Ну что же, запрос 111102546177977 ушел в Microsoft. Затаим дыхание.

Цитата:

Hello,

We have compiled a list of the most annoying ‘features’ in Russian invoices, factures, bills of lading etc. Please understand I cannot split the list into 17 separate errors: managing so many requests would be an administrative nightmare. All the issues listed are discovered on the latest Rollup 7 with the Eastern European layer.
The list uses the following notation:
(-) The report does not abide by the Russian law or it leaves parts of the governmentally approved layout empty.
(+) The report ignores some standard AX settings. The report gets less flexible and difficult to use without modifications.
(*) The implementation of the report ignores common accounting praxis in Russia.

1-) The bank connection in all the documents (invoice, facture, invoice for payment, bill of lading, acceptance/service act) is corrupt: spaces are missing, the text field is too short and cut off, the bank city is missing, our INN number is missing. An example of a correct bank connection is provided, see p.18.
A code snippet dealing with this problem is provided in the attachment.

2+) All the 5 documents ignore the payment mode in ‘our bank account’. Regardless of the payment mode the reports show the default bank account from the company information, which is not always correct.

3-) Invoices and bills of lading exhibit a unit code (“t”) instead of the unit text (for example, “тонн”) in the customer language in the fields ‘Total net weight’ and ‘Total gross weight’.

4-) The so-called KPP number must be taken from the consignee in the facture report instead of the primary customer (if the consignee and the customer are separate legal entities).

5+) The management of the consignors and consignees is failed: there is no default consignor in the customer record. Each time the sales specialist have to select it from a list on sales order creation. An even better idea would be to redesign the functionality and use the normal delivery addresses instead of a separate entry in the customer table.

6+) All 5 documents ignore the form setting ‘Print item dimensions’ (AR / Setup / Forms / Form setup)

7+) The form setting ‘External item description’ is ignored. There is no way to achieve the effect of the ‘Overwrite’ option. I.e. one cannot replace the internal item name by the external name in any of the 5 reports.

8+) Print management is not implemented for factures. As a result, it is not possible to print a copy of the facture automatically.

9-) One cannot switch between the ‘old’ and ‘new’ bill of lading formats. The ‘new’ one is used if an external transport company is delivering the goods. The ‘old’ one should be used with the EXW delivery term (the customer uses his own transport). Unfortunately, the hotfix KB2589594 assumes a global parameter for the whole company while it is needed to select the layout on the customer and/or delivery term level.

10*) With the warehouse management module active, our clients expect the number of pallets to be printed in the fields ‘Places’, ‘Total places’ on the invoice and bill of lading. The ‘Qty. in one place’ field should show the number of items on one pallet, respectively.
See a code snippet.

11-) The facture is created from lines of invoice(s). Invoices may have a rounding on the header level. The invoice report compensates for these rounding errors and distributes it over lines. The facture does not. As a result, a facture created 1:1 out of a single invoice may deviate in lines and total amounts from the invoice.

12*) The common praxis in Russia is to print an invoice, a facture and a bill of lading with same numbers for a single delivery. I.e. there must be a mode to inherit the facture and BoL numbers from the invoice.

13-) The ‘Bill of lading’ field on the invoice is always empty even though BoLs can be created automatically on invoice posting.

14+) Should the ‘Shortcut name for parts’ in the monetary unit declensions be empty, do not print the comma in the column headers of invoices and factures.

15-) If a facture consists only of service items, do not print the consignee, consignor names. Replace them with dashes.

16+) The payment reference in the facture report can be filled if there are some settlements for the invoice. Should the facture/invoice be reconciled with several payments, print their numbers and dates in a line separated with commas.

17*) The [service] acceptance act is useless: it doesn’t show any lines, only totals.
See a code snippet.

18-) The service acceptance act is designed badly with regards to long company names / bank connections: any name longer than 255 characters leads to an error in MS Word (‘string is too long…’). Split it into several field/bookmarks, one with the company name, another with the company address, bank account etc.

[EVGL]

Два пункта не подтвердились:
- нельзя на уровне клиента или способа поставки переключаться между старым и новым форматами ТТН (случай самовывоза vs. доставки с экспедитором)
Можно, поскольку для печати ТТН предусмотрено 2 галки - одна для новой и одна для старой.

- Если все номенклатуры относятся к типу Услуга, то в полях грузоотправитель и грузополучатель в счет-фактуре должен ставиться прочерк
Для этого есть параметр в журнале фактур. Лучше бы, конечно, чтобы параметр выставлялся автоматически, но не будем пристрастны.

[EVGL]

Обратил свой взор на счет на оплату (жуть) и сразу добавил работы русскому офису:

• в счете на оплату почему-то показывается адрес доставки вместо адреса плательщика
• "Накладная акцептован" - без комментариев
• "Наименование товара (описание выполненных работ, оказанных" - оказанных чего?
• отсутствует наш КПП