Вход | Регистрация


1С:Предприятие ::

Метки:ТиС

Контроль за долгами контрагентов

Я
   Валентин
12.06.04 - 18:23
Вопрос следующий. Суейчас наша фирма предоставляет отсрочку платежа своим клиентам. Следующим ?ГЕНИАЛЬНЫМ? шагом шеф считает разделение суммы максимального долга и количества дней отсрочки по номенклатуре. Т.е. клиент берет товар примерно следующего стостава "товар1 на 100 р, товар2 на 200 р, товар3 на 300 р". Сроки оплаты для товара 1 - 1 день, для товара 2 - 2 дня, для товара 3 - 3 дня. Суммы максимального долга перед нами по товару 1 - 150 р, товару 2 - 200 р, товару 3 - 200. Воторым заходом через 2 дня тот же самый клиент берет "товар1 на 100 р, товар2 на 200 р, товар3 на 300 р". Предыдущая накладная не оплачена, и следовательно запещена отгрузка по товару1, товару2 но разрешена по товару3 (надеемся что оставшийся день он оплатит). В текущей конфигурации есть только два понятия максимальная сумма долга и дни отсрочки без какой бы то нибыло разбивки по номенклатуре. Вот теперь собственно вопрос - как эффективно организовать проверку на долг, проверку счета при проведении (т.е. удалять позиции которые нельзя отгружать). Вопрос наверное ламерский, но все же помогите пожалуйста. Шеф сам с трудом понимает что хочет.
 
  Рекламное место пустует
   Gavrila
 
1 - 12.06.04 - 18:32
На примере Укр. Торговли.
Сразу возникает проблема - нет возможности отслеживать взаиморасчеты по товарам, тобто нет возможности определить оплачен товар или нет(только по накладной). Я делал когда-то что-то похожее, но пришлось изменять регистр "ПартииТоваров" и соответственно проведение документов, для того чтобы отслеживать погашение долгов по товарам... геморрройно все это :)
   Валентин
 
2 - 12.06.04 - 18:35
Я собственно говоря думал про регистр "ВзаиморасчетыПокупателей" с введением дополнительного измерения КредитнаяЛиния. А на "ПартияхТовара" это как выглядит?
   Gavrila
 
3 - 12.06.04 - 18:37
(2) на партиях я добавил ресурс "Долг"
   Валентин
 
4 - 12.06.04 - 18:49
И как потом списывал при оплате? Если я правильно понимаю, у тебя тогда и приход денег должен ложиться на этот регистр (всякие там выписки из банка, приходные ордера...)? Смысл вопроса все же о контроле. Как контролировать долги и как проводить счет (который кстати ложиться на Регистр.РезервированныйТовар)? Как вообще организовать связку КредитнаяЛиния - Товар? Должен ли справочник КредитнаяЛиния подчинятся Номенклатуре? Или же элемент номенклатуры сам должен обладать данными о сумме и днях?
   SnarkHunter
 
5 - 12.06.04 - 18:50
Это песец...
   Валентин
 
6 - 12.06.04 - 18:52
(5) То есть до такой степени элементарно что описано в документации? Тогда поделитесь ссылкой на эту документацию.
   Gavrila
 
7 - 12.06.04 - 18:54
(4) мы с тобой скорее о разном говорим, точнее о разных конфигурациях. Я делал на типовой "ТиС для Украины" рел7.70.004.
"Регистр.РезервированныйТовар" "Справочник.КредитнаяЛиния" - этого там нет
   SnarkHunter
 
8 - 12.06.04 - 18:56
(6)Нет, это было сказано по другому поводу... Шеф что хочет получить в итоге?
   Валентин
 
9 - 12.06.04 - 19:00
Про РезервированныйТовар извиняюсь правильно  "РезервыТоваров".
Справочник.КредитнаяЛиния - планируется добавиться мной. Будет содержать информацию о сумме долга и днях отсрочки, конечно в случае если он понадобиться. Мне не понятно - как это все организовать? Нужен ли вообще этот справочник? Ведь клиенту может быть предоставленна отсрочка а может и небыть. Таким образом вообще не ясно как увязать Номенклатуру, Контрагентов и эти гркбанные дни и суммы...
   Валентин
 
