Имя: Пароль:
1C
1C 7.7
v7: Нетипичное использование компоненты УРБД в системе 1С:Предприятие 7.7
0 Andreyyy
 
11.10.12
09:57
Идея взята отсюда Книга знаний: Нетипичное использование компоненты УРБД в системе 1С:Предприятие 7.7
Задача:
Требуется настроить обмен между базами типа "Снежинка". Стандартный УРБД неудобен, т.к. нет возможности отбора при выгрузке в периферию.
Проблема: на многих точках установлена однопользовательская версия программы, т.е. запускается база всегда насколько я понимаю в монопольном режиме и не будет возможности читать/изменять нужные файлы.

Как можно обойти это ?
1 Andreyyy
 
11.10.12
09:57
Поправьте тему плз в 7.7
2 Ork
 
11.10.12
10:05
(0)
1. "нет возможности отбора при выгрузке в периферию." Это не так.
2. "Как можно обойти это ?" не пускать базу монопольно. Или закрывать на время обмена.
3 Mikeware
 
11.10.12
10:07
Хм. А разве однопользовательская может работать в качестве центра распределенки? (в т.ч. и по условиям лицензии)
4 Andreyyy
 
11.10.12
10:13
(3) Из однопользовательской(периферийных) я хочу выгружать/загружать тоже своими средствами, но систему регистрации измененных объектов хотелось бы оставить стандартную, т.к. она надежна и не нужно городить огород.
5 Aleksey
 
11.10.12
10:15
MOD
6 Andreyyy
 
11.10.12
10:17
(2) 1. Каким образом можно отоборать выгрузку в периферийную базу по значению склада в шапке ? (перед выгрузкой пройтись по фалу 1SUPDTS.DBF ? Но вдруг кто из пользователей что-то поменял (всех выгонять на время обмена не вариант) выгрузится документ во все базы.
2. Обработка обмена будет своя и написана на языке 1С, т.е. не запускать базу в которой нужно произвести обмен не получится. Можно запустить базу не в монопольном режиме в однопользовательской платформе ?
7 Andreyyy
 
11.10.12
10:19
(5) Нужно по сабжу. МОД не подходит по определенным причинам.
8 ЗомбиТ1С
 
11.10.12
10:21
А разве УРИБ на однопользовательскую встанет?
9 Андрей_Андреич
 
naïve
11.10.12
10:21
(7) Причины в студию
10 Mikeware
 
11.10.12
10:24
(4) я про систему регистрации и говорю...
(6) выгонять _всех_ из однопользовательской версии? :-)
11 Andreyyy
 
11.10.12
10:24
(9) Нужно своими средствами и без денег.
12 Mikeware
 
11.10.12
10:28
(11) на краденой УРБД? :-)
13 Андрей_Андреич
 
naïve
11.10.12
10:29
(11) А за работу деньги заплатят или для души работаем? Просто МОД стоит копейки.
14 Andreyyy
 
11.10.12
10:31
(8) Читайте внимательно: однопользовательские на периферии.
(13) Хотелось бы оставить стандартную систему регистрации + МОД в модули пишет свой код, да и нагроможден уж больно. Неизвестно как будет работать с большими объемами. Вобщем не лежит душа к нему.
15 Andreyyy
 
11.10.12
10:34
(12) Да почему ж она краденая ??? В центре лицензия неограниченная, на периферийных купленные однопользовательские. По идее базы и будут в режиме периферийных УРБД работать, но файлы отвечающие за обмен редактироваться своими средствами.
16 Андрей_Андреич
 
naïve
11.10.12
10:37
(14) У меня регистрация от УРБД а обмен от МОД и весь МОДовский код из модулей убран (кроме доп.функций в глобальнике), поскольку эта куча кода нужна лишь для регистрации.
Можно вообще инсталлятором МОДа базу не обрабатывать - только добавить общий реквизит в доки и в каждый справочник :( + еще по мелочи.
Большие объемы - это сколько?
17 Mikeware
 
11.10.12
10:40
(15) "промежуточные центры" "снежинки" по идее тоже должны быть центральными.
Ну и читать модифицированным фокспрошным драйвером можно, а вот писать - проблемы (с индексами)...
18 Shur1cIT
 
11.10.12
10:42
я делал проще во все базы выгружал всю инфу, в переферийной базе при начале работы системы бежал циклом по документам и "не своим" домуметам снимал признак отслеживание изменений (не помню как называеться) и потом Удалить(1).в результате в переферийной базе только приходные накладные предназначеные долько для этой базы.
19 Shur1cIT
 
11.10.12
10:47
(18) работало таким образом 50 магазинов:-)))эх были времена приходилось извращаться не то что сейчас))
20 Andreyyy
 
11.10.12
10:51
(17) Я значит неверно истолковал слово "Снежинка". Одна база в центре и штук 20 периферийных.
21 Mikeware
 
11.10.12
10:52
(20) это - обычная типовая звезда.
обработка нужна только в ЦБ.
22 Andreyyy
 
11.10.12
10:52
(18) Так и засада в больших файлах обменов, сидят на "свистках" мегафоновских. +Если объем большой то и загрузка в базу может идти целый день - без шуток.
23 Andreyyy
 
11.10.12
10:54
(21) перед выгрузкой пройтись по фалу 1SUPDTS.DBF ?
24 Mikeware
 
11.10.12
10:54
(22)"большие" - это сколько?
и, собственно, что "нетипичного" при звезде?
25 Mikeware
 
11.10.12
10:55
(23) типа того.
Хотя работать с файловыми на запись я б не рекомендовал.
26 пипец
 
11.10.12
10:55
ТекущаяИБКод()
ИБСозданияОбъекта
ЦентральнаяИБКод()
PS файл выгрузки не судьба править ? и отсылать...
ЗЫЫ фигня это все , все в пределах - работает если обмениваться по 1-2 мега за раз ...
ЗЫЫы похоже с урбд да и с модом мало работали ...
27 GStiv
 
11.10.12
10:57
а еще смущает
как и сам автообмен в УРБД, работает только в разделенном (не монопольном!) режиме 1С:Предприятие 7.7
а однопользовательская запускается в монопольном,
Кстати МОД работает отлично
28 ЗомбиТ1С
 
11.10.12
11:00
(14) Всё бред. УРБД на перефирийку не встанет и никаких изменений регистрировать не будет.
29 Андрей_Андреич
 
naïve
11.10.12
11:05
(23) Можно добавить в справочник "Склады" код ИБ и удалять в UPDTS документы с "чужим" для этой ПБ складом. Это если однозначное соответствие ПБ - склад. Не знаю, как в ДБФ, а на скуле -в 2 счета.
30 akaBrr
 
11.10.12
11:05
(28) уже определились, что имеем дело с обычной "звездой"
31 akaBrr
 
11.10.12
11:06
(23) в периферийках создаются болванки нужных документов, в ЦБ заполняются, миграция "место создания - центр" и никаких плясок с бубном
32 Андрей_Андреич
 
naïve
11.10.12
11:09
(31) Лучше в одном месте поплясать, чем в сотне по всей стране :)
33 akaBrr
 
11.10.12
11:10
(32) в смысле? в пб болванки могут создаваться автоматически, не нужно плясать по всей стране
34 Andreyyy
 
11.10.12
11:17
(22) После перепроведения в центре за последнюю неделю в перифериную базу может загружаться сутки.
(22) Нетипичтое использование УРБД, механизм обмена свой - регистрация УРБД.
(25) Смущает то, что пока будешь пробегаться по файлу, юзеры еще наколотят документов и все-таки не по адресу что-то попадет.
(26) Про правку файла выгрузки еще не думал, если ссылку подкинете по структуре был бы признателен.
(26) Не получается обмениваться всегда по малу.
(26) С МОДом не работал, установл и удалил лет 5 назад.
(33) Это как ?
35 Andreyyy
 
