| |
|
|
| | Добрый день всем !
Назрела необходимость написать простенькую базу по учету реализации и оплат. Т.е. особых наворотов не требуется - только контроль задолженности по покупателю. К сожалению особого опыта в проектировании подобных баз у меня нет. В связи с этим мучаюсь с одним принципиальным вопросом (остальные благополучно решил в предыдущем приложении): Как правильно сконструировать таблицу по учету отгрузок и оплаты ? Напрашивается 2 варианта :
1. Сделать поля Покупатель-Накладная-Сумма-Оплачено-Долг - тут все просто, сумма долга посчитана и хранится в таблице. Но ежели покупатель платит частями , то возникают сложности с корректным разнесение оплат.
2. Сделать поля Покупатель-Накладная-Вид операции(отгрузка/оплата) -Сумма - в этом случае сумма долга будет формироваться в результате выполнения запроса.
первый вариант подкупает простотой, а второй гибкостью. У кого есть опыт в создании подобных баз - поделитесь мыслями плиз.
З/Ы Если кто поделиться простеньким примером буду премного благодарен. Взамен могу предложить либо пиво (в ПИТЕРЕ) либо базу по планированию платежей (заявки на оплату, реестр платежей, выписка, отчеты) | |
| |
| |
| |
|
|
| | 1) таблица покупателя Код, наименование.
2) Таблица накладных КодНакладной, КодПокупателя, что-то еще, что вам надо хранить
3) Таблица движения товара и учета оплат
кодНакладной, Дата, Отгрузка, оплата
Долг и другие вычисляемые значения в таблицах не хранить | |
| |
| |
|
|
| |
|
|
| | (мечтательно) ПИВО.... (еще более мечтательно) В ПИТЕРЕ.... эх, мечтательно закатил глаза и сглотнул слюну 
В общем тут для начала нужно понять что и как будем учитывать и как и что возможно:
1. нужно ли знать что оплатечена конкретная накладная или только сумма долга/оплат по клиенту в целом
2. возможна ли оплата конкретной накладной минуя оплату других неоплаченных накладных
3. возможна ли оплата одной накладной несколькими суммами?
4. возможна ли оплата нескольких накладных одним платежем?
5. Возможнали комбинация вариантов 2, 3 и 4? а в разной валюте?
6. Возможны взаимозачеты? а прощение долга?
ну для начала хватит  | |
| |
| |
| |
|
|
| | Да, п. с 1-4 возможны. Я просто походу немного туплю с алгоритмом определения скажем так оплаченности накладной. Попробую сделать как советовала уважаемая Ирч. Поскольку раскидав номера накладных по двум таблицам я ничего не добился. Но будем пытаться. | |
| |
| |
| |
|
|
| | >Назрела необходимость написать простенькую базу по учету реализации и оплат. Т.е. особых наворотов не требуется -
контроль задолженностей по покупателю (разноска платежей) не самая простая задача в любой предметке. Предположим
покупатель заказал:
ORDERNUM PRICE VAT AMOUNT
_______________________________________________
112233 400 72 472
668899 700 126 826
555001 1500 270 1770
_______________________________________________
TOTAL AMOUNT 3068
|
и покупатель оплатил
DATE ORDERNUM AMOUNT
_______________________________________________
12.12.2006 555001 1675
12.12.2006 668899 826
30-02-2007 112233 567
_______________________________________________
TOTAL AMOUNT 3068
|
как по вашему каково состояние задолженностей покупателя перед продавцом и продавца перед покупателем
(это я еще привел данные в которых нет ошибок в "предмет счета" в платежном поручении покупателя - так что просто пивом тут не отделаться :))) ) | |
| |
| |
| |
 33 Кб. |
|
| | Пиво выпил сам :))). И вот что получилось. Т.е. идея Ирча заработала. Остается только прикрутить покупателя и решить вопрос надо ли номер накладной и прочие её причиндалы заносить в отдельный справочник. Поругаете :)) | |
| |
| |
| |
|
|
| | Может это поможет http://accessoft.ru/SP/SP5.html | |
| |
| |
| |
|
|
| | Не понимаю что у вас заказ и что накладная? какой документ является первичным при фоктической отгрузке? если накладная, то именно её номер должен быть ключевым для таблицы операций... | |
| |
| |
| |
|
|
| | Накладная. Тут идеи какие были - накладные из 1С через шаблон эксел попадают в таблицу - в этом случае возникает косяк с указанием наименования покупателя. Но он решаем на уровне шаблона. Или накладные вводятся вручную - тут проблем нет кроме ошибок в номере. В первом случае если мы делаем ключом номер накладной то получем проблему с повторением уникальных записей (если я все правильно понял насчет ключевых полей) т.е. внести оплату , сославшись на номер накладной мы уже не можем. И получается что сначала мы должны должны заполнить справочник накладных, а потом уже таблицу операций, что несколько громоздко. Вот в чем главная проблема. В примере я просто прикинул сам алгоритм выявления оплаченной накладной.
З/ы Что интересно - в интернете не нашел ни одного примера реализации такой базы. Хотя вроде бы это уровень 2-3 курса института. Может проблема настолько ерундовая, что нет смысла её решать | |
| |
| |
| |
|
|
| | ключем номер накладной не стоит... они повторяются каждый год, лучше счетчик
Тогда вам в вашу структуру надо добавить таблицу накладных
типа:
КодНакладной(ключ)
КодПокупателя
Номер
Дата
И чего вы там хотите еще...
А в таблице движений привязываться к КодуНакладной.... | |
| |
| |
