Добрый день!

Посмотрите возможности "КИС Lack". Хотя, если Вы предполагаете БД на PostgreSQL , то возможно у Вас более 20 000 наименований и более сотни точек - она Вам не подойдёт. Имеет файл-серверную архитектуру, не предназначенную для таких объёмов информации. А по функционалу:

нужен единый партионный учет в сети.
-- здесь два решения. 1. На каждой точке стоит ПК и инфа консолидируется в одной БД; 2. В общую базу "сливаются" данные о продажах с бумажных носителей. Всё есть.

возможность в каждой точке отслеживать остаток и продажу товара каждого поставщика.
-- а так же скорость уходимости, рентабельность, анализ бартерных операций, контроль долгов
по "полной реализации", ABC/XYZ товаров поставщика...

работа со штрих-кодами EAN-13 (сканирование товаров в документы, печать этикеток на принтеры).
-- только определение при приходе, использование при продаже, аналитика в разрезе кодов и только USB & kbd сканеры.

возможность корректного учета комиссионного товара от поставщиков.
-- есть.

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

импорт-экспорт данных в другие системы.
-- только экспорт в 1С и авто передача документов между копиями системы.

свертка баз по отчетным периодам.
-- "обрезание" в терминах 1С? - есть.

поддержка (обновления печатных форм документов установленного образца и проч.)
-- оперативное отслеживание "базовых" форм документов.

возможность собственных доработок - ценообразование, отчетность и др.
-- большинство "настроек" на бизнес-процессы реализуются в рамках технологий программы, но средств перепрограммирования данных технологий НЕТ. Отчётность, если конечно Вам мало будет более 300 отчётов системы - любой "внешний" генератор отчётов, например Crystal Report. Ну и конечно возможны "дописки автора".

...Думается, лучшим будет готовое решение с минимальными доработками...Пока в рассмотрении вариант 1с 8.1
-- Если Ваши требования "столь обширны", то Вы оценивали стоимость доработки 1С? Чем она будет и в "какую сторону" отличаться от заказной самописки? Вы рассматривали её подсистемы консолидации инфы или перенос информации между БД?
-- Может быть (по 1С) разумнее узнать у реальных пользователей с аналогичной "торговой" архитектуров от возможных "граблях" благо на сайте "1С" если множество ссылок на "успешные" внедрения по тысячам различных предприятий.

с хранилищем на PostgreSQL.
-- Вам "доступны" специалисты по данной СУБД? Кроме этого посмотрите на форуме "сравнее СУБД" - по данной DBMS множество негативных отзывов по скорости и надёжности...

Система распространенная и дорабатываемая, но не хотелось бы зацикливаться на эСе.
-- С Вашими требованиями на 1С Вы получите УНИКАЛЬНУЮ самописку на 1С , т.е. у ней будет единственный клиент - это ВЫ. Со всеми перечисленными Вами "прелестями" заказных самописок.

например, не прельщает перепроведение большого количества документов при неизбежных коррекциях
-- 1. А знаете ли Вы, что 1С запрещает коррекцию данных "задним числом". 2. "КИС Lack" не "закрывает" период, а "запрешает" для отдельных пользователей коррекцию документов.

"тяжелая" типовая структура.
-- Маленькой совет! Почитайте сообщения "Сисой" и "Garya" на данном форуме - очень хорошо "снимают шоры", касаемые "1С".

По "КИС Lack" - она бесплатна с исходными кодами (скачать или оценить можете на её сайте), но в Вашем случае её потребуется немного дорабатывать,что понятно стоит денег.

У нас с год назад такая задача решалась. Покончили на внедрении xxxxxx на распределительных центрах, и небольшая самописка на розничных точках, которая общалась с xxxxxxx через всякие выгрузки

В принципе весьма разумное предложение :

1. Покупаете гибкую и мощную систему на центральный склад с серьёзной SQL.
2. Доделывете в неё модули:
- выгрузки межскладской передачи;
- импорт данных о продаже.
3. На торговые точки ставите недорогую программу, возможно даже 1С:ТиС (или самописку, например на SQLite), но в ней доделываете:
- загрузка межсклада, как прихода товаров;
- выгрузка данных о суточных продажах.

