Комментарии 15
Не увидел в статье отказа от переноса остатков.
А где вы увидили их перенос?
В конце объясняется почему при данном подходе к разработке их можно не переносить.
Что делаете с тем, что уже на балансе в момент начала использования "новой" системы?
Если я всё правильно понял, они показывают ошибку при отсутствии товара. И если он физически есть,а по базе его нет, то его просто дописывают в новую базу. Похоже на переучет, растянутый на месяцы(годы)
Как очень подробно описано в статье, ничего не делаем.
С момента начала использования "новой" системы, мы относительно быстро доставим товар получателю или вернем продавцу или констатируем что он потерялся.
Таким образом сравнительно быстро товара у нас не станет физически, и его отсутствие у нас физически будет равно отсутствию его на балансе.
Отчет об текущих остатках на балансе Ozon из такой системы не получить. Да и вообще как узнать хотя бы общую сумму на балансе Ozon на конкретную дату без переноса остатков? Только смотреть в старой учетной системе и вручную складывать с новой?
Не понятно, как определяется "Текущее состояние". Например предполагаемое состояние "Выдача клиенту", текущее состояние неизвестно, т.к. остатки не переносились. Стоимость товара может принадлежать как внешнему интернет-магазину так и Ozon.
Учитывая систему "Подумай дважды", можно узнать текущее состояние на балансе Ozon, без суммирования со старой системой. Нужно лишь подождать пока новый сервис немного поработает.
По "Текущим состоянием" понимается количество товаров в Ozon на данный момент.
Нужно лишь подождать пока новый сервис немного поработает
Правильно ли я понимаю, что это "немного" находится в прямой зависимости от времени жизни отдельно взятого остатка на балансе сервиса? Если так, то такой подход не применим для учета долгоживущих остатков. Неликвиды на складе магазина - не редкость, даже у продуктового консервы год-другой могут валяться. Это стоило бы указать в статье.
Правильно, но в случае, если у вашего объекта учета очень длинный жизненный цикл, можно придумать новое событие, которое может посавить ваш объект на баланс.
Например, в том случае, если в продуктовом консерва лежала до запуска сервиса, и еще долго будет лежать, можно поймать момент, когда у нее меняется цена (в больших сетях цены меняются приблизительно раз в неделю).
Вот лежит товар на полке (едет в контейнере, находится на ответственном хранении у кого-то и т.п.). Как понять, что ему надо менять цену? Таким событием может быть инвентаризация. Но Это фактически равно переносу остатков.
Предположим цена у консервы из примера и правда поменялась из-за инвентаризации.
Произошло событие изменения цены, товары очутились в моей балансовой системе.
Я же не переносил остатки. Они сами перенеслись из-за того, что я ловлю события, выявляю положения товара, которое следует из события и сравниваю его с предыдущим.
Таким образом вам не нужно переносить остатки при внедрении такового сервиса.
В том то и дело, что цена от инвентарицазии не поменялась. Но вот провести её - как бы нужно. но при этом - как узнать, что списывается (недостача), что приходуется (излишки) (а это влияет на бух результат, прибыль и прочее), если остатков от предыдущей системы нет?
Инвентаризация - это стандартный способ актуализировать остатки при внедрении новой системы, если мы не очень доверяем остаткам в старой. По сути, как сказал @Fragster, инвентаризация по затрачиваемым усилиям фактически равна переносу остатков.
Я в 1С на переносе остатков не одну собаку съел.
Описанное Вами решение, отлично подходит для вашей задачи. Автоматизируемый процесс динамичен и в нём есть акторы генерирующие события. Перенос остатков у Вас есть, только он по требованию. Через неделю после запуска в ней начнут крутиться новые объекты учёта, а вот код переноса остатков останется.
Мало того это применимо только к отдельным разделам учёта. Если необходимо перенести данные учётной системы всего предприятия без этапа переноса остатков не обойтись.
Описанный выше случай с неликвидами в принципе решается инвентаризацией, Хотя если кладовщики узнают, что от них зависит появление товара на складе в новой системе, они этим воспользуются. Есть ещё основные средства которые амортизируются годами.
К взаиморасчётам такой подход вовсе не примени. Получается пока должник сам не заплатит, вы не узнаете, что он был вам должен.
А для расчёта зарплаты (отпускных, больничных и т.д.) нужны данные за 2 года. По этой причине к примеру при переходе 1С ЗиУП 2.5 на 3.1 переносится почти всё.
Четыре шага к разработке и внедрению учётного сервиса без переноса остатков