| Предыдущая тема :: Следующая тема |
| Автор |
Сообщение |
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
 Чт Дек 17, 2009 11:53 107 поле в ПП по таможенным платежам |
 |
Полезность: Нет оценки
|
Коллеги!
А как у вас решен вопрос заполнения данного поля в связи с приказом минфина РФ от 1 октября 2009 г. N 102н.
А именно по пункту 6 приложения 3 данного приказа: "6. В поле 107 указывается код таможенного органа, присвоенный правовым актом федерального органа исполнительной власти, осуществляющего в соответствии с законодательством Российской Федерации функции по выработке государственной политики и нормативному регулированию, контролю и надзору в области таможенного дела, который идентифицирует таможенный орган, осуществляющий администрирование платежа."
Т.е. для платежей в таможню точки в данном поле не нужны. В то время как в бюджетном реквизите данное поле имеет формат &&.&&.&&&&. На запрос отправленный в ЦФТ пока ответа нет. Мы пока выходим из положения, убирая в хуке RC_POST_CREATE точки из поля создаваемого документа РЦ. Убираем по набору критериев, который нам дал бизнес. |
|
 |
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Чт Дек 17, 2009 15:01 |
|
Полезность: Нет оценки
|
ЦФТ:
| Цитата: | В связи с вводом в действие (приказом 102н от 01.10.2009) с 24.12.2009 новой редакции Приказа Минфина РФ N 106н от 24.10.2004 о правилах заполнения бюджетных реквизитов, планируется реализация новых требований в ЦФТ-Банк.
Дистрибутивное исправление проверок заполнения бюджетных платежей а так же операции печати подобных документов, выйдут в дополнении к версиям 9.6 и 9.5. (актуальная информация будет отображена на сайте сопровождения).
Рекомендации: Данные проверки при создании документа и при его обработке в РЦ являются мягкими. Соответственно, несмотря на предупреждения системы их возможно игнорировать. В РЦ данные проверки могут быть отключены, либо есть возможность проводить документы РЦ подтверждая их из 6 очереди.
|
|
|
|
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
| Чт Дек 17, 2009 15:07 |
|
Полезность: Нет оценки
|
Спасибо за сообщение. А как ЦФТ так быстро ответило  ?. Мой запрос так и висит на анализе... Или это где-то в новостях я упустил? |
|
|
timochev
Эксперт
Вступление в Клуб: 02.07.2007
|
| Чт Дек 17, 2009 15:25 |
|
Полезность: Нет оценки
|
| Chuk пишет: | | Спасибо за сообщение. А как ЦФТ так быстро ответило ?. Мой запрос так и висит на анализе... Или это где-то в новостях я упустил? |
Этот ответ можно найти на сайте сопровождения по ссылке "Запросы \ Просмотр запросов \ Важные запросы" |
|
|
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
| Чт Дек 17, 2009 15:31 |
|
Полезность: Нет оценки
|
| Спасибо. Чем дальше тем интереснее.... |
|
|
Alex2019
Профи
Вступление в Клуб: 02.07.2007
|
| Пт Дек 18, 2009 11:10 Re: 107 поле в ПП по таможенным платежам |
|
Полезность: Нет оценки
|
| Chuk пишет: | | Мы пока выходим из положения, убирая в хуке RC_POST_CREATE точки из поля создаваемого документа РЦ. Убираем по набору критериев, который нам дал бизнес. |
Мне бизнес объявил, что надежных признаков нет, т.к. любые поля (в т.ч. 106-е) могут быть заполнены нулем.
Не поделитесь вашим набором критериев? |
|
|
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
| Пт Дек 18, 2009 11:23 |
|
Полезность: Нет оценки
|
| Набор был прост. Поле "Статус составителя" не пустой. Бал счет получателя 40314. Правда это не помогло нашему филиалу в Москве. У них там платежи в таможню идут еще до сих пор на 40101. Поэтому для них пришлось сделать временную служебную операцию, которую выдали отвественным людям. Операция делает тоже самое, т.е. при запуске на платежном документе, происходит замена точек на пустоту в 107 поле документа РЦ. |
|
|
Alex2019
Профи
Вступление в Клуб: 02.07.2007
|
| Пт Дек 18, 2009 15:57 |
|
Полезность: Нет оценки
|
| Chuk пишет: | | Набор был прост. Поле "Статус составителя" не пустой. Бал счет получателя 40314. Правда это не помогло нашему филиалу в Москве. У них там платежи в таможню идут еще до сих пор на 40101. Поэтому для них пришлось сделать временную служебную операцию, которую выдали отвественным людям. Операция делает тоже самое, т.е. при запуске на платежном документе, происходит замена точек на пустоту в 107 поле документа РЦ. |
Очень это все странно...
1. Статус составителя - это какое поле? 101-е? но оно не пустое для всех бюджетных платежей, а точки не нужны только для таможенных.
2. Счет получателя 40314. Как мне сказали, этот счет потихоньку закрывается и учет таможни переносится на 40101. Во всяком случае наши клиенты все как один уже платят на 40101.
Единственное, что вижу я в качестве идентификации таможенного платежа - это фиксированный набор кодов из 102-го приказа для поля 106. Но этот признак ненадежен, поскольку это поле легко могут заполнить нулем.
Пока что отслеживаем эти платежи вручную и убираем точки в файле выгрузки перед обработкой Конвой. 
Попробую с вашей подачи в этом же хуке проверять непустое 107-е поле на последние 4 символа, если они не похожи на год, убираю точки. Посмотрим что получится... |
|
|
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
| Пт Дек 18, 2009 17:32 |
|
Полезность: Нет оценки
|
| Alex2019 пишет: |
Очень это все странно...
1. Статус составителя - это какое поле? 101-е? но оно не пустое для всех бюджетных платежей, а точки не нужны только для таможенных.
2. Счет получателя 40314. Как мне сказали, этот счет потихоньку закрывается и учет таможни переносится на 40101. Во всяком случае наши клиенты все как один уже платят на 40101.
|
Так ведь ж Москва... В нашем московском филиале тоже в платежи по таможне идут на 40101 и там они ручками операцию запускают. У нас в Питере, пока критерий бал. счета 40314 работает, вот этот кусок у нас и происходит автоматически. Насчет статуса составителя - да это 101-е поле, вот только когда оно заполнено мы платежи на 40314 начинаем курочить...
| Alex2019 пишет: |
Пока что отслеживаем эти платежи вручную и убираем точки в файле выгрузки перед обработкой Конвой.
Попробую с вашей подачи в этом же хуке проверять непустое 107-е поле на последние 4 символа, если они не похожи на год, убираю точки. Посмотрим что получится...
|
Главное чтобы клиент мог бы ввести свой номер отличный от даты. При ручном вводе это проблем не вызывает, а вот при поступлении из внешних источников... Бывает внешний источник не понимает, что это поле не обязательно дата ... |
|
|
Alex2019
Профи
Вступление в Клуб: 02.07.2007
|
| Пн Дек 21, 2009 09:58 |
|
Полезность: Нет оценки
|
| Chuk пишет: | | Главное чтобы клиент мог бы ввести свой номер отличный от даты. При ручном вводе это проблем не вызывает, а вот при поступлении из внешних источников... Бывает внешний источник не понимает, что это поле не обязательно дата ... |
Сообщение от Виктора Шахматова (ЦФТ): | Цитата: | В результате обсуждений и изучений вопроса мы прешли к следующему решению:
Мы меняем тип реквизита отвечающего за налоговый период, отныне это будет обычная строка 10 символов. Т.е. после выхода данного обновления разделители "." пользователи будут проставлять сами и в реквизите отныне будет храниться именно то, что ввел пользователь/пришло из внешней системы.
Замена реквизита на строку такой же длены не приведет к перестроению MAIN_DOCUMа, а конвертацию старых документов мы реализуем с возможностью указания диапозна дат, который будет определять какие документы необходимо конвертировать.
Выход данного дополнения запланирован на следующей неделе. |
(сейчас уже - на текущей) |
|
|
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
| Пн Дек 21, 2009 10:25 |
|
Полезность: Нет оценки
|
| Alex2019 пишет: |
Сообщение от Виктора Шахматова (ЦФТ): | Цитата: | В результате обсуждений и изучений вопроса мы прешли к следующему решению:
Мы меняем тип реквизита отвечающего за налоговый период, отныне это будет обычная строка 10 символов. Т.е. после выхода данного обновления разделители "." пользователи будут проставлять сами и в реквизите отныне будет храниться именно то, что ввел пользователь/пришло из внешней системы.
Замена реквизита на строку такой же длены не приведет к перестроению MAIN_DOCUMа, а конвертацию старых документов мы реализуем с возможностью указания диапозна дат, который будет определять какие документы необходимо конвертировать.
Выход данного дополнения запланирован на следующей неделе. |
(сейчас уже - на текущей) |
А можно узнать на каком обновлении это действует? Мы сейчас тестируем переход на 9.5 и на версии 9.5.13 в Платежные документы - Дополнительные реквизиты бюджетного документа - Налоговый период - Показатель налогового периода (NU_POINT) у нас строка 10 но с маской ввода &&.&&.&&&&. Т.е для ручного ввода все равно точки остались... Или я не прав? |
|
|
Alex2019
Профи
Вступление в Клуб: 02.07.2007
|
| Вт Дек 22, 2009 12:22 |
|
Полезность: Нет оценки
|
| Chuk пишет: | | А можно узнать на каком обновлении это действует? Мы сейчас тестируем переход на 9.5 и на версии 9.5.13 в Платежные документы - Дополнительные реквизиты бюджетного документа - Налоговый период - Показатель налогового периода (NU_POINT) у нас строка 10 но с маской ввода &&.&&.&&&&. Т.е для ручного ввода все равно точки остались... Или я не прав? |
Правы. Это вообще пока не реализовано. Как сказано выше обещают на этой неделе, видимо будут дополнения к 9.5 и 9.6 |
|
|
korobenkov
Участник
Вступление в Клуб: 29.09.2009
|
| Чт Дек 24, 2009 05:45 |
|
Полезность: Нет оценки
|
Мдааа... Процесс долгий и как то запутано все.
Имхо, наименее затратна, с точки зрения программисто/часов, простая операция: "Сменить поле 107" в уже сформированном п/документе... И убрать ее потом недолго. Или я что то упустил? |
|
|
Chuk
Участник со стажем
Вступление в Клуб: 18.08.2008
|
| Чт Дек 24, 2009 09:15 |
|
Полезность: Нет оценки
|
| korobenkov пишет: |
Имхо, наименее затратна, с точки зрения программисто/часов, простая операция: "Сменить поле 107" в уже сформированном п/документе... И убрать ее потом недолго. Или я что то упустил? |
В общем-то все правильно. Но 1-е что мы хотели сделать - это исключить из цепочки пользователя, что при наличии четких критериев нам могло помочь. А уже потом, когда выяснилось, что с критериями не все гладко, была создана операция, названная вами "Сменить поле 107". Ну и как обычно, такая операция доступна только группе операционистов с расширенными правами, дабы максимально исключить вероятность порчи "правильного" документа. |
|
|
|
О проекте
Поиск
Отзывы
Регистрация
Вход
