Очень часто бухгалтеры ругаются, когда уже отраженные документы в бухгалтерском учета меняются сотрудниками.
Понятно, что можно закрывать периоды, но есть и другой путь.
Дано, односторонний обмен между УТ 11 и БП 3, придерживаемся подхода
- Не проведен = не отражен, все новые документы полученные из УТ должны всегда создаваться не проведенными.
- Не отражен = доступен к обновлению, обновляем документ при получении новых версий
- Отражен = заблокирован, запретить изменение обменом уже проведенных документов.
Решение простое, красивое и устойчивое к обновлениям.
Расширяем общий модуль "МенеджерОбменаЧерезУниверсальныйФормат" или "МенеджерОбменаЧерезУниверсальныйФормат13" если у вас обмен в EnterpriseData1.3 и добавляем всего 1 процедуру
//костыли hands.center
///УстановитьПризнакПроведенПриЗагрузке выполняется при получение документов, для отметки проведения.
//перехват этой процедуры позволяет сделать врезку во все получаемые документы.
&Перед("УстановитьПризнакПроведенПриЗагрузке")
Процедура хцУстановитьПризнакПроведенПриЗагрузке(ПолученныеДанные, ДанныеИБ, ПараметрыКонвертации)
//костыль что бы запретить проведение документов после получения
ПараметрыКонвертации.РазрешитьПроведениеДокументовПриЗагрузке = Ложь;
/// Костыль для игнорирования проведенных документов
//Если в обработчике «Перед записью полученных данных» присвоить параметру «Полученные данные» значение «Неопределено», данные найденного объекта замещаться не будут.
Если не ДанныеИБ = Неопределено и ДанныеИБ.Проведен Тогда
ПолученныеДанные = Неопределено; //сбрасываем данные объекта и прерываем запись документа
КонецЕсли;
КонецПроцедуры
Related Posts
Получение логина и пароля техподдержки 1С из базы
Класс для вывода отчета в Excel
Счет-фактура для УПП
Библиотека классов для создания внешней компоненты 1С на C#- Акт об оказании услуг (со скидками) — внешняя печатная форма для Управление торговлей 11.1.10.86
Прайс-лист с артикулом в отдельной колонке
кстати подобными образом можно добавить в базе получателя любые условия и преобразования как полученных данных так и существующих данных.
Технически решение простое и красивое. А методологически ждём статью как найти и исправить расхождения учёта в связных системах.
Или от одностороннего обмена перейти на двухсторонний, а затем на Ка и ерп.
(2) практика говорит что бухгалтерам крайне важна неизменность данных. И гораздо более важнее что бы в сдаваемой отчетности первичка сходилась с контрагентами. Потому предложенный принцип предполагает, что бухгалтер принял выписанную первичку и отразил ее в своем учете.
А если нам надо принять новую версию уже проведенного документа, как в таком случае быть?
(5)отменить проведение в базе приемника
А для чего тогда «дата запрета загрузки данных» в приемнике?
(7) одно другому не мешает.
С моим вариантом бухгалтер сможет делать в свой базе все что захочет, закрывая и открывая периоды. При это полностью исключены «случайные» обновления данных
По идее после таких изменений в конфигурации у вас должны регулярно появляться ситуации расхождения в двух базах.
1. В первой базе док1, сумма=100. Во второй базе — приняли документ и провели.
2. В первой базе изменили сумму (сумма=120). Во второй базе — мы этот документ провели поэтому менять не будем.
В итоге в первой базе док1, сумма=120, во второй базе док1, сумма=100
(9) Именно в этом и есть смысл.
Очень часто документооборот бухгалтеров сильно отличается от управленческого, даже не часто а почти всегда.
И если менеджер задним числом поменял документ — то он обязан передать клиенту новые документы и дополнительно уведомить об изменении документа еще и бухгалтера, что в общем то разумно. А вот слепое обновление документов, еще так что бухгалтер не знает об этом — это всегда плохо.
В любом случае — это решение не претендует на истинно верное и не для всех. Это просто еще один подход в переносу документов из управленческой в бухгалтерскую.
(9) вообще, я это пример привел для демонстрации простого способа врезки в обмен документами. Так что бы можно было легко обработать получаемые документы на основе полученных и существующих документов. С реализацией любой логики обмена.
Такой молчаливый пропуск объекта при загрузке вряд ли заслуживает хоть какого-нибудь внимания.
Обмен данными, как сказано выше, превращается к обмен «шаблонами» документов, т.е. эдакую помогалку в избегании двойного ввода.
Как минимум нужно хранить информацию о пропуске загрузки в ЖР (с привязкой к объекту БД приемника), если по какой-то причине типовой механизм запрета по дате не устроил.