Когда «маленькие» ошибки в программе оперативного учета приводят к большим проблемам. Часть 2

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

Внес изменения в накладную «задним числом» – подвел компанию под камеральную проверку

Периодически возникает необходимость изменить ранее выписанные «отгрузочные» документы (заменить количество или наименование отгруженного товара, его цену, адрес и наименование получателя товара и т.п.). Часто менеджеры это делают прямо в базе оперативного учета, что называется, «задним числом». И это приводит к большим проблемам.

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

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

Здесь нет никаких проблем, если только контрагент не использует неподходящую систему налогообложения. Так, если покупатель на «упрощенке», то он не может продать вам ваш товар обратно с НДС – у него в природе такого налога нет.

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

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

Итак, зафиксируем еще одно важное правило: то, что уже произошло - изменено в программе быть не может; оно может быть только откорректировано.

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

Неправильно ввел документ – украл чужое рабочее время

Бывает, что один бумажный документ в программе оперативного учета отражается двумя записями. А потом бухгалтерия сходит с ума, пытаясь понять, где же эта отгрузка.

Или, наоборот: бумажных документов несколько (да еще и от разных дат), а менеджер сделал всего одну запись. Соответственно, бухгалтеру приходится сидеть и на калькуляторе суммировать все эти документы, чтобы вычислить, где же эти данные в программе оперативного учета.

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

Вот почему при вводе накладных так важно придерживаться правила: один бумажный документ = один документ в программе оперативного учета.

Не стал оформлять возвращаемый товар – добавил работы бухгалтерии

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

Бизнесу в данной ситуации все понятно: нет товара – нет проблем. А как бухгалтерии отразить возврат товара в 1С при таком подходе, не понятно, поскольку и покупатель товар не получил, и на складе он не появился, и вообще остается загадкой, что с ним произошло, и как все это отразить в учете.

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

Отсюда следующее правило: товар, который возвращают покупатели, должен приходоваться на склад.

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

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

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

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

Часто в оперативном учете происходит так, что товар продан раньше, чем куплен, то есть менеджер сначала вводит накладную на реализацию, а через некоторое время – накладную на поступление. Чем такой ввод накладных опасен?

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

Такие ошибки в расчете себестоимости приводят к ошибкам в расчете налога на прибыль. Причем он может быть как неоправданно завышен, так и неоправданно занижен.

Поэтому так важно следить за хронологией документов поступления (оприходования) и реализации (списания) товара.

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

Выбрано неоптимальное решение по автоматизации – усложнена жизнь всем сотрудникам

Напоследок расскажу вам одну историю. К нам на бухгалтерское обслуживание пришла компания, у которой изначально были две базы – 1С:Управление торговлей и 1С:Бухгалтерия предприятия. В этой компании был некий ответственный сотрудник, который очень сильно поднял свою ценность в глазах руководства, утверждая, что только он в состоянии разобраться в правилах работы в 1С:УТ. И он до такой степени убедил всех в своем знании, что практически парализовал работу менеджеров, говоря: это нельзя, то нельзя, даже доработать нельзя и т.п.

В конце концов с его подачи приняли совершенно удивительное решение – внедрить еще одну программу оперативного учета, в которой все будет «можно».

Получилась парадоксальная схема: реальный оперативный учет велся в программе «А», потом эти данные перегружались в 1С:УТ, а потом - в 1С:БП.

Когда мы начали общаться с руководителем компании, мы задали совершенно резонный вопрос: зачем вам все это нужно? Не проще ли сразу загружать данные из своей новой программы оперативного учета в 1С:БП? На что директор нам ответил: «А как же тот сотрудник, который один знает, как все программы между собой обмениваются? Вдруг, если выпадет одно звено, вся цепочка разрушится?».

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

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

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

Ведь одно из преимуществ нашей компании – это высокие профессиональные компетенции в вопросах автоматизации всех видов учета.

Обращайтесь, мы всегда рядом с Вами!