[ОТВЕТИТЬ]
13.03.2007 11:05
dmware
 
Здравствуйте!
Помогите, пожалуйста разобраться. Ситуация такая. Делаю отчет на конкретную дату: т.н. "Остатки в закупочных ценах", стандартный. Получаю результат. Далее...
Перехожу в раздел "Карточки", подраздел (закладка) Документы, выбираю артикул товара, затем дату, нажимаю перечитать. Получаю документы за указанный период времени. Есть там строчка: "Остаток на начало" - подразумевается остаток на начало дня. Данные не совпадают с тем, что представлено мне в отчете.
Почему так происходит?
Конкретные данные: задаю на 01.03. получаю остаток на начало: 5, на 02.03. - остаток на начало 3. По отчету на 01.03.: 4...
13.03.2007 11:13
OlegON
 
Хоть немножко бы форум почитал. "В закупочных ценах" подразумевает четкую связь с приходом. А ее иногда не бывает. Отчет по неустановленной себестоимости смотрим и форум на эту тему читаем.
13.03.2007 11:17
Mtirt
 
Цитата:
Целью отчета является предоставление сведений об остатках в закупочных ценах в данном месте хранения или во всех местах хранения на выбранную дату.
В отчете рассматриваются карточки складского учета типа "товар" и "тара", а также места хранения (кроме типа "офис") с отключенным признаком "отключить перерасчет остатков". Для получения остатков анализируются все документы прихода, расхода и перемещения по аналитическим таблицам с датой, не большей даты отчета.

Сведения о количестве оставшегося товара могут расходиться с отчетом "Остатки". В отчете "Остатки" анализируются не только полностью оприходованные документы, но и документы со статусом "принят на складе".
При выборе опции "детально по приходам" в отчете выводятся номера приходных документов, по которым, с точки зрения расчета товародвижения, имеется неизрасходованный остаток (остаток по партиям). Остаток товара, для которого не была установлена приходная партия, считается остатком с неопределенным приходом и помечается символом "нп" ("неустановленный приход"). Для остатка с неустановленным приходом показывается документ последнего прихода.

Для подсчета сумм с разбивкой по ставкам НДС ставки НДС берутся из документов-оснований по товародвижению.
Отчет выполняется в базовой валюте и требует предварительного расчета себестоимости.
Это из СМ2000. Доступно по кнопочке "?".
Как следствие можно предположить, что существует документ в статусе розовой галочки.
13.03.2007 13:12
dmware
 
Извините, за возможно глупые вопросы. С супермагом впервые познакомился две недели назад. К сожалению времени на нормальное изучение не было и не предвидится в ближайшее время. Моя задача сейчас заключается в написании отчета, который бы в какой-то степени дублировал стандартный отчет "остатки в закупочных ценах". Я взял за основу запрос Mtirt, определяющий остатки на конкретную дату, немного переделал его. Получил следующее:

SELECT
T.ARTICLE ARTICLE,
c.NAME, SUM(DECODE(T.DOCTYPE,
'WI', T.QUANTITY,
'WO', -T.QUANTITY,
'CR', T.QUANTITY,
'CS', -T.QUANTITY,
'IW', T.QUANTITY,
'OR', T.QUANTITY,
'CO', T.QUANTITY)) QUANTITY,
(pr.price),
prt.NAME,
NVL(d.locationto, d.locationfrom) LOCATION,
to_date('01.03.2007', 'DD.MM.YYYY') DATE_G

FROM SMSPEC t,
SMDOCUMENTS d,
SMCARD c,
SMPRICES pr,
SMPRICETYPES prt

WHERE t.doctype = d.doctype
AND t.docid = d.id
AND t.article = c.article
AND pr.article = c.article
AND pr.pricetype = prt.id

AND (c.RECEIPTOK='1'
AND pr.STORELOC IN(1)
AND nvl(d.locationto, d.locationfrom) IN(2,3,4)
AND c.ACCEPTED=1
AND prt.ID IN(2)
AND d.createdat <= to_date('01.03.2007', 'DD.MM.YYYY')
AND d.docstate >= 2
AND d.doctype IN('WI', 'WO', 'CS', 'CR', 'IW', 'OR', 'CO')
AND t.article IN('0003672'))

GROUP BY t.article, c.name, pr.price, prt.name, nvl(d.locationto, d.locationfrom) ORDER BY t.ARTICLE ASC

Все рассчитывается и совпадает с данными, указанными в упомянутой мною выше закладке Карточки-Документы. Со стандартным отчетом данные расходятся. Если я правильно понял, стандартным отчетом не учитываются документы т.с. "в статусе розовой галочки". Выставляю d.docstate >= 2, что ничего не меняет.

Поясните, пожалуйста, как ведет подсчет остатков стандартный отчет. Заранее спасибо.
13.03.2007 13:14
dmware
 
Цитата:
olegon Хоть немножко бы форум почитал. "В закупочных ценах" подразумевает четкую связь с приходом. А ее иногда не бывает. Отчет по неустановленной себестоимости смотрим и форум на эту тему читаем.
Возможно я просто не совсем корректно пояснил, что мне нужно:)
13.03.2007 13:28
Mtirt
 
