Взаиморасчеты в разрезе торг. агентов.... #140042

Помогите подобрать правильное направление. Стоит задача учета взаиморасчетов с покупателями в разрезе торг. агентов. Причем нужно отслеживать историю, т.е. с 1 по 10 работал один торг. агент, а с 10 по 30 другой. Конфа типовая ТиС 938. Как лучше сделать? Если измерением, тогда получаются увеличенные обороты, если реквизитом договора, история теряется. Уже сломал всю голову, помогите плиз

Дополнительный регистр заведи. Вт нём и учитывай взаиморасчеты как твоя левая нога захочет.

А нельзя договорами:Договор Петрова....

Смотри в сторону проектов. Должно получиться.

не понял, почему при добавлении измерения "Агент" получаются увеличенные обороты?? Обороты будут не увеличенные, а разрезанные по агентам {Контрагент, Договор, Агент}А в принципе измерение наверное лишнее, вставьте в документы, влияющие на взаиморасчеты реквизит "Агент", а потом вытащите его из "КредДокумент". Оплату как клиенты делать будут? В документы оплаты как-то вроде не очень красиво агента вставлять.Если работаете по основному договору, то послушайте , ничего больще и не надо будет.зачем еще регистр, если есть уже полноценный регистр?

а впрочем в документы оплаты и не нало будет, только в "Реализация"

А закрывать его ты как собираешься?

Мысля такая есть, но уж больно удобно учитывать это хозяйство в стандартных отчетах. Пытаюсь найти приемлимый вариант, хотя, мне кажется и в отдельном регистре такая проблема встанет. По договору Сидорова была отгрузка, по договору Петрова оплата. Как быть? см. для 2.(4,5) Повторюсь, реализацию делал один агент, оплату принимал другой. Абсолютно рабочая ситуация, т.к. товар клиентам отдается с отсрочкой платежа в 30 дней. А за 30 ситуация меняется. Теперь смотрим, почему будут увеличенные обороты:Отгрузка по Сидорову на 1000 руб. Оплата по Петрову 1000 руб. Сидоров не закрылся, Петров не закрылся. Я думаю не стоит забивать на правила проектирования регистров.

Поддерживаю . В доках реализации в поле "проект" заводить менеджеров, а также юзать "Отчет по проектам".

В догонку. Да никто и не пытается в документы оплаты вставлять дополнительные регистры, впрочем и в документы отгрузки тоже. Торговый агент - это переодический реквизит справочника договоры, на дату проведения я точно знаю кто из агентов закреплен за данным клиентом.

Человек ведущий кассу должен при внесении информации в ИБ в твоем случае орентироватся не на то кто принес деньги а за что он принес если за продажу Сидорова то выбирать договор Сидорова если за продажу Петрова то выбирать договор Петрова несмотря на то что деньги физически принес Иванов.

чем тебе проекты не угодили, не пойму.А главное, ничего делать не надо :)

Именно так. А если клиент платит за все чохом, то и сумму разбивать. Теперь оталось кассира застатвить делать это (Доп. работа, которая кассиру нах. не нужна!).

Реквизит регистра (коим является "Проект") не очень катит. Вот ответьте мне пожалуйста на вопрос, как мне получить остатки взаиморасчетов по торговым агентам.

Касир лицо подчиненное если фин/ком директор решат что необходимо отдельно вести договора по кажждому агенту то касира никто спрашивать не будет хочет он это делать или не хочет. ему это просто вминят в обязаность.

Послушай, попробуй с проектами, ничего нигде не меняя. Просто попробуй смоделироать технологическую цепочку с указанием проектов в доках отгрузки/оплаты. Сделай отчет. Посмотри. Может все уже изобретено?

Вполне возможно, потому и за советом пришел :) Не сходиться задачка. Да автоматом можно это сделать, автоматическое закрытие само по себе не проблема. Делать то в любом случае надо будет. Проектами тут точно не обойдешся. Впереди расчет заработной платы, ну уж очень не хочется делать это дело на проектах. Правильно понимаешь. Мысли появились, в общем за это спасибо. Все таки может быть я действительно в неправильном направлении иду, просто все уже привыкли к ведомости по взаиморасчетам....

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

