"Удобная торговля" по мотивам 7.7 на платформе 8.3

Не плохо, до сих пор куча фирм 1с 9.2

Конечно, воля Ваша, но я бы делал ТиС 8.3 на толстом клиенте и без всяких Такси, ИМХО!

Вот это заявка на успех! Автору удачи!

Занятно.
Полезно.
Но уже плохо.
Нет системы.
Для начала - месяц - нарисовать "архитектуру", предполагаемый функционал.
Потом делать.
Иначе получится лоскутно-костыльковая вещь.
ТиС можно содрать практически 1-в-1
Обычно допилы в части ценовой политики.
И ОЧЕНЬ ВОСТРЕБОВАНО разделение прав/доступов - вплоть до видимости и/или доступности для редактирования реквизитов.
новую УТ11 писать я думаю смысла нет, а вот улучшенный вариант ТиС (хрен с ним, пусть даже не улучшенный, а 1-в-1) немножко подсмотреть полезного в СКАТ и Элементарной торговле (https://sites.google.com/site/elementarytrade/home) - можно.

Если подходить по серьезному - может получиться вполне нормальный "фриварный/опенсорсный" продукт, пользующийся спросом. Но только если подходить серьезно. Пока - замах есть, но несерьезный ;-) так что если серьезно - я бы поучастовал. Программить на 8-ке мне влом, да и не умею, но вот потестить, попинать в нужных направлениях (типовую ТиС 9.2 знаю, думаю, очень неплохо) - я бы поучаствовал (даже подарил бы в конфигу вариант решения мгновенного контроля исправлений задним числом по неуходу в минуса от исправления до сейчас).

А если еще прилепить сюда вменяемый блок адресного учета (могу поучастовать, опыт/наработки есть) - то вообще может получиться хорошо.
я - на связи.

насчет толстый/такси - я б сильно подумал.
скольо наблюдаю - 99% времени персонал сидит в одном окне: либо пялится на "журнал", либо работает в документе, либо смотрит на какое-нит сводное "рабочее место".

Могу предложить достаточно легкую настройку и методику использования факторинга
Допиливаются два документа всего
Акт передачи на факторинг
Отчет по факторингу
Типовая схема регистров для тис остается без изменений
Если надо будет - стучись, плкажу как сделано

В рамках типовой тис хоть и можно реализовать - но для менеджеров получается трудоемко, надо подумать как это сделать красиво:
Описываю все на примере типовой тис
- реализованная в тис схема фиксации долгов/взаиморасчетов по договорам с фиксацией кредитного документа - вполне себе устраивает всех
- предлагается немного расширить в части (рулить настройкой для клиента)
1. Веден евзаиморасчетов кучей - то есть не фиксировать кредитный док в измерении, оставлять его пустым (типа как партионка по среднему в куче) - реализуется тривиально в полпинка
2. Штатный вариант договор-кредитный документ
3. Вариант ведения взаиморасчетов посделочно (одна реализация=одна сделка) - востребовано при отношениях с сетями - если по первым двум вариантам в основном важно должны мы или нам - то в этом варианте очень строго по какому конкретно - а так как в рамках одного договора по сетям могут грузиться разные магазины - которые по ряду причин нельзя выделить как отдельных клиентов и даже как отдельных грузополучателей - то оплаты идут не по порядку отгрузок а по конкретным реализациМ. Этот вариант реализуется по сути выделением сделки в отдельный договор с единственным документом отгрузки - то есть по сути это вариант 2 с ограничением - но как это сделать удобно - чтобы менеджерам не маяться с введением очередного Договора по шаблону основного договора - надо думать, наметки есть но надо думать

Возможно надо посмотреть как реализовано в ут11 аналогичные схемы

ВАЖНО
Принципиально отказаться от порочной практики несоответствия ввода на основании и зафиксированным движениям по регистрам, обыденная ситуация: м енеджер-лавочник уверен что раз пко или выписка введены на основании реализации - значит они закрывают эту реализацию по оплате. В типовой тис это не так - закрываются долги не по структуре подчиненности а по фифо, подробнее можно посмотреть у меня пояснения злесь http://infostart.ru/public/175550/

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