dmware, себестоимость когда рассчитывалась? Просто по отчету "Остатки в закупочных ценах" есть еще одно ключевое слово АНАЛИТИЧЕСКАЯ база. Если у тебя есть документ, созданный задним числом и не вошедший в расчет товародвижения, то остатки будут отличаться.

Что касается моего запроса, то он не учитывает документ "Перемещение", который на товародвижение влияет. У меня РЦ нет, мне не актуально.
13.03.2007 13:54
dmware
 
Цитата:
Mtirt dmware, себестоимость когда рассчитывалась? Просто по отчету "Остатки в закупочных ценах" есть еще одно ключевое слово АНАЛИТИЧЕСКАЯ база. Если у тебя есть документ, созданный задним числом и не вошедший в расчет товародвижения, то остатки будут отличаться.

Что касается моего запроса, то он не учитывает документ "Перемещение", который на товародвижение влияет. У меня РЦ нет, мне не актуально.
Ну, перемещение то я добавил: тип документа IW.
Себестоимость рассчитывалась на дату более позднюю: отчет на 01, расчет себестоимости на 04...
То есть, мог "найтись" документ, который был добавлен после расчета и он теперь оказывает влияние на отображаемые для меня остатки в разделе карточки-документы?
Если я правильно понял принцип формирования стандартного отчета таким образом должен отличаться от того, что я пытаюсь делать? Т.е. определение остатков не должно быть основано на подсчете документов, и данные, которые выбираются отчетом уже хранятся где-то в одной (/нескольких) из таблиц (/таблицах)?
13.03.2007 14:00
Mtirt
 
Цитата:
dmware То есть, мог "найтись" документ, который был добавлен после расчета и он теперь оказывает влияние на отображаемые для меня остатки в разделе карточки-документы?
Если я правильно понял принцип формирования стандартного отчета таким образом должен отличаться от того, что я пытаюсь делать? Т.е. определение остатков не должно быть основано на подсчете документов, и данные, которые выбираются отчетом уже хранятся где-то в одной (/нескольких) из таблиц (/таблицах)?
Да. Все правильно. Может найтись документ.
А стандартный отчет строится по таблице ffmaprep.
13.03.2007 14:06
dmware
 
Ага, спасибо большое. А верно ли мое предположение, что в данной таблице данные обновляются после очередного расчета?
13.03.2007 14:09
dmware
 
Еще раз спасибо за ответы!
14.03.2007 12:25
dmware
 
Цитата:
Mtirt А стандартный отчет строится по таблице ffmaprep.
Пытаяюсь разобраться. Выбираю нужный мне артикул товара. Обнаруживаю, что в данной таблице нет прихода. Просмотрел FFMapOutIn и FFMapInIn в них ничего по заданным критериям не нашел:( Информацию о приходе обнаружил в отчете Товародвижение по операциям и то же самое в разделе карточки->документы
Подскажите, пожалуйста, в какой таблице можно найти информацию об этих документах.
14.03.2007 13:00
Mtirt
 
Странно. У меня все есть...
Код:
select * from ffmaprep t where t.article=:Myarticle and t.saletype='WI'
14.03.2007 13:13
dmware
 
Нашел свою ошибку. Искал сложным запросом и наложил условие SALELOCATIONFROM IN(id), где id - идентификатор нашего магазина. Однако совсем упустил из виду, что для документов WI нужно проверять поле SALELOCATIONTO, поскольку это приход в магазин...
Теперь осталось собрать все в кучу:)
Спасибо!
15.03.2007 14:00
dmware
 
Обнаруживаю нечто непонятное. Сверяю количество проданного товара по идентификатору документа в разделе карточки->документы. Нахожу конкретный документ, напротив которого количество 5. Продажи по кассе - CS. Однако если верить таблице ffmaprep было продано 10 единиц такого товара по данному документу. Как такое может быть? Чему верить?
15.03.2007 14:16
Mtirt
 
Ты не то поле анализируешь. Он просто показывает, что эти продажи привязаны к разным приходным накладным по ФИФО. Проанализируй поля Quantity,SaleQ, IncomeQ. Найдешь свои 5 штук....
15.03.2007 14:40
dmware
 
Обнаружились две записи по данному документу. Количеством 5, но приходные документы разные.
Что в данной ситуации произошло на самом деле: реальное количество проданного товара - 5 единиц, так? Просто он из разных партий? Т.е. пришел по разным накладным?
16.03.2007 11:19
dmware
 
