ТиС, центральный офис + точки.
Центральный офис = (Фирма0, склад0)
Точки = (ФирмаN,СкладN), где N=1..M
.
товар на точку передаетс япосредством реализации(поступления) с центрального офиса на точки.
.
Вопрос: как сделать штатно так, чтобы на точку мигрировали только документы , предназначенные для этой точки..? С УРБД работал мало, и мне кажется что штатно не сделаешь - придется обрабатывать файлы обмена...?

(293) нет, такого функционала не надо.

(304) торговля видеодисками. есть еще весьма интересная задача в 'nqj области...

(305) Ну хоть, здесь по проще будет.

на (298) ответ будет?

(298) > а товар телепортируется со склада0 на складыN?
нет, не телепортируется.

в ЦБ при проведении делаются штатные движения по регистрам
- минус (Фирма0,склад0)
- плюс (ФирмаN,складN)

в ПБ приходят эти же самые движения, но ввиду того что на ПБ центральный склад "отсутсвует" - на нем получаются тотальные минуса

В принципе, если в файле обмена для каждой точки Вычеркнуть движеняи по минусам по ЦБ - то по идее должно быть все ОК, кроме того, что на ПБ нельзя перепроводить такой документ - иначе кирдык снова получится... или надо в модуль проведени ятсавить анализ где проводится документ в ЦБ (полные движения) , в ПБ - только по своей ТОЧКе - это не хочется делать..

(309)Почему не хочешь модуль проведения поправить?

(297) можно, но только в том случае если не удастся сделать ни вариантА, ни вариантБ

(309+) Без расходной части, они будут довольно быстро проводиться.

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

(310) потому что я ленивый и старый, выбираю путь минимального сопротивления ;-) надо будет - поправлю. Но по УРБД мало работал, поэтому надо "вьехать" в тему...
.
этого клиента подхватил только по причине чистого интереса 'nqj области бизнеса - очень короткие продажи, весьма интересна задача поддержания товарного состава на точках.
.

(309) я имел в виду, товар на склады попадает физически как? Его кто-то везет? если да то этот кто-то МОЛ? этот акт как-то отражается у тебя? Т.е. товар в пути учитываем?

(314) Тогда понятно.

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

(288) еще раз: если "деньги отпралены", то они не должеы просто уменьшать количество денг на счету/в кассе. они обязаны где-то на такую же сумму их увеличить. Для контроля. Элементарный принцип двойной записи.
Да, у меня регистр по одному из измерений не закрыт. Но у меня видно, откуда он ушел, и куда. И эти движения одинаковы во всех базах. ибо это _один_ документ. Если делать два документа, то нужен отдельный объект хранения, либо связывать их так, что ри изменеии одного документа автоматически меняется другой. Иначе это все отдается на откуп оператору.
2. догадываюсь, что "кнопка - это для пользователей". Только у меня они обходятся без кнопки "найти документ с похожим номером".
3. "История изменений в документах хранится в журнале регистрации" - это тоже "пять".
4."движения по месту проведения - это норма" - более чем сомнитетельное утверждение. Если я отдал деньги - я что-то получил. независимо, отдал я их из правого кармана, или из левого.  
"он оправил деньги от себя ВСЕ нет их у него на балансе" - замечательно. возмите меня туда кассиром....
5. у меня документы распечатываются. Все документы. И на документах ставятся подписи лиц, подтверждающие, что операция, зафиксированная документом, действительно произведена. у тебя на экране расписываются?

(315) Это путь к появлению новых сущностей, а он ленивый.

(315) товар физически перевозится из ЦБ в ПБ "курьером". Товар в пути не учитываем - ибо это ПОКА нафиг нужно не было. Товар с ЦБ на ПБ - попадает быстро - в течении часа-двух.

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

(317) Так у тебя так и будет. В ЦБ перед обменом всё лишнее подрежешь, а ПБ после обмена новые документы перепроведешь.

