Остатки

[Александр Черняев]

Добрый день!
Прошелся поиском по форумам, тема остатков всплывает то тут то там, но отдельной темы по вопросу нет.
Ребята, я пришел к выводу что очень нужны остатки и многое упирается в остатки. Например остатки предоплаты, которые нужно контролировать и запрещать отгрузку в минус.
Планируется ли что-нибудь по этому вопросу?

[Илья Федоров]

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

[Александр Черняев]

Более перспективный, как мне кажется, путь это интеграция с учетными системами где хранится актуальная информация по расчетам, остаткам и т.п.

Я пока не теряю надежды, тем более что интгеграция не решит задачу. В идеале мне нужно чтобы программист не принимал задачу в работу от клиента по которому есть задолженность. А для этого нужно чтобы система с которой интегрирован планфикс отправляла в планфикс такой запрет или какой-то признак. Такая интеграция выглядит довольно замороченной.

По теме придумал такой финт:

• В аналитику добавляем такой реквизит как "Дата обнуления остатков", .Т.е. это дата когда в последний раз остатки равнялись нулю.

• Когда остатки в очередной раз обнуляются (долг полностью погашен и дебет равен кредиту), добавляем в аналитику пустую запись с текущей датой в новом поле, это значит что все отчеты будут строится после этой даты.

• Затем заходим в настройки аналитики и меняем в ней значение по умолчанию на эту дату обнуления, т.е. все дальнейшие записи в этом поле будут иметь значение например 01-05-2018.

• В дальнейшем работаем, вводим записи аналитик у которых эта дата одинаковая.
  Потом строим отчет в котором в параметрах отбора нужно указать параметр по этому полю "больше или равен" указанной дате.

И отчет получится компактный (не за все года) и остатки будут актуальными.

[Михаил Храпунов]

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

Поддерживаю. Но понимаю сложность. Если что то будет двигаться по этой теме — будет замечательно.

[Константин Чугунов]

Решил не создавать новую тему, а в этой похожей теме написать.

Для отчетов нужно реализовать возможность расчета "начального сальдо", т.е. те самые остатки на дату начала периода по которому строится отчет.

Видимо для этого нужно запускать 2 отчета: первый с даты создания аккаунта, например, до даты начала заданного периода (это "невидимый" отчет, результаты которого, заносятся как начальное сальдо во втрой отчет). А второй, тот отчет который нам нужен, с нужным периодом.

[Константин Чугунов]

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

Мне кажется, Вам стоит смотреть в сторону вычисляемых полей в карточке контакта.

Примерно так, вижу:
Кастомное поле 1: "Платежи". Сюда суммируем соответсвующую аналитику по платежам клиента.
Кастомное поле 2: "Списания". Сюда суммируем аналитику по потраченным средствам клиента.
Кастомное поле 3: "Баланс" Вычисляемое поле = поле1 - поле2

[Константин Чугунов]

Мне кажется, Вам стоит смотреть в сторону вычисляемых полей в карточке контакта.

Примерно так, вижу:
Кастомное поле 1: "Платежи". Сюда суммируем соответсвующую аналитику по платежам клиента.
Кастомное поле 2: "Списания". Сюда суммируем аналитику по потраченным средствам клиента.
Кастомное поле 3: "Баланс" Вычисляемое поле = поле1 - поле2

Внимание вопрос: а можно ли в отчете выводить значение вычисляемого поля, на определенную дату? Т.е. не то значение поля которое имеется в нем на момент запуска отчета, а то, которое было в этом поле в определенное время... Интересные кейсы могли бы получиться.

[Dmitry Goncharenko]

Внимание вопрос: а можно ли в отчете выводить значение вычисляемого поля, на определенную дату? Т.е. не то значение поля которое имеется в нем на момент запуска отчета, а то, которое было в этом поле в определенное время... Интересные кейсы могли бы получиться.

Нет, это очень сложная штука со множеством нюансов. Если бы такая возможность была, то это решало бы половину задачи превращения ПланФикса в систему учета вроде 1С.

[Михаил Храпунов]

Нет, это очень сложная штука со множеством нюансов. Если бы такая возможность была, то это решало бы половину задачи превращения ПланФикса в систему учета вроде 1С.

Но стремится то в эту сторону надо :)
А то никакого учета не сделать в планфиксе... Тогда зачем у нас есть аналитики? Т.е. данные собираем, а посчитать до конца не можем...

[Юрий]

Да... наличие регистра остатков (типа как в 1С) сделало бы ПФ практически уникальным универсальным конструктором.