11.10.12
11:22
(31) Возможно при создании документа в центре изменять признак места создания на другую базу ?
36 Андрей_Андреич
 
naïve
11.10.12
11:22
(33) Это в ПБ при старте создаются пустышки будущей датой и поддерживается запас? А в ЦБ запрещено вводить новые доки определенного вида - пользуйтесь пустышками?
37 Андрей_Андреич
 
naïve
11.10.12
11:25
(35) Тогда проще не регистрировать доки. А при записи/проведении вставлять запись в UPDTS для нужной базы по соответствию Склад-ПБ.
38 Andreyyy
 
11.10.12
11:25
+(35) ИМХО самый бескровный вариант - в какой
39 Andreyyy
 
11.10.12
11:25
+(38) таблице хранится создания объекта ?
40 Andreyyy
 
11.10.12
11:26
(37) Либо так.
41 Надсмотрщик
 
11.10.12
11:29
(0)

1) На ПБ делаешь перемещение - ПУСТЫШКУ.
2) Выгружаешь в ЦБ
3) Заполняешь документ перемещение в ЦБ
4) Выгружаешь в ПБ.

Что тебе еще надобно, старче?
42 Андрей_Андреич
 
naïve
11.10.12
11:29
(39) Уууу. Один фик ты сначала запишешь. И при этом уже будет зарегено для всех баз. Да еще и запись будет заблокирована - слишком много но. Править надо только в UPDTS - иначе намудохаешься.
43 Mikeware
 
11.10.12
11:32
(34) структура файла выгрузки более чем позрачная...
44 Andreyyy
 
11.10.12
11:33
(41) Выглядит "через ж.", хочется чтоб прозрачно для пользователей все было.
45 Надсмотрщик
 
11.10.12
11:35
(44) Зато работает "как часы" и штатными методами.
46 Andreyyy
 
11.10.12
11:35
(43) Навскидку - своими средствами (в обработке 1С) сложно сформировать такой файл ?
47 Mikeware
 
11.10.12
11:36
(44) оно и так прозрачно для пользователей
48 Mikeware
 
11.10.12
11:37
(46) кому-как.
в общем, легко, но геморно. Плюс только формированием файла дело не ограничивается...
49 Andreyyy
 
11.10.12
11:37
(45) Несомненный плюс. Может и правда ну нахрен всю эту свистопляску.
50 Надсмотрщик
 
11.10.12
11:37
(46) Можно и обработкой откорректировать, можно и ручками.
51 Andreyyy
 
11.10.12
11:40
Не, не пойдет обмен через УРДБ. Нужно конвертировать одни документы в другие - например перемещение в центральной должно быть поступлением в розницу в периферийной.
52 Надсмотрщик
 
11.10.12
11:40
Сейчас, в данный момент, варганю 97 базу.
Подбираю, только для них, нужные элементы справочников
53 Andreyyy
 
11.10.12
11:42
Вся проблема в том, что не могу корректировать файл UPDTS в периферии. Вариант создать еще одну базу для обмена. Закрывают рабочую, открывают для обмена.
54 Mikeware
 
11.10.12
11:42
(51) зашибись распределенка... :-)))
ты еще номенклатуру одну в другую конвертируй...
55 Надсмотрщик
 
11.10.12
11:42
(51) А накуа?
Основной склад - оптовый
Переферийный - розничный (перемещение в розницу)
56 Andreyyy
 
11.10.12
11:43
(52) Жесть, ладно у меня все справочники общие.
57 Andreyyy
 
11.10.12
11:43
(55) А движения лишние зачем ? Списание с основного будет.
58 Скользящий
 
11.10.12
11:43
(51) КД2 решит твою проблему. Только повозиться придется с ее освоением. )
59 Andreyyy
 
11.10.12
11:45
(58) Я и собираюсь ее использовать. Проблема встала в регистрации объектов для обмена. Либо УРБД (надежно), либо свое делать.
60 Надсмотрщик
 
11.10.12
11:45
(56) Я каждому даю только ту номенклатуру, что нужна им. И только тех контрагентов с которыми они будут работать, из числа заведенных в базу, остальных они сами заведут и пришлют мне.
61 Скользящий
 
11.10.12
11:47
(59) УРБД понадежнее будет, там механизм регистрации изменений очень мощный. А с КД2 постоянно у меня проблемы. то она перезаписывает то что не нужно перезаписывать, то дозаписывает. )
62 akaBrr
 
11.10.12
11:50
(51)Это разбивается на 2 этапа, в ЦБ пользователь делает перемещение, затем уже автоматически, опять же в ЦБ, на основании перемещения заполняется болванка поступления в розницу для конкретной ПБ, которая и уходит в ПБ, перемещение остается в ЦБ, нехер ей в ПБ делать, только с ссылками может быть засада
63 Andreyyy
 
11.10.12
11:51
(60) Выглядит так ?
Звонок в колхоз Ивановкий из центра: "Марья Ивановна, заведи-ка перемещение, товар тебе хотим отправить !"
64 Andreyyy
 
11.10.12
11:52
(62) Тогда уж в периферии создается поступление в розницу, а в центре заполняется и создается перемещение между складами, которое остается в центре.
65 akaBrr
 
11.10.12
11:53
(63) перемещение у тебя делается в ЦБ, если я правильно понял (51)
66 akaBrr
 
11.10.12
11:53
(64) ну тебе на месте виднее
67 Andreyyy
 
11.10.12
11:54
Проблема еще в том, что хотят уйти от редактирования документов задним числом, работать только текущим. Ввиду этого ввести корректировочные документы. Т.е. документооборот будет активный и заводить документы изначально в периферийной базе может стать неприятной обузой.
68 Andreyyy
 
11.10.12
11:55
(65) Да.
69 akaBrr
 
11.10.12
11:55
(67) это уже потом будешь делать, сначала с обменом разберись
70 Andreyyy
 
11.10.12
11:59
Еще вариант забить на УРБД и использовать журнал регистрации. Напривер ВК Journal.dll
http://1c.proclub.ru/modules/mydownloads/personal.php?cid=5&lid=2167
71 Andreyyy
 
11.10.12
12:00
Точно, никаких проблем с монопольным запуском. Прикрутить КД2 и в путь.
72 Andreyyy
 
11.10.12
12:01
(61) Буду надеяться что мне повезет больше)
73 Надсмотрщик
 
11.10.12
12:08
(63) Если у тебя пришел товар для всех. одной накладной, а тебе его надо раздать каждому по чуть чуть.
74 Andreyyy
 
11.10.12
12:11
(73) У меня центральный склад на который приходит весь товар. С него идут продажи и перемещения на другие склады/магазины.
75 Mikeware
 
11.10.12
12:12
(63) "выглядит так" - при начале работы системы проверяется количество пустышек, лежащих в каком-нибудь 2020 году 1 января, и если их меньше 20, скажем, то генерируется недостающее до 20 количество.
----
а вообще, почитай форум. эта тема мусолися года с 2004...
вариант с пустышками для твоей базенки - оптимальный.
76 АНДР
 
11.10.12
12:18
(0) У творения Саши Орефкова SQLite есть замечательный побочный эфект - умение работать с файлами базы, когда она запущена в монопольном режиме. Так что можно реализовать любые извраты фильтрации и изменения принадлежности объекта к БД.
77 пипец
 
11.10.12
12:18
(34) http://pro1c.org.ua/index.php?showtopic=352
Файл 1Cv77Chs.dat и вовсе
***
***,
{"Acknowledgements",
{"****"}},
{"Constants"},
{"References"},
{"Accounts"},
{"Documents"},
{"Template Operations"},
{"Deleted References"},
{"Deleted Documents"},
{"Deleted Accounts"},
{"Deleted Template Operations"}}
78 Mikeware
 
11.10.12
12:19
(76) а с записью и индексами там проблемы решены?
читать-то несложно....
79 КонецЦикла
 