Подумать как правильно разрулить иакую ситуацию - возможная часть вариантов в моей счылке в предпосте

В регистрах взаиморасчетов - по покупателям/поставщикам - отказаться от измерения "вид долга" (за товары/за услуги) - это разруливать на уровне договоров

Здесь могут быть траблы, когда в одном дркументе и товары и услуги
Думать здесь надо.
Представляется прагматичным подход - чем однотипнее/однообразнее - тем проще контролировать/выполнять. Тупо и жестко принимаем что товары отдельно, услуги отдельно.

Думать
Вполне возможно что не так или совсем не так

Документ "корректировка долга"
Типовая тисовская формулировка причем разная по отношению к покупателем/поставщикам - вводит юзверя в ступор. Формулировать просто - указывать корретируем по покупателю или поставщику и просто уменьшение нашего долга/увеличение нашего долга - прога сама перелопатит в нужном направлении покупатель или поставщик

Возможен вариант как в типовом тис - но пояснения тогда расписать чуть подробнее сразу на форме

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

С выбором корретируемых документов вручную - совершенно аналогично как выше, только доки набираются не автоматом, а пользователе с использование например галочек в таблице-запросе непогашенных доков

Учесть также что возможно надо указать и вид долга для каждого погашаемого документа..?

Наряду с типовым корретировкой долга сделать типовой документ взаимозачета
Между долгами покупатель-покупатель, покупатель-поставщик, поставщик-поставщик
С учетом договоров?
Заполнение аналогично корректировке долга - обязательно должно быть видно в табличной части какие документы погашаются

Тщательно подумать
Сделать по подобию типовых конфиг - их всетаки не дураки разрабатывают, со многими решениями в типовых конфигах я вынужден согласиться
Например
Припервом проведении документа в тч дока фиксировать получившееся авторраспределение какоелибо - например, что оплата легла конкретно на такието отгрузки. Эти отгрузки погашенные оплаатой - фиксируем гдето - например в тч дока
Все последующие проведения в первую очередь стараются сделать так, чтобы припроведении получилось точно то что зафиксировано в тч дока. Если не получилось - тогда уже пытаемся заново распределить. Отклонения текущего распределения припроведении от предыдущего либо сразу стопорим или - возможно регулируется глобальной настройкой - проводим как получилось, все отклонения от предыдущего проведения гдето фиксируем

Самый простой пример: в типовой тис - напечатали клиентту счф, все ок
Спустя какое о время клиент просит напечатать счф заново или выставить ту же самую но с учетом вычерка - то нсть переделать документ. Печатаем - получаем совершенно другие гтд по куче позиций.

Реализация такого варианта есть, успешно работает, позволяет спокойно спать

Есть особо упоротые клиенты
Например сети
И не только они
Для них не подходят стандартные формы например счф
Пример: клиент хочет чтобы в торг12 были одни инн/кпп указаны, а в счф - инн/кпп другие при совпадении всех остальных реквизитов.
И таких хотелок вагон
Вменяемых вариантов программного заполнения по таким хотелкам реализовать не удалось. Самая простая, логичная и легко прослеживаемая и контролируемая система при которой к одноэсника не болит голова - подткаждый первичный документ есть тупаф форма со всеми реквизитами которые ДОЛЖНЫ БЫТЬ В Этой ПЕЧАТНОЙ ФОРМЕ - вот что туда ответственное лицо - менеджер/бухгалтер - впишет - то и будет печататься 1-в-1
Запилил такую систему у себя - стал спать спокойно. Как реализовать - форма с полями или регистр сведений или вообще готовый макет со стационарновбитыми данными - вопрос технический. Суть: всякие значения для заполнения документов берем не из карточек клиентов а из значений соответсвующих полей сооттветствующих печформ.

Сильно подумать о реализации учета в разрезах характеристик цвета/размеры/сернумы и прочее

Возврат от клиента
Тупо запретить/ не реализовывать вариант без указания документ-основания
Возврат - только на основании реализации

При возврате обязательно проверять непревышение возврата над реализацией

Типовая тис тупо пропустит вариант
Реализация 100 шт
Возврат1 70шт
Возврат2 50шт

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

