Всю задачу рассказывать не буду, расскажу кусочек (если потребуется обрисую все сразу).
Мне нужно по н\н узнать остаток номенклатуры на складе (это продукция).
Желательно бы поуниверсальнее решение, вне зависимости от партионности. И по всем складам...
Пути решения?
Само собой интересует что-нибудь более просто, чем "шерстить" картотеку складского учета и "считать" остаток по данной номенклатуре. При большом количестве н.ед. такой алгоритм будет долго работать...
Я просто себе представляю, что необходимо суммировать все партии (смотреть каждую)...
Обнаружил некую "сводную запись" в картотеке, которая точно показывает сумму остатка даннойго Н\Н. Хотелось бы услышать что-либо по поводу этого момента... Можноли этой записью пользоваться и как?
Саак, вы обнаружили запись сводной карточки! Конечно ей пользоваться можно, однако нужно иметь ввиду:
-- это остатки на данный момент а не на произвольную дату
-- при нарушении правильности значений в сводных карточках можно воспользоваться пересчетом остатков по картотеки [Alt-F10]
Евгений Плешивцев пишет:
Саак, вы обнаружили запись сводной карточки! Конечно ей пользоваться можно, однако нужно иметь ввиду:
-- это остатки на данный момент а не на произвольную дату
-- при нарушении правильности значений в сводных карточках можно воспользоваться пересчетом остатков по картотеки [Alt-F10]
А как к ней обратиться, собственно... Зная н\н (и группу тоже)...
Чем принципиально данная запись отличается от остальных? Единственное, что заметил - это отсутствие инф о партии...
Какой индексный ключ использовать?
И еще я так понимаю, эта карточка не содержит в себе сумму остатков на разных складах?
Я использую индекс MKART и в строке фильтра прописываю "Empty(Partia) .And. !Empty(NNum)"
А вообще то, крутые пацаны, уже давно остатки по банку данных собирают
Евгений Плешивцев пишет:
Я использую индекс MKART и в строке фильтра прописываю "Empty(Partia) .And. !Empty(NNum)"
А вообще то, крутые пацаны, уже давно остатки по банку данных собирают
Ну, мне еще до крутых пацанов далеко...
Мне бы простенькую инфу выуживать по движению изделий...
Банк даныых!???
А что это? Нововведение в СП?
Очень важный - что ставиться раньше скоп или фильтр, при использовании DbPush?
Тогда представляйте себе, что на базу установлен скоп, а затем для каждой записи выполняется выражение фильтра. Если выражение возвращает .T., то запись показывается, если .F., то пропускается.
Алексей Новиков пишет:
Тогда представляйте себе, что на базу установлен скоп, а затем для каждой записи выполняется выражение фильтра. Если выражение возвращает .T., то запись показывается, если .F., то пропускается.
Вот! тогда исходя из моих представлений ответ все-таки - сначала ставиться скоп, а потом фильтр ... И вот это вот сравнение идет уже после "обрубания" (скорее игнорирования остальных записей)...
Алексей Новиков пишет:
На самом деле я, лично, не знаю, как это реализовано в драйвере dbf/cdx. Может и так, может иначе. Но результат от реализации не зависит.
Э... Но как же не зависит еще и как зависит!!!!
Само собой речи о том, что изменяться отображаемые записи речи нет...
Речь о производительности, скорости работы кода....
Сначала фильтровать, а затем "одним махом обрубать" будет много много медленнее, чем сначала "одним махом обрубать". а затем в обрубленном каждую запись смотреть....
Согласитесь разница огромная.... Да и этот не к драйверу dbf, а к работе DbPush
В Б-5 есть специальная таблица где хранятся итоговые за день остатки и движения но каждому НН если у него в этот день было движение.
Банк данных обновляется одновременно с расчетом с/с по товарам / материалам
Коллеги прерву Ваш спор.
1. Банк данных надо рассчитывать. Просто оттуда брать на мой взгляд не есть гуд.
2.По причине аналогичной п.1 брать из картотеки тоже не есть гуд. При интенсивной работе сети там значение может "плыть"
3.Если интерес к пункту 2 сохранен и ответ не полный готов описать
(дискуссию всю внимательно не смог осилить)
4.Рассчитать остатки по н.н. для БЭСТа плевое дело после наложения скопа. Всякий раз Вы это делаете когда в картотеке жмете F10.
Уже многим любителям доказывал что для скажем тысячи строк это достаточно быстро. И пока именно этот способ в некоторых своих задачах продолжаю считать самым правильным и самым точным ИМХО.
Саак Шахламджян пишет:
считать" остаток по данной номенклатуре. При большом количестве н.ед. такой алгоритм будет долго работать...
Повторюсь - вот это заявление не есть факт.
На 2 Гб таблице у меня расчет меньше сек. на локальном компе.
Если задача сводится к расчету только по одной позиции, то
это не может составлять проблему.
Недостаточно информации по контексту задачи
nordk пишет:
Цитата Саак Шахламджян пишет:
считать" остаток по данной номенклатуре. При большом количестве н.ед. такой алгоритм будет долго работать...
Повторюсь - вот это заявление не есть факт.
На 2 Гб таблице у меня расчет меньше сек. на локальном компе.
Если задача сводится к расчету только по одной позиции, то
это не может составлять проблему.
Недостаточно информации по контексту задачи
Имелось ввиду получить данные по 100-200 номенклатурным единицам (не более 500).
Так, а Вы что же это считате разве? (суммируете все партии между собой)
Я уже написал плагин. Использовал то, что дал Евгений. Обращаюсь сразу к "сводной карточке", всё довольно быстро делается... Т.е. считать ничего не надо... (Я так написал, т.к. думал, что придётся суммировать все партии на складах, не зная еще о "сводной карточке")
Все так, но следует помнить что цифра сводной карточки может быть ошибочной. Вспоминая Вашу любовь к точности и дотошность - сразу предупреждаю. Цифра легко уточняется утилитой пересчета остатков.
С таким же успехом можно и банк данных пересчитывать....
На 200-300 думаю что расчет банка данных будет оптимальным подходом,
как предлагал Евгений.
Но я в своих задачах делаю расчеты сам
Для ассортимента в 180 000 и с объемом таблицы mdocm в 2 Gb
в БЭСТ-4+ именно мой расчет длится 40 минут.
Сколько будет считать банк данных на БЭСТ-5 надо проверять.
Но тут надо отдать должное. Банк данных считает не только
остатки, но и много других любопытных аналитических разрезов.
И после его расчета можно использовать огромное количество
различных отчетов и анализов. В этом плане он интересен.
Тут опять все очень и очень зависит от контекста задачи.
nordk пишет:
Все так, но следует помнить что цифра сводной карточки может быть ошибочной. Вспоминая Вашу любовь к точности и дотошность - сразу предупреждаю. Цифра легко уточняется утилитой пересчета остатков.
С таким же успехом можно и банк данных пересчитывать....
Об этом в курсе и помню :) Данные не смертельны...
Цитата
nordk пишет:
На 200-300 думаю что расчет банка данных будет оптимальным подходом,как предлагал Евгений.
Банк данных отдельно покупается, кроме всего прочего...
А, к стати по поводу общей задачи. Думаю, есть смысл её озвучитиь.
Попробую её кратенько обрисовать...
Ситуация:
У нас есть НЕСКОЛЬКО заказов на продукцию от ОДНОГО заказчика.
Как узнать какие позиции этих заказов уже готовы?
Т.е. приехала машина от нашего партнера, её загрузили чем планировали, но, допустим на месте решили еще чем-нибудь её набить. Чтобы узнать чем набить, надо знать что есть в наличии на складе именно для этого заказчика...
(Заказы в данном случае сводные...)
А вот тут не простой.
А именно.
Само производство не выпускает продукцию в разрезе заказа.
Т.е. когда мы делаем выпуск изготовленное изделие не имеет
отношения ни к какому заказу.
И отсюда .
Просто остаток на складе смотреть не гуд - а если эта же позиция изготавливается под другого заказчика и ему надо срочно. Вы отдали чтобы набить машину, потому что изделие на складе появилось, а тот другой остался не у дел.
Но если идти от остатка.
Получается у вас клиент ждет еще ассортимент из 200-300 позиций для изготовления под него ? Так ?
Банк данных отдельно покупается, кроме всего прочего...
Тут нужно пояснить не совсем очевидную вещь: Банк данных (БД) в Б-5 представлен двумя элементами:
-- Интерфейсная часть для работы пользователя с агрегатированными данными
-- функции и механизмы по агрегатированию данных
так вот, сама суть БД - функции и механизмы а так же специальные таблицы хранения поставляется с Б-5 всегда и бесплатно, и у вас Саак эта часть тоже есть и отлично работает. А в прайсе заявлена цена за интерфейсную часть для коечного пользователя: там реестры в разных видах, анализы и оценки, экспорты...
Банк данных требует регулярного досчета, точнее, после любого движения, информация по движущемуся НН будет не верна начиная с даты движения. Как делать досчет? Два варианта:
-- посчитать себестоимость. Расчет с\с считает и БД
-- сформировать любой отчет Б-5 из папки "Отчеты по банку данных"
Как попробовать этот режим? Постройте сводную оборотную ведомость по документам и по БД. Сравните время. Только сперва, рассчитайте с\с.
Саак, если все это будет делаться впервые, позвоните мне.
nordk пишет:
А вот тут не простой.
А именно.
Само производство не выпускает продукцию в разрезе заказа.
Т.е. когда мы делаем выпуск изготовленное изделие не имеет
отношения ни к какому заказу.
И отсюда .
Просто остаток на складе смотреть не гуд - а если эта же позиция изготавливается под другого заказчика и ему надо срочно. Вы отдали чтобы набить машину, потому что изделие на складе появилось, а тот другой остался не у дел.
Но если идти от остатка.
Получается у вас клиент ждет еще ассортимент из 200-300 позиций для изготовления под него ? Так ?
Вы всё подметили совершенно верно, за исключением последнего.
Проблема не связанности изготовленного изделия ни с каким заказом существует в Б-5. Её можно обойти 2мя способами (на мой взгляд):
1. Сделать кодом изделия номенклатурный номер (как это сделано у нас)//на то были и другие причины...
2. "Прослеживать" изделия от заказа к изготовлению до его сдачи...
(от заказа к изготовлению такая связь прослеживается. После сдачи нет, реализовать не столь сложно, т.к. приходуется тоже плагином, но из-за 1го особой необходимости нет).
Поэтому один и тот же Н\Н не может быть для 2х разн заказчивов.
По поводу того, что висит 200-300 наименований. Нет, такого конечно же нет, их гораздо меньше! Бывают просто из большого заказа(а таких довольно много) остается "висеть" одна позиция(тоже довольно частое явление), из-за этого заказ не закрыт. Мой плагин "шерстит" все открытые заказы по заданному заказчику, отсюда может получиться (опять же чисто теоритически) до 300 шт, м\б немногим больше.
Саак Шахламджян пишет:
Вы всё подметили совершенно верно, за исключением последнего.
Проблема не связанности изготовленного изделия ни с каким заказом существует в Б-5. Её можно обойти 2мя способами (на мой взгляд):
1. Сделать кодом изделия номенклатурный номер (как это сделано у нас)//на то были и другие причины...
2. "Прослеживать" изделия от заказа к изготовлению до его сдачи...
(от заказа к изготовлению такая связь прослеживается. После сдачи нет, реализовать не столь сложно, т.к. приходуется тоже плагином, но из-за 1го особой необходимости нет).
Я хотел написать по этому поводу но прикинув что Вы хотите работать от остатка на складе, отсюда сделал вывод что Вы идете путем без учета в разрезе заказа.
Если же Вы хотите завязываться на заказ, то прослеживать весь
заказ великого смысла нет. Достаточно реализовать задачу на запись документа приема готовой продукции, которая будет определять по какому заказу будет отгрузка. Тут опять требуется много всяких НО, связанных с особенностями предприятия.
Саак Шахламджян пишет:
По поводу того, что висит 200-300 наименований. Нет, такого конечно же нет, их гораздо меньше! Бывают просто из большого заказа(а таких довольно много) остается "висеть" одна позиция(тоже довольно частое явление), из-за этого заказ не закрыт. Мой плагин "шерстит" все открытые заказы по заданному заказчику, отсюда может получиться (опять же чисто теоритически) до 300 шт, м\б немногим больше.
Дак вот надо решать , чтобы плагин шерстил ТОЛЬКО не отгруженные позиции, а их у вас единицы как я понял, а эти единицы несложно и пересчитать. И этот вяжется вплотную с контролем выпуска продукции и распределения по заказам.
Я бы таким путем рассмотрел
nordk пишет:
Цитата Саак Шахламджян пишет:
Вы всё подметили совершенно верно, за исключением последнего.
Проблема не связанности изготовленного изделия ни с каким заказом существует в Б-5. Её можно обойти 2мя способами (на мой взгляд):
1. Сделать кодом изделия номенклатурный номер (как это сделано у нас)//на то были и другие причины...
2. "Прослеживать" изделия от заказа к изготовлению до его сдачи...
(от заказа к изготовлению такая связь прослеживается. После сдачи нет, реализовать не столь сложно, т.к. приходуется тоже плагином, но из-за 1го особой необходимости нет).
Я хотел написать по этому поводу но прикинув что Вы хотите работать от остатка на складе, отсюда сделал вывод что Вы идете путем без учета в разрезе заказа.
Если же Вы хотите завязываться на заказ, то прослеживать весь
заказ великого смысла нет. Достаточно реализовать задачу на запись документа приема готовой продукции, которая будет определять по какому заказу будет отгрузка. Тут опять требуется много всяких НО, связанных с особенностями предприятия.
Тут я не до конца Вашу мысль понял.
Сейчас при приёме готовой продукции, которая осуществляется спец плагином, определить к какому заказу относиться изделие - это полдействия (у меня доп таблица есть). Т.е. можно, например, при создании партии (при сдаче ГП) указать в этой самой партии для кого она, собственно предназначена (кажется там хватает аналитик).
Как я понимаю, Вы предлагаете "смотреть" по документам сдачи ГП "готово ли изделие", я правильно понял? Если да, то ведь неадо учесть еще а не отгружено ли оно уже, т.е. "смотреть" еще и за расходными документами... (Не совсем понял что имеломсь ввиду.)
Цитата
nordk пишет:
Цитата Саак Шахламджян пишет:
Поэтому один и тот же Н\Н не может быть для 2х разн заказчивов.
Может быть - есть еще варианты внутренней аналитики
Да вариантов на самом деле двольно много. Этот тоже рассматривался. + еще у нас партионность - можно даже там использовать. Н\н у нас -это код изделия, причем одинаковый и в модуле продаж и в модуле производства, чтобы каждый в любом месте программы знал "о чем идёт речь". По этой причине вообще многое можно было бы объединить в этих модулях, но это немного не по теме сейчас...
Цитата
nordk пишет:
Дак вот надо решать , чтобы плагин шерстил ТОЛЬКО не отгруженные позиции, а их у вас единицы как я понял, а эти единицы несложно и пересчитать. И этот вяжется вплотную с контролем выпуска продукции и распределения по заказам.
Я бы таким путем рассмотрел
Само собой такая постановка задачи много много лучше. Тем более, что интерес за контролем выпуска продукции есть. Но это уже немного глобальнее задачка. У нас еще не все решено по поводу планирования, какой уж тут контроль за исполнением... Я даже на эту тему не думал. Потому как мне казалось, что данный нельзя решить отдельно от многих других, которые сейчас стоят.