10 - 12.06.04 - 19:04
(8) То что описано. Плюс много еще чего. Типа вывода акционного и бонусного товара из под процеса кредитования. Вообще автоматизировать процес выдачи бонусов. Контроль за соблюдением клиентами линейки товаров по которым предоставляется отсрочка. И прочие радости. В общем отдыхать он хочет с утра, днем и вечерос. А тут папы его работать заставляют...
Когда служил замполит у нас любил говорить "Я за вас свою работу делать не буду"
 
 
   SnarkHunter
 
11 - 12.06.04 - 19:12
Угумс... То есть, автоматизировав этот контроль, он наберет после этого человек ...дцать операторов, которые будут разносить суммы оплаты в разрезе номенклатуры, а потом перебрасывать эти суммы с одной номенклатуры на другую, потом на третью...
Что за товар-то?
   Gavrila
 
12 - 12.06.04 - 19:17
(9)Я так понимаю, что по каждому товару для каждого покупателя свои сроки оплаты и максимальная сумма долга. Если да, то подчиненный справочник понадобится в любом случае(подчиненный либо справочнику "Контрагенты", либо "Номенклатура") с ссылкой на другой справочник и параметрами сроков оплаты и максимальной суммы долга, можно попробовать приспособить один из уже имеющихся...
А дальше уже нужно думать как (откуда) получать инфу о сумме долга по товарам и т.д. и т.п.
   Валентин
 
13 - 12.06.04 - 19:19
Колгейт, жилет и прочая хрень. Перспектива мрачная конечно отоносительно 20 человек сверху. Тут как раз наоборот делается. Что бы все автоматически шло. Выписали счет, на его основании накладную - отгрузили. Сидим ждем оплату. Получили. Смотрим сколько денег пришло. Если все - то ок. Иначе начинаем гасить товар по накладной. Сперва с минмальными сроками отсрочки платежа, потом потом все остальное.

А последняя его идея (15 минут назад заходил, гениальный мой) - ввести приоритеты по оплате. Типа для одного клиента колгет приоритетней жилета. Для другого - наоборот.
   SnarkHunter
 
14 - 12.06.04 - 19:20
Юноши, посмотрите на шаг вперед... Пусть шеф пояснит, что он потом с оплатами будет делать... Это для начала...
   Валентин
 
15 - 12.06.04 - 19:21
(9) А куда захерачить приоритеты? Или например клиент не имеет таких прерогатив как отсрочка по товару. Или нафиг они ему не нужны (есть тут один супермаркет перед которым стелимся)
   Gavrila
 
16 - 12.06.04 - 19:22
(13) мда, повезло тебе
   Валентин
 
17 - 12.06.04 - 19:24
(14) Оплаты - контролировать. Вообще вся эта хрень задумывается для привлечения новых клиентов. Типа мы непомерно круты, и можем себе такое позволить.
   SnarkHunter
 
18 - 12.06.04 - 19:35
ЭТИМ клиентов привлечь?
   Валентин
 
19 - 12.06.04 - 19:39
Возможно. Но вопрос не в этом. Вопрос как эту хрень сделать?
А всякая там реклама и прочая ересь - не моя головная боль.
   SnarkHunter
 
20 - 12.06.04 - 19:49
Вопрос - в другом... Нужно ли это делать...
   Валентин
 
21 - 12.06.04 - 19:56
Нужно. Хотя бы за зарплату. В общем, конструктивные предложения?
   427
 
22 - 12.06.04 - 20:10
Самое интересное - все нах не нужно...
Я работал и работаю с парфюмерией и косметикой - на этой номенклатуре заипаются даже автоматически разноски делать и через месяц все тихо умрет

Обычно такие проблемы решаются через договора с разной отстрочкой (не более 3-х у каждого клиента) и максимальной деталировкой долга до РасхНакладной...
   Валентин
 
23 - 12.06.04 - 20:29
А проведение счета как? Или в договора еще номенклатуру пихать?
   Самоучка
