В ИНФИНе имеются так называемые "спецрасчеты" для расчета амортизации. В 1С - типовой функционал. Но ни тот, ни другой изначально нас не устроил по ряду причин (разработчик очень часто забывает о тех нюансах, которые имеют место на тех или иных предприятиях). В итоге мы в ИНФИНе настроили собственные формулы для расчета амортизации (и в 1С - тоже). Вот, к примеру, формулы расчета амортизации в БУ:
Списание в количестве остатка срока полезного использования:
ЕСЛИ(СНМДТ(сч=0100;А1=ВСЕ;А2=101;А3=2;А4=ВСЕ)>0;ЕСЛИ(СКДТКОЛ(сч=0200;А1=ВСЕ;А2=101;А3=2;А4=ВСЕ)>0;1;0);0)
Для суммы:
ЕСЛИ(СНМДТ(сч=0100;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)>0;ЕСЛИ(АН4КТ(1).Норм_ам=0;(СНМДТ(сч=0100;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)-СНМКТ(сч=0200;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)-МОКТ(сч=0200;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ))/МАКС(СКМДТКОЛ(сч=0200;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ);СНМДТКОЛ(сч=0200;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ);1);МИН(СНМДТ(сч=0100;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)/1200*АН4КТ(1).Норм_ам;СНМДТ(сч=0100;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)-СНМКТ(сч=0200;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)-МОКТ(сч=0200;А1=ВСЕ и (А1=1..10 или А1=14);А2=ВСЕ;А3=1;А4=ВСЕ)));0)

Примечание: Срок полезного использования в БУ автоматически пересчитывается в норму амортизации, которая применяется к остаточной стоимости (а не к балансовой).

А вот так она выглядит в НУ для суммы:
ЕСЛИ(СНМДт(сч=0102;А1=ВСЕ;А2=ВСЕ;А3=ВСЕ;А4=ВСЕ)>0;МИН(СНМДт(сч=0102;А1=ВСЕ;А2=ВСЕ;А3=ВСЕ;А4=ВСЕ)*АН4Кт(1).КоэфДорогихОС/АН4Кт(1).СПИ_НУ;СНМДт(сч=0102;А1=ВСЕ;А2=ВСЕ;А3=ВСЕ;А4=ВСЕ)-СНМКт(сч=0202;А1=ВСЕ;А2=ВСЕ;А3=ВСЕ;А4=ВСЕ)-МОКт(сч=0202;А1=ВСЕ;А2=ВСЕ;А3=ВСЕ;А4=ВСЕ));0)

Примечание: Срок полезного испоьзования в НУ автоматически пересчитывается в норму амортизации, которая применяется к первоначальной, а не к остаточной стоимости.

Отличие в способах начисления амортизации, казалось бы, одним и тем же линейным способом, проявляются при модернизациях, увеличивающих стоимость ОС, но не изменяющих срок полезного использования. В БУ срок полезного использования в конечном итоге заканчивается по фактическому истечению заданного числа месяцев СПИ, в НУ же каждая модернизация, увеличивающая стоимость объекта ОС, приводит к отодвиганию момента, когда завершится начисление амортизации, не смотря на то, что формально срок полезного использования остался неизменным.

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

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

В частности, если вдруг ставка НДС станет прогрессивной либо регрессивной, мы создадим новый справочник (назвав его "Шкала НДС") со значениями ставок и базами, для которых они должны применяться, и введем в формулы начисления НДС соответствующие корректировки с динамическим вычислением накопленной базы, сравнением полученного значения с указанной базой в шкале и применением соответствующей ставки. Такое исправление по всей совокупности настроек может быть сделано буквально за 1 день без обращения в ИНФИН.

Сахават совершенно верно акцентировал внимание на возможности клиента самому изменять алгоритмы. Продукт может быть просто великолепным изначально, но если любое изменение требует обращения к разработчику, это не есть здорово. Хорошо, что разработчик готов вносить любые исправления, удовлетворяя любые пожелания любых потребителей продукта, но вот ключевым остается вопрос сроков. Андрей Ж сообщил, что изменения вносятся в течение месяца, но некоторых клиентов такая оперативность по некоторым изменениям может не устроить. У клиента должен быть выбор - либо ждать, когда (и если!) будут внесены изменения разработчиком, либо реализовать их основную массу собственными силами.

Кроме того, пока потребителей относительно немного, разработчик может себе позволить попытаться удовлетворить их всех. Но у разных клиентов требования могут противоречить друг другу, либо противоречить законодательству (но клиент всё равно упертый и требует реализации такой, которая ему представляется правильной - такое тоже бывает). Так что нормальный разработчик, если у него нет намерения утонуть в противоречивых требованиях и пытаться удовлетворить их сразу все, должен уметь фильтовать, что он принимает к переделке, а что не принимает. Кроме того, разработчик, которому даже удастся удовлетворить все требования всех клиентов, неизбежно перегрузит интерфейс чересчур множественными возможностями выбора того или иного варианта расчета, который будет запутывать пользователей и вызывать их раздражение.

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

Андрей Ж, не обижайтесь, я просто постарался быть объективным.