(318) > Если делать два документа, то нужен отдельный объект хранения, либо связывать их так, что ри изменеии одного документа автоматически меняется другой. Иначе это все отдается на откуп оператору.
- да, именно этого и хочется избежать, ибо придется наворачивать сверху над парами документов интерфейс-обработку, что мне нахрен не хочется - ибо на 12 лет нанаворачивался уже ;-) есть поинтереснее задачи.
.
ПРОСЬБА: обсуждения по схемам УРБД - ПРОСЬБА отложить пока. попробуем сосредоточиться конкретно?

(321) OLE - это ещё тот геморой. Я бы не стал связываться с такой схемой.

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

(322) если в ЦБ в файле обмена (или в соот.таблице ИБ) - все подрезать - то зачем перепроводить доки в ПБ?

(322) Чтобы получить только плюсовые движения у перемещения.

(327) это к 326

(318)  утомл уже....Элементарный принцип двойной записи.
В одном ПИБ расход, этот акт отражен соответствующим документом, который увидели в ЦИБ и переправили в другой ПИБ где произошел приход!!!!!!!!! Где нарушение принципа двойной записи?
2. Только у меня они обходятся без кнопки "найти документ с похожим номером. рад за тебя искренне, повторяю, все мои ограничения обусловлены ИСКЛЮЧИТЕЛЬНЫМ размером БД и огромным документооборотом.
3. ну ты же у нас любиттель всего нештатного,  ЖР и тот нужен крайне редко, при форс- мажерных разбирательствах и его волне достаточно. Поэтому никто ничего ЛИШНЕГО не городил.
4. более чем сомнитетельное утверждение - исключительно для ТЕБЯ!
5. Атличнег! У меня так же но только в ПИБах, ты речь завел про поиск и позиционирование в ЦИБе

(317) используй транзитный склад и пусть отслеживают остатки на нем.

размышляя попутно: если взять например вариантБ, то его штатно в УРБД тоже не получится реализовать?
.
в ЦБ (передача товара из ЦБ на ПБ)
1.
- реализация с ЦБ на ПБ;
- поступление от ЦБ на ПБ
в ПБ (передача товара из ПБ на ЦБ - есть такая необходимость):
- реализация с ПБ на ЦБ;
- поступление от ПБ на ЦБ;
.
и какая схем миграции для Реализации и ПоступленияТМЦ должна быть в таком случае - чтобы в ЦБ было всё, а в ПБ - только "родные" доки?

(330) не понял.

(318, 329) горячие финские парни! ;-) давайте ПОТОМ обсуждение разовьем в отдельнйо ветке (ПРИ НЕОБХОДИМОСТИ).

(317)Он же сказал, что его в ПБ не волнуют остатки по ЦБ в ПБ и также не волнуют остатки в других ПБ

(333) Спорим, каждый останется при своем.

(334) меня смущают минусы и при такой тяге к прекрасному ТС, его равнодушное отношение к ним!
не должны видеть и видеть минуса не одно и тоже. считаю что либо в ПИБах должны видеть остатки ЦС либо видеть 0, но никак не -

(329)
1. для особо выдающихся - деньги не должны исчезать. пардон, "списываться с баланса". Если деньги ушли у меня из кармана - у меня должна появиться материальная ценность, либо документ, подтверждающий то, что она у меня появится...
2. нет, это обусловлено исключительно твоим представлением.
3. ЖР нужен достаточно часто. раз в месяц точно. Знание конкретных изменений нужно тоже достаточно часто. Не зря, допустим, в снеговике ввели версионирование.
4. еще раз - на примере: если я заплатил деньги в размере 100 рублей - ф должен поиметь что-то на эти 100 рубле независимо от того, из какого кармана я заплатил эти деньги.

(336) Не путай. Минусы есть сейчас. И ТС хочет от них избавиться.

(337) п.1 а где сказано, что документ, подтверждающий то, что она у меня появится...  не появляется???? их появиться даже два!!! в ЦИБЕ именно исходя из принципа двойной записи.

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

