採用先進先出的退貨問題

2021-05-25 06:39:44 字數 4876 閱讀 4048

採用先進先出的退貨問題**)

採用先進先出由於同時有幾處進貨,倉庫管理不完善,出現如下問題:在a**商,b**商處先後進貨,在電腦裡a**商的貨已賣完,還有b**商的貨。而實際中a**商有少量貨需要退。但電腦裡面他已賣完,求教各位大俠,一般是怎麼處理的?急!急!

a**商作銷售退回處理增加庫存,b**商作銷售處理減少庫存

這個問題在使用先進現出演算法時比較常見,可按照二樓馬兄的建議來操作,簡單易行,流程順暢而且不需要對系統進行修改,缺點就是無端多出一些退貨記錄來,不利於以後分析,還造成銷售成本在月份之間的分攤不均衡(跨月退貨)的情況.

先進先出演算法的庫存成本調整比較麻煩,進行批次成本管理對於零售企業來說難度也相當大,但對於電器這一類單品價值比較大,**變動快的產品往往是需要採用先進先出的演算法的,如果你的軟體支援不同產品採用不同成本演算法的話那就最好採取這樣的策略:

1) 量大,價低,**變化不大的產品採用移動平均或加權平均.

2) 對於電器一類,價高,量小,**變化塊的產品採用先進先出.

不過這要看軟體支援的程度和公司財務人員對成本核算的理解程度.否則實施的難度很大

對於這個問題,我在我海博特軟體做了一下,請各位大俠看看我們軟體這樣處理是否合理:

1、設有編號111商品,有a和b**商供貨,庫存計算方式為先進先出

2、先從a**商,進價為15,數量為100,然後再從b**商進貨,進價為14,數量為200。這樣,總進貨額為4300,數量為300

3、商品銷售150個,這樣銷售成本金額為2200(15*100+14*50)。這樣庫存僅餘150個商品,全部為b**商,成本價為14,成本金額為2100。

4、把a**商的商品退掉10個,退貨價為當時的進貨價15。錄進貨退回單,按進貨單退貨。

5、退貨後,庫存成本金額為140個b**商商品,進價為14。銷售成本金額發生變化,調整金額為10,即2190。為什麼是2190呢?(看這個公式15*90+14*60,因為實際上a**商只有90個商品銷售,b**商實際為60個)

至此問題,已經全部解決。很簡單吧。我們軟體在庫存核算方面是很細緻的。每乙個商品都可以選擇按什麼核算方式進行成本核算。若是商品111設定為移動加權平均,則退貨後成本又不一樣了。在此我就不闡述了。

把退貨與進貨分開,進貨作為進憑證,計算存貨的單位成本,增加庫存數量和金額;退貨作為出憑證,根據退貨當時的成本計算庫存的減少和毛利的變化,而不改變存貨的單位成本。退貨的**由業務控制。

你的批次定義有問題,在批次中同一種商品不管在幾家

**貨商處進貨,它的匹次都是根據,收的批次來的,

而銷售中應該是倒算的,再說我認為你的庫存不應該根據**商來,

即使象你上面說的仍然可以退給a,因為你在它那有進貨,而在批此中你系統現示售完,這是因為你退貨不及時,

辦法:退給b,做庫存調

本人所在的公司用的也是批次先進先出法。按照你的描述來看,是**商庫存帳和實物不符,我不明白你們是怎樣在實物上區分哪個商品是哪個**商的?

解決的方法是要實現**商庫存轉換功能,包括庫存、應付賬款的轉移

在批次管理的軟體中,這種問題算是比較常見的問題了,除非乙個商品只有乙個**商。本人覺得解決方法可以有2個:

1,按照二樓的說法,做**商a的銷售紅衝,然後銷售扣減**商b的庫存,這樣**商a的庫存就有了,可以退貨。

2,既然是批次管理,那麼可以通過損益對**商a的商品報益,對**商b的商品做報損,這樣商品的庫存沒有變化。但也可以對**商a退貨了,這種辦法,要看財務對損益的限制程度了。

有一些人可能沒有讀懂我發的帖子,說我們沒有解決問題。現在我總結了一下,大部分人認為是要首先把a**商做銷售退回,增加a**商庫存,b**商做銷售銷售處理,減少b庫存,這一切調整完後才可以做a**商退貨,這樣做當然是正確的,但是這需要額外記錄許多不必要的調整單。

