Совместная разработка : УКМ-4

Есть чувство, что часто в ИТ подразделениях сетей и даже отдельных магазинов достаточно квалифицированных людей могущих программировать. То есть пока вся концепция продукта заключалась в том, чтобы состыковаться с конкретной системой. Фактически официальных открытых интерфейсов для подключения своего кода нет. Возник вопрос, а есть ли желающие? Могу предложить напрашивающиеся интерфейсы взаимодействия.

На уровне выноса части кода в виде исходников - поддержка оборудования, в первую очередь регистраторов (C++). написание процедур импорта экспорта (C++)

На уровне Web-service - создание произвольных скидок, видов оплат.

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

Поясню, есть возможность сделать что-то вроде плагинов к самому серверу УКМ, кассам и вебу. Прежде чем реализовать эту возможность, хочется узнать, будет ли ей кто-то пользоваться. Отпишитесь или не поленитесь хотя бы ткнуть в голосование, пожалуйста.

Скорее всего это будет востребовано. Только вот вряд ли я сама что-нибудь хорошего сотворю. С С++ у меня плохо...

Кому-то понадобится обмен по модему, кто-то сделает для себя минимальный бэк, кто-то прикрутит интерфейс для бонусных карт для клиентов. Да мало ли что ещё может понвдобиться...

хочется понять, есть ли среди посетителей те, кому это нужно. Или есть готовые наработки, которые хоччется подключить к УКМ. То есть по теории вероятности очевидно, что в мире есть люди которым это нужно, вопрос как их найти и пользуются ли они УКМ4 :)

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

А не будет ли проблем при обновлении версий?

Из последних пожеланий руководства по доработке УКМ:
1. Требуется запрет продажи кассиром для неавторизованных лиц. Т.е. можно продавать только лицам обладающим дисконтной картой. Проект ушел на 1с.
2. Управление форматом, шадулером конвертера. В частности интересовало изменение формата файлов выгрузки, и частоты выгрузок. Т.е. если будет возможность создания собственного конвертера, то процесс заточки УКМ к бекофису ускорится. Создано сторонними средствами.
3. Изменение системы авторизации внутреннего персонала на кассах. В частности интересует внедрение биометрических датчиков. Карточки, штрихкода, ключи не интересны. Вопрос не решен.
4. Отбрасывание копеек в виде скидки при продаже. Решено С+. В январе 2007 этот вопрос возник, в августе-сентябре появилось решение. Но все равно спасибо С+.

Была бы система плагинов с возможностью доработки функционала, было бы намного проще. Вопрос глючности конечно важен, но никогда не глючит то чего нет.

Если разработчик что-то напутает, то произойдёт путаница :) Защититься от разработчика никак невозможно, поэтому за такую фишку как API в программе от отдела сопровождения мы скорее всего получим *97.

Если мы выпустим некий API то будем стараться его не трогать, иначе в этом нет никакого смысла. Но я имел ввиду не только внешний по отношению к УКМ код, я так же имел ввиду и просто участие в написании кода. То есть, например, сторонним разработчиком пишется базовая работа с ФР, а мы в дальнейшем её поддерживаем и распространяем.

А почему доработку не заказали? Сделали бы, я думаю.

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

Датчик + документация + тестовые пальцы и напишем. Пока не стоит вопрос о том, чтобы вообще изменять логику программы. Это возможно, но представляется трудным в поддержке.

Это не так просто обеспечить устойчивать программы, если она работает с внешним кодом, поэтому выходить на уровень плагинов пока не рискнём, если только в очень узких местах.