Пробовал, строил, не подходит. Вернее именно "Проекты" не подходят. Но буду думать в направлении отдельного оборотного регистра. Что в принципе похоже на логику проектов. А проекты не подходят по той причине, что здесь должен быть завязан справочник ФизЛица (конкретные агенты), не хочется портить стандартный механизм Проектов.

Может быть кто-то реализовывал у себя такое? Поделитесь схемой реализации. Основная задача - история работы агента с торговой точкой (т.е. в моем случае справочник Догворы). В первую очередь учитывать оплату, учитывать реализацию скорее всего нужно тоже учитывать. Для плана.

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

ну сделай доп. реквизит (тип спр. Физ. лица) в спр. Проекты, связывающий сотров с проектами. А как интерпретировать проекты - дело конкретной прикладной задачи... т.е. твое дело :)

Дело в том уважаемый что те советы которые дают остальные учасники мне не кажутся более правильными чем мой. даже если вести учет в разрезе Проектов то все равно так или иначе касир будет вынужден ВЫБИРАТЬ РУЧКАМИ это доп. поле и также разбивать сумму на несколько сум если пришли деньги сразу на несколько агентов. короче не вижу принцыпиальной разницы между моим советои и советом вести учет в разрезе договоров.....

+ вести учет в разрезе договоров.....= вести учет в разрезе проектов.....

Если речь идет о взаиморасчетах то тут по определению не может быть регистра оборотов, используя регистр оборотов как ты сможеш ответить на вопрос : на 26_11_05 кто каму сколько должен мы контрагенту или он нам?

"а Zam сказал, что приход может быть по одному агенту, а расход - по другому" Под этим он имел в виду что деньги физически вносит в кассу человек который мог вообще ни чего не продать. как разрулить эту ситуацию я писал в .

что противоречит понятию взаиморасчетов?"человек, ведущий кассу должен вести кассу и ВСЁ"- это утверждение верно только если говорить к крупном предприятии где все бухгалтеры разбиты по участкам, на практи же многие бухгалтера отвечают одновременно за все участки (на то они и главные)по поводу "и что будет в противном случае" вообще не думал что придется коментировать, т.к. это полный бред, но видимо придется: касир так или иначе отражает поступление денег в кассу и какая разница сделает он это через один договор или через три разных договора, можеш не отвечать я сам отвечю РАЗНИЦЫ НИ КАКОЙ НЕТ. и никаких преимуществ у кассира нет (в плане мухляжа) при многодоговорной схеме перед однодоговорной.

Задача сформулирована так как она сформулирована. И виденье взаиморасчетов в разрезе контрагентов оправдано т.к. наверняка у этих самых агентов зп зависит от этих самых взаиморасчетов."какое отношение имеет количество заключенных договоров на реализацию агента Васи Пупкина к взаиморасчетам с клиентом?"количество договоров на взаиморасчеты конечно не влияют (этого я собствеенно и не писал) на взаиморасчеты влияют только фактически совершонные сделки купли-продажи чего либо. вопрос лишь только в том как отражать в программе эти самые сделки, через один договор или несколько вот и все.

Считаю что задача поставлена корректно и оправдано (писал собственно об этом в ). Кроме того считаю что решение данной задачи вполне может быть выполнено типовой конфигурации без всяких дописок если реквизит Менеджер справочника Договоры-типовое (плохо помню торговлю 938, 7.7. не юзаю давно).

Не пойму что мы спорим. Во взиморасчетах есть 2 операции:1.Реализация2.Оплата1. При реализации документ "Реализация" пишется в регистр "Покупатели" как "КредДокумент". Из него можно вытащить агента, если добавить его в "Реализация"2. Оплата. Здесь возможке простой случай, когда документы оплаты не правятся и долги контрагента гасятся в хронологическом порядке, документы каких агентов будут оплачены решит ТИС. Более сложный случай, когда надо конкретно указывать, что оплачивается. Здесь тогда надо организовывать подбор неоплаченных документов. а если реализация не в разрезе агентов, тогда какие взаиморасчеты в их разрезе?? непонятно. Есть организации, где агентам начисляют зарплату за оплаченную отгрузку. Автор бы лучше толком сказал, что ему вообще надо

