[ОТВЕТИТЬ]
Опции темы
06.07.2006 16:46  
Little
Вот тут сегодня родилось, сильно ногами не бить, но работает быстрее супермажного отчета.
Вычисление остатков в производстве на дату:
Код:
SELECT   tr, trn, art, artn, (SUM (pr1) + SUM (pr2) - SUM (rh1) - SUM (rh2)), max (mb)
    FROM (
          SELECT ca1.tree tr, ca1.NAME trn, c.article art, c.NAME artn,
                 0 pr1, 0 pr2, 0 rh1, 0 rh2, c.MESABBREV mb
            FROM supermag.smcard c,
                 supermag.sacardclass ca1,
                 supermag.sacardclass ca2
           WHERE ca1.tree LIKE :smrgroup
             AND c.idclass = ca1.ID
             AND ca2.tree = SUBSTR (ca1.tree, 1, INSTR (ca1.tree, '.'))
          UNION ALL
          SELECT   ca1.tree tr, ca1.NAME trn, c1.article art, c1.NAME artn,
                   SUM (psp.altquantity) pr1, 0 pr2, 0 rh1, 0 rh2, '' mb
              FROM supermag.smprodexpspec psp,
                   supermag.smdocuments d,
                   supermag.smcard c1,
                   supermag.sacardclass ca1,
                   supermag.sacardclass ca2
             WHERE psp.docid = d.ID
               AND psp.doctype = d.doctype
               AND d.doctype = 'PE'
               AND d.createdat <= :smrdatestart
               AND d.docstate = 3
               AND d.locationfrom = :smrstoreloc
               AND c1.article = psp.artingredient
               AND c1.idclass = ca1.ID
               AND ca1.tree LIKE :smrgroup
               AND ca2.tree = SUBSTR (ca1.tree, 1, INSTR (ca1.tree, '.'))
          GROUP BY ca1.tree, ca1.NAME, c1.article, c1.NAME
          UNION ALL
          SELECT   ca1.tree, ca1.NAME, c.article, c.NAME, 0,
                   SUM (sp.quantity), 0, 0, ''
              FROM supermag.smdocuments d,
                   supermag.smspec sp,
                   supermag.smcard c,
                   supermag.sacardclass ca1,
                   supermag.sacardclass ca2
             WHERE d.ID = sp.docid
               AND d.doctype = sp.doctype
               AND d.docstate > 1
               AND d.doctype = 'PD'
               AND d.createdat <= :smrdatestart
               AND d.LOCATION = :smrstoreloc
               AND sp.article = c.article
               AND c.idclass = ca1.ID
               AND ca1.tree LIKE :smrgroup
               AND ca2.tree = SUBSTR (ca1.tree, 1, INSTR (ca1.tree, '.'))
          GROUP BY ca1.tree, ca1.NAME, c.article, c.NAME
          UNION ALL
          SELECT   ca1.tree, ca1.NAME, c.article, c.NAME, 0, 0,
                   SUM (sp.quantity), 0, ''
              FROM supermag.smdocuments d,
                   supermag.smspec sp,
                   supermag.smcard c,
                   supermag.sacardclass ca1,
                   supermag.sacardclass ca2
             WHERE d.ID = sp.docid
               AND d.doctype = sp.doctype
               AND d.docstate = 3
               AND (d.doctype = 'PN' OR d.doctype = 'PO')
               AND d.createdat <= :smrdatestart
               AND d.locationto = :smrstoreloc
               AND sp.article = c.article
               AND c.idclass = ca1.ID
               AND ca1.tree LIKE :smrgroup
               AND ca2.tree = SUBSTR (ca1.tree, 1, INSTR (ca1.tree, '.'))
          GROUP BY ca1.tree, ca1.NAME, c.article, c.NAME
          UNION ALL
          SELECT   ca1.tree, ca1.NAME, c.article, c.NAME, 0, 0, 0,
                   SUM (psp.quantity), ''
              FROM supermag.smdocuments d,
                   supermag.smprodactspecin psp,
                   supermag.smcard c,
                   supermag.sacardclass ca1,
                   supermag.sacardclass ca2
             WHERE d.ID = psp.docid
               AND d.doctype = psp.doctype
               AND d.docstate > 1
               AND d.doctype = 'PD'
               AND d.createdat <= :smrdatestart
               AND d.LOCATION = :smrstoreloc
               AND psp.article = c.article
               AND c.idclass = ca1.ID
               AND ca1.tree LIKE :smrgroup
               AND ca2.tree = SUBSTR (ca1.tree, 1, INSTR (ca1.tree, '.'))
          GROUP BY ca1.tree, ca1.NAME, c.article, c.NAME)
GROUP BY tr, trn, art, artn
Если у кого появится конструктивная критика буду рад. Да сразу говорю, что остатки между цехами не собирался различать, поэтому и не рассматриваю их.
 
06.07.2006 16:54  
OlegON
Ты бы озвучил еще, что это из Репортера... А то многие в тупик попадут от переменных...
 
06.07.2006 17:01  
Little
Цитата:
Сообщение от olegon
Ты бы озвучил еще, что это из Репортера... А то многие в тупик попадут от переменных...
А какая разница в принципе, как называются параметры, хоть 1, 2, 3 Но в принципе вот описание параметров
:smrdatestart - дата включая которую будут рассчитаны остатки
:smrgroup - группа классификатора товара, задается в виде параметра tree таблицы sacardclass, или проще говоря, как мы видем в карточках товара 1.2.3 только надо писать 1.2.3.%
:smrstoreloc - id места хранения (магазина) к которому у нас прикреплен производственный участок
 
07.07.2006 17:33  
Jameson
У нас производство, но геморой полнейший. Главное - невозможно заставить людей записывать, что к ним пришло и в каком количестве. Да и забить около двух сотен рецептов (точнее, объяснить, как забить) - ужас. А частично забивать бесполезно, да это и не вина СМ. Пока шлепаем приходные, а ингредиенты списываем инвентаризацией.
 
07.07.2006 17:41  
akonev
это еще пол-беды. вот когда доходит до записи сколько израсходовали и сколько из этого чего получилось - тут и приходит катастрофа. отличная иллюстрация для давнишней сентенции: "автоматизация хаоса не дает ничего, кроме автоматизированного хаоса" *04
 
07.07.2006 17:51  
Little
Цитата:
Сообщение от Jameson
У нас производство, но геморой полнейший. Главное - невозможно заставить людей записывать, что к ним пришло и в каком количестве. Да и забить около двух сотен рецептов (точнее, объяснить, как забить) - ужас. А частично забивать бесполезно, да это и не вина СМ. Пока шлепаем приходные, а ингредиенты списываем инвентаризацией.
Могу сказать,что у меня цех выпускает порядка 560 наименований продукции + к этому еще куча полуфабрикотов. Иничего работают.
Главное изначально поставить правильно процесс, забить как можно подробнее рецепты. Если Вы в салатах используете вареную картошку, то ее надо сначала отварить, потом почистить и только потом запихнуть в салат. Иначе у вас потом может случиться ситуация, когда будут пересмотрены проценты потерь, а исправлено не во всех рецептах.
Рекомендую не откладывать в долгий ящик по ведению документооборота, иначе сможете очень многого не досчитаться.. Тут хотя бы появляется наглядность, что и куда ушло.. И где народ перекладывает или еще чего хуже....
 
22.10.2007 06:16  
LissA
Ко мне пристали начальствующие субъекты с этим вопросом: а можно ли организовать суммовой учет в программе?
Люди добрые, я не могу понять, каким образом можно организовать суммовой учет в программе с количественным учетом товаров?
Аргументируют это тем, что ничего у них не списывается, зависают непонятные остатки (хотя на самом деле виновны они в этом сами).
Ну ладно, будут они по сумме учитывать приходы/расходы в производстве чисто для себя. Проведя ревизию, при абы-какбы ведении документов и оставляя без внимания остатки, что же они увидят в остатках??? и какой будет остаток товаров учетный?
В общем, у меня представление такое: ведут себе на бумажке приход, расход в суммах, и считают остаток по последним ценам прихода.

Поделитесь опытом общения с бухгалтерами, please
 
22.10.2007 08:30  
akonev
только мое мнение. могу в чем-то ошибаться.

учет и так идет количественно-суммовой. но в закупочных ценах.
что, кстати, для производства есть вариант единственно правильный.

люди пытаются бороться со следствием не видя причин.

самый прямой путь к уезжанию остатков:
по рецепту (и калькуляции, соответсвенно) надо взять 12 яиц на 20 булочек, к примеру.
вместо этого берется 10, остальное доливается водой.
делаем выход 20 булочек. согласно калькуляции формируется акт производства и списывается 2 лишних яйца. они уходят на излишек.
или наоборот. или не яйца, а мука и что угодно еще...
есть всего два способа борьбы:
1) строго соблюдать рецептуру и действующие калькуляции
2) каждый день (вечер) подгонять калькуляции под реальный расход продуктов для получения реального количества продукции (сегодня мы сделали 24 булочки, на них потратили 14 яиц; забиваем это все в сегодняшнюю калькуляцию)

это погрешность, которую в рамках СМ по другому вывести не получается.
если не готовы на строгий учет - его надо вообще выводить из СМ.

еще одна специфичная именно для СМ ошибка в учете производства:
когда в рецепте используются полуфабрикаты, забывают в калькуляциях ставить галочку полуфабрикат. тогда на этот полуфабрикат не формируется акт производства. получается, что полуфабрикат берется из воздуха. он уходит в минус, ингридиенты подвисают на остатках.

ну и ошибка, не зависящая от СМ: ингридиенты взяли со склада, но не сделали расход на производство; наоборот, продукцию отдали, но не сделали выход.

резюме: производство в СМ можно использовать только при строгом документальном оформлении всего процесса. если такой возможности нет - надо производство из СМ убирать. некоторые производственники просто в голову не могут уложить идею строгого учета ингридентов.
делать суммовой учет без строгого документирования количественных движений в СМ - сложнее, чем считать все руками. точнее, это просто бред :)

ну или смириться с тем, что остатки будут ползти и выводить их еженедельными ревизиями по производству. на мой взгляд - лучше уж совсем производство не вести, чем так.

можно, конечно, попытаться выгружать в бухгалтерию расходы на производство и выходы в розничных ценах и на этом основании строить суммовой учет. но упрешься в переоценки.
 
22.10.2007 10:22  
Shiba
Цитата:
Сообщение от AlexLog
А у нас такое производство что даже через 10 лет надежды нет... белорусы мы... не обидели высшие силы катаклизмами, так есть другое... *11 , но ниче, прарвемси !
А в чем проблема? Или "Гедымина" мало?
 
22.10.2007 12:20  
AlexLog
Гедемина - выше крыши ! Движок только там названьице имеет "Дятел". Раскочегарить его ну никак ... ни хорошее железо ни помогает, ни настроек почти никаких....
 
 


Опции темы



Часовой пояс GMT +3, время: 20:43.

Все в прочитанное - Календарь - RSS - - Карта - Вверх 👫 Яндекс.Метрика
Форум сделан на основе vBulletin®
Copyright ©2000 - 2016, Jelsoft Enterprises Ltd. Перевод: zCarot и OlegON
В случае заимствования информации гипертекстовая индексируемая ссылка на Форум обязательна.