Проблемы украинского add-on (перепост Александр Цыбульский)

[Uukrul]

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

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


Проблемы украинского решения по НДС в SAP
ПРОБЛЕМЫ УКРАИНСКОГО РЕШЕНИЯ ПО
ОГЛАВЛЕНИЕ

• Назначение и цель документа
• Архитектурные соображения по поводу налоговой схемы и использования кодов налога
• Связка документов-оснований и налоговых накладных и структура документа
• Проблемы регистрации входящих налоговых накладных
• Объединение и централизация настроек аддона
• Возможности расширения и BADI
• Прочие проблемы и отсутствующая функциональность
• USABILITY
• Отношение службы поддержки

1. НАЗНАЧЕНИЕ И ЦЕЛЬ ДОКУМЕНТА
Я занимаюсь внедрением САПа уже 7 лет. Почти на каждом проекте (в основном – это «ролауты» для западных компаний) я, так или иначе, сталкивался с т.н. украинским аддоном. У меня накопился определенный опыт работы с этим продуктом и определенное видение его состояния.

В данном документе я хочу изложить основные проблемы решения учета НДС, с которыми я встречаюсь на своих проектах с попыткой обобщить опыт моей работы с адоном и мыслями по поводу «что не так» и как это можно улучшить.
Цель: привлечь внимание к существующим проблемам и, по возможности, предложить свое видение их решения.

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

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

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

Этттт точно, причем одна заплатка делает одно исправление, но вносит две новые проблемы  :-\

Ряд проблем касается так называемого «usability» - логичности и удобства работы с пользовательским интерфейсом решения. Эти проблемы могут показаться надуманными и мелкими, но, на самом деле, для пользователя, который каждый день работает с программой, они определяют его отношение к продукту в целом (т.к. пользователи часто не разделяют сап на модули). И потом по рынку идут рассказы про страшно неудобную систему, непокрытые, по сравнению с 1С-ом процессы и пр. Иными словами, проблемы конкретного кусочка вредит имиджу продукта (SAP ERP) в целом. Я присутствовал на совещаниях, где аргументы «САП плохо поддерживает укр специфику» и «бухгалтера жалуются на удобство работы с программой» воспринимались весьма серьезно в контексте вопроса о внедрении.

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

Зря надеешься, вот к примеру, последняя моя просьба в SAP исправить проблему, причем я указал место, где и что и почему надо исправить, ну там вообще была синтаксическая ошибка использования оператора BETWEEN, так вот на это мне было заявлено, что это работает в сотнях компаний и вообще посоветовали обратиться к своему консультанту SAP, если я не могу понять как это работает. И ведь действительно работает, точнее все жрали этот кактус, кололись больше полутора лет из-за этой проблемы, а когда пользователи спрашивали у консультантов почему так, и говорили, что так не правильно,им отвечали, вы ничего не понимаете так просто работает SAP и это правильно. Так что пока надеяться особо не на что.

2. АРХИТЕКТУРНЫЕ СООБРАЖЕНИЯ ПО ПОВОДУ НАЛОГОВОЙ СХЕМЫ И ИСПОЛЬЗОВАНИЯ КОДОВ НАЛОГА

• Сомнительная необходимость 3-го уровня кодов налога
• Выравнивание счета «неподтвержденного» НДС
• Обороты НДС для отчета о ПиУ
• Расхождение сути бухгалтерских проводок и значения кода налога для отчетности
• Код налога для услуг и ОС

В первую очередь хочу коснуться такого концептуального вопроса, как налоговая схема и коды налога. Моя исходная предпосылка – набор кодов и их функции должен быть понятен и логичен. Для работы аддона сейчас необходимо слишком большое количество кодов. В них легко запутаться, а назначение части лишено бизнес смысла. Например, коды 3-го уровня из налоговых цепочек не несут никакой смысловой нагрузки.
Разъясню: типичная цепочка состоит из 4 кодов – Т1 – Т2 – Т3 – Т4

