Всем добрый день!
ТИС 7.7 - 6 перифериек и ЦБ
Периферийки на ДБФ а вот ЦБ переходит на MS SQL
Это конечно здорово особенно то что не надо каждый год свертывать базу.
Но вот на ПБ где ДБФ регистр RA328 ведь будет подходить к 2 ГБ.
И их надо тогда сворачивать.
А с другой стороны в обмен попадает куча инфы совершенно не нужной для ПБ.
Поступлений на ПБ нет, только перемещения как с ЦБ так иногда с ПБ на ПБ, но
все равно же через ЦБ обмен идет.
Вот как убрать лишнее и не нужное.
Наверняка кто-то решал эти проблемы.
Здесь еще заморочка с ПАРТИЯМИ получается.
То есть партия есть а документа ее породившего в таком случае нет.
Поступление же пришло на ЦБ.
Можно конечно как советует Злопчинский убивать движения партий на ПБ за устаревший период
Главное чтоб итоги не пересчитывать за убитый период.
Но все равно когда-нибудь опять возникнет проблема размера базы на ПБ.
ПБ тоже на скуль переводить?

Вариант перейти на УТ хороший но никак не взлетает.
Не хватает компетенции на такой проект. Это надо ИТ-отдел
увеличить а на это никто не пойдет.

А что такое лишнее идёт на ПБ, что появилась такая проблема? Миграция ненормальная?

А с партиями - или принудительно выгружать документ прихода, или подумать - а зачем на ПБ нужен этот документ?

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

SQLExpress бесплатно.

(3) А платформа скульная? И ключик к ней? ))0

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

(2) Я уже забыл, как там в УРБД - что будет, если не включать в миграцию регистр, допустим, партий? Оставить на точках только количественный учет по складам.

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

+(6) Проверил на демо - проблема, что в ЦБ приходящие документы из ПБ надо перепроводить, чтобы движения по партиям получились.

(8) Все это крайне неудобно. Проще может и правда убивать движения прямым запросом?
Ну а когда журнал документов или другие регистры вырастут - все равно что-то же делать придется. уже тошнит от этим дурных заморочек

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

Да, можно но как быть со справочником Партий ?

(10) Злопчинский/чучундер выбрал другой путь - миграция по принципу место создания - центр. Но для этого ему приходится заранее заводить в ПБ пустышки, чтобы отправить их в ЦБ и заполнять по мере необходимости.

(10) А не сохранилось такого запроса у тебя?
(12) Да это я давно фишку знаю но есть опеределенные неудобства. Убирать надо из файлов обмена уже готовых.
Как апдейтить 1supdts при одновременной работе пользователей ?

Обмен начинается с ЦБ по-любому, так что самое оптимальное чистить файлы обмена до загрузки в ПБ, 6 ПБ - 6 файлов. Но опять же непонятно как быть с партиями. Ведь документ прихода же в ПБ тогда будет отсутствовать. Получается - не найден объект

(13) там не апдейт, там тупо делит

(14) И опять же неплохая штука МОД чтобы не таскать кучу барахла, а на точках простейший количественный учет. Но его уже и покупать поди не у кого :)

(15) Тупо делете. На момент делете же в 1supdts ничего же записать нельзя будет. Скажем провелли какой-то документ и он должен оставить запись в 1supdts. А она занята. Получается что документ в обмен не попадет?

(16)всегда думал, что он бесплатный :) ключей 70 где-то валялось еще от  него(или 200 ?) не помню.. Хотя да, даже коробка была от него раньше, первые версии покупали

(17)чей та ?

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

(16) Нереально МОД. Количественный учет на отчках - тоже нереально.
На момент делете же в 1supdts ничего же записать нельзя будет. Скажем провелли какой-то документ и он должен оставить запись в 1supdts. А она занята. Получается что документ в обмен не попадет?

(20) Это все в скуле? Под ДБФ так уже не получится. Ну да мы и пытаемся на скуль ЦБ перевести. Может и проканает такое очищение апдейтса. Но блин с партиями как быть? Переместился товар когда поступивший в ЦБ. Если все это поуничтожать - то в как на ПБ фифо должно работать?

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

(23) Это уже не УРБД будет

(23) у получателя партия при вводе документа поступила - какого документа? Перемещения? То есть регистратором партии является перемещение?

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

