<?php // Полная загрузка сервисных книжек, создан 2024-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Не плохо, до сих пор куча фирм 1с 9.2
Конечно, воля Ваша, но я бы делал ТиС 8.3 на толстом клиенте и без всяких Такси, ИМХО!
Вот это заявка на успех! Автору удачи!
(2) DoctorRoza, Хорошо! Я буду иметь ввиду ваше пожелание при дальнейшей доработке конфигурации.
Занятно.
Полезно.
Но уже плохо.
Нет системы.
Для начала — месяц — нарисовать «архитектуру», предполагаемый функционал.
Потом делать.
Иначе получится лоскутно-костыльковая вещь.
ТиС можно содрать практически 1-в-1
Обычно допилы в части ценовой политики.
И ОЧЕНЬ ВОСТРЕБОВАНО разделение прав/доступов — вплоть до видимости и/или доступности для редактирования реквизитов.
новую УТ11 писать я думаю смысла нет, а вот улучшенный вариант ТиС (хрен с ним, пусть даже не улучшенный, а 1-в-1) немножко подсмотреть полезного в СКАТ и Элементарной торговле ( — можно.
Если подходить по серьезному — может получиться вполне нормальный «фриварный/опенсорсный» продукт, пользующийся спросом. Но только если подходить серьезно. Пока — замах есть, но несерьезный 😉 так что если серьезно — я бы поучастовал. Программить на 8-ке мне влом, да и не умею, но вот потестить, попинать в нужных направлениях (типовую ТиС 9.2 знаю, думаю, очень неплохо) — я бы поучаствовал (даже подарил бы в конфигу вариант решения мгновенного контроля исправлений задним числом по неуходу в минуса от исправления до сейчас).
А если еще прилепить сюда вменяемый блок адресного учета (могу поучастовать, опыт/наработки есть) — то вообще может получиться хорошо.
я — на связи.
(5) CheBurator, Благодарю, за советы! Действительно конструктивные, принял во внимание! Месяц нарисую, как оформлю документ ввода остатков. Тестирование в нашем случае необходимая вещь! Будем дружить 🙂
насчет толстый/такси — я б сильно подумал.
скольо наблюдаю — 99% времени персонал сидит в одном окне: либо пялится на «журнал», либо работает в документе, либо смотрит на какое-нит сводное «рабочее место».
Могу предложить достаточно легкую настройку и методику использования факторинга
Допиливаются два документа всего
Акт передачи на факторинг
Отчет по факторингу
Типовая схема регистров для тис остается без изменений
Если надо будет — стучись, плкажу как сделано
В рамках типовой тис хоть и можно реализовать — но для менеджеров получается трудоемко, надо подумать как это сделать красиво:
Описываю все на примере типовой тис
— реализованная в тис схема фиксации долгов/взаиморасчетов по договорам с фиксацией кредитного документа — вполне себе устраивает всех
— предлагается немного расширить в части (рулить настройкой для клиента)
1. Веден евзаиморасчетов кучей — то есть не фиксировать кредитный док в измерении, оставлять его пустым (типа как партионка по среднему в куче) — реализуется тривиально в полпинка
2. Штатный вариант договор-кредитный документ
3. Вариант ведения взаиморасчетов посделочно (одна реализация=одна сделка) — востребовано при отношениях с сетями — если по первым двум вариантам в основном важно должны мы или нам — то в этом варианте очень строго по какому конкретно — а так как в рамках одного договора по сетям могут грузиться разные магазины — которые по ряду причин нельзя выделить как отдельных клиентов и даже как отдельных грузополучателей — то оплаты идут не по порядку отгрузок а по конкретным реализациМ. Этот вариант реализуется по сути выделением сделки в отдельный договор с единственным документом отгрузки — то есть по сути это вариант 2 с ограничением — но как это сделать удобно — чтобы менеджерам не маяться с введением очередного Договора по шаблону основного договора — надо думать, наметки есть но надо думать
Возможно надо посмотреть как реализовано в ут11 аналогичные схемы
ВАЖНО
Принципиально отказаться от порочной практики несоответствия ввода на основании и зафиксированным движениям по регистрам, обыденная ситуация: м енеджер-лавочник уверен что раз пко или выписка введены на основании реализации — значит они закрывают эту реализацию по оплате. В типовой тис это не так — закрываются долги не по структуре подчиненности а по фифо, подробнее можно посмотреть у меня пояснения злесь
..то есть должен по максимуму использоваться вариант вививиг — что вижу то и есть
При этом сразу и жестко блокировать попытки ввода неверных ситуаций по типу: аыписка в 100 руб вешается на реализацию в 100 руб — но при этом внезапно реализация на 20 руб оплачена — хдесь должен быть запрет ибо нарушается принцип визивиг — привязано 100 рублей оплаты, а по факту привязалось всего 80, остаток 20 повис фиг его знает где.
Подумать как правильно разрулить иакую ситуацию — возможная часть вариантов в моей счылке в предпосте
В регистрах взаиморасчетов — по покупателям/поставщикам — отказаться от измерения «вид долга» (за товары/за услуги) — это разруливать на уровне договоров
Здесь могут быть траблы, когда в одном дркументе и товары и услуги
Думать здесь надо.
Представляется прагматичным подход — чем однотипнее/однообразнее — тем проще контролировать/выполнять. Тупо и жестко принимаем что товары отдельно, услуги отдельно.
Думать
Вполне возможно что не так или совсем не так
Документ «корректировка долга»
Типовая тисовская формулировка причем разная по отношению к покупателем/поставщикам — вводит юзверя в ступор. Формулировать просто — указывать корретируем по покупателю или поставщику и просто уменьшение нашего долга/увеличение нашего долга — прога сама перелопатит в нужном направлении покупатель или поставщик
Возможен вариант как в типовом тис — но пояснения тогда расписать чуть подробнее сразу на форме
Корректировка долга два режима:
Авторазноска корректируемого долга или с явным указанием корректируемых документов
Тогда в корректировке должна быть табличная часть в которой при авторазноске автоматом в табличную часть заносится корректируемые документы по общему правилу подбора (по фифо например) на требуемую сумму общей корректировки. Такое заполнение делается только один раз, далее при проведении дока отрабатывает вариант с указанием погашаемых документов, см ниже (автоподбор документов может быть перезаполнен принудительно по кнопке)
С выбором корретируемых документов вручную — совершенно аналогично как выше, только доки набираются не автоматом, а пользователе с использование например галочек в таблице-запросе непогашенных доков
Учесть также что возможно надо указать и вид долга для каждого погашаемого документа..?
Наряду с типовым корретировкой долга сделать типовой документ взаимозачета
Между долгами покупатель-покупатель, покупатель-поставщик, поставщик-поставщик
С учетом договоров?
Заполнение аналогично корректировке долга — обязательно должно быть видно в табличной части какие документы погашаются
Тщательно подумать
Сделать по подобию типовых конфиг — их всетаки не дураки разрабатывают, со многими решениями в типовых конфигах я вынужден согласиться
Например
Припервом проведении документа в тч дока фиксировать получившееся авторраспределение какоелибо — например, что оплата легла конкретно на такието отгрузки. Эти отгрузки погашенные оплаатой — фиксируем гдето — например в тч дока
Все последующие проведения в первую очередь стараются сделать так, чтобы припроведении получилось точно то что зафиксировано в тч дока. Если не получилось — тогда уже пытаемся заново распределить. Отклонения текущего распределения припроведении от предыдущего либо сразу стопорим или — возможно регулируется глобальной настройкой — проводим как получилось, все отклонения от предыдущего проведения гдето фиксируем
Самый простой пример: в типовой тис — напечатали клиентту счф, все ок
Спустя какое о время клиент просит напечатать счф заново или выставить ту же самую но с учетом вычерка — то нсть переделать документ. Печатаем — получаем совершенно другие гтд по куче позиций.
Реализация такого варианта есть, успешно работает, позволяет спокойно спать
Есть особо упоротые клиенты
Например сети
И не только они
Для них не подходят стандартные формы например счф
Пример: клиент хочет чтобы в торг12 были одни инн/кпп указаны, а в счф — инн/кпп другие при совпадении всех остальных реквизитов.
И таких хотелок вагон
Вменяемых вариантов программного заполнения по таким хотелкам реализовать не удалось. Самая простая, логичная и легко прослеживаемая и контролируемая система при которой к одноэсника не болит голова — подткаждый первичный документ есть тупаф форма со всеми реквизитами которые ДОЛЖНЫ БЫТЬ В Этой ПЕЧАТНОЙ ФОРМЕ — вот что туда ответственное лицо — менеджер/бухгалтер — впишет — то и будет печататься 1-в-1
Запилил такую систему у себя — стал спать спокойно. Как реализовать — форма с полями или регистр сведений или вообще готовый макет со стационарновбитыми данными — вопрос технический. Суть: всякие значения для заполнения документов берем не из карточек клиентов а из значений соответсвующих полей сооттветствующих печформ.
Сильно подумать о реализации учета в разрезах характеристик цвета/размеры/сернумы и прочее
Возврат от клиента
Тупо запретить/ не реализовывать вариант без указания документ-основания
Возврат — только на основании реализации
При возврате обязательно проверять непревышение возврата над реализацией
Типовая тис тупо пропустит вариант
Реализация 100 шт
Возврат1 70шт
Возврат2 50шт
Возвраты — мегаболезненное место практически у всех
Предусмотреть вариант некой загрузки возвратов — мастер возвратов типа — когда подсасываем количество возврата требуемое и автоматически вычисляем — с учетом уде ранее сделанных возвратов — по каким документам какие возвраты надо сделать и тупо сами их генерим
Гтд для импорта и для отечественных товаров
Гораздо проще все свести к одному
Гтд должна указываться всегда, даже для отечественных товаров
Для отечественных товаров тупо юзер подмтавляет болванку «отечествееной гтд» — где номер гтд 4 прочерка как обычно указывается для отечественных гтд
Ряд клиентов- обычно сети — требуют в отгрузке соблюдения оригинального порядка строк исходной заявки
Сделал тупо
Во всех тч всех доков есть скрытая служебная колонка ОПС — оригинальный порядок строк — там где надо просто проставляется нумератор строк, сортировка которую может делать юзер всегда идет как ОПС+реквизитсортировки. Для незаполненных опс жквивалентно сортировке по реквизиту.
Необходимость заполнения опс регулируется соответсвующей предопределенной зарактеристикой клиента
В типовой тис если реализация по товарному составу меньше заявки — часть заявки оставалась непогашенной. Для большинства клиентов длинные заявки по которым возможны несколько отгрузок — непрозрачны, трудноконтролируемы.
ПОЭТОМУ проще когда даже неполная реализация ЗАКРЫВАЕТ ЗАЯВКУ ПОЛНОСТЬЮ
И клиент если е у надо выставляет новую заявку
Вариант длинных или коротких отгрузок регулируется предопределенной зарактеристикой клиента/договора
У меня все заявки — корткие
В типовой тис это реализуется вставкой одного оператора присвоения в нужное место глобальной процедуры
Типовая тис никак не защищена от кривыз минусовых резервов
Например по регистру остатков = 100, в резерве = -40, по факту на свободных остатках действительно 100
Приходит заявка на 130шт
Тис считала тупо
доступно = остаток — резерв = 100 — (-40) = 140
Заявка в полном составе принимается на обслуживание, потом начнается (_._)
В тисе правится тривиально, но так до сих пор эта дырка в типовой есть
Учесть это в восьмерочной конфигурации!!!
.. Вот накидал малость по мелочам
В типовой тис есть дырка, которая приводит к труднообнаруживаемым нарушениям в учете которые получаются пересортами, хотя их не должно быть — связано с указанием свойства партии
Отгрузки с отложенным переходом права собственности
Допилил такое, реализуется достаточно просто
Надо будет — стучись
Подписываюсь. Я б тоже поучаствовал в серьёзном проекте.
В разрабатываемом решении следует сделать обязательно какойнить простой вариант, готовые шаблоны оперативной загрузки данных — заявок, например
То есть некий механизм плугинов для каждого вида документа для каждого клиента
1-2 готовых варианта загрузки — типа из плоского экселя по столбцам артикул-количество, из плоского текста с разделителями
(27) категорически приветствую!!!
Есть соображения
Самое первое — кто в мск — очная встреча.
Прошу обдумать данное предложение.
Маня декларировал что он тупой ковертицие 77 на 8ку типовыми инструментами — получил практически работающее приложение, ручной доводки надо было мало
В команде хорошо бы иметь спеца по ут11 — там есть ряд интереснополезных моментов.
Он бы пинал нас в нужном направлении или хотя бы критиковал.
Но боюсь таким спецам по ут наша возня будет неинтересна
(26) CheBurator, не хилая такая заявка на доработку. Похвально.
(19) CheBurator, А как же быть с возвратом от клиента если были вводы остатков и реализации остались в прошлой базе? В ТиСе есть возможность указания себестоимости в ВозвратеОтПокупателя и соответственно создается новаПартия с ПриходнымДокументов — ВозврОтПокуп…
(29) CheBurator, Очная встреча правда необходима, но я в Иркутске 🙁 Поэтому можно групповой SKYPE организовать)
(34) С очной ставкой не выйдет. Магнитогорск. Как раз посерёдке между вами 🙂
Адресное хранение и ценообразование очень нужно в такой конфигурации.
(33) Забить на возвраты в начале ведения учета. такие возвраты — возможность делать только через ПоступлениеТМЦ — смирится с этим. Потом такое поступление Взаимозачетом зачесть в отгрузки.
» В ТиСе есть возможность указания себестоимости в ВозвратеОтПокупателя» — скольок ни смотрел — никто из типа ведущих учет в ТиСе — нихрена там не забивает. Поэтому все возвращаемые себестоимости — спрятать нафиг от пользователя, все автоматом. ТОЛЬКО НА ОСНОВАНИИ РЕАЛИЗАЦИИ.
(32) «фигня какая-то» 😉
Это не заявка на доработку, это то, что тупо всплыло в голове в мутном состоянии ночью глубокой…
(36) Про ценообразование — черкани пару строк, что хочется.
Про адресное хранение — тут надо сильно подумать, чтобы не свалиться в излишества.
(39) CheBurator, Думаю, большое количество потребностей в «адресном хранении» закроет иерархический справочник складов с возможностью указывать в документах/отчетах склад-группу. И склад в табличной части документа.
(6) в 2009 году в нашей компании было принято решение переписать ТиС9.2 на платформу 1с 8.1 мы потратили 1 год и около 7 лимонов рублей (60% кода было написано франчем) и работаем на ней до сих пор (около 250 пользователей) . Мы сравнивали а не писать ли под УФ и решили не писать… ну вод такая история. А вам — удачи !
(29) CheBurator, я то же за скайп, т.к. Волгоград. Готов принять участие. Знаю немного Ут11 (есть два внедрения)
+ (41) продолжим )
(31) CheBurator,
(43) rozer, Добрый день! О границе последовательности уже подумано и она прекрассно восстанавливается в данном конфиге. Проверяйте! И еще как вы думаете за сколько минут в маловесном данном конфиге восстанавливается ГП? На то и упор — на скорость. К примеру восстановить 4000 документов сейчас занимает меньше минуты…Партионный учет уже есть, но немного подкорректировать осталось… опять же проверяйте и увидите… 🙂 Благодарю за конструктивную критику!
(43) rozer, И еще главный момент, — работаем не на коробку, но ради удобства и простоты большинства пользователей, принципиально бесплатный фриварный продукт, для людей которые ищут альтернативные маловесные конфиги под конкретные задачи. 🙂
(45) оставьте в ут два регистра и там будет шикарная скорость восстановления ГП особенно если не очищать движения автоматом и не трогать не измененные данные как в ут11 а для инфо может не в курсе — магазька уже бесплатна а функционала там немного поболее… А так просто завидую по хорошему людям которые в учебных целях могут тратить время на такое бесплатно (сам давно когда-то таким был) а когда у тебя большая семья и работаешь один это как-то понять и мотивировать на такое сложно. Ну ладненько — удачи!
(43) rozer,
много думал/думаю на эту тему.
вообщем да — мне УТ11 вполне показалась.
(44)
если писать чисто УУ-конфу, то вполне можно обойтись без процесса восстановления ГП. просто исключив исправления и внос документов задним числом. Все вносим/исправлеям в «сейчас». но, боюсь, что такое не найдет понимания в широких кругах лавочников.
На размышление/обсуждение.
отказаться от типового механизма фиксации «основной единиц измерения» — за все время ни разу не видел, чтобы народ работал в основных единицах. Все работают в базовых. То есть карточка клиента в которой указана базовая единица и все. При этом остальных единиц измерения — может быть неограниченное количество. Они используются в основной работе. Их же допускается использовать — ручным выбором юзверем и в документах.
В подавляющем количестве случаев выписка счф производится по кнопке из документа реализации тупым техническим методом — нажать кнопкк — в открывшейся новой форме документа счф жмем ок (записать-провести-закрыть). Все. То есть тупые технические действия которые по большей части менеджеры врспринимают как тупую лишнюю работу
У себя сделал подписку на проведение реализации и автосоздание счф. Все довольны. Имеет смысл сделать аналогично, тем более что подписки на события штатно в восьмерке. Или иным способом но суть — автогенерация счф при проведении реализации у которой нет счф
Концепция корректировки заявок как она есть в тис
В целом вполне работоспособно
За исключением полной невозможности работать с заявками в терминах журнала документов, так как с точки зрения менеджера заявка одна — по состоянию на сейчас — а в программе это целая цепочка корректировочных заявок. Менеджеры тупо выпадают в осадок, а все что надо — показывать для оперативной работы только текущее состояние заявок — то есть некий псевдожурнал-список, который показывает только незакрытые активные заявки, с выделение просроченных цаетом или както иначе. У меня так сделано и все менеджеры практически постоянно сидят в этом псевдожурнале где основные действия ввести новую заявку, закрыть заявку, скорректировать заявку. Корректировка заявки в виде новой заявки с автозаполненными показателями всеми у менеджеров не вызывает вопросов — менеджер правит нужные данные и проводит заявку и ее текущее состояние отражается в обновленном псевдожурнале. Внимание: ненужная заявка закрывается штатным образом, а не удаляется — это непрвильно!
В обычный журнал менеджер заходит изредка, больше для служебных целей. Основное правило: проведенная заявка не может быть изменена — только вводом корректировочной. Это автоматом снимает проблемы с гп и проблемы с любителями увеличивать например резерв путем изменения заявки в прошлой неделе — и получается жпс.
Если в данной конфигурации реализовывается схема цепочки корректировочных заявок как инструмента изменения заявки — делать надо типа так как описано выше. Такая схема у меня отработана и работает кучу лет. Показала свою правильност, эффективность и беспроблемность. Единственная дописка к штатному функционалу — дополнительный внутренний нумератор заявок (с точки зрения менеджера) — так как номера заявок есть просто номера хозяйственных операций, а с клиентомнадо общаться в какомто однозначном идентификаторе заявки-сделки. Внедрение такого внутреннего нумератора достаточно просто, с десяток строк кода.
Вполне возможно, что корректировка заявок по типу описанного выше в снеговике можно организовать иным способом — так как в снеговике возможно формирование движений любой датой, а не позицией регистратора. Тут я не спец. Нужны будут пояснения — стучитесь, готов пояснить более подробно.
Типа пояснения/размышления
Например если бы я писал на елюшках то заявку покупателя я разделил бы на две части — отдельно заявка-шапка и отдельно заявка-тч, привязываемая к заявка-шапка. Тч заявки-шапки может использоваться как протокол действий с заявкой — изменение статусов, логгирование действий выгрузокзагрузок и прочее полезное, в тч регистрацию грузовых мест и прочее логистическое в тч и в интересах внешних покупателей — примерно так у меня сделано в типовой тис, только это все по заявке регистрируется в дополнительном нумераторе
По снеговику не спец
Deda, сделай партионку еще «по-среднему» — реализуется просто (галка/список в настройках организации по выбору вида партионки — как есть в ТИС) по типу «по среднему= ФИФО при одной партии» — в измерении пустая партия, все кладешь на нее. Штатный алгоритм, который отрабатывает ФИФО — штатно такой вариант будет давать такой же результат как по-среднему.
(49) CheBurator,
Про единицы измерения.
По моему, достаточно регулярно востребован учет одновременно в нескольких единицах. Продаём во всяких разных единицах, а общая управленческая отчетность в тоннах, литрах, метрах…
(50) CheBurator,
Не знаю, как у вас, а у меня по причине требований налоговой приходится выписывать по нескольку счетов фактур к одной реализации. Одну для собственного товара, и, отдельно, по одной для каждого комитента. Поэтому автовыписка с/ф сделана явно и с обязательной печатью. Потому что, бывает, при банальном выборе другой партии в документе приходится отдавать покупателю новые счета-фактуры.
(51) CheBurator,
Про корректировки.
В ТиС довольно легко допиливается возможность корректировки практически любого документа. Заявок, поступлений, реализаций… С соответствующим формированием проводок. У меня активно используется по причине особенностей работы с поставщиками.
К заявкам, по моему, важней корректная цепочка — заявка (с корректировками) — приказ на отгрузку — реализация.
У тебя такое реализовано? Я никак не соберусь 🙂
(53)
Про единицы измерения.
«По моему, достаточно регулярно востребован учет одновременно в нескольких единицах. Продаём во всяких разных единицах, а общая управленческая отчетность в тоннах, литрах, метрах… » — учет одновременно в нескольких единицах — это несколько из другой оперы. И в ТИС он не реализован никак. Пересчет погонные метров в тонны и тому подобное — это скорее варианты вывода отчетов. когда одна единица пересчитывается в другую по правилам, определяемым либо коэффициентами либо «плугинами»
(53)
«Не знаю, как у вас, а у меня по причине требований налоговой приходится выписывать по нескольку счетов фактур к одной реализации.»
это всетаки достаточно экзотический вариант, как и одна СЧФ на нескольо накладных. просто в настройках отрубаем автогенерацию СЧФ 1-в-1 и выписвааем как надо.
«Потому что, бывает, при банальном выборе другой партии в документе приходится отдавать покупателю новые счета-фактуры.» — если ручной учет партий — то да, это понятно. если автовыбор партиф (гтд) в счф — выше я описал как это можно будет реализовать ПРИ НЕОБХОДИМОСТи.
(53)
Про корректировки.
«В ТиС довольно легко допиливается возможность корректировки практически любого документа. Заявок, поступлений, реализаций… С соответствующим формированием проводок. У меня активно используется по причине особенностей работы с поставщиками. »
— в типовой ТИС джля этого не надо ничего дописывать побольшому счету:
.корректировка заявок поддерживается штатно (обсосано мной от и до)
.корректировка поступлений — нет такой фигни (если привязываться к бухпроводкам): любая корректировка поступления ведет либо к корректировочной счф В ЧАСТИ УЧЕТА НАЛОГОВ, ТО ЕСТЬ ОТНОШЕНИЙ С ГОСУДАРСТОВМ. а как докинуть или снять часть суммы с поступления поставщика — ту вагон возможностей даже штатно — «возврат поставщику» и новое поступление (что автоматом приведет к правильным суммам в учете, обороты — отдельная история) или документ «корректировки» — который тупо докидывает разницу (по типу доп.расходов в типовой ТИС). если речь идет о бонусах и премиях — то они вообщем тоже реализуются шттано как пример — поступление (прочее) услуга, с взаимозачетом на взаимрасчеты по товару. или иным способом.
.корректировка продаж — аналогично поступлениям.
я бы не стал типовой ТиС в части клона что-то переделывать в этой части (ПОКА). все таки конфа универсальнйо должна получиться. Кого не устроит — допил отдельный (или развитие функционала) — нет смысла писать НОВУЮ УТ11
А вот отложенный переход права собственности (на складе покупателя) — это уже чуть ли не стандарт. его было бы смысл впилить нормально (реализуется просто), а не притянутыми за хвост складами «товар в пути»… где под каждую отгрузку свой склад придется делать…
(53)
«К заявкам, по моему, важней корректная цепочка — заявка (с корректировками) — приказ на отгрузку — реализация.
У тебя такое реализовано? Я никак не соберусь :)»
— цепоряка заявок в ТИС — реализована штатно (описывал выше, требуется мелкая дорабтка для номера «сделки» да и то в рамках8-ки это может штатно получится — надо советоваться, писал выше)
— приказ на отгрузку смысла нет в клоне ТИС писать. — мы же не хотим писать новую УТ11 или полностью ордерную схему (пока)?
приказ на отгрузку реализуется в полпинка — перведом заявки со склада «основной склад» на виртуальный (или вполне реальный) склад «зона готовых к отгрузке» (готовые может сразу пониматься как и разрешенные, а разрешенные = приказ — может отдельно — то есть «основной склад» — «готовые к отгрзке» — «разрешенные к отгрузке». Реализуется в полпинка (простая обвеска не трогая глобальный код даже можно сделать). Операторами/юзерами авыполняется по нажатию кнопки.
Все что на складе «разрешено к отгрузке» — по нему выписывается реализации. на остальных — заблокировано.
у меня это реализовано статусами заявок (но делалось это давно и сейчсас бы чуть по другому сделал)
Рез.ме: в рамках создания КЛОНА — я бы не морочился (пока) реализацией этого функционалда как стандартного. На штатный функционал клона mnfrfz пришлепка реализуется в полпинка при необходимости — затраты на клюшках — пару часов если красиво и аккуратно.
«приказ на отгрузку реализуется в полпинка — перведом заявки со склада «основной склад» на виртуальный (или вполне реальный) склад «зона готовых к отгрузке» (готовые может сразу пониматься как и разрешенные, а разрешенные = приказ — может отдельно — то есть «основной склад» — «готовые к отгрзке» — «разрешенные к отгрузке». »
— причем состав заявок — !!!все штатным функционалом!!! — готовых к отгрузке и/или разрешенных — тривиально и содержательно (даже со всей истрией движений) смотрится типовыми отчетами ОтстакиТМЦ и Ведомость по остаткам ТМЦ
(55) CheBurator,
Всего лишь комиссионная торговля. И мы обязаны отражать в книжках и журнале с/ф отдельно свой товар/услуги, отдельно комиссионные по каждому комитенту. Притом налоговая хочет, что бы легче проводить перекрёстную проверку, не только отдельными строками в книжках и журнале отражать, но и выдавать отдельные с/ф.
(56) CheBurator,
— в типовой ТИС джля этого не надо ничего дописывать побольшому счету:
Тут я о своём геморрое радею. В металлоторговле есть такая засада. Вот ты взял металл у производителя, отгрузил его покупателю, успешно закрыл месяц. И где-нибудь в середине следующего месяца от производителя сваливается исправление чуть ли не половины всего месячного поступления с новыми ценами. И это безобразие нужно текущим периодом отразить, да так, что бы себестоимость не зависла. Еще и части покупателей, согласно условиям договоров, выставить по новым ценам.
(57) CheBurator,
Я опять о своём. У меня часто случается подписывание договора и спецификации на поставку (это заявка), который будет вывозиться не весь и не сразу. Особенно с тендерами. Подписали спецификацию, а вывозить металл по ней будут полгода чуть ли не каждый день. А склад, вдобавок, зачастую арендованный и хранитель хочет бумажку на конкретно сегодняшнюю отгрузку в конкретный сегодняшний камаз. Как-то без отдельного документа грустно.
Но, вроде, и касательно других возможных пользователей. Иметь отдельной бумагой приказ кладовщику от менеджера полезно для наведения порядка.
ээээ! вы не смешивайте спецификацию, то есть, грубо говоря, товарную матрицу договора. с заявками, которые отражают РЕАЛЬНО происходящие физические процессы. Я очень сомневаюсь, что по спецификации СОБИРАЕТСЯ СРАЗУ ВЕСЬ ТОВАР в одну большую кучу, и потом постепенно происходит типа «вот из этой большой кучи надо отгрузить вот такую кучку поменьше вот такого-то числа». Для склада заявкой на исполнение будет являться как раз «вот такая кучка поменьше на отгрузку вот такого-то числа». Все операции с такой кучкой и будут являть собой собственно складскую работу и складские документы. и вполне реализуется стандартной схемой работы заявок в типовой тис. Да, может быть несколько неудобно, но реализуемо (например, приказом на отгрузку может быть появление НЕПРОВЕДЕННОЙ РАСХОДНОЙ НАКЛАДНОЙ с пустой табличной частью. Новые накладные склад не имеет права создавать (тупо отобрано правами шттано), может только оперировать с уже существующими). А вот «спецификация» — как раз попадает под классификацию заявки как «длинной» — практически один-в-один такая схема работы как ты написал по металлопрокату у меня была в фармопте при отгрузках на бюбджетный фармации. Одна большая заявка (которая даже еще в большей части своей и на складе нет) — которая потом месяц-полтора отгружалась кучей накладных. И ничего — справились типовыми объектами метаданных.
Что и как делать — презумпция автора разработки.
Имхо, делать клон, заточенный на какую-то специфику именно автора — имеет место быть такая парадигма.
Но тис 9.2 получила такое широкое распространение именно ввиду свойе относительной простоты, и при этом вполне достаточной функциональности ДЛЯ БОЛЬШИНСТВА. Специфику точил каждый сам (тем более что дотачивается достаточно легко).
Такая концепция представляется мне обоснованной. Я бы и придерживался ее. Вплоть до «соглашения» не вводить новых объектов метаданных, предназначенных для отражения частных специфик. Свои предложения я автору высказал в этом отношении — я думаю, мы их обсудим на конференции.
еще раз: писать новую УТ11 — смысла нет. Надо где-то остановиться. остановить СЕБЯ.
Имеет смысл делать легкие улучшения, которые реализуются только добавками в код типовой (например, деление, заявок на длинные и короткие). новые метаданные/виды документов — имеет смысл делать (да и то надо думать/принимать решение), если это представляет из себя некий новый отдельный блок, которого не было в типовой, которые не встраивается в уже существующие цепочки документов (например, реализация факторинговых операций — где просто появляются два новых вида документа типа акт о передаче на факторинг и отчет по факторингу в конце месяца).
Как-то вот так я представляю себе доработки НОВОГО функционала.
(60) CheBurator,
У меня они в предметной области смешаны. Спецификация от обычного счета отличаются де юре, а не по факту отработки. Когда клиент подписывает спецификацию или берёт счет, ни кто не может сказать, за сколько дней и сколькими машинами он это будет вывозить. Разве что спецификация обычно имеет больший тоннаж и чаще выводится не за раз.
(62) CheBurator,
Это да. Но всё же предлагаю:
— Возможность ведения взаиморасчетов с разрезе счетов, множественное указание кред.документов в документах банка и кассы.
— Человеческий взаимозачет/переуступка долга.
— Приём на хранение, передача на хранение (расширение стандартной комиссии)
— Нормальное распределение доп.расходов на себестоимость при поступлении и прочих операциях, возможность указания доп.расходов сразу при поступлении
— Может быть векселя?
— Учет на складе по качеству и доп.характеристикам поставки, складская пересортица
— Возможность ведения взаиморасчетов с разрезе счетов, множественное указание кред.документов в документах банка и кассы.
Поддерживаю, выше писал. Под измерение счет нет необходимости выделять отдельное измерение, прекрасно реализуется
Друзья! Есть ли у кого возможность или желание дописать к этому конфигу небольшой модуль установки цен номенклатуры? Либо как в ТиС7.7 либо как в УТ11 или скрещением? Либо по-нашему попроще 🙂
И итоге со всеми хотелками — получаем УТ10.3…
думаю идея автора самая верная — базовый функционал, а остальное кто как хочет допилит.
(67) Il,
думаю идея автора самая верная — базовый функционал, а остальное кто как хочет допилит.
Если так подходить, лучше просто брать УТ. Гораздо проще по трудозатратам «отпилить» ненужный функционал (хотя бы скрыть ролями), чем допиливать ненужный. Бонусом получишь еще и развиваемую конфигурацию на поддержке, что бы не париться с вопросом с/ф и разновсяческой регламентированной отчетности и форм документов.
Наверное, если пилить что-то альтернативное, нужен альтернативный подход. Может быть смена документарной идеологии на другую. Например, процесс согласования заказов клиентов может породить длинную цепочку документов корректировки, которая только замыливает взгляд менеджера в журнале. Аналогично для процесса утверждения заказа поставщику. Работа со складом тоже далеко не всегда хороши ложится на документ (про склад Чебуратор лучше меня скажет, у него этот вопрос навороченней).
Было в прошлом тысячелетии такое понятие — АРМ. Автоматизированное Рабочее Место. Притом под ним обычно подразумевалась не настройка ролей при том же самом принципе работы «журнал-документ-отчет», а интерфейс, адаптированный под потребности и особенности.
(65)
— в принципе — интересное решение. Но немного противоречит смыслу кред.документа. Кред.документ — это некий «финансовый» документ, по которому возникают обязательства — это или платежи или отгрузки. То есть то за что нам должен клиент или мы должны клиенту. Внедрение в качестве кред.документа «заявки покупателя» в общем случае ведет к подвисшим остаткам и надо предпринимать доп.действия по закрытию таких остатков.
Например:
— выставили счет на 100 руб — во взаиморасчеты надо отражать? — вообщем-то нет, так как счет/заявка — это всего лишь некое ПРЕДЛОЖЕНИЕ клиенту. если отразили заявку во взаимлорасчетах — сразу поис долг. а клиент забил на эту заявку — вместе с закрытием заявки (которую забил клиент) — надо закрывать и взаиморасчет.
— если при проведении документов по взаиморасчетам (платежи/отгрузки) в кред.документе указывать счет/заявку, по которому идут эти взаиморасчеты — это уже как-то ближе к действительности и мне больше нравится. Но это приводит к тому, что нельзя выписать платежи/отгрузки без указания документа/основания (по которому можно вытащить заявку). А с учетом того,что в Типовой ТИС корректировка заявок выполняется не в смой исходной заявке, а корректировочными заявками (а как это в 8-ке делать? — ВОПРОС!) — то идентификация «корневой» заявки, которую надо указывать в документах взаиморасчетов — нетривиальная задача, если только во все документы не вводить дополнительный реквизит «сделка» (счет/заявка) — чтобы пропускать документы по этой сделке и она автоматом попадала в кред.документ — в итоге — это тоже самое, что элемент справочника «договоры» в группе какого-то договора.
Не мог бы ты более развернуто пояснить как у тебя работает/построена схема когда в кред.документе указывается заявкаПокупателя?
«У меня доработана штатная комиссия. Новый статус партии, несколько новых кодов операций. Тоже работает 🙂 »
— тоже можно, но мне кажется что более правильно концептуально — новый/отдельный участок учета/работы — новый/отдельный регистр. Это проще и прозрачнее.
надо подумать/посовещаться.
(65) по доп.расходам
«Документ доп.расходов делает движения с такими же измерениями и реквизитами, что делал документ реализации, но на сумму 100руб.»
— расход себестоимости увеличиваешь? а приход себестоимости? Можно подробнее покахать/посмотреть? (можно в личку или скайп Zlopun — на живых примерах посмотреть движения по регистрам — чтобы понять лучше? спсб.)
(65) » доп.характеристиках поставки хорошо выглядит, например, к «Пальто женское» характеристика «красное с перламутровыми пуговицами». Что бы не раздувать бесконечно номенклатуру. »
— мы об одном, но в разных терминах. — Это не доп.характеристка ПОСТАВКИ. это доп.характеристика НОМЕНКЛАТУРЫ (а где она — в поставке, остатках, реализации — это уже другое дело.). так что, таки да, учет по доп.характеристикам НОМЕНКЛАТУРЫ надо однозначно делать (и мне кажется что это будет самое большое дополнение в клон).
«Ну если уж говорить про штатный функционал, свойство партии и есть доп.характеристика поставки.» — а тут уже непонятно немного.. в ТИС этим пытались делать деление по характеристикам номенклатуры за неимением оных используя свойства партии, и учет остатков велся полностью на регистре партий (был у меня такой опыт). При наличии характеристик номенклатуры — такая потребность скорее всего отпадет. Я бы вообще подумал бы на тему отказа в клоне от свойств партии.
(65)
С управленческой точки зрения, я не нашел на складе излишек в свой карман, а балбесы-кладовшики перепутали два ящика. И если сделаю оприходование, просто завышу себе маржу по какой-то позиции.»
— если можно, то тоже посмотреть на живом примере. Примерно я представляю, но лучше глянуть. Предлагаемый документ «Пересортица» — может оприходовать списывать нужные «себестоимости» и количества. например запросто может быть пересорт 1 коробки Термосы1 и термосы2 — ну одинаоквые коробки по внешнему виду и где-то рядом. Только Термос1 — 12 шт на 12000 рублей, а Термос2 — 6штук на 6000 рублей. Как тут в «ноль» пересортить?
(68) угу, про АРМы — самое оно. по сути у меня в ТИС менеджеры и склад работают именно с АРМами — псевдожурналами текущнего состояния.
ну, до Ут10.3 — даже с обсуждавшимися ВОЗМОЖНЫМИ доработками — еще достаточно далеко (как мне кажется) 😉
(68) vcv, согласен — был похожий случай еще на клюшках, урезаная до мин. тис92 по точкам + допиленый уриб, в центре полновесная 9.2, которую впоследствии заменили на 10.3,
но если 77 урезать по времени вполне реально, то урезать 10.3 — это жуть
что касается задумки автора — очень хорошая тема для «ларьков» — кому «розницы» мало, а УТ уже много.
(69) CheBurator,
Использовать КредДокумент я решил потому, что по этому измерению был бардак, порождаемый редактированием документов задним числом. Пользователи не особо понимали, что такое КредДокумент. А теперь все знают — в рамках договора есть выставленные счета/спецификации, взаиморасчеты мы ведём раздельно по счетам.
В банковских и кассовых документах добавлена табличная часть с указанием кред.документов (заявок) и суммы, которая на них распределяется (есть вариант <авто>). Если сумма по документу больше, чем долгов по указанным заявкам, превышение считается «нераспределенным авансом» (пустой КредДокумент в регистре). Если в качестве кред.документа указана не заявка, определяется заявка по структуре подчинённости.
В реализации добавлен реквизит табличной части ПоЗаявке, что бы можно было выписывать реализацию по нескольким заявкам. Реализация, при проведении, формирует таблицу долгов по каждой заявке покупателя, указанной в табличной части.
Процедура в глобальнике глДвижениеДолгов проверяет переданный КредДокумент, если он не заявка, ищет корневую заявку сделки по структуре подчинённости (ДокОснование в шапке, ПоЗаявке в табличной части). Для заявки определяется корневая заявка по структуре подчинённости. То есть какая заявка начала сделку с учетом цепочки корр.заявок, выписанных на основании корневой (первичной) заявки.
Документ ОтменаЗаявок закрывает авансы по заявке (если есть) перенося их на неуказанный кредитный документ, превращая в нераспределенные авансы. Долги, естественно, остаются на своих заявках.
Сделан документ распределения долгов, который позволяет в рамках договора перебрасывать аванс с одной заявки на другую и закрывать долг на одной заявке авансом на другой.
Реализация без указания заявки или со значительным превышением объёма заявки запрещается полномочиями пользователя.
В реализации так же есть настройка, позволяющая указать, что какие-то заявки (или все) нужно полностью закрывать при реализации. При закрытии заявки авансы, числящиеся на ней переносятся на «нераспределенные авансы».
Введено понятие «планового долга» по заявке. Он состоит из фактического долга по заявке (остатки по КредДокумент в регистре покупателей) и неотгруженного остатка заявки.
По каждой заявке можно указать график платежей, но этот кусок у меня реализован дурно, поэтому отмолчусь.
Расширен штатный отчет ОплатаЗаявок, которые показывает не только остатки заявок, но и, по каждой заявке, фактический и плановый долг. График платежей (отдельный отчет по анализу долгов покупателей, сроков задолженности и всего прочего) тоже показывает как фактический, так и плановый долг. Отчет по взаиморасчетам фактически штатный.
(71) CheBurator,
— расход себестоимости увеличиваешь? а приход себестоимости? Можно подробнее покахать/посмотреть?
Смотри скриншот отчета по партиям наличным и партиям отданным (у меня с филиалами по комиссии работа). И в экселе служебный отчет об движении партии по наличным.
(73) CheBurator,
У меня жесткий партионный учет. Поэтому пересортица в первую очередь используется, когда на складе/офисе попутали и по факту отгрузили одну пачку металлопроката, а по учету — другую.
Оприходование/списание используется, в основном, не классически, а в виде доприходования/списания тоннажа в пачке металла при провеске. Принял металл по договору по теоретическому весу, но потом, по какой-либо причине потребовалось взвесить и доприходовать излишки веса или списать недостачу веса.
И в других областях торговли возможно аналогичное. Стоит две коробки с пуговицами. Аналогичные. По одной цене. Только одни черные, другие красные. Продавцы перепутали в тетрадке какие продажи. На инвентаризации выяснилось что по учету 40 черных и 60 красных, по факту 50 и тех и других. Тут бы просто «перекинуть» учетный излишек вместе с себестоимостью на другую номенклатуру/партию/характеристику, а не списывать и приходовать.
(77) Все нормально, примерно так представлял. Плохо одно — извращена суть «кред.документа». Которым может быть только то, что порождает взаиморасчеты — платежи или отгрузки. Ни счета, ни заявки не являются доками, порождающими обязательства перед друг другом. По сути ты конкретный ДОГОВОР (которым является выставленный счет/заявка при условии принятия его клиентом — то есть оплатой этого счета) опустил на уровень кредитного.документа.
В принципе, норм.решение. Введено понятие «сделки» по сути.
Немного непонятно, но вопросы уже в личке задам
(80) CheBurator,
Суть его какая-то неустойчивая к перипетиям жизни. Бухгалтер была в налоговой и банк разносила позднее обычного, склад накосячил и сегодняшнюю непроведенную накладную получится провести только завтра, менеджер обнаружил ошибку в позавчерашнем документе… В результате в кред.документе непонятным для пользователя образом то банк, то накладная, то вообще какая-то невнятная корректировка долга…
Более-менее это работает либо при жестком регламенте работы, или постоянном восстановлении последовательности. Первое мешает пользователям работу работать, второе замедляет работу с отчетами. А при достаточно регулярных ошибках восстановления последовательности велик риск, что на это вовсе забьют и взаиморасчеты в разрезе кредитных документов превращаются в седой замшелый «пересорт» с отсутствием малейшего смысла в движениях по новым документам.
В результате ни кто не смотрит на этот кред.документ в отчетах, а бухгалтера жалуются «у меня долга по договору нет, а реализация почему-то сделала проводку на 62.2».
(81) все правильно
То сто ты предложил выше — ты по сути превратил кредитный док в «кучу»
При таком варианте кредитный док совершенно излишняя сущность и его можно вообще убрать, потому что «куча» реализуется измерением договор.
Поэтому все что ты написал по работе с заявками в качестве креддокумента — спокойно и красиво — без всяких лазаний по структурам подчиненности — которые весьма неоднозначны могут быть для правильного определения главной заявки — спокойно и красиво реализуются на уровне договора, что и следует сделать без кредитного документа. То есть договору придается смсл сделка — в рамках договора может быть несколько заявок и вообщем такая же схема как ты нарисовал выше.
(79) «тут бы просто «перекинуть» учетный излишек вместе с себестоимостью на другую номенклатуру/партию/характеристику, а не списывать и приходовать.» — ага. волшебное слово «перекинуть».. 😉 — это и будет одновременное списание колва стоимости с одного товара, и повесить это колов и стоимост (или скорректированную стоимость) на другой товар. Ясен пень, что удобнее это делать одни документом. Трабла только в том, что пересорта как самостоятельного факта нет — это даже по инвентариным ведомостям отнесение излишков и недостач друг на друга.
(17) CheBurator,
Я такие хотелки решал просто — в договоре добавлял нужные поля (обычно разные реквизиты идут под разные торговые точки), договор обзывается по имени торговой точки. И делал печатные формы в которых нужные варианты реквизитов брались из договора. В восьмерке был еще вариант (для упрощения обновления) с использованием доп. реквизитов
Вопрос, а почему не посмотреть в строну УНФ конфигурация по простоте напоминает как раз ТиС (и даже еще проще) плюс еще много положительных плюшек, которые как раз отключаемы и в коробке уже синхронизация с сайтом и БП?
Спасибо автору за разработку, скажу за себя, как и многие на форуме, давно хотел сделать какую-то конфигурацию простенькую, для мелких магазинов и прочих участников мелкой розничной сети, но всё руки как-то не доходили.
Может действительно, если мы объедением силы, то получится СУПЕР ТИС))) в любом случае все мы люди не глупые, опыт есть, есть и багаж с внедрением, а такого рода программных продуктов нет, и скорее всего не будет.
Так что давайте граждане, на баррикады!
P.S. Готов поучаствовать в разработке!
Уж как-то забористо все получается!
Тут уж или наиболее простой вариант делать с минимумом документов и регистров для мелких ООО работающих по упрощенки по схеме «Доходы» или патент. С возможностью подключения кассового оборудования, и расчетом себестоимости продаж. Либо, не изобретая заново велосипед, использовать типовую УТ,
На мой взгляд используемый метод учета партий в разрезе документов поставки как в УТ 10 и выше, наиболее рационален, чем по создаваемым бесконечное количество раз элементам справочника «Партии». По крайней мере данные по продажам можно выгружать в какую-либо типовую типа БП и уже там шаманить глубже.
Кстати аналогом для партионного учета, реализованного в УТ10, была давно уже позабытая конфигурация ТиС 8.7. Но она была выпущена более 15 лет тому назад, и очень тормозила. Возможно алгоритмы проведения документов были коряво написаны, либо какие-то недочеты в самой платформе 1С; да и «железо» тогда слабенькое было. Вот и появилась на смену ей ТиС 9.2.
А с восьмого релиза платформы 1С опять вернулись к методу учета по поставкам как к более рациональному.
(87) те оесть партией является ссылка на документ поставки?
(87) все-таки (пока) мне кажется более удобной организация партий — именно как в ТИС 9.2 — спр.партии (в котором есть ссылка на документ) — при необходимости в спр.партии добавляются нужные реквизиты. если партия — ссылка на документ — то будет проблематично…
???
Уважаю, приятно, что не вымирает племя альтруистов.
Грустно что все это довольно быстро погибнет, а кто-то потратит на разработку этого свое время.
— для разработки нечто своего, нужна сильная методическая поддержка. Чего скорее всего нет.
Следствие — в лучшем случае получится повтор ТиС или Ут10, о чем автор сразу заявил.
Стоит ли тогда делать дубль два? Может проще взять УТ10 и расширить функционал тем чего нет в УТ11?
Но тут опять все упрется в отсутствие опытных методистов.
— разработка требует денег. Ладно опустим это — можно на энтузиазме вывезти.
— самое важное — разработку нужно уметь продать. А в среде участников похоже только программисты.
Конечно коммерчески удачные опыты самостоятельной разработки есть
1.Снегопат. Но у Орефкова за плечами был телепат и колоссальное уважение общества 1с.
2.Татиту со своим магазином. Его удача в его незаурядной коммерческой жилке.
….
(85) kao_andi, Добрый день! УНФ уважаю, работа в ней радует, но как и в остальных продуктах 1с — смущает громоздкий интерфейс и сложность кода в расчете себестоимости. Тут принципиально важно создать продукт маловесный с основными функциями. А там дальше пользователи пускай БСП прикручивают к ней или скрещивают с другими модулями. 🙂
(90) ну так основнавя идея и есть практически 1-в-1 ТИС повторить. К ней методическая поддержка практически не нужна. Ввиду простоты, обсосанности и сохранившихся мамонтов по 77
100% надо!
Многие спрашивали: «А есть 8-ка, как ТиС 7.7?»
(89) Партиеобразующих документов не очень много:
— ввод остатков ТМЦ
— приходная накладная (и не обязательно еще делать отдельно для розницы и по импорту)
— оприходование излишков
Возврат от покупателя можно возвращать на партии отгрузки
Сделайте их с одинаковыми реквизитами и храните в них всю нужную вам информацию.
В конце концов в регистре учета партий можно завести реквизиты.
Что мне больше всего не нравилось в ТиС 9.2 так это учет партий в разрезе розничных цен и перемещение их со склада на склад. Что в принципе методологически не верно! Партии должны учитываться в целом по организации, а не по отдельному складу в рамках этой организации. Фирма 1С пошла на компромиис, чтобы обеспечить функциональность системы в режиме распределенной базы данных, хотя не видно какой в этом смысл: все равно потом надо перепроводить БД для восстановления ГП.
(94) в типовой тис партии учитываются как раз по организации, по складам не учитывают. Пиплы партии привязывают к складам через мол в партионном учете в первую очередь не для расчета себестоимости, а для учета матответсвенности и исчисления прибыли по фактически самостоятельным (с точки зрения собственника-управленца) магазинам-точкам. Обеспечение таких хотелок в рамках тис реализуется другим образом, а не через выкручивание партионного учета как это обычно делают эмулируя склады в партиях через мол — но тут да, может быть не сильно удобно и замудрено по мнению типапродавановведущихтипаучет — потому как обычно хочется чтобы было и просто и так как нужно и потом оказывается чтобы это было максимально близко к белой бухгалтерии
(91) я всегда для розничной торговли использую Розница 2.2, работал с многими пп 1С, от Уполномоченного до КА и УПП, но удобнее и приятнее чем 1С:Розница 2 я еще не встречал.
(153) по данному проекту речь о рознице не идет. ТиС (которая перепиливается) менее всего пригодна для розницы.
на начальном этапе для ускорения запуска в продакшен — я бы розничный блок из ТИС вообще не переносил. Ибо там он только для того что он там.
(154) CheBurator, ну тут ты ошибаешься, ТиС по уровню внедрения в рознице имеет огромную часть, лишая этого блока 2/3 клиентов отлетит.
(155) да,у меня тоже у любимого лавочника-хомячка крутится розница на ТиС в 11 точках и регулярно новые появляются. Но там от исходного «Чека» розничного — минимум осталось. аналогично — все кто ставит ТиСовскую розницу — там от нее только название — все пилят скидки, дисконты, 3 по цене двух, купи 3 по распродаже получи 4 беспллатно и т.д. и т.п. Поэтому розница в ТиС — вещь в себе. Аккуратно надо.