• Т1 – используется при проводке основной операции (прихода или продажи)
• Т2 и Т3 – для проводки налоговой накладной
• Т2 и Т4 – для проводок корректировки
• Т2 – символизирует «подтвержденный» НДС, попадает в реестр и в декларацию
• Т4 – символизируется корректировку и попадает отдельно строкой в декларацию, для реестра он не нужен (на мой взгляд признак корректировки можно из извлекать по-другому нежели дополнительным кодом, но об этом можно спорить)

Зачем код Т3? Он не несет никакой бизнес нагрузки. Просто технический код, чтобы провести сумму НДС по корреспондирующему счету? Слабое техническое решение. Корреспондирующий счет прописан в коде операции (Т1) – зачем его дублировать. При создании НН документ-основание находится, так сказать, в контексте обработки и его данные легко могут быть использованы.

Правильней использовать только Т2 (и Т4 для корректировки) с одной стороны проводки, а счет для второй стороны извлекать из документа-основания и использовать непосредственно. База НДС может указываться в строке самого НДС (есть такая техническая возможность). Причем целесообразно было бы сразу выравнивать сумму НДС на счете «неподтвержденного» НДС. Кстати, именно так работает российский аддон, решение, мне кажется, более удачным, логичным и удобным.

Еще одно соображение по поводу нелогичности использования кодов цепочки в текущем решении. Повторюсь: с точки зрения процесса код в документе-основании символизирует неподтвержденный НДС без налоговой накладной (как входящей так и исходящей), а код Т2 – символизирует подтвержденную налоговой накладной сумму. Следовательно, логично, чтобы код Т1 формировал проводку на счет «неподтвержденного НДС» (так и происходит), а Т2 – проводку на счет «подтвержденного». Однако это не совсем так. Для входящего процесса так и происходит. Но для исходящего почему-то наоборот – Т2 содержит счет неподтвержденного НДС, а Т3 (который, как я показал, ничего не символизирует с т.з. отчетности) настроен на «подтвержденный». Разрыв шаблона – с точки зрения бухгалтерских проводок код значит одно, а с точки зрения «попадания» суммы в реестр налоговых накладных – другое. Возможно, «архитекторы» сделали это, чтобы сохранить логику «2 код из цепочки по дебету, третий по кредиту» - я не могу придумать другого обоснования. Но такая логика не релевантна. Если код попадает в отчетность как подтвержденный – его сущность со стороны проводок
должна быть аналогична.

Второй случай неэффективного раздувания количества кодов – это формирование оборота по НДС для отчета о прибылях и убытках. Как известно, украинская «традиция» проводок подразумевает проводку на счет дохода брутто суммы с НДС, а затем, выделение НДС на счет НДС. В САПе же на счет дохода проводиться нетто сумма. Решение – добавить 2 технических условия на код налога (ZUD, ZUK), которые «наматывают» этот оборот и которые затем можно использовать в финансовой отчетности для увеличения оборотов по соответствующим статьям. Решение в целом неплохое, если бы не ряд нюансов:

• для предоплат обороты не нужны – это не доход
• также не нужны обороты для «прочих» продаж, которые не отображаются на 70-м счете
• также следует разделять обороты НДС по продажам и возвратам т.к. это разные статьи отчета о ПиУ

Эти факторы порождают необходимость добавления дополнительных кодов для предоплат, дополнительных кодов для прочих продаж и возвратов. Как следствие, увеличивая неразбериху в кодах и повышая затраты и сложность настройки сбытовых процессов в модуле SD, где это все различные процессы. А ведь все эти случаи с точки зрения учета НДС ничем не отличаются. А кодов получается минимум 4 (продажа, предоплата, возврат, прочее). Не высока ли цена для появления в отчете строчки, которую и так зачастую можно посчитать, поделив оборот по 70-му счету на 5 (20% НДС)?

Безусловно, эта проблема в какой-то мере консалтинговая – в рамках конкретного проекта можно принять решение не считать обороты по НДС. Но можно было бы и подумать о более абстрагированным от кодов налога решении. Один из вариантов – рассчитывать оборот отдельной программой при подготовке баланса.

