Використання типового механізму РИБ УПП.
Для клієнта основний мінус цього способу полягає в тому, що в базах на майданчиках міститься ВСЯ (практично) інформація центральної бази даних. Також повинна бути встановлена платформа 1С.
Плюси: легко розгорнути РИБ, можливість створення деревовидної структури РИБ, підтримка оновлень механізму РИБ в рамках типового поновлення УПП.
Використання власних правил обміну в типовому механізмі РИБ УПП.
Для клієнта особливих мінусів цього способу я не бачу.
Плюси: як і в першому способі + в базі містити усіх дані центру, а тільки необхідні на майданчику.
Якщо взяти правила обміну, розроблені для Інтера, за еталон, то їх невелике доопрацювання з нашого боку займе 1 день. Якщо ми ці правила будемо намагатися зробити в якомусь вигляді універсальними, то я бачу доопрацювання на пару тижнів.
Моя пропозиція - розробити типовий обмін для ломопереработкі на базі Інтер. Таким чином, це буде хитрість в стилі 1С - як би типовий обмін у нас є, але по факту кожного клієнта доведеться доопрацьовувати його під себе.
Використання термінальних підключень. Використання веб-клієнта.
Критичним стає стабільність мережі, тому що в разі її функціонування, робота майданчика практично встає.
Також знаю, що виникають проблеми з підключенням і використанням принтера для роздрукування документів (наприклад, актів зважування).
Щоб розгорнути і використовувати такий варіант доступу, необхідний грамотний фахівець (системний адміністратор).
При використанні веб-клієнта ми стикаємося з тими ж особливостями роботи, описаними вище для термінального підключення. Головна відмінність, що користувач підключається до бази через веб-браузер.
ГОЛОВНИЙ МІНУС ДЛЯ НАС:
Веб-клієнт взаємодіє з базою ТІЛЬКИ в режимі керованого застосування. Наш ЛОМ, на жаль, на даний момент абсолютно непрацездатний в цьому інтерфейсі! Доопрацювання цього інтерфейсу для ЛОМА може затягнутися на місяці, тому що фактично - це розробка нової конфігурації.
Для клієнта основний мінус цього способу полягає в тому, що при наявності великої кількості вузлів РИБ, навантаження на центральну базу зростає багаторазово! Обсяги скоєних транзакцій в день можуть бути колосальними, що навряд чи чи не позначиться на швидкодії системи.
Плюси: можна розгорнути РИБ без установки 1С, щадні вимоги до комп'ютерів на майданчиках.
Використання додаткової конфігурації до лому.
Як баз на майданчиках можна використовувати полегшену конфігурацію ЛОМА, в якій буде реалізований тільки самий необхідний функціонал для приймання і обліку брухту на майданчику.
Механізм обміну в даному випадку можна реалізувати двома способами:
1) Полегшений. Використовуємо типовий універсальний обмін даними між конфігураціями за розробленими правилами обміну. В цьому випадку ми не використовуємо сам механізм РИБ і плани обміну. Тобто конфігурація на майданчику не буде мати ознаки підпорядкованої і обмін між базами відбуватиметься завжди ПОВНИЙ (в даному випадку мається на увазі, що передаватися завжди будуть всі відібрані за правилами обміну об'єкти бази, а не тільки змінені). Такий обмін нічим не відрізняється від звичайного перенесення даних між конфігураціями.
2) Максимальний. В цьому випадку в конфігурації необхідно створення планів обміну, розробка підсистеми обміну і підключення РИБ.
ГОЛОВНІ МІНУСИ ДЛЯ НАС:
- розробка універсальної конфігурації з урахуванням основних загальних вимог клієнтів - це справа тривала. Оцінку дати вкрай складно. Якщо оцінювати тільки облікові і допоміжні підсистеми - то близько 2-3 місяців. Окремо створення підсистеми обміну - від 1 до 2 місяців. Розробка правил обміну - від 0,5 до 1 місяця (в залежності від того, необхідні будуть тільки правила обміну між центром і майданчиком, або ще й між самими майданчиками).
- підтримка і оновлення даної конфігурації, реалізація в ній особливих вимог конкретного клієнта - все це додаткова чимала навантаження на програмістів.
Для клієнта особливих мінусів цього способу я не бачу, крім як оновлення двох баз замість однієї.
Плюси: на майданчиках повністю окрема база і конфігурація.
(Спосіб 3): можна рекомендувати термінальне підключення для не надто віддалених від центру майданчиків з гарантовано надійним каналом зв'язку (можна організувати дублюючий канал), і якщо важлива оперативність отримання інформації про стан справ на цьому майданчику.
Так що думаю, спочатку варто схиляти клієнтів до першого варіанту, з використанням, при необхідності, третього.