|
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) Обращайся. Если что.
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |