МГ: сессия от 2010-08-06

Сегодня в мастер-группе рассмотрим 5 вопросов.

К сожалению, у Вас недостаточно прав для просмотра этой записи. Если Вы еще не залогинены на сайте — залогиньтесь.

Если не активировали токен — посмотрите видео-инструкцию (видео N5)

Если вы залогинены, у Вас активирован токен доступа, но вы все равно видите эту запись — напишите нам на e-mail поддержки.

комментариев 6 на “МГ: сессия от 2010-08-06”

  1. Вопрос №2: алгоритм определения даты оплаты накладной описанный в вопросе – не верный. Наример, он не корректно опледелит дату оплаты для следующей ситуации:

    (данные по одному контрагенту)

    01.01.2010 Реализация 100р
    03.01.2010 Реализация 50р
    05.01.2010 Реализация 1000р

    06.01.2010 Оплата 150р
    10.01.2010 Оплата 1000р

    Анализируем накладную от 03.01.2010
    пл описанному алгоритму оплата данной накладной произведена 10.01.2010

    Хотя, очивидно, что она была оплачена 06.01.2010.

    P/S Соответственно, для решения задачи необходимо:
    1. Выбрать накладные за период
    2. Для каждой из них определить остаток долга контрагента после каждой реализации.
    3. Если долг нулевой или отрицательный, то тогда считать такую накладную оплаченой (т.е. дата оплаты равна дате реализации)
    4. В противном случае необходимо для каждой накладной выбрать все оплаты которые были после каждой реализации и определить на какой из них закрывается ранее определенная задолженность, дата этого платежного документа и будет датой оплаты.

    P.S. Есть серьезные основания полагать, что данную задачу можно решить одним пакетным запросом.

    • Может быть я не совсем четко описал свой алгоритм, но в приведенной ситуации для накладной от 03.01 он выдаст дату 06.01.
      Ведь оплата от 06.01 сделает два движения – по двум отгрузкам.
      Соответственно алгоритм возьмет наибольшую из дат (03.01, 06.01).
      Приведенный вами алгоритм на словах конечно верный, но реализовать его одним запросом будет крайне сложно.
      Скорее всего в этом случае для каждого документа будет отдельный запрос в пакете.
      То есть, если в периоде 3000 документов, будет выполнено 3000 непростых запросов, от чего серверу будет не сладко…
      Попробуйте реализовать указанный вами алгоритм, а потом опишите свой опыт.

      • Евгений, я говорил о неправильности алгоритма не вашего, а описанного на слайде :)

        Алгоритм, описанный на слайде, даст как раз дату 10.01.2010

        По поводу одного запроса, ок я постараюсь реализовать данную функциональность …. и думаю, величина запроса не будет зависить от числа документов :)

        • С алгоритмом понятно ))
          Интересно было бы проанализировать ваш опыт решения подобной задачи.

          • Александр Горлов 08.08.2010 в 21:37

            Насчет решения задачи одним пакетным запросом (правда, в немного другом изложении – получении просроченных долгов) детально описано в статье http://infostart.ru/public/61295/

            • В статье описана задача немного другая, но все равно интересная.