Приветсвую. Все было хорошо пока не выскочила ошибка при обмене в переферийной базе - Ошибка при выполнении обработчика - 'ПередЗаписью': {ОбщийМодуль.ПроцедурыОбменаСРозничнойТорговлей.Модуль(1138)}: Значение не является значением объектного типа (Склад)

Конфигурация на поддержке, ничего не меняли.

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

(36) Видимо остается один вариант - Отладчик в руки и вперед!

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

(38) Может и ваши гланды так удаляют), но не помню ваших предложений по отладчику и объекты обмена.

Повторю (3) - ищите ошибку в данных и устраняйте.

А совет в (23) (кстати, Вами уже забытый) - это не лекарство и/или устранение проблемы, это разовый обход ошибки ради завершения текущего обмена. От проверки данных Вас никто не освобождал.

(39) а нужно чтоб каждый, кто прочитал ветку в обязательном порядке лично повторил, что без отладчика эту проблему решить не получится?

Кстати: а что за алгоритм находится в строке 1138? Нет, мне так просто, чисто... любопытства ради.

(42) Склад = Регистратор.СкладОрдер.Склад;

(42) :) и как его увидеть, если конфигуратором туда не сходить... у меня тоже подозрение, что там могли дописать чего-то крайне полезное

(43) это по факту проверка получаемое внутри регистратора ссылки на ссылочную целостность, скажем так, "на лету"

(43) Ыыы... лучше бы ты этого не говорил :(

Вам на консультацию к (30). А я тут мимо проходил - у меня реальный РИБ.

(44) Упс, забыл добавить в (38):

   *
(место для таблички "Сарказм!")

(47) а че не так то со строкой?

Я бы предположил, что нужно отдельно загрузить нужные элементы справочника Склады (или как он там в конфе назван правильно) .

Самое адекватное решение : создавать план обмена "ОбменДаннымиНСИ", вписать в него подобные, сколнные к сглючиванию справочники и регистры сведений, затем вешать на регулярное выполнение этот план.
Если так сделать, то вероятность граблей сильно понизится, но в ноль все равно не исчезнет. Это будет зависеть от интенсивности создания новых элементов НСИ.

(48) не так, что в обработке данный в обмене идет обращение к полю "через точку", при том, что :
Регистратор - это выгружаемый объект
СкладОрдер - так же выгружаемый, причем он должен быть правильный не только по содержанию, но и по типу, т.к.
обращение "через точку" .Склад само по себе уже потенциальный источник ошибок реквизитов составных типов

Если СкладОрдер успеет загрузиться в Приемник до обработки объекта Регистратор - не будет ошибки. Не успеет загрузится (пусть будет даже в том же пакете, но позже Регистратора, например) - будет ошибка.

(48) Бред какой-то получается, непривычно как-то - во-первых обращение "через точку" в регистраторе; во-вторыхполучается "склад в складе". Не знаю как там в Казахстане, а по мне привычнее "Склад = Регистратор.СкладОрдер;", ну или Склад = Регистратор.СкладОрдер.Ссылка;". Хотя сама по себе такая конструкция в обмене - дико для меня. У Вас что, план обмена по складам что ли?

Нужно смотреть в конфигураторе метаданные - тип реквизита "СкладОрдер" и действительно ли в этом справочнике есть реквизит "Склад". Если "СкладОрдер" - иерархический справочник или там связи типа "место/склад", то можно ради эксперимента (в копии разумеется) все записи этого/этих справочников зарегистрировать к обмену, мигрировать их в ПБ, а уже после этого прогнать вновь это сообщение обмена (которое спотыкается с ошибкой)... но чувствую что не так всё просто :(

(50) Эээ... мелочь, но: не исключаю что это движения документа (возможно записи регистра накопления) так странно мигрируют (возможно с отбором по складу)

(51) повторюсь-конфига на поддержке, никто ничего в ней не менял. работало ж раньше

Если Регистратор.ВидПоступления = Перечисления.ВидыПоступленияТоваров.НаСклад Тогда
                
                Склад = Регистратор.СкладОрдер;


Может какои документ порыть, где не указан параметр склад?

(53) чего вы паритесь? посадите бухов, пусть просмотрят все документы, где-то или не задан склад, или битая ссылка на склад.

(54) если они просто создали в центральной базе новый элемент Склад, обмена по этому элементу не было, или он не был загружен в силу какой-то ошибки - затем пишут свежий документ с таким складом = должна быть такая же ошибка

(54) Да Вы садист оказывается :) Имхо, достаточно их наказать просмотром зарегистрированных изменений. Но что-то мне подсказывает, что это не бухие виноваты в таком бардаке с данными.

(53) Хочешь фокус покажу? Я умею штатной обработкой удалять данные, на которые есть ссылки. Фокус в том, что удаляю водном узле, а ссылки - в другом узле. Они со следующим обменом поступят... а может быть и нет если судить по этой ветки :)