11.10.12
12:20
(24) +1 ^)
80 Andreyyy
 
11.10.12
12:44
(76) Похоже то что надо по сабжу, спасибо.
81 Andreyyy
 
11.10.12
12:49
Всем спасибо, предложили много вариантов.
82 Aleksey
 
11.10.12
12:53
(15) В 7-ке УРБД это отдельная компонента с отдельным ключом, который стоит денег и не маленьких. У вас оно тоже куплено?
83 Aleksey
 
11.10.12
12:54
(76) Только чтение, без записи в БД
84 Andreyyy
 
11.10.12
13:08
(82) Лови скрин лицензии http://www.idinahui.net/
Коли топик в который раз лень прочесть.
85 Андрей_Андреич
 
naïve
11.10.12
13:40
А ЦБ у тебя скуль или дбф?
86 Andreyyy
 
11.10.12
15:10
(85) ДБФ
87 Andreyyy
 
11.10.12
15:14
Вобщем подумали, порешали и остановились на варианте создания пустышек в периферийных ИБ.
Поскольку времени мало для внедрения и чувствуется что для других вариантов потребуется много времени на тестирование.

Если бы еще подсказали как в центральной базе изменить признак в какой базе был создан документ.
Чтобы пересоздать периферийные базы по новой (сейчас они практически клоны центральной).
88 akaBrr
 
11.10.12
15:21
(87) Если бы еще подсказали как в центральной базе изменить признак в какой базе был создан документ. - признак этот 3 символа в ИД объекта, подменять их я бы не стал, может случится так что ПБ создаст объект с уже существующим ИД, последствия понятны?
89 Andreyyy
 
11.10.12
15:29
(88) Ясно, спасибо.
Тут либо менять вместе с признаком ID, т.е. делать по порядку для каждой ИБ.
Либо создавать клоны документов в периферийных и удалять предыдущие в центре.
90 Андрей_Андреич
 
naïve
11.10.12
19:34
(88) Это еще все ссылки надо на этот ИД вовремя отследить и заменить. Короче - ну его.
91 Надсмотрщик
 
11.10.12
20:06
(87) Если есть желание, то любой документ, созданный в любой базе, можно перенести в любую базу - ручками.
Одно НО изменения в документе не будут передаваться.
92 Злопчинский
 
11.10.12
23:13
(51) запросто. у меня так и есть, но пришлось помучиться..
93 Злопчинский
 
11.10.12
23:22
короче - была тема по большой файл, открытие периода и ПБ.
.
ситуация была такая,
центральный офис и куча точек-магазинчиков.
изначально схема УРБД была сделана так что
- каждый магазинчик = отдельная фирма
- все фирмы (в т.ч. и ЦБ) - одно юрлицо.
- приход на оптовый ЦБ фирма-склад; зашибись
- перемещение с оптовый ЦБ фирма-склад на розничный ПБ фирма-склад;
.
соответсвенно в каждую ПБ уходили все перемещения для всех точек.
в ПБ получалсиь висящие остатки по ЦБ фирма-склад.
.
в итоге рано или поздно нас тупил капец - периоды открывались все дольше (по нескольку часов уже), файло регистров расло безмерно.
.
в итоге схему пока оставили как есть, а на ПБ тупо запускаем обработку, которая удаляет все доки где нет пары ПБ фирма-склад, а там где такая есть пара - для этого документа удаляем движения регистров по чужим парам Фирма-склад.
.
в итоге все стало почти "шоколадно" - размеры регистров упали от около 2Гбразмеров до сотни мегабайт 9а то моет и меньше, навскидку не помнюЮ на ПБ не залезть посмотрть), период открывается секунд 5-7
94 Злопчинский
 
11.10.12
23:27
соответсвенно, если бы осовоить, чтобы в ЦБ чистился файл регистрации изменений (для кажлдой ПБ вытирались записи определенные - я так понимаю)...
может есть у кого примерчик, плиз?
95 Aleksey
 
11.10.12
23:29
(94) Только если ЦБ на скуле
96 Злопчинский
 
11.10.12
23:30
(95)
а) почему?
б) да, ЦБ на скуле.
97 Aleksey
 
11.10.12
23:38
(96)
1. Потому что до сих пор нет нормальной возможности редактировать dbf файлы напрямую, без риска "поломать" индексы
Для Скуля такой проблемы нет, ибо нет индексов. Там хоть триггер повесь на изменение таблички и оно само будет автоматом чиститься (пишу по рассказам, а не по опыту)
98 Aleksey
 
11.10.12
23:40
Теорию можно почитать тут http://pro1c.org.ua/index.php?showtopic=5683
или такой вариант http://www.1cpp.ru/forum/YaBB.pl?num=1243496545/all
99 Надсмотрщик
 
11.10.12
23:46
(93) Все решается элементарно с помощью пустышек
100 Злопчинский
 
12.10.12
00:27
(99) нахрен пустышки. изврат неимоверный. а все что требует извращенных решений с привлечением ненужных допсущностей - скольо раз убеждался нахрен нежизненно.
101 Andreyyy
 
12.10.12
00:29
(99) Согласен, уже продумали схему с перемещениями:
Создается пустышка прихода в периферии, заполняется в центре и когда проводится то создается еще один документ (условно перемещение), который списывает товары, но остается в центральной базе. Таким образом все регистры закрываются. Нюанс с регистрацией изменений первичного документа, придется добавлять признак изменения и обработку в центре запускать постоянно чтобы отслеживала и изменяла второй документ соответственно.
(100) Поначалу показалось извратом, но когда всего за пару часов набросал систему ввода новых доков понял насколько быстро разрабатывается и пользователи ничего не видят "за занавесом".
102 Злопчинский
 
12.10.12
00:32
(101) раньше и 3.14дарасы были в диковинку... а ща в порядке вещей - но это не значит что они мне нравятся тьфу..тьфу.. хотя некоторым говорят без этого не прожить...
103 Aleksey
 
12.10.12
00:34
(100) Нормально работает с пустышками
104 Злопчинский
 
12.10.12
01:07
(98) спсаибо за ссылочку вторую - практически на 100% то что надо.. еще бы там живой кто в ветке был.. ;-)
105 Злопчинский
 
12.10.12
01:07
(103) я не возражаю... я уж лучше хирургическим методом.. а то вся эта нетрадиционная мыдыцына...
106 Aleksey
 
12.10.12
01:12
Ну там вроде бы Eprst засветился и он живой вроде бы
107 Злопчинский
 
12.10.12
01:14
(106) ок.
в принципе, с той подчисткой что я сделал с помощью сообщества - будут жить еще пару лет ;-)
108 Злопчинский
 
12.10.12
01:16
..единственное, что не понял - регистрируются изменения документов, а движения регистров по зарегенным докам идут "паровозом"..?
109 Aleksey
 
12.10.12
01:28
(108) Да в типовой регистрируются только документы/справочники/константы, движения автоматом тянутся
110 Aleksey
 
12.10.12
01:28
Для движений ты максимум можешь запретить миграцию и всё
111 Злопчинский
 
12.10.12
03:49
(110) а как я из документа могу запретить миграцию только половины движений?
112 Mikeware
 
12.10.12
07:51
(111) никак.
113 Надсмотрщик
 
12.10.12
09:43
(103) А ты возражал.   С тебя пиво!
114 Aleksey
 
12.10.12
09:51
(113) Я? Я к Злопчинский не имею отношение
115 Надсмотрщик
 
