Сергій Сікора
Переможець- Проєкти 80
- Оцінка 1.0
- Рейтинг 1 975
Бюджет: 2500 UAH Термін: 3 дні
Здоров’я Приємно, що завдання детально описано) Є досвід і бажання працювати. Зверніться до нас.
Ставки поки відсутні
Ставки приховані
-
Сергей Назаренко 10 вересня 2019Наверное, Вы меня сочтете занудой, но "Исправление ошибки на этапе проектирования в 200 000 раз дешевле ее исправления на этапе тестирования"(С)Из книжки по PM (к сожалению уже не вспомню точно из какой).
И т.к. я вижу ошибку в самой постановке, то хочу исправить ее, пока еще никто не перенес ее в код.
Итак.
Рассмотрим внимательно задание:
"Отчет формировать на выбранную дату, при этом считать, что эта дата есть началом и концом периода.
...
нас интерисует регистратор «Реализация товаров и услуг» (РТУ)
...
Группировки выводить по ... Дате* (В строке отчета выводить ДатуДок РТУ)."
Это только мне кажется, что сочетание этих трех условий приведет к тому, что в группировке Дата будет всегда одна и та же дата? Только время отличаться будет. И то, только в том случае, если мы периодом выбора оборотов будем считать не выбранную дату, а начало и конец дня выбранной даты.
-
Сергей Назаренко 10 вересня 2019"Вместо счета-фактуры - выводим дату РТУ, по ней же и группируем"
Правильно. Но т.к. мы выбрали обороты только за 01.07.2017, то в данных у нас будут только РТУ за 01.07.2017 (т.к. РТУ - это регистратор из выбранных оборотов). И в отчете в группировке ДатаРТУ будут везде одинаковые значения = 01.07.2017.
-
Natali Dem
10 вересня 2019
Это верно,
но в случае, если было сальдо на начало периода, то это значит, что дата РТУ будет меньше выбранной.
-
Сергей Назаренко 10 вересня 2019Но эта РТУ не попадет в выборку ВООБЩЕ, т.к. РТУ - это регистратор ("нас интерисует регистратор «Реализация товаров и услуг» (РТУ)"), а остатки по регистраторам, не попавшим в период выборки, у нас отсутствуют.
-
Natali Dem
10 вересня 2019
Угу, тут я не корректно использовала термин, исправляюсь: "нас интересуют входящие остатки и обороты по счету 361"
-
Сергей Назаренко 10 вересня 2019Возьмусь предположить, что необходимая Вам логика построения отчета следующая:
В параметрах указываем дату (на конец которой мы хотим получить остатки), а также, возможно, фильтр по организациям и контрагентам.
1. Система выбирает на указанную дату остатки в разрезе Организаций, Контрагентов и Сделок (в Вашем случае Счетов на оплату).
2. Далее, система выбирает все реализации (за все время существования базы), которые делали проводки (по 361 счету) по попавшим в отчет Сделкам. И из каждой реализации берет ее дату (дата документа). И для каждой Сделки определяет минимальную дату реализации (на случай, если по одной Сделке было несколько отгрузок).
3. И наконец, в полученном в п.1. отчете нужно заменить все Сделки на полученные в п.2. минимальные даты РТУ.
Я правильно понял Вашу задачу (в том, что касается группировки по Дате)?
Теперь о разбивке на БУ / БУ+УУ.
Признаки БУ и УУ есть в Сделке (Счет, Заказ и т.п.), в РТУ, в ПП.
Хорошо, если во всех документах по одной сделке эти галочки совпадают. Тогда мы можем ориентироваться на эти галочки в Сделке.А если эти галочки разные в разных документах по одной Сделке? Например, в Сделке БУ и УУ, в РТУ1 - только БУ, в РТУ2 - только УУ, в РТУ3 - БУ и УУ, в ПП1 - БУ и УУ, в ПП2 - только БУ и т.п. То как правильно разделить сумму остатка (которая по Сделке в целом) на виды учета?
-
Natali Dem
10 вересня 2019
В начале - спасибо Вам за помощь в анализе задачи.
Если у СФ все подчиненные доки с разной датой, то выводим их отдельными строками. Сумма сделки в СФ - не учитывается (СФ - не имеет проводок). Так же игнорируем и подчиненные доки с ТОЛЬКО управленческим учетом (т.е. только УУ). На рисунке Ваш пример:

Если же , например, Дата1=Дата3, то картика будет такой:

-
Сергей Назаренко 10 вересня 2019Первое, что сразу бросается в глаза в Вашем примере, это то, что в таблице не будет Дата4 и Дата5, т.к. мы ищем только даты РТУ (согласно условию задачи).
Допустим, что я не правильно понял условие задачи, и описанный мною выше алгоритм нужно поправить так, чтобы мы по Сделке брали даты не только РТУ, но и всех регистраторов, которые делали проводки по этой Сделке.
Но нужно понимать, что таким образом мы не получим остатки по этим датам (регистраторам). Это будут обороты по указанным датам.
А остаток у нас будет суммарный - по Сделке (СФ) в целом. И как этот остаток разнести по датам - вопрос еще тот.
Также нужно понимать, и в Вашем примере это видно, что оплаты не будут закрывать остаток по отгрузкам, а будут попадать в отчет в отдельную колонку в отдельные даты.
Это так и хочется? Или хочется, чтобы оплаты закрывали остатки по отгрузкам?
А вообще, та табличка, которую Вы привели в пример, уж очень похожа на оборотку (с начала времен до указанной даты), с детализацией до регистраторов (отображается не сам регистратор, а его дата), с разделением сумм оборотов по видам учета (указанным в регистраторе), и с отбором только тех сделок, по которым суммарный оборот за период формирования отчета - не нулевой. А также, в названиях колонок вместо слова "Обороты" указано слово "Сальдо".
-
Natali Dem
11 вересня 2019
Документооборот фирмы проще, чем указано на вашей иллюстрации, например:

Результат, который Вы мне показали - уже есть:

Красным выделены примеры оборотов, по которым нужно подвести ИТОГ (сальдо), но проблема в том, что 1. Это обороты, а нужно сальдо, с учетом входящих остатков и этих оборотов (Вы верно подметили - как в оборотке). Так же открытым остается вопрос ДАТЫ (на иллюстрации даты из оборотов за указанный период, но если учитывать входящие остатки, то - не решенная задача.)
Примечание: если понадобится, для решения задачи- мою обработку с оборотами могу выслать.
-
Сергей Назаренко 11 вересня 2019Поставьте в этом отчете дату начала = '0001.01.01' (в путое значение) и получите то, что Вам требуется - остатки на конец периода (которые равны оборотам +/- за весь период).
Актуальні фриланс-проєкти в категорії Автоматизація управління підприємством
Привіт! Шукаю програміста BAS / 1С для створення простої та зручної програми "під себе".Будуємо 9-поверховий багатоквартирний будинок. Бухгалтерія працює окремо, тому програма потрібна не для податків, а для мого особистого контролю фінансів та будівництва.Що програма має робити (основне):Гроші: бачити, скільки зайшло, скільки витрачено і скільки є в наявності (готівка / безготівка).Витрати на будинок: чіткий облік, куди пішли гроші (матеріали, зарплата будівельникам, техніка, проекти, дозволи тощо).Матеріали: що купували і на що воно пішло.Підрядники та бригади: скільки ми їм винні за виконану роботу і скільки вже виплатили.Прості звіти: щоб я могла в будь-який момент відкрити і побачити реальну собівартість будівництва та загальний фінансовий стан.Шукаю фахівця, який може пояснити все простою мовою та зробити програму зручною для щоденного використання.Будь ласка, пишіть, чи робили ви подібні фінансові модулі та яка орієнтовна вартість такої роботи.
Потрібно розробити централізовану серверну систему збору та зберігання даних із Planfix, 1С, Meta Ads і Google Ads, а також веб-дашборд для їх відображення та аналізу. Усі дані, історія змін, розрахунки та агреговані показники повинні зберігатися виключно в серверній базі даних. Дашборд не повинен зберігати або дублювати бізнес-дані. Він має отримувати необхідну інформацію із серверної бази через API відповідно до запитів користувача та відображати її у вигляді KPI, графіків, таблиць і деталізованих звітів.
Наповнення товарами магазину Etsy автоматизовано. Шукаємо, хто зможе автоматизовано наповнити магазин товарами на Etsy. Магазин одягу з принтами. Ми займаємось друком аніме на одязі, але на Етсі було купа страйків по АП, тому змінюємо нішу, будемо займатись друком на одязі. Задача не потрапити під АП та заповнити магазин товарами. Потрібна допомога з цим та якась базова автоматизація.
Мета: Замінити 1С на гнучку ERP із відкритим кодом. Потрібна базова торговельна логіка + інтеграції з українськими сервісами + можливість підключати нашого ІІ-агента.Обов’язковий функціонал Базова ERP-логіка Контрагенти, рахунки, прибуткові/видаткові накладні, складський облік. Продажі, замовлення, ціноутворення. Інтеграція з Новою поштою Двосторонній обмін: створення ЕН, друк накладної, статуси доставки. Розрахунок вартості. Інтеграція з маркетплейсами (двостороння) Prom.ua – товари, замовлення, залишки. Rozetka – те саме. Epicentr – те саме (якщо є API – використати, якщо ні – через універсальний конектор). Синхронізація номенклатури із зовнішньої бази Товари та ціни автоматично підтягуються з іншої бази (наприклад, через REST API або SQL-з’єднання). Потрібна періодична синхронізація. Інтеграція з нашим ІІ-агентом Через REST API Odoo. Агент зможе читати/писати дані (наприклад, генерувати описи товарів, прогнозувати залишки, обробляти замовлення). Локалізація для України План рахунків, податкові накладні, ПРРО (Checkbox), звітність.
Шукаю уважного та системного помічника для ведення клієнтської бази невеликого кавового бізнесу. Потрібно допомогти організувати простий і зрозумілий облік клієнтів. На початковому етапі це може бути добре налаштована Google-таблиця, Notion або недорога CRM. Розгляну ваші пропозиції щодо найбільш зручного та бюджетного рішення. Що необхідно враховувати по кожному клієнту: ім'я та контактні дані; джерело звернення, наприклад реклама, Instagram, рекомендація; дата першого контакту; що клієнт купував; які види та смакові профілі кави йому сподобалися; спосіб приготування кави; історія та приблизна частота замовлень; дата наступного контакту; коментарі та важливі деталі переписки. Шукаю перш за все розумне та економічне рішення для невеликого бізнесу, тому дорогі та складні CRM на даному етапі не розглядаю. На першому етапі основний акцент на систематизації інформації та нагадуваннях. В подальшому можна буде обговорити самостійну відправку погоджених повідомлень клієнтам.