Гтд для импорта и для отечественных товаров
Гораздо проще все свести к одному
Гтд должна указываться всегда, даже для отечественных товаров
Для отечественных товаров тупо юзер подмтавляет болванку "отечествееной гтд" - где номер гтд 4 прочерка как обычно указывается для отечественных гтд

Ряд клиентов- обычно сети - требуют в отгрузке соблюдения оригинального порядка строк исходной заявки

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

Необходимость заполнения опс регулируется соответсвующей предопределенной зарактеристикой клиента

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

ПОЭТОМУ проще когда даже неполная реализация ЗАКРЫВАЕТ ЗАЯВКУ ПОЛНОСТЬЮ
И клиент если е у надо выставляет новую заявку
Вариант длинных или коротких отгрузок регулируется предопределенной зарактеристикой клиента/договора

У меня все заявки - корткие
В типовой тис это реализуется вставкой одного оператора присвоения в нужное место глобальной процедуры

Типовая тис никак не защищена от кривыз минусовых резервов
Например по регистру остатков = 100, в резерве = -40, по факту на свободных остатках действительно 100
Приходит заявка на 130шт
Тис считала тупо
доступно = остаток - резерв = 100 - (-40) = 140
Заявка в полном составе принимается на обслуживание, потом начнается (_._)
В тисе правится тривиально, но так до сих пор эта дырка в типовой есть

Учесть это в восьмерочной конфигурации!!!

.. Вот накидал малость по мелочам

В типовой тис есть дырка, которая приводит к труднообнаруживаемым нарушениям в учете которые получаются пересортами, хотя их не должно быть - связано с указанием свойства партии

Отгрузки с отложенным переходом права собственности
Допилил такое, реализуется достаточно просто
Надо будет - стучись

Подписываюсь. Я б тоже поучаствовал в серьёзном проекте.

В разрабатываемом решении следует сделать обязательно какойнить простой вариант, готовые шаблоны оперативной загрузки данных - заявок, например
То есть некий механизм плугинов для каждого вида документа для каждого клиента
1-2 готовых варианта загрузки - типа из плоского экселя по столбцам артикул-количество, из плоского текста с разделителями

Маня декларировал что он тупой ковертицие 77 на 8ку типовыми инструментами - получил практически работающее приложение, ручной доводки надо было мало

В команде хорошо бы иметь спеца по ут11 - там есть ряд интереснополезных моментов.
Он бы пинал нас в нужном направлении или хотя бы критиковал.
Но боюсь таким спецам по ут наша возня будет неинтересна

Адресное хранение и ценообразование очень нужно в такой конфигурации.

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

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

Концепция корректировки заявок как она есть в тис
В целом вполне работоспособно
За исключением полной невозможности работать с заявками в терминах журнала документов, так как с точки зрения менеджера заявка одна - по состоянию на сейчас - а в программе это целая цепочка корректировочных заявок. Менеджеры тупо выпадают в осадок, а все что надо - показывать для оперативной работы только текущее состояние заявок - то есть некий псевдожурнал-список, который показывает только незакрытые активные заявки, с выделение просроченных цаетом или както иначе. У меня так сделано и все менеджеры практически постоянно сидят в этом псевдожурнале где основные действия ввести новую заявку, закрыть заявку, скорректировать заявку. Корректировка заявки в виде новой заявки с автозаполненными показателями всеми у менеджеров не вызывает вопросов - менеджер правит нужные данные и проводит заявку и ее текущее состояние отражается в обновленном псевдожурнале. Внимание: ненужная заявка закрывается штатным образом, а не удаляется - это непрвильно!
В обычный журнал менеджер заходит изредка, больше для служебных целей. Основное правило: проведенная заявка не может быть изменена - только вводом корректировочной. Это автоматом снимает проблемы с гп и проблемы с любителями увеличивать например резерв путем изменения заявки в прошлой неделе - и получается жпс.

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

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

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

По снеговику не спец

Deda, сделай партионку еще "по-среднему" - реализуется просто (галка/список в настройках организации по выбору вида партионки - как есть в ТИС) по типу "по среднему= ФИФО при одной партии" - в измерении пустая партия, все кладешь на нее. Штатный алгоритм, который отрабатывает ФИФО - штатно такой вариант будет давать такой же результат как по-среднему.