Извините за может быть простой вопрос.
Подскажите пожалуйста, как проигнорировать эти самые дополнительные записи для товаров из разных приходов?
Бьюсь уже очень долго(, а результат увы...
Т.е. к примеру такие записи как:
SaleID IncomeID Quantity
--1----------12--------5
--1----------14--------5
Нужно подсчитать лишь один раз.
Например,
SELECT DISTINCT SALEID, SUM(DECODE(SALETYPE,
'WO', -Saleq,
'CS', -Saleq,
'IW', Saleq,
'IL', Saleq
)) Quantity
FROM FFMAPREP
WHERE SALETYPE IN('WO', 'CS', 'IW', 'IL')
AND ARTICLE='0003672'
AND SALEDATE < to_date('01.03.2007', 'DD.MM.YYYY')
AND nvl(SALELOCATIONFROM, SALELOCATIONTO) IN(6)
GROUP BY SALEID;
Все равно считает эти записи по два раза. Каким образом делается подобное?
16.03.2007 12:05
Mtirt
 
Посмотри вот это
Код:
SELECT STORELOC,
                       ARTICLE,
                       INCOMEID,
                       MAX(INCOMECLIENTINDEX) CLIENTINDEX,
                       MAX(INCOMEQ) DOCQUANTITY,
                       MAX(INCOMESUM) DOCSUM,
                       SUM(QUANTITY) QUANTITY from ffmaprep
16.03.2007 13:05
dmware
 
1. поля storeloc нет в таблице ffmaprep (там SALELOCATIONFROM, SALELOCATIONTO)
2. max - похоже действительно то, что нужно. возвращает наиболшее значение, но поскольку содержимое полей будет совпадать у документов с одним и тем же saleid, то возвращается единственное значение.
сейчас попробую переделать запрос, спасибо!
16.03.2007 14:34
deucel
 
поставь rectype = '1'
*04
16.03.2007 15:37
dmware
 
а это что будет значить?
19.03.2007 08:11
dmware
 
Помогите пожалуйста собрать все вместе. В одном из полей соответственно нужно подсчитывать остатки: ПРИХОД - РАСХОД. Делаю так:
SUM(MAX(INCOMEQ) - MAX(SALEQ)). Выдает групповая функция не является одногруппной...
Как мне получить разность между выражениями MAX(INCOMEQ) и
MAX(SALEQ) в одном запросе?

Весь запрос целиком:
SELECT
FFMapRep.ARTICLE ARTICLE,
SMCARD.NAME,
SUM(MAX(INCOMEQ) - MAX(SALEQ)),
(pr.price),
prt.NAME,
NVL(FFMapRep.Salelocationto, FFMapRep.Salelocationfrom) LOCATION,
to_date('01.03.2007', 'DD.MM.YYYY') DATE_G

FROM
FFMapRep,
SMDOCUMENTS,
SMCARD,
SMPRICES pr,
SMPRICETYPES prt

WHERE
FFMapRep.ARTICLE = SMCARD.ARTICLE
AND FFMapRep.Saletype = SMDOCUMENTS.doctype
AND FFMapRep.Saleid = SMDOCUMENTS.id
AND FFMapRep.article = SMCARD.article
AND pr.article = SMCARD.article
AND pr.pricetype = prt.id

AND (SMCARD.RECEIPTOK='1'
AND pr.STORELOC IN(1)
AND nvl(FFMapRep.Salelocationfrom, FFMapRep.Salelocationto) IN(6, 12)
AND SMCARD.ACCEPTED=1
AND prt.ID IN(2)
AND FFMapRep.Saledate < to_date('01.03.2007', 'DD.MM.YYYY')
AND SMDOCUMENTS.docstate = 3
AND FFMapRep.article IN('0003672'))

GROUP BY FFMapRep.article, SMCARD.NAME, pr.price, prt.name, nvl(FFMapRep.Salelocationto, FFMapRep.Salelocationfrom)
ORDER BY LOCATION ASC
19.03.2007 08:21
Mtirt
 
Во внешнем запросе - Sum, во внутреннем - Max. Добавь еще одну группировку...
19.03.2007 08:24
dmware
 
Цитата:
Mtirt Во внешнем запросе - Sum, во внутреннем - Max. Добавь еще одну группировку...
Извини, не совсем понятно, каким образом) А разве здесь не так?
SUM(MAX(INCOMEQ) - MAX(SALEQ))
Сначала sum, затем max.
19.03.2007 08:26
Mtirt
 
2 запроса. Один внутри другого.
а у тебя 2 функции.
19.03.2007 08:35
dmware
 
Если я правильно понял, что-то вроде:
(SUM(
(SELECT
MAX((INCOMEQ))
from ffmaprep
WHERE
ARTICLE='0003672'
AND SALEDATE <= to_date('01.03.2007', 'DD.MM.YYYY')
AND nvl(SALELOCATIONFROM, SALELOCATIONTO) IN(6)
GROUP BY INCOMEID, (INCOMEQ))))
Но в данном случае внутренний запрос возвратит более одной строки, о чем и сообщает oracle
19.03.2007 08:38
Mtirt
 
Приблизительно так:
Код:
select SUM(QQ) from
(SELECT
MAX(INCOMEQ)-max(saleq) QQ
from ffmaprep
WHERE
ARTICLE='3672'
AND SALEDATE <= to_date('01.03.2007', 'DD.MM.YYYY')
AND nvl(SALELOCATIONFROM, SALELOCATIONTO) IN(6)
GROUP BY INCOMEID, INCOMEQ)


Опции темы


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

 

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