Кстати, пример из другой сферы. Все мы видим хайп, связанный с биткоином. Там тоже нет регистра остатков, а текущее сальдо считается через приход-расход с самой первой транзакции. Я не специалист, но возможен ли здесь "трансфер технологий"? Может внедрить в ПФ технологию блокчейна для расчета остатков?

[Dmitry Goncharenko]

Тогда зачем у нас есть аналитики? Т.е. данные собираем, а посчитать до конца не можем...

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

[Dmitry Goncharenko]

Кстати, пример из другой сферы. Все мы видим хайп, связанный с биткоином. Там тоже нет регистра остатков, а текущее сальдо считается через приход-расход с самой первой транзакции. Я не специалист, но возможен ли здесь "трансфер технологий"? Может внедрить в ПФ технологию блокчейна для расчета остатков?

У нас этот механизм тоже работает, через отчеты, которые можно запускать с даты появления первой аналитики и до текущего момента - они покажут остатки. Но это так себе решение, т.к. с каждый днем такие отчеты будут формироваться все дольше. Это делает такую схему не особо жизнеспособной. Что касается блокчейна, то он тут не поможет - технологически сам по себе блокчейн в текущем состоянии достаточно затратная технология. Он стремится разными путями обойти лежащие в основе его модели проблемы применения в подобных областях, но что из этого получится, покажет время.

[Michael G.]

У нас есть решение с аналитиками, могу в кратце описать как мы его видим:

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

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

[Илья Федоров]

У нас есть решение с аналитиками, могу в кратце описать как мы его видим:

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

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

Очень интересное решение.

[Юрий]

У нас есть решение с аналитиками, могу в кратце описать как мы его видим:

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

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

А поле будет хранить только текущий актуальный остаток?
Или в нем будет храниться история изменения остатка (в привязке к времени создания аналитики)?

[Michael G.]

Поле будет хранить только текущий актуальный остаток.

[Илья Федоров]

Поле будет хранить только текущий актуальный остаток.

Вот только все эти идеи с "остатками" могут работать только для очень простых автоматизаций где только один склад, расчетный счет, касса.
Как только возникает необходимость учитывать остатки более чем на одном складе все это перестает масштабироваться.

[Vitalii Pervukhin]

4. Перемещение например между складами это расход с одного справочника (склада) и приход в другой справочник (склад).

Михаил, прошу прощения.
Пробовал реализовать похожую задачу, но не получилось.
Не подскажете как именно реализуется вот эта часть? Как обращаться к справочнику.
Копал в автоматических сценариях, не нашел.

[Michael G.]

Это описанный концепт работы.
Он еще не реализован.

[Michael G.]

Вот только все эти идеи с "остатками" могут работать только для очень простых автоматизаций где только один склад, расчетный счет, касса.
Как только возникает необходимость учитывать остатки более чем на одном складе все это перестает масштабироваться.

Не вижу проблемы с машстабированием.

Пример:

Склад 1 Склад 2
Склад1.Остаток1 Склад2.Остаток2

Перемещение между складами:

Аналитика:
Расход.Склад1.Товар1 (Склад1.Товар1.Остаток -1)


Аналитика:
Приход.Склад2.Товар1 (Склад2.Товар1.Остаток +1)

Т.е. на перемещение между складами делается 2 записи.

[Vitalii Pervukhin]

Это описанный концепт работы.
Он еще не реализован.

А когда планируете реализовать?

[Vitalii Pervukhin]

Это описанный концепт работы.
Он еще не реализован.
А когда планируете реализовать?

Михаил?

[Dmitry Goncharenko]

А когда планируете реализовать?

Тут применим стандартный планфиксовский ответ на вопросы по срокам: К сожалению, точную дату реализации назвать мы не можем.

Не потому, что не хотим, а потому, что у нас есть "большая очередь", в которой находятся абсолютно все задачи на доработку, и "близкая очередь", в которую попадают задачи, над которыми мы работаем прямо сейчас и которые увидят свет в ближайшие недели или месяцы. Так что единственное, что можно сказать, это входит конкретная задача в близкую очередь или нет. Задача про остатки - не входит.

[Vitalii Pervukhin]

Принято!
Спасибо

[Котелкин Андрей]

Как раз понадобилось для себя реализовать такое решение, жаль что не входит в список приоритетов. также возник вопрос и пока не могу красиво его решить по этой же теме.
Приходит партия товара (например 10 единиц одного наименования по одной себестоимости), через месяц приходит такойже товар, но себестоимость другая. Сам товар хранится в записях справочника как отдельный приход товара.
Хочу отслеживать, когда будет продан товар из первой партии. Чтобы " снять" его с продажи и перевести записи справочника в архив.