"приказ на отгрузку реализуется в полпинка - перведом заявки со склада "основной склад" на виртуальный (или вполне реальный) склад "зона готовых к отгрузке" (готовые может сразу пониматься как и разрешенные, а разрешенные = приказ - может отдельно - то есть "основной склад" - "готовые к отгрзке" - "разрешенные к отгрузке". "

- причем состав заявок - !!!все штатным функционалом!!! - готовых к отгрузке и/или разрешенных - тривиально и содержательно (даже со всей истрией движений) смотрится типовыми отчетами ОтстакиТМЦ и Ведомость по остаткам ТМЦ

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

Что и как делать - презумпция автора разработки.
Имхо, делать клон, заточенный на какую-то специфику именно автора - имеет место быть такая парадигма.
Но тис 9.2 получила такое широкое распространение именно ввиду свойе относительной простоты, и при этом вполне достаточной функциональности ДЛЯ БОЛЬШИНСТВА. Специфику точил каждый сам (тем более что дотачивается достаточно легко).

Такая концепция представляется мне обоснованной. Я бы и придерживался ее. Вплоть до "соглашения" не вводить новых объектов метаданных, предназначенных для отражения частных специфик. Свои предложения я автору высказал в этом отношении - я думаю, мы их обсудим на конференции.

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

Как-то вот так я представляю себе доработки НОВОГО функционала.

- Возможность ведения взаиморасчетов с разрезе счетов, множественное указание кред.документов в документах банка и кассы.

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

Про кред.доки в доках банка и кссы - тоде писал выше, поддерживаю

- Человеческий взаимозачет/переуступка долга

Писал выше, поддерживаю

- Приём на хранение, передача на хранение (расширение стандартной комиссии)

У себя сделал тупым доп регистром переданные на ох по образу комиссии и два дока передача и возврат по ох. Работает ок. Проблем нет. Достаточно будет акты мх1,3 - они есть - журнал актов, и ведомость инвентаризации ох - там есть некоторые мелкие засады. Стоит ли заводить отдельный регистр под ох или можно обойтись регистром комиссионеров - с довидом операции комиссия или ох - надо смотреть. Есть засады спартионкой при учете комиссии и ох - разная логика, надо совещаться

- Нормальное распределение доп.расходов на себестоимость при поступлении и прочих операциях, возможность указания доп.расходов сразу при поступлении

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

Тут я считаю что: в связи с целевым назначением конфиги она должна быть проще. В том числе именьше альтернатив сделать нужное движение. Иначе это затруднит реализацию.

Итого я практически присоединяюсь

- Может быть векселя?
В рамках типовой тис это прекрасно реализуется без всяких допсущностей вроде. Надо посовещаться

- Учет на складе по качеству и доп.характеристикам поставки,
Складу и менеджерам вообщем допхарактеристики поставки пофиг. Учет по допхарактеристикам товаров (сюда же попадает и качество) - да, надо делать

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

Во всем этом лично для меня сложность в учете по допхарактеристикам

Друзья! Есть ли у кого возможность или желание дописать к этому конфигу небольшой модуль установки цен номенклатуры? Либо как в ТиС7.7 либо как в УТ11 или скрещением? Либо по-нашему попроще :)

И итоге со всеми хотелками - получаем УТ10.3...
думаю идея автора самая верная - базовый функционал, а остальное кто как хочет допилит.

"У меня доработана штатная комиссия. Новый статус партии, несколько новых кодов операций. Тоже работает :) "
- тоже можно, но мне кажется что более правильно концептуально - новый/отдельный участок учета/работы - новый/отдельный регистр. Это проще и прозрачнее.
надо подумать/посовещаться.

ну, до Ут10.3 - даже с обсуждавшимися ВОЗМОЖНЫМИ доработками - еще достаточно далеко (как мне кажется) ;-)

Вопрос, а почему не посмотреть в строну УНФ конфигурация по простоте напоминает как раз ТиС (и даже еще проще) плюс еще много положительных плюшек, которые как раз отключаемы и в коробке уже синхронизация с сайтом и БП?