[Yarik.ORG]

Подскажите, пожалуйста, как сделать так, что бы при формировании налоговой накладной автоматически были выставлены:
- "Вид цивільно-правового договору": если услуги, то "Договір надання послуг", если товары, то "Договір поставки";
- Дата договора использовалась от даты создания счет-фактуры, номер договра = номер счетфактуры.
Последний пункт наиболее важный.

Другими словами: надо сделать так, что бы не создавать постоянно все новые договра в справочнике "Договора контрагентов", но использовать в НН данные счет-фактуры.

Использую: 1С:Предприятие 8.2 (8.2.19.130), "Управление торговлей для Украины", редакция 2.3.24.3.

Очень желательно, что бы при этом не пришлось менять типовую конфигурацию.

!

Правила, п.5

Сообщение отредактировал logist - 01.04.15, 12:33

[logist]

Очень желательно, что бы при этом не пришлось менять типовую конфигурацию.

Придется менять типовую конфигурацию, на уровне пользователя этого сделать нельзя.

[Petre]

- "Вид цивільно-правового договору": если услуги, то "Договір надання послуг", если товары, то "Договір поставки";

А если и услуги, и товары?

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

Это можно организовать внешней печатной формой.

[logist]

Это можно организовать внешней печатной формой.

Если выгружают в xml то еще и для этого измененный вариант выгрузки.

[Petre]

Если выгружают в xml то еще и для этого измененный вариант выгрузки.

Совершенно верно. В Бухгалтерии так и делаем. Этот момент опустил, т. к. из Торговли обычно выгружают в Бухгалтерию.

[Yarik.ORG]

А если и услуги, и товары?

Ну даже не знаю. :) У меня всегда либо товары, либо услуги. Может быть тогда будет "Договір поставки та надання послуг" ? :)))

Это можно организовать внешней печатной формой.

Если выгружают в xml то еще и для этого измененный вариант выгрузки.

Спасибо всем откликнувшимся!

Внешняя печатная форма - хороший вариант. Но если учесть, что за пару месяцев нам пришлось использовать три разных варианта налоговых накладных, то легко не уследить за изменениями. А изменения в формате XML могут вообще не анонсировать.
Хороший человек прислал строки для изменения в конфигурации. И там совсем немного надо поменять. Но менять придется при каждом обновлении.

Вот и получается два варианта решения проблемы с разными "плюсами" и "минусами".

I. Внешняя печатная форма:
+ Не надо ничего менять при каждом обновлении;
- Надо разово проделать больше работы по разработке внешней печатной формы;
- Надо делать внешнюю обработку для выгрузки в XML;
- Надо самому следить за изменениями в Налоговом Кодексе.

II. Изменение конфигурации:
- Надо каждый раз вносить правки в типовую конфигурацию сразу после каждого обновления конфигурации;
+ Не надо разрабатывать внешнюю печатную форму;
+ Не надо делать внешнюю обработку для выгрузки XML;
+ Не на столько пристально надо следить за изменениями в Налоговом Кодексе.

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

А что если прявится третий вариант - III. Изменение типовой конфигурации разработчиками этой конфигурации?
Как считаете? Займутся ли они этим? Думаю, было бы очень не плохо иметь возможность определять для каких налоговых накладных использовать как основу договора - счет-фактуру, для других - договор из справочника договоров контрагентов.
Может быть, составить техническое задание на этот счет и отправить в техническую поддержку с просьбой передать разработчикам или напрямую написать разработчикам?

Конечно же, пока можно будет воспользоваться первым или вторым вариантами, но третий куда лучше. Вы согласны?

[logist]

Может быть, составить техническое задание на этот счет и отправить в техническую поддержку с просьбой передать разработчикам или напрямую написать разработчикам?

Вы можете обратиться в поддержку с данным вопросом, если являетесь подписчиком ИТС. Вашу просьбу зафиксируют и всё, если аналогичных предложений поступит n-е число, то возможно это реализуют.
Разработка типовых решений не предполагает внесение изменений по требованию нескольких клиентов.

[Yarik.ORG]

Вы можете обратиться в поддержку с данным вопросом, если являетесь подписчиком ИТС. Вашу просьбу зафиксируют и всё, если аналогичных предложений поступит n-е число, то возможно это реализуют.
Разработка типовых решений не предполагает внесение изменений по требованию нескольких клиентов.

Так и думал. Но благодара данному ресурсу мы могли бы собрать достаточно много действительно желающих такой реализации в новых версиях конфигурации. Я бы даже описал механизм подачи заявки/просьбы, что бы их все зафиксировали.
Возможно, я наивен, но если это не сложно сделать, почему нет?

Сообщение отредактировал Vofka - 02.04.15, 7:57

[logist]

бы даже описал механизм подачи заявки/просьбы, что бы их все зафиксировали.

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

[Petre]

Вот и получается два варианта решения проблемы с разными "плюсами" и "минусами".

I. Внешняя печатная форма:
+ Не надо ничего менять при каждом обновлении;
- Надо разово проделать больше работы по разработке внешней печатной формы;
- Надо делать внешнюю обработку для выгрузки в XML;
- Надо самому следить за изменениями в Налоговом Кодексе.

II. Изменение конфигурации:
- Надо каждый раз вносить правки в типовую конфигурацию сразу после каждого обновления конфигурации;
+ Не надо разрабатывать внешнюю печатную форму;
+ Не надо делать внешнюю обработку для выгрузки XML;
+ Не на столько пристально надо следить за изменениями в Налоговом Кодексе.

Как видно из набора "плюсов" и "минусов", плюсов больше во втором варианте, когда надо менять типовую конфигурацию под себя.
Но, к сожалению, мои "плюсы" и "минусы" могут иметь разный вес и один "минус" может перевесить несколько "плюсов", потому так тоже тяжело судить.

Странные плюсы и минусы у вас.
А если посмотреть с другой стороны:

I. Внешняя печатная форма:
+ Не надо ничего менять в конфигурации при каждом обновлении;
+ Возможно не надо менять ВПФ при каждом обновлении (если обновление не касается формы НН);
+ Меньше работы, чем при изменении конфигурации(!!!);

II. Изменение конфигурации:
- Надо каждый раз вносить правки в типовую конфигурацию сразу после каждого обновления конфигурации;

- Надо делать внешнюю обработку для выгрузки в XML - это при любом варианте.
- Надо самому следить за изменениями в Налоговом Кодексе - это еще зачем???
+ Не надо разрабатывать внешнюю печатную форму - это не преимущество. Это изначальный вариант: либо ВПФ, либо изменения в конфигурацию.

[batlcat]

Плюсы и минусы у каждого свои индивидуальные

Для нужного человеку функционала нужно всего добавить 7 строк кода в конфигурациию
А печатная форма даже если копи пасте большей части из конфигурации несколько сот строк, которые еще через отладку нужно пропустить

Нужно еще убедится что вся эта беда экспортируется в XML и 1СЗвіт

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

Насчет пункта III
Обращения игнорируются
Видимо все усилия брошены на развитие конфигураций с новым интерфейсом

Есть надежда на новый механизм Расширений и сравнений (внешне diff утилиты) в новой платформе 8.3.6

[Petre]

Есть надежда на новый механизм Расширений и сравнений (внешне diff утилиты) в новой платформе 8.3.6

Расширения не поддерживаются в режиме совместимости. Да и перехода на управляемое приложение, похоже, еще ждать и ждать.

[alex1c]

А если просто попробовать переделать запрос по шапке в модуле документа и всего-то проблем.