Суть в чем?
Выгружаю в файл send получателю все объекты, зарегистрированные для него.
У получателя загружаю эти объекты из файла send.
Если загрузка успешна, переименовываю файл send в файл read.

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

Конфу передаю автоматом, целиком, процедура тоже реализована.


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

(115) Просто, если не отлаживать свой код, то можно написать большую кучу никому не нужного неработающего кода.

P.S. посмотри просто приоритеты изменений.

(115) и сделать новые ошибки, которые потом будет проще не искать а писать новую схему

и так до бесконечности :)

(115) Там на коленке написать сравнение объектов по метаданным. А объекты считываются через сериализатор. Зато можно найти причину, что бы не напороться на неё в своей схеме.

(116) (117) если уйти от порочной схемы на более простую, ошибок будет меньше

(115)  нифига не проще
Комуто просто было влом работать кропотливо
То ли тебе
То ли франчу

Даже как неспец совсем тупо бы сделал по факту установки расхождения между базами методом половинного деления восстановление из бэкапов базы там и тут и сравнения объектов там и тут

(119)  простые схемы имееют тенденцию превращаться в сложные в условиях отсутствия возможности четких регламентов

(90)предположим последнее сообщение имело номер 99

я записываю док1 (версия 221)
делается выгрузка пакета с номером 100
подтверждения нет....
я снова меняю док1 (версия 222)
выгружаю пакет (номер его будет то же 100, ведь состав пакета не изменился...)

Ради интереса проверил. 8.2.19.90. Создал конфу с одним доком. КАЖДАЯ выгрузка имеет свой номер. Даже если ничего не менял в базе.

Так что ничего пропадать не должно.

(102) Небось в тестовых копиях работали регламентные задания обмена ))

(0) как конфу передаёте в вашей схеме?

(123) кстати очень может быть, классические грабли :)

Весь мир уже давно пользуется плодами прогресса, один только Гений1с до сих пор трахается с распределенными базами. Если найдется умный человек и покажет его руководству какие выгоды те получат от единой базы и прикинут затраты на РИБ и на единую базу начальство Гения будет просто в шоке.

А теперь по сабжу, по сути это лисепед очередной при чем без тормозов ибо тормоза придумал трус.

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

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

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

(130) Я бы на фронт в макдаке, 1с вообще бы не ставил.  Там впрочем именно так и сделали.

(131) так о каких плодах прогресса вы говорите, которые избавляют от секса с РИБом ?

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

(128) пАтамучтА лисапед он и есть лисапед. И нифига он не решает проблему обмена с 1000 точек розницы.
В мобильной платформе РИБ вообще не используется. Ввиду ограниченных возможностей платформы. А обмен работает и отлажен и методики выложены. Сырьоже их просто влом изучить. Начил изобретать лисапед.

(133) полно магазинов у которых на фронте 1с, для примера Hoff, 3 кита, да и вообще почти все хозяйственные, мебельные, автомобильные и т.д.

разумеется на супермаркет 1с ставить это не айс, но это ПОКА !!!

И тут скорее дело в лицензиях а не в техническом развитии...

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

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

2. Упр конфигурация - там проги делают чего от них хотят, конфигурация меняется часто. От нее узлы - в магазины

---------------------------------------------
обмен продаж
касса -> база фронта магазина -> центральная база фронта -> урп центральная база -> упр база магазина

---------------------------------------------
обмен цены, номенклатура
урп центральная база -> упр база магазина
урп центральная база -> центральная база фронта -> база фронта магазина -> касса

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

(133) это не возможно получить инет в любой точке мира. в наших точках за уралом до сих пор файлики обмена на флешках переносят. причем не достаточно иметь просто инет, наверно вам не надо говорить, что он должен быть стабильным и широким.
не понял вашего вопроса. мы работаем на данных, которые на 95-97% показывают правду в учете, понимаем это и закладываем риски. Вы предлагаете отделу продаж не знать о продажах вовсе, чем знать что мы продали 10000 штук +-500штук?

(135) на практике фронт меняется очень часто, чем хотелось бы, вашу схему очень тяжело поддерживать

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

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

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

(141) и всё же представим, что звёзды сошлись и инет есть везде. о каком решении вы говорили ранее?

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

+(143) А то что кассиру нежрен делать в центральной базе это просто не обсуждается.

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

