Появилась задача - написание программы для приема ПРОЧИХ платежей от населения.
Прошлую программу по приему КОММУНАЛЬНЫХ платежей писал на делфи в связке с MSSQL, так как прием осуществлялся только в одном городе и все отделения могли быстро обращаться к серверу. Но прием ПРОЧИХ платежей может осуществляться и в отделения находящихся в других городах не имеющих скоростной связи с нашим сервером. По этому задача такова:

Создать оффлайн программу по приему платежей и только в конце рабочего дня файлы с проводками должны вываливаться на расшаренную папку (или отправляться по почте) чтобы сервер мог их втянуть. В принципе в данном случае как таковая онлайность и не нужна.

Подскажите как реализовать всё это? Писать буду на делфи... с помощью чего создавать базу? думаю в Access так как там достаточно развит язык SQL, что будет удобно для работы через ADO. Или есть другие варианты? Как я себе представляю при работе с просто DBFниками будет нулевое удобство...

Люди добрые, направьте на путь истинный..

Использоваться будет порядком 15 справочников при работе программы.

я вот тоже подумываю насчет MSDE, но никогда с ним не сталкивался. Насколько она повторяет MSSQL? Реально ли там админить через Enterprise Manager, и использовать Query Analizer?

Серж
Вот зачем городить зоопарк? Раз уже МС СКЛ работает, то и делай все остальное тоже под него. И SQL и ADO там разветее на порядок выше, чем в Access'е.


Дело в том что в других городах связь бывает не стабильной, иногда может отваливаться, и как бы смысла в постоянном общении с общим сервером нету. А как насчет MSDE? Настолько же он удобен как MSSQL?

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

Vladimir M SklyarГде-то видел в одном из городов схему приема платежей (вообщем их очень много этих схем и зависят они от разных условий).

Есть центральная БД (расчетный центр) и отделения по приему платежей от населения по городу.
Связано все это дело выделенными каналами (адлс, радио и т.д. - неважно)
Так вот, отделения из центрально БД по запросу берут только ин-цию о задолженности, а свои платежи хранят локально у себя. Потом вечером все скидываеться в центр для сверки/обработки и втягивания в центральную БД.


С уважением Владимир.
Автоматизация ЖКХ города, единый расчетный центр.

Это схема по приему КОММУНАЛЬНЫХ платежей, которое я уже разработал и успешно запустил полтора месяца назад. Принцип таков - ко мне поступают данные по газу, водоснабжению, электроэнергии, телевидению, данные от разных ЖКХ, после чего каждое из нах отдельно я втягиваю в свою базу данный (по мере поступления данных о задолженности). Кассиры на отделениях принимают платежи и в конце дня формируют реестры оплаты и выгружают данные (формируется ДБФник для втяжки в основную программу для распределения денег по счетам). После этого для некоторых видов услуг каждый день, для некоторых несколько раз в месяц данные передаются и они втягивают их у себя, производят новые начисления и передают обновленные базы данных в начале следующего месяца. Это всё - КОММУНАЛЬНЫЕ платежи.


автор> А что за ПРОЧИЕ платежи?

Логично предположить, что это различные штрафы/пени и т.д.


Абсолютно верно! Для них не нужна централизованная база данных, так как нету начислений. Ее можно использовать разве только что для ведения архива принятых платежей и построения отчетности.

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