AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 05.10.2011, 23:57   #21  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
1. Может, стоит все текстовые графы явно хранить в таблице накладной / фактуры (как в международной версии?), а то реквизиты берутся всегда текущие, что не есть хорошо.
2. В фактуре очень бы хотелось видеть информацию о платежках.
3. В накладной количество мест считается от какого-то поля в карточке товара (количество в упаковке что ли). Странно это
4. В идеале бы сделать возможность в авансовой фактуре выводить полноценный список товаров, а не в одно поле всё записывать.
1) См. выше.
2) Принято
3) См. мой пункт о "кол-во мест". В отсутствие модуля WMS количество в упаковке - не такое уж плохое поле, поскольку во внедрениях традиционно не используется, а пустая графа всегда лучше неправильной.
4) Полноценные фактуры, выставленные до отгрузки товара появились только в 2012. Для фактур на предоплаты делать список товаров, если это имеется в виду - это немного overkill. Или секрет твоего предложения заключается в формировании многострочного журнала с одним К и несколькими Д? Тоже жесть, не сделают они нам этого.
Старый 06.10.2011, 10:21   #22  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Цитата:
Сообщение от EVGL Посмотреть сообщение
4) Полноценные фактуры, выставленные до отгрузки товара появились только в 2012. Для фактур на предоплаты делать список товаров, если это имеется в виду - это немного overkill. Или секрет твоего предложения заключается в формировании многострочного журнала с одним К и несколькими Д? Тоже жесть, не сделают они нам этого.
Речь про авансовые фактуры, которые выставляются по авансовому платежу. В стандарте можно выбрать счет на оплату - тогда номенклатура из счета будет добавлена в единственное текстовое поле через запятую. При этом многие клиенты требуют, чтобы по 100% предоплате была фактура с полным списком товаров (в законодательстве про это мутно написано). Можно сделать простую модификацию, чтобы создавались строки фактуры как в счете и выводились на печать. Никаких дополнительных проводок / проверок / обработок не требуется - просто печатная форма.
__________________
Ivanhoe as is..
Старый 06.10.2011, 11:02   #23  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от EVGL Посмотреть сообщение
(не могу больше редактировать свой список вверху)
Добавил к твоим правам модератора возможность модерировать раздел "DAX: Программирование".
редактируй на здоровье.

но технологически такие вещи лучше вести в своем блоге
http://axforum.info/forums/blog.php
__________________
полезное на axForum, github, vk, coub.
Старый 06.10.2011, 11:04   #24  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от lvan Посмотреть сообщение
Гы, ты правда думаешь, что Microsoft будет что-то изменять в старой версии, тем более в отчетах, которых больше не будет?
Не имею права комментировать это. Извините.
__________________
полезное на axForum, github, vk, coub.
Старый 06.10.2011, 11:31   #25  
lvan is offline
lvan
Участник
Аватар для lvan
Лучший по профессии 2014
 
856 / 82 (4) ++++
Регистрация: 15.04.2011
Записей в блоге: 1
Цитата:
Сообщение от mazzy Посмотреть сообщение
Не имею права комментировать это. Извините.
Неужели в российской локализации сохранят старые отчеты?
лучше бы уж темплейты в екселе нарисовали ей богу
Старый 06.10.2011, 11:59   #26  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
Речь про авансовые фактуры, которые выставляются по авансовому платежу. В стандарте можно выбрать счет на оплату - тогда номенклатура из счета будет добавлена в единственное текстовое поле через запятую. При этом многие клиенты требуют, чтобы по 100% предоплате была фактура с полным списком товаров (в законодательстве про это мутно написано). Можно сделать простую модификацию, чтобы создавались строки фактуры как в счете и выводились на печать. Никаких дополнительных проводок / проверок / обработок не требуется - просто печатная форма.
Понял, спасибо. Извини, но боюсь брать это в список. Если сумма счета не совпадает с суммой оплаты (да хоть на копейку), то задача вычисления суммы строки фактуры становится очень нетривиальной. Также будет стремно, если счет в УЕ, а платеж - в рублях.
Старый 06.10.2011, 12:35   #27  
Alexius is offline
Alexius
Участник
Аватар для Alexius
 
461 / 248 (9) ++++++
Регистрация: 13.12.2001
Цитата:
Сообщение от mazzy Посмотреть сообщение
Сейчас уникальность определяется 4мя полями
SalesId, InvoiceId, InvoiceDate, numberSequenceGroup
Уникальность только предполагается на уровне связей, но почему-то не реализована уникальным индексом.
Цитата:
Сообщение от mazzy Посмотреть сообщение
нельзя делать CustInvoiceJour.InvoiceId уникальным
Я за уникальность этого поля и создание отдельного поля для печатных форм по аналогии с документами по поставщикам и фактурам.

PS. Для 2012 это скорее всего будет не актуально.
Старый 06.10.2011, 12:47   #28  
egorych is offline
egorych
Участник
Самостоятельные клиенты AX
Oracle
 