(55) на прошлой неделе бухгалтер поменяла шрифт и размер названий складов.

(56) Вы наверное хотели сказать мазохист? Не,я не такои. Есть проблема у меня и ее надо решить.

вот только какое отношение это имеет, если копии ДТ и конфиги я сделал этой ночью

(58) угу. Как в том анекдоте: я ему доказываю, что не изменяла, а он рогом в землю уперся и не верит

(59) сравни в списках количество складов в разных базах, ну и ...

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

(61)в ЦБ куча. С розницей с кассами.

с филиалами)

(61) все одинаковое. и количество и название

Иногда не успевает прийти файл обмена через инет и начинается новый сеанс. Отключи автоматический обмен и убедись в том, что файл обмен пришёл локально на компьютер. Запусти пару обменов вручную. А склад добавь в состав обмена, чтобы заново пришёл

(64) ну на грани гипотетических предположений :
- прямо сейчас в какой-то периферийке Ха есть такой склад, которого нет в периферийке Игрек. Из периферийки Ха выгружают транзитный документ, он благополучно мигрирует в Центральную, а при миграции в Периферийную его в обмене нет.

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

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

Выгрузил с ЦБ и загрузил в ПБ обработкой-Выгрузка и загрузка данных XML турбо v0.9- склады, результат 0. Выгрузил загрузил документы возврат покупателей (за последние 10 дней)-обмен заплясал. Вот а в чем проблема была-не понял.

забыл-до выгрузок искал может не догрузилось или удалил кто документы возврата, нашел в ПБ битую ссылку на возврат от 3го сего месяца, как раз в эту ночь я снимал ДТшник. Получается выгрузка ИБ операция не надежная? Снимал ДТшку обновлятором 1С.

(68)  DT не является средством резервного копирования. Это во всех ИТС написано

Я тут ветку завел но ответа небыло. Как еще сделать копию ИБ?

(70) если файловая база, то в windows CtrlC-CtrlV

и еще вопрос по выгрузке-загрузке ХМЛ. Я визуально посмотрел документы возврата и склады-они не задвоились. Вроде бы. Стоит ли переживать за это?

(71)Скульная. Про бекап скль я в курсе). Как ее потом в фаиловую переделать? все равно ж ДТ нужен

(68) "нашел в ПБ битую ссылку на возврат от 3го сего месяца, как раз в эту ночь я снимал ДТшник. Получается выгрузка ИБ операция не надежная"

что-то хрень какую-то пишете. Именно за счет битых ссылок и обеспечивается надежность.

Например, у вас выгрузка в 2 этапа: документ, потом справочник Склады. После выгрузки первого этапа в документе в поле склад - битая ссылка, после 2-го этапа нужный склад встает на место, битых ссылок уже нет.

В этом вся фишка.

(74) или вы не так поняли или я. В конфигураторе  отладкои с остановкои при ошибке нашел у выражения(не помню сеичас уже) результат был <Объект не найден> (116:80f6a02bb831b5e911e8c72334edc306). В ЦБ посмотрел что этот гуид стоит на документе возврата покупателей. выгрузил его-загрузил в ПБ.

(75) ну и хорошо. в чем проблема? Так будет всегда, когда у вас загрузка прерывается посередине. Этих ОбъектНеНайден должно быть до сотни и более.

(75) Т.е. я это вижу, как подтверждение моего предположения:

Я ему доказываю, что не изменяла, а он рогом в землю уперся и не верит

Склады таки менялись, но в пб даже если попадают, то не вовремя.

Насчет задванивания не в курсе? никакои галочки не стояло.

провел 3 обмена, вручную, но фаил обмена от ЦБ почему то только чуть уменьшился в размере. 115 081 810 баит в не сжатом виде. Это еще что такое

От ПБ-1КБ.

(79) а как ты ожидаешь уменьшения файла вызгрузки из ЦБ, если не принимать ответные пакеты от ПБ ?

(81) так я ж не тлько на ПБ его делаю. по очереди, туда-сюда, и наоборот. В общем каждая база по 3 сделала. Внутренние заказы допустим упали в ПБ.

И обе базы в процессе обмена пишут что-прочитал, загрузил изменил.

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