Другой вариант – использование условия на строке расчета в налоговой схеме (есть там такое) – условие должно анализировать операцию и определять нужно ли для конкретного случая проводить эти самые обороты или нет – такое решение в стандартной поставке могло бы упростить решение т.к условия, насколько мне известно, не могут быть добавлены клиентом, а создаются только самим САПом (возможно я ошибаюсь), рисунок uk1.png

Еще одна ситуация (эта правда более спорная т.к. есть аргументы и в ее пользу) – это выделение отдельных кодов для основных средств и услуг. Операции с ОС отдельным образом отражаются в приложении 5 к декларации НДС и больше ничем не отличаются. Для услуг по другому печатается налоговая накладная – количество в строке НН «послуга» и единица изменения «грн» - и больше ничем код не отличается. Возникает вопрос, стоит ли использовать для этого отдельный код, ведь и признак услуги и признак основного средства в принципе можно вытянуть с документа-основания.


3. СВЯЗКА ДОКУМЕНТОВ-ОСНОВАНИЙ И НАЛОГОВЫХ НАКЛАДНЫХ И СТРУКТУРА ДОКУМЕНТА

• Связка через текст заголовка
• Нелогичное использование полей финансового документа
• Множество строк в НН
• Концепция налогового события

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

• Критическая проблема – скорость. Все отчеты аддона работают крайне медленно, причем тем медленнее, чем больше налоговых накладных. Это заметно уже через несколько месяцев после запуска проекта. Проблема критична. Медленная скорость раздражает пользователей, приходится искусственно ограничивать выборки датами и другими параметрами, что иногда идет вразрез с бизнес требованиями (например, задача отслеживания неполученных налоговых накладных – по  определению подразумевает выбор всех данных за значительный период). Причина очевидна – текст заголовка не индексируемое поле, к тому же ссылка на документ-основание представляет собой составной ключ. Это поле не предназначено для такого использования – все варианты оптимизации будут полумерами.
• Разнится подход формирования ссылки – то ссылка должна быть на документ основание, то на корректируемую налоговую (причем ссылки на документ основание в таком случае вообще нет). Это все непрозрачно и путает пользователей, особенно в случае формирования НН вручную (а случаев таких достаточно).

Или, например, прописывание договора в текст второй строки налоговой накладной. А почему не в первую? Ах да, там же текст, который попадет в печатную форму в строку. Но ведь это надо постоянно помнить! А ведь договор – это атрибут всего документа, то бишь заголовка, почему он находится в строке? Почему в каждой? Почему в поле текст? Это все так не логично и не user-friendly. А это заполнение через символ «^»! И не вмещающиеся в 50 символов атрибуты договора, который может иметь достаточно длинное название и номер.

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

Еще одно архитектурное ограничение – это формирование пары строк проводок для каждой строки налоговой накладной. В чем смысл? Нет, я понимаю, что в текущем решении у нас есть код налога Т3 (см. предыдущий раздел), который нужно поставить для того чтобы вообще сформировать проводку по НДС. Но вторая строка не несет никакой смысловой нагрузки в отличие от первой, в которой указаны материал, количество и отчетный код налога. Вторая строка вполне могла бы быть единой для всего документа или группы строк, объединенных одним кодом НДС. Дополнительный аргумент – это максимальное количество строк в налоговой накладной, Который по факту ограничивается ~490 строками. Случай не частый, но я встречал компании, у которых сбытовые заказы содержат более 500 строк. Соответственно, налоговые накладные для таких случаев надо разбивать, что во-первых некорректно точки зрения законодательства, во-вторых кроме как вручную это не сделаешь – программа генерации НН не поддерживает – а с таким количеством строк это огромные затраты времени и риск ручных ошибок. Между прочим, большие документы нагружают базу данных. В, скажем, сбытовых документах для этого предусмотрены механизмы уплотнения проводок, а в НН получается 1000 строк. Признаю, что данное соображение несколько противоречит предложенному в предыдущем разделе выравниванию неподтвержденного счета НДС, что автоматически порождает строку проводки, но мне кажется, что выход есть.

Вариант решения

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

