Всем привет,
очередная проблема со сторно закрытым месяцем, вид сбоку.

Имеем попытку отсторнировать проведенную в октябре фактуру октябрем же. Однако месяц закрыт, в итоге сторнирующая фактура хоть и создалась, но проведена не была. Т.е. проводки не пострадали.

Однако пострадал самопальный отчет по продажам со стороны сбыта, в котором сторнированные фактуры не учитываются - статус исходной фактуры сменился на "Сторнирована", факутура в отчет уже не попадает.

Быть может, у кого-то есть идеи, как исправить ситуацию с отчетом? Была мысль руками убрать из VBRK статус сторнирования, но это оказалось невозможно, не дает система эту таблицу править.

Ну, если проблема только в отчете, то и доработайте его. Можно для прямых фактур искать сторнирующую и проверять ее статус проводки в FI.
Кстати, недавно встал перед задачей сверки отчета из оборотки в FI с отчетом по выручке из VBRK. Вот тут-то я и понял, что нельзя просто откидывать сторнированные и сторнирующие фактуры в VBRK. Этот метод не прокатывает, если фактура проведена в одном периоде (квартале), а сторнирована в другом. В результате оборотка показывает выручку в первом квартале и минусовую выручку во втором. Если брать период выборки первый квартал - суммы не сойдутся.

В итоге пришел к тому, что в отчете, построенном на основе VBRK, нужно сторнирующие фактуры не убирать, а показывать с минусом.

К сожалению, тут пострадал не только отчет, но и целостность данных. Теперь у вас имеется расхождение между SD и FI, что вообще-то не есть хорошо. Кроме того, если у вас используются info structures (SIS), то в них сторно скорее всего тоже было зафиксировано, так что стандартные отчеты тоже "пострадали". Можно, конечно, в самопальном отчете создать иллюзию, что "все хорошо, прекрасная маркиза", но это и будет только иллюзия.

А что с фактурой-то, собственно? Вообще передумали сторнировать?

Спасибо, из разряда пословицы про незамеченного слона.
Добавил я такую проверку, отчет вместо 2х секунд стал работать 15, можем абаперы подскажут, как ускорить.
Насчет сторно с минусом - мысль дельная, обсудим.

@Jelena: фактуру сторнировала дрогнувшая рука пользователя.
SIS была вручена сразу с оговоркой, что в свете постоянно заводящихся новых ОЗМ и ОЗД и др. факторов вроде возможных ошибок обновления ручаться за 100% верные суммы проблематично. После чего пользователи затребовали отчет, в котором суммы совпадут с проводками по 90м счетам.

Ну, вы напишите, как сделали поиск сторнирующей фактуры, тогда можно будет и посоветовать оптимизациию. Я делел не через поток документов (VBFA), а через ссылку в VBRK для сторнирующей фактуры на номер сторнированной. После того, как добавил индекс по этому полю со скоростью проблемы исчезли.

я не совсем понял насколько разорвана стандартная логика, но вот есть такая вот нота

394318

тут есть моменты соединения разорвавшихся во времени СФ и её сторно. Я пользовался её в свое время успешно

@LKU:
вот что я добавил( rfbsk = статус проводки = C для проведенных, sfakn - номер фактуры, которая была сторнирована текущей фактурой):

В анализе производительности 98% времени - запросы к БД, а конкретно этот select single.
Ещё надо бы упомянуть, что запрос сделан через квери по vbrk, vbrp. Хотелось бы считать vbrk один раз во внутреннюю таблицу и потом обращаться к ней, но где это сделать и можно ли, пока не понятно.

@Justudent: нота полезная, но после применения нотки фактура, видимо, окончательно осторнируется по всем понятиям, а нам она как раз нужна живая - ещё раз продать нельзя будет т.к. закрыт месяц.

Ну вот я и говорю: попробуйте создать индекс по полю VBRK-SFAKN.

Индекс, конечно, поможет, но в любом случае делать подобную проверку SELECT SINGLE для каждого документа не рационально в принципе. Я бы посоветовала использовать internal table и FOR ALL ENTRIES.

A eсли речь идет о больших объемах данных, то возможно вообще будет гораздо рациональнее захардкодить номер документа или завести Z табличку для записи подобных (крайне редких, полагаю) исключений. Это немного корявое решение, но иногда элегантность не стоит свеч.

Всем спасибо за советы, в итоге захардкодил.

А не проще отказывать в сохранении фактуры с помощью проверки открытости периода по дате сторно-фактуры? Думаю, с enhancement это реализуемо.