Остатки

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

Остатки

12.11.2018 18:10

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

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

Re: Остатки

13.11.2018 13:09

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

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

Re: Остатки

13.11.2018 16:37

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

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

Аватара пользователя
Михаил Храпунов
Сообщения: 423
Зарегистрирован: 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: Интересные кейсы могли бы получиться.

Аватара пользователя
Дмитрий Гончаренко
Сообщения: 3310
Зарегистрирован: 06.06.2012 13:54

Re: Остатки

15.05.2019 16:54

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

Аватара пользователя
Михаил Храпунов
Сообщения: 423
Зарегистрирован: 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С) сделало бы ПФ практически уникальным универсальным конструктором.

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

Аватара пользователя
Дмитрий Гончаренко
Сообщения: 3310
Зарегистрирован: 06.06.2012 13:54

Re: Остатки

25.05.2019 14:58

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

Аватара пользователя
Дмитрий Гончаренко
Сообщения: 3310
Зарегистрирован: 06.06.2012 13:54

Re: Остатки

25.05.2019 15:02

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

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

Re: Остатки

27.05.2019 09:59

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

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

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

Аватара пользователя
Федоров Илья
Сообщения: 224
Зарегистрирован: 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. Перемещение например между складами это расход с одного справочника (склада) и приход в другой справочник (склад).

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

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

Re: Остатки

28.05.2019 12:28

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

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

Re: Остатки

28.05.2019 17:48

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

Ответить