сшивка кодов на 80% происходит автоматически при заказе,
при поставке проверятся вместе с ценами, легко корректируется или создается новый код

http://www.orc.ru/~zgrad/am/avtomagik7.JPG

Подытоживая легкий обмен мнениями, можно добавить, легкая фишка - целый час ночью вычисляется оптимальная последовательность кодов для заказа в виде ленты, по которой 4 менеджера днем строчат по прайсам, делая заказы как из пулемета Максим :)
как наркоманы – пришлось им сделать лимит заказа.

и в качестве сервера у нас используется PC Пентиум 4 с 1Г озу вроде DDR333
(короче такую уже не выпускают)
и где-то 20 клиентских машин, одна из которых даже NT4.0 230 мегагерц.

Алексей Е.
Не подскажите:
1. Как adp проект относится к разным версиям MS Access ?
2. Закладок Access не поддерживает?
3. Может ли пользователь открыть adp проект в режиме коструктора и чего-то подпортить?

1. - не в курсе, в каждом офисе есть Access, нажал конструктор и ты - ларджест программист

2. - не в курсе (сам знаю 5% от возможностей Access, и не хочу больше, меня привлекает рисование, direct-конструирование)

3. - легко, все накладные и финансы двигаются и меняются только триггерами на сервере (то есть только юзером с правами сисадин)

но если клиента раскурочили, а такие случаи бывают, есть ярлык - взять копию клиента с сервера, а утром при старте клиентских машин на них копируется текущая версия клиента с сервера)

не надо вам никаких Oracle Forms

зачем они Вам?

веб-клент на джаве?
это что сильно лучше веб клиента на asp?
просто я не в курсе
все очень туманно

Вопрос спецам 1С - у бухгалтера стоит 1С 7.7 бухгалтерия, там есть «Журнал платежных документов» с платежами за аренду, электричество и пр.
Мне нужно, чтобы в SQL была актуальная таблица - копия этих расходов.
(пусть хоть с суточной задержкой)

Как сделать?

Глянул, какие меняются DBF, при создании платежки, чуть крыша не сьехала.

> Могу похвалиться :-) , у нас полный расчет ЗП на 2300 человек идет 35 минут максимум, не выгоняя никого из базы.

Вы опоздали на 35 минут?

Если эти данные нужны, то они должны считаться в реальном времени.
А если не нужны, то и вопроса нет..
Ежесекундный баланс фирмы в актуальном состоянии.

А вообще-то главное в бухгалтерии - расходы на единицу продукции – и они тоже должны считаться в реальном времени – то есть постоянно быть посчитаны (и нужно это чтобы принятие решения о цене продажи было мгновенным)

То есть данные, неожиданно нужные в 14 часов, должны были быть посчитаны до этого момента, делается это триггерами, ничего сложного.

> зачем постоянно все расчитывать в реальном времени, если сами данные идут с опозданием?


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

документ провел – баланс пересчитался.
документ провел – баланс пересчитался.

Закрыть старый период – поставил метку заблокировать новые проводки.
Текущий актуальный баланс чего-то всегда перед всеми, кому он нужен, и для его «расчета» не нужно ждать ни одной секунды.

> У вас бухгалтерия чем занимается? БУ? Бухгалтерский учет всегда был и остается посмертным. Никакой принципиальной необходимости в реальном времени считать зарплату просто не существует.


наверно вы правы, лично я не в курсе, что такое бухгалтерский учет, у нас этим занимается специальная тетенька в 1С

вы бы сами как сформулировали - что такое дебит и кредит?

> представьте, что у вас всего 2 бухгалтера, а они должны обработать до 1000 документов в день (это средний показатель, бывает и 2000), при этом документы заполняются конечными данными хаотично, т.е. сегодня он сделан так, но пока период не закрыт его еще 10 раз поменяют - все это постоянно перепроверять и контролировать нереально




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

2 процессора работают быстрее 1
5 землекопов копают больше 4

все проверки и исправления и контроль надо кинуть туда – на места - где эти 1000 документов пишутся, если обработка их узкое место

и с точки зрения вычислений - от «учетов» надо переходить на реагирование на событие.

На месте произошло событие – сработал триггер на это событие - и пересчитал все балансы, если это надо.

В том то и дело, что на сегодня – связка Access adp проектов и SQL дает возможность легко реализовать это повсеместно.
(еще в 2000 году это было проблематично, а сегодня это тривиально – именно это я и отмечаю и на практике, и тут на форуме – мне самому непонятно куда движется программирование, но изменения произошли качественные с появлением в 2000 году Access adp проектов, всякий гимор с odbc драйверами ушел в прошлое, не то что какие-то пересчеты, а сама разработка клиентских мест стала идти в реальном времени - в сотни раз повышая производительность по вашему "УУ".

Если мощность "УУ" можно повысить в сотни раз - прилепить к нему "БУ" - это просто еще один эпизод сетевой командной работы.