Остатки

Аватара пользователя
Александр Черняев
Сообщения:229
Зарегистрирован:29.05.2014 18:14
Остатки

12.11.2018 18:10

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

Аватара пользователя
Федоров Илья
Сообщения:412
Зарегистрирован:21.01.2018 18:09

Re: Остатки

13.11.2018 13:09

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

Аватара пользователя
Александр Черняев
Сообщения:229
Зарегистрирован:29.05.2014 18:14

Re: Остатки

13.11.2018 16:37

Федоров Илья Александрович писал(а):
13.11.2018 13:09
Более перспективный, как мне кажется, путь это интеграция с учетными системами где хранится актуальная информация по расчетам, остаткам и т.п.
Я пока не теряю надежды, тем более что интгеграция не решит задачу. В идеале мне нужно чтобы программист не принимал задачу в работу от клиента по которому есть задолженность. А для этого нужно чтобы система с которой интегрирован планфикс отправляла в планфикс такой запрет или какой-то признак. Такая интеграция выглядит довольно замороченной.

По теме придумал такой финт:
  • В аналитику добавляем такой реквизит как "Дата обнуления остатков", .Т.е. это дата когда в последний раз остатки равнялись нулю.
  • Когда остатки в очередной раз обнуляются (долг полностью погашен и дебет равен кредиту), добавляем в аналитику пустую запись с текущей датой в новом поле, это значит что все отчеты будут строится после этой даты.
  • Затем заходим в настройки аналитики и меняем в ней значение по умолчанию на эту дату обнуления, т.е. все дальнейшие записи в этом поле будут иметь значение например 01-05-2018.
  • В дальнейшем работаем, вводим записи аналитик у которых эта дата одинаковая.
    Потом строим отчет в котором в параметрах отбора нужно указать параметр по этому полю "больше или равен" указанной дате.
И отчет получится компактный (не за все года) и остатки будут актуальными.

Аватара пользователя
Михаил Храпунов
Сообщения:444
Зарегистрирован:23.05.2013 21:46

Re: Остатки

05.12.2018 20:14

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

Аватара пользователя
Константин Чугунов
Сообщения:64
Зарегистрирован:11.02.2013 15:18

Re: Остатки

15.05.2019 12:42

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

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

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

Аватара пользователя
Константин Чугунов
Сообщения:64
Зарегистрирован:11.02.2013 15:18

Re: Остатки

15.05.2019 12:58

Александр Черняев писал(а):
13.11.2018 16:37
Я пока не теряю надежды, тем более что интгеграция не решит задачу. В идеале мне нужно чтобы программист не принимал задачу в работу от клиента по которому есть задолженность.
Мне кажется, Вам стоит смотреть в сторону вычисляемых полей в карточке контакта.

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

Аватара пользователя
Константин Чугунов
Сообщения:64
Зарегистрирован:11.02.2013 15:18

Re: Остатки

15.05.2019 13:02

Константин Чугунов писал(а):
15.05.2019 12:58

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

Примерно так, вижу:
Кастомное поле 1: "Платежи". Сюда суммируем соответсвующую аналитику по платежам клиента.
Кастомное поле 2: "Списания". Сюда суммируем аналитику по потраченным средствам клиента.
Кастомное поле 3: "Баланс" Вычисляемое поле = поле1 - поле2
Внимание вопрос: а можно ли в отчете выводить значение вычисляемого поля, на определенную дату? Т.е. не то значение поля которое имеется в нем на момент запуска отчета, а то, которое было в этом поле в определенное время... :think: Интересные кейсы могли бы получиться.

Аватара пользователя
Dmitry Goncharenko
Сообщения:3630
Зарегистрирован:06.06.2012 13:54

Re: Остатки

15.05.2019 16:54

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

Аватара пользователя
Михаил Храпунов
Сообщения:444
Зарегистрирован:23.05.2013 21:46

Re: Остатки

23.05.2019 12:45

Дмитрий Гончаренко писал(а):
15.05.2019 16:54
Нет, это очень сложная штука со множеством нюансов. Если бы такая возможность была, то это решало бы половину задачи превращения ПланФикса в систему учета вроде 1С.
Но стремится то в эту сторону надо :)
А то никакого учета не сделать в планфиксе... Тогда зачем у нас есть аналитики? Т.е. данные собираем, а посчитать до конца не можем...