В идеале должно быть введено понятие налогового события, связанного с документом-основанием, имеющий свой заголовок с нужными полями, имеющего строки, непосредственно используемые для печати. Финансовый документ будет в таком случае играть чисто бухгалтерскую роль. Что уменьшит его размер и позволит урегулировать упомянутое мной противоречие между выравниванием счета неподтвержденного НДС и количеством строк в документе. Для выборок будут использованы предназначенные для этого поля, которые можно будет покрыть индексами и скорость работы с отчетами увеличится многократно. Идеально также было бы встроить налоговую накладную в поток документов (relevant document browser в меню Environment) т.к. часто просматривая документ у бухгалтера может возникнуть вопрос, выписана/получена ли по нему налоговая. Сейчас для этого приходится лезть в отдельный отчет, а так будет интуитивно и логично.

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

Понимаю, что приведенное решение подразумевает достаточно серьезную разработку. Но ведь и озвученные проблемы по-другому не решаются! Может быть сделан промежуточный вариант в виде отдельной таблицы для начала только для заголовков налоговых накладных с такими данными:

Так это и есть отдельная сущность заголовок - позиции

• ссылка на финансовый документ НН
• на документ-основание (для ускорения выборок)
• раздельными полями с данными договора
• полем для месячного номера НН
• ссылки на корректируемую НН для корректировок
• названия метода платежа (еще одно поле заголовка, печатаемое в НН)
• ссылки на контрагента для ускорения выборок
• и прочими полями.

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

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

Отдельную таблицу для строк НН можно реализовать позже или не реализовывать совсем (хотя ряд проблем
тогда останется).

Да ладно нужно просто изначально продумать архитектуру и реализовать ее, а не делать ублюдочное решение с дальнейшими костылями, тут лучше день потерять, потом за пять минут долететь, чем что-то склепать и потом годы страдать, Кстати, Александр вы спрашивали там вначале почему так работает украинский аддон, так я вам скажу, что его как раз и делали по принципу, что-то прикрутим, потом исправим. Результат вы видите!!!

4. ПРОБЛЕМЫ РЕГИСТРАЦИИ ВХОДЯЩИХ НАЛОГОВЫХ НАКЛАДНЫХ

• Импорт ТМЦ и услуг нерезидента
• Отслеживание неполученных налоговых накладных, статусы в J1UFRON
• Процесс регистрации НН и его неудобство

Отдельного обсуждения заслуживает процесс регистрации входящих НН. Отчеты и программы по генерации входящих НН практически не изменялись уже на протяжении 7 лет (с момента моего знакомства с САПом) хотя нельзя сказать, что там нет проблем и непокрытых требований законодательства. Например, импорт ТМЦ и услуг нерезидента – это полностью ручные операции в системе, хотя, как мне кажется, доработать их авто-создание совершенно не сложно. Напомню:

• Функция авто создания генерирует накладные для импорта в валюте (что неправильно)
• Налоговая накладная на импорт фактически должна содержать проводку между счетом подтвержденного НДС и контрагентом-таможней, что никак не реализовано, хотя технически не должно быть проблемы указать контрагента-таможню в какой-то настроечной таблице
• Для услуг нерезидента должны формироваться 2 налоговые накладные – на налоговые обязательства в текущем периоде и на налоговый кредит в следующем.

Критике хочу подвергнуть старый отчет по просмотру документов оснований и связанных с ними НН – J1UFRON. Кроме того, что отчет очень медленный благодаря связке документов через текстовое поле заголовка, он еще и достаточно неинформативен:

• В частности, желтый статус документа может означать совершенно разные вещи, что затрудняет анализ:
  что документ НН не проведен (запаркован),
  что документ НН не совпадает по сумме с документов основанием – требует внимания бухгалтера, потенциальная ошибка
  что документ НН был запаркован, а теперь удален (это что, равносильное предыдущим событие?)
• Плохо поддерживается разделение на первое/второе налоговые события. Отчет с некоторых пор умеет анализировать выравнивания, но в рамках одной группы документов разобраться не всегда легко – что выравнивание, что предоплата, что проведенная НН, а что удаленный запаркованный документ – можно определить по отдельным признакам или провалится в документ, но это очень не наглядно. Гораздо лучше, например, в этом смысле отображает данные новый отчет по исходящим налоговым накладным – J1UFRVN_NEW