Всё просто и легко проверяется: остановил работу юзверей и регламентных заданий (или воспользовался моментом, когда они не работают); провёл сеанс взаимных обменов между узлами; посмотрел зарегистрированные изменения - их не должно быть; посмотрел в ЖР - там не должно быть ошибок обмена; номера принятых/переданных сообщений в узлах должны измениться. Всё просто.

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

Тридцать три несчастья у автора :) Ветка навеяла:

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

Может, что-то в консерватории подправить?

и снова здравствуйте. Видать загрузка складов и возвратов ничего особого неисправила. снова ошибка ОбщийМодуль.ПроцедурыОбменаСРозничнойТорговлей.Модуль(1138)}: Значение не является значением объектного типа (Склад) Чтение данных из файла обмена завершено с ошибками!

Если Регистратор.ВидПоступления = Перечисления.ВидыПоступленияТоваров.НаСклад Тогда
                
                Склад = Регистратор.СкладОрдер;
                
            Иначе
                
                Склад = Регистратор.СкладОрдер.Склад;
                
            КонецЕсли;

(88) видимо

Регистратор.СкладОрдер  объект не найден

поэтому

Регистратор.СкладОрдер.Склад выдает ошибку

(88) точка останова ставится в эту строку

Склад = Регистратор.СкладОрдер.Склад;

?

Смотри на этот регистратор, найди его в базе Источник и проверь что там по виду документа, есть у него заполенный реквизит СкладОрдер и если заполнен, то смотри существует этот реквизит в базе Приемник или нет.

и еще не мешает посмотреть в принципе какие разрешены типы у поля СкладОрдер - там же ВидПоступленияТоваров получается не равен Складу, а тогда что это за объект такой? Почему он или не выгружается в файл обмена или у него нет заполненного поля Склад

Регистратор = <Объект не найден> (116:80f6a02bb831b5e911e8cc8876f93ba2). Нашел обработку которая по которой нашел возврат товара от покупателей. На что обратить внимание? Склад указан. (основной который всегда указывают)

(92) так а сам Возврат товара от покупателей в обмен включен?

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

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

да на переферийкии. Как включить эти документы в обмен? Регистрация изменений для обмена-возврат товаров от покупателей-добавить регистрацию?

(95) а нужен он на чужих базах? там надо не его включать в выгрузки, а проверять или условия, которые регают набор записей возвраты на "левые" узлы, либо при выборке зареганных изменений и записи их в пакет обмена отлавливать, что это такой набор записей, который никуда не нужно передавать.

Развернул обекты для обмена. вижу этот документ возврата в центральной. то есть он передается?

Может зарегистрировать Склады для обмена в центральной?

(97) из периферийки в центр - конечно! Иначе как бы оно в центр смогло залезть без ошибки?!

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

(98) Склады в данном случае ничем не помогут - ты же сам увидел, что нет именно документа-регистратора в обработке загружаемых данных на Приемнике

(0)Похоже на попытку получения значения реквизита у битой ссылки или чего то вроде неопределено

(96) вот тут интересно стало. А без этого документа, на переферийке остатки разве не собьются?

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

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

* с этим документом - с этим документом возврата

(99) да стоит авторегистрация.

я так понимаю. Обмен перестает работать тогда, когда в централке внесят новый документ возврат товара. Об него а точнее об документ основание спотыкается. Возможно что  документ возврата создается в 1СРознице , после обменом идет в УТ, а с УТ централки идет уже в переферийку которая спотыкается при обмене.

(105) слово Возможно-пропустить

(105) Да. Именно в такой последовательности.
Если Возврат от покупателя в центре никто не принимает - а его принимают там, где его продали покупателю.
Иногда бывает (я такое видел на практике), что возврат от покупателей на рознице оформлять запрещено, а есть распоряжение руководства, чтоб его делали ручками только в центре. Ну тогда в обмене и будет глюк 100% не потому что программа дура, а потому что не учли такой вариант руководства. Такое вообще редко бывает, чтоб регали возвраты только на центре, но все же бывает.

В любом случае, нужно в процедурах обмена и в планах обмена поработать напильником :-)
Но уже ясно (мне, как минимум) где и в чем конкретно.

(107) Поделитесь?

Еще. Узнал у операторов что-чаще всего возврат делают в Рознице. В УТ редко и эти редко как то влияют на обмен.

(109) дык, не просто "как-то влияют", а конкретно глючит.

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

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

Немного не так сказал. То есть когда делают возврат товара с УП ЦБ то обмен летает, они документом основания делают Отчет о продажах, а когда делают возврат товара с Розницы то-нет документа основания, а привязка идет к чеку ККМ. Вот. Между УТэшками есть док.т основание. А между Розницей и УТ нету)))..

И вопрос тупой. Между ЦБ и ПБ должны быть одинаковые списки регистраций для обмена? То есть запретить авторегистрацию я не могу, а добавить регистрацию или удалить могу. Вот список этих добавленых должен быть одинаков?

Я к тому что ЧЕКуККМ не добавлена регистрация в ЦБ. Сеичас добавил так там более 2000 чеков ждут обмена.

(110) Если возврат не нужен в ПБ, то как я отключу обмен этими документами? Повторюсь, конфа на поддержке.

(114) Если очень захотеть, то саму процедуру, пишущую в файл обмена, можно разместить в обработке. Тогда и конфиг останется "на замке" и файл обмена соберется такой, какой нужен. Не самая быстрая доработка, конечно, но сделать можно.

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

(115) а на вопрос (112) не ответите?

(116) можно посмотреть, что это такое у вас "списки регистраций для обмена", скрин сделать и выложить?

чтоб в терминах не путаться, а на скрине понятней будет

Ну что тут, в трех словах?

(119) :)
ошибка из-за попытки загрузки в ПБ набора записей регистра без самого документа регистратора этих движений. Не складов, как предполагали в самом начале, а документа.

вот

http://programmist1s.ru/wp-content/uploads/2014/05/registratsiya-izmeneniya.png  картина с инета

я то том где написано зарегистрировано 55

Вопрос такой- на ЦБ и ПБ одинаковые "строчки" должны быть зарегистрированы?

(122) колонка с зелеными пометками и числами, сколько экземпляров объектов помечено. Зеленые пометки относятся к тому, что по метаданному, вкл в состав обмена разрешена авторегистрация. Непосредственно по составу метаданных - состав с обеих сторон обмена одинаков. Далее, если установлена зеленая галка на авторегистрацию в этой обработке, то и попадание в обмен должно быть одинаковое с обоих сторон. Может быть такое, что в состав метаданное включено, но авторегистрация не включена. В этом случае, должно быть исполнение где-то программного кода (в подписке по событию ПриЗаписи..., например) , которое закончится строчкой вида:
ПланыОбмена.ЗарегистрироватьИзменения(Узел, Выборка.Ссылка);

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

не совсем поняли

https://ibb.co/nLGaZU обратите внимание на первую строчку банки

и вот

https://ibb.co/n49OM9

это я добавиол регистрацию банков. А есть допустим чеки ккм, так если там раскрыть то появятся более 2000 строчек этих чеков. Что дает добавление к регистрации чеков)?

(120) Прикладной код требует определенного порядка загрузки (чтоб регистратор вперед движений), так?
Код типовой что ли?

https://ibb.co/cdy8M9 это я в тестовои базе, ДТшник которорй я снял в ЦБ вчера. Может так быть что изза того что эти чеки не выгрузились(или откуда эти 20 000) и не идет обмен, т.к они выступают в качестве документа основания?

ДАже не 20 а 30 000

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

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

(127) код типовой, да.
Там выявлен конкретный документ. Документы этого вида в принципе не выгружаются в указанный периферийный узел, а набор движений попадает, т.к. движения по регистру идут с признаком авторегистрации (в составе плана обмена вкл авторегистрация)

А, ну это нормально - в Рознице (или УТ, не помню уже) так остатки товаров передаются в движениях чеков (сами чеки не передаются)

(в конфах на ОФ)

Интересно как. Началось все с -  Ошибка при выполнении обработчика - 'ПередЗаписью': {ОбщийМодуль.ПроцедурыОбменаСРозничнойТорговлей.Модуль(1138)}: Значение не является значением объектного типа (Склад) .

А оказалось чеки.
(130) Тогда может принудительно выгрузить чеки и воврат товаров? На ночь поставить, пусть синхронизируются.

Еще по размеру смотрю фаила обмена, с 5 МБ(в архиве) уменьшился до 2х. А дальше не уменьшается. Хотя минимум у меня в этих обменах был 100 КБ.

(134) фиг его знает.
По моему мнению, там не добавлять нужно новые объекты, а наоборот - убирать из обмена не нужные.

Возврат товара - если его сделали в центре или он уже попал в центр, то его уже нет необходимости в ПБ передавать именно возвратом.

Или возврат рождается непосредственно на том складе, где физически есть база и затем перемещается (другими документами)
Или товар с возврата просто уже никуда больше не перемещается между складами, а уезжает после оформления возврата прямо к поставщику.