761 / 154 (7) ++++++
Регистрация: 09.11.2006
Адрес: Краснодарский край
Цитата:
Сообщение от EVGL Посмотреть сообщение
Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.
У нас кол-во точечек, черточек и т.п. иногда доходит до 8 !!! Так что хотса что-нибудь более прозрачное, что-ли.
__________________
Axapta 3.0 sp - хз какой, kr2
Старый 06.10.2011, 13:08   #29  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Talking
Цитата:
Сообщение от EVGL Посмотреть сообщение
Что касается InvoiceId, придерживаюсь мнения Mazzy: лучше не наступать на грабли, не ловить колючих ежей и оставлять номер уникальным. Если говорить о моих клиентах, то точечки, черточки и невидимые символы их вполне удовлетворяют.
EVGL, MAZZY - но ведь по сути это вариант 1, предложенный мной :
Цитата:
Сообщение от Logger Посмотреть сообщение
Самым безопасным, простым и дешевым способом на мой взгляд было бы сделать поле CustInvoiceJour.InvoiceId уникальным, а для печати использовать свое кастомизированное поле. Так безопаснее. По крайней мере большинство кода с вышеописанными косяками при этом условии выполняется правильно. Косяк не проявляется.
Ведь, по сути, что вы предлагаете:
а. Сделать поле InvoiceID де факто уникальным, за счет того что номера не повторяются из-за добавления несущественные постфиксы в виде точек, черточек, etc.
б. Сделать добавляемые постфиксы малозаметными для пользователя (точка, черточка), чтобы на печати номера были похожи.

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

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

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

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

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

Последний раз редактировалось Logger; 06.10.2011 в 13:16.
Старый 06.10.2011, 13:11   #30  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Цитата:
Сообщение от Logger Посмотреть сообщение
EVGL, MAZZY - но ведь по сути это вариант 1, предложенный мной...
Или вы во что бы то ни стало хотите избежать модификаций ?
Все верно. Я боюсь другого: Microsoft классифицирует это как новое требование, отложит в долгий ящик и сделает лет через 5. Поэтому я стараюсь быть осторожен в своих желаниях.
Старый 06.10.2011, 13:19   #31  
Logger is offline
Logger
Участник
Лучший по профессии 2015
Лучший по профессии 2014
 
3,867 / 3123 (112) ++++++++++
Регистрация: 12.10.2004
Адрес: Москва
Записей в блоге: 2
Цитата:
Сообщение от EVGL Посмотреть сообщение
Все верно. Я боюсь другого: Microsoft классифицирует это как новое требование, отложит в долгий ящик и сделает лет через 5. Поэтому я стараюсь быть осторожен в своих желаниях.
А, это да.
Соглашусь.

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

Я вообще это обсуждение затеял чтобы определиться как лучше. Можно и вообще не регать - все равно понятно как самим исправлять.
Старый 06.10.2011, 20:08   #32  
Pustik is offline
Pustik
Участник
 
807 / 372 (14) ++++++
Регистрация: 04.06.2004
Полностью присоединяюсь к Alexius, Logger хотя бы потому, что это устраивает и налоговую, и пользователей, и программистов(когда им нужно найти ошибку, допущенную пользователем). А добавленное поле и вывод его на печать это (на мой взгляд) не плохое И НЕ СЛОЖНОЕ решение. В чем может быть беда? Кто объяснит интересно будет услышать?
__________________
-Ты в гномиков веришь?
-Нет.
-А они в тебя верят, смотри, не подведи их.
Старый 17.10.2011, 11:37   #34  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
EVGL, удалось составить некий конкретный перечень замечаний? Хочу включить их в рассмотрение на предстоящей партнерской встрече по локализации.
__________________
Ivanhoe as is..
Старый 17.10.2011, 18:32   #35  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Нет еще, на следующей неделе сделаю. Добавилось еще пунктов. Самое вопиющее - в акте на услуги нет строк.
Старый 18.10.2011, 16:04   #36  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
Там нужно ответить до 20-го. Включу тогда то, что тут на первой странице звучало.
По поводу акта - там же не акт, а бумажка для галочки на тендере
__________________
Ivanhoe as is..
Старый 18.10.2011, 16:42   #37  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Обновил список в начале темы. Надеюсь, он окончательный.
Старый 25.10.2011, 16:52   #38  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Ну что же, запрос 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.
За это сообщение автора поблагодарили: AlGol (2), Pustik (2).
Старый 02.11.2011, 14:17   #39  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Два пункта не подтвердились:
- нельзя на уровне клиента или способа поставки переключаться между старым и новым форматами ТТН (случай самовывоза vs. доставки с экспедитором)
Можно, поскольку для печати ТТН предусмотрено 2 галки - одна для новой и одна для старой.

- Если все номенклатуры относятся к типу Услуга, то в полях грузоотправитель и грузополучатель в счет-фактуре должен ставиться прочерк
Для этого есть параметр в журнале фактур. Лучше бы, конечно, чтобы параметр выставлялся автоматически, но не будем пристрастны.
За это сообщение автора поблагодарили: mnt_dx (3).
Старый 09.12.2011, 17:20   #40  
EVGL is offline
EVGL
Banned
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
4,445 / 3001 (0) ++++++++++
Регистрация: 09.07.2002
Адрес: Parndorf, AT
Обратил свой взор на счет на оплату (жуть) и сразу добавил работы русскому офису:
  • в счете на оплату почему-то показывается адрес доставки вместо адреса плательщика
  • "Накладная акцептован" - без комментариев
  • "Наименование товара (описание выполненных работ, оказанных" - оказанных чего?
  • отсутствует наш КПП
Теги
баг, локализация, накладная, ошибка, печатная форма, счет-фактура

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Уникальный индекс в журнале накладных поставщиков Starling DAX: Программирование 11 14.03.2011 17:02
Расхождение функционала журнала одобрения накладных. PavelM DAX: Функционал 4 22.12.2005 19:03
Ax3.0 SP3 CIS: Журнал накладных и российские договора (ошибка) mpa DAX: Функционал 2 11.10.2004 15:14
Как включить контроль изменений в журнале накладных ? NEO DAX: Функционал 0 17.06.2004 12:30
Одобрение накладных Swetik DAX: Функционал 1 24.11.2003 14:53
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:15.
Powered by vBulletin® v3.8.5. Перевод: zCarot
Контактная информация, Реклама.