Неудобен процесс регистрации входящей налоговой. В отличие от исходящего процесса, с которым все в целом неплохо. Модуль автопарковки НН автоматически создает НН для всех входящих документов, не разбирая их на первое/второе события. Соглашусь, без выравнивания это сделать сложно и не целесообразно. Но тогда зачем их вообще создавать автоматом? Почему бы не совместить анализ документов и создание НН в едином интерфейсе? Доработать J1UFRON таким образом, чтобы можно было выбрать нужный документ-основание, нажать кнопку создать и НН бы сформировалась к проводке или, как вариант, запарковалась с автоматическим переходом к изменению этого документа. Для групп выровненных документов в таком случае можно автоматически подсчитать сумму НН, а не править ее руками, как сейчас. Для случаев 100% предоплаты НН вообще создавать не нужно (тогда как сейчас она все равно паркуется и ее нужно удалять, а заголовок запаркованного документа в системе продолжает висеть и слегка усложнять аналитику). Это был бы крайне удобное, логичное и потенциально не сложное развитие текущего функционала.


5. ОБЪЕДИНЕНИЕ И ЦЕНТРАЛИЗАЦИЯ НАСТРОЕК АДДОНА

• Роль и значение кодов налога
• Цепочки кодов налога
• Глобальные настройки БЕ
• Типы документов

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

Например, вот скриншоты программ печати НН, корректировочной НН и реестра НН, рисунок uk2.png:

Ведь это однообразные и зачастую значащие одно и то же настройки! Что они делают в трех разных местах? Значение кодов налогов и их использование определяется единожды на стадии дизайна проектного решения и больше (за исключением случаев изменения законодательства) не меняются. Это не параметры – это настройка! Бухгалтерам совсем не обязательно иметь доступ к их изменению. Обычно для этих отчетов просто создаются варианты и в параметры кроме диапазона дат никто из пользователей даже не вникает. А потом выходит новое изменение закона и САП срочно меняет, скажем, форму НН, забывая про реестр и корректировочную печатную форму. В течение следующих месяцев, в ответ на обращения в поддержку, остальные формы тоже подтягиваются к новому законодательству. И тут оказывается, что в какую-то форму настройку забыл прописать уже в свою очередь консультант. Так было уже не раз. Централизованная настройка значений кодов налога сделали бы настройки понятней, а описанные случаи реже. В добавок, убрались бы из
отчетов простыни параметров, которые никто кроме консультантов не меняет.

В добавок к этому хочу прибавить, что считал бы целесообразным вести аналогичным образом (в отдельной таблице) цепочки кодов налогов. Существующий способ указания целевых кодов не очень прозрачен – нужно просмотреть все коды, чтобы увидеть цепочку, которая обычно придумывается как единое целое. К тому же цепочки бывают разные, например, обычная цепочка имеет 4 кода, но для услуг нерезидента цепочка совсем другая, а еще есть случай с ежегодным распределением НДС при продаже исключенных товаров – это еще пару кодов, а еще есть продажа ниже нормальной цены – ответвление от стандартной цепочки. Если это все организовывать в виде целевых кодов (кстати, большинство случаев из упомянутых сейчас не организованы никак, да и не поддерживаются для автоматического создания НН), то нужно помнить для каждого случая какой номер в цепочке что означает, а в отдельной таблице все было бы наглядней и гибче.

Аналогичная проблема с другими параметрами в отчетах

• ФИО и ИНН главбуха и директора – повторяется в реестре НН и декларации по НДС. В этом направлении правда есть сдвиг – недавно вышла нота позволяющая прописывать эти данные в данных балансовой единицы, но программы пока это нововведение не поддерживают.
• Аналогично – данные налоговой администрации (код и название) – повторяются в реестре НН и декларации по НДС. Лучше бы их тоже вынести в данные БЕ.
• Блок типов документов в реестре НН – это тоже настройка – ей нечего делать параметрах – будучи единожды настроенной, не меняется до новых законодательных изменений.

Лучше бы их сделали отдельной настройкой, то как это сделали на уровне БЕ, по моему мнению, тоже сделано через одно место.

