<?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='\
Это не «зачем-то», а требования 54-ФЗ.
И правильно сделала. Потому что правильно — это оформить чек на возврат прихода.
Контроль остатков в розничной торговле? Оригинально… Это если сказать мягко…
По факту ваша обработка — производственная диверсия.
Эх, я бы и рад был бы, если бы все было так оптимистично, как вы пишете.
Согласен, этот момент не знал.
Они сами никак не могут понять как правильно. Отказались лишь потому, что это сложно (по их мнению) для обучения кассиров.
Не совсем розничная, а оптово-розничная. Напомню — это УТ 11.4. Несколько складов-магазинов, по одним оптовая торговля, по другим розничная.
Но не в этом дело — контроль остатков для них очень важен, чтобы поддерживать хоть какой-то порядок.
И я не пойму вопроса — неужели в розничной торговле контроль остатков не нужен?
А по факту — не проводится документ «Отчет о розничных продажах», если в него попадает номенклатура из чека на возврат. Попадает она туда с минусовым количеством.
(1)
И правильно сделала. Потому что правильно — это оформить чек на возврат прихода.
Вот здесь уже я не согласен, при формировании чека из такого расходника, разве не проставится возврат прихода, поэтому как раз правильная схема возврат -> расходный на основании возврата.
(3) вчера специально проверил оба варианта. В двух случаях печатается идентичный чек возврата прихода. И получается минусовой отчет по данной позиции, если в этот день она не была реализована (правда отчет у меня проводится с контролем остатков)
Другое дело что из чека ККМ на возврат не напечатать заявление на возврат и сложно отслеживать и искать возвраты.
По мне так схема работы через заказ на возврат, возврат и РКО единственно правильная.
Да причем тут идентичность чека, если мы получаем абсолютно разное содержание операции с точки зрения бухгалтерского учета.
Розничная продажа отличается обезличенным подходом к контрагенту, 62P, в отличие от остальных 62-х имеет единственное субконто — склады, тогда как у остальных 62-х — это контрагент и договор.
При розничной продаже мы будем иметь проводки Дт 50.1 — Кт 62Р при продаже и Дт 62Р — Кт 50.1 при возврате.
Если оформлять возврат через Возврат + РКО то в цепочку проводок попадет 62.02, который требует гораздо большего документального оформления со стороны бухучета, потребуется договор с контрагентом и его паспортные данные. Т.е. на ровном месте возникает необходимость очень большого пласта первички для оформления операции возврата. Поэтому вполне понятно нежелание бухгалтеров так работать.
Такая схема может и должна применяться в том случае, если с покупателем действительно составляется договор и дальнейшая поставка и возвраты осуществляется в рамках этого договора. Со всем сопутствующим документальным оформлением.
А если речь идет об обычной рознице, то так делать неверно, плюс могут возникнуть вполне справедливые вопросы при проверке по поводу наличия договоров и их реального характера. При этом также следует учесть, что нормы 502 ГК РФ и ЗоЗПП не содержат требования предъявления покупателем паспорта или письменно оформлять заявление на возврат. Для этого достаточно кассового чека (хотя и это не является необходимым условием).
Получается тупиковая ситуация: покупатель не обязан предъявлять паспорт и вполне может не иметь его с собой. А бухгалтер не имеет права отдать деньги по РКО без паспорта (и договора с покупателем). Выхода тут ровно два: обостряем конфликт и посылаем покупателя за паспортом, теряя его лояльность, либо отдаем ему деньги и закрываем документы левыми данными, либо с нарушениями их оформления.
А то, что сделал автор обработки — это производственная диверсия. Потому что покупатель делает возврат и уходит с деньгами на руках, а бухгалтер остается с кучей РКО на неустановленных лиц, которые ей надо как-то отразить в учете.
(2)
Не нужен и даже вреден. Если товар стоит на витрине / лежит в корзине у покупателя — то он должен быть продан, независимо от того, есть ли он по остаткам. Актуальность остатков поддерживается инвентаризацией.
(2)
Выше я подробно написал как правильно, почему и когда нужно делать так, а когда иначе.
(2)
Оптово-розничной торговли не бывает. Оптовая предусматривает наличие договора между покупателем и продавцом, т.е. проводки через 62.01 / 62.02, возвраты идут тоже в рамках договора и производятся через возврат — РКО, хотя последнее не обязательно, я могу не забирать деньги, а взять на них в рамках этого же договора иной товар. И опт — это практически всегда выписка товара без его физического наличия здесь и сейчас. Покупатель выписывает товар у менеджера по учетным остаткам и уже после этого идет получать товар на склад, может быть даже и не сегодня.
Розница — это преимущественно обезличенные продажи здесь и сейчас, т.е. покупатель сам выбирает товар из наличия и оплачивает его на кассе. При этом никакой договор с ним не заключается, в системе он никак не идентифицируется (в лучшем случае по номеру скидочной карты, но тоже скорее всего обезличено, ибо хранение паспортных данных добавляет кучу головняка с ПД).
(7)
Законодательные размышления ставят рамки, которые мы обязаны соблюдать вне зависимости от того, как ведем учет, хоть в УТ, хоть в Экселе.
(7)
Эта информация устарела и не соответствует текущим законодательным нормам. Ниже прикрепил скриншот из Консультанта.
(7)
Это — устаревшая информация. Все необходимое в текущих версиях УТ реализовано, это именно то, что вы назвали:
Вы же для чего-то принялись изобретать велосипед, хотя более правильно было бы проводить отчет о розничных продажах без контроля остатков. Да и вообще надо было начать оттуда, посмотреть логику проведения и понять, то ли это недоработка УТ, то ли у вас что-то с настройками.
(4)
А скажите, при этом сообщение какое-нибудь выдается? Или проводит без каких-либо ошибок?
(9)
Знаете, ввёл вас в заблуждение. Контроль остатков организаций выключен. Другое дело, не понимаю почему с ним не даёт провести. Ведь это в отчете значения с минусом а по факту товар то прибавляется, какое ему дело до остатков если они увеличиваются!
Я сейчас просто буду блокировать пробитие этих чеков по предыдущим сменам и верну возможность создавать только возврат на чеках в закрытых сменах.
(10)
Я сейчас просто буду блокировать пробитие этих чеков по предыдущим сменам и верну возможность создавать только возврат на чеках в закрытых сменах.
А потом к вам придет покупатель с возвратом. Вы его пошлете за паспортом (потому что РКО), он обидится и потопает прямиком в Роспотребнадзор. И будет прав, потому что отсутствие у него паспорта не является основанием отказа в возврате.
Либо вы отдадите деньги без паспорта и нарушите правила оформления кассовых документов, что может вылиться в 10 тыр штрафа по 120 НК РФ.
(11)
Даже пытаться не буду Вам рассказывать как мы работаем, ваши сообщения в которых вы все знаете за всех просто восхищают но не создают интерес к продолжению диалога.
Только интересно, перед кем я на ЕНВД должен свои РКО показывать…
(8)
Получается для УТ 11.4 эта информация тоже устарела?
Именно оттуда всё и началось. Поэтому сначала делали через отключение контроля остатков (пару документов и только главный бухгалтер).
Разрешать кассирам каждый раз отключать контроль остатков, да вообще чтобы они знали об этой функции руководство правомерно отказалось.
Таким образом — по оптовому складу (для оптовых продаж) требуется контроль остатков, по розничному, как вы пишете, нет.
Значит решение — использовать тот алгоритм, который предлагает 1С уже в 2018 г., когда 54ФЗ уже действует.
А для этого и потребовалась доработка.
(12)
И не надо, я за время своей трудовой деятельности достаточно насмотрелся на организации и ИП которые работают как им удобно, а не так как нужно. Также насмотрелся и последствий.
(12)
ЕНВД уже отменило кассовую дисциплину?
(13)
Я вам написал, что ваше решение требует паспорт при возврате денежных средств, который вы требовать не в праве. А дальше смотрите сами, что вы будете нарушать.
А забавно было бы собрать группу (большую группу) проверенных модераторов, которые бы одобряли статьи к публикации :)) понимаю что это не реально, но качество контента выросло бы в разы. А так от постоянных дублей, высеров какой я хороший и вбросов говна заведомо диверсионных действий, никто не застрахован, особенно молодые специалисты.
(15)
идея отличная, но действительно не реальная.
Тем более, что нужно было бы еще отслеживать и комментарии, не относящиеся к теме публикаций.
Или комментарии «почтальона Печкина» от 1С — «я знаю что правильно вот так, но как сделать это в программе я вам не скажу (потому что сам не знаю)».
Ведь только время зря такие комментаторы отнимают, ничего дельного не предлагая.
(16)
Вам русским по белому написали два сценария действий и когда какой надо применять, с какими последствиями. Вы же либо не понимаете о чем идет речь, либо не хотите понимать. Если вы продали товар в рамках розничной купли продажи, т.е. вам дали деньги — вы дали чек, то и возвращать его нужно через чек на возврат. Почему при это не проводится ОРП и причем тут контроль остатков — это уже вопросы не к методике, методика правильная, а прежде всего к вашим настройкам УТ.
(16) Столкнулся с той же проблемой, ОРП не проводится, ругается на отрицательный остаток на складе при проведении ОРП в котором были возвраты и они в документе идут отрицательным числом. Чеки при закрытии смены удаляются и они больше не создают движения по регистрам.
Удалось решить проблему?
Ошибка возникает в процедуре «ЗаполнитьВидыЗапасовПоТаблицеОстатковСформироватьВТНовыеРез
В общем-то я нашел условие, которое должно быть выполнено, чтобы не было ошибок, оно выглядит вот так
ИначеЕсли (КоличествоТовара > 0 И КоличествоОстаток > 0)
Или (КоличествоТовара < 0 И КоличествоОстаток < 0) Тогда
КоличествоТовара — это количество в документе, у нас -1
КоличествоОстаток — это на складе, у нас 0
Смущает условие «Или (КоличествоТовара < 0 И КоличествоОстаток < 0», но очень часто кол-во на складе = 0, а не меньше нуля.
(18) Само решение я в публикации и написал.
А так да, в коде есть условия, которые не применяются к отрицательному количеству в табличной части.
Не совсем помню в каких процедурах искал ошибку (более 10-ти часов потратил на поиск ошибки), но приведенное вами название процедуры очень знакомо.
(19) Дело в том, что мы проводим продажи в Рознице, а не в УТ. В УТ по обмену попадают документы из Розницы и в УТ ОРП уже не проводится. Ваша публикация подразумевает то,что продажа и возврат должны быть в УТ .
Но вот как мне победить это, пока не могу понять.
Нашел причину.
В моем случае дело было в настройках контроля остатков, в УТ три вида контроля, если выключить контроль остатков по организации и включить Контролировать обеспечение в настройках склада, то ОРП проводится (с возвратом), товар встает на остаток и остатки контролируются.
(21) да, кстати, отключение контроля остатков решает эту проблему.
Но в моем случае контроль отключать нельзя было. И нельзя было даже обучать продавцов, чтобы отключали на время (чтобы не пользовались в других ситуациях)
Да, а как по Расчету себестоимости (если возврат товара в другой день)?
При минусовом остатке товара в Отчете о розничных продажах, партия не подставляется и себестоимость по этому товару и этой операции не считается. Только при схеме: Возврат товара клиенту — Расходно-кассовый ордер — себестоимость расчитывается правильно..
(6)
Прикольная ересь.
И кто же мне запретит в маленьком магазинчике вязания веников, где благополучно стоит розничная касса, выписывать счета на поставку моей незаменимой продукции для соседского ЖЭКа? Пусть даже и с того же самого склада, откуда ведётся розничная торговля?
Ещё более интересно мне, где можно в конфигурации УТ найти проводки по счетам. Вот сейчас специально залез в конфигурацию управления торговлей (нет), дабы убедиться лишний раз, что я не верблюд.
Ну да, ну да. Особенно в наших реалиях, когда ты пока не купил партию товара, никогда не сможешь предсказать его стоимость у поставщика. Для крупных компаний эти ценовые колебания, конечно, нивелируются объёмами продаж, но даже они редко рискуют выставлять не обособленные счета на товар, большая часть которого ещё не имеется у них на складах. Что уж говорить про разного рода мелкие ИП?