Ошибка обмена данными нет транзакции

Ошибка при обмене данными между базами 1С: причины и способы исправления

Вместе со специалистом линии консультаций Алексеем Налимовым разбираем основные типы ошибок, которые могут возникать при обмене данных между базами 1С.

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

1) – обмен не прошел, ошибка транспорта сообщений.

При возникновении ошибки обмена, программа предлагает зайти в «Журнал регистрации», чтобы посмотреть подробности ошибки. Ниже представлены примеры ошибок в «Журнале регистрации»:

Рис. 1. Ошибка при отправке данных (нажмите, чтобы увеличить)

Рис. 2. Ошибка при получении данных (нажмите, чтобы увеличить)

2) – предупреждение, обмен в целом прошел, но есть проблемы в данных:

• не проводится документ. Например, при проведении реализации не хватает товара на остатке;

• не записывается элемент справочника. Например, в карточке товара не заполнена единица измерения;

• загруженный документ имеет дату, которая в БП является запрещенной к изменению;

• элемент справочника с момента последнего обмена менялся в обеих программах (конфликт версий).

Открыть предупреждения и попытаться устранить их можно, нажав соответствующую ссылку:

Рис. 3 (нажмите, чтобы увеличить)

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

Рис. 4 (нажмите, чтобы увеличить)

Ошибки подразделяются на следующие типы:

1) Не связанные с данными:

Ошибка подключения базы к базе;

2) Связанные с данными: в выгружаемом документе или справочнике не заполнены какие-либо данные (единица измерения и т.д.).

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

regsvr32 «C:Program Files (x86)1cv88.3.15.1534bincomcntr.dll»

В Windows 10 для запуска командной строки от имени администратора нужно нажать правой кнопкой мыши по кнопке Пуск:

Рис. 5 (нажмите, чтобы увеличить)

Рис. 6 (нажмите, чтобы увеличить)

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

Например: УТ нетиповая (т.е. доработанная) и поэтому редко обновляется, а БП, наоборот, поддерживается в актуальном состоянии. Если разработчики добавили и переименовали в документе или справочнике какой-нибудь реквизит, может возникнуть ошибка.

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

Иногда есть необходимость срочно провести обмен и совместно со специалистом линии консультаций решается вопрос о временном исключении проблемного объекта из обмена.

Довольно часто случаются такие досадные ошибки, когда документ или справочник некогда был параллельно введен в обеих обменивающихся базах. При этом существует большой риск после обмена получить в базах дубли объектов. Исправление таких ошибок требует большой внимательности, осторожности и знаний в предметной области, сопряженной с удалением дублей, а также переносом ссылок. Желательно не запускать такие случаи и вовремя обратиться за помощью.

Источник

Не работает синхронизация ЗУП 3.1 – БП 3.0. Что может проверить бухгалтер?

Обмен не проходит, документы не переносятся

1) Проверка соответствия релизов БП 3.0 и ЗУП 3.1

Частой причиной ошибок при обмене выступает разрыв между обновлениями конфигураций ЗУП 3.1 и БП 3.0.

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

2) Проверка корректности подключения

Заходим в раздел Администрирование – Синхронизация данных – Настройка синхронизации данных.

Встаем мышкой на нужный обмен — кнопка Настроить – кнопка Ещё – Настройки подключения:

В открывшемся окне производим проверку подключения по одноименной кнопке:

Данную проверку следует произвести как в ЗУП 3.1, так и в БП 3.0.

Распространенные ошибки подключения:

При подключении через сетевой каталог – разные папки для обмена в ЗУП 3.1 и БП 3.0 (в данном случае нужно проверить оба пути и указать верный); отсутствие доступа до папки (обратиться к системному администратору для настройки общего доступа);

При прямом подключении – смена пароля у пользователя, используемого для подключения (следует обновить данные для подключения).

Обмен проходит, документы не переносятся

Документы регистрируются к обмену в автоматическом режиме при добавлении, изменении. Бывают случаи, когда документ по какой-то причине не переносится.

1) Убедиться, что нужный документ по дате попадает в период, с которого начинается обмен данными:

Если необходимо, следует провести корректировку настроек обмена.

2) Проверить Предупреждения при обмене, раздел Непринятые по дате запрета:

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

3) Зарегистрировать документ к обмену вручную

Для этого необходимо перейти по кнопке Состав отправляемых данных, выбрать нужный вид документа, затем по кнопке Зарегистрировать или правой кнопкой мыши в соседней табличной части зарегистрировать нужный документ к обмену:

Затем следует повторить проведение обмена между конфигурациями.

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

Для анализа рекомендуем переходить по активной ссылке Журнал регистрации в полученном сообщении результата обмена:

Где мы увидим, что сообщение обмена было принято ранее, поэтому получать в ЗУП 3.1 из БП 3.0 было нечего.

Иными словами, файл с данными, который был отправлен конфигурацией БП 3.0 к запуску текущего обмена не обновлялся. Это означает, что данные из сообщения уже были загружены в ЗУП 3.1 ранее и повторно загрузка производиться не будет.

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

Статью подготовила старший консультант «ИнфоСофт» Анастасия Ткаченко

Источник

Вы не умеете работать с транзакциями

Заголовок вышел броским, но накипело. Сразу скажу, что речь пойдет об 1С. Дорогие 1С-ники, вы не умеете работать с транзакциями и не понимаете что такое исключения. К такому выводу я пришел, просматривая большое количество кода на 1С, рождаемого в дебрях отечественного энтерпрайза. В типовых конфигурациях с этим все достаточно хорошо, но ужасающее количество заказного кода написано некомпетентно с точки зрения работы с базой данных. Вы когда-нибудь видели у себя ошибку «В данной транзакции уже происходили ошибки»? Если да — то заголовок статьи относится и к вам. Давайте под катом разберемся, наконец, что такое транзакции и как правильно с ними обращаться, работая с 1С.

Почему надо бить тревогу

Для начала, давайте разберемся, что же такое представляет собой ошибка «В данной транзакции уже происходили ошибки». Это, на самом деле, предельно простая штука: вы пытаетесь работать с базой данных внутри уже откаченной (отмененной) транзакции. Например, где-то был вызван метод ОтменитьТранзакцию, а вы пытаетесь ее зафиксировать.

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

Есть, конечно, вероятность, что технологический журнал сервера (он ведь у вас включен в продакшене, да?) как-то поможет диагностировать проблему, но я сейчас навскидку не могу придумать вариант — как именно в нем найти реальную причину указанной ошибки. А реальная причина одна — программист Вася получил исключение внутри транзакции и решил, что один раз — не карабас «подумаешь, ошибка, пойдем дальше».

Что такое транзакции в 1С

Неловко писать про азбучные истины, но, видимо, немножго придется. Транзакции в 1С — это то же самое, что транзакции в СУБД. Это не какие-то особенные «1С-ные» транзакции, это и есть транзакции в СУБД. Согласно общей идее транзакций, они могут либо выполниться целиком, либо не выполниться совсем. Все изменения в таблицах базы данных, выполненные внутри транзакции, могут быть разом отменены, как будто ничего не было.

Далее, нужно понимать, что в 1С не поддерживаются вложенные транзакции. Собственно говоря, они не поддерживаются не «в 1С», а вообще не поддерживаются. По-крайней мере, теми СУБД, с которыми умеет работать 1С. Вложенных транзакций, например, нет в MS SQL и Postgres. Каждый «вложенный» вызов НачатьТранзакцию просто увеличивает счетчик транзакций, а каждый вызов «ЗафиксироватьТранзакцию» — уменьшает этот счетчик. Данное поведение описано в множестве книжек и статей, но выводы из этого поведения, видимо, разобраны недостаточно. Строго говоря, в SQL есть т.н. SAVEPOINT, но 1С их не использует, да и вещь это достаточно специфичная.

Здесь и далее, специально для Воинов Истинной Веры, считающих, что код должен писаться только на английском, под спойлерами будет приведен аналог кода в англоязычном синтаксисе 1С.

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

Вы же наверняка пишете такой код, да? Приведенный пример кода содержит ошибки. Как минимум, три. Знаете какие? Про первую я скажу сразу, она связана с объектными блокировками и не имеет отношения непосредственно к транзакциям. Про вторую — чуть позже. Третья ошибка — это deadlock, который возникнет при параллельном исполнении этого кода, но это тема для отдельной статьи, ее рассматривать сейчас не будем, дабы не усложнять код. Ключевое слово для гугления: deadlock управляемые блокировки.

Обратите внимание, простой ведь код. Такого в ваших 1С-системах просто вагон. И он содержит сразу, как минимум, 3 ошибки. Задумайтесь на досуге, сколько ошибок есть в более сложных сценариях работы с транзакциями, написанных вашими программистами 1С 🙂

Объектные блокировки

Итак, первая ошибка. В 1С существуют объектные блокировки, так называемые «оптимистические» и «пессимистические». Кто придумал термин, не знаю, убил бы :). Совершенно невозможно запомнить, какая из них за что отвечает. Подробно про них написано здесь и здесь, а также в прочей IT-литературе общего назначения.

