Преминаване към основното съдържание
Поддръжка
Влизане с Microsoft
Влезте или създайте акаунт.
Здравейте,
Изберете друг акаунт.
Имате няколко акаунта
Изберете акаунта, с който искате да влезете.

ВЪВЕДЕНИЕ

В тази статия е описан как различните транзакции влияят върху сумата "Цена на продадените стоки" (COGS) в Microsoft Office "Счетоводител" и Microsoft Office "Счетоводен експрес".

Повече информация

Счетоводният професионален и счетоводен експрес използва метода на разходите "първи ин", "първо напускане" (FIFO). Този метод на разходите предполага, че най-старата стойност на елемент от склада се използва за първи път, когато се продаде артикулът. За повече информация относно метода на разходите за FIFO вж. темата "За оценката на наличностите" Microsoft Office помощ за счетоводството.

Стандартният поток на транзакциите

Помислете за следния сценарий:

  • На 1 януари 2006 г. получавате 3 единици от елемент A. Всеки елемент има цена от 5,00 лв.

  • На 5 януари 2006 г. получавате още 2 единици от елемент A. Всеки елемент има цена от 5,50 лв.

  • На 2 февруари 2006 г. продавате 2 бройки от артикул A. Транзакцията се публикува в акаунта за COGS за 10,00 лв., тъй като системата предполага, че продадените елементи са два от елементите, които сте получили на 1 януари. Всеки от тези елементи има цена от 5,00 лв.

  • На 5 февруари 2006 г. продавате 3 бройки от артикул A. Транзакцията се публикува в акаунта за COGS за 16,00 лв., тъй като системата предполага, че артикулите, които сте продали, включват един от елементите, които сте получили на 1 януари, и два от елементите, които сте получили на 5 януари. Един от тези елементи има цена от 5,00 лв., а два от тези елементи имат цена от 5,50 лв. всеки.

Изключения от стандартния поток на транзакциите

Следващите примери илюстрират конкретни транзакции, които може да повлияят на сумите в акаунта за COGS. Тези примери показват изключения от стандартния поток на транзакциите. Във всеки пример е описан процесът на преизчисляване на акаунта за COGS. Всяка комбинация от тези транзакции може да доведе до сложно изчисление и голяма корекция на акаунта за COGS. За да видите ефекта върху акаунта за COGS в следващите примери, прегледайте отчета "Подробности за транзакцията по акаунт". Използвайте набор от филтри, за да покажете анулираните транзакции.

Пример 1: Продавате артикули, без да получавате артикулите в наличност

Ако продавате артикули, без да получавате артикулите в наличност, се използва продажната цена от записа на елемента, за да се изчисли сумата на COGS. Сумата на COGS от всички предишни транзакции се преизчислява, ако са изпълнени следните условия:

  • Покупната цена се променя.

  • Елементът се продава отново. Обаче не получавате елемента в наличност.

Помислете за следния сценарий:

  • Можете да създадете елемент A. Елемент A има покупна цена от 10,00 лв. Елемент A има количество на ръка 0 и стойност от 0,00 лв.

  • На 1 януари 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 10,00 лв.

  • Отваряте елемент A от списъка с елементи. След това променяте покупната цена от 10,00 лв. на 20,00 лв.

  • На 5 януари 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 30,00 лв.

Тъй като продажната цена в записа на елемента е променена преди получаването на този елемент в наличност, системата преизчислява всички предишни транзакции с помощта на новата покупна цена. Следователно транзакцията от 1 януари 2006 г. сега използва цена от 20,00 лв., а не цена от 10,00 лв. Освен това транзакцията от 5 януари 2006 г. използва и цена от 20,00 лв. Следователно крайният баланс на акаунта за COGS сега трябва да бъде 40,00 лв. Тъй като вече са публикувани 10,00 лв. за транзакцията от 1 януари 2006 г., друга транзакция за 30,00 лв. ще бъде публикувана на 5 януари 2006 г., така че крайният баланс от 40,00 лв. да се показва правилно.

Пример 2: Записвате документ за продажба, преди да запишете документ за покупка

Ако запишете документ за продажба, преди да запишете документ за покупка, продажната цена от записа на елемент се използва, когато документът за продажба бъде записан. Следователно, когато елементът е действително закупен, се прави корекция на акаунта за COGS, ако възникнат някакви разлики в разходите.

Помислете за следния сценарий:

  • Създавате елемент A. Елемент A има покупна цена от 5,00 лв. Елемент A има количество на ръка 0 и стойност от 0,00 лв.

  • На 1 януари 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 5,00 лв.

  • На 1 март 2006 г. получавате 1 единица елемент A, който има цена от 4,50 лв. Транзакцията се публикува в акаунта за COGS за отрицателна сума от 50 лв. на 1 януари 2006 г. Това сега води до точно отразяване на крайния баланс от 4,50 лв.

