по поводу сверки - пока она никогда не происходит :) - за ненадобность. программа моя для не оч больших аптечных сетей - в таком виде как сейчас даже для маленьких скорее. т.е. просто трудозатраты жестоко ж зашкаливают. это не наш метод. кстати у нас на украине вообще оч распространена практика, когда все работы по сборке товара под аптеки перекладываются на поставщика. а иногда и доставка товара на точки тоже - довольно часто. конечно методика такая немного чревата полтергейстами - но очень рентабельна. а - ну и ещё от складов своих сети аптек отказываются. т.е. всё что заказывает точка перезаказывается у поставщиков. причём на каждую точку отдельно заказывается. и потом уже по обстоятельствам - либо привозится разобранным под точки - и в коробочки (не распаковывая даже) вкладываются свои накладные с розничными ценами - и вузётся на точки - а там уже проверяется всё - уже по своей накладной.
вариант 2-й - поставщик сразу развозит всё по точкам. а точка потом получает накладную с офиса свою - с розничными ценами - а накладные поставщика передат на офис. ну или накладные с офиса точка получает в эл.виде - в идеале. такая система работы обеспечивает наибольшую оперативность и оборачиваемость- и наименьшие остатки товара. да - но такая схема - особенно во втором варианте - чревата большим количеством недоразумений - но всё это решаемо и ничего фатального в этом нет - работают многие так. я работаю по первому варианту - и вообще почти нет никаких недоразумений.
а смысл в таких трудозатратах (и незабывайте пожалуйста что и дееньгозатраты ж отсудова вытекают!) - токо разве на опте есть. на рознице нет абсолютно. не знаю как у вас - но у нас не дикий запад - если вдруг бывают какие-то недовозы, пересортицы и т.п. - всё это решается одним звонком - и парой спокойных слов в доброжелательном и спокойном тоне - и нет смысла абсолютно так заморачиваться с проверкой товара - на складе уж точно. на рознице - может и есть смысл - и люди и всё такое... но у нас пока розница не автоматизирована - вообще полностью.
да - я вот токо поймал себя на мысли, что всё время это думал о проверке товара на складе перед отпуском на точки - а вы что имели ввиду?

по поводу monseniorА иногда ещё бывает отборка на сертификаты соответсвия.
Заявки полезны но только в качестве вспомогательного инструмента
для заказа, никакого автоприхода - жизнь вносит свои коррективы! - думаю вы просто меня не поняли. возможно потому, что у вас жизнь эта другая :) - либо потому, что вы программист - и ваша жизнь протекает немного в стороне от аптек. а Я ЖИВУ В АПТЕКЕ :) - токо и всего. и уж кому как ни мне знать её жизнь :). а может мы просто вообще о разных вещах говорим... если так - то видимо проблема в том, что говорю в основном токо я - вы токо немногословно язвите - а о себе не рассказываете ничего. так я с вами не дружу - это односторонняя дружба. расскажите подробнее о своей программе или как считаете нужным и т.п.
а вообще мне начинает казаться что немного это всё наше общение для меня бесполезно - а может и вредно: токо разболтаю что-то - а сам ничего интересного не знаю.
а ещё я ненавижу 1с, дельфи и интербейс :) - тихо ненавижу - но долго и тенденция стойкая - не думаю что в этом плане что-то способно измениться :).
блин - видимо надо отсудова валить. тут токо делфисты и интербейз/фаербёрдовцы и 1ссники видимо - и они же ещё хытрецы - выспрашивают блин у меня всё - а сами молчат как рыба об столб. вопросы больше не принимаются. токо рассказы о себе а потом о своих прогах. а иначе мне это не интересно.

monseniorНа счет ваших автозаказов было такое, но практика отвергла эту идею!
наша практика напротив подтвердила - больше сотни покупателей моей программы было + 2 более сурьёзных чем я конкурентов с большими тиражами. у нас это вообще давно уже это аксиома - не требующая никаких подтверждений.
у вас видимо другая специфика рынка. нет для этого видимо предпосылок. хотя - что-то с трудом верится... к примеру я делал закупки для немецких школ - в германии которых. так мне тоже говорили, что у нас мол не надо то, нет этого - а по итогу оказалось что в процессе закупок я таки лучше ориентируюсь чем заказчик (он не был конечным потребителем). закупками я занимаюсь профессионально шото там около 5 лет или больше. не хочу показаться слишком гамнистым((с) мистер гаррисон - сауз парк) :) - но есть у меня сомнения большие что у вас это не было бы востребовано. а про нас - не смейте понимаиш рассказывать что мол "жизнь показала" и т.п. - это токо к вам относится - у нас жизнь показала совсем обратное. у вас 200 аптек своих - а у нас думаю за 200 сетей чужих.
хотя - всё же есть и подозрение что мы гдето друг друга не поняли и говорим о разных вещах...