Суть проблемы в том, что в указанном примере кода изменяется объект базы данных, но в другом сеансе может сидеть интерактивный пользователь (или соседний фоновый поток), который тоже будет менять этот объект. Здесь один из вас может получить ошибку «запись была изменена или удалена». Если это произойдет в интерактивном сеансе, то пользователь почешет репу, ругнется и попробует переоткрыть форму. Если это произойдет в фоновом потоке, то вам придется искать это в логах. А журнал регистрации, как вы знаете, медленный, а ELK-стек для журналов 1С у нас в отрасли настраивают единицы… (мы, к слову, входим в число тех, кто настраивает и другим помогает настраивать :))

Короче говоря, это досадная ошибка и лучше, чтобы ее не было. Поэтому, в стандартах разработки четко написано, что перед изменением объектов необходимо ставить на них объектную блокировку методом «ОбъектСправочника.Заблокировать()«. Тогда параллельный сеанс (который тоже должен так поступить) не сможет начать операцию изменения и получит ожидаемый, управляемый отказ.

А теперь про транзакции

С первой ошибкой разобрались, давайте перейдем ко второй.

Если не предусмотреть проверку исключения в этом методе, то исключение (например, весьма вероятное на методе «Записать()») выбросит вас из данного метода без завершения транзакции. Исключение из метода «Записать» может быть выброшено по самым разным причинам, например, сработают какие-то прикладные проверки в бизнес-логике, или возникнет упомянутая выше объектная блокировка. Так или иначе, вторая ошибка гласит: код, начавший транзакцию, не несет ответственность за ее завершение.

Именно так я бы назвал эту проблему. В нашем статическом анализаторе кода 1С на базе SonarQube мы даже отдельно встроили такую диагностику. Сейчас я работаю над ее развитием, и фантазия программистов 1С, чей код попадает ко мне на анализ, порой приводит меня в шок и трепет…

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

Поднимемся на уровень выше по стеку вызовов:

Смотрите, что получается. Наш проблемный метод вызывается откуда-то извне, выше по стеку. На уровне этого метода разработчик понятия не имеет — будут ли какие-то транзакции внутри метода ОченьПолезныйИВажныйКод или их не будет. А если будут — то будут ли они все завершены… Мы же все тут за мир и инкапсуляцию, верно? Автор метода «ВажныйКод» не должен думать про то, что именно происходит внутри вызываемого им метода. Того самого, в котором некорректно обрабатывается транзакция. В итоге, попытка поработать с базой данных после выброса исключения изнутри транзакции, с высокой вероятностью приведет к тому, что «В данной транзакции бла-бла…»

Размазывание транзакций по методам

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

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

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

Пытаемся исправить код

Вернемся к исходному методу и попытаемся его починить. Сразу скажу, что объектную блокировку мы чинить пока не будем, просто, чтобы не усложнять код примера.

Первый подход типичного 1С-ника

Обычно программисты 1С знают, что при записи может быть выдано исключение. А еще они боятся исключений, поэтому стараются их все перехватывать. Например, вот так:

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

Однако, опытный 1С-ник здесь скажет, что нет, лучше не стало. По сути ничего не поменялось, а может даже стало и хуже. В методе «Записать()» платформа 1С сама начнет транзакцию записи, и эта транзакция будет уже вложенной по отношению к нашей. И если в момент работы с базой данных 1С свою транзакцию откатит (например, будет выдано исключение бизнес-логики), то наша транзакция верхнего уровня все равно будет помечена как «испорченная» и ее нельзя будет зафиксировать. В итоге этот код так и останется проблемным, и при попытке фиксации выдаст «уже происходили ошибки».

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

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

Методы работы с транзакциями в 1С

Не будет лишним напомнить, что вообще 1С предоставляет нам для работы с транзакциями. Это всем известные методы:

• НачатьТранзакцию()
• ЗафиксироватьТранзакцию()
• ОтменитьТранзакцию()
• ТранзакцияАктивна()

Первые 3 метода очевидны и делают то, что написано в их названии. Последний метод — возвращает Истину, если счетчик транзакций больше нуля.

И есть интересная особенность. Методы выхода из транзакции (Зафиксировать и Отменить) выбрасывают исключения, если счетчик транзакций равен нулю. То есть, если вызвать один из них вне транзакции, то возникнет ошибка.

Как правильно пользоваться этими методами? Очень просто: надо прочитать сформулированное выше правило: код, начавший транзакцию, должен нести ответственность за ее завершение.

Как же соблюсти это правило? Давайте попробуем:

Выше мы уже поняли, что метод ДелаемЧтоТо — потенциально опасен. Он может выдать какое-то исключение, и транзакция «вылезет» наружу из нашего метода. Окей, добавим обработчик возможного исключения:

Отлично, мы поймали возникающую ошибку, но что с ней делать? Записать сообщение в лог? Ну, может быть, если код логирования ошибок должен быть именно на этом уровне и ошибку мы тут ждем. А если нет? Если мы не ожидали тут никаких ошибок? Тогда мы должны просто передать это исключение выше, пусть с ними разбирается другой слой архитектуры. Делается это оператором «ВызватьИсключение» без аргументов. В этих ваших джава-сиплюсплюсах это делается точно так же оператором throw.

Так, стоп… Если мы просто прокидываем исключение дальше, то зачем тут вообще нужна Попытка? А вот зачем: правило заставляет нас обеспечить завершение начатой нами транзакции.

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

Финальный вариант

Наконец, мы можем написать правильный, «транзакционно-безопасный» вариант кода. Вот он:

**UPD: в комментариях предложен более безопасный вариант, когда ЗафиксироватьТранзакцию расположен внутри блока Попытка. Здесь приведен именно этот вариант, ранее Фиксация располагалась после блока Попытка-Исключение.

Постойте, но ведь не только «ОтменитьТранзакцию» может выдавать ошибки. Почему же тогда «ЗафиксироватьТранзакцию» не обернут в такое же условие с «ТранзакцияАктивна»? Опять же, по тому же самому правилу: код, начавший транзакцию, должен нести ответственность за ее завершение. Наша транзакция необязательно самая первая, она может быть вложенной. На нашем уровне абстракции мы обязаны заботиться только о нашей транзакции. Все прочие должны быть нам неинтересны. Они чужие, мы не должны нести за них ответственность. Именно НЕ ДОЛЖНЫ. Нельзя предпринимать попыток выяснения реального уровня счетчика транзакций. Это опять нарушит инкапсуляцию и приведет к «размазыванию» логики управления транзакциями. Мы проверили активность только в обработчике исключения и только для того, чтобы убедиться, что наш обработчик не породит нового исключения, «прячущего» старое.

Чек-лист рефакторинга

Давайте рассмотрим несколько наиболее распространенных ситуаций, требующих вмешательства в код.

Паттерн:

Обернуть в «безопасную» конструкцию с Попыткой, Проверкой активности и пробросом исключения.

Паттерн:

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

Примерно похожий вариант:

аналогично: фиксация транзакции по условию — это странно. Почему тут условие? Что, кто-то иной мог уже зафиксировать эту транзакцию? Повод для разбирательства.

Паттерн:

1. ввести управляемую блокировку во избежание deadlock
2. ввести вызов метода Заблокировать
3. обернуть в «попытку», как показано выше

Паттерн:

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

В заключение

Я, как вы уже, наверное, догадались, отношусь к людям, любящим платформу 1С и разработку на ней. К платформе, разумеется, есть претензии, особенно в среде Highload, но в общем и целом, она позволяет недорого и быстро разрабатывать очень качественные корпоративные приложения. Давая из коробки и ORM, и GUI, и веб-интерфейс, и Reporting, и много чего еще. В комментариях на Хабре обычно пишут всякое высокомерное, так вот, ребята — основная проблема 1С, как экосистемы — это не платформа и не вендор. Это слишком низкий порог вхождения, который позволяет попадать в отрасль людям, не понимающим, что такое компьютер, база данных, клиент-сервер, сеть и всякое такое. 1С сделала разработку корпоративных приложений слишком легкой. Я за 20 минут могу написать на ней учетную систему для закупок/продаж с гибкими отчетами и веб-клиентом. После этого, мне несложно подумать о себе, что и на больших масштабах можно писать примерно так же. Как-то там 1С сама все внутри сделает, не знаю как, но наверное сделает. Напишу-ка я «НачатьТранзакцию()».

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

Источник

	Не идет обмен между базами Я