Пример 3: Анулирате фактури от предишна дата, когато съществуват документи, които имат дата на транзакция, която е по-късна от датата на транзакцията на анулираните фактури

Когато анулирате фактура, елементите в тази фактура се връщат в наличностите. Артикулите се връщат в наличностите на датата, която се използва в анулираната фактура. Когато елементът се върне в наличността, се възстановяват разходите за стоките, които са свързани с тази продажба. Тази цена на стоките ще има най-старата дата. Тази цена на стоките ще се използва първо за всички по-късни продажби. Записите в акаунта за COGS за по-късни продажби на един и същ елемент се преизчисляват, ако са изпълнени следните условия:

  • Продадели сте повече от същия елемент, след като сте създали фактурата.

  • Продадели сте повече от същия елемент, преди да анулирате фактурата.

Следователно разходите за артикулите в анулираната фактура се използват в следващата записана продажба. Всички продажби след датата на анулираната фактура имат нови суми в акаунта за COGS.

Когато анулирате фактура, програмата създава набор от транзакции, за да компенсира първоначалната продажба, така че да може да възникне преизчисляването. Тези транзакции включват следното:

  • Транзакция, която премахва първоначалната цена на стоките.

  • Друга транзакция, която добавя стойността на елементите в анулираната фактура обратно към наличностите.

И двете транзакции имат същата дата като анулираната транзакция. Следователно акаунтът за COGS и наличностите имат правилни крайни баланси след преиздаването. Има обаче голяма едно-часова корекция за преизчисляване на всички по-късни продажби.

Помислете за следния сценарий:

  • Можете да създадете елемент A. Този елемент има количество на ръка 0 и стойност от 0,00 лв.

  • На 1 януари 2006 г. получавате 1 единица елемент A. Този елемент има цена от 5,00 лв.

  • На 1 февруари 2006 г. получавате 1 единица елемент A. Този елемент има цена от 4,50 лв.

  • На 1 март 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 5,00 лв.

  • На 5 март 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 4,50 лв.

  • Анулирате фактурата от 1 март 2006 г.

В този случай, когато анулирате фактурата от 1 март 2006 г., елементът се връща в наличност. На елемента се присвоява първоначалната стойност на стоките, която е използвана на 1 януари 2006 г. Това означава, че фактурата от 5 март 2006 г. всъщност ще има СУМА ОТ 5,00 лв., а не сума от 4,50 лв. Отрицателно количество от 4,50 лв. се публикува в акаунта за COGS на 1 март 2006 г.

Този процес ще засегне всички записани фактури, които съдържат елемент A, тъй като ще бъде публикувана голяма единична корекция. Тази корекция ще използва датата на анулираната фактура.

Пример 4: Създавате транзакция за корекция на наличности

Когато създавате транзакция за корекция на наличности в прозореца Коригирай количеството или в прозореца "Коригирай количеството и стойността", трябва да въведете новата стойност вместо стойността на корекцията, която искате да направите. Разликата между новата стойност, която сте въвели, и стойността на акаунта за COGS на зададената дата се използва за определяне на размера на корекцията на наличностите.

Помислете за следния сценарий:

  • Можете да създадете елемент A. Елемент A има количество на ръка от 10 и стойност от 2000,00 лв. към 1 януари 2006 г. Това означава, че всеки артикул струва 200,00 лв.

  • На 1 февруари 2006 г. продавате 5 бройки от артикул A. Транзакцията се публикува в акаунта за COGS за 1000 лв.

  • На 5 февруари 2006 г. продавате 5 бройки от артикул A. Транзакцията се публикува в акаунта за COGS за 1000 лв.

  • Осъзнавате, че стойността на 1 януари 2006 г. би трябвало да бъде 1500 лв., а не 2000 лв. За да създадете тази корекция, отваряте прозореца "Регулиране на количеството и стойността на наличностите". Задавате датата на 1 януари 2006 г. Въвеждате ново количество от 10 и въвеждате нова стойност от 1500 лв.

В този случай транзакцията се публикува в акаунта за COGS за отрицателна сума от 500,00 лв. на 1 януари 2006 г.

Ако генерирате отчета за оценка на наличностите за елемент A, отчетът съдържа следната информация:

  • На 1 януари 2006 г. първоначалната транзакция, която се показва, е за 2000 лв.

  • На 1 януари 2006 г. се показва транзакция за отрицателно количество от 500,00 лв. Тази транзакция за отрицателна сума отразява разликата между първоначалната стойност от 2000 лв. и новата стойност от 1500 лв. Това променя отделните разходи за артикул от 200 лв. на 150 лв.

  • На 1 февруари 2006 г. се показва транзакция за отрицателно количество от 750,00 лв. Тази транзакция за отрицателна сума отразява 5-те елемента, които са продадени, и които са имали цена от 150,00 лв. всяка.

  • На 5 февруари 2006 г. се показва транзакция за отрицателно количество от 750,00 лв. Тази транзакция за отрицателна сума отразява 5-те елемента, които са продадени, и които са имали цена от 150,00 лв. всяка.