по поводу ценности сказанного мной - спасибо, вы меня успокоили :)

да - а на чём ваша техника работает? как я понял видимо делфи+интербейз/файер?

у меня клиент на шарпе. а бд постгрес.
а я видел по истории ваших сообщений что у вас к шарпу появился интерес.
так это - давайте дружить :). у меня там имеется длл для быстрого создания клиентов для бд - токо оно сейчас под постгрес заточено. изначально я планировал универсальной её делать - но потом что-то меня напрягло. на этой длл я по сути начинал ооп изучать :). я на шарп после васика перешол - и что такое ооп с трудом представлял по началу. не знаю как сейчас :). ну короче оно сейчас немного сыровато. но уже оч даже ничего техника. я на ней за неделю вечерами и за 2 выходных магазинчик одежды автоматизировал :). её бы немного долизать - и можно бы было 1с на пенсию отправлять :). а под возможность работать с разными бд думаю там не напряжно её переделать. у меня просто щас в этом нет потребности. я оч люблю постгрес :) и его ни на что не променяю. а так вообще возражений не имею.
кстати на постгрес у вас не было мыслей перейти? хорошая ведь штука. думаю лучше чем мс скл. мне так точно лучше - тут без вариантов - из-за бесплатности. у меня и моя контора и клиентура по крайней мере что первая будет - все бедные и ещё жлобы. у меня нет просто альтернативы. ну а вам всёже думаю смысл тоже есть в этом направлении подумать.

вражаюча осведомлённость :)
всё так и было.
объёмы данных на сегодняшний день не особо велики. даже малы в принципе - мелкая сетка аптек, 4 месяца работы - ещё не накопилось ничего особенного. да и розницы тоже нет - а думаю основной объём данных будет оттудова - чеки. думаю самая большая таблица в бд будет в будущем "позиции чеков". вобщем так или иначе - но 4гига на мсскл-экспресс - это возможно и для моей родной мелкой сетки может стать мало - через пару лет после автоматизации розницы. а клиенты то многие думаю покрупнее будут. вообще у нас дохлая сетка - 4 дохлых аптеки. но за что её люблю - тут у меня полная свобода для смелых экспериментов :).
сейчас текстовый дамп базы 21мб.
но структура бд уже сейчас довольно извращённая. и выбор в ползу постгреса не только из-за объёмов данных. ещё в нём мне нравится plpgsql - ну и другие есть процедурные языки. жалко токо плпгшарпа нету :) - токо явка. ну вобщем - особенно после аксеса - в пгскле я чуствую что мне никогда не будет тесно - я его сейчас не плохо знаю - но ещё долго мне будет куда расти - и главное - я уверен, что всё, что вообще можно сделать с клиент-серверной бд на пгскле я смогу сделать. с скл-экспрес есть токо в противоположном уверенность. с боьшим мсскл есть лёгкая неуверенность что его может для чего-то не хватить мне - проверять не охота. хватает и того, что кроме этого он ещё и платный.

а в мсскл есть что-то по типу обработки ошибок? ну вот наподобие плпгсклшной конструкции:

monseniorвы хотите вынести розницу в отдельную таблицу?
Технологически розница - это тоже списание товара(продажа с адресом в никуда),
и для неё не надо создавать отдельной таблицы.

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

а чеки и позиции чеков - это 2 таблицы отдельные будут - и в розничном блоке - и на центр.складе (это 2 программы отдельные будут - с обменом данными через файлы)
monsenior
Основная проблема розницы - это создать удобный интерфейс
для "бабушек" из аптек!
Посоветую вам попробовать на тестовую базу залить большой объем,
а потом посадить условную "бабушку" - поработать.
согласен полностью. я дело в том что работал одно время внедренцем одной программы где это было. там это было очень удачно. и на 1с видел пару конфигураций для этого - не оч там было хорошо. там да - простота и скорость (т.е. минимальное количество телодвижениев) залог успеха - и одновременно самое узкое место и самое важное требование.
я кстати ещё кроме всего прочего профессиональный учитель для бабушек по основам компутерной грамотности :). у меня даже была ученица одна - за 70 :). паника была с истерикой жуткая :) - всем коллективом и мной уговаривали не увольняться 2 дня :). ничего - обучилась, работает :)

sobolev monsenior
вы хотите вынести розницу в отдельную таблицу?
Технологически розница - это тоже списание товара(продажа с адресом в никуда),
и для неё не надо создавать отдельной таблицы.

Я то же когда-то так думал. Сложно обобщить. Кассовые чеки и кассовые сессии совершенно отдельные структуры данных. После того как кассовая сессия сформирована ее (или совокупность сессий - суперсессию) следует проецировать на учетные документы.
Почему так?
1. Кассовых чеков действительно очень много. Особенно в сетевой рознице. Их структура сильно отличается от обычной разреженной отгрузки: точное время, кассир, стол (для ресторана), агент, кассовый аппарат (особенно, если их много), дисконтная карта и т.д.
2. В строках чеков похожие проблемы, кроме того, их на порядок больше, чем самих чеков, и их структуру надо оптимизировать.
3. Если система взаимодействует с внешними кассовыми модулями, то нужна хорошо адаптируемая к разным модулям структура.
4. Пользователи очень любят аналитику по чистым кассовым чекам, не спроецированным на учетные документы.