По поводу типов документа, кстати, тоже нужно заметить, что решение разделять типы налоговых накладных в реестре типами документа в финансах – не идеально:

• Во-первых, чисто практически это встречает резкое сопротивление центральной команды внедрения в проектах-ролаутах западных компаний. Они (команда) не понимают и протестуют против добавления 10 и более типов документов специально для Украины.
• Во-вторых, с точки зрения бизнес операций приобретение, скажем, ЖД билета и проживания в гостиницы особо не отличаются и могут даже проводиться на один счет, а в НН это будут 2 типа документа.

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


6. ВОЗМОЖНОСТИ РАСШИРЕНИЯ И BADI

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

• Методы BADI вызываются из: программ печати НН, реестра НН, программы генерации НН. Почему это все один BADI? Или как из названия понять, к чему оно относиться? Половина имеет префикс PODATK_NAKL, другая половина – TAXVOUCHER, третья не имеет префикса и даже описания (CHANGE_SGSTXT). Бардак, рисунок uk4.png
• Параметры методов тоже местами поражают (в примере метод TAXVOUCHCORR_TITLE_DATA). Как из описания передаваемой структуры понять, скажем, что PAYMDIR – это номер договора ? И что означают другие поля? И ведь описание нигде нет и в нотах, добавляющих этот функционал тоже. А поддержка в одном из моих запросов прямым текстом написала – обратитесь к абаперам – они мол должны знать – это меня просто поразило. Откуда они должны знать? Да под отладкой кое-что понятно, но ведь надо предоставлять какую-то сопроводительную документацию, если уж даете решение. И тем более не отвечать на общение в поддержку, мол, разберитесь сами рисунок uk5.png!

Ну их ответ обозначал, что вы должны нагрузить своего абапера, он вам расскажет откуда попадают значения в эти поля, путем трассировки выполнения кода. При этом если в следующем релизе что-то поменяется, то как бы и SAP тут не причем, ну это же вы сами так сделали, а компания и не обещала нигде что последовательность заполнения не будет изменена  8). Кстати, в свое время так и делал, ковырял код, чтобы понять что и откуда берется в этом аддоне

7. ПРОЧИЕ ПРОБЛЕМЫ И ОТСУТСТВУЮЩАЯ ФУНКЦИОНАЛЬНОСТЬ
Теперь ряд более мелких, но не менее важных недочетов.

7.1 Создание НН на предоплату на отдельные строки заказа. Довольно серьезная проблема. Независимо от того, что заказывает клиент, он имеет право заплатить предоплату за что-то конкретно и требовать налоговую накладную согласно тому, что он заплатил. НН на предоплату формирует строки на все строки сбытового заказа, пропорционально раскидывая сумму предоплаты между ними. Клиент имеет право потребовать переделать такую НН. И тогда в САПе ее можно сделать только вручную. Иная вариация той же проблемы: желание клиента оформляется в системе в сбытовой заказ, но по факту, по причине недостач на складе отгрузиться меньше (как количество по отдельным строкам, так меньший набор наименований товара) и это известно уже на этапе выставления счета на предоплату. Соотношение заказа и отгрузки – ключевой показатель эффективности планирования запасов и внимательно отслеживается компанией. Сбытовое решение полностью в рамках стандартной функциональности и идеологии САП. В итоге формируется проформа инвойс, структура строк в которой отличается от таковой в заказе. На основании проформы печатается счет. А НН в итоге берет структуру строк из заказа и не соответствует счету на оплату. Как следствие клиент имеет право отказать принять такую НН.

Решением, очевидно, будет возможность формировать НН по предоплатам на основании проформ, структура строк в которой верна.


7.2. Распределение НДС. Для компаний, продающих товары, освобожденные от НДС, существует процесс распределения НДС. Суть в том, что часть налогового кредита согласно рассчитанной раз в год процентной ставке относится (распределяется) к категории невозмещаемого НДС. В аддоне есть возможность отобразить такое распределение в реестре и декларации, но не возможности провести распределение автоматически. Проблема существенная т.к. распределение должно быть проведено в разрезе каждой полученной НН или, на крайний случай, в разрезе контрагентов (распределение детализируется в приложении 5 по ИНН). Такая проводка вручную занимает значительное время.

