Немного ОФФ: В каких случаях менять конфигурацию?

У работаю в фирме франчайзи 1С. Многие клиенты меня спрашивали: почему возвраты от покупателей ставит в книгу продаж, а не в книгу покупок, как положено по законодательству. Я обратилась в 1С, мне ответили, что скоро это исправят. А мой начальник говорит, что надо пойти и изменить текст типовой конфигурации, чтобы ставило как надо.
Я против этого по нескольким причинам:
1. Клиенты не очень-то и жалуются на это, в принципе дело решается несколькими способами, например делать не "возврат от покупателя", а "поступление от поставщика".
2. Обновлять измененную конфигурацию гораздо труднее, а обновлять придется мне же.
3. Все равно рано или поздно это исправят, зачем лишний раз корежить конфигурацию.
В связи с этим вопрос: в каких случаях разумно менять типовую конфигурацию, как бы вы поступили в подобном случае и что, интересно, думают про изменение кода типовой в фирме 1с?

"Пункт 1 и является решающим:
- если  клиенту надо - то надо настроить;
- если клиенту не надо - то незачем ему впаривать ненужные настроки.

-------------------------------------
Очень уважаю заботу о клиентах :)"

Сложно обновлять - это, на мой взгляд, не самый главный аргумент. Если ты сделаешь какие-то настройки, а в очередной кнфигурации 1с это исправит, соответственно можно смело обновлять и твоя конфа станет типовой

А вообще - согласен. Если клиенту надо - значит надо сделать. В моем ведении две организации с сильно настроенными базами. У одной - 474 релиз бух, у второй аж 458. И обновить их просто нереально, поскольку от родного 1с-го кода там мало что осталось. При выходе новых изменений проще "выдрать кусок" из нового типового релиза, чем обновлять базу и бояться что-нибудь пропустить. Причем проблем при этом не возникает, так что можно и не обновлять...

Я работаю с 1С 11 лет. Начинал с версии 4 для ДОС. Вел несколько организаций. Вначале менял и приспосабливал под себя программу довольно сильно. Потом меньше. Сейчас не трогаю ничего, что надо будет помнить при обновлении. Все мои коррекции рано или поздно аукались мне.

Кстати, Швед не совсем прав насчет того, что исправленная конфигурация беспроблемно заменит самодельные исправления, даже если они относятся к одному и тому предмету.

Нет, это естественно. Я имел в виду, что такое в принципе возможно (хотя в моей практике такого не встречалось). А коррекции - без них никак, если учет в организации достаточно специфичный. Например, учет оплат поставок векселями в ПУБ - ручными проводками не сделаешь, т.к. взаиморасчеты по регистрам, следовательно надо либо дописывать конфу, либо добавлять свои документы... и т.д. и т.п. Или "а вот я хочу логотип своей фирмы на счете-фактуре. Я вам денег дам, вы только сделайте..." ну как тут не сделать

Даже при специфичном учете есть (не буду утверждать, что всегда) возможность сделать так: типовая часть конфигурации  нетронута, к ней "довешены" дополнения. Обновляется она "чисто" как типовая. Я уже "наелся" с существенно нетиповыми конфигурациямим, долго (несколько лет) их сопровождать и обновлять нерентабельно, мне самому уж точно не рентабельно. Итог обычно печален: клиент "бросается" исполнителем (не только мною, так делает подавляющее большинство исполнителей по прошествии какого-то времени). Уже около года реализую железное правило: не делать так, чтобы конфигурацию нельзя было бы обновить, как типовую. С трудом, но получается. Даже при существенно отличных от типовой требованиях по учету и сервису. Если клиент "упирается" и требует "быстрого " решения с нарушением типовой части конфигурации - выгоднее отказаться от клиента, чем потом иметь "головную боль".