Афтар исчез давно:))

Отгрузка по Сидорову на 1000 руб. Оплата по Петрову 1000 руб. Сидоров не закрылся, Петров не закрылся. Я думаю не стоит забивать на правила проектирования регистров.И что ? причем здесь уже будут регистры или не регистры? Это уже вопрос организации платежей. Не закроются-лягут деньги на аванс, потом закроются. Они не закроются при такой оплате ни на регистрах, ни на , извините, текстовых файлах.Мне кажется, что вам вполне хватило бы предложения

Зря стараешся автор ушел от нас."Отгрузка по Сидорову на 1000 руб. Оплата по Петрову 1000 руб. Сидоров не закрылся, Петров не закрылся."я как раз предлагал закрывать регистры в ."Я думаю не стоит забивать на правила проектирования регистров."- так думать не допустимо. ИМХО.

Кто отрицает, что регистры должны закрываться? Это требование экзамена 1с. Пусть тогда учитывают по основному договору, агента вытягивают из реализации, а оплата на кого распределится, тому и повезет. Всё закрывается, регистры целы.

Как раз в последнем варианте можно использовать проект

Все сказанное - фигня с точки зрения самой поставленной задачи...Ибо на 99% основная цель (кстати, не названная) - это оценка работы каждого агента для начисления агенту ЗП или бонуса .....    если начисление делается исходя из профита каждой сделки - это будет откровенная туфта в силу особенностей построения партионного учета в ТиС. Просто задним числом поменяли местами в журнале пару расходов... И прощай бонус... В силу перераспределения партий... Умные манагеры будут надувать ЗП от профита "своим" агентам....    Если начисление делается исходя из суммы отгрузки и суммы поступившей оплаты - это будет сильная зависимость от правильности работы тех промежуточных звеньев, которые агентам не подчиняются (например, правильность работы лица, разносящего оплату)... А учитывая, что клиента НЕВОЗМОЖНО заставить правильно разносить СВОЮ оплату по поставкам (ему это на.... не надо - учитывать ЧУЖИХ агентов). Поэтому клиент кидает деньги как ему удобно. Если же есть еще разные договора с разной отсрочкой оплаты и дисциплиной их закрытия - всЁ, тушите свет и ищите Обезьяну С Гранатой, она вас вылечит)... Не будет достоверности - будут скандалы....P.S. менять надо принцип оплаты ....

я полностью согласен, так как начислять зарплату по оплаченной отгрузке и при этом кидать оплату в кучу (на усмотрение глобальному модулю ТИС)-это абсурдно. Насчитали зарплату, а через 10 мин все может перевернуться.Если невозможно обеспечить привязку в разноске оплаты, то может программно пропорционально делить ее между агентами (по доле неоплаченного долга)? хотя как-то мне не нравится. По предоплате-та же фигня, да здесь видимо и не тот случай