12.10.12
10:27
(114) Пиво пожалел на мыло скинуть   ;-(((
116 mista2012-09-11
 
12.10.12
10:36
(0) Че за хня - а префиксы то зачем тогда??? У меня уже 6 лет как я на фирме перемещения и складские доки с ПБ 771 не могут попадать в ПБ 881 - только в ЦБ
117 mista2012-09-11
 
12.10.12
10:38
милай - делая так - перемещения должны делаться в самих
ПБ
118 Злопчинский
 
13.10.12
01:25
(117) дадада, особенно когда инициатором перемещения является центральный офис... хвост виляет собакой
119 Torquader
 
13.10.12
02:18
На самом деле, необходимость создания документов в периферийной базе связана с тем, что мы не можем создавать документ с произвольным ID, так как в каждой базе ID идут по порядку. А хвост префикса определяет принадлежность документа к базе.
Однако, можно использовать для каждой периферийной базы два префикса - один для отправки документов из центральной базы, в другой - для получения из периферийной.
В этом случае, будет возможность фильтрования по префиксу в ID и ничего лишнего куда не надо не попадёт.
Вот только файлы обмена придётся немного править.
120 Надсмотрщик
 
13.10.12
09:25
(118) Не пудри мозги молодежи. И выполни свое желание:- "хотел бы пойти падаваном на 8-ку... "
121 Mikeware
 
13.10.12
09:44
(118) Не обращай внимания. Это завсом.
122 Mikeware
 
13.10.12
09:45
(119) имхо, ты пьян....
123 milan
 
13.10.12
10:04
Ромиксовая компонента для регистрации изменений + своя выгрузка/загрузка на 1спп - все работает отлично, монопольный режим не нужен, все правила настраиваешь в центре, на стороне филиалов работает само
124 Последний Русский
 
13.10.12
13:28
(0) Можете сформулировать задачу в терминах пользователя (предметной области) без использования терминов 1С?
125 Mikeware
 
13.10.12
13:50
(124) Александр, ранее ты был более хорошим телепатом :-)
126 Последний Русский
 
13.10.12
15:57
(125) остался таким :-) Подозреваю, у (0) есть первичное требование, решаемое штатными средствами, но догадки хочется проверить после ответа на (124).
127 Злопчинский
 
13.10.12
16:37
(120) кто ж мну возьмет...
128 Злопчинский
 
13.10.12
16:40
(124) формулирую: надо чтобы в точки-магазины попадала только предназначенная для этих-точек магазинов информация.
129 Злопчинский
 
13.10.12
16:41
(123) это какая?
130 Последний Русский
 
13.10.12
18:49
(128) Первичное требование будет, или тут конкурс телепатии среди прогов? :-)
131 Andreyyy
 
13.10.12
19:01
(128) Для тех, кто невкурил тему "пустышек", как сейчас реализую:

1. При запуске периферийной базы создается условно-необходимое количество "документов-пустышек", назовем их "Приход" - с датой "апокалипсиса", дабы не видеть их в журналах нашего времени.
2. Соответственно эти документы попадают в центр (правила миграции "Место создания-центр".
3. В центре создается пользователями документ "Перемещение", который так же может создаваться и в другой периферийной базе.
4. Проводится и формируются движения только РАСХОД (поскольку к примеру при партионном учете строки могут разбиваться, то движения ПРИХОДА пишутся в дополнительный оборотный регистр.
5. Регламентная обработка заполняет "Пустышку - "Приход" и проводит, которая делает движения ПРИХОД согласно дополнительному регистру.
6. Документ "Приход" попадает в периферийную базу.
7. Профит.

Поправьте, если можно упростить.
132 Andreyyy
 
13.10.12
19:03
(124) Пользователям нужен шустрый обмен и (128)
133 Andreyyy
 
13.10.12
19:07
+(131) Добавлю, что остальные виды документов, которые должны попадать только в определенную базу тоже потребуется делать из пустышек.
134 Злопчинский
 
13.10.12
19:52
Гемор. куча ненужных сущностей, плюс переписывание типовой, причем не в 1-2 строчки. все-таки проще чистить периферийную базу или файл обмена/регистрацию обмена.
135 Последний Русский
 
13.10.12
19:57
(131) Хороший пример для иллюстрации http://www.informat.name/humor/project.htm
136 Andreyyy
 
13.10.12
20:26
(134) У меня самописка (два десятка документов) + дбф + обмен "звезда", потому проще конечно. Но на мой взгляд в варианте (41) преимущества в надежности и времени на отладку/тестировании очевидны.
(135) Не уловил юмора. Поддержите своими предложениями.
137 Злопчинский
 
13.10.12
20:46
(135) во-во.. ;-)
138 Andreyyy
 
13.10.12
21:09
(137) Очень похоже на поддержку медвепутов на выборах.
139 Злопчинский
 
13.10.12
21:10
(138) а мну по барабану...
140 Andreyyy
 
13.10.12
21:24
(139) По барабану тоже больно бывает. А обосновать поддержку поста (135) хотелось бы увидеть объективную.
Судя по посту (75) я много пропустил (может и еще кто) и уверен, что ветка кому-то поможет.
141 Злопчинский
 
13.10.12
21:44
(140) Хотите ? хотите дальше! ;-)
каждый выбирает сам какое решение применять.
142 Злопчинский
 
13.10.12
21:45
(140) тем более, что решение с пустышками решает проблем миграции, но не решает про блему частичной миграции, например - половины движений по документу перемещения...
143 Andreyyy
 
13.10.12
21:56
(142) Далеко не претендую на удобное решение, но в (131) раздвоение документов решает эту проблему в контексте поставленной задачи в (0).
144 Злопчинский
 
13.10.12
22:11
(143) дадада, главное, исправив что-то в одном документе - не забыть исправить и в другом...
145 Andreyyy
 
13.10.12
23:23
(144) Технические нюансы есть конечно, не все так гладко.
146 Andreyyy
 
13.10.12
23:27
+(144) Но из двух зол как говорится выбирают меньшее.
147 Semen
 
13.10.12
23:50
(102) Жесть!

(143 ) а зачем при раздвоении документов пустышки вообще?
148 Andreyyy
 
14.10.12
00:03
(147) А каким образом обмениваться документами только с определенной ИБ ?
149 Злопчинский
 
14.10.12
00:04
(147) иначе будут мигрировать на все ПБ
150 Semen
 
14.10.12
00:22
(149)
а зачем мигрировать на все?
Половинка остается в ЦБ (или другой периферийке и передается в Центр)
а в периферийной базе создается приход, по поступлении товара, который тоже попадает в ЦБ. При этом движения по регистрам вовсе не обязательно гонять в ЦБ.
Только сам документ.
151 Andreyyy
 
14.10.12
00:49
(150) Как в периферийной базе создастся приход ?
152 Semen
 
14.10.12
01:27
(151) Из расхода выгружается в xml файл, сжимается раром под паролем, и отправляется на мыло (записывается на переносной носитель).

В базе приёмнике, по поступлении товара с бумажным носителем, загружают его электронную копию, сверяют наличие... всё, круг замкнулся.
153 Andreyyy
 
14.10.12
02:25
(152) Исключительное желание остаться при средствах обмена самой платформы.
154 Semen
 
14.10.12
02:35
(153)
так вы и остаетесь, можете не передавать электронный дубликат.
Это по любому не отменяет приём и пересчет товара материально ответственным лицом на периферии ...
Логически
вы отгрузили товар в магазин
у вас со склада он ушел, но это вовсе не означает, что он уже пришел в магазин. А документ перемещение именно это и делает.
В бухгалтерском учете эта ситуация разобрана на составляющие.
Деньги, материальные ценности там всегда имеют ответственного... деньги в дороге, товары во внутрихозяйственном обмене.
155 Последний Русский
 
14.10.12
15:05
(136) Скажите мне, чего хотел пользователь, тогда, возможно, предложу решение с использованием штатных средств УРБД. До сих пор:
(0) -> 1-3 с картинки (135)
(131) -> 4-5 с картинки (135)
Основная мысль - при правильно организованном учете достаточно штатных средств УРБД.
156 Злопчинский
 
14.10.12
15:37
(155) Ну подскажи как. Только безо всяких доп.приблуд типа пустышек и (желательно) без подчисток регистрации изменений и файлов обмена.

