Serhii Sikora
Oferta, która wygrała- Zlecenia 80
- Ocena 1.0
- Ranking 1 975
Budżet: 2500 UAH Termin: 3 dni
Pozdrawiam . Cieszę się, że zadania są szczegółowo opisane) Istnieje doświadczenie i chęć pracy. Zwróć się.
Aktualnie brak ofert
Oferty ukryte
-
Sergey Nazarenko 10 wrzesnia 2019Наверное, Вы меня сочтете занудой, но "Исправление ошибки на этапе проектирования в 200 000 раз дешевле ее исправления на этапе тестирования"(С)Из книжки по PM (к сожалению уже не вспомню точно из какой).
И т.к. я вижу ошибку в самой постановке, то хочу исправить ее, пока еще никто не перенес ее в код.
Итак.
Рассмотрим внимательно задание:
"Отчет формировать на выбранную дату, при этом считать, что эта дата есть началом и концом периода.
...
нас интерисует регистратор «Реализация товаров и услуг» (РТУ)
...
Группировки выводить по ... Дате* (В строке отчета выводить ДатуДок РТУ)."
Это только мне кажется, что сочетание этих трех условий приведет к тому, что в группировке Дата будет всегда одна и та же дата? Только время отличаться будет. И то, только в том случае, если мы периодом выбора оборотов будем считать не выбранную дату, а начало и конец дня выбранной даты.
-
Sergey Nazarenko 10 wrzesnia 2019"Вместо счета-фактуры - выводим дату РТУ, по ней же и группируем"
Правильно. Но т.к. мы выбрали обороты только за 01.07.2017, то в данных у нас будут только РТУ за 01.07.2017 (т.к. РТУ - это регистратор из выбранных оборотов). И в отчете в группировке ДатаРТУ будут везде одинаковые значения = 01.07.2017.
-
Natali Dem
10 wrzesnia 2019
Это верно,
но в случае, если было сальдо на начало периода, то это значит, что дата РТУ будет меньше выбранной.
-
Sergey Nazarenko 10 wrzesnia 2019Но эта РТУ не попадет в выборку ВООБЩЕ, т.к. РТУ - это регистратор ("нас интерисует регистратор «Реализация товаров и услуг» (РТУ)"), а остатки по регистраторам, не попавшим в период выборки, у нас отсутствуют.
-
Natali Dem
10 wrzesnia 2019
Угу, тут я не корректно использовала термин, исправляюсь: "нас интересуют входящие остатки и обороты по счету 361"
-
Sergey Nazarenko 10 wrzesnia 2019Возьмусь предположить, что необходимая Вам логика построения отчета следующая:
В параметрах указываем дату (на конец которой мы хотим получить остатки), а также, возможно, фильтр по организациям и контрагентам.
1. Система выбирает на указанную дату остатки в разрезе Организаций, Контрагентов и Сделок (в Вашем случае Счетов на оплату).
2. Далее, система выбирает все реализации (за все время существования базы), которые делали проводки (по 361 счету) по попавшим в отчет Сделкам. И из каждой реализации берет ее дату (дата документа). И для каждой Сделки определяет минимальную дату реализации (на случай, если по одной Сделке было несколько отгрузок).
3. И наконец, в полученном в п.1. отчете нужно заменить все Сделки на полученные в п.2. минимальные даты РТУ.
Я правильно понял Вашу задачу (в том, что касается группировки по Дате)?
Теперь о разбивке на БУ / БУ+УУ.
Признаки БУ и УУ есть в Сделке (Счет, Заказ и т.п.), в РТУ, в ПП.
Хорошо, если во всех документах по одной сделке эти галочки совпадают. Тогда мы можем ориентироваться на эти галочки в Сделке.А если эти галочки разные в разных документах по одной Сделке? Например, в Сделке БУ и УУ, в РТУ1 - только БУ, в РТУ2 - только УУ, в РТУ3 - БУ и УУ, в ПП1 - БУ и УУ, в ПП2 - только БУ и т.п. То как правильно разделить сумму остатка (которая по Сделке в целом) на виды учета?
-
Natali Dem
10 wrzesnia 2019
В начале - спасибо Вам за помощь в анализе задачи.
Если у СФ все подчиненные доки с разной датой, то выводим их отдельными строками. Сумма сделки в СФ - не учитывается (СФ - не имеет проводок). Так же игнорируем и подчиненные доки с ТОЛЬКО управленческим учетом (т.е. только УУ). На рисунке Ваш пример:

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

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

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