我請各位再看看我上面舉的例子,我們軟體的優越之處就是,系統能自動調整**商庫存,可以直接對a**商退貨,而不需要手工錄入前面的一系列調整單。

還有人認為退貨不需要跟成本掛鉤,這才是大錯特錯。退貨肯定有退貨價,退完後自然會造成庫存成本額減少。若退貨單價不等於庫存成本價,退貨後庫存成本價自然會發生變化。這跟進貨時各個批次進貨價不同,會造成庫存加權成本價變化是乙個道理。軟體會自動調整成本,這也是我們軟體另乙個優越之處。

樓上兄弟的做法很好啊。

當然系統必須是自動處理的,a、b**商的銷售調整、庫存調整全部是自動進行的。這樣在批次管理、先進先出的系統上,應該是沒有問題的。其實在負庫存等問題上,處理的辦法也一樣。例如出現了負庫存,但是後來進貨更改了**商(單據輸入滯後),那麼也只有先將負庫存的**商退銷售、調整為0,然後將銷售調整到b**商上。關鍵問題是真要系統自動處理才好。

至於退貨**的問題,如果退貨**不等於進價,只好將這部分差價作為其他損溢單列,讓財務自己給掛到乙個科目上了。

如果討論的是一般的超市,你的方法有兩個問題:

1、調整銷售成本。如果跨月退貨,月結後你如何再調整銷售成本?

要是退貨發生在3個月以後,你如何調整前3個月的銷售成本。

很多商品每個月有10個批次的進貨,你的退貨可能包括了很多批次,而且你根本不可能追溯到所退商品屬於哪一批。

即使不同批次均使用不同的物流碼,但物流碼是用在包裝上的,而退貨的商品大多是拆零的。

每個月,一般超市的退貨同時發生1000種商品以上,每種商品的進銷存資料都需要調整嗎?

不要以核算的越細緻越好,考慮到實際情況,要簡單易用才好。

2、退貨後的庫存成本平均會出問題。在超市進銷存的實際過程中,就是單**商,進價也是會經常變動的,

舉實際例子:

假設某商品當前的平均進價:10元。庫存數量:100。庫存成本:1000元。而之前很可能有過8元,12元等不同的進價。

現進行退貨,在退貨過程中,退貨的單價還是會有乙個討價還價的過程,不一定能知道這批貨的當時的實際成本。

如退貨單價:8元,退貨數量:60,退貨金額:480。

庫存成本:=1000-480=520元,庫存數量:=100-60=40個

平均進價:=庫存成本/庫存數量=520/40=13元,這時很可能已經是倒毛利了。

再如果如退貨單價:9元,退貨數量:99, 退貨金額:891。

庫存成本:=1000-891=109元,庫存數量:=100-99=1個

平均進價:=庫存成本/庫存數量=109/1=109元。

曾經有大型連鎖超市公司在應用最有名的it企業的系統(解決方案)時,在電腦系統實際中單價常常出現天文數字,倒毛利比比皆是。

有庫存金額沒有庫存數量,有庫存數量卻有負的庫存金額,

在用加權平均(或移動平均)處理退貨時,這些情況會頻頻出項。

我認為到目前位置,處理退貨最好的也是最簡單的方法就是把退貨當成出憑證。

用銷售的方式計算庫存的成本。將退貨金額同退貨成本間的差額,作為了退貨毛利。

這樣沒有庫存調整和銷售調整,也不影響核算和結算。

此問題在於前期批次庫存的不準確造成的.

對於一品多**商的處理,建議保持乙個**商的商品庫存,若因為種種原因而進另一**商的商品,則要將上一**商的商品庫存退成零,然後再做入庫.

雖然這樣做有點麻煩,但可以保持資料的準確.

強調:::::有些軟體好稱能處理好一品多**商的問題,但千萬不要相信他們的處理能力,即使做的不錯,也會在某些流程上造成資料的不準確.

