2 Menahem

Есть решение от компании Landsteinar называется DataDirector

http://www.LSRetail.com

Позволяет настраивать репликацию м\д различными источниками данных типа:

Аксапта - Аксапта
Аксапта - POS
Аксапта - База данных (например, филиала)

Решение забугорное, достаточно распространенное
Партнеры в России http://partners.lsretail.com/displayer.asp?cat_id=62

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

Абстрактно говорить о том, что репликации нет, считаю нецелесообразно.



Posted via ActualForum NNTP Server 1.3

2 "mazzy"


Спокойствие и еще раз спокойствие... Все высказанное ниже, является моим
мнением замечания по существу приветствуются.



Ну почему компания обязательно торговая, а если и торговая то почему всего
три точки?



А я считаю, что точек 200 шт. и при описанном БП, опишите мне, пожалуйста,
как все это будет работать даже с учетом одной общей базы.



В предложенном варианте есть 2 выхода - механизм авизо и распределение
товара через распределительный центр.



т.е. для первого случая



1. авизо на товар

2. подтверждение авизо

3. 79-10

10-79

4. гасим авизо



для второго случая заранее известно, что в соответствии с бюджетом запасов и
приоритетности филиалов товар уходит в соотношении 3- А на 2 на Б. Далее
вопрос с остатком по авизо... уничтожаем или ждем пока придет товар...



Что хотел сказать, утверждать что репликации в аксапте нет, крайне не
осматрительно.






Posted via ActualForum NNTP Server 1.3

2 "mazzy"

>>Покажите :)
>>Я видел только два варианта репликации.
>>Оба чертовски дороги, оба чертовски сложны в сопровождении.
>>Это и позволяет говорить о том, что репликация отсутствует,

>>присутствует агрегация и консолидация.

Начну с конца =))



В самом начале я написал что: Если мы будем передавать
консолидированные данные по счетам учета...



Я не говорю что нам необходимо передавать каждую проводку каст, леджер и
прочее -транс.


>>Я же написал - для простоты.
>>Напишите как это делается для трех точек.
>>Можно будет обобщать и для 200.
>>Если не будет решения для трех точек, то не будет решения и для 200 :)

Простите, но теоретическими изысканиями я не занимаюсь. Есть реальная задача
и точек более 200 шт.



>>ВСЕ? ЭТО? Это - что?



Ну как при наличии 200 точек вы будите распределять товар? на основании
какого принципа? Кто первый пришел того и тапки?

>>Описанный мной случай? Просто.
>>Кто-то из них начинает транзакцию,

>>блокирует базу, уменьшает остаток, коммитит транзакцию.
>>Затем к работе приступает следующий.

Хорошо.



Точка 1. Авизо1. Товар 1 - 5шт. Дата1

Точка 2. Авизо2. Товар 1 - 3шт. Дата2





ttnB

Центр. Авизо 1 принята.

Центр. Товар 1 зарезервирован. 5 шт. осталось 2

Центр. Авизо 1 подтверждена.

ttE



ttB

Центр. Авизо 2 принята.

Центр Товар 2 зарезервирован. 3 шт. (физ. резерв.2 зарезерв. заказ. 1)
осталось 0

Центр. Авизо 2 подтверждена. на 2 шт.

ttE





Центр. Авизо 1. отгрузка.

Центр. Авизо 2. отгрузка.



Точка 1. Авизо1. приемка

Точка 1. Авизо2. приемка



Подробнее расписывать не буду.





>>Вас волнует как работает механизм транзакция для 200 пользователей? :)


Нет меня волнует, как будет распределены 5 шт. товара на 200 точек.


>>Отлично. Кто в какой последовательности и что делает.
>>кто получает отказ, кто продает. Как и когда получает отказ...

см. выше

>>:)
>>Ню-ню. Кто решает? В? Какой алгоритм и в какой момент?

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


>>Вспоминается анекдот:
>>Приходят ежики к филину...

Де жа вю...


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




Posted via ActualForum NNTP Server 1.3

2 "Валентин К"
>>Вот только этого маленьго чуда нет, которое эти пакеты обработает.

Да есть такое чудо, живет потихоньку у меня на буке... умеет в аксапту и
навижн втраиватся... правда ограничено...

The Data Director is a general purpose application to move data between
databases in a fast and efficient way. It is closely tied to the Microsoft
Navision platform, and most of the configuration is still made in Microsoft
Navision.

It is a flexible tool that can be adapted to a variety of data transfer
scenarios. The most commonly used configurations are for:

a.. Moving data between head-office, stores and point-of-sale Terminals
(POS Terminals) in a Microsoft Navision based retail organization.

b.. Moving data from Microsoft Navision based database into a data
warehouse based on either Oracle or Microsoft SQL Server.


Posted via ActualForum NNTP Server 1.3

2 "mazzy"



>>Возвращаю вопрос вам: А как делается в централизованной базе?



точно также как и в децентрализованной.


>>Замечательно.
>>И как вы думаете, этот алгоритм сильно отличается

>>от алгоритма для централизованной базы?

..Нет

>>Так вот. Если делать репликацию, то мы

>>должны изменить простой транзакционный

>>(уже существующий) механизм на механизм

>>многоуровневой фиксации (пусть это называется

>>Авизо :) ). Если вы ничего страшного в этом не

>>видите... Как скажете...

На сколько я понимаю, вопрос отсутствует, а это реплика вслух... а вам
кошмары снятся при упоминании 79 счета?


>>Если же вы говорите про "консолидированные данные".

>>То консолидированные - это совсем не то же самое, что

>>и репликация. Не стоит смешивать эти два понятия в голове.

Консолидация процесс направленный на агрегацию данных.

Репликация - синхронизация данных. Думаю, что буду прав, если допущу, что
реплицированные данные на стороне получателя или отправителя могут быть
подвержены консолидации... то есть вместо десятка проводок 10 - 60, мы
получим одну 10-60, при условии что взаиморасчеты с поставщиком в филиале
нас не волнуют... Как назвать такой процесс? Репликация? Консолидация?



>>никакой актуальности информации :(( ...



Слишком громкое утверждение, юношеский максимализм...



>>Т.е. реально нельзя зарезервировать товар

>>на удаленном складе в точке В (чтобы в это

>>время никто не отпустил товар с самого склада,

>>считая его свободным).



Можно.


>>В точке А, где заказали товар, узнают о том, что

>>им точно его привезут только через 2 репликации -

>>пока эту авизовку обработуют на В и когда

>>подтверждение вернется в точку А.

Да это так. 2 сеанса связи...


>>По-моему, значительно меньше рисков с терминалом :) ...

>>или просто позвонить по телефону?



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



Уважаемый mazzy, по моему мы говорим о разных весчах, вы говорите что
репликация это сложно и дорого и не хотите услышать мысль что все
реплицировать и не надо... просто не за чем... Необходима организация
передачи ограниченного объема информации. Вы же говорите... нет...
невозможно... дорого... обоснуйте... распишите... По моему я не сказал ни
чего, что бы как то опровергло ваши слова, я добавил ограничений и показал
что при их наличии аксапта с репликацией может справится.




Posted via ActualForum NNTP Server 1.3