aleks100 28.09.21 — 10:04	Не идет обмен между Згу 3.1.18.216 и бгу 2.0.80.31. Не выгружается документ отражение зарплаты в учете. Не могу понять, может правила обновить?
aleks100 1 — 28.09.21 — 10:12	обмен идет через каталог, почему в зарплате пишет данные отправлены и получены, а в бухгалтерии только отправлены, но не получены
hhhh 2 — 28.09.21 — 10:16	(1) это то как раз правильно, если обмен не идет, то она и не пишет, что получено, всё логично.
aleks100 3 — 28.09.21 — 10:24	может правила обмена обновить?
aleks100 4 — 28.09.21 — 10:24	или вручную выгрузить?
hhhh 5 — 28.09.21 — 10:38	(4) ну вы ошибку озвучьте, которая в журнале регистрации, чего гадать?
aleks100 6 — 28.09.21 — 10:40	Не удалось выполнить отправку данных. Подробности см. в журнале регистрации
hhhh 7 — 28.09.21 — 10:40	(4) а, конечно, вручную попробовать. Об этом и спрашивать не надо.
aleks100 8 — 28.09.21 — 10:40	Ошибка, Отправка данных; Объектов обработано: 0
hhhh 9 — 28.09.21 — 10:44	(8) вы получение смотрите, а не отправку. Не отвлекайтесь. Ошибка же при получении.
patapum 10 — 28.09.21 — 10:46	(6) Значит надо посмотреть пару сообщений перед этим, в них информация об ошибке.
aleks100 11 — 28.09.21 — 10:58	а как выгрузить один документ через универсальный обмен?
aleks100 12 — 28.09.21 — 11:06	почему то на стороне бухгалтерии обмен не идет
hhhh 13 — 28.09.21 — 11:13	(12) вы же это уже писали в (0). Запускайте вручную в бухгадтерии.
SleepyHead 14 — 28.09.21 — 11:14	(12) а он точно видит входящее сообщение? Может, там права на папку отвалились.
aleks100 15 — 28.09.21 — 11:18	(14) в бгу  пишет данные не получены, обмен идет из ЗГУ в БГУ
aleks100 16 — 28.09.21 — 11:19	(13) что значит вручную в бухгалтерии?
SleepyHead 17 — 28.09.21 — 11:42	(15) Видно ли из БГУ папку, в которую ЗУП выложила файл обмена?
hhhh 18 — 28.09.21 — 11:46	(16) обмен как запускаете в бухгалтерии?
timurhv 19 — 28.09.21 — 11:54	(15) >в бгу  пишет данные не получены, обмен идет из ЗГУ в БГУ Подробности из журнала регистрации будут? Обычно, в БГУ период закрывают, а из зарплаты пытаются выгрузить старый документ.
Pro-tone 20 — 28.09.21 — 11:56	(0) вангую, что обмен по правилам КД2, там тогда можно протокол выполнения подключить, либо он уже есть и нужно только в него посмотреть, это текстовый файл, куда логи обмена пишет, включая подробное описание ошибок
aleks100 21 — 28.09.21 — 12:04	кто-то дату установил  дату запрета на 31 августа в бгу, а документ отражения зп в учете за август, может из-за этого не выгружает
aleks100 22 — 28.09.21 — 12:06	пытался вручную документ добавить, смотрю а он не добавляется
aleks100 23 — 28.09.21 — 12:16	выгрузил,из-за даты запрета документы не выгружались

Пользователь не знает, чего он хочет, пока не увидит то, что он получил. Э. Йодан

ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку «Обновить» в браузере.

Тема не обновлялась длительное время, и была помечена как архивная. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.

Форум консультаций по прикладным решениям и программам фирмы «1С».

Онлайн консультации, вопросы и ответы, бесплатная регистрация, личная страница, twitter и facebook каналы и многое другое ждут Вас здесь.

Зарегистрироваться ← Ваш выбор → Войти на форум

1. Здравствуйте форумчане!!!!!!
   Пожскажите пожалуйсте если кто то сталкивался с проблемой по синхронизированию 1с8 управление торговлей 11 и бухгалтерия предприятием 8.2(все обновлено)

   Проблема состоят в том что при синхронизировании данные за июль 2013г. не переносятся в бухгалтерию, хотя до этого всё работало нормально и данные за июнь успешно перенеслись. У меня возникают мысли что может где-то стоит ограниечение 30 июня и из за этого не цепляет июль но могу ошибаться.

   Вот что пишится в журнале регистрации:
   Обмен данными.ОбменУправлениеТорговлейБухгалтерияПредприятия.Узел МГ.Выгрузка данных
   Начало процесса обмена данными для узла Бухгалтерия предприятия, редакция 2.0
   Обмен данными.ОбменУправлениеТорговлейБухгалтерияПредприятия.Узел МГ.Выгрузка данных
   ВНЕШНЕЕ СОЕДИНЕНИЕ: Сообщение обмена было принято ранее
   Обмен данными.ОбменУправлениеТорговлейБухгалтерияПредприятия.Узел МГ.Выгрузка данных
   {Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(3405)}: ВНЕШНЕЕ СОЕДИНЕНИЕ: Сообщение обмена было принято ранее
   ВызватьИсключение СтрокаСообщения;

   Обмен данными.ОбменУправлениеТорговлейБухгалтерияПредприятия.Узел МГ.Выгрузка данных
   Ошибка, Выгрузка данных; Объектов обработано: 0

   Нет транзакции

2. Реклама на форуме

   Чтобы убрать:

Похожие темы

Обмен типовой, односторонний УТ-> Бух, через каталог. У нас была ошибка при обмене с начало. Не помню сейчас какая, что-то связано с «пометкой удаления». Мы решили обновить УТ. Сейчас УТ 10.3.30.1 Бух 3.0.37.39 Загрузили правила конвертации, правила регистрации объектов в УТ. Поначалу были проблемы с нумерацией пакетов. Обнулил нумерацию и там и там. Запускаем обмен , пишет в ут успешно, в бух успешно. Смотрю данные в Бух, их нет. Дату загрузки проверял. Регистрация объектов для обмена в УТ не изменилась. Как будто бы и не выгружал не разу. Хотя по несколько раз туда и обратно прогонял. Все успешно!!! Уже и не знаю куда копать. подскажите, пожалуйста, посоветуйте…

Смотрю журнал регистрации в ут Данные получены: Выполнено, Загрузка данных; Объектов обработано: 0 Данные отправлены: Выполнено, Выгрузка данных; Объектов обработано: 2 088 Смотрю журнал регистрации в БУХ Данные успешно получены: «Подробно» пустая таблица Данные успешно отправлены: «Подробно» Выполнено, Отправка данных; Объектов обработано: 0

а как? попытался отладчиком. не нашел куда точку ставить)))бросил эту затею. Думаю может у кого такое было …поможет советом.

Не плохо бы перед обменом посмотреть регистрацию для обмена. А вообще обновлять надо после всех обменов и регзаданий.

Не сказал бы что мне этот обмен нравится, но он работает. Надо правильно делать все.

С регистрацией для обмена все в порядке, проверял сто раз. Посмотрел еще раз ЖР , убрал все фильтры получил : Ошибка в обработчике события ПослеЗагрузкиОбъекта ИмяПКО = СчетФактураПолученный ТипОбъекта = Счет-фактура полученный Объект = Счет-фактура полученный АМ000001195 от 22.12.2014 9:43:23 Обработчик = ПослеЗагрузкиОбъекта ОписаниеОшибки = Преобразование значения к типу Дата не может быть выполнено ПозицияМодуля = Документ.СчетФактураПолученный.МодульМенеджера Странно както обмен работает. Ошибок реально ни каких не выдавал…

убрал с регистрации все счет фактуры-полученные. изменений никаких. Еще обратил внимание что счетчик номеров пакетов в УТ ведется на принятые и отправленные . В бух только на отправленные , а принятые

Уж и не знаю что делать. Попробовал новую синхронизацию настроить. Застопорился на этапе когда префикс Бухии нужно ставить. Говорит, что такой префикс уже стоит в синхронизации…

ну хоть что-то: {Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(13315)}: Ошибка в обработчике события ПриПолученииИнформацииОбУдалении (конвертация)     Обработчик             =  ПриПолученииИнформацииОбУдалении (конвертация)     ОписаниеОшибки         =  Ошибка при вызове метода контекста (УстановитьПометкуУдаления): Действие не может выполняться в режиме загрузки данных

Автор нашел решение? У меня такая же проблемма один в один.

Была похожая ситуация обновил УТ до 10.3.31.2 и загрузил из последнего релиза правила обмена, и заработало.

Тэги: 1С 8

Комментарии доступны только авторизированным пользователям

1

2

Показывать по
10
20
40
сообщений

Новая тема

Ответить

mycap420

Дата регистрации: 04.02.2016
Сообщений: 7

Добрый день!

