Взаимосвязь операций с товарами и оплатами товарных операций : КИС Lack & УС Land

Добрый день Андрей Николаевич!
С наступившем Вас новым годом)) Всех благ, здоровья, удачи во всех начинаниях))

Вопрос по отчету "ожидаемая оплата" :
в отчете в колонке "видОпл" у некоторых контрагентов стоит статус "реал", но они не должны, а у некоторых стоит "долг" но они тоже расчитались и акт выверки показывает сальдо "0". Как сформировать объективный отчет по "Ожидаемое поступление денег за отгруженный товар"

Спасибо

Добрый день Алексанр Николаевич!.. и Вас с праздниками! Вообще вопрос поднятый Вами по конкретному древнейшему (не сразу догадался какой), примитивному и "правильному" отчету гораздо его шире, а посему выделил его в отдельную тему. Кроме того понятия УС Лэнд, связанные с тематикой могут вызвать много возражений у пользователей "канонических" систем. Довольно подробно технологии описаны в учебнике по финансовым операциям - приложу его здесь, а пока позвольте кратко ответить на Ваши вопросы:

В данном отчете, потом, опишу его анализируются ТОЛЬКО операции (накладные - атрибут отсрочка платежа) отгрузки и СВЯЗАННЫЕ с ними платежные документы, как следствие данный отчет нельзя пытаться "стыковать" с аналитикой по всем видам документов с клиентом.

Как устанавливается признаки на суммы отчета?

Для анализа имеем по накладной:
1. Дату отсрочки платежа
2. Сумму накладной
3. Список привязанных к ней оплат - с датами и суммами.

В отчете запрашиваем период оплат и анализ производится от "адама" до конечной даты периода. Если:

1. Все связанные оплаты с накладной произведены до конца периода, то "нал.", т.е. полностью оплачено

2. Накладная до конца не оплачена, но срок по отсрочке ещё не наступил, то "реал"

3. Накладная до конца не оплачена, но платежи уже просроченны, то на сумму просрочки "долг"

В акте выверки (оборотках) анализирутся:

1. ВСЕ виды операций с клиентом
2. Игнорируется понятие "привязки" оплат к товарным накладных

... и данные отчеты стыкуются только если у клиента только (отгрузки и четко связанные оплаты) ...

НИКАК!!! Без пунктуального и полного связывания платежей с товарными документами.


Провакационное лирическое отступление! Уважаемый FinSoft как то описывал технику желаемого Вами анализа в своей системе - её суть: сканируем период от "адама" до конечной даты, берем накладную и "закрываем" её найденными платежами, а затем переходим к следующей накладной и "так же", но это "бред"! Например, как отмечено выше у клиента кроме отгрузок и платежей по ним могут быть и другие операции, например возврат. Во вторых у Вас могут быть на разные типы товаров разные отсрочки и возможно погашения более поздней накладной должно быть произведено раньше и etc...

Вложения

hand_fin.7z (2.55 Мб, 99 просмотров)

Привет, Андрей. С прошедшими праздниками.
Придется прокомментировать твою реплику в адрес программы ФинСофт:КупецЪ.
1. Расчет ведется не от адама, а от ближайшей границы закрытого периода. Периоды можно закрывать с произвольным интервалом, исходя из ощущений комфортности работы с программой. Вначале программа определяет по границе задолженность по расчетам с контрагентом, затем подбирает платежные или долговые документы (накладные) на сумму долга, в зависимости от того, кто кому должен. А потом уже от этой границы и до конца заданного периода рассчитывает перекрытие отгрузок и оплат. Расчеты выполняются в разрезе контрагент-фирма-раздел расчетов.
2. Возвраты учитываются автоматически. Прежде чем перекрывать отгрузки и оплаты, программа определяет, какие отгрузки соответствовали возвратам, и уменьшает их. Возвраты учитываются в последовательности, обратной хронологической. Сейчас можно еще явно указывать, по какой отгрузке делается возврат. Этот вариант имеет понятные неудобства, он был введен с целью всяких манипуляций с корректировочными счетами-фактурами, для обычных возвратов его не используют.
3. Оплаты и отгрузки перекрываются автоматически в хронологическом порядке, но можно и явно привязывать документы друг к другу. Отношение многие-ко-многим, то есть одна оплата может закрывать несколько отгрузок и наоборот. Этим механизмом пользуются, хотя я рекомендую его только в крайних случаях (чехарда со сроками оплаты). В большинстве ситуаций лучше полагаться на автомат. При ручных привязах может потребоваться отслеживать всякие возвраты по оплаченным документом с помощью специального отчета, и разбираться с ними вручную. Автоматический расчет сочетается с явной привязкой документов. То есть автомат обрабатывает только те документы, которые явно не привязаны или привязаны частично (на часть суммы).

Насколько я знаю, активно пользуются отчетом "План исходящих платежей". Аналогичный отчет для покупателей "План входящих платежей" востребован в меньшей степени. В этих отчетах задается список контрагентов, по которым надо провести анализ, и количество дней от заданной даты (обычно текущей), когда должен наступить срок оплаты. В отчет выводятся неоплаченные накладные с указанием полной суммы и суммы неоплаченного остатка. Там же можно отметить, какие документы хотим оплатить, и автоматически сформировать платежку или кассовый ордер.

Привет! Тебе здравия и благополучия!