24 - 12.06.04 - 20:37
А шеф твой очень интересную идею выкинул, для торговли и эффективного использования денежных ресурсов это очень актуально!!!
Идея есть, если ты программист, неважно как ты это будешь делать, но обязан! Не понимаешь его логики, наймите постановщика задач, он напишет тебе ТЗ и бедет всем хорошо: шефу, тебе, постановщику. Работай Валентин!!!
   SnarkHunter
 
25 - 12.06.04 - 21:09
(24)Идиотская идея... Бесполезная трата ресурсов... И, как правильно сказано в (22), все умрет, не родившись...
   Валентин
 
26 - 13.06.04 - 14:49
То что идея идиотская - ясно. Но также ясно что ее делать надо. Вопрос не ставился надо это или нет. Вопрос был как это сделать. Единственные подвижки в этом направлении были только у Gavrila и 427 (и то как-то робко). Не просил же за меня писать, просил подсказать как лучше. А филосовствование на хрена это надо - можно было бы вынести в другой форум.
Что ж, уважаемые профессионалы, простите ламера за то, что отнял ваше драгоценное время.
   Gavrila
 
27 - 13.06.04 - 15:18
(26) продолжим отнимать время :)
   Gavrila
 
28 - 13.06.04 - 15:50
(24) идея сама по себе не нова, вот только нормальных решений не встречал пока :(
(25) идиотской она будет в том случае, если ее использовать в каком нить "киоске торгующем пивом и сигаретами", если же у фирмы есть сеть дилеров либо просто постоянных оптовых покупателей, четкая ценовая политика, бонусы, кредитные линии(или как они там называются) и т.д. и т.п. то нормальное решение этой задачи, существенно облегчит работу отдела ответственного за работу с покупателями (или как он там называется) :)
зы: ИМХО
   427
 
29 - 13.06.04 - 17:57
Идей по реализации указанного в (0) - куча...

Но только все отомрет в связи с окуенным гемором на вводе информации и на ошибках пользователей...

А еще клиенты будут в платежах указывать совсем не то основание...
   Валентин
 
30 - 13.06.04 - 18:21
(29) Клиент платит по накладной. Накладная одна. Может содержать сколько угодно товарных позиций - но одна. При вводе оплаты - ошибка оператора - вещь неизбежная. Но за невыполнение своих обязанностей обычно штрафуют. Если клиент ерундой мается (маловероятно, сейчас многие берут и электронные выгрузки накладных)- тоже можно найти способы воздействия.
В общем ничего сложного в этой задче оказывается нет. Просто название и постановка страшная, а так - в принципе просто. Увязать между собой пять справочников и 2 регистра. Изменить алгоритм проведения и формирования счета на основании заявки.
Через неделю расчитываю разродиться готовым решением.
Всем кто принимал участие  - спасибо.
Отдельное спасибо - Gavrila
   427
 
31 - 13.06.04 - 19:50
С программистской точки зрения - задача простейшая....

Умрет на этапе эксплуатации...

"Но за невыполнение своих обязанностей обычно штрафуют.".... ню-ню.. Всех не уволишь... Если из 5 операторов уволить 3 - работа встанет...

Если твои действия приведут к гонениям на операторов - на 100 % они уволятся.. Но при этом тебе нагавнякают так, что мало не покажется...

Просто задача сия каждому лавочнику приходит в голову.... Но некоторые быстро понимают, что сделали гуано, а некоторые - после потери туевой хучи денег. И получения репутации конторы как .... ну промолчу... поберегем чужие уши...
   Валентин
 