Есть фирмаО+складО = Оптовый; есть N точек ФирмаN+складN - розничные.

Все фирмы принадлежат одному юрлицу, так что необходимости перепродаж между фирмами центра и периферии - нет.

Конфигурация - типовая ТиС.
Товар из оптового склада-фирмы на розничный склад-фирмы перемещается обычным Перемещением ТМЦ между фирмами-складами.

Вот такой УЧЕТ. Правильно или неправильно - какой есть.

Как это сделать штатными средствами УРБД?
157 Злопчинский
 
14.10.12
15:38
Как это рассказать дрругими словами, без привлечения "предметки 1С" - я затрудняюсь... ;-)
158 Последний Русский
 
14.10.12
18:45
(156) А что тут мудрить? Миграция для ПеремещениеТМЦ = "Все ИБ".
159 Андрей_Андреич
 
naïve
14.10.12
19:01
Блин, Я, похоже, лох, но шел бы Злопчинский на восьмерку, раз прогать не умеет. Не - правда - годами хрень несешь - шел бы в манагеры - может больше заработал бы.
160 Злопчинский
 
14.10.12
19:35
(158) а зачем на точке1 перемещения для точки2..?
161 Злопчинский
 
14.10.12
19:37
(159) возможно я прогать и не умею, зато умею делать так, что контора способна работать и выполнять свои функции, в отличие от техз кто дохрена прогает, но в конторе бардак..
162 Mikeware
 
14.10.12
20:02
(131) Ох и любите вы ходьбу по граблям...
(152) чрезжопица полная...
(159) а почему "похоже?"?
163 Надсмотрщик
 
14.10.12
20:43
Еще идею подкинуть? Как обойтись без пустышек?
Только я так справочники гоняю.
164 Последний Русский
 
14.10.12
21:53
(160) Странный вопрос, с учетом (161) :-) В любой точке состояние склада должно отражать реальную картину, поэтому все перемещения должны быть во всех базах. Показ документов можно ограничить, но лишено смысла. Лучше ограничить в правах на изменение документа, созданного в чужой базе.
165 Злопчинский
 
14.10.12
22:01
(164) это подгонка под действительность.
с точки зреняи "бизнеса" - точка/магазин - самостоятельная единица. и состояние склада = состоянию точки.
.
пока что незачет...
166 Злопчинский
 
14.10.12
22:02
(163) давай.
167 sdv2000
 
14.10.12
22:09
(161) кросафчег
168 Злопчинский
 
14.10.12
22:10
9164) вдогонку еще... из выбраннйо ранее схемы учета - н аточках не должно быть видно состояни дел в центре. Поэтому приходы на оптовый склад на точки не мигрируют... и получаются на точках "висящие" списания тмц с опотовго склада..
169 Надсмотрщик
 
15.10.12
00:28
(166) По правилам, установленным мною, на ПФ пользователь имеет право вводить только контрагентов.
Возникла необходимость вводить МНОЮ элементы некого справочника от имени ПФ (миграция переферия-центр)
Я в обработке ввожу эти элементы в файл XML и отправляю его на ПФ по почте. Одновременно в ЦБ ввожу идентификатор в спец справочник временных элементов, который, периодически этой же обработкой, очищается. Там в автомате, при заходе в базу под определенным пользователем, считывается этот файл и вводятся эти элементы в справочник на ПФ. При следующем обмене это все приходит ко мне.
В дольнейшем на данной ПФ документами изменяю реквизиты элементов данного справочника. И это все идет ко мне!
170 Злопчинский
 
15.10.12
03:18
(169) однако мсье знает толк в извращениях! ;-)
171 Последний Русский
 
15.10.12
06:20
(165) Понятно, каша в голове :-)
172 Mikeware
 
15.10.12
07:51
(171) каша. но не у него... :-)
173 Андрей_Андреич
 
naïve
15.10.12
08:09
(170) Я тут вчера нахамил - извиняюсь. Был нетрезв. Но ты правда нудный :)
174 kloptula
 
15.10.12
08:18
(168) Ну а что собственно криминального в том, что будут висеть минуса по другому складу (по основному или по другому магазину) в базе текущего магазина.
175 Последний Русский
 
15.10.12
08:55
(165) (168) При твоей концепции:
Покупатель: "Дайте эту штучку..."
Продавец: "У нас нет".
Покупатель: "А где есть?"
Продавец: "Не знаю, звоните в центральный офис".

При моей концепции:
Покупатель: "Дайте эту штучку..."
Продавец: "На нашей точке отсутствует, но есть на точке 2 и точке 3. Где вам было бы удобнее забрать, в нашем магазине через 2 дня или самостоятельно в точке 2 или 3? Поставлю в резерв, заберете гарантированно!".
Покупатель: "Удобнее в вашем магазине".
Продавец: "Хорошо, заказал, зарезервировал. Приезжайте через 2 дня".

Какая концепция для бизнеса правильнее? :-)
176 Mikeware
 
15.10.12
09:11
(174) Про "закрытие регистров" что-нибудь слышали?
177 Mikeware
 
15.10.12
09:13
(175) офигительно, особенно когда между точками "0", "2" и "3" расстояние пару сотен километров (при том, что вместо дорог между ними "направления")...
178 Надсмотрщик
 
15.10.12
09:37
(170) Поработай с мое, не до того дойдешь.   ;-)))
179 kloptula
 
15.10.12
10:05
(176) В конкретно моем случае, в каждой периферии приходные накладные делают сами (нет централизованного склада), перемещений очень немного и периферийные базы создаются каждый год заново. Так что незакрытые регистры присутствуют в периферийках, но пофиг. Главное в центральной базе все хорошо, т. к аналитикой занимаются люди, работающие в центральной базе.
180 akaBrr
 
15.10.12
10:10
(175) информацию по остаткам можно передавать не используя механизм УРБД, например поднять вэбсервер откуда периферийка через вебсервис будет подтягивать данные по остаткам интересующих товаров
181 kloptula
 
15.10.12
10:11
(175) Чтобы в любой периферийной базе видеть остатки по другим периферийкам, нужно не только перемещения мигрировать везде, но и приходные и расходные документы тоже. У нас так было изначально, но хранить в каждой точке полную копию базы не вариант. Не безопасно это как-то
182 akaBrr
 
15.10.12
10:11
+(180) это про остатки в других периферийных базах и ЦБ
183 Mikeware
 
15.10.12
10:17
(180) Можно через регламентный документ - на момент обмена заполняется триггером, регистрируется и отправляется во все ПБ.
Ну и, соответсвенно, в ПБ корректируется механизм получения остатков для просмотра (для текущей базы - из регистров, для прочих баз - из регламентного документа)
184 Mikeware
 
15.10.12
10:18
(179) м-дя.. знаете толк в извращениях...
185 kloptula
 
15.10.12
10:21
(184) А что делать...
186 Mikeware
 
15.10.12
10:22
(185) строить работу так, чтобы не требовалось регулярного вмешательства человека... "работать должны роботы"©
187 akaBrr
 
15.10.12
10:24
(183) в доке больше 9999 строк делать не рекомендуется и табличка ТЧ дока будет пухнуть
188 akaBrr
 
15.10.12
10:25
(183) док будет один?
189 Mikeware
 
15.10.12
10:28
(188) у меня их 48 (по одному на каждый обмен) соотвественно, переписывается "самый последний" - становится "самым первым"...
ну и остатков товаров немного - не более 2000 на каждом складе, но я отправляю только остатки ЦБ...
190 kloptula
 
15.10.12
10:30
(186) Жить хорошо, когда есть инструменты для работы. У Вас скуль, у нас нет такой роскоши.
191 Mikeware
 
15.10.12
10:34
(190) это да...
192 Последний Русский
 
