Задача следующая.
Есть скажем 2 БД (одна из них 7.7 SQL) разнесённые по двум серверам. Один из них бэкофис а другой фронт обслуживает и необходимо при проведении продажи чотбы чек/накладная автоматически появлялась в базе бэкофиса.
Т.е. необходимо из одной БД формировать документ (и проводить) в другой не задействуя OLE.
Рассматирваю вариант с прямым физическим вмешательством в БД на уровне таблиц СУБД но если что касемо получения данных всё более менее понятно (тем более в 8.2.14 где есть работа с внешними источниками) то вот касаемо повторения механизма платформы который задействован при создании и проведении документа у меня тут пробел.

Может занимался кто подобным ?

pailЕсли вариант подходит - могу и код семёрочный процитировать

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

спасибо подумаю... может и выкрутимся :)

pailLast1Cmenпропущено...


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

спасибо подумаю... может и выкрутимся :)
Не совсем так. В справочнике "изменения" - только ссылка на измененный объект (маркер изменений), и ничего кроме этого.
Внешняя БД по этой ссылке читает 1sjourn DHxxx DTxxx и удаляет маркер прочитанного объекта. Или помечает его как прочитанный.

а... не
в БД иннициаторе этого документа не будет вообще :)

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

вот думаю в качестве фронта сделать 8чную разработку и повесить на неё с точек тонких клиентов (8чных)
слава богу с 8.2.14 появилась возможность подключать в качестве источников таблицы других баз так сказать "напрямую" т.е. при продаже на точке я смогу вытянуть как остаток товара так и его характеристики (которые ведутся в 7чтоной базе) а вот обратно с точки надо как-то передать факт самой продажи... т.е. как-то сообщить 7ке что была осуществлена продажа и чтобы в ней сформировался этот самый документ продажи

т.е. 8ка по сути играет роль "прокладки" между точкой и центральной уже 7чной базой
как-то так вобщем

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

ну а идти путем планировщика + конвертации для полного автоматизма это сильно "тонкий" метод имхо (сильно много составляющих больше подходящих для ручного режима обмена нежели автоматического)

не... таки сначала попробую через вспомогательные таблицы (в 7ке обрабатывать их с помощью 1С++)

Злой БобрLast1Cmen,

УРБД я так понимаю неподходит?..
Если база скульная то пишем триггер и в нем создаем документ в нужной базе.
Если ДБФ то опрашиваем БД время от времени. Тут или ADO, или OLE.

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

Внешние источники данных - они только для чтения,на запись не работают.

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

авторУРБД я так понимаю неподходит?..
нет... сильно много объектов (не одна сотня... а файловый режим обмена даже у 8ки для такого количества скажем так довольно сильно хромает) плюс требования к тому чтобы небыло никаких данных на самих объектах вообще :(

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

AHDPLast1Cmen,

А какие временные параметры предъявляютсмя к решению? Остатки в 7.7 будут меняться не только движениями из 8ки?



конечно... 8ка отвечает только за передачу данных о товаре на клиента и возврат обратно самого чека/накладной и всё... остальные операции в 7ке

AHDPЕсли канал хреновый, то лучше веб-интерфейс юзать. Тонкий клиент ещё хуже RDP.

там от него требуется получить с десяток параметров при сканировании штрихкода (причем это не потоковый ввод т.е. задержки в 5-10 сек вполне допустимы и в одном чеке 1-5 позиций обычно) да отослать такой же десяток обратно в принципе обратно и всё... на мобильном интернете (32-120Кб проверял, достаточно... главное чтоб в момент транзакции была связь)
а почему не вэб ? торговое оборудование будь оно неладно :(

AHDPLast1Cmenпропущено...


конечно... 8ка отвечает только за передачу данных о товаре на клиента и возврат обратно самого чека/накладной и всё... остальные операции в 7ке
И только ради этого изобретать велосипед?

угу
костыль между клиентом и бэкофисом но умеющий работать по тонким каналам

AHDPLast1Cmen, не думаю, что реализовать работу со сканером штрихкода через web большая проблема. У Штриха наверняка есть готовое решение.

а весы ? фискалки ?

на крайний случай думаю можно удет убедить хранить обороты (чеки) хотябы одну смену и "подчищать" их в 8ке автоматически после переноса в 7ку в ручном режиме (всё равно людям в офисе необходимо контролировать чего там понапродавали на точках)

но хотелось бы конечно "автоматически" сразу передавать да и меньше мороки потом с "двойным учетом" (часть в 7ке и часть в 8ке временно) по отчетам

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

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

к сожалению 7ка слабо работает в многопользовательском (там где не одна сотня сеансов... чего только блокировки стоят) режиме плюс проблемы онлайна и терминального сервера (опять же сеансов много и проблемы с одним отражаются на всех как и очень "нежный" майкрософтский РДП) тоже дают знать
вэб расширение рассмотрению не подлежит по ряду причин основная из которых проблемы подключения торгового оборудования

всё что описывали (кроме вэб расширения) уже пробовали и вопрос возник не на пустом месте

как вариант это создать отдельную 8чную БД для обслуживния точек а там уже заниматься "в лоб" т.е. оприходыванием товара перемещением продажей и т.д. с последующим переносом данных уже в основную 7ку
НО это увеличение штата и переобучение сотрудников плюс ещё одна лишняя цепочка требующая ведения более менее полноценного оперативного учета т.е. адмнистративное усложенние комплекса вцелом

вот и ищу выход как бы так и 7ку не трогать и точки контролировать на ином уровне нежели это сейчас :(

AHDPА какое торговое оборудование на точках у вас есть?
ЗЫ ИМХО сделать УРБД на 7.7 и рулить им (удалять старые данные из перифериек) через 1SUpdts. Готовых решений полно.

весы планируется и переход на фискальные принтера

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