32 - 13.06.04 - 20:43
>Умрет на этапе эксплуатации...
Все рождается, все умирает...
>Если из 5 операторов уволить 3 - работа встанет...
Их всего 2 ответственных за ввод оплаты. Сидят, в полтолок плюют. Текучка кадров среди операторов - вещь обычная. Кстати, среди тех кто набивает заказы - даже больше. Гонения на себя они сами же и вызывают.
> Просто задача сия каждому лавочнику приходит в голову....
Что-то не видно что бы было дано решение. Хоть где нибудь. Или лавочники не деляться своей информацией.
> Но некоторые быстро понимают, что сделали гуано
Никто не говорит что стремимся получить "Птичье молоко". Но есть потребность хотя бы такое гуано иметь.
> И получения репутации конторы как ....
Вот тут точно не понял. На клиентах это отражается только положительно. На операторах и програмистах - всех когда-то увольняют. Это не повод сидеть сложа руки и саботировать работу только лишь потому что получается гуано
> ну промолчу... поберегем чужие уши...
У Вас, как СУПЕРПРОФЕССИОНАЛА очень редко (судя по вашим постам) возникает желание быть коректным... По моему я уже извинялся за трату ВАШЕГО времени. Напоминать мне о том что Вы до сих пор обращаете на мой вопрос внимание, снисходя с Вашего Олимпа не с предложениями или нормальной конструктивной критикой, а базарным трепом - бестактность с Вашей стороны.
   427
 
33 - 13.06.04 - 22:58
Лучше, когда таких программистов увольняют сразу....
Меньше ипаты людям... Убивал бы таких реализаторов идей на месте...
Не хотел бы я работать в такой долбаной конторе... Где всех когда то увольняют..

Рассказывать после такого подхода не очень то и хочется...
Хотя эту задачу реализовывало большинство... и она есть в зачаточном состоянии в типовых... Сможешь разобраться - доделаешь... нет - тебя уволят...

Как говорится, успехов...

P.S. не одна тысяча фирм пыталась это сделать... И практически все от этого отказались - НЕРЕНТАБЕЛЬНО и не дает никакой информации для реального управления...
Но если есть желание в очередной раз построить пятиколесный велосипед с треугольними колесами - флаг в руки ...
 
  Рекламное место пустует
   427
 
34 - 13.06.04 - 22:59
Да... У сайентологов это работает....
   427
 
35 - 13.06.04 - 23:19
А насчет реализации...
У меня сейчас клиент - 14000 наименований, сотня покупателей постоянных... Реально отслеживать состояние оплаты по каждому товару - невозможно...
Все сделано через договоры (РасхНакл) и ВидДоговора...
Скидка идет по клиенту и зависит от суммы покупки за предыдущие 3 месяца...

И то мороки вагон с разноской оплаты...
   Валентин
 
36 - 14.06.04 - 09:07
(33) >Лучше, когда таких программистов увольняют сразу.... Меньше ипаты людям...
Спорно, но возможно.
> Где всех когда то увольняют..
Наверное и есть конторы где никого, никогда не увольняют. А только набирают.
> Рассказывать после такого подхода не очень то и хочется...
Вообще-то подход был да в (0). Если и такая постановка вопроса Вас, профессионала, не устраивает, то я уже и не знаю куда понятнее спрашивать.
> Сможешь разобраться - доделаешь
Думаю, что смогу
> А насчет реализации...
Другими словами надо пять постов откровенной ерунды, размышлений о жизни и моих возможностях, для того что бы хоть что-то сказать. Причем это что-то оказалось типовым решением. Не самым эффективным с моей точки зрения.
Уважаемый 427. Мне меньше всего было интересно Ваше отношение к идее, еще меньше Ваше мнение о мое конторе и обо мне как программисте. Вопрос стоял как реализовать описаное в (0) эффективно. А утверждение что это все "гуано" ... Так можно было сказать и RTFM. Лицо бы умным осталось...
   Z1
37 - 14.06.04 - 09:42
(0) Лучше давать отсрочку на всю накладную чем на строку накладной.
( лучше с методологич точки зрения а не программной - это будет более понятно
клиентам).
Решение отдельный регистр по отсрочкам.
Постулат Взаиморасчеты  отдельно, отсрочки отдельно.
Постулат два отсрочка дается "хорошим-проверенным" клиентам.
Расходные накладные увелич значения по регистру долг отсрочки ( счета резервируют если в счетах предусмотрен резерв товаров).
Отдельный документ (специальный) уменьшает долг отсрочки.
Документы уменьшения создаються автоматически обработкой - для их создания можешь использовать всю фантазию очередности погашения твоего шефа.
Ну и 2-3 отчета показывающие всю картину.
В расх накладной реквизит ПоследняяДатаОплаты - реквизит шапки ( для тебя реквизит многостроч части ).
Мой регистр отсрочек :
Измерения
Менеджер
Клиент
ДокОтсрочки ( расх накладная )
Ресурс
Долг