(336) Показать 0 вместо 0 по ЦС, не такая уж и проблема, а вот куда девать лишние записи из ПБ, из-за чего страдает быстродействие.

(339) да очень просто. втородокумент

(340) В чем МОД или универсальный обмен для ленивого дешевле?

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

(336) именно. мое гипертрофированное чувстов "прекрасного" не позволяет мне мирится с текущей ситуацией, тем более что она мешает бизнесу реально.

(343) в части отсечения ненужных движений

(340) Себя тоже отношу к ленивым, поэтому тоже вначале много думаю, только потом делаю.

в ПБ по остаткам и движениям имеющим отношение к ЦБ - быть ничего не должно.

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

(340) этот вопрос уже поднимался в (315) ответ был дан в (319)

(340) транизитный склад не нужен. Проблем с товарами во время перевозки - мизерные, на этом - пока не заморачиваемся.

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

(348) (350) штатно, без каких либо доработок, без использования учета товара в пути и транзитного склада не реализовать! вопрос не в проблемах с товаром во время перевозки!

(343) Тогда скажи сколько работы нужно провернуть, чтобы настроить МОД и сколько, чтобы подрезать 1Supd

(352) обозначил выше - доработки возможны. Мне наиболее привлекателен путь "подправки" 1Supd

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

(354) Думаю, для тебя это будет самый правильный и быстро реализуемый выбор.

(354) не понимаю зачем? штатная задача. Да конечно появляются дополнительные цепочки документов и сущности, но их не много раз, учитывают ВСЕ хоз.операции - два.
Филиалы не видят ничего кроме свох остатков и движений, в ЦИБЕ видят ВСЕ! ровно что ты и номинировал в задаче. Зачем МОДы и правки непонимаю?

Итого: реализовать вариант А (290,292) с использованием документов перемещения возможно, для этого придется "подправить" перед выгрузкой 1Supd.
- правильно я понял?

(357) > Да конечно появляются дополнительные цепочки документов и сущности
- резюмируй плиз, кратко: какие именно документы/сущности и их назначение?

на удивление :) здесь мы с  Mikeware едины во мнениях.
или я ошибаюсь?

Доп сущности:
Транзитный склад (курьер) и доп. перемещения на/с этого/т склад

(358) Я тоже так понял, что да, только ешё подправить модули проведения, потому как в ПБ могут тоже исправлять перемещения( или не могут?)

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

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

(364) в контроле исправлений.

(363) Так ты же:
1. модуль проведения поправишь
2. после приема будешь запускать перепроведение полученных документов.
Следовательно документ проведется заново.

(365) подробнее, плиз.

(364)
при перемещении (ПРМ, миграция МСЦ) на транзиный склад (смотрим на реквизит: вид склада, склад измерение обоих регистров) делать расход по регистру ПартииНаличие и Приход по регистру ТоварВПути (в ЦИБЕ учитываем товар не доехавший до склада, филиал видит остатки - путь и свои) в филиале на основании пришедшего ПРМ делать ПТО - расход по регистру ТоварВПути и приход по регистру ПартииНаличие

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

(366) зачем мне на ПБ перепроводить полученные документы - если после подрезки файла обмена придут правильные данные?

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

(368) если у ПРМ миграция =МСЦ, то как перемещение попадет в ПБ вообще?
.
в ПБ наличие товаров в пути никак не интересует. Нет товара на точке - не надо никаких сведений о товарах в пути.
.
не нравится мне эта схема... мутная...

(371) > Скорее всего в каждой ПБ потребуется своя подрезка.
не понял... имеется в виду что В ЦБ ДЛЯ КАЖДОЙ ПБ - своя подрезка?

в (368) описана гибрид схемы вариантаА +вариантаБ. Вместо одного документа ПРМ появляется дополнительный документ ПТО (приход товара?)...
- тогда уже "проще"(?) сделать схему продажа-покупка с участием ЦБ и ПБ с обоих сторон... но тогда остается вопрос: (331)

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

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

