[ОТВЕТИТЬ]
01.02.2008 16:46
creosote
 
После рабочего понедельника решил поднять бэкап за субботу. В результате в магазинных базах оказались карточки(созданные в понедельник) которых небыло в центральной базе(база за субботу). При создании в центральной базе новых карточек, их номера совпали с теми карточками, что есть в базе магазина, при этом карточки разные.
Подскажите, как правильно выбраться из этой ситуации?
01.02.2008 16:56
Mtirt
 
Еще раз, для меня, непонятливой:
у тебя в ЦО, например, 1012 - Сок яблочный, 1013 - Водка финляндия
А в магазине 1013 - Водка Финляндия, 1012 - Сок яблочный.
Я правильно поняла?
02.02.2008 04:47
akonev
 
эк вас угораздило-то...

самый первый и основной вопрос: почтовик после этого работал?
если "да" и он уже прослал документы из магазина в офис и/или карточки из офиса в магазин - это вы попали. концов уже не найти и надо тупо перебивать все руками.

сколько карточек пересеклось по номерам? и как много документов, их содержащих (в офисе и магазинах по отдельности).
порядок инересует. типа, 10-20 или 300-400?
если мало - возможно проще окажется перебить карточки в офисе по данным маговских баз.

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

еще вариант, если магазинов не слишком много: для пересекшихся номеров в подчиненных базах прибить глобальные артикулы и базу-отправителя; базу создателя поправить на локальную.
Дальше по стандартной процедуре синхронизации.
Но если магазинов много - замучаетесь синхронизировать.

PS. тема пока нифига не оракловая. надо было в см2000 ее.
03.02.2008 18:17
creosote
 
Цитата:
Mtirt Еще раз, для меня, непонятливой:
у тебя в ЦО, например, 1012 - Сок яблочный, 1013 - Водка финляндия
А в магазине 1013 - Водка Финляндия, 1012 - Сок яблочный.
Я правильно поняла?
В понедельник завели 1012 - Сок яблочный, карточка ушла в магазин. Во вторник поднимается база за субботу, заводится карточка 1012 - Водка Финляндия(номер карточки был выбран автоматически), карточка ушла в магазин, совпала с 1012 - Сок яблочный в магазинах и не записалась в магазинную базу.
03.02.2008 21:49
akonev
 
Цитата:
creosote В понедельник завели 1012 - Сок яблочный, карточка ушла в магазин. Во вторник поднимается база за субботу, заводится карточка 1012 - Водка Финляндия(номер карточки был выбран автоматически), карточка ушла в магазин, совпала с 1012 - Сок яблочный в магазинах и не записалась в магазинную базу.
Вот это место самое мутное. Могли ведь не совпасть некоторые и приняться: опечатка или ошибка формирования наименования или совсем новый, которого в маге еще не было...
Если принялись - подменили наименования товаров в маговских документах.
Надо перепроверять все подозрительные артикулы по журналу приема или журналу изменений. Если изменения подтвердятся - сверять по первичке, что там раньше было на самом деле под этими артикулами.
04.02.2008 03:42
isi
 
рекомендую прилинковать сервер магазина (для начала одного) и выбрать не совпадающие например по наименованиям карточки, дальше можно оценить масштабы проблемы, можно сделать так например:

create database link "DBAMIK07"
connect to supermag
identified by "пароль"
using 'DBAMIK07';

select article, name from smcard
minus
select article, name from smcard@DBAMIK07

Потом посмотреть документы (плохо если продажи пройдут) с этими артикулами, ну а дальше уже все вроде было сказано
04.02.2008 09:32
creosote
 
В магазинных базах, на основе несоответствующих центральной базе артикулов, уже созданы приходные накладные. Можно ли использовать инструмент
Синхронизация – замена всех локальных артикулов в подчиненных базах данных на соответствующие глобальные артикулы. При этом локальные артикулы блокируются, но оста-ются в ТС;
К чему это приведёт?
04.02.2008 09:35
Dim
 
Сталкивались с этим... по совету Олега объявили базу ЦС как подчиненную базу магазину и разослали из магазина все отсутствующие в базе ЦС карточки, потом вертанули подчиненность назад и разослали из магазина документы.
04.02.2008 09:37
Mtirt
 
Цитата:
creosote В магазинных базах, на основе несоответствующих центральной базе артикулов, уже созданы приходные накладные. Можно ли использовать инструмент
Синхронизация – замена всех локальных артикулов в подчиненных базах данных на соответствующие глобальные артикулы. При этом локальные артикулы блокируются, но оста-ются в ТС;
К чему это приведёт?
Их у тебя Супермаг не посчитает локальными, они хоть и другие. но созданы в ЦО.

Конев выше правильный путь написал.
04.02.2008 09:48
akonev
 
это приведет к тому, что появятся "двойные карточки". локальный будет служить ссылкой на глобальный артикул. все и везде обрабатываться и считаться будет правильно.

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

есть небольшая сложность: эти ошибочные карточки в магазинной базе считаются глобальными. чтобы заработала синхронизация, их надо сделать локальными: базу отправки выставить в null, базу создания поправить на локальную, штрихкода пересадить в другую таблицу.
04.02.2008 10:47
creosote
 
