Новые счет-фактура и его друзья - Постановление от 26 декабря 2011 г. N 1137

[epic]

Собственно сабж.
Когда планируется обновление от МС по этому поводу?

[EVGL]

Ну, новый счет-фактура появился в декабре: rumicrosofterp: AX2009: формирование корректирующих фактур, обновление
Правда, теоретики из Microsoft переделали обычную (не корректирующую) фактуру на Excel, что сводит на нет возможные достоинства этого решения. Шаг вперед - два назад.

Сами книги продаж и покупок пока никто не менял. По-видимому, они ждут конца квартала - отчетного периода по НДС, хотя многи готовят книги ежемесячно.

[Ivanhoe]

http://blogs.technet.com/b/rumicroso...0/3476459.aspx

[Jabberwocky]

Цитата:

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

Правда, теоретики из Microsoft переделали обычную (не корректирующую) фактуру на Excel, что сводит на нет возможные достоинства этого решения. Шаг вперед - два назад.

Уточните пожалуйста, в чем конкретно, по Вашему, "сведение на нет возможных достоинств этого решения"? Желательно, по существу, без "философии" в стиле: Корректировочный счет-фактура (ФЗ от 19.07.2011 N 245-ФЗ )

Цитата:

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

По-видимому, они ждут конца квартала - отчетного периода по НДС, хотя многи готовят книги ежемесячно.

Это не более, чем домыслы: rumicrosofterp: Dynamics AX: планы разработки

[EVGL]

Цитата:

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

Уточните пожалуйста, в чем конкретно, по Вашему, "сведение на нет возможных достоинств этого решения"? Желательно, по существу, без "философии"...

Конечно. Начнем с того, что выдача в документы Office в пакетном режиме не работает под версиями Windows, начиная с Vista. Во всей красе это проявляется при работе в терминальном режиме, поскольку терминальные серверы обычно снабжаются Windows Server 2008. Знает ли об этом поддержка Microsoft? Знает. Будет ли это исправляться? Нет. Это не было исправлено за последние 2 года, так и останется. Итак, вы сделали фактуру, которая при определенных, часто встречающихся условиях не может быть напечатана одновременно с накладной.

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

Наконец, не забудем про минимальное, но переучивание пользователей. Будем, конечно, исходить из того, что на всех затронутых компьютерах или терминальных сессиях установлен Office, что в 99,99% соответвует действительности, поэтому брюзжать не буду.

Такие вот дела.

[Jabberwocky]

Спасибо. С этим не могу согласиться:

Цитата:

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

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

Рекомендую ознакомиться с постановлением №1137: http://правительство.рф/gov/results/17759/
Формат корректирующего счета-фактуры (отличный от формата оригинальной фактуры) был основательно изменен, причем, это уже 3-й опубликованный законодателями вариант за последние пару месяцев. Кроме того, было много изменений в правилах заполнения "шапочной" части. Это все отражено в последних обновлениях. Так что добавилось, отнюдь, не "два поля".

[EVGL]

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

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

* если в содержании корр. фактуры есть ошибки, их искать/анализировать все равно придется с нуля, никаких старых инвестиций защищать не надо, обосновать трудозатраты легко

* само появление корректирующей фактуры делает неизбежным дополнительное обучение пользователей

[Jabberwocky]

Ок, задам вопрос иначе. Если бы логика расчета показателей в стандартной фактуре была основательно редизайнена (что по сути и произошло), но канал вывода остался бы тот же - X++ ReportRun - вас бы это устроило? Потому как это единственно возможная альтернатива с учетом планируемых изменений.
К слову сказать, если в фактуре допущена техническая ошибка, корр. фактуры это не требует, но требует т.н. "исправления" (его номер указывается в шапке фактуры).

[EVGL]

Цитата:

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

Ок, задам вопрос иначе. Если бы логика расчета показателей в стандартной фактуре была основательно редизайнена (что по сути и произошло), но канал вывода остался бы тот же - X++ ReportRun - вас бы это устроило? Потому как это единственно возможная альтернатива с учетом планируемых изменений.

