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