Альтернативный прайсчекер. : Другие вопросы

сп форт. сам один фиг не напишу, но если поискать готовые решения, то можно что-нить сляпать. сейчас работаю над формой. есть проблемы с буфером ком-порта, но, думается мне, решаемые. ты лучше пока приведи пример как получить по ШК, помимо артикула, ещё короткое название товара, цену и сколько его осталось на оперативных остатках. Всё отдельными запросами, по аналогии с первым. Желательно, не привязываться к остаткам вообще, т.е. если даже товара нет на остатках, то один фиг информация по нему должна отображаться, раз он в магазине нашёлся.

сделаю чуть позже. ты только скажи, как ты их пользовать собираешься. просто вызывать плскл и ему скармливать? или куды ты их вставишь? я к тому, что могу "обвязку" сделать из TEXT_IO, к прмеру. чтобы в файлы пробелы не падали и строчки лишние.

напрямую в сп форт я ответ на запрос никак не запихаю. следовательно, нужно использовать какие-то промежуточные варианты. Если сможешь, запихай их в буфер обмена, оттуда я смогу данные достать. Второй вариант - текстовый файлик, но желательно без пробелов и без символов перевода строки. Можно, конечно, запихать все данные в один файл и добавить между ними разделители, но в этом случае, опятьже, придётся писать функции-дробилки. Поэтому пусть лучше 5 разных запросов пишут данные в 5 разных текстовых файликов.

Народ, чего вы страдаете? Нарисуйте внешний вид и утвердите ТЗ - я вам это сделаю максимум за неделю.

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

Пробовал я "рисовать" на VB, не понравилось. Не хочу сейчас затрагивать тему предпочтений в языках программирования, т.к. я не программист.
Техническое задание на альтернативный прайсчекер неплохо описал konst. Мне добавить нечего.
Нарисовать не проблема, вопрос в другом. Кто будет заниматься отладкой кода на протяжении всего периода тестирования? Это ведь работа, на которую нужно выделить немало времени. Тем более, за бесплатно. Если есть такие, то давайте обсуждать ТЗ. А я, паралельно, допишу на коленке свой вариант

вот об этом и речь...
если реально начать делать альтернативный ПЧ то необходимо:
1. определить круг заинтересованных лиц....
2. довести до ума и согласовать ТЗ
3. написать программу
4. потестить, доработать и начать эксплуатировать....
сразу о себе - я не дизайнер, поэтому внешний вид ПО - больная тема...
у меня куча старого оборудования, которое можно использовать...
но к сожалению это (конкретно ПЧ) никому не нужно в моей компании
поэтому когда я писал ТЗ - постарался описать те функции которые, по моему мнению, не сложно реализовать, и они реально помогут сотрудникам в магазинах...
теперь самое заинтересованное лицо в тестировании как мне кажется - Vovantus
я тоже готов потестить, благо как я говорил железо и идеи есть... только мало времени - но мне это интересно...
непосредственно с программированием может помочь - YuraZ
... ну что, понеслись?

Обращаю внимание, что ты опубликовал не ТЗ, а список "хотелок". Это никак не ТЗ. К тому же, понятно, что такой расширенный функционал так быстро реализовать не удастся. Начинать следует с того минимума, который отвечает в чистом виде за ПЧ. А уж дальше наращивать функционал. Далее. При формировании внешеного вида программы необходимо учитывать, что практически все выводимые поля могут быть отключены. При этом внешний вид должен оставаться "читабелным". Т.е. отключение какого-либо поля для отображения не должно вносить дисбаланс в общую картину. Начать следует именно с этого. Как будет устроено ПО внутри не столь важно, т.к. здесь важен именно внешний вид и удобство пользования. Сделайте это, а внутренний механизм за мной.
Потом, никто не обратил внимания на пост Andrew_Konev, ктоторый был очень прав на счет синхронизации цен с кассой. Именно из-за этого, модуль ПЧ в Супермаге заводится как отдельная касса. Это необходимо для "одинакововсти" цен на кассе и ПЧ. Этот момент тоже необходимо обдумать.
Короче, я считаю, что необходимо сначала написать ТЗ на:
1. Внешний вид (с учетом его "настраиваемости")
2. Базовый функционал (в том числе и откуда брать цены)
Тестирование базового функционала, лично мне, кажется задачей несложной. Для этого нет необходимости "останавливать" магазин. Он либо работает - либо нет.

Сразу оговорюсь, что если это все необходимо только одному человеку, то браться за это не имеет никакого смысла. Если не будет РЕАЛЬНО заинтересованных в этом людей, то я даже браться за это не буду.

Дело не в том, кому это необходимо. Дело в том, что фактически, ты делаешь это для себя. Тебе не заплатят за работу, максимум, скажут спасибо. И не важно, сколько человек будет потом пользоваться твоей программой. Вот в чём весь прикол. Поэтому я и не стал заморачиваться с глобальным проектом. Лично мне нужна простая форма, с несколькими информационными полями, в которых будут отображаться определённые данные при считывании ШК. Форму я нарисовал выше. Все настройки можно вынести в конфигурационный файл. Там же, через соответствующие параметры, можно будет добавлять/убирать некоторые поля, хотя, по большому счёту и это тоже не требуется. Нужно просто жёстко зафиксировать их количество и всё. Главное, на мой взгляд - программа должна работать без сбоев и тормазов.
Что касается синхронизации цен с кассой.. Тут нужно думать. Конечно, цену правильнее брать из выгрузок для кассы. Там же можно найти артикул и название товара. Но оперативные остатки, один фиг, придётся брать из базы. Поэтому я предлагаю, на начальном этапе, не заморачиваться этим вопросом и брать все данные из базы. В последствии, если понадобится, можно дописать функционал и брать данные частично из базы, частично из выгрузок.