(372) использовать "пустышку" ПБ :)

(377)А пустышек сколько и в какой момент создаются?

(378) Опять? С начала? :)
уже было. Пустышки создаются (лежат) в  ПИБе контроль нужного кол-ва (до создать или нет) выполняется ПриНачалеРаботыСистемы() "нужное кол-во" - либо констатна, либо городим/дополняем справочник, где определяем нужное кол-во по видам документов. Повторюсь никак ситльно систему это не напрягает.

+(379) - доработок миниммум

(372) так в чем мутность, то? в ЦИБе уичтываешь, что у тебя и куда уехало. В ПИБе товар физически приехал, в два щелчка создал на основании Приходный Товарный Ордер. Путь закрылся, Склад пополнился. ПИБ видит только свой склад и то что к нему едет! никаких минусов и лишних документов. Куда помоему прозрачнее!?

(379)Не сначала не надо, идея понятна. На первый взгляд вроде всё просто. Избыточности и так хватает и сам её ввожу для ускорения каких-то операций. Почему бы ещё немного не добавить. Надо будет при случае попробовать.

(382) см (82)

(383) А вот если с ПБ нет связи неделю и пустыши в ЦБ закончились, но при этом движения товара остаются. Тогда как выкручиваться? или ждать пока появится связь и не оформлять документы в ЦБ, дожидаясь прихода пустышек?

(383)Но это я так, зная о возможности такой ситуации, можно наверное и заранее что-нибудь придумать.

(384) так если нет связи:
1. Это форс-мажер
2. не понятно, зачем что-то слать в ПБ с которой нет связи
3. Не оформлять документы в ЦБ на эту ПБ или же в ЦБ используя прмой доступ (запросом) насоздавть нужное кол-во пустышек или держать в ЦБ заведомо большое кол-во пустышек

>>заведомо большое кол-во пустышек
ну если ПБ с потенциально не надежной связью

(386)
1. форсмажор, но не такой уж и редкий.
2. На соотвествующий склад делается перемещение материальных ценностей. Следовательно, делается и документ. Следовательно, он обязан туда отправиться при восстановлении связи.
3. насоздавать пустышек от имени периферийки? замечательно, однако :-))

(388) а я против? Обязан - отправиться. Я же написал, либо заведомо избыточное кол-во пустышек, либо (удивлен, что такому знатоку прмого доступа к данным) нужно рассказывать, что болванка документа без движений - это три записи в трех таблицах (если есть ТЧ), а ИБ создания определяется постфиксом поля iddoc в этих таблицах. И на случай форс-мажера создать нужно кол-вол объектов ПИБа в ЦИБЕ грамотному специалисту не сложно. В моей практике (120 филиалов от Владика до Калиниграда) с провайдерами сами понимаете разношерстными, подобный форс мажер был пару раз за последние лет 5-ть так что недостатка в пустышках нет.
>>
насоздавать пустышек от имени периферийки? замечательно, однако :-))
т.е. убивать записи из таблицы регистрации изменений религия позволяет, а вот создать записи от имени ПБ нет? Переобуваешься прямо в процессе ходьбы!

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

(390)
Открою тебе тайное знание, дабы "убогий разум" твой не не подсказывал тебе, а точно говорил какой ИД будет следующий:

Хранение ID объекта

   ID может иметь 3 представления (уровня) в зависимости от длины (количества значащих символов):

9 символов – определен тип и вид объекта (например «Справочник.Клиенты»), в ID включается только порядковый номер в 36-ричной системе исчисления. Под порядковый номер отводятся первые 6 символов, последние 3 символа зарезервированы под код базы УРБД.
13 символов – определен только тип объекта, вид не задан (например «Справочник»). Первые 4 символа – идентификатор вида (как он задан в метаданных), последующие 9 символов – по аналогии с предыдущим пунктом.
23 символа – не определен тип и вид объекта. В таком случае в первых 2 символах храниться тип объекта (будет рассмотрен ниже), следующие 13 символов формируются аналогично предыдущему пункту.

