<?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. Перемещение товаров между фактической и липовой бухиями
2. Продажа товаров, часть которых прошла по левой, а вторая — по правой бухии
Понятно, что такие операции будут требоваться сплошь и рядом при работе. Они точно получатся при указанной схеме учета?
(0) Налоговая, фас! :)))
Первый раз слышу о массовых попытках указанных в заголовке…
Хорошо, что в заголовке использовано слово «попытка». Статья рассматривает, на самом деле, идеальный вариант фирмы, где виды деятельности никак не пересекаются, скажем, ракетостроение, продажа канцтоваров и содержание борделя. В реальной практике схема едва ли сработает. Статья — типичный пример того, что может посоветовать вам консультант во франче, чтобы продать очередную коробку 1С.
В реальности, без правки регистров/документов не взлетит…
Еще способ: 3 фирмы и 2 юр. лица… + небольшая доработка документов/глобальника/отчетов/регистров напильником.
Кто бы тут что не трындел — схема реальная и рабочая. Правик в конфигурацию вносятся минимальные.
Все работает. Проверено неоднократно.
Когда юхвери не знают возможностей, описанных в сабже, — и рождаются такие выморочки… что опупеть… сталкивался.. знаем… проходили…
Основной вопрос, который возникает при применении таких схем — как «хозяину» увидеть свой доход реальный…
(6) В реальности, всё гораздо сложнее… и без заведения 2-ых сумм в документах /регистрах помимо 3-х фирм не обойтись.
(1)
> 1. Перемещение товаров между фактической и липовой бухиями
При такой схеме это не требуется.
> 2. Продажа товаров, часть которых прошла по левой, а вторая — по правой бухии
Часть товаров оформляшь документом(ами) от имени левой фирмы, вторую часть — по правой…
(2)
Налоговая не только в курсе, но и в доле… 😉
(4)
Любитель борделя на ракетостоительном заводе?
> Статья — типичный пример того, что может посоветовать вам консультант во франче, чтобы продать очередную коробку 1С.
Ты, Планет, в своей совдепии все еще заморачиваешься продажей семерочных коробок? Бедолага!
Цивилизованные люди давно отказались от такой фигни… 🙂
(5, 7)
Обсуждаемая схема не предполагает расчет (учет) бухгалтерской маржинальной прибыли. Для этого есть бухгалтерская программа.
Задача бухгалтера — сгенерить бухгалтерские документы так, чтобы учет выглядел правдоподобно. В первую очередь — обеспечить неотрицательные остатки товаров в учете на любой момент времени.
То, что ты, Ёпрст, предлагаешь реализовано в другой типовой конфигурации — Торговля+Склад ред. 8.х
(6)
> Основной вопрос, который возникает при применении таких схем — как
> «хозяину» увидеть свой доход реальный…
Если при списании партий убрать сортировку по фирмам. Учет должен получиться похожим на реальный.
Как считаешь?
(11) Спасибо, я в курсе.
(12) Встречный вопрос:
Как при такой схеме будете учитывать простейшие примеры:
1. Товар пришел по одной цене, рассчитываемся с поставщиком по другой.
2. Товар пришел от одного Поставщика (по бумажкам), расчет с другим (в реальности)
3. Продали по одной цене, в бумажках другая..
4. как обелить/очернить товар ? …
ну и т.д..
ЗЫ: без вторых цен не раализуемо.
вот попробуй с такими 1снегами удвой ввп
(15)>вот попробуй с такими 1снегами удвой ввп
Да! Вот коммуняке на бумаге запросто и удваивали, и утраивали? :)))
(14)
п.1,2,3 Оформляется два документа по разным фирмам — ООО «Подставное» (реальный учет) и ООО «Белое-Пушистое» (виртуально-бухгалтерский учет)
п.4 Используем ООО «Белое-Пушистое» (виртуально-бухгалтерский учет)
Обелить — поступление из помойки;
Очернить — реализация химчистке.
З.Ы. Взлетает?
(17) Неа .. всё равно нужны еще суммы.
С твоей схемой не все варианты учитываются. Это пройденный этап… 🙂
(18)
> всё равно нужны еще суммы.
Два документа — две цены, две суммы. Какие суммы еще нужны?
Какие варианты не учитываются?
> Это пройденный этап… 🙂
Поделись опытом. Чтоб другие не проходили этот этап…
(19) В твоей схеме нельзя учитывать откаты/бонусы.
Есть товар, который нельзя продавать по «белой» ниже определенной цены, например (по законодательству, например, алкоголь)
Вот для этого 2 цены в документе — черная/белая.. ну и т.д.
Если не лень будет, напишу все случаи..попозже.
Не, poppy, схема ацтойная все равно.
>> 1. Перемещение товаров между фактической и липовой бухиями
> При такой схеме это не требуется.
Убила! А как же продавать официально товары, купленные через левую фирму? Правильно, перемещением с одной фирмы на другую (тонкости, как это проводить по документам не рассматриваю). Сплошь и рядом именно так и делают.
> Часть товаров оформляшь документом(ами) от имени левой фирмы, вторую часть — по правой…
Угу. А ты помнишь, какие по какой фирме прошли? А если один и тот же товар и там, и там? Ты спустись на землю и посиди пару часов на оптовом складе. Вот стоит клиент, набирает корзину товаров, позиций эдак двести. За ним — еще пять клиентов. Предложи вариант, как операторы разбить эту корзину на две накладные, и как объяснить клиенту, почему она так сделала (хотя это и проще)?
(21)
> А как же продавать официально товары, купленные через левую фирму?
> Правильно, перемещением с одной фирмы на другую
Перемещение между фирмами — это пара документов Реализация+Поступление. Использование в этих документах фирм с аналитикой «Реальный учет» приведет к искажениям — задвоениям оборотов.
В обсуждаемой схеме при т.н. перемещении не нужно создавать Реализацию, достаточно оформить поступление по фирме «ООО «Белое-Пушистое» (виртуально-бухгалтерский учет)».
Назвать такое действие перемещением язык не поворачивается… 😉
> Предложи вариант, как операторы разбить эту корзину на две накладные, и
> как объяснить клиенту, почему она так сделала (хотя это и проще)?
Это все твоя извращенная фантазия, Планет! Хотя, не исключаю, что твои клиенты так и поступают… 😉
Выбор фирмы для документа оператором должен быть основан на следующем:
— необходимость оформить твердые копии документов;
— на какое юр.лицо будет (была) произведена оплата, форма оплаты нал/безнал;
— вероятность влететь на контрольную закупку…
Оператор не должен париться по вопросу на какой фирме числятся товар. При условии что нет других административно-политических ограничений.
(20)
Эта схема еще много чего другого не умеет. Например, варить кофе… 😉
Откаты/бонусы — это отдельная тема. При их наличии желательно учитывать их финисовый результат. В типовой ТиС механизмов для такого учета нету. Поэтому искать черную кошку в темной комнате — достаточно глупо. 😉
Про алкоголь не очень понятно. Сделка состоит из двух частей — черная=реальная и белая=виртуально-бухгалтерская. При такой постановке задачи она вполне нормально оформляется обсуждаемой схемой.
(16)
> Да! Вот коммуняке на бумаге запросто и удваивали, и утраивали? :)))
Считаешь, все что говорит Планет нужно делить на три? ;-)))
(15)
> вот попробуй с такими 1снегами удвой ввп
Это не одноэсники плохие. Это заказчеги не хотят удваивать…
По этому поводу песенка
Эх, poppy…
> не нужно создавать Реализацию, достаточно оформить поступление по фирме «ООО «Белое-Пушистое»
Не путай теплое с мягким =) Неофициальной фирмы нет вообще, поэтому, поступление от нее официально ты не оформишь. На точке лежит 15 коробок чего-то, все продаются по 20 рублей. 5 — куплено официально по 18, 10 — не официально, по 14. Я пришел и купил 13. Как выписываем документ? Партии не потянут, потому что фирмы разные. Усложним задачу: я купил 8 в розницу, а ты — оптовик, для тебя действует vip-цена, но не официально. Ты забираешь 6, и их нужно вывести из официального учета, бутто бы их и не было. Твоя схема может и сработает, но только там, где нет операций задним числом. А если их нет, то какой смысл что-то прятать? Все игры с официально/не официально направлены для уменьшения налогов.
(24)>Считаешь, все что говорит Планет нужно делить на три? ;-)))
Нет!!! Просто умножать на ноль :))))
поппи глаголет все правильно..
ща просто времени нет немного…
вариантв решени я- есть и без лишних заморочек…
как пример:
Епрст немного «путает» понятия
1. Товар пришел по одной цене, рассчитываемся с поставщиком по другой.
.. оч.просто: оформляет приход 10 шт по 50 рублей товара рельса, итого по «проводкам себстоимости» = 500 рублей, в сумму взаиморасчетов по доку пишем РЕАЛЬНУЮ сумму, например 800 рублей… итого: на складе товаров на 500 руб, долджны поставщику — 800 руб…
.. здесь тоже есть «дфрки», но уже гораздо меньшего размера, а если сетсь и прорисовать конкретные схемы — то куча всяких «вторых» цен отпадет сама собой.. и доделыватть/дотачивать не 100%, а всего 10% придется…
(27) Я не «путаю» понятия.
Продал я в «белую» 10 бутылок по цене 20 рублей, а в документе должен показать 100 рублей, и по бухгалтерии — тоже 100 рублей. т.к по законодательству не могу продать ниже 100 рублей.
Оформи ка ?
«в сумму взаиморасчетов по доку пишем РЕАЛЬНУЮ сумму, например 800 рублей…»
Афигеть, а сумму эту с потолка будем брать ? Читаем внимательнее мои посты:
>>>>ЗЫ: без вторых цен не раализуемо.
(28) что-то мы путаем… если продали ВБЕЛУЮ на 200 руб, то и пойдет в учет 200 руб, а если надо показать другую сумму — это уже «почерному» получается..
(29) возможно, но ни разу не видел, чтобы манагер опернировал двумя ценами.. они-то и чб схему с одной ценой еле тянут. а уж с «двумя»… вторые цены вылазять только во время «причесываия».. т.е. обеливания
Все решается если между документами описывающими одно и тоже действие но в разных учетах, обеспечить некую связь. Тогда в отчете можно будет показать сколько клиент оплатил, и какова в сумме оплаты сумма отката
Схема отличная. Запущена и опробована на реальном предприятии (ТиС 9.2 рел.947 в ТиС 8.7 кажется еще проще реализовать). Ситуация сложилась удачно и доработок не потребовалось — использован исключительно функционал типовой конфы.
Единственная и серьезная проблема внедрения — необходимость выделить для этих целей грамотного специалиста по 1С, т.к. бухи не могут работать с ТиС с рождения (и это практически не лечится), а среди манагеров и операторов нет специалиста реально умеющего работать с 1С ТиС. Проблему решена следующим образом — выбрали самого грамотного оператора и для него подготовили регламенты по действиям в ИС, затем в течение нескольких месяцев их дополняли новыми вариантами (которые не учлись на первоначальном этапе).
Результат. Поступления на белую и черную, реализация с белой и черной. По мере необходимости регламентные операции по обелению и очернению, которые можно делать и переделывать столько сколько нужно для получения необходимой белой отчетности.
Возникла проблема аналитики по поставщикам (анализ данных по реальным поставщикам после обеления/чернения), но на тот момент она была не актуально и поэтому рассматривалась только в качестве возможной в будущем.