15.10.12
10:46
(180) (183) ...и понеслась "звезда по ухабам..."! :-)
(177) моя концепция решает задачу (156) штатными средствами.
Для вашей задачи у меня есть другое решение, использующее только штатные средства УРБД без всякого рода программистских заморочек (триггеры-шмиггеры :-) http://new.abelov.com/contacts/about/reviews/354/

(181) Только программист может настоять на замене правильного решения кривым, пугая пользователя страшилками об отсутствии безопастности :-) И для задачи (0) есть первичное требование пользователя, решаемое штатными средствами УРБД. Программисты легко увлекаются, забывая о том, чего хотел пользователь (135) :-)
193 kloptula
 
15.10.12
11:15
(192) У нас как раз "продвинутый" директор озаботился безопасностью. Программист - наёмный человек, а незаменимых нет
194 Злопчинский
 
15.10.12
11:56
(174) траблы простые - распухание файлов итогов, открытие месяца по нескольку часов.
195 Злопчинский
 
15.10.12
11:59
(175) Правильне концепция бизнеса - когда нужный товар присутствует на точке. Потому что а) клиент через два дня не придет б) накладные расходы на перемещение товара из соседних точек больше, чем потеря от  отсутсвия товара.
.
короче понятно. ничего нового предложить нет ;-)
(так и запишем ;-)
196 Злопчинский
 
15.10.12
12:01
(192) > На основе 1С:Бухгалтерии 7.7 организована распределенная информационная база, с настроенным обменом между узлами в условиях отсутствия интернета
.
блинаааа.. это как? почтовыми голубями?
197 akaBrr
 
15.10.12
12:05
(192) Для вашей задачи у меня есть другое решение, использующее только штатные средства УРБД - и что там?
198 Надсмотрщик
 
15.10.12
12:29
(196) Флешкой
199 akaBrr
 
15.10.12
12:53
+(197) И тишина, типичное бла-бла, с битьем копытом в грудь.
200 DJ Anthon
 
15.10.12
12:55
(200)
201 Последний Русский
 
15.10.12
13:48
(195) А чего ты хочешь НОВОГО от 7.7+УРБД? Свое решение для условия (156) озвучишь?
Моему решению (192) уже более 7 лет и оно работает даже без программистов и интернета!
202 akaBrr
 
15.10.12
14:09
(201) в (192) нет ничего чтобы позволило оценить "решение"
203 Последний Русский
 
15.10.12
14:27
(202) Вы считаете, что мне необходима ваша оценка моего решения? :-)
204 akaBrr
 
15.10.12
14:35
(203) ахах, ну конечно нет, вы ведь здесь просто пальцы раскинули, что здесь оценивать?
205 Mikeware
 
15.10.12
15:45
(203) а это никакое не "решение" - просто установленная и настроенная распределенка. И не более того.
Так, уровня начинающего внедренца, или младшего сотрудника-стажера франча...
206 Mikeware
 
15.10.12
15:46
(201) "нового" может быть много. ИНструмент УРБД достаточно гибкий, если уметь им пользоваться.
207 Последний Русский
 
15.10.12
16:56
(206) Инструмент гибкий в пределах своих ограничений и достаточно старый, чтобы пытаться открыть в нем для меня что-то новое.
(204) (205) Ну, как? ЧСВ выросло после таких оценок? :-)
208 akaBrr
 
15.10.12
16:59
(207) кроме вас тут никто свое ЧСВ не пытается поднять, выдыхайте
209 Mikeware
 
15.10.12
17:00
(207) Ограничений при грамотном использовании умелыми руками  - мало.
210 Злопчинский
 
15.10.12
18:48
Господа, чтобы прекратить все кривотолки - замечу: Д'Артаньян здесь один я...
211 Последний Русский
 
15.10.12
18:56
(210) нетипичное лечение головной боли http://youtu.be/s73GjbSw5xY или как руководитель предприятия наказывает программиста за нетипичное использование компоненты УРБД :-)
212 Злопчинский
 
15.10.12
19:04
(211) это из собственного опыта управления проектами? не пойду я к вам! ;-) рекомендую данный ролик пустит бэкграундом на выступлении ИнофтартЭвент... ;-)
213 ПиН
 
15.10.12
19:06
Саша на инфостарте будет делиться опытом по выставлению счетов на многие десятки тысяч рублей за запуск восстановления последовательности у клиентов?
214 Злопчинский
 
15.10.12
19:07
(213) а почему бы и нет? если клиент не способен найти других исполнителей - то такая цена вполне себе обоснована...
215 ПиН
 
15.10.12
19:07
или уникальным способом внедрения урбд без использования интернета с использованием оленьих упряжек в условиях горной местности?
216 ПиН
 
15.10.12
19:08
(214) так я разве в укор, молоток наоборот, жизнь по принципу "без лоха и жизнь плоха" вполне себе имеет право на сущетсвование
217 Злопчинский
 
15.10.12
19:22
№все крупные сотсояния нажиты нечестным путем.."...?
218 monitor
 
15.10.12
19:30
А что бы сказал народ если бы можно было создавать документ с заданным внутренним ID? Например в централке можно было бы создать документ перемещения в магазин с внутренним идентификатором соответствующим этому магазину. И УРБД молчаливо уносит его в эту периферийку..
219 Злопчинский
 
15.10.12
19:37
(218) индексы?
220 monitor
 
15.10.12
19:40
(219) внешняя компонента
221 Andreyyy
 
15.10.12
20:18
(218) Это пожалуй решило бы часть проблем.
222 Злопчинский
 
15.10.12
20:19
(220) я не против, но как при этом поддерживать целостность базы на уровне индексов? и надо ли это делать с индексами?
223 Злопчинский
 
15.10.12
20:20
(221) при этом надо взвести "флажок" изменения этого перемещения для УРБД - иначе не унесет..?
224 Andreyyy
 
15.10.12
20:27
(223) Флажок сам взведется при создании документа. Другое дело в какой момент ему удастся подсунуть "правильный" идентификатор, а то флажок останется на уровне одной базы - центра.
225 Andreyyy
 
15.10.12
20:29
Будет серьезная проблема с нумерацией идентификаторов, не взлетит.
226 monitor
 
15.10.12
20:38
(225) проблем не будет если провести некую подготовку при создании новой базы. Для новой, пустой базы принудительно создается документ с ID равным, ну например 1000000. Все последующие документы в базе автоматом пойдут инкрементом от этого ID. Таким образом у нас есть некоторое количество зарезервированных ID которые гарантированно не будут созданы штатными механизмами 1с-ки. Остается завести счетчик (константу например) и создавать документы по нему, добавляя к ID нужный суффикс периферийки.
227 monitor
 
15.10.12
20:41
(221) ID подсовывается 1С-ке при создании документа. Так что УРБД уносит штатно.
228 monitor
 
15.10.12
20:41
(227) к (223)
229 Andreyyy
 
15.10.12
20:48
(226) Что-то мне подсказывает, что после попадания из центра документа с ID 100000000 в периферийную базу, там уже будут создаваться документы исходя из этого.
Поправьте, если кто знаком ближе с таким нюансом.
230 SWD
 
15.10.12
21:01
(229) Расскажите как вы ИД будете подсовывать?
231 Andreyyy
 
15.10.12
21:09
(230) Просто теория в (218)
232 Злопчинский
 
15.10.12
21:12
(230) впихнем невпиху/\емое!
233 SWD
 
15.10.12
21:17
(232) Невпехнут. В по крайней мере в дбф 1с использует первичный ключ в виде строки, причем с ведущими пробелами. У меня был легкий шок, братья нур сделали все чтобы убить производительность.
234 SWD
 
15.10.12
21:18
Вернее тот самый ИД36 для документоа
235 monitor
 
16.10.12
01:58
(229) совершенно верно, именно это и нужно. Чтобы вся база работала с ID начиная с 1000000. А я буду себе создавать документы с ID до 1000000.
236 monitor
 