сейчас уже детали не помню но когда были проблемы с каналами связи - для филиалов отдельные документы делали типа ПередачаВФилиал, ПриемИзЦентра
позволяло меньше данных таскать по всем периферийкам.

(25)>> То есть регистратором партии является перемещение?
А в чем проблема ? "Оприходование излишков ","Пересортица" создают партии и ничего , живут же как-то :)

(26) Да, та наверное можно. Хотя не очень представляю что значит партия созданная перемещением

(29) партия это тупо запись в справочнике, Астор в ТД 1с 7.7 ушел от справочника , был документ-основание , принципиально разницы никакой. Ну будет у вас в переферийке  партия от перемещения с ЦО , себестоимость-то останется та же , наценку можно на основании перемещения делать. Можете вообще не замарачиваться и поставщика ЦО создать и набивать в переферийках поступление ТМЦ

(27) Ну да.
(28) Правда партий становится в два раза больше тогда. Хотя для скуля по хрену
(28) Но апдейтс все равно резать надо будет

(22) нет, в дбф

(31) ну и что ? по одной партии остатки списались , по другой появились , в переферийке партии только поступлений , которые вводили сами сотрудники и при перепроведении документов локально будет проще , чем с заморочками документов  набитых в ЦО и касающихся остатков переферийки

(32) Ну да, вот только как резать апдейтс когда другие вводят в него добавление - не врубаюсь

(32) прямым запросом с delete

и установкой драйверу не блокировать табличку

(33) Но документ же в ПБ сформируется с партиями хоть прихода хотть расхода - перемещение но документ от партии прихода - пустой точнее "объект не найден". просто я все это уже 1000 раз промысливал за эти годы.

(37) ? если вы впишите в документ прихода поступлениеОтЦО (или перемещение подшаманите) , то в чем проблема , там будет документ - который вы запишите .

(38) Я понял - разбивать перемещение на два документа. Тоже там думал - типа приход не мигрирует а мигрирует расход

(39) в вашем случае если отправитель ЦБ , то мигрирует приход с ПБ , а расход только списание делает в ЦБ

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

(38)+ А иначе в ПБ не проведется перемещение с ЦБ. Ибо партия списанная в первой части переммещения - будет минусовать. Непонятно откуда она взялась на остатке. Приходы все у нас в ЦБ делаются

(42) ну да ,в ЦБ списали , в ПБ оприходовали и вперед и с песней :))

+(43) заодно и приемка качественнее будет , когда сами будут набивать товар

(44) Ага, ну это вообще отказаться от УРБД, от всех ее преимуществ. Может все-таки с партиями как-то по-другому можно подшаманить ?

(45) >>Ага, ну это вообще отказаться от УРБД, от всех ее преимуществ.
Зачем так категорично :)

(44) Так они в ЦБ сами для себя перемещения формируют просто сразу из остатков ЦБ, ну а потом они мигрируют. Вот если бы можно было создавать пустые болванки поступлений по партиям из ЦБ с номерами поступлений из ЦБ - вот тогда было бы классно. Но как это автоматом жделать - не знаю. А главное - когда

(47) Ну и никогда не перепроводить эти перемещения или при проведении смотреть что если создано  в ЦБ - перепроведение в ПБ запрещено

(47)+ Соответственно остатки по ЦБ и другим ПБ - вообще нет смысла даже смотреть

(48) я бы вообще поделил ЦО на 2 базы одна общая ЦБ и переферийка , где все вводили бы , в ЦБ только получатель и отчеты

(50) Ну отчасти так и есть. Просто там склад никак поделить не могут на ЦБ между оптом и розницей по этому такой вариант не работает.  А ПБ вообще-то аж 6 штук

(52) Из-за того что на 3 ПБ и опт и розница (разнофирменные), то приходится чтобы менеджеры смотрели платежи и долги клиентов - мигрировать стоки выписки приход и приходные кассовые ордера

(19) Епрст У вас случайно нет примера такого запроса к апдейтс? Чтоб хоть малость понять что к чему

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

(53) Посмотри структуру урбд там все просто

(55) Структуру апдейтс?

(54) Закрывает но создает массу проблем - ведь блин выгрузка в бухгалтерию перемещений идет. То есть придесят еще и обменс БП3 модифицировать? Потом у меня есть учет кабельной мерной продукции - получается вместо одного подчиненного документа бухт мне два создавать - один на приход и один на расход? Ну неужели нет никакого варианта чтобы партии в неприличном состоянии были ? )

