| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Посоветуйте, как
Imshanya © (2003-02-05 16:50:00)Уважаемые Мастера!!!
Посоветуйте, как "строить" склад по системе FIFO ???
Конкретно, интересует вот что:
1.Для каждой строки в приходной накладной необходимо получить
информацию, на какие строки в расходных накладных "ушел" товар
и в каком количестве.
2.Задача, обратная 1:
Определить, с каких приходных накладных произведено
данное списание?
Буду признателен за помощь и
приношу извинения за очень размытую постановку вопроса.
MsGuns (2003-02-06 16:19:00) [1]>Imshanya (06.02.03 16:13)
>Тут месяц назад один кекс спрашивал то же самое: тишина стояла гробовая!
Ему тож повезло. Могли ведь забить. Ногами ;))))
Imshanya (2003-02-06 16:13:00) [2]Да уж точно повезло. Тут месяц назад один кекс спрашивал то же самое: тишина стояла гробовая!
Еще раз всем спасибо !
MsGuns (2003-02-06 16:09:00) [3]Я тоже хочу поблагодарить BlackTiger и passm © за весьма содержательную беседу. Давно так душевно и, главное, без тупых наездов (не считая собственного ;(), исключительно конструктивно и "в мозги" не общался ! И не только на Форуме.
Спасибо огромное, ребята и успехов вам в нашем нелегком труде.
>Imshanya (06.02.03 14:05)
Ну повезло ж тебе, дружище ;))
Присоединяюсь к BlackTiger (06.02.03 14:48)
BlackTiger (2003-02-06 14:48:00) [4]>Imshanya
Ну и тебе успехов! Не напори косяков, а то потом по голове получишь от заказчика.
passm (2003-02-06 14:24:00) [5]BlackTiger (06.02.03 13:22)> Просто у нас склад - часть торговой системы. Товар покупаем, назначаем собственную цену, затем списываем, перемещаем, продаем оптом и в розницу...
Нагрузка на АРМ "Склад" здесь небольшая - заполнение фактического количества товара и отгрузка документа, либо отправка документа, если не понравился, обратно менеджеру. А так же прием данных из удаленных точек.
ЗЫ: Сейчас эта система работает: файл-сервер + FoxPro. Со временем появились проблемы с объемами и с крупными изменениями. Теперь перевожу все это на Delphi + DB2. Практически от старой системы остается только схема работы.
Imshanya (2003-02-06 14:05:00) [6]Н У Н А Р О Д!!!
О Г Р О М Н О Е С П А С И Б О !!!
У Д А Ч И В А М В С Е М И З Д О Р О В Ь Я !!!
P.S. Кажется это Аншлаг...
BlackTiger (2003-02-06 13:22:00) [7]Хммм, если этого товара не было на складе, то его "складская" цена равна закупочной. Всегда цена товара на складе "на сейчас" - средневзвешанная, значит, если такой товар уже есть на складе и я нахожу "вруг" еще такой же - я просто делаю поставку/коррекцию и пересчитываю его средневзвешанную цену "на сейчас".
Такая схема использовалась в предыдущих версиях системы, с которой я сейчас работаю. Сейчас они отказались от нее из-за большого геморроя и противоречивости их же идеологии и перешли на более навороченный вариант (офигенная гибкость, но и требования тоже здорово подросли). Им легче - у них есть несколько интересных патентов для ускорения расчетов (типа, подсчет суммы по выбранным записям ДВУМЯ(!!!) обращениями к базе, кто знает - тот узнает эту систему). Да и базу они используют собственной разработки, хотя есть и MSSQL-вариант. Самое смешное - на MSSQL ааааафигенно падает производительность по сравнению с родной базой.
А, вообще, склад - далеко не самая простая задача, чистая бухгалтерия куда проще, а самая сложная задача - производство.
И умиляют меня всякие "системы ведения склада и печати платежек", которые выкладываются на всяких shareware/freeware-серверах.
passm (2003-02-06 12:59:00) [8]BlackTiger (06.02.03 12:45)>
> Насчет "пересортиц" и "вдруг найденного товара". Ну нашли,
> ну определили стоимость, ну и что? Есть два варианта - возврат
> поставщику "некорректного" товара и получение правильных
> документов или приход-коррекция за счет счета Главной Книги
> "результаты инвентаризации/коррекции склада" - "приход ниоткуда".
Для определения стоимости есть переоценка. Но это определяет внутренюю цену. Привязка к виртуальной поставке служит для определения внешней/закупочной цены товара. По здравому смыслу - IMHO, бред. Но бухгалтерия - дело тонкое :)
passm (2003-02-06 12:52:00) [9]MsGuns © (06.02.03 12:34)> Да все нормально! Не чувтствую себя отрезанным от мира - у нас сейчас сеть маршруток хорошая. За 30-40 мин до Тулака довезут.
Домики не видел - нет у нас дачи. Вместо дачи - рынок в 2 мин ходьбы :)
Летом арбузы, абрикосы... :)~ Впрочем, Украина - тоже не север. Верно?
ЗЫ: Скоро, наверняка, модератор придет...
BlackTiger (2003-02-06 12:45:00) [10]Насчет базы данных - это да, не для Парадокса оно. Такие системы вообще никогда не используют файл-серверные базы (1Сы не в счет, хотя у них, вроде, есть SQL-вариант) - надо что-то по-серьезней. Хотя если объем данных планируется небольшой (всегда очень сложно определить) - сойдет. Можно еще предусмотреть "упаковку" записей - проводки по складу за определенный период упаковываются в один общий документ по определенному критерию, а детальная информация сбраывается в архив.
Насчет "пересортиц" и "вдруг найденного товара". Ну нашли, ну определили стоимость, ну и что? Есть два варианта - возврат поставщику "некорректного" товара и получение правильных документов или приход-коррекция за счет счета Главной Книги "результаты инвентаризации/коррекции склада" - "приход ниоткуда".
softmaster (2003-02-06 12:40:00) [11]Всем привет!
так я не до конца понял- если делать связи- то при расходе со склада надо указать пользователю с какого приходного документа списать- так что ли?
MsGuns (2003-02-06 12:34:00) [12]>passm © (06.02.03 12:28)
>ЗЫ: Знаю, конечно! У меня есть друзья из Тулака. Но я живу в другой стороне города - на Спартановке с 97 года. Раньше жил в области - в далеком тихом хуторке :)
Ох, и занесло ж тебя ! У моей сестренки там дача недалеко. Был в прошлом году в гостях,- поехали на дачу - какие, блин, домишки у вас там недалеко от Спарты понастроили ! Есть даже с крытым бассейном.
passm (2003-02-06 12:28:00) [13]MsGuns © (06.02.03 12:13)> Нет, AFAIK, у нас в бухгалтерии на этот счет все чисто. Просто, поскольку эта ситуация теоретически возможна, то ее надо обыграть. Например, приняли товар, все довольны. Но вдруг выясняется, что подложили что-то очень похожее, но не то. Есть два варианта - выяснять ситуацию с поставщиком или провести инвентаризацию.
Не хочу сказать, что у нас постоянно происходят пересортицы. Но если это теоретически возможно, то надо обыграть.
ЗЫ: Знаю, конечно! У меня есть друзья из Тулака. Но я живу в другой стороне города - на Спартановке с 97 года. Раньше жил в области - в далеком тихом хуторке :)
MsGuns (2003-02-06 12:13:00) [14]>passm © (06.02.03 11:42)
Алексей, мы, кажется, плавно переходим от белой бухгалтерии к черной ;)). Такая схема "отмывания" черного товара применялась года 2-3 назад. Сейчас так делают только уж совсем отчаянные "бизнесмены", к тому же совершенно не знакомые с налоговым законодательством и основами бухучета. Да и не один нормальный завскладом не примет на себя ни одного гвоздя без документа.
PS А мы, оказывается, земляки ! Я в Сталинграде жил до 74г, когда и уехал на Украину учиться. С тех пор там и обитаюсь.
А моя сестичка с семьей и матушка до сих пор живут на Тулака. Знаешь, где это ?
passm (2003-02-06 11:42:00) [15]MsGuns © (06.02.03 11:27)> Кажется, я не совсем ясно изложил свои мысли. Представь:
Товара N никогда не было на складе. Его нашли по инвентаризации, значит надо определить приходную цену. Для этого формируют виртуальную внешнюю поставку от такого-то клиента по такой-то цене, но количество = 0. Таким образом, количественный приход произошел именно по инвентаризации, но для определения закупочной цены этот приход привязан к виртуальной поставке, по которой, повторюсь, было приходовано количество 0.
MsGuns (2003-02-06 11:34:00) [16]Кстати, написал n-й пост, а потом попристальнее взглянул на сабж, а там явственно написано - ПАРАДОКС. Так вот, для Парадокса, особенно для многопользовательского приложения, метод привязки движения к приходам, ИМХО, обречен на сомнительную надежность и уж совсем отвратно масштабируем, т.к. практически не поддерживает нормальные транзакции. Я бы или строил систему все-таки на карточках (не требует сложных запросов и работает единичными табличными модификациями, т.к. вся логика "на клиенте") или выбрал бы нормальную клиент-серверную СУБД ("жар-птицу", ИМХО).
MsGuns (2003-02-06 11:27:00) [17]>passm © (06.02.03 11:05)
Тигр прав. Любые недостачи-излишки, выявленные при инвентаризации, можно и лучше всего учитывать именно приходом (со знако мплюс или минус). Вот в этом я абсолютно уверен. Тем более, что прекрасно согласуется с бухучетом, т.к. просто "ложится" на счеты. В том числе и по "средним" ценам.
passm (2003-02-06 11:05:00) [18]BlackTiger (06.02.03 10:56)> Не-е надо. Чтобы не портить отчетность.
В конце отчетного периода расчитываются, например, средневзвешенные закупочные цены. Если "нашли" товар ХХХ, куда-то его отправили, а потом продали. Всю картину портит.
Особенности работы бухгалтерии, однако.
MsGuns (2003-02-06 11:04:00) [19]Тигр, спасибо за объяснение. Действительно, такая система имеет несколько очевидных плюсов, в частности нет "завязок" на одну цену сб-сть (т.е.необходимости заводить новую позицию в ценнике на тот же товар, если он пришел с другой ценой), удобство при выборе позиции товара при отпуске (выписке счета) и т.д.
Отпадает необходимость ведения картотеки (у меня, в частности, все системы строятся именно на ней).
Единственный прокол - я не понял, как ни размышлял, как решается при такой системе проблема резервирования товара. Объясни, если не трудно.
jocko (2003-02-06 11:03:00) [20]?????????????!!!!!!!!!!!!!!!!!!!
>Продолжать? Я имею ввиду большие системы к которых склад и >бухгалтерия стоит уже на ВТОРОМ месте, а не поделки, >типа "склад и бухгалтерия - два по цене одного, да еще в одном >флаконе".
| |
Страницы: 