Красным выделены примеры оборотов, по которым нужно подвести ИТОГ (сальдо), но проблема в том, что 1. Это обороты, а нужно сальдо, с учетом входящих остатков и этих оборотов (Вы верно подметили - как в оборотке). Так же открытым остается вопрос ДАТЫ (на иллюстрации даты из оборотов за указанный период, но если учитывать входящие остатки, то - не решенная задача.)
Примечание: если понадобится, для решения задачи- мою обработку с оборотами могу выслать.
-
Sergey Nazarenko 11 wrzesnia 2019Поставьте в этом отчете дату начала = '0001.01.01' (в путое значение) и получите то, что Вам требуется - остатки на конец периода (которые равны оборотам +/- за весь период).
Aktualne zlecenia dla freelancerów w kategorii Automatyzacja zarządzania przedsiębiorstwem
Cześć! Szukam programisty BAS / 1C do stworzenia prostej i wygodnej aplikacji "pod siebie".Budujemy 9-piętrowy budynek mieszkalny. Księgowość działa osobno, dlatego program jest potrzebny nie do podatków, a do mojego osobistego kontrolowania finansów i budowy.Co program ma robić (główne):Pieniądze: widzieć, ile wpłynęło, ile wydano i ile jest w gotówce (gotówka / bezgotówkowo).Wydatki na budynek: dokładne rozliczenie, gdzie poszły pieniądze (materiały, wynagrodzenie dla budowlańców, sprzęt, projekty, pozwolenia itp.).Materiały: co kupiono i na co to poszło.Podwykonawcy i ekipy: ile im jesteśmy winni za wykonaną pracę i ile już wypłaciliśmy.Proste raporty: żebym mogła w każdej chwili otworzyć i zobaczyć rzeczywisty koszt budowy oraz ogólny stan finansów.Szukam specjalisty, który potrafi wszystko wyjaśnić prostym językiem i stworzyć program wygodny do codziennego użytku.Proszę, piszcie, czy robiliście podobne moduły finansowe i jaka jest orientacyjna cena takiej pracy.
Potrzebna jest centralna serwerowa system zbierania i przechowywania danych z Planfix, 1C, Meta Ads i Google Ads, a także webowy dashboard do ich wyświetlania i analizy. Wszystkie dane, historia zmian, obliczenia i agregowane wskaźniki muszą być przechowywane wyłącznie w serwerowej bazie danych. Dashboard nie powinien przechowywać ani duplikować danych biznesowych. Ma on uzyskiwać niezbędne informacje z serwerowej bazy przez API zgodnie z zapytaniami użytkownika i wyświetlać je w postaci KPI, wykresów, tabel i szczegółowych raportów.
Automatyczne wypełnienie sklepu produktami na Etsy. Szukamy kogoś, kto będzie mógł automatycznie wypełnić sklep produktami na Etsy. Sklep z odzieżą z nadrukami. Zajmujemy się drukiem anime na odzieży, ale na Etsy było wiele strajków związanych z prawami autorskimi, dlatego zmieniamy niszę i będziemy zajmować się drukiem na odzieży. Zadanie polega na uniknięciu problemów z prawami autorskimi i wypełnieniu sklepu produktami. Potrzebna pomoc w tym oraz jakaś podstawowa automatyzacja.
Cel: Zastąpić 1C elastycznym ERP z otwartym kodem. Potrzebna podstawowa logika handlowa + integracje z ukraińskimi usługami + możliwość podłączenia naszego agenta AI.Obowiązkowa funkcjonalność Podstawowa logika ERP Kontrahenci, rachunki, dokumenty przychodowe/wychodowe, ewidencja magazynowa. Sprzedaż, zamówienia, kształtowanie cen. Integracja z Nową Pocztą Dwustronna wymiana: tworzenie EN, drukowanie dokumentu, statusy dostawy. Obliczanie kosztów. Integracja z rynkami (dwustronna) Prom.ua – produkty, zamówienia, stany magazynowe. Rozetka – to samo. Epicentr – to samo (jeśli jest API – użyć, jeśli nie – przez uniwersalny konektor). Synchronizacja asortymentu z zewnętrznej bazy Produkty i ceny automatycznie pobierane z innej bazy (na przykład przez REST API lub połączenie SQL). Potrzebna okresowa synchronizacja. Integracja z naszym agentem AI Przez REST API Odoo. Agent będzie mógł czytać/pisać dane (na przykład generować opisy produktów, prognozować stany, przetwarzać zamówienia). Lokalizacja dla Ukrainy Plan kont, faktury VAT, PRRO (Checkbox), raportowanie.
Szukam uważnego i systematycznego asystenta do prowadzenia bazy klientów małej kawiarni. Potrzebna pomoc w zorganizowaniu prostego i zrozumiałego systemu ewidencji klientów. Na początkowym etapie może to być dobrze skonfigurowana tabela Google, Notion lub niedroga CRM. Rozważę wasze propozycje dotyczące najbardziej wygodnego i budżetowego rozwiązania. Co należy uwzględnić dla każdego klienta: imię i dane kontaktowe; źródło kontaktu, na przykład reklama, Instagram, rekomendacja; data pierwszego kontaktu; co klient kupił; jakie rodzaje i profile smakowe kawy mu się podobały; sposób parzenia kawy; historia i przybliżona częstotliwość zamówień; data następnego kontaktu; komentarze i ważne szczegóły korespondencji. Szukam przede wszystkim rozsądnego i ekonomicznego rozwiązania dla małego biznesu, dlatego drogie i skomplikowane CRM na tym etapie nie są brane pod uwagę. Na pierwszym etapie główny nacisk kładzie się na systematyzację informacji i przypomnienia. W przyszłości można będzie omówić samodzielne wysyłanie uzgodnionych wiadomości do klientów.