Аватара пользователя
Юрий
Сообщения:3
Зарегистрирован:21.05.2019 11:11

Re: Остатки

24.05.2019 15:33

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

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

Аватара пользователя
Dmitry Goncharenko
Сообщения:3630
Зарегистрирован:06.06.2012 13:54

Re: Остатки

25.05.2019 14:58

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

Аватара пользователя
Dmitry Goncharenko
Сообщения:3630
Зарегистрирован:06.06.2012 13:54

Re: Остатки

25.05.2019 15:02

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

Аватара пользователя
Michael Goshka
Сообщения:281
Зарегистрирован:29.06.2014 17:11

Re: Остатки

27.05.2019 09:59

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

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

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

Аватара пользователя
Федоров Илья
Сообщения:412
Зарегистрирован:21.01.2018 18:09

Re: Остатки

27.05.2019 16:55

Mike Goshka писал(а):
27.05.2019 09:59
У нас есть решение с аналитиками, могу в кратце описать как мы его видим:

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

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

Аватара пользователя
Юрий
Сообщения:3
Зарегистрирован:21.05.2019 11:11

Re: Остатки

28.05.2019 11:14

Mike Goshka писал(а):
27.05.2019 09:59
У нас есть решение с аналитиками, могу в кратце описать как мы его видим:

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

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

Аватара пользователя
Michael Goshka
Сообщения:281
Зарегистрирован:29.06.2014 17:11

Re: Остатки

28.05.2019 12:28

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

Аватара пользователя
Федоров Илья
Сообщения:412
Зарегистрирован:21.01.2018 18:09

Re: Остатки

28.05.2019 17:48

Mike Goshka писал(а):
28.05.2019 12:28
Поле будет хранить только текущий актуальный остаток.
Вот только все эти идеи с "остатками" могут работать только для очень простых автоматизаций где только один склад, расчетный счет, касса.
Как только возникает необходимость учитывать остатки более чем на одном складе все это перестает масштабироваться.

Аватара пользователя
Vitalii Pervukhin
Сообщения:7
Зарегистрирован:29.01.2020 23:38

Re: Остатки

16.04.2020 01:25

Michael Goshka писал(а):
27.05.2019 09:59
4. Перемещение например между складами это расход с одного справочника (склада) и приход в другой справочник (склад).
Михаил, прошу прощения.
Пробовал реализовать похожую задачу, но не получилось.
Не подскажете как именно реализуется вот эта часть? Как обращаться к справочнику.
Копал в автоматических сценариях, не нашел.

Аватара пользователя
Michael Goshka
Сообщения:281
Зарегистрирован:29.06.2014 17:11

Re: Остатки

16.04.2020 05:33

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

Аватара пользователя
Michael Goshka
Сообщения:281
Зарегистрирован:29.06.2014 17:11

Re: Остатки

16.04.2020 05:39

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

Пример:

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

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

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


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

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

Аватара пользователя
Vitalii Pervukhin
Сообщения:7
Зарегистрирован:29.01.2020 23:38

Re: Остатки

16.04.2020 13:51

Michael Goshka писал(а):
16.04.2020 05:33
Это описанный концепт работы.
Он еще не реализован.
А когда планируете реализовать?

Аватара пользователя
Vitalii Pervukhin
Сообщения:7
Зарегистрирован:29.01.2020 23:38

Re: Остатки

18.05.2020 21:05

Vitalii Pervukhin писал(а):
16.04.2020 13:51
Это описанный концепт работы.
Он еще не реализован.
А когда планируете реализовать?
Михаил?

Аватара пользователя
Dmitry Goncharenko
Сообщения:3630
Зарегистрирован:06.06.2012 13:54

Re: Остатки

20.05.2020 12:26

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

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

Аватара пользователя
Vitalii Pervukhin
Сообщения:7
Зарегистрирован:29.01.2020 23:38

Re: Остатки

20.05.2020 12:36

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

Аватара пользователя
Котелкин Андрей Игоревич
Сообщения:110
Зарегистрирован:08.06.2017 18:15

Re: Остатки

03.06.2020 11:46

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

Ответить