С начала года для бухгалтера была развернута новая база Бухгалтерии редакции 3.0. На данный момент требуется обмен данными УТ 10.3 с БП в одностороннем режиме (данные приходят из УТ в БП).
Вчера целый день бился так и не понял что я делаю не так данные не загружаются (из УТ в БП 2.0 всегда все работает без проблем лишь бы узлы совпадали а тут…., а вот выгрузка осуществляться хотя я вроде как установил что односторонний режим только принятие данных.

Делал следующие действия (Вариант 1):
В УТ
1. В параметрах учета уже стояла галочка использовать обмен данными, и префикт «УТ»
2. Далее «Сервис — Обмен данными с продуктами на платформе 1С: Предприятие 8.2 — Обмены данными» — создаю синхронизацию данными
3. Создаю новую синхронизацию — «Другие каналы связи (сетевой катало,….)»
4. Настройки параметров синхронизации данных — указал наименование и префик базы БП
5. Изменил правила выгрузки, выгружать данные с 01.04, и указал выгружать всю информацию (везде поставил галочки, выгрузка по всем организациям в базе)
6. Сохранил «Настройки для второй базы», произвел выгрузку (имя файла выгрузки Message_УТ_БП)

В БП
1. Администрирование — Настройки синхронизации данных, указал префикс «БП» и поставил галочку «Синхронизация данных» — «Настроить синхронизацию данных» и выбрать вид синхронизации УТ 10.3
2. Загрузил «Настройки для второй базы» — указал путь к каталогу (папке с фалом обмена)
3. Далее все без изменений, и данный не загружаются ({Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(13038)}: Тип не определен (РегистрСведенийЗапись.АдресныеСокращения)
СоответствиеТиповДанныхДляЗагрузки().Вставить(Тип(ИмяТипа), СоответствиеТипа)
PS При выгрузке фала обратил внимание что имена узлов не совпадают, у меня после выгрузки из УТ имя файла «Message_УТ_БП» а после выгрузки из БП «Message_002_УТ»

Не проблема решил использовать другой вариант выгрузки из УТ, заменить имя узла БП (как менять код узла в БП 3.0 так и не понял) (Вариант 2)
В УТ
1. Иду «Операции» — «План обмена» — меня код БП на 002
2. Произвожу выгрузку, имя фала «Message_УТ_002»

В БП пытаю загрузить данные и результата нет.

Подскажите что я делаю не так?

Консультант 1С

Дата регистрации: 06.09.2008
Сообщений: 300

Ошибка навевает на вопрос:
адресный классификатор почистили в обеих базах перед обменом?
И, зачем Вы его вообще загружали — проблем и тормозов много, пользы — ноль

mycap420

Дата регистрации: 04.02.2016
Сообщений: 7

Геннадий Новосибрск, Не совсем Вас понял: адресный классификатор нужно чистить перед обменом (не знала, а это зачем?), а как это сделать в БП редакции 3?

Загружал что именно не совсем Вас понял?

Консультант 1С

Дата регистрации: 06.09.2008
Сообщений: 300

mycap420 пишет:

Цитата
Не совсем Вас понял: адресный классификатор нужно чистить перед обменом (не знала, а это зачем?), а как это сделать в БП редакции 3? Загружал что именно не совсем Вас понял?

«не…понял…не знала» — У Вас раздвоение?
Хотелось бы с кем-то одним в одном лице разговаривать, а то как-то тревожно-неуютно….

«а это зачем?» — как я написал ранее, процитированная Вами «Ошибка навевает на» это.
У адресных классификаторов в конфигурациях на обычных формах (в УТ10.3) и на управляемых (БП3.0) существенно разная структура .
У них даже название существенно различается — КЛАДР (для УТ10.3) и ФИАС (для БП3.0)…

«а как это сделать в БП редакции 3?» — меню Администрирование => Поддержка и обслуживание => Адресный классификатор => Очистить адресные сведения.
Я Вам настоятельно рекомендую минимально познакомиться с конфигурациями, меду которыми Вы настраиваете обмен

«Загружал что именно не совсем Вас понял?» — как я ранее написал: «адресный классификатор», вроде, ничего другого в принципе я не упоминал…

mycap420

Дата регистрации: 04.02.2016
Сообщений: 7

Геннадий Новосибирск, сделал как вы посоветовали (удали КЛАДРы в УТ и БП (в БП удалялись начерно часа 2)), и все равно результата ноль. Пробовал через каталог и прямым соединение баз, данные выгружаются из УТ и БП а загрузка в обе базы не идет. Возможно сможете еще что посоветовать.

PS У нас есть доступ к сайту итс 1с, но сколько я не пытался искать (поисковик там работает?) информации не нашел по обмену БП ред. 3 с УТ 10.3

Консультант 1С

Дата регистрации: 06.09.2008
Сообщений: 300

Вряд ли найдёте больше и актуальнее, чем написано в файлах Совместное использование.htm , находящемся в папке установок-обновлений, с поправкой на версии между которыми производится обмен:

• БП 3.0
  %appdata%1C1cv8tmplts1cAccounting3_0_43_241Обмены даннымиОбмен с конфигурацией Управление торговлей, ред. 10.3
  где 3_0_43_241 для версии БП 3.0.43.241
  Содержит файлы:
  — Инструкция по подключению правил обмена.txt
  — Правила конвертации.xml
  — Правила регистрации.xml
  — Совместное использование.htm
• УТ10.3
  %appdata%1C1cv8tmplts1ctrade10_3_36_1Обмены даннымиОбмен с конфигурацией Бухгалтерия предприятия, ред. 3.0
  где 10_3_36_1 для версии УТ 10.3.36.1
  Содержит файлы:
  — Инструкция по подключению правил обмена.txt
  — Совместное использование.htm
  — Правила конвертации.zip
  ZIP содержит:
  — CorrespondentExchangeRules.xml
  — ExchangeRules.xml
  — RegistrationRules.xml

mycap420

Дата регистрации: 04.02.2016
Сообщений: 7

Геннадий Новосибирск, прочитал данный файл, появилась идея что после перехода БП с ред. 2 на 3 не делали изменения настроек плана обмена. Начал это делать при помощи обработки «Конвертация обменов с БП 2.0.epf» и застрял на выгрузке настроек из БП, выходит ошибка — Значение не является значением объектного типа (ИмяТипа)

Скриншот ошибки

http://images.vfl.ru/ii/1466069541/14fb1986/13041449.jpg

Консультант 1С

Дата регистрации: 06.09.2008
Сообщений: 300

mycap420 пишет:

Цитата
В БП 1. Администрирование — Настройки синхронизации данных, указал префикс «БП» и поставил галочку «Синхронизация данных» — «Настроить синхронизацию данных» и выбрать вид синхронизации УТ 10.3 2. Загрузил «Настройки для второй базы» — указал путь к каталогу (папке с фалом обмена)

Конечно, всегда советуют настраивать обмен из УТ (тем более, «односторонний»), но, наверное, это имеет смысл когда обе базы — для одной платформы (или 8.2, или 8.3)

Но, в данном случае БП 3.0 «знает» всё о том, как настраивать обмен с УТ 10.3 и это встроено в БП3.0, а УТ 10.3 «не знает».
При настройке обмена прямым подключении обычно папки и файлы не нужны, не нужны выгрузки-загрузки настроек из другой базы, первоначальная синхронизация справочников…
Я бы попробовал, сделав копии, снести настройки обмена в УТ10.3 и запустить настройку обмена с УТ10.3 из БП3.0 прямым подключением (а не через папки-файлы)…

mycap420

Дата регистрации: 04.02.2016
Сообщений: 7

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

В БП следующие ошибки из журнала регистрации:
Обмен данными.ОбменУправлениеТорговлей103БухгалтерияПредприятия30.Получение данных
1. {Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(14885)}: Тип не определен (РегистрСведенийЗапись.АдресныеСокращения)
                  СоответствиеТиповДанныхДляЗагрузки().Вставить(Тип(ИмяТипа), СоответствиеТипа);

2. Не удалось загрузить данные из «%1» (этап анализа данных).

3. Ошибка, Получение данных; Объектов обработано: 0

В УТ ошибки обмена
Обмен данными.ОбменУправлениеТорговлей103БухгалтерияПредприятия30.Узел 002.Загрузка данных
Ошибка при загрузке данных: {Обработка.КонвертацияОбъектовИнформационныхБаз.МодульОбъекта(12844)}: Тип не определен (РегистрСведенийЗапись.СведенияОбАлкогольнойПродукции)

Подскажите что еще можно сделать?

Консультант 1С

Дата регистрации: 06.09.2008
Сообщений: 300

Давно назрел вопрос — какие версии у БП 3.0 и УТ10.3, которые сейчас обмениваются?

Было упоминание, что обновляли БП 2.0 до БП 3.0 — с какой версии до какой?

Такое впечатление, что ошибки на обмене данными, которые и не нужны…
Можно попробовать их исключить из обмена. В обеих базах должна быть обработка

• Регистрация изменений для обмена

с помощью которой можно попробовать исключить из обмена ненужно-излишнее

	Я
VorHel 26.05.17 — 15:06	Здравствуйте. УТ1 обменивается, пишет, что обмен прошел успешно. БП 3 отрицает факт загрузки данных, видит только выгрузку из БП. Единственное, что УТ11 пишет «нет транзакции». Причина непонятна… УТ файловая, БП серверная. В обеих базах оставила остановку по ошибке. Не остановилось ни в одной. В чем может быть дело?
yzimin 1 — 26.05.17 — 15:15	в БП журнал при ошибке загрузки что пишет?
VorHel 2 — 26.05.17 — 15:19	В БП отсутствует запись о загрузке. Говорит, последняя загрузка 17 мая.
VorHel 3 — 26.05.17 — 15:20	А выгрузку правильно отражает, типа «10 минут назад».
yzimin 4 — 26.05.17 — 15:23	Обмен через файл или прямое подключение к базе?
VorHel 5 — 26.05.17 — 15:26	Прямое подключение. Отладку к запущенным УТшкой процессам в БП3 подключала, остановки по ошибке не происходит.
yzimin 6 — 26.05.17 — 15:33	(5) В отладке включите фоновые задания, через них обмен
VorHel 7 — 26.05.17 — 15:48	Подключены ив УТ, и в БП. Не останавливается. Говорит, что обмен прошел успешно. Серверная-серверная то же самое… Но БП факта получения данных не видит вообще.

конфигурация Управление торговлей 11.0.9.15. В узле обмена заполнили все реквизиты, при нажатии на Выполнение обмена данными нет загрузки и выгрузки заказов. В журнале регистрации при этом возникает ошибка : Интерактивный обмен произошла ошибка нет транзакции. Кто может подсказать, что за ошибка и как ее исправить. Компания Битрикс пока ответа не дает.