|
|
|
| Задача следующая. В сети порядка 30 пользователей, которые понятия не имеют что такое 1С и с компом дружат через раз вообще. Юзверы принадлежат к разным отделениям.
Есть аптека, которая должна получить заявку от каждого из 30 отделений, в электронном виде, после чего обработать должным образом. Главное – это что бы в заявке была та номенклатура, которая есть в 1С и звучать должна как звучит в 1С предприятии. (само собой в 1С никого не допущу просто так) К тому же в сети акс тормозит мягко говоря даже с 2-3 пользователями.
Решил сделать так:
Бухгалтер аптеки выгружает из 1С номенклатуру в экселевском файле. Скажем Лист1. Там порядка 3000 наименований. Выкладываю этот файл в ресурс сервера, где юзверы его не достанут.
В каждом отделении мелкая базка в виде одной лишь ленточной формы с системой поиска. Экселевский файл присоединен к этой базе. (тут почему-то не получилось эту таблицу сделать источником данных для формы) Не важно. При нажатии кнопки на стартовой форме запускается запрос на создание таблицы и в локальной базе юзвера появляется таблица – копия того эксель файла. Она - источник строк для ленточной формы на компе юзвера.
Далее юзверу необходимо выбрать нужное (поле номенклатура заблокировано, что бы ничего не изменили) и напротив поставить количество.
При закрытии формы запрос на создание таблицы создает в базе аптеки таблу с выбранной номенклатурой и желаемым количеством. Третье поле – префикс принадлежности к отделению.
Каждый раз при новом создании таблы, будут новые данные.
Затем запрос на объединение суммирует все созданные 30 таблиц в одно целое и получаем по каждой номенклатуре сколько надо и кому конкретно сколько чего надо.
При изменении номенклатуры есть 2 варианта. Либо обновить файл екселя, выгрузив заново из 1С, либо добавить пару наименований ответственному лицу непосредственно в эксель.
Прежде чем это делать, решил выложить на суд свой позор, что бы получить совет не заморачиваться или что не так. | |
|
| |
|
|
|
|
При закрытии формы запрос на создание таблицы создает в базе аптеки таблу с выбранной номенклатурой и желаемым количеством.
|
не рациональное место
зачем создавать каждый раз новую таблу - подгрузить данные в таблицу в одну
подконнектиться к бд аптеки и подгрузить заявку
еще одно непонятное место - что останется у клиента в подтверждение заявки | |
|
| |
|
|
|
| Не-не. Не каждый раз. В базе аптеки будет всего 30 таблиц. В каждой будет только то, что заказано. Если подгружать в таблу, то можно было бы и одной обойтись, куда подгружались бы все данные со всех отделений, с фиксацией своего префикса (откуда), дата и все остальное.
Может быть и так. Но в этом случае табла будет жутко расти, а то, что было заказано никого не интересует. Заказали - выдали - списали, накладные в базе 1С оставили следы.
Дело в следующем: В аптеке все медикаменты разложены по группам по шкафам. В каждое отделение надо сколько-то из каждой группы. Если набирать накладную в отдельности, то получится к каждому шкафу подойти раз 100, что одному челу невозможно. Он там и умрет среди шкафов.
Надо после того, как получили заказы, разгруппировать все так, что бы подойдя к одному шкафу, было ясно. Из этой группы берем
Аспирин - 40 штук
Димедрол - 100 штук
хрень - 400 штук
Далее уже потом из этого аспирина 2 штуки -на 1 отделение, 20 штук в другое, 5 штук... и так по всем.
В данное время заявки приходят в письменном виде. Прежде чем собирать что надо в шкафах, все эти ручные заявки разбираются, выписывается количество по каждому медикаменту, затем складывается, после чего идется к шкафам... В общем на это полдня уходит. Вот и идея. Проще им работать с экселем. Файл экселя как прайс ну и т.д.
Почему решил создавать таблу в базе аптеки. Нужен разовый заказ. Если на той стороне решили перезаказать, то сделали новый набор и новые данные по количеству. При создании новой таблы старая уничтожается. База не растет, не надо думать как уничтожить старые данные.
Что останется в базе заказчика. Думаю над этим вопросом. Вплоть до шаблонов что-то надо бы. Может быть будет добавляться в архивную таблу с фиксацией времени и даты. Но тут тоже что-то делать надо со старыми данными, которые уже не интересны.
Вот и в размышлении ЧД и как. | |
|
| |
|
|
|
| почему не все в одной базе? | |
|
| |
|
|
|
| 1. Акс жутко тормозит в сети, и особенно когда к базе подключено более 2 человек. Тут же почти одновременно будут работать 30 (заявки будут создавать в одно время)
2. Прайс легче менять, когда просто из 1С в екселе файл выгружается.
3. Работать каждый будут в своей базе. Для этого и создается таблица в аксе (копия экселевского) хотя я уже думаю от этого отойти и делать форму на основе прилинкованной экселевской
4. В главной базе будут только таблицы текущего заказа каждого из отделений. Поэтому сама база расти не будет.
Пока так. | |
|
| |
|
|
|
| 300 тысяч номенклатуры 10-15 пользователей
вполне сносно работает на msa 2003
гемор с синхронизацией справочников с головой накроет всякие выгоды.
Выгружить из 1С можете куда хотите, но в принципе можно и прилинковать к access прямо 1c dbf
а вот база, IMHO, если все в одной сети. должна быть одна. | |
|
| |
|
|
|
| А нельзя создать одну таблицу, как и советует Олег. Табла м.б. одна на все заказы за все время, либо одна на заказ (я бы выбрал первое). Далее, группируем по номеру заказа и по наименованиям. В итоге, будем иметь одну позицию с кол-вом (центр. склад). Если тупо сгруппировать по номеру заказа и отделению- будем иметь нужное кол-во в каждую точку...
Выборка на центральном складе:
select idZakaz, Tovar, sum(CountZak) from Table1 where idZakaz = 127 group by Tovar
При развозке набранного токара:
select idZakaz, Otdelenie, Tovar, sum(CountZak) from Table1 where idZakaz = 127 and Otdelenie = 5 group by Tovar
т.о. на один заказ можно несколько раз "докидывать" один и тот же товар. Все равно потом сгруппируется. При развозке дубликаты тож убрали.
Или идея в двух словах: Иметь одну таблицу для заказа. Данные могут добавляться несколько раз. Выборка оттуда группировкой по нужным полям.
Если несколько одновременных подключений тормозит- то возможно стоит ограничить параметры подключения (OpenOptions, LockType, adCursorTypeEnum)- тогда базе будет полегче, если она скажем, когда надо пользователю тока читать, будет давать тока читать, а не полный доступ...
Как-то так.. | |
|
| |
|
|
|
| Проблема в том, что табла будет расти как гриб после дождя. А зачем? Вторая проблема с корректурой. Заказали... Ой нет, не так, другое хочу.... Снова заказали. А как ту инфу будут убирать? Стало быть надо подключать клиента к главной базе и пойдут тормоза. Ограничивать как? Все будут подавать и выбирать заказы в одно и то же время по распорядку дня. Иначе не получится.
На счет группировки по полям - это все понятно. Вопрос как корректировать. Заказал 20 штук, потом решил перезаказать 10. Связывать таблу с пользователем надо.
А так, запрос на создание таблы будет уничтожать старую и делать новую с префиксом отделения. А запрос на объединение всех созданных таблиц выдаст отчет кому что надо. К тому же в ексель будет гораздо легче выкидывать номенклатуру из 1С.
Хотя это мои домыслы. Как на практике сделать пока не знаю, потому и советуюсь. А вдруг уже кто-то что-то в этом роде делал и наступил на грабли. Не хоцца. | |
|
| |