истину глаголите :) - всё так и есть - абсолютно согласен

sobolev
Одна из самых больших здесь проблем: отсутствие онлайновых остатков. Приходится либо объяснять пользователям, что они не очень и нужны, либо делать "виртуальный" расчет остатков с учетом и документов и чеков, которые еще не списаны в документы.
это не очень понял. в чём проблема? у меня по идее их не должно быть - вот в отпуске по складу у меня сразу при включении позиции в накладную в другую её уже не выбьеш. а по складу это количество светится как резерв. т.е. как-бы оно ещё на складе - но для того, чтобы его выбить в другую накладную его надо токо снять с первой. так же и новый приход по складу видно отдельной колонкой. сейчас в складской программе в реализации это всё не нужно - а на рознице в реализации это всё будет видно - новый приход (допустим пришло - но ещё не проверено) и резерв под другие чеки (ещё не пробитые) тоже.

2sobolev
однако я ету технику на продажу пишу - самому мне оно нафик не надо - работёнка эта у меня оч плохо оплачивается и сеть аптек тоже не моя. и свою тоже не хочу открывать - хоть может бы и смог - т.к. тесновато тут уже у нас - давка страшная - меня затопчут мастодонты всякие.

у меня сейчас остатки во вьюхе. никакой отдельной таблицы для этого нет. вполне нормально всё работает - но как я уже говорил токо 4 месяца работает - и на дохловатой сети из 4-х дохлых аптек. т.е. может вы и правы - может и тут через пару лет с этим проблемы начнутся. не знаю. щас правда машина тут слабая - замечательно тянет всё. даже если и будут проблемы - то думаю на такую же машину сервер переставить и ничем его больше не загружать - и нормально будет. или если получше взять аппарат - так думаю нагружать его можно будет на пару порядков больше. не знаю. будем посмотреть - вскрытие покажет. может как-то попробую потестить - забью мусором всяким базу - чтобы данных было на пару-тройку порядков больше - и посмотрю как потянет. но с таблицей отдельной - это явно нарываться на ошибки лишние. хотя конечно от конкретной реализации зависит...
думаете по такому принципу не прокатит с чеками? для склада то видимо этого на долго хватит. а вот за чеки я побаиваюсь... годик работы - и может уже начнутся пробуксовки - да?
хотя это - железо то сейчас дешевеет :). можно будет сервак навёрнутый поставить - и будет сплошной ок и вери гуд:)

2sobolev: а где на http://www.petroglif.ru скрины можно глянуть? там токо пока нашол предлагается скачать большие файлы справки и демки - у меня оплата по трафику - жаба давит :). мне скринов хватит вполне - для общего развития пролистнуть.
а на чём наисано?

на данный момент в базе 1254 приходных документов с 12947 строк и 691 расходных с 13203 строк. ничтожно мало в принципе. чеки куда быстрее будут размножаться. заставили вы меня призадуматься. надо будет провести эксперимент следственный с искуственным и оч резким размножением прихода и расхода - и посмотреть как по скорости тогда склад будет считаться...
да - вот кстати постгрес 8.3 недавно вышел - обещали резко улучшить перфоменс. ещё я на него не перебирался. кстати довольно часто его обновления выходят - и всё это безвозмездно - тоесть даром :). рекоммендую :).

sobolevЗавтра, если хотите прибью к реплике несколько штук. Только скажите, что именно.

Написано на c++. Честно сказать, пишется о-о-очень давно. Несколько сетевых и standalone-аптек у нас есть. Они всякие импорты-экспорты и серийные номера используют - работает.
PS
Мне казалось, что дистрибутив маленький (ок 30М в сумме). На будущее будем знать - выложим на сайт пару десятков скрин-шотов.

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

на сайт можно конечно бы выложить - думаю не помешает. особенно там, где текстом у вас описание - туда и скрин бы положить - для наглядности. а вообще на меня не стоит ориентироваться - у клиентов то потребности другие совсем - им может и так нормально. а мне то качать его ради посмотреть 3-5 скринов как-то не очень хотелось бы.

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

C++ 10 9,62% 0.02%
ERP и учетные системы 60 57,69% 0.16%
VB.NET 1 0,96% 0.01%
Программирование 5 4,81% 0.02%
Проектирование БД 3 2,88% 0.01%
Просто треп 8 7,69% 0.00%
Разработка информационных систем 16 15,38% 0.09%
Тестирование и QA 1 0,96% 0.08%