Здравствуйте. Обмен РИБ между центральным узлом и магазином настроен через отправку почтовых сообщений. По типовой процедуре при закрытии смены все чеки меняют статус из "пробит" на "архивный", с документа проводки снимаются. Формируется Отчет о розн. продажах. При обмене с центральным узлом по журналу регистрации видно, что каждый чек записывает данные по регистрам, хотя после окончания обмена у документа "Чек ККМ" со статусом архивный проводок нет. В чем может быть дело?

А кто сказал, что должны быть?

(1) поясните, пожалуйста

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

Стоп. Версия платформы.

версия платформы : была 8.1.15, перешли на 8.2.19.130 - из файловой базы на центральном узле на sql

Попробовать откатиться на 8.2.18.

(6) а как от версии платформы обмен зависит?

Регистры включены в состав плана обмена, каждый архивный чек не пишет проводки при обмене, а удаляет их

(7) Есть доступ на партнерку?

(9) нет

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

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

(11) ЯННП

(12) ?

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

(0) ты сразу напиши про ситуацию : ты только настроил и сразу стала проявляться ошибка или настроено давно , всё работало и вдруг ошибка стала периодически возникать ?

сколько периферийных магазинов - в каких из них ошибка ?

(13) http://goo.gl/SfmHlQ

магазинов больше 20, база центр узел - больше 30 ГБ, ошибка изначально превышен допустимый размер файла - на SQL выяснилось, что таблицы по вложениям эл. писем более 4 ГБ - очистила, следующая - подходит по чекам ККМ, т. е. оставлять в файловой версии в таком состоянии базу не вариант, на SQL - обмен очень медленный... в общем как то так

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

(16) ты не написала - в скольких магазинах наблюдается эта ошибка.

Надо смотреть на примере одного магазина по Журналу регистрации - на каком то этапе у тебя от узла в котором проводится ОоРП и на котором ЧекККМ становится архивным,  инфа не проходит обратно в периферийный узел. И тот периферийный узел снова посылает инфу что ЧекККМ "пробитый". Проверяй по ЖР когда это происходит и почему.

(18) спасибо, хорошо

(16)

>> на SQL - обмен очень медленный..
Всегда бывает наоборот, надо только SQL уметь настраивать корректно и админить его постоянно: прирост правильн осделать, реиндексации делать, статистику обновлять каждые 24-часа (или каждые 24 минуты - везде индивидуально).
Можно почитать тут - вроде в открытом доступе
http://its.1c.ru/db/metod8dev#content:5837:hdoc:_top:очистка%20процедурного%20кэша

>> центр узел - больше 30 ГБ
его надо было перевести на SQL уже поле 10 Гб
а лучше сразу было сделать на SQL

(0) >> Обмен РИБ между центральным узлом и магазином настроен через отправку почтовых сообщений

Это трындец догадались сделать. У нас сообщения обмена на одном проекте были - xml-ки по 30 Гиг - сжимаются примерно в 30 раз - т.е. получалось бы письмо с гиговым вложением. Вот запулите гиг в какой-нибудь почтовый клиент - и посмотрите, что получится (с клиентом и почтовым сервером).
Единственный корректный способ обмена для рознички, если не в локальной сети, это по ftp - собственно для того придуман этот протокол, чтобы не гонять большие файлы данных.
ftp - наиболее стабильно с платформой себя проявляет виндовый встроенный в winserver (только права ему надо корректно настраивать и фиреволами закрывать).

(18) + именно так и бывает обычно.

(20) к предпоследнему абзацу: чтобы не гонять большие файлы данных по другим протоколам.

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

ещё можно обмен по веб-серверу

как вариант убрать обмен РИБ по чекам ККМ и оставить только по отчету о продажах.

(24) многие типовые отчёты используют данные не из регистров , а обращаются к документам ЧекККМ. Правильнее всё же - найти где появляется ошибка и устранить её.

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

(20) спасибо, буду проверять, ну вроде сисадмин опытный настраивал, про ftp да мысль хорошая, еще интересно, на магазинах базы многие уже по 10 ГБ, получается, выход только новый образ делать (с оприходованием)? рабочее место кассира виснет, открывается в лучшем случаем мин 20... Сам новый образ только со справочниками уже 4 ГБ

(26)  ты знаешь , что в определенный день и час у тебя в центр базе данный ЧекККМ был архивный , а потом позже в определенный день и час этот ЧекККМ стал снова пробитым , то выводишь Журнал Регистрации за этот период и первое что ищешь - в какой момент произошло изменение.

Я привык выводить с отбором только по виду документа , но НЕ по данным - так быстрее. А потом выводить в табл документ и искать "поиском" , но это детали.

Нашел момент изменения - смотришь - какое письмо , когда оно было получено. Потом - в базе которая отправляла - когда было отправлено. Так сопоставляешь - почему на момент отправления из периферийной базы ЧекККм был пробитый.