![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Триггеры в master-detail [IB6.x]
deras © (2007-05-21 15:36:00)есть 3 таблицы:
1) Главная T_MAIN
Поля: ID, ID_KONTRAG, ID_SKLAD
2)Подчиненная T_CHILD
Поля: ID, ID_PARENT, KOLVO, CENA, SUMA
T_CHILD.ID_PAREN -> T_MAIN.ID
3) Таблица KUB
Поля: ID, ID_KONTRAG, ID_SKLAD, KOLVO, CENA, SUMA
Как повесить триггеры (After INS/UPD/DEL) на какую-то из T_MAIN или T_CHILD (точно не знаю), чтоб данные попадали в таблицу KUB?
deras (2007-05-23 18:10:00) [1]>DrAndrey © (23.05.07 17:55) [106]
ответил на мыло
DrAndrey (2007-05-23 17:55:00) [2]>deras © (23.05.07 17:40) [105]
Не против, но асинхронно и не в форуме, пиши в мыло.
:-)
deras (2007-05-23 17:40:00) [3]>DrAndrey © (23.05.07 15:28) [103]
Получил Ваше письмо. Надо переосмыслить... Вопросы конечно же будут, если Вы не против отвечать.
deras (2007-05-23 16:12:00) [4]>DrAndrey © (23.05.07 15:28) [103]
Мне пока большего и не надо. Благодарю!
DrAndrey (2007-05-23 15:28:00) [5]>Я не просил, просто по-дружески предложили и я не отказался :-)
Да речь шла именно о рисовании примера, лови. Но как и обещал все очень примитивно.
Сергей М. (2007-05-23 15:18:00) [6]
> ANB © (23.05.07 14:59) [99]
> Таки я одного не понял - зачем для одной партии в 180 единиц
> при расходе в 100 бить расход на 2 записи ?
Партия-то одна, но документов-то по ней два)
А приходные акты движения, imho, логичней связать с приходным документом в полном комплекте документов по поставляемой партии, а не с "общепартийным" документом.
Заметь - отчетным документом в фиск.органы является накладная и счет-фактура, в них никакие "партии" не фигурируют и в помине.
deras (2007-05-23 15:07:00) [7]>Вообще то даже рисование примера базы будет стоить больше всего вашего гонорара.
Я не просил, просто по-дружески предложили и я не отказался :-)
ANB (2007-05-23 15:00:00) [8]
> ..Помнится Ві обещали пример базу отослать. Жду с нетерпением.
> ..
:) Вообще то даже рисование примера базы будет стоить больше всего вашего гонорара.
ANB (2007-05-23 14:59:00) [9]
> справочник ФХ-операций со справочником движения товаров
> в одну кучу - тупиковый путь.
Не, этож совершенно разные таблицы.
Таки я одного не понял - зачем для однойпартии в 180 единиц при расходе в 100 бить расход на 2 записи ?
Когда я писал бухгалтерию одной из проблем было предупредить непомерное разрастание базы. Посему несколько приходов вполне укладывались в одну партию поставки, чтобы потом не вводить слишком много записей о расходе - просто неудобно и база пухнет.
deras (2007-05-23 14:58:00) [10]>DrAndrey © (23.05.07 14:18) [90]
Учту Ваши предложение
..Помнится Ві обещали пример базу отослать. Жду с нетерпением...
Сергей М. (2007-05-23 14:51:00) [11]
> ANB
Давай уже не спорить и не выяснять "истину" - оно Автору не на пользу.
Еще раз скажу лишь, что, imho, "движение товара" с т.з. торгово-складского учета, не имеет ничего общего с "оборотам по счетам" с т.з. бухучета, и месить справочник ФХ-операций со справочником движения товаров в одну кучу - тупиковый путь.
Сергей М. (2007-05-23 14:41:00) [12]
> Первый акт - 100, второй - 80. Расход 120.
При условии, разумеется, что по дате этот расход не ранее обоих приходов ?
Сергей М. (2007-05-23 14:40:00) [13]
> Какой должна быть связка ?
>
Два расходных акта: один снимает с первого приходного 100, другой со второго приходного 20.
Оба расх.акта ссылаются на один и тот же расх.документ.
Для бухгалтерии формируются миниму 2 проводки.
Проблемы не вижу.
ANB (2007-05-23 14:33:00) [14]Первый акт - 100, второй - 80. Расход 120.
Какой должна быть связка ?
Сергей М. (2007-05-23 14:26:00) [15]
> к которому из них потом подвязывать расход ?
>
К удовлетворяющему условиям принципа FIFO/LIFO.
ANB (2007-05-23 14:21:00) [16]
> Непонятки не будет, если приходный акт ссылается на партию.
А если приходный акт не один - к которому из них потом подвязывать расход ?
Сергей М. (2007-05-23 14:19:00) [17]
> ANB © (23.05.07 14:10) [89]
> я бы просто подвязал к партии и не мучился
Можно и к партии. Но это, imho, в случае Автора неоправданно усложнит реализацию.
> приход по разным документам можно сложить в одну партию.
> Тогда в цепочке возникнет непонятка
Непонятки не будет, если приходный акт ссылается на партию.
DrAndrey (2007-05-23 14:18:00) [18]>ANB © (23.05.07 12:45) [79]
>На дорогую складскую систему такая структура не тянет, т.к. там все
>сложнее намного (учитываются партии, сроки, что где лежит, условия
>хранения, есть процедуры инвентаризации и прочие полезные вещи).
Реализация описываемой структуры тоже тянет не на 100$.
Учитывая отсутствие ТЗ, неопределенность требований заказчика, отсутствие опыта у разработчика, смешную цену, неопределенную перспективу и т.д. рекомендую автору ориентироваться на максимально простой и дубовый вариант, чисто склад, никаких проводок и бухгалтерии.
Для начала набросай прототип с минимальной функциональностью и продемонстрируй заказчику. После этого многое прояснится. Готовы ли они к внедрению ПО вообще. Обязательно узнай условия эксплуатации: где будет стоять программа, кто с ней будет работать? За такую цену однозначно д/быть однопользовательская. Очень важен уровень подготовки персонала, не берись ликвидировать компьютерную безграмотность. Посмотри кто непосредственно будет сидеть за компьютером.
ANB (2007-05-23 14:10:00) [19]
> Если таки речь идет о партионном учете, то расх.акты должны
> ссылаться на приходные.
А я бы просто подвязал к партии и не мучился. По идее можно смоделировать ситуацию, когда приход по разным документам можно сложить в одну партию. Тогда в цепочке возникнет непонятка.
Впрочем, на уровне частника/мелкой торговой конторы партионный учет обычно нафиг не нужен посему я его с нуля никогда не делал - разве что в готовых системах с ним работал (а там запись о движении и подвязывали к партии).
Сергей М. (2007-05-23 13:54:00) [20]
> ANB © (23.05.07 13:43) [87]
Ты меня не понял.
Если таки речь идет о партионном учете, то расх.акты должны ссылаться на приходные. Я именно об этих связях в Справочнике движения товаров.
Иными словами, справочник движения должен иметь многокорневую древовидную структуру.