Может ли база данных как-то расшифровывать ошибки? Например, если проблема в том, что водитель привязан к одной машине, а мы пытаемся его посадить на другую (если это может вызвать ошибку, конечно), как-то указывать, где искать проблему

Пытаюсь создать маршрут, указала сегодняшнюю дату, выбрала водителя, привязала к нему машину (не связанную с этим водителем), привязала несколько "ожидающих оформления" заявок.

При попытке сохранить выдает "Ошибку во время сохранения данных в БД" и "Ошибка сохранения связанных данных (заявки)".

Не совсем понимаю, для чего существует эта привязка, потому что при создании маршрута и выборе водителя, к нему можно привязать опять же любую машину из справочника...

Это пока не работает?

Может, переименуем ее в "Выбрать", или еще как?

Мне кажется, с точки зрения самого простого пользователя это понятнее, чем "Связать"

Пытаюсь ввести новую заявку.

В поле "Доп.соглашение к договору" нажимаю "Связать", выбираю контрагента, а дальше кнопки "Связать" нет...

Есть ли здесь возможность просматривать некую историю всех действий, производимых с базой? Аксесс умеет фиксировать все введенные/измененные/удаленные данные в виде: "Дата, время, пользователь, какое поле, что сделал, старые данные, новые данные". Это нам очень нужно.

Не вижу в доп.соглашении пункта "Вид отхода бухгалтерский". Это обычное текстовое поле, данные из которого будут фигурировать в бухгалтерских документах.

Дело в том, что фактически вывозимый груз не всегда соответствует тому, что будет написано в документах.

В дополнительном соглашении указываю "предполагаемый объем" 1000, в списке доп.соглашений это число выглядит как "1 000 м3"

Не нашла некоторых справочников, которые существуют в Аксесс:

1. Владельцы талонов.

Это справочник тех пользователей, кто может являться "владельцем" или ответственным за талон. Вкратце поясню, что это означает.

В момент забора груза с объекта, водитель получает от заказчика "талон" (мини-накладная или акт, в котором указано: контрагент, объект, дата, время, фактическое количество вывезенного груза, фио, должность и подпись ответственного на объекте - фактически это подтверждение выполнения нами работы), в этот момент водитель является владельцем талона.

По приезду на АТП водитель сдает талоны оператору, с этого момента она является их владельцем.

Оператор сканирует талоны, прикрепляет каждый к соответствующей заявке в базе данных. Правильно оформленные талоны оператор "передает" новому владельцу - менеджеру коммерческого отдела. Менеджер КО проверяет талон, если он неверен - передает обратно оператору с указанием "причины возврата", если верен - ставит галочку, что все хорошо, бухгалтер на основании этой галочки понимает, что "ходка" закрыта и выставляет бухгалтерские документы. Все, заявка на этом считается закрытой.

Отсутствующие или неверно оформленные талоны оператор передает другому владельцу - менеджеру по работе с клиентами. Их задача - получить отсутствующий или исправить существующий талон у клиента и привезти обратно оператору. После этого талон от оператора идет к менеджеру КО по вышеописанной схеме.

2. Должности.

Должности сотрудников - они же группы прав доступа.

3. Лимиты.

Это ограничения для некоторых объектов по вывозимому объему отходов на месяц. Дело в том, что руководство некоторых объектов устанавливает для них ограничения (или лимиты) на количество отходов, которые они могут вывезти нашими силами. Отслеживание этих лимитов возложено на нас, все, что вывозится сверх лимита - вывозится за наш счет.

Менеджер КО в начале каждого месяца указывает лимиты для своих объектов, диспетчер должна отслеживать эти лимиты перед вводом заявки по этому объекту (вернее, отслеживать, конечно, должна база данных, и не давать ввести заявку, если лимит исчерпан).

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

4. Пользователи.

Я так понимаю, сейчас это где-то существующий, но недоступный справочник? Нужно будет предусмотреть возможность нескольким администраторам пополнять этот список и, соответственно, права (должности)

5. Причины возврата талонов.

В пункте Владельцы талонов упомянула этот справочник. Это закрытый перечень причин возврата.

6. Работа.

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

7. Цены для водителей.

Для расчета их работы по справочнику видов работ. Пока не нужно, но на перспективу.

8. Регионы

Справочник регионов, в которых осуществляется работа.

9. Статусы заявок.

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

Нужно принять решение на основе чего у нас будут создаваться заявки. (Если считать, что уже реализованная система не подходит.)

В данным момент основа - это выбранное доп. соглашение. Даже если отключить диспетчерам возможность видеть и выбирать договора/допы, тем не менее оставить доп. соглашения как основу возможно. Тогда возникает вопрос, должны ли диспетчеры иметь возможность их редактировать? Или наоборот редактируют их только менеджеры? Если диспетчеры их редактируют, то существующий интерфейс редактирования заявок не нужен. С другой стороны этот интерфейс наиболее простой, т.е. он ближе всего ложится на существующую структуру БД.

Второй вариант, брать за основу для заявок объект. Основание: в цепочке регион -> контрагент -> объект ни договор, ни доп. соглашение на прямую не участвует. Т.е. при создании заявки можно выбрать только разрешенный объект (т.е. на него должно быть доп. соглашение), после создания заявки заявка перестаёт иметь какое либо отношение к доп. соглашению, мы просто копируем ссылку на объект, контрагента и пр. в саму заявку. Другими словами, например, удаление доп. соглашения больше не затронет саму заявку (потому как она привязана не к допу, а к контрагенту и объекту). Естественно, что изменение внутренностей конкретного доп. соглашение связанные заявки никак не меняются, т.е. заявки будут существовать отдельно от договоров, договоры будут служить просто "настройками фильтра" при создании заявки, все, после того как заявка создана договор/доп никак не используется.

Пока не могу принять решение в пользу одной из архитектур, Екатерина, нужны ваши мысли.