Пример 5: Можете да промените елементите в записан документ

Когато промените елементите в записан документ, ефектът върху сумата на COGS прилича на пример 3. Когато промените елементите в записан документ, цената на всички премахнати елементи се възстановява с помощта на датата на редактирания документ. Сумата на COGS се преизчислява за документи, които са създадени след датата на редактирания документ.



Помислете за следния сценарий:

  • На 1 януари 2006 г. купувате 1 единица елемент A. Този елемент има цена от 5,00 лв.

  • На 5 януари 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 5,00 лв.

  • На 1 февруари 2006 г. купувате 1 единица елемент A. Този елемент има цена от 6,00 лв.

  • На 5 февруари 2006 г. продавате 1 единица елемент A. Транзакцията се публикува в акаунта за COGS за 6,00 лв.

  • Редактирате фактурата от 5 февруари 2006 г. Можете да заместите елемент A с елемент B.



В този случай транзакцията се публикува в акаунта за COGS за 6,00 лв. на 5 януари 2006 г. Тази дата е датата на редактираната фактура. Следователно фактурата, която е създадена на 5 февруари 2006 г., използва цена от 5,00 лв., а не 6,00 лв.

Пример 6: Мерната единица, която сте използвали за закупуване на елемент, се различава от мерната единица, която сте използвали за продажба на елемента.

Понякога, когато закупувате елемент от доставчик, разделяте елемента на по-малки единици, за да го продадете като отделни елементи. За да бъде точна сумата на COGS, ви препоръчваме да използвате една и съща мерна единица, когато закупувате артикулите и когато продавате артикулите.

Помислете за следния сценарий:

  • Можете да създадете елемент A. Този елемент има покупна цена от 10,00 лв., количество на ръка 0 и стойност от 0,00 лв.

  • На 1 януари 2006 г. купувате 5 бройки от артикул A. Този елемент има цена от 10,00 лв. всеки. Можете да добавите бележка в сметката, която показва, че има 5 бушела. Всеки бушел съдържа 20 уши от царевица.

  • На 5 януари 2006 г. продавате 10 бройки от артикул A. Добавяте бележка в полето за описание на фактурата, че тази продажба е за 10 уши от царевица.

В този случай транзакцията се публикува в акаунта за COGS за 100,00 лв. Тази транзакция отразява 10-те елемента, които са продадени и които са имали цена от 10,00 лв. всяка. Тази сума обаче наистина трябва да бъде 5,00 лв. Следователно сумата в акаунта за COGS е надценена с 95,00 лв.

Освен това, ако генерирате отчета за оценка на наличностите, отчетът ще покаже количество наличности от -5 и отрицателна стойност от 50,00 лв. за елемент A. Въпреки това все още има 90 уши от царевица, които да продадете. Ако продължите да продавате елементите на стъпки от 10 уши от царевица, възникват следните проблеми:

  • След като всички уши на царевица се продават, отчетът "Оценка на наличностите" ще покаже количеството на наличностите от -95.

  • Наличностите ще имат отрицателна стойност от 950,00 лв.

Пример 7: Можете да промените акаунта за COGS, който е свързан с елемент

Когато се промени акаунт за COGS, който е свързан с елемент, предишните транзакции не се засягат. Новият акаунт за COGS се използва за всички нови документи, които съдържат този елемент.

Пример 8: Фактура за доставчик се редактира, когато вече съществува фактура за един или повече елементи, включени в сметката


Когато сметката на доставчика бъде редактирана, тя става анулирана и се създава нова сметка. След като редактирането бъде записано, сметката вече не е свързана с елементите във фактурата. Сумата на COGS от всички предишни транзакции след това се преизчислява.

Нуждаете ли се от още помощ?

Искате ли още опции?

Разгледайте ползите от абонамента, прегледайте курсовете за обучение, научете как да защитите устройството си и още.

Общностите ви помагат да задавате и отговаряте на въпроси, да давате обратна връзка и да получавате информация от експерти с богати знания.

Беше ли полезна тази информация?

Доколко сте доволни от качеството на езика?
Какво е повлияло на вашия потребителски опит?
Като натиснете „Подаване“, вашата обратна връзка ще се използва за подобряване на продуктите и услугите на Microsoft. Вашият ИТ администратор ще може да събира тези данни. Декларация за поверителност.

Благодарим ви за обратната връзка!

×