Стандартного решения нет. Вариант решения – отдельная программа распределения (по оценкам, очень несложная).


7.3. Продажа ниже нормальной цены. В случае продажи товара ниже так называемой «нормальной цены» НДС начисляется на «нормальную цену», а не на продажную. В результате должно быть сформировано 2 НН – одна на продажную цену, а вторая на разницу между продажной и нормальной ценами. Вторая НН на данный момент может быть проведена только вручную. Автоматизировать данный процесс нетривиально т.к. понятие «нормальной цены» может несколько варьироваться от предприятия к предприятию – иногда это себестоимость материала, иногда совершенно посторонняя цифра, которую можно указать, скажем, в дополнительном условии в сбытовом заказе. Однако решением могло бы быть предоставление метода BADI, который бы для каждого конкретного клиента реализовывал расчет нормальной цены с последующей генерацией НН стандартным способом с использованием этой информации.


7,4. Продажа импортных ОС. Для импортных товаров в НН должен отображаться код УКТЗЕД – ОС не исключение. Для товаров решение есть, для ОС – нет и поддержка в реализации функционала мне отказала. Решается с помощью BADI, но хотелось бы увидеть в стандартном решении – благо функция совершенно не сложная.


7,5. Поддержка SD договоров. Ряд компаний используется стандартный функционал сбытовых договоров в системе. Для НН в частности важно то, что к договорам могут быть привязаны предоплаты. Для таких предоплат НН формируется некорректно – без количеств. Хотелось бы увидеть в стандартном решении.


7,6. Атрибут плательщика НДС в карточке контрагента. Для корректной печати налоговой накладной необходима информация о том, является ли контрагент плательщиком НДС. Признаком этого в системе является галочка «Налог с оборота» в карточке контрагента. Реально же достаточным и однозначным признаком это является наличие номера свидетельства о регистрации плательщика НДС (налоговый номер 3). На практике, пользователи заполняя карточку контрагента, часто забывают устанавливать упомянутый флаг, что приводит к неправильной печати НН (только первой конечно, но все равно факт). Номер свидетельства же заполняется всегда как часть реквизитов. Целесообразно         использовать именно этот признак для определения плательщика НДС.

7.7. Мелочи:
а) Генерация ежемесячных номеров НН производиться запуском реестра со специальным параметром или при печати НН. Иногда пользователи забывают сделать одно из этих действий (обычно, по причине различных зон ответственности), что приводит к нарушениям нумерации – ранние номера могут иметь более позднюю дату. Это может привести к штрафам.     Целесообразно было бы генерировать номер НН при ее проводке, отслеживая это события с помощью модуля в OpenFI business events.

б) Реестр НН и декларация по НДС не добавляют символ «\» к пути выгрузки файлов. В итоге если не дополнить символ в конце, то имя файла будет объединено с название последнего каталога в пути. "C:\temp" -> "c:\temptaxvoucherfilename.xml"

в) НН в форме XML формируются программой печати НН, запускаемой внутренне из реестра НН. При этом программа печати требует существования запроса на печать корреспонденции (SAPU1 и SAPU3) и без них не выгружает запрошенную НН. Очевидный вопрос: зачем запрашивать печать НН для ее выгрузки в XML? Очевидно, программа печати должна проверять запущена ли она для генерации файла или для печати и требовать запрос корреспонденции только в последнем случае.


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

8.1. Параметры декларации НДС.

• Диапазоны даты проводок. Зачем их дублировать для приложений 1 и 5? Как будто их можно формировать за разные периоды. И вообще этот диапазон можно автоматически рассчитывать из месяца отчетности
• Повторение перечня приложений в начале параметров и для выгрузки в XML. Зачем дублировать? Если человек отметил, что он хочет сформировать приложение 5, значит он его и выгружать будет!
• Чекбокс «Актуальная версия». Актуальная это какая? А если сегодня приняли новые изменения, то она тоже актуальная? Очень не прозрачно – здесь должна быть дата утверждения «версия от хх.хх.хххх». Да и вообще целесообразность этой галочки не ясна. Если поддерживаются предыдущие версии декларации, то там должен быть список и всех поддерживаемых версий, а не «актуальная/неактуальная»