(145) Да,  именно так а все остальное от лукавого.

(144) я думал мы говорим о рознице, у которой ~1000 точек и о том как ускорить выгрузку\загрузку с этими точками ... (145) так и делаем :) но с каждой точкой обмен 2-3 минуты, а их 1000. сколько часов будем обмениваться? :)

(147) У вас в один момент времени база может принимать данные только от одной точки?

(148) давайте сразу перейдем к выгрузке? так как с параллельностью загрузки никогда проблем не было в платформе 1с

(147) А в чем проблема с сумарной выгрузкой? Уж точно максимум 2-3 секунды.

(149) А какие проблемы с выгрузкой?

(147) Для розницы я бы сделал регистрацию выгружаемых объектов из центральной базы по дате времени с индексом по дате времени. А при запросе данных выступала бы максимальная полученная дата.
Лучше конечно использовать номер транзакции. Но и даты достаточно. Всегда можно передавать избыточные данные и загружать данные с предварительным сравнением

152 в регистре сведений.

Да еще можно регистр сведений с ответами, где хранится максимальное время ответа от каждого магазина, для чистки регистра изменений

(147) такие вещи делают с промежуточной консолидацией, о чем я и писал ранее...

(124) целиком. выгружаю в спец каталог с именем файла например config_2014_03_22.cf

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

при входе если ГУ отвязан, он привязывается и перезапуск.

Плюс: перестали возникать ошибки "Конфа не соответствует ожидаемой".

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

(123) я такое встречал, да, но там номера сообщений мелкие, не грузилось. Да бывало такое, но это быстро находится и лечится. реально классические грабли. Проблема то не в этом.

(126) ты будешь удивлен, но Единая База рассматривалась и была послана .... в лес. Ибо гладко на бумаге, но я указал, где овраги. и слава богу.

(129) в чем будет гимор, интересно? гыгыгы.... в частном данном случае наоборот, решилась куча проблем. Особенно с блокировкой.

(133) вы батенька идеалист, наверное считаете что в любой точке москвы можно получить шикарный интернет. Вынужден вас разочаровать. Увы и ах, особенно в ТЦ порой с интернетом туго.

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

(136) не только. Еще на фронте нужна приемка товара, контроль остатков и ревизии.

(161) У вас конечности не с того места растут.
У меня, почему-то, даже в поделке на VbScript, которая через тот же самый драйвер работает, но она не только знала, пробит чек или нет, но и умела проверять, что он оформлен правильно в ЭКЛЗ.

(162) Вот когда начинается приёмка товара с вводом нового, то сразу возникает вопрос - как это вообще можно вести в единой базе или в РИБ, так как одинаковые товары вводятся разными операторами в разные позиции.
Поэтому, если нет электронного обмена с поставщиками и они не во всех точках совершенно одинаковы, то вообще нафиг не нужна попытка объединить базы - достаточно сделать базу, в которой будут консолидироваться результаты.

(157) вот это жестко.

(105) а я как раз про механизм передачи данных

(157) почитай на 50 оттенков мутнее, там как раз про такое

(161) Вообщем при пробитии чека аппарат возвращает код успеха. Если нет кода успеха - значит ошибка - в чем проблема принципиальная?

(161) это в любом ПО так, 1С не при чем
другое дело что 1с после поднятия могла бы и слазить в фискальник за информацией, пробился чек или нет.

(168) а если фискальник пробился и тут фигак связь пропала, 1с лезет - тайм аут однако, ну думает 1с - нифига не вышло, и откатывает свою транзакцию... результат очевиден...

(169) Просто, если связь пропала, то её нужно восстановить.
У меня, например, система перед пробитием чека запоминала номера операций в ФР-е и в случае потери связи проверяла сначала номера документов - если они не изменились, то операция на ФР-е не прошла, а если изменились и чек закрыт, то считается, что чек пробит.
Потом, отменять транзакцию в случае не пробития чека на ФР-е вообще нет смысла. Пробивать чек нужно не в транзакции, а отдельной обработкой, сделав запись документа до (с признаком начала пробития чека) и после (с признаком окончания).

(170) это все припарки мертвому, ненадежные. В DrvFr1C нет метода для проверки завершенности транзакции. Это странно. С таким подходом супермаркеты не автоматизировать, гыгыгы...