Но в принципе любопытно , какие виды товаров могут дать (в скорее всего небольшом магазине ) 50k наименований (ограничение ТС)? Прошу у форума реальный пример , просто в силу позиционирования моей системы и из практики (розница 800 кв.м. - 7000 позиций, книги&канцы 600 кв.м. - 5600 позиций, автозапчасти 450 кв.м. - 12000 позиций, аптека 100 кв.м. - 3800 позиций).

"Не льсти себе - подойди поближе!!!" - Это стандартная надпись около писсуара. Ведь просил дать РЕАЛЬНУЮ картину по ассортиментам, а не мечты. Не поверил и пришлось погуглить - дам несколько фактов:

1. "Ежегодно российские издатели выпускают около 80 тыс. наименований книг. Казалось бы, все это не может не радовать. По мнению аналитиков книжного рынка, основным каналом реализации книг является книжный магазин, средний ассортимент которого пока не превышает 10 000 наименований , а по статистике один книжный магазин приходится на 60–70 тыс. населения."
http://www.booknavigator.ru/index.php?page=itrec_13&id=2643

2. "Средний ассортимент аптек Волжская мануфактура превышает 5000 наименований"
http://ivsale.ru/shops/health/health_166.html

3. "ювелирные магазины традиционно занимают небольшую площадь (около 200 кв. м), средний ассортимент — примерно 700 наименований и четкое ценовое позиционирование"
http://www.magazinmagazinov.ru/news/detail.php?ID=8296

4. По игрушкам не нашёл чётких цифр, но ассортимент Internet магазинов от 10000 до 50 000 наименований, что превышает ассортимент РЕАЛЬНЫХ магазинов в 10-100 раз.

Повторю вопрос! Пожалуйста "без рекламной шелухи" подскажите направления торговли, имеющее более 50 тысяч наименований товара или оптово-розничную фирму, имеющую такой прайс.

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

В какой-то момент времени это понял сам, чем и вызвано мое "возмущение", но спасибо за "внешнее" уточнение!

В принципе знакомо "разбухание" баз 1С и если уважаемые спецы ассоциируют неоптимальное хранение информации с количеством ассортиментных позиций... Менял как-то 1С в "большом" магазине её объем БД за 2 года составлял 3Gb, следовательно в терминах номенклатуры 1С около 1000000 позиций-ХаХаХа!! У меня за два года работы этого магазина объем файловой системы составлял 300Mb и объем номенклатуры, разбитой на партии составлял 60 000 позиций или ассортимент, о котором спрашивал 10 000 наименований .

Уважаемый ТС нужно закладывать некий запас устойчивости, но не десятикратный.

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

Уважаемый Iscrafm! Извините - не понял данную Вами информацию?

Позвольте кратко описать "свою" архитектуру хранения "номенклатуры", м.б. тогда будет понятна терминалогия. Для примера количество записей по одному "крупному" магазину с 8 отделами, накопленные за 1 год работы (торгует, в т.ч. ювелиркой, игрушками, хозтоварами и продуктами):

1. Ассортимент - количество разноимённых товаров, в "моих" терминах "номенклатура" накопленная за год (20 103). Из него при построении отчётов извлекается инфа при сканировании справочников товаров и архива.

2.1. Оперативный справочник товаров, накапливаемый с разделением по партиям (13 858).
2.2. Архив партий товаров - используется при построении отчётов (17 394).

3. Справочник товаров складов - товар с оперативными остатками, как правило ненулевыми, содержащий инфу по остаткам, ценам отдела и т.д. Инфа автоматически и периодически пакуется (32 774).

4. Общий объем файловой системы (БД), содержащей данные по количественно-суммовому и бухгалтерскому учету магазина (таблицы + индексы) (132mb)

5. Всего "элементарных" операций приход, расход, списание, деньги, переоценки и т.д. (480 000)

прямые запросы (с группировкой и расчетом по десятку показателей) отрабатывают до 5-10 мин

Для примера построил:
1. Анализ продаж за год и прогноз продаж на следующие 3 месяца (44 сек.)
2. Произвёл ABC/XYZ анализ за год - (6 минут)
3. Остатки текущие по одному отделу (12 сек)

То есть в "моих" терминах за год через магазин прошло (13 858+17 394) "уникальных" партий?