Comments 18
В той же 1С эти проблемы уже решены
Простите, но Вы либо не читали статью (внимательно), либо не работали с 1С (что вряд ли), либо мне остается только догадываться о причинах этого комментария.
Статью прочитал и 1с много где внедрял, а вот зачем эта статья с описанием велосипедов, да еще и не до конца правильными так и не понял
Рад бы предложить Вам на выбор один из двух вариантов:
1. Вы выбираете любую конфигурацию 1С и находите несколько отличий от того, что написано в статье.
2. Вы называете конкретную тиражируемую конфигурацию 1С и конкретный документ, где, как Вам кажется, эти проблемы решены. А я нахожу отличия и указываю Вам на них.
Но пока что настоятельно предлагаю первый вариант.
1. Вы выбираете любую конфигурацию 1С и находите несколько отличий от того, что написано в статье.
2. Вы называете конкретную тиражируемую конфигурацию 1С и конкретный документ, где, как Вам кажется, эти проблемы решены. А я нахожу отличия и указываю Вам на них.
Но пока что настоятельно предлагаю первый вариант.
В типовых от 1С не решены. А на платформе 1С это решается просто, да.
Я имею ввиду конфигурации КА2, ERP, УТ11 — в части платежей, там есть заявки на расходование денежных средств и лимиты по оплате, соответственно, при формировании заявки этот лимит уменьшается, если у заявки будет статут «отвергнут», то она освободит лимит, есть так же платежный календарь, который показывает на несколько дней вперёд сколько денег у вас будет с учетом текущего состояния расчётных счетов и касс, а так же запланированных заявок.
Есть заказы покупателям, которые учитываются в свободном остатке товаров, соответственно если есть заказ и его строки стоят в статусе к обеспечению или отгрузка, то свободный остаток уменьшается и при подборе товара в новый заказ или изменении существующего заказа это будет учитываться, система не даст поставить к отгрузке товар, даже если он есть на складе, но зарезервирован другими заказами. Для анализа доступности товара есть соотв. отчет
Есть заказы покупателям, которые учитываются в свободном остатке товаров, соответственно если есть заказ и его строки стоят в статусе к обеспечению или отгрузка, то свободный остаток уменьшается и при подборе товара в новый заказ или изменении существующего заказа это будет учитываться, система не даст поставить к отгрузке товар, даже если он есть на складе, но зарезервирован другими заказами. Для анализа доступности товара есть соотв. отчет
Уже лучше. Даже поставил плюс.
Но это именно частная реализация, а не решение в общем виде. До него еще много отрывов.
1. Вы сами говорите, что в связке участвуют только Заявка на расходование и Списание. Как вы заметили, платежное поручение не учитывается (хотя я о нем писал, как и о «звонке из банка»).
Это значит, что если в поручении указаны другие, уточненные данные, в сравнении с заявкой — программа их не учтет, она все равно будет использовать в расчетах/отчетах заявку и ее реквизиты до тех пор, пока ваш бухгалтер не проведет списание и не свяжет его с нужной заявкой.
Это далеко от реалтаймовости. Если что, Таблица 1 в статье — не надуманная фантазия, она составлена на основе реальной практики.
2. Условия по типу {Если в списании не указано подразделение — брать его из заявки} не прописаны. Данные берутся либо из заявки целиком, либо из списания целиком.
3. Если вы попробуете такое условие дописать (а тем более сделать это по цепочке из 3х или более видов документов) — вы построите запросы через связку документов, про производительность которой сами все понимаете. Для более-менее крупных объемов данных нужна другая архитектура (например, через регистры).
Кстати, даже в разных продуктах 1С используются разные подходы. Например, еще одна реализация была, кажется, в УТ10, когда общий регистр представлял собой единый актуализированный срез по товарной операции, и разные документы в цепочке по очереди проводили в него данные. Причем когда свежий документ отменялся, в нее обратно подставлялись данные из предыдущего документа. Но у этого подхода другая обратная сторона — очень сложный код механизма проведения/отмены проведения, и при попытке его доработать (например добавить в цепочку еще один кастомный документ) разработчикам приходится очень непросто.
Кстати, уже планировали с партнерами из сферы 1С сделать MVP на этой платформе для демонстрации решения в общем виде. Но пока это вопрос времени.
Но это именно частная реализация, а не решение в общем виде. До него еще много отрывов.
1. Вы сами говорите, что в связке участвуют только Заявка на расходование и Списание. Как вы заметили, платежное поручение не учитывается (хотя я о нем писал, как и о «звонке из банка»).
Это значит, что если в поручении указаны другие, уточненные данные, в сравнении с заявкой — программа их не учтет, она все равно будет использовать в расчетах/отчетах заявку и ее реквизиты до тех пор, пока ваш бухгалтер не проведет списание и не свяжет его с нужной заявкой.
Это далеко от реалтаймовости. Если что, Таблица 1 в статье — не надуманная фантазия, она составлена на основе реальной практики.
2. Условия по типу {Если в списании не указано подразделение — брать его из заявки} не прописаны. Данные берутся либо из заявки целиком, либо из списания целиком.
3. Если вы попробуете такое условие дописать (а тем более сделать это по цепочке из 3х или более видов документов) — вы построите запросы через связку документов, про производительность которой сами все понимаете. Для более-менее крупных объемов данных нужна другая архитектура (например, через регистры).
Кстати, даже в разных продуктах 1С используются разные подходы. Например, еще одна реализация была, кажется, в УТ10, когда общий регистр представлял собой единый актуализированный срез по товарной операции, и разные документы в цепочке по очереди проводили в него данные. Причем когда свежий документ отменялся, в нее обратно подставлялись данные из предыдущего документа. Но у этого подхода другая обратная сторона — очень сложный код механизма проведения/отмены проведения, и при попытке его доработать (например добавить в цепочку еще один кастомный документ) разработчикам приходится очень непросто.
Кстати, уже планировали с партнерами из сферы 1С сделать MVP на этой платформе для демонстрации решения в общем виде. Но пока это вопрос времени.
1. Списание ДС — это и есть платежка, только там есть признак проведена она банком или нет. Пока не проведена, расход бюджета делается из заявки, как только проведена, делается фактическое списание ДС, расход бюджета сторнируется. В некоторых организациях делали еще более глубоко. Бюжет -> Договор ->Заявка -> ПП. Таким образом нельзя было назаключать договоров сверх бюджета.
2. Обычно такого не допускаем, т.к. бюджет верстается в разрезе ЦФО, и будет хрень
3. В 1с есть регистры, которые сильно ускоряют такие вещи
2. Обычно такого не допускаем, т.к. бюджет верстается в разрезе ЦФО, и будет хрень
3. В 1с есть регистры, которые сильно ускоряют такие вещи
Списание ДС — это и есть платежка, только там есть признак проведена она банком или нет.
Точно, с 1С: Бухгалтерией перепутал.
В некоторых организациях делали еще более глубоко. Бюжет -> Договор ->Заявка -> ПП.
Так и надо. Но опять же, не типовом функционале
2. Обычно такого не допускаем, т.к. бюджет верстается в разрезе ЦФО, и будет хрень
Не понял, о чем вы, но это просто пример (который легко решается автозаполнением в платежке ЦФО равным значению из заявки — костыль, но все же), не суть принципиально
В 1с есть регистры, которые сильно ускоряют такие вещи
Я это только что написал:)
Для отчётов, балансов и планов (денежным) мне в своё время хорошо зашли события, но не обычные, регистрирующие факты, а со статусом типа факт/отменено/запланировано. Фильтруя по типу, статусам, датам отчёты удобно получались и шустро относительно. А особенно удобно было переводить планы в факты или отменять
LEFT JOIN / COALESCE вам в помощь! Джойнимся и с таблицей планов, и с таблицей фактов (предполагаем, что ключевая часть у них идентична). Дальше при отсутствии значения из фактов берём план. Вокруг этого ядра строим всю остальную отчетную агрегацию. На вменяемой модели данных такие штуки делаются чуть сложнее, чем тривиально. Но, да, современному бизнесу они нужны. Ему без OLAP никак, как современному программисту без CI ;)
Естественно. Я просто призываю это делать:)
OLAP я упомянул на случай хайлоада, когда данных крайне много, а правила получения одного и того же расчетного показателя в разных отчетах различаются. С точки зрения логики это не имеет значения, это вопрос сугубо производительности.
OLAP я упомянул на случай хайлоада, когда данных крайне много, а правила получения одного и того же расчетного показателя в разных отчетах различаются. С точки зрения логики это не имеет значения, это вопрос сугубо производительности.
Или про OLAP и CI был не стёб? Тогда второй абзац моего предыдущего комментария не читать:)
Причем тут хайлоад к ОЛАПу? У нас, например, данных — единицы миллионов строк (даже не десятки), но отдел консолидированной отчетности обожает куб. )))
В консолидированной куб традиционно используется. В комментарии Глеба, я так понимаю, речь про куб в оперативном учете)
Отчеты с планами / фактами и прогнозами — это уже отчетность, а не оперативный учет…
Как показывает опыт — даже небольшие наборы данных при формировании отчетов удобнее будет выдать пользователям в виде кубов — так им проще строить нужные им отчеты — сразу в екселе будут делать.
То есть сами данные о планах и фактах храним в ERP, а отчеты строим отдельно.
В оперативном данные о планах тоже нужны, но не как отчеты, а как способ ввода фактических данных. Например, при вводе заказа поставщику показать доступные статьи бюджета (с остатками), чтобы тут же привязать — может быть очень полезно. Но надо очень аккуратно с этим обращаться, чтобы сохранить гибкость.
Как показывает опыт — даже небольшие наборы данных при формировании отчетов удобнее будет выдать пользователям в виде кубов — так им проще строить нужные им отчеты — сразу в екселе будут делать.
То есть сами данные о планах и фактах храним в ERP, а отчеты строим отдельно.
В оперативном данные о планах тоже нужны, но не как отчеты, а как способ ввода фактических данных. Например, при вводе заказа поставщику показать доступные статьи бюджета (с остатками), чтобы тут же привязать — может быть очень полезно. Но надо очень аккуратно с этим обращаться, чтобы сохранить гибкость.
Sign up to leave a comment.
Логика ERP-системы реального времени: замещение планов фактами