Исходя из ~ суточного прироста документов прикинуть сквозной поярдковый номер с запасом, чтобы исключить возможность пересечения, перевести его в 36-тиричную систему и делов-то

http://www.metaprog.co.ua/opisanietabl.html

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

(393)
способ формирования ида я и так знаю...создавая документы в ЦБ с таким идом, с которым придет документ из ПБ - рискую получить я коллизии

не вяжется

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

какие колиизии???

Не комильфо - никто не спорит. так ведь речь про форс-мажер.

(394) вопрос в том, насколько "далеколежащий" генерить - исходя из дня - могу получить коллизии из-за длящегося форсмажора. исходя из 5 дней - получу большие дыры.
зы.
разговаривая про ид документов в частности (а вообще, любой ид объекта - 9символьный) вываливать описания различных _представлений_ ида, и утверждать, что "создавал несколько раз" - тоже вяжется слабовато....

Чем тебя напрягают большие дыры? Боишсь разрядности не хватит?

>> разговаривая про ид документов в частности... т.е. теперь ты доипался, до количества скопиашенного текста? ну извини если сильно напряг тебя, так это ж такма что бы расширить твой кргозор и навсякий случай избежать дальнейших вопросов про "описания различных _представлений_ ида", но видишь млин.. мой план не удался!

>> что "создавал несколько раз" - опять лагаешь! сплошная клевета, я написал, что подобных (длительное отсутствие связи) ситуций, при обширнейшей географии филиалов и разношерстности провайдеров за последние 5-ть лет было не более 2-х! Где там утверждения ""создавал несколько раз"?

Вариант создания тестировался на клонах ПИБ и ЦИБ,  была проверена работоспособность! Было проверено опытным путем! А не только исходя из религиозных убеждений! Что коллизии отсутствуют ! Негатвных воздействий от "дыры" в номерации iddoc не было обнаружено.

(376) перемещения с ПБ на ПБ - только через ЦБ идут.

(376) не хочется на ПБ делать процедуру перепроведения принятых документов... ибо тогда - перепроведенные в ПБ доки будут мигрировать назад в ЦБ - а в ЦБ что получится?
.
хочется "нештатными" движениями ограничиться только в ЦБ. по принципу - подготовили инфу для ПБ - выгрузили, ПБ загрузи - все!

(381) на ПУБе - розничная точка. Поэтому что едет на ПУБ - нахрен не надо в ПУБе знать - пока не приехало - на пубе ничего нет.
.
с транзитным складом - все равно непонятно с закрытием регистров по транизитному складу и что куда мигрирует. если "перемещение" из ЦБ на транзитный склад делается в ЦБ - то получаем точно такие же грабли - такие перемещения будут мигрировать НА ВСЕ ТОЧКИ. то есть возвращаемся нафиг к тем же граблям + доп.сущность. - без тех же самых пустышек, по всей видимости не обойтись. Сильно не думал - но навскидку - изъянов дофига.

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

(400) Ну так и набери в любом поисковике "структура 1Supdts".
Там куча ссылок.

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

(400) структура примитивнейшая -
DBSIGN (char3) - код базы, в который отправляется объект
TYPEID (integer) - тип объекта (0 - выгрузка конфигурации)
OBJID (char9)  - ид объекта (0 - выгрузка конфигурации)
DELETED (char1) - признак необходимости удаления объекта из БД
DWNLDID (char9) - ид выгрузки, в которую данная запись уже попала (если пусто, то объект еще не отправлялся). записи с непустым идом удаляются из таблицы, когда приходит подтверждение получения узлом пакета. удаляются все записи с идом обмена меньше или равным подтвержденному.

(402) скромность - не твоя добродетель. Я бы посоветовал тебе обратиться к психологу - маниня величия явно налицо!