Конф.
http://prntscr.com/plsmdy

Помогите понять.

На данный момент продаем товары и так же даем в долг.
Заводим реализацию в тот день когда покупатель взял товар. Оставляем ее как неоплаченный.
А в тот день когда покупатель приносит деньги.

Делаем приходный кассовый ордер и реализацию перепроводим на тот день когда пришли деньги.

Как бы все работает но при таком изменении дат реализаций выходит что при списании товара происходит ошибки.

Выходит так что товар весь продали а по деньгам товар не выходит в 0 ... Некоторые + пару центов  некоторые в - пару центов, бывает на большом промежутке времени и нару долларов.

Как я понял что это из за того что товар считаем по среднему.


Поможет ли мне если перейду на ФИФО

(0) "и реализацию перепроводим на тот день когда пришли деньги."
- нафейхоа? что мешает реализацию и оплату оставлять в разных днях?

(0) "что при списании товара происходит ошибки."
фраза ни о чем.
какая ошибка? конкретно? в чем проявляется?

не трогай реализацию

и ошибки скорее всего уберет перепровеление

при вашем подходе переход на фифо только ухудшит ситуацию. следует оставаться на средней.

(0) "Выходит так что товар весь продали а по деньгам товар не выходит в 0"
- это что за поток сознания?
.
продали весь товар. остаток по товару=0.
про какие деньги идет речь? про себестоимость товара, может?

навскидку, при работе по среднему (то есть большой кучей) - все должно быть норм. причина может быть в кривом алгоритме.
имхо.
ибо.
рассмотри крайний вариант.
все идет как у вас и идет.
в один прекрасный момент у вас остается 10 шт и себестоимость 100 рублей.
продали эти 100штук с оплатой.
по остаткам=0, по себестоимости=0.
теперь, вы распроводите какую-то заднюю реализацию. у вас на остатках появляется 23шт на себестоимость 1345.77.
вы сдвигаете реализацию и проводите ее. все списывается в ноль.
как-то так я себе представляю.

возможно что проблемы в тогм, что вы списываете штуки не суммой, а ценой.
на остатке у вас 3 шт, на 100 рублей.
выначинаете при продаже списывать по цене - по 33.33руб.
и последнюю штуку списываете точно так же, в итоге 1 коп повисла без количества.

при списании с баланса ВСЕГО ОСТАТКА, следует списывать ВСЮ СУММУ., в данном случае на остатке 1шт, на сумму 33.34. и списываете по сумме.

Интересно, а как связаны себестоимость и оплата?

(6..8) а еще бывает прайс вуе, а реализация невуе

(9) офф: ну, на нэньке свой путь...

(10) и чо?

(11) А шо, на Нэньке в доллярах ужо торгуют?

Не трогать реал. не выходит в реал. заносим все в $ а деньги получаем в гривне по курсу того дня когда пришел покупатель рассчитываться.

После таких манипуляций с датой реализации появляются товары с кол. 0 а ценой не 0.
все решает простое перепроведение

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

(15) описал выше - кривой алгоритм.

(15) и какие нахрен "товары с ценой" в регистрах?
в регитсре учета ведете учет по количеству и по цене или по количеству и сумме? или по количетсу, цене и сумме? - тоже все выше описано.

(18) Количество    Стоимость

По партиям товаров на складах

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

(19) ты ему валюту регламентированного учета скажи лучше и после Стоимость валюту укажи

(20) при чем здесь партии товаров на складах?
если у вас в партиях товаров на складах - учет по среднему - у вас там одна партия "пустая".
описано выше.

проблема решается в полпинка обычно
разворачивается по всем измерениям ведомость движения по количеству и сумме. и смотришь когда колво=0 а стоимость не равно нулю. находишь _последний_ документ распроводишь. проводишь заново. ушла проблема или нет? дальше танцуешь отсюда.

сейчас чуть сильнее еще подумаю

ага, подумал.. мне понравилось.. решил подумать еще раз.