(57) Вопрос зачем нужны партии считаем вбросом?

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

(59) Ладно, это позже.
(58) ДА, потому что буквально вчера разбирался. Для увеличения маржи в реализации были проставлены конкретные партии - это на ПБ и на ЦБ бывает.

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

(59) Я понял. Перемещение оставляем но наполовину и его собственно и выгружаем. А приходизЦБ уже в ПБ уйдет и все.

(62)+ Так а может вторая часть - это просто Оприходование ТМЦ и все?

(36) Епрст
и установкой драйверу не блокировать табличку - это как сделать?
А под скуль точно так же? ТАм же драйвера БД нет

(61) А если на ПБ сделал перемещение обратно на склад ЦБ или на другую ПБ - тоже двоить должно? Тольк в обратную сторону?

(64) SET TABLEVALIDATE TO 0

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

(66)+ что есть?

(66) Да, понял. Типа вся база ждет пока не выполнится мой запрос

(68) ты не понял, никто никого не ждёт

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

(70)+:

(69) Тогда пожаоуйста растолкуй

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

(71) Ну типа того, только вот надо тогда везде робота запускать который после обмена перепроводить будет

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

(75) :)))
какие на.. запросы на изменения ?
Там все го лишь insert и delete, всё.

И какая в на.. очередь еще ?

(77) юзер1 делать делете на апдейтс
     юзер2 в это же время делает инсерт на апдейтс какого-то объекта.
     Как я понимаю сначала выполняется мой запрос  раз он раньше пошел и только потом запрос юзер2. Или нет?

(78) нет

(79) Если можно в двух словах - пожалуйста разъясни

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

ну и прочитай про многопользовательскую работу с файлами в дбф

(82) Читал ибо работаю с ДБф примерно с 1994 года так или иначе.

(82) Если я делаю запрос на делете а юзер делают туда же запрос на инсерт то при попытке обмена - выгрузки в файл обмена - у меня будет лишняя неудаленная запись

SQL имеет средства управления параллелизмом для точного указания места получения результата: ни одна команда не должна быть выдана, пока предыдущая не будет завершена (включая команды COMMIT или ROLLBACK).

Механизм, используемый SQL для управления параллелизмом операций, называется блокировкой. Блокировки задерживают определенные операции в базе данных. Задержанные операции выстраиваются в очередь и выполняются только после снятия блокировки.

(84) вешай триггер тогда на табличку, и при каждом инсерте удаляй им лишнее

при желании, можно вычищать данные из dat файла..но, это трудозатратнее

(87) Конечно куда интереснее удалять даныые из самого файла обмена. Насчет того чтоб при инсерте сразу удалять - это красиво. Только это надо процедуру сыскать которая это все делает и менять ее. Причем тут 1С - ваще непонятно )

(88) ты делаешь проблему там, где ёё нет. перед выгрузкой примитивный запрос на delete потрёт все записи за мс

(89) Я не делаю проблему хотя да, из пушки по нанообъектам )

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

(91) То есть вообще полностью менять обмен данными и содержание ПБ. МОД когда-то был но помнится кто-то очень сильно его раскритиковал

(92) критиковали его те, кто с ним не работал никогда или знаком поверхностно. На основе мода потом кд2 слепили

(93) Считаешь что мне стоит найти МОД в каком-то виде и заняться им? С одной стороны ничего такого в свертке ДБФ когда регистр RA328 подходит к 2 ГБ нет. Делается она шустро и только потом приходится заново создавать все ПБ. А до их ввод в работу использовать старые с выгрузкой данных в уже новые.

Мне очень не нравится вот весь этот геморрой.
С другой стороны если склад получатель и отправитель имеют разные ПрефиксыУРБД, то надо как бы разбивать перемещение а если перемеещение внутри одной базы или перемещение из ПБ в ЦБ то можно использовать обычное перемещение. А если из ПБ в ПБ то точно так же надо делать - разбивать перемещение на две части

(92) МОД прикольная штука. У меня у пары клиентов на нем была реализована схема снежинка.
Кстати ставится на раз и за пару дней запускается в бой. Это, конечно, если опыт есть.
Ну а без опыта за 2 недели.
Потом тупо щелкая флажками настраиваешь для каждой точки все фильтры и вуаля - каждая точка видит только свои остатки и документы и размер базы на точках в 10 раз меньше

