Есть сетевой ритейл, торгующий товарами с серийными номерами, конфа Розница, РИБ.
На точки выдается весь справочник серийных номеров, т.к. может быть возврат по прошлым продажам в течении 1-2 лет (гарантийный срок).
Как можно минимизировать объем серийных номеров, выгружаемый на точки, ибо сейчас их 1 000 000?

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

Есть какие-нибудь идеи, как реализовать это в РИБ?

http://wstaw.org/m/2013/04/10/0.png

все по риб нормально грузится.

если не хочешь РИБ - сделай централизованную проверку по веб сервису

(2) Это же Гений. Ему все нужно сделать через универсальный интерфейс.

(2) объемы! База филиала пухнет
(3) при возврате серийник должен быть в базе... как-то так...

(0) Хочешь совет "падавана"?   ;-))

+ (6) Как я внедрял у себя?

(5) что там пухнет-то? тебе пары сотен метров жалко?

>объемы! База филиала пухнет

на елку залезть и не ободраться...

>если не хочешь РИБ - сделай централизованную проверку по веб сервису

чем плохо если связь нормальная

(8) люди в файловой сидят... еще поди встроенным клиентом пользуются - база забита разным мусором в блобах

(5) подгружать серийник только при необходимости (том самом возврате), не?

(5) сделай веб сервис, который проверяет и подгружает в случае чего

(3) (12) а про подгрузку через веб-сервис есть что почитать?

(5) Клюшечный вариант!

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

(13) на ИТС есть демо конфа

(15) нашел, благодарю!

(11) серийники еще и при продажах юзаются.

(12) а если интернет не доступен

(18) Ты (14) читал?

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

+ (20) И посадить на переферийках отдельных юзверей + начальников над этими юзверями + итд....

(19) и чем мне (14) поможет?
(20) ненужное усложнение

(22) По этому принципу я делал учет серийников на Бухии 7.7 на 90 перефериек

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

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

>а если интернет не доступен

сделать "план Б" xml файлик с запросом на нужные номера, в ответ такой же с серийниками... загружать хоть с флешки

+ (23) Все серийники были только на ЦБ

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

т.е. в первоначальный образ все равно все будет перегружаться?

(25) на флешку постоянно обновлять? нет. мне мой план в (24) больше симпатичен

(27) ну регламентное проще написать, чем ковырять выгрузку. А образ генерируется в центре, все под рукой. Почему бы и нет.

а еще ремонты бывают негарантийные...

(28) а кто придет и ткнет в "реструктуризацию таблиц"? или они в 8-ке сами сжимаются?

(30) нет, тут исключено...
(31) начальный образ можно реструктуризироваться. К тому же на каждом компе сделан ярлык на chdbfl, а он тоже сжимает базу.

размер базы на точке какой, если там данные за пару лет

(33) 5 Гб, файловая

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

сколько выигрывается при удалении серийников?

(36) см. (8)

(35) для поиска по индексу не особо в разницу 1млн или 100

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

(35) а с индексами чего там? хотя база файловая...

(38) а индекс по наименованию вроде бы не делается, так? предлагаешь дублировать наименование в индексируемый реквизит?

(39) негарантийных не будет. нету таких

(41) индекс по наименованию всегда есть. или вы наименование через поиск в верхнем окошке делаете?

(43) гм. все равно поиск по наименованию длится довольно долго среди 1 000 000 серийников. По крайней мере, на файловой.

(44) ищи по 2-м полям - номенклатура+СН, в таблице РС это должны быть 1 и 2 измерением

(45) ты о чем? когда я на входе имею штрихкод, я не знаю, к какой номенклатуре он относится.

(46) а ты узнай. у нас сканируется сначала еан, потом сн

(47) а смысл, если можно сразу СН

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

(49) Только разработчики розницы забыли это включить в типовой функционал, ага.

Не верю, что миллион серийников могут что-то там тормозить. В консоли поиск за сколько выполняется?

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