Выставление счета по сравнению с заключением в кавычки или оценкой
Если счета могут быть освобождены, они должны использоваться в качестве цитат?
Я имею Invoices таблицы, который создается из материально-технических ресурсов, связанных с a Job или Order. У меня мог быть a Quotes таблица как социальная гостиница между материально-техническими ресурсами и счетами, но такое чувство, что у меня были бы дублирующиеся структуры данных и логика только для обработки, "Действительно ли это - кавычка?" бит.
С бизнес-точки зрения кавычки отличаются от счетов: завка отправлена до обязательства, и счет отправляется, после того как это завершено, и оплата является подлежащей выплате, но как представить это в моем репозитории и модели.
- Что изящный путь состоит в том, чтобы сохранить и управлять кавычками и счетами в базе данных?
Править: обозначенный Job === Order для этого конкретного экземпляра.
4 ответа
Существует 3 подхода:
Храните счета и расценки в отдельных таблицах.
Это хороший вариант, если в счетах-фактурах и котировках есть несколько повторяющихся полей (в противном случае используйте вариант № 3 с 3 таблицами), и если между ними существует связь «один-много» или «много-много» (для 1–1 используйте вариант №2).
Это также хороший выбор, если обычно "общая" информация между ними может фактически изменяться, когда цитата становится счетом-фактурой (хотя некоторые из этих изменений должны обрабатываться должным образом с отдельными полями / таблицами, например, применяемые скидки, так далее...).
Очевидно, что необходимо сделать небольшое изменение этой опции, когда несколько предложений превращаются в один (или несколько) счетов-фактур. Это добавляет третью таблицу, которая представляет собой сопоставление между набором кавычек и счетом-фактурой (или набором счетов-фактур, если он становится настолько сложным) для них.
Сохраните их в одной таблице с дополнительным флагом «Счет-фактура или предложение» и любыми дополнительными полями из обоих сохраненных. Это можно сделать либо с помощью счетов-фактур и кавычек в отдельных строках, либо с их общими строками (с флагом, имеющим значение «оба»).
Последний вариант (одна и та же строка может быть как счетом-фактурой, так и цитатой) является хорошим выбором , если они отображаются от 1 до 1 , и есть несколько полей, которые различают эти два поля.
Первый вариант (отдельные строки для счетов-фактур и предложений) в целом не является хорошим дизайном, и его лучше использовать с вариантами №3 или №1.
Имейте 3 таблицы: одна для общих полей между ними, а две - только для счетов-фактур и только для котировок.
Это хороший выбор, если счета-фактуры и кавычки сопоставлены 1–1 или если они равны 1 к множеству, но каждый из множества счетов-фактур имеет точно такие же значения полей для любых полей, которые являются общими. В противном случае используйте №1.
Небольшая вариация этой опции может быть сделана, когда несколько предложений преобразуются в один счет-фактуру. Это добавляет 4-ю таблицу, которая является отображением между набором кавычек и накладной (или набором накладных, если это становится настолько сложным) для них. Опять же, здесь предполагается, что существует значительный кусок общей информации между всеми котировками и счетами, связанными / объединенными вместе, в противном случае просто используйте №1.
Котировки больше похожи на заказы. Я видел несколько систем распределения / розничной торговли с таблицей заказов, у которой есть логический флаг, названный чем-то вроде IsQuote. Это может показаться простым, поскольку превращение цитаты в заказ становится тривиальным делом. Мне это никогда не нравилось, потому что заказы, которые выходят из котировок, не всегда в точности соответствуют котировкам. В результате такие системы теряют информацию, которая может быть полезна (например, отчет, в котором котировки сравниваются с заказами). Поэтому я предпочитаю системы, в которых таблицы котировок и заказов примерно одинаковы, но разделены. В системах распределения это часто приводит к таким таблицам, как OrderHeader, OrderLine (относится к таблице товаров / запасов), QuoteHeader и QuoteLine. У вас также может быть таблица для моделирования отношений, в которой одна цитата может отображаться на несколько заказов.
Счета-фактуры обычно являются результатом заказов. Иногда в одном счете выставляется более одного заказа. Например, есть случаи, когда я видел, как компании ежемесячно выставляют счета своим хорошим клиентам. Я также видел, как это работает иначе, когда большой заказ с несколькими отправками оплачивается по нескольким счетам (по одному на каждую отправку).
Наконец, платежи обычно имеют отношение "многие ко многим" со счетом-фактурой. Иногда один платеж покрывает несколько счетов. Иногда один счет оплачивается двумя платежами.
Я бы порекомендовал проявить максимальную гибкость. Используйте следующие таблицы
Таблица заданий, Таблица счетов-фактур, Таблица предложений
В таблице счетов-фактур и Таблице предложений сохраните идентификатор задания, дайте ему индекс и создайте ограничение внешнего ключа.Оставьте кластерный индекс по идентификатору котировки и идентификатору счета-фактуры.
В последней системе я работал над единственной разницей между котировками и счетами (с точки зрения БД) был флаг в таблице, который указывал, был принят клиентом (в этот момент было создано другое заявление со всей той же информацией, за исключением того, что это был счет, а не предложение)