Вячеслав, как ты правильно понял - был "камешек" в твой огород! Извини, но описал "твою" технику, как помнил, т.е. не полностью, хотя суть её от этого не меняется и я считаю её ресурсоёмкой и недостаточно гибкой... Будет корректно, если данное сообщение вынесешь и в свой раздел, а там по наличии времени постараюсь "тебя" попинать.

Скажу больше, впрочем, как и по ряду других алгоритмических подходов... У меня в ряде систем, создаваемых до 1994 года (и даже пару лет в (то время) Laks) были такие отчеты - с данным алгоритмом анализа долгов, но в то былинное время в основном была "полная реализация", практически не было возвратов, да и объем ведущейся инфы был мизерным

Спасибо за подробное и обстоятельное пояснение!!!

Сейчас кризис, работать надо...
Сколько считается отчет, специально не засекал. Быстро, не напрягало. Ну, несколько секунд в многопользовательском режиме. Сколько контрагентов смотреть хочешь. Там ведь из базы дергается только необходимая информация. Основные затраты на обработку возвратов. Объем данных не такой маленький. Компы сейчас мощные, код компилированный. Работает давно, вопросов особо никаких не возникало.

Закончилась алкоотчетность, разобрался с текущими "железячными" проблемками, накопившимися после "отпуска", посмотрел потребности клиентов в развитии системы (видно по версии 1502)... и понял, что сейчас самое время отдыхать и повышать свой профессиональный уровень пока пользователи привыкают к новой реальности.

Часто об этом упомянал: Не столько ты, сколько разработчики при "1С" на протяжении многих лет пользуют "старые" подходы к проектированию системы и по мере появления новых потребностей пользователей "нахлобучивают" на эти техники многие заплатки... что уже и переписать техники не представляется возможным.

Что по мне, то "безжалостно" удаляю технологии из системы по мере выявления в них недостатков или отсутствии в них потребностей, т.ч. при постоянном развитии системы она продолжает быть маленькой, но универсальной, а я всегда готов легко в неё добавить новые подсистемы... в частности, что ты описал:

1. Беру из "мусорки" удаленный в 1998 году контур "расчета долга по фактическим операциям" и переписываю его под измененные структуры данных с учетом накопленного опыта проектирования (программирования).

2. Продаю его, как уникальную (нужную единственному пользователю) задачу по возможности не засоряя ядро системы... или никто не запрещает внешнему разработчику на любой системе программирования написать данную задачку, как внешнюю программу (я сейчас такие вещи так же выношу из УС Лэнд во внешние программы, устанавливаемые тому ЕДИНСТВЕННОМУ пользователю).

Недавно делал небольшие обработки для 1c77 и 1c8 для импорта накладных у пользователей своей системы электронных заказов. Нужно то было прочитать и сохранить код поставщика в дополнительном параметре товаров. Так вот, в 3 основных конфигурациях (1с77 Торговля и склад, 1с8 Розница и 1с8 Управление торговым предприятием) организация хранения этих параметров была сделана по разному (!) - то через подчиненный справочник, то через табличную часть справочника, то через регистр сведений. А если сравнить 1с77 ТиС и 1с8 УТП, то, по сути, это совершенно разные программы, написанные практически с нуля.

Я сам придерживаюсь мнения, что программа должна развиваться эволюционным путем. Самое худшее, что можно делать, это переписывать отлаженный код. Инвестиции в разработку должны сохраняться и накапливаться. Основная причина переделок, на мой взгляд, заключается, во-первых, в отсутствии у разработчика достаточно полной информации о предметной области на момент начала разработки, и, во-вторых, в попытках включить в программу изначально конфликтующие между собой алгоритмы из разных предметных областей. Соответственно, я придерживаюсь таких правил при разработке: не начинать реализацию, пока не ясна вся картинка будущего функционала; не писать под конкретного пользователя, а рассматривать задачу с точки зрения специфики конкретного вида бизнеса; сосредоточиться на ограниченном круге центров компетенции (видах бизнеса).

Добрый вечер Вячеслав!

У нас не столь сильно отличаются подходы к разработке и развитию наших систем, сколь отличаются подходы к их продвижению и позиционированию...

Не уверен, что я прав, но твой путь в развитии системы, её продвижении и позиционировании сильно повторяет мой до 2008-2010 года, а иногда до 2000 года (в основном технологические подходы). До 2008 г. система, тогда КИС Lack активно расширялась за счет автоматизации новых бизнес технологий, усложнялись межмодульные взаимосвязи, каждую новую задачу пользователей стремился сделать максимально универсальной и полезной большинству и других пользователей системы. Система стала громоздкой и сложной в освоении - тогда, при наличии большого числа крупных пользователей "мелочевка" и её проблемы были мне не очень важны. Когда в 2010-2011 государство "отобрало" у меня основных крупных клиентов с данным подходом крупно "сел в лужу":

1. Крупняк был уже автоматизирован, к тому же программные технологии были для них устаревшими;

2. Небольшие фирмы были неготовы вкладываться в освоение данного "монстра";

3. Уже малоквалифицированные пользователи активно возражали против огромного числа не нужных им режимов, но при этом столь же активно противились примитивизму некоторых предлагаемых им подходов.

Всё это заставило меня пойти по пути упрощения, уменьшения системы, выбрасывая или переводя в уникальные программы эксклюзивные режимы... пока жизнь мне доказывает правильность данного современного тренда. Как ты развиваешься - тебе решать, ведь это твой путь!