Написать программу для выявления неправильной выручки : Программирование

сорри, я просто как пример привел, чем занимался в ту минуту. Винты на моем компе что-то забарахлили, а эти команды выводят их статус по S.M.A.R.T. К кассам это имеет самое отдаленное отношение.

спасибо все нашол сам..можно не отвечать извиняюсь за офф-топ

Да тут дело в элементарном нежелании админа в магазине формировать отчёт "реестр Z-отчётов" или "журнал продаж" и сравнить их с бумажным носителем.... Вот и вся проблема....

Много раз объяснял администраторам в магазинах... снисите X-отчёт перед закрытием смены, посчитайте деньги в кассе... сходится - хорошо, не сходится - тут уж извините, звоните в ЦТО или сисадминам....

Это в конце концов их недостача.... они в магазине материально ответственные....

З.Ы. Это конечно сугубо моё личное мнение....
З.З.Ы. И проблемы с кассами начинаются в некоторых случаях из-за самих кассиров... захотели они схимичить... чек не пробили, кассу перезагрузили, вот вам и глюк... замечал я за ними такое и неоднократно. И ЦТОшники поэтому акты отказываются писать, т.к. неизвестно, из-за сбоя ли в кассе такое расхождение появилось или премудрый кассир денежки прикарманил... (извините за тон, просто накипело...)

А слились кассы или не слились.... тоже достаточно просто выявляется стандартными средствами Супермага... зачем изобретать велосипед??? Книга продаж за день... у тебя в магазине три кассы, в супермаге две... одна не слилась... простая математика ;)

Гораздо интересние иметь утилиту ктороая анализировала бы расхождения...

например:
1. имеется выгрузка с кассы.
2. Имеется бумажный З отчет.
3. Запускаем утилиту...

Внимание: расхождение на 231.21 руб.
Уведомляю по электронной почте...
Имеются два чека №125 и 256 дающие данную сумму....
Исправть? нажмите да\нет...

Если "да" то в ДБшных файлах удаляются эти чеки и правятся другие таблички... а уж потом заливаем в супермаг...

Работать будет не во всех случаях.. но все же...

Выше я уже писал, что есть простые вещи, которые не хочется делать, поскольку есть возможность автоматизировать :) Сравнивать хотел более детально, но стало влом связываться с этим парадоксом, есть дела поинтереснее.

Вот это уже опасно. Она может найти вовсе не то, что нужно. Да и опираться при написании таких утилит надо на фискальные показатели, а их не достать, ну и ладно...

Вернусь к Ораклу, почему нельзя брать данные из него, т.е. те данные которые уже слились в супермаг. Т.е. просчитать сколько передано выручки в СУПЕРМАГ, и сравнить с тем что насчитал управляющий по чекам, если расхождение...то к примееру сообщить админам.
Т.е. тут идеальная ситуация рассматриваеться, выручка сходиться с суммой по чекам, но расходиться с тем что выгружено в супермаг....вот на этом этапе и надо сообщить сисадминам...поставить вопрос.

Тебе два человека задают вопрос: а что мешает взять реестр Z-отчетов и проверить? А если не сообщили до 10 часов утра, то наказать упарвляющего?
Зачем писать софт, который давно написан?
Чисто программные методы не избавляют от беспорядка. Если у тебя сейчас люди не исполняют своих обязанностей, то они их не будут исполнять и при наличии "суперпрограмм".

1) Чтобы научиться писать :)
2) Чтобы на простом примере убедиться, что не все решаеют программы

Можно! Только никому не хочется писать, потому что нерационально.
Если тебе лично хочется, но про что-то не понимаешь как - задавай конкретные вопросы.
Если будешь спрашивать: "вот я купил диск с MVC, чего дальше делать?" - никто не ответит.
Если "я подключился по ODBC к своей базе, в какой таблице Z-ы искать?" - ответят.

Полный автомат мне лично тоже был бы симпатичен, но путей реализации не вижу.
Проблема 1: надо сверять фискалку, базу укм, базу см2000; бог с ним, что все в разных местах живет... фискалки все разные. придется модуль для работы с фискалкой в нескольких вариантах писать. мало радости.
Проблема 2: как реагировать, если касса вообще не включалась в какой-то день? считать, что с ней связи не было и поднимать тревогу? всех быстро забодает.