Цитата:
Andrew_Konev чтобы заработала синхронизация, их надо сделать локальными: базу отправки выставить в null, базу создания поправить на локальную, штрихкода пересадить в другую таблицу.
Вот тут поподробнее, пожалуйста. Это всё надо делать средствами sql? С помощью супермага сделать не получится? Если не сложно, покажите пример команд sql для карточки в магазине.

Решение через почтовый модуль считаю в моём случае неприменимым, т.к. к 30% магазинов удалённо подключиться нет возможности.
04.02.2008 10:52
Dim
 
Цитата:
creosote Решение через почтовый модуль считаю в моём случае неприменимым, т.к. к 30% магазинов удалённо подключиться нет возможности.
Достаточно подключиться к одному магазину.
04.02.2008 11:03
creosote
 
Цитата:
Andrew_Konev эк вас угораздило-то...

сколько карточек пересеклось по номерам? и как много документов, их содержащих (в офисе и магазинах по отдельности).
порядок инересует. типа, 10-20 или 300-400?
если мало - возможно проще окажется перебить карточки в офисе по данным маговских баз.
Приблизительно 200.

Цитата:
Andrew_Konev где заводятся документы? то есть имеются ли документы, созданные в офисе после отката базы, в которые попали проблемные карточки.
если все документы рождаются в магазинах и надо только привести в порядок карточки в офисе - можно попробовать поменять роли баз в почтовиках и прослать карточки снизу вверх.
или не связываться с почтовиком, а организовать экспорт/импорт карточек.
или, опять же, перебить руками.
Да, в офисе уже появилась куча документов (Акты переоценки, Контракты), содержащих эти карточки.

Цитата:
Andrew_Konev еще вариант, если магазинов не слишком много: для пересекшихся номеров в подчиненных базах прибить глобальные артикулы и базу-отправителя; базу создателя поправить на локальную.
Дальше по стандартной процедуре синхронизации.
Но если магазинов много - замучаетесь синхронизировать.
Магазинов около 50-ти, но пока, мне кажется, способ с синхронизацией наиболее приемлимый.
04.02.2008 11:43
akonev
 
Цитата:
creosote Вот тут поподробнее, пожалуйста. Это всё надо делать средствами sql? С помощью супермага сделать не получится? Если не сложно, покажите пример команд sql для карточки в магазине.

Решение через почтовый модуль считаю в моём случае неприменимым, т.к. к 30% магазинов удалённо подключиться нет возможности.
супермагом не получится.
запросы примерно такие (все для одной карточки с артикулом "0"):
Код:
update smcard t set t.arrivedfrom=null, t.bornin=(select paramvalue from sssyinfo where paramname='DBID') where t.article='0'
insert into smforeignunits (select * from smstoreunits where article='0')
delete from smstoreunits where article='0'
запросы не проверял, но общая идея такая.
надо еще версию СМ уточнить: недавно менялось место хранения штрихкодов для локальных артикулов

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

реально, проще заниматься правкой одной офисной базы.
04.02.2008 12:05
creosote
 
Цитата:
Andrew_Konev реально, проще заниматься правкой одной офисной базы.
Что необходимо сделать в центральной базе, расскажите пожалуйста подробннее? Что будет с документам, созданными в центральном офисе(акты переоценки, контракты), содержищими ошибочные артикулы?

Сейчас при попытке отправить в магазин карточку с артикулом 1199353(созданная в центре карточка с номером существующей в магазине карточки) выходит ошибка:
ORA-20102: Попытка изменения фиксированных атрибутов карточки товара
ORA-06512: на "SUPERMAG.CORE", line 262
ORA-06512: на "SUPERMAG.SMCARDFIXATTR", line 21
ORA-04088: ошибка во время выполнения триггера 'SUPERMAG.SMCARDFIXATTR'

Смогут ли изменённые в центре карточки перезаписать карточки в маг. базах?
04.02.2008 12:57
Mtirt
 
Давай еще раз.

Меняем подчиненность баз. ЦО делаем подчиненным.

В ЦО:
1. Копируем эту карточку (да, еще раз).
2. Скриптом перекидываем движения документов, созданных в базе ЦО на новую карточку (update smspec set article='Новый артикул' where article='Старый артикул'). Надо поменять и остальные таблицы, которые содержат артикула.
3. Удаляем карточку в ЦО. (Совсем, с концами, со штрих-кодами и историей).

4. Рассылаем из магазина артикула и документы. Проверяем, что всё дошло.

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

6. Возвращаем назад настройки почтовика. ЦО делаем старшим, Магазин - подчиненным.

По идее, должно работать. Проверять работоспособность данного способа лично мне не хочется...
Ну и естественно, желательно всё это проделывать, когда в ЦО никого нет.
04.02.2008 13:13
akonev
 
фиксированные атрибуты - это такие данные, как тип артикула, единица измерения...
если этот артикул не принимается - скорее всего "старый" штучный, а "новый" - весовой. или наоборот.
если они будут одинаковые - все нормально примется.

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

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

или проверяйте каждый из проблеммных артикулов на предмет: смог он прослаться в магазины или его отпнули по ошибке. выпнуть из магазина его могли по двум причинам: те самые фиксированные аттрибуты или совпадение наименования с уже существующим артикулом.
06.02.2008 10:11
creosote
 
Спасибо всем за внимание, очень помогли!
Опции темы


Часовой пояс GMT +3, время: 20:51.

 

Форум сделан на основе vBulletin®
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.