(169) да, там штук 5 комбинаций. комп может тупо перезагрузиться, когда чек пробьется, и 1с не получит подтверждение пробитости чека, например.

(163) как как. У товара ставится признак Новый и периодически новые товары синхронизируются, дубли заменяются. делов-то.

(163) на уровне драйвера можно все получить, да.
но 1с не позиционирует себя как надежное решение для розницы, т.к. в типовом драйвере DrvFR1s нет возможности для проверки законченности транзакции. Вот и вся малина

(174) В типовом драйвере есть метод, позволяющий получить состояние ФР-а и даже данные из ЭКЛЗ, чтобы не только понять состояние последнего чека, но и нужного чека по номеру - у меня так и работало. Причём, дату-время завершения чека только из ЭКЛЗ и можно получить, так как получение даты-времени до начала завершения чека не даёт гарантии, что он именно тогда завершится.
Конечно, всё без танцев с нескольким количеством бубнов не обходится, но, если захотеть, то всё получается.
И база данных в текстовых файлах тоже получается.

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

вместо того, чтобы настроить и использовать штатный риб, горе-одинесник тратит уйму человеко-ресурсов на безобразную г0вноподелку сверху.

гнать сцаными тряпками!

+ (176) Помимо прочего РИБ в мобильной платформе не поддерживается. Но методика обмена прописана в штатной документации. С использованием планов обмена и фильтрацией по реквизитам участвующих в обмене данных.
Одна пичаль. Это читать надо. И не пропишешь "мой гений дарит вам". А к "безобразную г0вноподелку" - влегкую.

На самом деле, проблема работы ФР даже не в драйвере - она глубже.
Начнём с того, что ФР как и любой принтер - пассивное устройство, то есть оно не умеет передавать команды в компьютер, а только отвечает на переданные компьютером.
В случае печати и завершения чека фискальные регистраторы Штрих-М (и Атол, так как они "потомки") выполняются команду за два этапа - сначала проверяется режим и возможность выполнить команду, потом выполняются вычисление и выдаётся ответ компьютеру, а только после ответа начинается печать чека.
Поэтому, чтобы узнать у ФР-а напечатал он чек или нет - нужно давать отдельную команду - запрос состояния (для ФР-а Штрих-М не так часто, так как эта команда очень замедляет исполнение печати).

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

(179) Как раз у Штрих-М фискальник отвечает "закрытие чека выполнено успешно" и только начинает печатать чек. Понятно, что отменить чек после этой команды нельзя, а критические ошибки ФР-а рассматривать не обязательно, так как после них ФР отправляется в сервисную организацию, но, например, окончание бумаги в процессе печати требует выдать пользователю сообщение о том, что её нужно заменить, а также дать команду продолжения печати, чтобы допечатать чек на новом рулоне.

P.S. работа с ФР и другим торговым оборудованием с РИБ никак не связано.

(181) По вопросам обмена рекомендую http://its.1c.ua/db/pubintromobile#content:117:hdoc. Там есть все, что сырожа пытается представить прорывом.

(182) Правда там основным транспортным каналом рекомендуют Web-сервис. Но в легкую обмен дополняется обменом файлами сообщений. И это там тоже есть.

(183) Канал не важен - есть проблема, когда все узлы (например, вечером) должны обменяться с центром.

(184) Поделка от сырьожи эту проблему никак не решает.

+ (185) Нужна запись измененных данных - она должна быть выполнена. Параллельная запись в одну таблицу БД - это фантастика даже в исполнении сырожи.

(186) Параллельная запись в одну таблицу - для нормальных SQL-серверов - это повседневная реальность.

(188) Да ладно... Я же не настаиваю на том, что это невозможно. Я говорю, что при любом варианте записи нужно время. И переименование файлов из send в read этот процесс никак не ускорит.

(188) Ну, поставьте FireBird и посмотрите, как оно работает - можно даже в одну строку параллельно писать, только вот второму будет "сюрприз" при COMMIT-е.
Так что, думаю, взрослые SQL-сервера тоже это умеют, если не из коробки, то после настройки.
Просто, если "хорошим" программистам 1С дать такой инструмент, то "гвоздей назабивают аш мама не горюй".

(169) речь про другую ситуацию, когда 1с рухнула.
фискальник сам по себе очень надежен и его ПО падает на порядок реже.