仔細看了周兄的解決方案,如果光從例子上來看是可以的,不過很納悶的是你們如何處理先進先出的呢? 要先進先出你就必須記錄每一次進貨的批次(這個批次和業務管理中的批次不同,對於使用者也不可見,但必須在系統中記錄,一控制發貨的順序) 包括序號,商品編碼,進貨數量,進貨**,另外還必須有乙個當前數量,然後在每一次出貨時找出沒有發完貨的(當前數量大於零)然後按時間順序進行倒排,這樣才能實現先進現出, 如果系統是這樣設計的就必然要求在所有進退貨過程中跟蹤到批次才行(這個跟蹤過程對使用者是透明的),而周兄的這個方案好象在退貨過程中並沒有跟蹤到. 周兄可否解釋一下你們先進先出的實現機制,對於你們的實現方法我很納悶.

另外扯遠一點, 說說為什麼在業務系統中會扯上成本核算, 從資訊系統層次來看,我覺得有三個層次的系統(1) 解決數量問題的系統

(2) 解決數量,金額問題的系統.(3) 數量,金額,會計整合系統

第乙個層次的系統是不管商品成本的,只管數量,因此在業務處理中可以不考慮那麼多因素,只要把數量搞平就可以了,現在很多的商場管理系統還處於這個層次,只要看看他們發現庫存不對時不分清紅皂白就使用損溢單來調整庫存就知道了.

第二個層次的系統是需要管理商品成本的,也就是能出數量,金額式報表的系統, 雖然只多了乙個金額,其實系統複雜了很多, 首先必須選擇庫存成本的核算方法, 而對於同一種業務,每一種核算方法又可能使用不同的處理流程,而這些流程又必須反應到系統中,因此系統的複雜程度可以說成倍的提高,有人可能會說,庫存金額不就是數量*進貨價嗎?其實他還完全沒有弄懂庫存成本是什麼? 這樣說還差不多,庫存成本金額=數量*演算法加工後的單價,至於演算法有那些,對於業務有什麼影響,大家還是找會計書看吧,有幾大章講呢!目前國內很多erp也只到這個層次而已.

第三個層次應當是比較理想的,也就是整整實現業務,財務的一體化管理, 財務的資訊完全是通過業務來實現的, 這是什麼意思呢? 這就是說業務的任何一項有關資金流的動作都必須反映到財務, 比如: 採購進貨 反應到財務就是一張:

借: 庫存商品

貸: 應付帳款

的憑證,這張憑證可以是自動反應到總帳的,也可以是人工確認到總帳的,國外的erp系統多採用前者, 國內的做到這一層次的還不多,做到的也一般採用後者, (沒辦法這是國情,企業有太多的"例外"需要調整,國外的模式到國內來絕大部分是使用不起來的).

這個層次系統的難點在於,每乙個和資金流相關的業務步驟都必須和財務處理相對應, 而且帳務處理是需要原始憑證的,你不能憑空調整乙個資料: 例如當發現退貨**和進貨**不等時就不能簡單的去直接調整庫存成本, 還必須記錄二者的差異,只有這樣資料反映到會計系統時,系統才能將這個差異掛到某個費用科目下.

企業資訊化管理追求的是業務順暢,流程清晰, 真正實現:資訊流, 物流與資金流三者的統一:資訊流控制物流,物流反應資金流.

物流,資金流又影響決策從而影響資訊流, 這是資訊化的基本要求,也是現在很多企業的追求, 不過看了大家的貼子發現即使很多專業人員對此認識也不是特別清楚.

佇列 先進先出

看前面的是什麼型別 指標 普通 出現指標指向空報錯的情況下,傳參不能為空,可以傳個空間的位址給他 queue front next null 從尾進 先進先出 define crt secure no warnings pragma once include include include incl...

智慧型出庫,先進先出

3分鐘左右 t erp location 庫存表 4000行 如果是40000呢 code time location number 2000 20180101 a1 1 10 2000 20170102 b1 1 20 2000 20180103 c1 1 5 2000 20180101 d1 1...

佇列實現先進先出

1 入隊,如例 q.push x 將x 接到佇列的末端。2 出隊,如例 q.pop 彈出佇列的第乙個元素,注意,並不會返回被彈出元素的值。3 訪問隊首元素,如例 q.front 即最早被壓入佇列的元素。4 訪問隊尾元素,如例 q.back 即最後被壓入佇列的元素。5 判斷佇列空,如例 q.empty...