16.10.12
01:59
(231) эта просто теория уже лет 5 как работает
237 Последний Русский
 
16.10.12
06:19
(213) не понял, завидуете, сударь, или сплетничаете, сударыня? :-)
238 Mikeware
 
16.10.12
07:10
(218) Создавая документ с идом, принадлежащим периферийке, ты либо задвоишь иды в периферийке (попадешь на используемый), либо, "отступив" гарантированно далеко, сделаешь дырку в идах периферийки (после обмена нумерация идов будет с максимального), и достаточно быстро исчерпаешь иды.
(да, в 226 - частное решение)
(226) можно новые иды "считать обратно", кстати. реализуемо, и не очень сложно.
вполне себе вариант. но мне он не нравится. Для сиквельных баз подойдет, в файловых будут проблемы с индексами.
239 monitor
 
16.10.12
09:10
(238) ну насчет быстрого исчерпания я не согласен. У меня же отложенные ID используются только документами перемещения из/в магазин. Прикинул, и отступил с очень приличным запасом, предварительно посмотрев какой вообще максимальный ID выдержит 1с.
240 Андрей_Андреич
 
naïve
16.10.12
09:13
Что только люди не придумают, лишь бы МОД не юзать. Специально же для этих случаев придуман.
241 Mikeware
 
16.10.12
09:35
(239) три пути: первый - постоянно отступать "вперед" с запасом. Получишь дырки. и исчерпание.
второй: в ПБ иды с фиксированного значения. в цб создаешь иды с начала до фиксированого значения, храня текущий (ну, или очередной) в каком-то хранилище. (как я понял, твой текущий вариант). имеешь потенциально неиспользуемый диапазон, но это не страшно (главное, его правильно выбрать), а до исчерпания все равно не дойдешь.
третий - то же, что и второй, только чуть проще - считать иды "вниз" от первого использованного для этой периферийки. (не нужно его нигде хранить)
242 Mikeware
 
16.10.12
09:36
(240) в первых версиях он доставлял немало геморроя.
да и зачем, собственно, если все можно легко разруливать руками...
243 monitor
 
16.10.12
09:39
(241) ну да. примерно так. Дырки не страшны, а при исчерпании отложенного диапазона всегда можно отступить еще раз.
244 Андрей_Андреич
 
naïve
16.10.12
09:40
(242) Так мне имхается - товарищ уже заикался о преобразовании типов документов и прочем. Как бы в результате за несколько лет напишет кривой аналог МОДа :)
245 Mikeware
 
16.10.12
09:45
(244) преобразование типов - имхо, идиотизм...
его задачи вполне штатно решаются штатными методами через лишний - "транзитный" -склад.
246 Андрей_Андреич
 
naïve
16.10.12
09:53
(245) Что такой ласковый-то? Ничего плохого, если перемещение с центрального склада на точку передастся как приходная накладная или что-то в этом роде. Иначе придется мириться с незакрытыми регистрами или дописывать, чтобы в ПБ перемещения только приходовали товар.
ой - сейчас меня с оном смешают. блин работы куча а я тут нарываюсь
247 Mikeware
 
16.10.12
09:57
(246) ничего хорошего. ибо документ должен отражать факт жизни.
и (что касается разных движений) должны быть одинаковы во всех базах.
248 Андрей_Андреич
 
naïve
16.10.12
10:06
(247) Ни в одной библии это не написано. Дело привычки. Открою Вам страшную тайну - когда я выдаю клиенту счет-фактуру выданную - у него она становится счет-фактурой полученной. И ни у кого крышу не сносит :)
249 Mikeware
 
16.10.12
10:21
(248) "у него" и "у тебя" - разные контексты.
а единая РБД - это единый контекст.
один факт в одной базе может порождать более одного документа - но тем не менее, эти документы тогда должны быть связаны.
ТС делает _перемещение_ и хочет отражать это куплей-продажей. Идиотизм. равно как идиотизм отражать куплю-продажу перемещением.
250 Андрей_Андреич
 
naïve
16.10.12
10:28
(249) Размышляя в рамках точки - для них это приход. Чтобы это было перемещением - на точке должна быть полная копия базы. Перемещение со склада, на котором и так висят миллиардные минуса тоже нелогично. Вот какого лешего на точке годами висит склад с минусами?
251 Mikeware
 
16.10.12
11:20
(250) размышляьть нао не в рамках точки, а в рамках всей РБД.
кроме того, нет такой операции - "просто приход". Есть либо поступление товаров от поставщика, либо перемещение между складами.
252 Андрей_Андреич
 
naïve
16.10.12
11:26
(251) Я, конечно, сейчас мозги клюю, но кладовщик или продавец в рамках РБД размышлять не должен. Он за товар расписался, что ему пришло. Двойная запись его не волнует. Ладно - завяжем, меня занесло.
253 Mikeware
 
16.10.12
11:33
(252) В рамках РБД должен размышлять тот, кто систему проектирует и внедряет.
за это ему и платят больше, нежели кладовщику или продавцу...
254 kloptula
 
16.10.12
11:33
А лучше всего, когда нет вообще РБД, а есть терминальный сервер с работой всех в одной базе. Но в реаоиях провинции - это пока на утопию похоже
255 Mikeware
 
16.10.12
11:40
(254) это вопрос философский.
вероятность устойчивость работы системы с РБД есть произведение вероятностей устойчивой работы сервера ЦБ, устойчивой работы канала связи и устойчивой работы прокси на периферии... Т.е. всяко ниже "распределенки". Ну и в "централизованной системе" есть все данные, даже которые не нужно видеть.
в случае РБД базы работают в достаточной мере независимо, выше защищенность, ниже требования к каналам связи - но возникают вопросы потери обменов, коллизий и т.п.
все решается для каждой конкретной ситуации.
256 Андрей_Андреич
 
naïve
16.10.12
11:48
+255 Еще и производительность системы надо считать. Работали в базе полста юзеров, а к ним с филиалов / розницы еще сотня подключилась - совсем другой расклад получается
257 Cthulhu
 
16.10.12
11:50
(250): ну регламентный(по-месячный) документ без миграции - с соответсвующим авто-заполнением и реестровой печ.формой с перемещениями за отчетный период (и иными "плюшками") - и для МОЛ не будет лишним. а движениями будет нулить остатки, "уехавшие" за счет полученных из других ИБ движений. ммм?..
258 Андрей_Андреич
 
naïve
16.10.12
11:51
(257) Если часы остановить - 2 раза в день они покажут точное время
259 Cthulhu
 
16.10.12
11:52
(258): т.е. по сути сказать нечего - я правильно понял?..
260 Андрей_Андреич
 
naïve
16.10.12
12:00
(259) Так суть не была обозначена. Если суть в том, чтобы раз в месяц обнулять остатки, чтобы не пухли регистры - почему бы и нет. А в течение месяца белиберда по остаткам в отчетах и формах подбора так и будет. Хотя на это спокойно можно забить и сказать - так положено. А что положено на это дело программистом - не говорить :)
261 Cthulhu
 
16.10.12
12:07
(260): суть обозначена - и заключается в решении указанной в (250) проблемы с накоплением отрицательных остатков на складах-источниках перемещений из-за приехавших "прицепом" к перемещениям других движений. хотя зачем я это объясняю - непонятно, как, впрочем, непонятна и причина того, что ті заявляешь, что "сути нет", и тут же єту суть формулируешь.
в течение месяца проблемы тоже особой нет - благодаря четкому разделению складов ПБ на "свои" и "чужие". подкручивается на раз-два.
262 Andreyyy
 
16.10.12
12:48
(236) Не поделитесь методами создания произвольного ID документа ?
(249)(251) Категоричность признак глупости и я бы не стал однозначно утверждать как нужно оперировать данными в рамках УРБД. В констексте поставленной мне задаче движения в ПБ должны попадать только их, а уж как документ назовется "Купи/продай, Оприходование, Мана небесная" глубоко пофиг.
263 Cthulhu
 