Для тебя еще будет измерение строкадокумента ( для строки документа дучше создай свой ID), вместо менеджера товар.
Три года полет нормальный.
   427
 
38 - 14.06.04 - 10:47
(37) до тебя 36 постов ему пытались доказать, что отслеживание оплат до накладной - оптимальный вариант... Так что тебя скорее всего тоже пошлют .... Разве ты не понял, что человеку НУЖЕН дурдом...

Кстати, а на фига менеджер в измерениях? Или отслеживаете по менеджеру? У него что, оплата от этого зависит?

Ну, в ТиС кроме регистра для быстрого извлечения итогов вроде еще ничего не придумали.... Но ежели он попрется с каждым товаром в регистр ... У меня средняя накладная от 200 до 600 строк... У тебя один док - одна запись в регистре. При средней накладной даже в 200 строк регистр будет иметь 200 записей на расх накладную + 200 записей на погашение... А если клиент оплачивает частями?...

База у него сдохнет через пару кварталов... просто по объему... Хотя если 15 клиентов и пять товаров - будет жить...

Впрочем, сдохнет она раньше ... и дохнуть будет открытие периода.... Через 3-4 месяца при нормальных объемах в силу заднего ввода и штатного косячка ... который не исправляет даже перепроведение. При ручном разбиении суммы оплат...
   Z1
39 - 14.06.04 - 10:57
(38)Каждый менеждер имеет  макс сумму ( по всем сделкам) долга - назначают сверху ,
каждый клиент также имеет свою макс сумму долга.
При проведении расх накладной надо проверять на превышение по зашкаливанию отдельно по менеджеру и отдельно по клиенту.
Отсрочку менеджер может дать только "своему" клиенту. "Свой" клиент может меняться по времени. По регистру легче отслеживать ошибки, неточности.
Ошибки редкие но возникают в основном из-за коллизий в УРБД.
Всю дискусию не читал. Решение в 37 приведено на 4/5
Пусть 1/5 сам додумает.
   Crystalizer
 
40 - 14.06.04 - 11:58
Валентин: ты писал базы данных с нуля сам?
   Ариф
41 - 14.06.04 - 14:01
Мы делали с сотрудниками подобное. Но зато срубили не плохо с них. Но и помучались пока тестировали. Клиент рад до ушей.
   SnarkHunter
 
42 - 14.06.04 - 14:13
Интересно, что именно вы делали с сотрудниками...
   Валентин
 
43 - 14.06.04 - 14:22
(41) Как сделано? В общих чертах...
(40) В наследство досталась. От предыдущего профессионала.
(38) Понятно что с регистрами погорячился. Сам это теперь вижу.
Хотя почему все так уверены что каждый товар ложится на регистр? На регистр ложится элемент справочника описывающий условия отсрочки. И это не регистр ПартийТоваров с его размерами. Групируем накладную по этим элементам и из 200-600 строк остается - 2-10. Если клиент гасит частями  - то единственное где будет набор геморроя , если оплата по выделенному товару не полная. Т.е. на каком-то этапе за товар2 заплатили 20%, потом еще 20%, потом еще 60. В остальном все нормально.
>Через 3-4 месяца при нормальных объемах в силу заднего ввода и штатного косячка ...
Каковы должны быть "нормальные" объемы чтобы возник геморой? 20 тысяч наименований на 3 тысячи клиентов, в среднем 800 накладных отгрузки в день, достаточно или нет?
При каких условиях возможно увеличение/уменьшение задолженности задним числом?
(как-то не встречалось такое)
И что это за штатные косяки (просто пару пример для убедительности) от которых уже ничего не спасает?
И просто что Вы понимаете под ручным разбиением суммы оплаты?
   Z1