ситуация в (0) потенциально может вылезти если переносимая реализация ставитьс не на сейчас, а задним числом.

и есть далее лежащие списания товара после этой накладной.

в рамках типовой - без исправления кода не лечится (имхо). только перепроведением. или проведением переносимой накладной ВСЕГДА ТОЛЬКО В СЕЙЧАС. или подвисание копеек не связано с описанной ситуацией автором, а вылазит из-за других действий (исправления задним числом)

переход на фифо в этом случае крайне вреден. ситуация только ухудшится.
лечить можно и без полного перепроведения, но потребуется обработочку накропать
1. кропаем обработку.
2. вычисляем все товары, по которым по количеству баланс=0, по сумме - не ноль.
3. для каждого такого товара определяем последний документ-расход, который выводит количество в ноль.
4. перепроводим этот документ. ситуация должна стать нормальной.

(24) Да все именно так за 3 года работы больше 1000 товаров были с такой ошибкой все перепровел все стало ровно.

Но вот на прошлой неделе пришел должник оплатил долг 1000$ перепровел  реализации на тот день когда он принес деньги и снова в некоторых товарах пошли расхождения с стоимостью.


Как исправлять данные ошибки я понял.  

Вопрос в том как их избежать. Может есть какая нибудь другая система заводить должников.

(31) "реализации на тот день когда он принес деньги " - ну, деньги же он принес не вчера? вчера - не существует. деньги он приносит всегда СЕГОДНЯ. а вот то что вы СЕГОДНЯ не делаете операцию описанную в (0) - проблема вот в этом.

(0) Гуглить курсовые разницы
https://wiseadvice-it.ru/o-kompanii/blog/articles/kursovye-raznicy-v-1s-8-3-kak-otrazit-v-uchete/

Как это у вас хз, читайте бух и налоговый учет.

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

Предполагается что работы будущим числом в базе нет.

(33)+ Изменять дату документа реализации и перепроводить на дату получения оплаты не надо.

(32) Делается на Сегодня.
Сегодня привес деньги и на сегодня перевел реализации.

(35) По курсу ж не будет совпадать. курс скачет

(33) курсовые разницы - относятся к взаиморасчетам. и никак к себестоимости товара (который тоже может конечно переоценяться из валюты по курсу в гривны но к сабжу отношения не имеет)

(36) "сегодня" - это значит что документ всегда если проводится значит проводится ПОСЛЕДНИМ. сегодня тоже можно задним числом делать если под сегодня понимается ДЕНЬ. у меня под сегодня понимается момент времени. он - единственный.

(35) см.(36) они работу с курсовыми не потянут. тупые.

(36) "Сегодня привес деньги и на сегодня перевел реализации."
я сказал как лечится - найдипоследний документ расхода по проблемному товару. и просто перепроведи его там где он есть. ситуация должна исправиться. и доложи - так это или нет.
если ак - проблема снята.
если не так - будем смотреть дальше (ошибка в алгоритме)

(40) да при этом проблема исправляется

(41) значит, проблема не в переносах.
проблема в испралениях или введениях документов задним числом.
лечится либо перепроведением документов или в (30).
.
перепроведение может быть ресурсозатратным.
если ресурс ограничен - тогда (30) - это будет намного быстрее, но менее "точно". эта точность влияет только на определение прибыльности документа.
.
в раках учета по среднему и в отсутсвии значительных колебаний курса и в той парадигме работы что у вас - это вообще не имеет значения.

кстати, после выполнения (30) над обязательно повторно см.п.2

(43) А может, дешевле штатно последовательность восстанавливать?

(44) зависит от бадачности работы. если исправлений задним числом мало - то прокатит (30), иначе - может и штатно ГП восстановить лучше будет

(36)[ По курсу ж не будет совпадать. курс скачет]
дык договор должен быть в $ и в них же взаиморасчеты, документы отражаются датой отгрузки и платежа