(91) Кстати, допилка МОД+УРБД меньше сотни строк. Хорошей секретарше на минуту работы.

(96) Допилка встроенным языком 1с или чем-то еще? И в плане чего допилка? Еще бы где-нибудь найти сначал это МОД. Был ну очень давно. Пока мы были маленькие - все было хорошо но вот выросли и начались все эти заморочки

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

(98) Понятно, но допилка в плане чего? Мне лично УРБД своей мощной сохранностью и уникальностью данных очень нравится. Просто раз пока мы на УТ не переходим - решили перейти на скуль 7.7 и пока я бьюсь с прямыми запросами - заодно в параллель надумал наконец как-то решить и этот вопрос. Не нравится мне куча лишней инфы в ПБ

(98) Найти этот триггер который отвечает за работу с апдейтс и поправить его как мне надо

(99) Я допиливал так - регистрация изменений с помощью УРБД, а выгрузка-загрузка с помощью МОД. У меня был немалый документооборот при построчном проведении документов. Механизм регистрации МОД не справлялся. Без построчного проведения при нынешней технике это не актуально. Ну если только выйдете на десятки тысяч документов в день...

(101) Пока такого нет что десятки тысяч. Но блин и МОД нет. Еще непонятно где его взять чтоб поюзать. Если что - купить не проблема будет

(102) У Ёпрст двести штук МОД залежалось - одолжи десяток :)

(102) У меня дистрибутив далеко не последний - я его для себя дорабатывал и обновляться было не актуально

Ну может и одолжит

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

(106) С пустышками пробовал но не все так гладко было. Насчет партий - ну ндо думать. Спасибо!

(106) Не совсем понял как так одно перемещение расход другое приход. Типа два разных документа составляющих одно перемещение?

(104) Я нашу замороченную бизнес-логику рисовал и с зарплатой и бухгалтерией занимался. УРБД работала и не морочился.

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

(108) Да, типа того

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

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

"То есть партия есть а документа ее породившего в таком случае нет."
для типовой ТИС это некритично если на ПБ будут партии но не будет доков ее породивших. в типовых при проведениях по партиям нет обращений к партиеобразующим документам

(114) Согласен, но тогда в справочнике Партия в ПБ будет Приходный документ - "Объект 34023984/ПБ" не найден, а в ЦБ все как надо. Ну и опять же остатки на на ПБ по другим складам. Они же повиснут

В реале надо убивать движения по складам не этого магазина ну а перед обменами как-то удалять лишние записи в апдейтс

(115) " Партия в ПБ будет Приходный документ - "Объект 34023984/ПБ" не найден,"
-- ну и хрен с ним, если этот обьект по ссылке не используется то битая ссылка ничему не мешает.

(115) "ПБ по другим складам. Они же повиснут"
- подчищать раз в год. это проще чем, каждый раз при написании алгоритмов не забывать, что надо не создавать перемещение, а искать пустое созданнное на ПБ и использовать его. а если так делать - надо суко не забывать что при многопользовательской работе такоую "болванку" может захватить кто-то другой, и надо разруливать блокировки. и еще кучу гемора.

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

(119) Класс. То что надо примерно. Вот только теперь еще и опенконф. где хоть его взять? он платный?

(118) Полностью согласен. Мы уже не раз обсуждали этот вопрос и все эти пустышки как-то не то что хотелось бы.

(120) не, на ИС набери OpenConf - там есть сборка ОпенКонф лайт пак и ее подправки. я им пользуюсь (правда совсем в минимальном виде).

(122) Нет у меня стартмани на исе. но вресию 2010 года лайт вроде надыбал

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

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

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

(119) в дбф после чистки данных  надо бы переиндексировться.  
вроде Ёп говорил, что если через фоксовый драйвер удалять - то и переиндексироваться не надо, но я не пробовал.

(0) А что у вас на точках делают? Может проще туда какой ни будь фронтол поставить для продажи, а все товародвижения делать в центральной в терминале.

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

(128)+ Вот если б в этот фронтол как-то всобачить мой механизм продажи кабеля - то было бьы неплоох

(129) Давно с ним не пересекался, но говорят, что он очень гибкий. Но и не обязательно его использовать, сама идея отдельно фронт, отдельно бэк. Фронт можно и самому написать или подходящий найти и убрать УРБД.