16.10.12
12:58
(262): тогда лепи ещё ПБ "товары в пути"...
264 Andreyyy
 
16.10.12
12:59
(263) Если понадобится, почему бы и нет.
265 Mikeware
 
16.10.12
13:04
(262) 1.а какие проблемы сгенерировать документ с нужным id'ом?
2. Признак глупости - название, не отражающее сути. Или имеющее разночтение с общепринятыми определениями.
зы. Назови у себя в базе приходный документ "списанием", ПКО - "Расходом", инвентаризацию - "платежным поручением"... пофик же? :-) пусть запоминают...
ззы.
"#define TRUE FALSE  //счастливой отладки, суки..."©
266 Andreyyy
 
16.10.12
13:12
(265) 1. На вопрос вопросом ...
2. Имя документу дал не мудрствуя лукаво "Приход по перемещению" с подсказочкой снизу, о ! Теперь остается набрать даунов на работу, чтоб было кому не понять что отражает этот документ.
267 Mikeware
 
16.10.12
13:21
(266) 1. Так в чем вопрос? Имена таблиц известны, структура базы известна, форматы идентификаторов известны...
2. считай меня дауном, но перемещение - оно одно. по определению.
зы. у вас есть внктри компании словарь террминов, глоссарий, корпоративный справочник? база знаний?
268 monitor
 
16.10.12
13:55
(267) не, лезть в таблицы чтобы создавать с нужным ID не айс. Это отдельно для SQL, отдельно для DBF, проблемы всякие полезут.
269 Mikeware
 
16.10.12
13:57
(268) а другого способа нет.
ну, разве что кроме "создать штатно, а потом заменить ид на свой" :-)
если есть другой способ - скажи :-)
270 monitor
 
16.10.12
13:59
(269) ну я бы не был столь категоричен. Есть такая функция в кишках системы, называется GetDefDBSign. Вот к ней и можно приклеиться и подменить вновь сформированный ID на свой.
271 Злопчинский
 
16.10.12
14:06
(249) именно.
именно так у моего клиента и было и есть и будет.
ибо все зависит от частностей.
у меня частность простая - на ПБ по сути кассовая точка с нескольо расширенным функционалом. и даже то, что туда приходят инфа для других ПБ - не мешает, bmj точка работает по исключительно по своему "складу", а объем данных на точке таков, что достаточно один раз в пару месяцев подчистить ПБ прямым запросом, удалив все чужое и переиндексировать базу ...
272 Mikeware
 
16.10.12
14:14
(270) Возможно. не пробовал хучить самостоятельно.
Но такой способ ничем не лучше прямого доступа к базе.
273 monitor
 
16.10.12
14:24
(272) ну почему же, как мне кажется - лучше и универсальней. Засчет того, что с базой работает сама 1С-ка и мы ей не мешаем.
274 Mikeware
 
16.10.12
14:26
(273) И ваять отдельную компоненту?
275 monitor
 
16.10.12
14:29
(274) ну да
276 Mikeware
 
16.10.12
14:31
(275) возникает ТКВ...
277 Andreyyy
 
16.10.12
15:23
(267) Ага, осталось заказчику сказать, что млин из-за неопределенных религиозных соображений идейной ценностью общепринято не разбивать документы. Придется таскать всю базу по всем точкам и пусть они там смотрят всю инфу (можно и попортить заодно), и ипутся с обменом на мегафоновских свистках.
(275) Совершенно случайно не видели подобной компоненты в широком доступе ?)
278 Mikeware
 
16.10.12
16:31
(277) базу совершенно не нужно таскать по всем точкам. И более необходимой информации отправлять в ПБ тоже не нужно.
279 Andreyyy
 
16.10.12
16:43
(278) Честно говоря я притомился из пустого в порожнее лить, на мой взгляд большинство возможных варианты обсудили в этой ветке.
280 Надсмотрщик
 
16.10.12
16:48
(278)(279) Все еще трете?   ;-))
281 Mikeware
 
16.10.12
16:49
(280) просто похоже, что ТС - франч...
282 Andreyyy
 
16.10.12
16:58
(281) Троллинг откровенный пошел ?
283 Mikeware
 
16.10.12
17:01
(282) ага. прямой и непосредственный.
ибо только для франчей "желание заказчика - закон". а фиксям приходится  ср@ться до зеленых соплей с руководством, чтобы поняли, что "так делать нельзя". Хреново бывает, когда то, что иногда руководство побеждает, и что "так делать нельзя" доходит через пару месяцев...
284 Andreyyy
 
16.10.12
17:10
От темы явно ушли, для любопытных - никогда в структуре франчайзи не работал.
285 akaBrr
 
16.10.12
17:11
(283)  Хреново бывает, когда то, что иногда руководство побеждает, и что "так делать нельзя" доходит через пару месяцев... - я поэтому стараюсь все записывать :)

Хоть как-то ж.пу прикрыть :)
286 akaBrr
 
16.10.12
17:12
+(285) еще помогает расчет затрат на реализацию "так делать нельзя" и на исправление ситуации
287 Mikeware
 
16.10.12
17:20
(285) Да прикрыть-то проблем нет. правило "больше бумаги - чище жопа" - никто не отменял. обидно бывает... сейчас вон перетаскиваем в снеговика всё, на некоторые вещи достаю служебки - ржем всем отделом.
288 Andreyyy
 
16.10.12
17:50
(236) А на коммерческой основе возможно поюзать вашу теорию ?
289 Mikeware
 
16.10.12
18:02
(288) если центральная база - сиквельная, то  генери ид вручную, и пиши в таблички.
290 Andreyyy
 
16.10.12
18:14
(289) Удачи вам в этом безнадежном деле.
291 Mikeware
 
16.10.12
18:16
(290) почему ж безнадежном? Сейчас так документы из снеговика грузятся :-)
292 Andreyyy
 
09.11.12
19:25
Подниму ветку, т.к. хочу подвести небольшой итог:
Система с пустышками взлетела и радует малыми пакетами обмена данных и скоростью загрузки в ПБ.
Создавал базу таким образом:
1. Сделал центральную со всеми справочниками.
2. Перенес в нее документы, которые бегают по всем ПБ.
3. Создал распределенные, загрузил в них только те, которые якобы должны были там создастся.
4. Обменялся, провел все в центре, опять обменялся и профит.

Серьезно времени потерял из-за того, что таким образом взялся создавать всю базу с начала года, а это порядка 100тыс. документов на 25 базах. Убил время, контора в тетрадках пишет.
Пришлось свернуть базу на 1 октября и за одну ночь успел все перенести.
Если еще придется делать подобную работу, однозначно буду смотреть в сторону подмены ID в таблицах, а не копирования доков.
Еще раз обращаюсь к monitor, есть варианты приобрести компоненту ?

Надсмотрщик, спасибо за идею, готов проставиться !
293 Mikeware
 
10.11.12
10:51
(292) а мог бы сделать все гораздо быстрее, и не останавливая работу....
зы. 100 тыс документов - не так и много.
294 Andreyyy
 
10.11.12
16:07
(293) Наверно мог бы, если б опыта было больше в этой теме.
295 Надсмотрщик
 
12.11.12
19:41
(292) Можешь ему "проставиться" - OFF: Одинэсник сильно заболел. Нужны деньги на лечение если так "жаждешь"
296 temsa
 
12.11.12
21:38
Ветку все не читал.
А ни кто не предагал переходить на 1с82?
297 Andreyyy
 
13.11.12
08:36
(295) Готово !
(296) Дорого было бы писать заново, а типовая вряд ли устроила заказчика. +Лицензий вагон покупать.
298 Надсмотрщик
 
13.11.12
10:08
(297) Обращайся. Если что.
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство. Фредерик Брукс-младший