Да, это было бы идеально. Такой апгрейд можно было бы сделать за день, а у меня не тряслись бы поджилки от страха, что фактура выдаст стохастический COM-error и пользовательница Наталья потянется к трубке, чтобы разбудить меня в 6 утра по Вене.

[Logger]

Кстати, о птичках.
Похоже исправлять баги ядра при работе с Excel и Word в MS не собираются. Кто-нить пробовал регать запросы по этому поводу ?

Может попробовать. Это уже стало доставать.

[AndyD]

Проблема с COM-ами решаема, причем, на любой версии DAX (ну, по крайней мере начиная с 3.0)

Вспомните про класс ComDispFunction и про ООП

[Logger]

Цитата:

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

Проблема с COM-ами решаема, причем, на любой версии DAX (ну, по крайней мере начиная с 3.0)

Вспомните про класс ComDispFunction и про ООП

Можно подробнее ?
Не понял вашу мысль.

[gl00mie]

Цитата:

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

выдача в документы Office в пакетном режиме не работает под версиями Windows, начиная с Vista. Во всей красе это проявляется при работе в терминальном режиме, поскольку терминальные серверы обычно снабжаются Windows Server 2008.

Да все работает, в т.ч на w2k8 r2, см. Сохранение документа Excel.

Цитата:

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

Проблема с COM-ами решаема, причем, на любой версии DAX

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

[EVGL]

Цитата:

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

Да все работает, в т.ч на w2k8 r2, см.

Не работает. Я подхожу к этому вопросу не как программист с неограниченными ресурсами времени, а как консультант: запустить проект в предельно сжатые сроки с минимальными отклонениями от стандарта.

Разумеется, запросы в Microsoft отправляли. Только от имени моей австрийской фирмы было отправлено два, другие партнеры тоже не оставались в стороне. Мне намекнули, что прямого и окончательного решения, похоже, не будет. Было предложено 2 workaround:
- избавиться от Ghosting (описывалось на форуме, не панацея)
- добавить перед запуском отчета сообщение пользователю, чтобы прервать, так сказать, течение процесса (вроде, помогло, для надежности сделали сообщение на основе Windows-messageBox)

[Logger]

Цитата:

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

- добавить перед запуском отчета сообщение пользователю, чтобы прервать, так сказать, течение процесса (вроде, помогло, для надежности сделали сообщение на основе Windows-messageBox)

А как это может помочь ? Не совсем понятно как вывод messageBox помогает дальнейшему выводу в Excel.

[Logger]

Цитата:

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

Не работает. Я подхожу к этому вопросу не как программист с неограниченными ресурсами времени, а как консультант: запустить проект в предельно сжатые сроки с минимальными отклонениями от стандарта.

Но ведь если проделать эту работу 1 раз, то потом не надо тратить время. Вы же свое решение по производству, которое теперь везде продаете, тоже один раз сделали и потратили существенное время. Так и тут.

[EVGL]

Цитата:

А как это может помочь ? Не совсем понятно как вывод messageBox помогает дальнейшему выводу в Excel.

Ошибка, о которой я говорю, возникает только при печати в Excel-документов в комплекте с другими, друг за другом.

Цитата:

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

Но ведь если проделать эту работу 1 раз, то потом не надо тратить время. Вы же свое решение по производству, которое теперь везде продаете, тоже один раз сделали и потратили существенное время. Так и тут.

Абсурдно встраивать в программу всесторонние решения российских проблем. Наш профиль - внедрение ERP-систем для типографской отрасли, а не исправление ошибок Microsoft. Любой день работы, который мы тратим на такую ерунду - это на день меньше времени на обучение, настройку, анализ особенностей предприятия.

Модераторы, перенесите, пожалуйста в соотв. новую ветку.

[AndyD]

Цитата:

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

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

Нет, этого не требуется

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

Даже отслеживать прямые вызовы нет необходимости

[AndyD]

Вообще, здесь, по-моему, это оффтопик, по-этому предлагаю перенести обсужение в новую тему

[Logger]

Ну про российские проблемы вы погорячились.
Проблeмы с Excel - касаются всех, а не только российскую локализацию.