(191) Можно перед пробитием чека записать его содержимое в текстовый файл, чтобы потом можно было восстановить.
Но, если сделать запись до пробития и запись после, то ничего теряться не должно.
Случай, когда база 1С "отправилась коту под хвост" мы не рассматриваем как и случай, когда "за фискальником пришёл белый лис".

Если не ошибаюсь, то для избавления от проблемы блокировки при выгрузке (и если не страшен риск ущерба целостности данных) достаточно установить размер транзакции = 1 (ну или 100).

(175) и как называется типовой метод из DrvFr1s, дружище? гыгыгы...

(176) штатный риб не значит лучший риб. ;-)
горе поделка работает лучше штатного риб, как быть? чую холивар

(191) вот именно. 1с упала и чек не получит подтверждения от фр.

(191) или кабелек задели и подтверждение не прошло в 1с.

(192) она не отправилась, комп перезагрузился. Скажем так, при объеме 100 магазинов с нагрузкой 100 чеков в день в среднем случалось 2-3 коллизии с ФР при штатной схеме подтверждения.

не забудьте также, что типовая 1с ставит статус пробит и пытается перепровести чек, а перепроведение чревато неудачей (при блокировках), так что типовая Розница весьма крива в этом плане.

(193) да, об этом есть моя статья на ИС, вот как раз после этого и начались потери данных. ;-)
поэтому перешел на альтернативный РИБ.

(182) Стыдно давать ссылки на закрытые ресурсы, не комментируя содержимое.

(198) штатные схемы вообщем страдают херней обычно. Хочешь чтобы работало устойчиво и быстро - надо переписывать. Это еще и на семерочной рознице так было.

GetEKLZDocument ПолучитьДокументЭКЛЗ
Метод позволяет по номеру КПК, который следует указать в свойстве KPKNumber, извлечь из ЭКЛЗ и распечатать документ, соответствующий этому номеру. Перед вызовом метода в свойстве Password указать пароль системного администратора. В свойство UDescription возвращается название ККМ из ЭКЛЗ.

(201) Лучше смотреть в сторону GetEklzState, так как там можно увидеть дату и время последнего документа.

------------------------------------------------
eeeio
193 - 17.03.15 - 03:10
Если не ошибаюсь, то для избавления от проблемы блокировки при выгрузке (и если не страшен риск ущерба целостности данных) достаточно установить размер транзакции = 1 (ну или 100).

------------------------------------------------
Гений 1С
199 - 17.03.15 - 10:11
(193) да, об этом есть моя статья на ИС, вот как раз после этого и начались потери данных. ;-)
поэтому перешел на альтернативный РИБ.


------------------------------------------------
Прикольно, сначала появились блокировки

Г1С придумал отменить транзакции и распиарил это на инфостарте
потом именно из-за отмены транзакции пошли пропадания данных
и тут Г1С стал бороться с потерями данных (вместо того, что-бы признать, что сделал ошибку и вернутся к проблеме блокировок) он опять начинает изобретать сомнительную схему и ее пиарить....

ничего в нашем мире не меняется !!!

Размер транзакции в 1 объект не должен приводить к потере данных, так как транзакция всё равно будет отрабатываться.
А вот отказ от транзакций вообще действительно может приводить к потере данных из-за блокировок, которые таким образом отменили.

(205) если транзакция отменяется, то и вся выгрузка отменяется как бы. не вижу проблемы

(209) та ладно, мы вот как бы не видим проблемы юзать стандартный механизм риб (слегка отшлифованный)

(210)+ вместо какой то неведомой ...

(210) я список преимуществ написал, ты видимо его пропустил мимо ушей. В моей схеме меньше блокировок, например, т.к. при выгрузке таблица изменений не блокируется.

Не знаю как реализация, но сама идея пообъектной выгрузки и пообъектного снятия регистрации горазда лучше типового 1с риба и пачками изменений

(213) гы, а пухнущая база не мешает? когда 100+ узлов? для каждого нужно каждый измененный объект хранить не? вместо пакета?

(213) Эта идея как раз и тесно связана с "Потерей данных при обменах. Непонятно почему происходит, началось после введения параллельных выгрузок на точки."

Вы же тупо теряете ссылочную целостность. Аккуратно ее восстанавливать и есть решаемая задача.