8.2. Сомнительно удобство и логичность запуска отчет RFUMSV00 для подготовки декларации. Я понимаю, зачем это, но ведь те же приложения формируются фоновым запуском реестра, который с прогоном RFUMSV00 никак не связан. И даты можно в декларации выбрать отдельно. Нецелостно получается.Более правильно было бы запускать RFUMSV00 неявно в фоне самой декларацией или, еще лучше, формировать декларацию непосредственно на основании реестра, раз уж он все равно запускается декларацией. Между прочим, так формирует декларацию некоторый внешний специализированный софт (например, Медок).

8.3. Давно пора перевести реестр НН к новому табличному ALV – выглядел бы компактней и удобней. Заодно привести в порядок колонки реестра, названия которых не соответствует тому, что в них отображается («Noвиправлення» и пр.). Переход между частями реестра удобней было бы сделать внутри самого отчета т.е. выбирать сразу обе части, а внутри вкладки. Для этого, правда, надо решить сначала вопрос с быстродействием.

8.4. Выгрузка XML файлов в реестре и декларации должна осуществляться отдельной кнопкой внутри отчета, а не как сейчас – запросил отчет, отчет подумал, вывел данные, пользователь на них посмотрел – все в порядке – вернулся на экран параметров, спустился в самый низ, отметил флаг, запустил, отчет подумал, вывел данные (на которые и смотреть то уже не надо), пользователь нажал выйти – отчет выгрузил файлик – крайне неудобно.

8.5. То же с выгрузкой НН в XML для ЕРПН – нужна возможность отметить галочками внутри отчета и нажать кнопку «сохранить в XML» - гораздо удобнее постоянных перезапусков отчета. Тут конечно стоит оговориться, что возможность для фоновой выгрузки файлов должна остаться как опция.

8.6. Печатать НН было бы удобнее прямо из реестра без использования дополнительных операций для вызова корреспонденции – это одна из самых типичных и частых жалоб реальных пользователей – «чтобы распечатать налоговую нужно выполнить кучу действий»

Перечень далеко не полный – дополнить еще есть чего. ☺



9. ОТНОШЕНИЕ СЛУЖБЫ ПОДДЕРЖКИ
Под конец хочу отметить вопрос о качестве службы поддержки (SAP Calls). Возможно, он несколько субъективен, но все-таки, хочу обратить на него внимание. За время работы консультантом я открыл многие десятки запросов в САП. Около половины вылилось в релизы новых нот (из чего могу судить, что запросы в основном адекватные ;). Но на некоторые запросы я встречал глухое непонимание и нежелание проникнуться сутью проблемы.

Создается впечатление, что задача специалистов первого уровня поддержки просто отбить запрос. Не вдумываясь в его суть. Наверное, это целесообразно с т.з. загрузки отдела разработки. Но очень обидно, когда ты находишь четкую проблему, тратишь время на ее описание, а иногда и формирование конкретного предложения решения, а в ответ тебе – «это консалтинговая проблема» или еще какой-то заготовленный шаблонный ответ, в который этот человек не вписывает ни единого слова т.к. даже имя наверняка поставляется автоматом. Или пытается судить об актуальности проблемы, с которой на практике даже не встречался. Для того, чтобы развивать продукт надо прислушиваться к мнению рынка, самой осведомленной частью которого, наверное, являются как раз консультанты, общающиеся с пользователями и встречающиеся с запросами непосредственно.

Отдельно надо упомянуть про тестирование и отслеживание качества решения – Господа! Половина выпускаемых заплаток – это исправление багов других заплаток, такие ноты появляются чуть ли не каждую неделю! Регулярно (регулярно!) эти заплатки ломают старую функциональность. Куда это годится?

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

PS: Ну и оригинальный файл от Александра Цыбульского: Проблемы украинского решения по НДС в SAP.pdf

[ysichov]

А я думал, что хуже/сложнее HR PY ничего быть не может :)