44 - 14.06.04 - 14:24
(42)Скорее всего сотрудник = менеджер (тз 37) и далее за просрочку платежа тем или иным способом вешали долг клиента на сотрудника.
   Z1
45 - 14.06.04 - 14:39
(43) Так тебе pit и говорит выдели эти 2-10 строк в отдельную накладную
и делай отсрочку на всю накладную
ну например так ( макс( колво дней по всем строкам) или мин(колво дней по всем строкам) ). И тогда либо погасил долг по всей накладной либо нет.
Так будет на порядок проще отслеживать отсрочки. Твоя схема будет работать но ее чуть сложнее сделать с точки зрения программиста, неправильно с методической.Например  объясняться с клиентом или менеджером ( которого ставят на деньги ) что мы зачислили оплату только по какой то строке а по какой то нет ну это очень сложно после двух трех таких разборок сам поймешь.
   Валентин
 
46 - 14.06.04 - 15:52
Т.е. по каждому счету порождать несколько накладных с разными условиями оплаты?
Правильно понял?
P.S. Что такое pit?
   427
 
47 - 14.06.04 - 18:07
(45) не взлетит... У (0) постановка другая.... немного ...
   BorisG
 
48 - 14.06.04 - 18:23
(47) Тебе не надоело сражаться? Ну не хотят слушать, на надо...
   Gavrila
 
49 - 14.06.04 - 18:27
одни говорят, что летать хотят, другие им в ответ советуют как правильно из окна прыгать, третьи рассуждают о законе всемирного тяготения :)
 
 
   Валентин
 
50 - 14.06.04 - 18:38
И хоть бы кто аргументировал бы хоть как-то.
Может просто я такой тупой, что не вижу очевидных вещей? Что на (43) ответа от 427 так и не дождался. (48) - поделились очень дельной мыслью, имеющей непосредственное отношение к (0).
Профессионализм определяется количеством неинформативных постов? Или просто общей активностью на форуме?
   Z1
51 - 14.06.04 - 18:43
(43)  427 = pit
Ответь всего на один вопрос одним предложением : Ради чего Вы все это хотите
сделать ( как написано в 0 ) ?
(46) В принципе да. И отсрочка по накладной либо погашена либо нет.
(47) Да в (0) схема еще та - одна расход. накладная дает разные отсрочки по
разным строкам и плюс частичная оплата по накладной.
Какие строки считать оплачеными частично оплаченными, какие нет да еще с учетом (13) и динамики (13) во времени.
Т.е все считать до строки, а если еще есть изменения накладных задним число то вообще труба.
Вообщем сделать как в (0) не проблема ( и уже все сказано как)а вот проблема сможет ли фирма  с этим успешно работать вот это вопрос.
   Валентин
 
52 - 14.06.04 - 18:53
(51) С моей точки зрения - смягчение условий по важным клиентам. Но я не начальство.

Действительно, все уже сказано. Всем спасибо, кто принимал участие. Если что не так - извините.
   Z1
53 - 14.06.04 - 19:01
(52) Не всегда надо во всем соглашаться с начальством.
Ведь виноватым то ты окажешься ( если что не так).
Можешь распечатать эту ветку своему начальнику.
   BorisG
 
54 - 14.06.04 - 19:22
(48) Видишь ли... профессионализм не на форуме определяется. Это раз.
И есть два. Золотое правило форумов интернета. Никто никому ничего не должен. Похоже ты этого не понял. Мне лично повторять еще раз уже сказанное и очевидное неинтересно.
Этот вопрос вообще-то не технический. Правильно уже отмечено. Для начала нужно разложить по полочкам постановку учета. А это... извини уже консалтинг. Со всеми вытекающими.



Список тем форума
Рекламное место пустует   Рекламное место пустует
Чтобы обнаруживать ошибки, программист должен иметь ум, которому доставляет удовольствие находить изъяны там, где, казалось, царят красота и совершенство.
Фредерик Брукс-младший
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.
Ветка сдана в архив. Добавление сообщений невозможно.
Но вы можете создать новую ветку и вам обязательно ответят!
Каждый час на Волшебном форуме бывает более 2000 человек.
Рекламное место пустует