Организационная структура БД

← →
Skalp (2003-05-08 12:47) [0]

Добрый день!
Отрывок из архивов форума:

// начало цитирования

Автор: BlackTiger (05.02.03 20:20)

FIFO/LIFO и "средневзвешанное" - это методы списания СЕБЕСТОИМОСТИ товара.
Идеальный вариант (так делается в серьезных западных системах) - две таблицы минимум. "Приходы + Уходы", "Связь между уходом и приходом".
Смысл 2-й таблицы в том, что ОДНО списание/уход со склада может перекрывать НЕСКОЛЬКО приходов и, в свою очередь, ОДИН приход может быть закрыт НЕСКОЛЬКИМИ уходами.
При этом разбивать уходы на несколько записей очень неудобно.

Пример:

"ПРИХОДЫ+УХОДЫ (Движение склада)"
Приход 1 - +1 шт. по 100 USD
Приход 2 - +5 шт. по 124 USD
Уход 1 - -2 шт. на сумму 224 USD (1x100+1x124).

"СВЯЗИ"
Связь 1 - "Уход 1" связан с "Приход 1", 1 шт.
Связь 2 - "Уход 1" связан с "Приход 2", 1 шт.

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

// конец цитирования

Это не дословное цитирование, я позволил себе сделать исправления опечаток (которые сам автор в дальнейшем поправил), чтобы невозникало вопросов.
Так вот, такая система ("Связь между уходом и приходом") очень удобна. Упрощает выполнение отчетов в дальнейшем, легко рассчитывать сумму себестоимости списанного товара и много других плюсов.
Но ... у меня при реализации такой системы возникает проблемы связанные с реализацией функции редактирования документов "задним числом".
Понятно, что по всем правилам такого быть не должно. Но на практике очень часто встречается такая необходимость и пользователю надо позволить это сделать.
Но тогда возникает необходимость сложной обработки таблицы "СВЯЗИ".
Прошу простить, за псевдо представление таблиц, но я думаю что все понятно.
Представьте такую ситуацию:

"ПРИХОДЫ+УХОДЫ (Движение склада)"
Приход 1 - Груша - +5 шт. по 50 USD
Приход 2 - Груша - +20 шт. по 60 USD
Уход 1 - Груша - 1 шт. ( на сумму 50 USD (1x50).)
Уход 2 - Груша - 1 шт. ( на сумму 50 USD (1x50).)
Уход 3 - Груша - 1 шт. ( на сумму 50 USD (1х50).)
Уход 4 - Груша - 1 шт. ( на сумму 50 USD (1х50).)
Уход 5 - Груша - 10 шт.( на сумму 590 USD (1х50 + 9х60).)

"СВЯЗИ"
Связь 1 для ГРУША - "Уход 1" связан с "Приход 1", 1 шт.
Связь 2 для ГРУША - "Уход 2" связан с "Приход 1", 1 шт.
Связь 3 для ГРУША - "Уход 3" связан с "Приход 1", 1 шт.
Связь 4 для ГРУША - "Уход 4" связан с "Приход 1", 1 шт.
Связь 5 для ГРУША - "Уход 5" связан с "Приход 1", 1 шт.
Связь 6 для ГРУША - "Уход 5" связан с "Приход 2", 9 шт.

Теперь допустим пользователь захотел изменить "Уход 1" с количества 1 на 10, тогда:

"ПРИХОДЫ+УХОДЫ (Движение склада)"
Приход 1 - Груша - +5 шт. по 50 USD
Приход 2 - Груша - +20 шт. по 60 USD
Уход 1 - Груша - 10 шт. ( на сумму 550 USD (5x50 + 5х60).)
Уход 2 - Груша - 1 шт. ( на сумму 60 USD (1x60).)
Уход 3 - Груша - 1 шт. ( на сумму 60 USD (1х60).)
Уход 4 - Груша - 1 шт. ( на сумму 60 USD (1х60).)
Уход 5 - Груша - 10 шт.( на сумму 600 USD (10х60).)

Тогда таблица связей должна быть переделана в:

"СВЯЗИ"
Связь 1 для ГРУША - "Уход 1" связан с "Приход 1", 5 шт.
Связь 2 для ГРУША - "Уход 1" связан с "Приход 2", 5 шт.
Связь 3 для ГРУША - "Уход 2" связан с "Приход 2", 1 шт.
Связь 4 для ГРУША - "Уход 3" связан с "Приход 2", 1 шт.
Связь 5 для ГРУША - "Уход 4" связан с "Приход 2", 1 шт.
Связь 6 для ГРУША - "Уход 5" связан с "Приход 2", 10 шт.

Были изменены ВСЕ строки в таблице связи при изменении только одной строки в таблице "ПРИХОДЫ+УХОДЫ (Движение склада)".
Тогда либо надо писать тригер, который при изменении в первой, будет редактировать 2-ю таблицу, либо хранимую процедуру, которая будет запускаться с клиента при редактировании.
А если бы уходов было бы несколько сотен? Тут представлен один товар, а если их будет несколько?
Все это усложняет реалезацию очень сильно.
Подскажите, пожалуйста, как в этом случае поступать. Как решить эту проблему?

← →
VAleksey © (2003-05-08 17:32) [1]

Насколько мне известно за рубежом просто никто ничего не делает задним числом.

← →
Serginio (2003-05-08 18:17) [2]

Мне очень нравится организация таблиц в 1С. Есть две таблицы таблица движений и таблица остатков по периодам. И расчет остатков организуется очень просто.
Посмотри http://www.1c.hippo.ru/cgi-bin/predownl.cgi?id=2019

← →
Serginio (2003-05-08 18:55) [3]

А фифо лифо элементарно организуется храня остаки Ввиде товар,ДатаВремядокумента,Документ.

← →
LordOfSilence © (2003-05-08 19:22) [4]

2 Serginio

Привет, Сергей!
Ох и достанется сейчас тебе! ;-)
Не любят здесь 1С. :-)
Кстати, зашел по ссылке и прочитал отзывы людей на твою
разработку. Они точь-в-точь такие же, что и я тебе когда-то
давно говорил в форуме и здесь, и на Территории :-).
Все, собираю манатки, на поезд и в отпуск!
Удачи тебе.

← →
Serginio (2003-05-12 12:16) [5]

2 LordOfSilence Рад тебя слышать И весело тебе отдохнуть. А организация БД в 1С очень грамотна есть чему поучиться.

← →
Skalp (2003-05-12 12:41) [6]

2 Serginio (12.05.03 12:16)
>> А организация БД в 1С очень грамотна есть чему поучиться.

А где можно (желательно в интернете) прочитать об этом?

← →
Serginio (2003-05-12 13:11) [7]

В инете не знаю все приходилось разбираться самому. В итоге создал программу которая создает объекты вокруг таблиц 1С. Ссылка на данную программу выше. А суть хранения остатков можно посмотреть через сформированный объект регистр. Правда для этого нужна установлена 1С и какая нибудь база содержащая регистры.

Организационная структура БД Найти похожие ветки