Как дискуссия :) Спс за внимание к ветке. А ушел я вчера из ветки, ну дык воскресенье, семья :)to pitРасчет зарплаты - это 50% общей задачи. И в общем-то можно сказать практически главная часть этой задачи. Ну да, я ее не незвал, просто не хотелось грузить полностью всей задачей. Люди и так вон спорить начали :) Что касается зарплаты от профита сделки. На данный момент так и есть, но будем менять, изначально казавшаяся удачной идея на практике себя не оправдала. В первую очередь в силу специфики бизнеса. По факту торговый агент не знает себестоимость товара, и соответственно не знает наценки. Не видя цели невозможно идти к ней :) Получается с его точки зрения - работай хорошо и будешь получать хорошо, а вот сколько это самое хорошо, большой вопрос для него :) Когда он будет точно знать, что за выполнение таких-то и таких-то задач он будет получать столько и столько имхо будет понятнее и проще.Что касается работы промежуточных звеньев. У нас в общем-то потоковая торговля. Договор как правило один, или же в случае нескольких торговых точек - на каждую точку свой. Проблемы возникают только в случае когда не совсем понятно на какую точку разносить оплату по банку. Но это уже решается другими методами. Больше проблем я тут не вижу, во всяком случае пока. Вполне возможно в будующем изменение условий работы с клиентами, но тогда уже будет видно, к сожалению сверхуниверсальный алгоритм боюсь не придумать :)to Лёвыч и ОператорПКВ общем, прихожу к выводу, что все таки к взаиморасчетам привязаться не получиться. Если делать так, как хотелось бы видеть - регистр можно просто похоронить, если делать так как правильно с точки зрения типовой ТиС регистр Взаиморасчеты, тогда нихрена не понятно будет. По любому придется делать другой регистр, и причем, все таки оборотный. Для данных по реализации продукции (скорее справочно, потому как для расчета зарплаты врядли пригодиться) скорее всего регистр продажи чуток подправить. Для отражения оплаты - отдельный регистр оборотный (в принципе, я думаю с учетом возможных изменений в расчете заработной платы - так будет тем более правильно). Для получения информации по долгам клиентов закрепленных за конкретными торговыми агентами у меня на данный момент существует обработка заточенная под работу торг. агентов (выставлениние претензий, формирование актов сверок, письм всяких и т.д. если нужно в пакетном режиме), так там информация берется из регистра взаиморасчетов на определенную дату (просто смотрю в алгоритме, за каким договором закреплен нужный нам торг. агент и долги по этому договору вывожу). В общих чертах скорее всего так. И вообще, мое мнение по поводу кассира. Ну во-первых деньги у нас собирают сами торговые агенты, у них касса, КПК, все нормально :) Конечно банковская оплата остается на совести бухгалтеров. Я абсолютно против того, чтобы бухгалтер сама решала куда ей нужно закинуть сумму. Я просто знаю, что получиться если дать возможность кассирам или бухгалтерам выбирать документ отгрузки вручную (Это я как пример просто :))... Вот тогда точно поможет только обезьяна с гранатой :)(38,41,43) Постарался объяснить что мне надо, если не получилось, я сожалею, если есть еще желание помочь, могу попробовать подробнее объяснить. Хотя вроде в этом посте должно быть понятно что нужно.Немного не понятно, причем тут организация платежей. Проще всего сделать так чтобы все закрывалось, по регистру покупатели типовой ТиС все хорошо, но при этом данные для торгового отдела - будут не данными а просто набором цифр, и мы не облегчим работу, а еще усложним.В общем, чуть выше я прикинул варианты решения данной задачи. Может кто чуток подправит. Может есть подводные камни, которых пока не видно?

...гхм!Перебирал "сам лично и в состеве эскадрилии" множество вариантов.Самый удобный на наш взгляд - введение реквизита ТА(ТП) (Торговый агент, торговый представитель) в справочник Договоры.Тем самым мы не рушим отличный мехенизм (да, я говорю отличный по отношению к механизму написаному 1С :))), предусмотренный ТиС.По поводу разноски оплаты, поступившей "скопом" от клиента - поверьте, это нормально решается с клиентом.

Из всей дискуссии стало понятно, что ТиС - все-таки тупиковая разработка 1С.

В любом случае информация о ТА работающем с торговой точке храниться в реквизите справочника Договоры. Самое интересное начинается когда этот реквизит делаем периодическим. Сразу же стает вечный вопрос как быть...

Подскажите мне пожалуйста более лучшу конфу для торгового учета чем ТиС? Ну а так как предположим любая конфа потребует времени для заточки под специфику и определенного времени на перенос данных и внедрения, то так же и лучше чем УТ 10.2.6.Как вариант можно рассмотреть не 1С как платформу вообще. Но тогда стает вопрос по цене и прочим вещам. Из области "СуперМаз конечно круче чем Газель, но нахрен он нам нужен для доставки товара по городу".

Периодика в договоре - это цирк... и перегрузка системы....В любом случае надо для агентов делать нормальную систему оплаты с корректной оценкой из труда... В этой системе д.б. по возможности исключить субъективные оценки, возникающие в результате некорректной работы оценивающих звеньев....  Особенно при поточной работе....P.S. а этим на заказ занимаются некоторые фирмы, причем за неслабые деньги... Мотивация персонала - неслабая вещь....( она не тупиковая - она достаточно узкая... И не надо пытаться ее перегружать несвойственной информацией.

"Периодика в договоре - это цирк... и перегрузка системы..." - ээ... А, может быть я чего-то не понимаю, но как перегрузит систему периодический реквизит справочника Договоры. Который нужен только для информации - "на данную дату с этой торговой точкой работает такой-то торговый агент". Делать отдельный справочник по типу Регистра сведений? Типа такой-то торговый агент - такая-то торговая точка на такую-то дату... Имхо несколько похоже на попытку укусить себя за зад :) Или может быть я мыслю через чур узко....?

Что касается системы оплаты труда - я конечно согласен. Но тут получается вечная дилема. Для того чтобы заплатить кому-то неслабую денюжку, нужно сперва заработать неслабую денюжку, а для того что бы заработать неслабую денюжку нужно грамотно работать, а чтобы грамотно работать..... :) Утрирую конечно, но в нашем Мухосранске контор которые могли бы решить подобную задачу нет. Везти их откуда-то... Раза в полтора дороже получается. И кроме прочего - знать бы точно, когда окупяться вложения "неслабой денежки"... В общем, ничего нового, стандартные проблемы небольшого предприятия которое хочет стать больше, но не совсем понимает что для этого нужно :) Ну соответственно человек поставивший 1С и заставивший все это дело крутиться - должен быть вкурсе всего и вся :) И с этой логикой трудно спорить и бороться :) Да и задачки такие самому интересны :)

Многие проблеммы, в том числе и означенную в теме ветки я долго и тщательно пытался решить на базе типовой торговли (тогда была 6 версия, помоему) еще в 1999 году! После подробного анализа конфигурации ТиС выяснилось, что быстрее и дешевле свою конфу с нуля написать, чем разгребать "поток сознания разработчиков" в типовой. Слишком много там тупиковых (в смысле не поддающихся развитию с разумными усилиями) решений. Через задницу спроектированные регистры (причем практически почти в разрез рекомендациям самой же 1С) тому пример. А так же хранение цен в периодических реквизитах, цена товара - как измерение реквизита регистра. Розничный склад - вообще песня с припевом! Надо же было додуматься Магазин со складом объединить, объекты, имеющие абсолютно разные свойства! Про объединение нескольких операций в одном документе - это вообще методически не допустимо. Такое ощущение, что ТиС изначально был написан студентом в качестве курсовой работы, потому как на диплом не тянет. (Причем ТиС, который был в 7.0 с точки зрения развития конфигурации был гораздо менее тупиковый) По v8 - история повторяется, как было с первыми релизами 77. Я не хочу делать из себя и своих клиентов бетатестеров v8, да еще и деньги за это платить. Со стороны 1С - это натуральное жлобство: сэкономить на тестировании, выпустив на рынок сырой продукт, а потом потихому править выявленные пользователями массы ошибок. Только я не понимаю, почему это должно делаться за мой счет и за счет моих клиентов? Мое мнение по 8 - ждать пару - тройку лет, пока не стабилизируется платформа и станет менее мутной лицензионная политика 1С. Может к тому времени появятся другие, заслуживающие внимания конкурентные решения.

По-моему pita не очень поняли. Дело не в регистрах и не в том где вы учтете данные, не раз уже сказано, что если оплата жестко не привяжется к реализации, то всякий подсчет выручки агекнтов будет фигней, зависящей от порядка следования документов.А агента в договор - ваще труба. Периодический реквизит-лишний головняк. Добавьте его в документ "Реализация" и используйте, либо введите проекты по агентам. Периодическим делают то, что действительно меняется во времени(ставка, директор), но что в принципе является неизменным какое-то продолжительное время. А то, что меняется от документа к документу, это не периодический реквизит, это просто реквизит некой сущности. Ваш файл с периодическими реквизитами раздуется так, что Вам мало не покажетсяА на счет неслабой оплаты, Вы просто получшше разберитесь что хотят, а затем объясните руководству, что для этого должно быть вот так, а иначе-фигня.У меня есть клиент, они торгуют и делают изделия, у них агенты получают за олплаченные и отгруженные заказы. Но они ЖЕСТКО выписывают документы (платежные, выпуск изделия, перемещение на склад агента, реализация) на основании "СчетаЗаказа", проблем нет. Обычно предоплата, но не всегда.

Во многом соглашусь, но в данном случае проблема же не только и не столько в 1С.

Вот подскажите мне, как в реквизит документа "Реализация" должно попадать значение т.е. торговый агент? Ну не всегда отгрузка происходит через самого торгового агента. И тому есть не малое количество причин. Оператор должен помнить и знать что с этой торговой точкой работает такой-то торговый агент? А если оператор ошибется? Торговый агент - это совсем не тот сотрудник который сидит в офисе и набивает документы в 1С. Он непосредственно ездит в торговые точки. Если из моих слов стало понятно, что они ОЧЕНЬ часто меняются, то это не так. Они меняются, но не особо часто.

Спор начинает переходить в область религиозных убеждений :) Альтернативы, действительно достойной альтернативы для стоящих передо мной задач, насколько мне известно нет. И надо учитывать слишком многие факторы, для того, чтобы понять что будет лучше, а что хуже. В данный момент альтернативы 1С я не вижу (хотя и не сильно искал :)). Что касается 8.0 мне тоже не очень приятно наступать не грабли. По 8.0 сам лично отправлял несколько сообщений с ошибками, чего по 7.7 ни разу не делал. Но все ошибки исправляются без больших сложностей, а вот функционал на голову превышает. И что самое интересное - функционал дествительно нужный для работы. Не раз и не два матерился на то, что в ТиС нужно делать тоже самое что в УТ уже есть. По мелочам конечно, но все-же. А некоторые из этих мелочей вообще в 7.7 через всем известное место делаются.

..."Расчет зарплаты - это 50% общей задачи. И в общем-то можно сказать практически главная часть этой задачи. Ну да, я ее не незвал, просто не хотелось грузить полностью всей задачей...." Вот такое ТЗ. Такое хитрожопое мышление: будем употреблять благородное слово "взаиморасчеты", и промолчим о том, что хотим стравить между собой манагеров в драчке за клиента. Чтоб иметь возможность подкармливать то одного, то другого (за счет остальных, разумеется). Чтоб следили друг за другом, чтоб капали друг на друга..........

>>...Чтоб следили друг за другом, чтоб капали друг на друга..........Так это же одна из основ корпоративного управления. Иначе фиг заставишь народ работать так как нужно компании, а не так, как народу хочется.

Прикольная логика... На чем основанная? Изначальная задача - мотивировка торговых агентов заработной платой, не от фонаря, а от сделанной работы. Их тяжело контролировать, они всегда в дороге. Может быть это не совсем правильно, но по другому сейчас сделать офигенно трудно. И кроме всего прочего, чтобы делать по другому нужно быть абсолютно уверенным что будет такой-то или такой-то результат. А нету таких знаний, были бы, не было бы меня здесь :)

Кто бы спорил.... основа...Только причем здесь "регистры", "периодические значения"... вообще "Торговля и Склады"... ???

Ну в принципе и на счетах считать можно... Вот нафиг тогда мы все заморачиваемся этой 1С? :)

Это не "прикольная логика". Это названное прямо истинная задача: "Стоит задача учета взаиморасчетов с покупателями в разрезе торг. агентов." "Изначальная задача - мотивировка торговых агентов заработной платой ... от сделанной работы." "Чтобы правильно сделать, надо правильно думать. Чтобы правильно думать, надо правильно назвать" (Конфуций)

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

Вот после формулировки задачи можно и сформулировать решение:У Сделки есть Агент. Сумма сделки = его отложенный актив. Если Покупатель платит наличкой сразу, то если оплату примент сам Агент, то весь отложенный актив становится его базой для оплаты. Если подсуетится другой Агент - отложенный актив делится между ними. Заранее определенной пропорцией. Чтоб соплей и крику потом не было: заранее определенной и озвученной.Если оплата по безналу, то весь отложенный актив засчитывается Агенту. Если Покупатель не счел нужным разделять оплату по сделкам - ничего страшного, в худшем случае актив полежит до следующего платежа. Не нравится - договорись с покупателем, чтоб "персонифицировал" оплату. Презентик дай: ручку, календарик с дЕвицей, коврик для мышки...И никаких навороченных регистров ;)

ТЗ поставлено явно некорректно. из-за этого такой сыр бор.Сначала надо точно определить по каким критериям будет анализироваться работа контрагентов и только после этого надо искать механизмы реализации. Автор начал с середины...Тем более, что 50% задачи относится не к ТиС, а к расчетам. Если использовать реквизит Проект в документах, то можно сделать отдельный документ РасчетыПоАгентам, подвязать его к регистру ДоходПоАгентам.

В общем примерно понятно :) 68 прав в том, что нужно сперва сделать анализ по каким критериям нужно будет считать заработную плату, и уже после этого реализовывать. Ну а так, спасибо за правку мозгов :) Ну и остальным тоже спасибо за тоже самое :) Ну в общем-то правильно, начал с середины :)

Ребята, или господа, боюсь показаться глупым или навязчивым, но все же, все задачи распадаются на:1. Что мы хотим безотносительно учетной системы. Ведь товары, услуги и деньги ходят вне зависимости есть 1с, Navision, Parus или еще 2 десятка названий.2. В какой учетной системе мы работаем?3. Как ее прспособить к нашей постановке, чтобы было хотя бы надежно, чтобы после выгрузки=загрузки, переиндексации или перепроведения все наши цифры не показали нам их гордый зад? Вот и всё.Мне кажется, что ответа не было прежде всего на .

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

Не вижу ничего глобального.- Что переделать ?- Исправляем что хотим и тдМожет конечно ничего не останется от что хотим, но вопрос начинается не с регистров или партий, а с учета

Делал. Работает. Однозначно измерение в реагистр типа "агент".+ корректировка ПКО и Выписки, процедур проведения и отчетов. А головняк с распределением сумм кто за что полатил решается:1. Административными методами: Агенты точно знают и указывают по какой накладной что было заплачено.2. В неясных случаях вмешиваются нач. отдела агентов и сидит с касиром и агентами выясняя что к чему. Тут уж не путайте теплое с мягким.Если агент договорился о поставке, то "поставка по Петрову, оплата по Сидорову не канает." если действительно все так и происходит, тады у Петрова долг, у Сидорова - аванс и тут остаточный регистр свое преимущество показывает.+ Можно еще оборотный прикрутить оборотный регистр для удобства расчета оплаты. Ну и интерфейсные справочники типа КлиентовАгента. + отчеты с группироваками по КлиентамАгента. Со справочником будет удобнее операторам работать: выбрал агента и работаешь только с его клиентами.Есть там несколько тонкостей, но об этом сам узнаешь.

+ мой совет: не смешивайте никогда бухгалтерию и торговлю, если торговля достаточно интенсивная в одной БД. это два разных полюса, всегда тянущих одеяло на себя, конфликт всегда будет иметь место.

это только в склочных компаниях имеется конфликт бухгалтерии и торговли... На самом деле в рамках сабжа у бухии будет только 1 требование - своевременное внесение полученных оплат в базу... Через кого прошли суммы - бухии до фени, она отслеживает общие взаиморасчеты... Если же требуется детализация взаиморасчетов - бухия к этому индифферентна....P.S. на самом деле после моего поста (где я точно указал причину возникновения сабжа) тема резко поменялась...   И это правильно. Ибо любая учетная система (без разницы, какая) работает по заложенным в нее правилам. А учет взаиморасчетов в разрезе контрагентов возникает там, где глупые (или наоборот, очень умные) начальники пытаются свалить на систему несвойственные функции, причем без четкого описания задачи (но чтобы работало....)....Решение сабжа в любой системе (1с, бест, и т.д.) зависит от промежуточных звеньев и всегда будет скандальным... В силу предвзятости людей, их лени и некомпетентности.   Там, где не желают разбираться с вопросами стимулирования людей и принципами оплаты - всегда стоит такая бардачная задача...   Где с этим разбираются - есть два интересных последствия...

to pitЕсли не секрет, какие возникают обстоятельства?