Divide by Zero Error

V5 Issue
1

Hi,

We have seen the error “Attempted to divide by zero.” when trying to end a work period a couple of times in the past few months.

It seems to occur when a staff member puts in a negative item on a ticket (see attached ticket screenshot). Most likely if an item ends up being ‘0’ total quantity is the true cause but I haven’t been able to confirm this.

Ignoring why staff are doing this in the first place this does seem to be a bug that’s reoccurring. To fix it I have to go into the database and manually delete the offending orders.

Log:
20/03/2020 6:20 PM

[General Info]

Application: SambaPOS
Version: 5.2.26
Region: en
DB: SQ
Machine: xxx
User: xxx
Date: 20/03/2020
Time: 10:20 AM

User Explanation:

simon said “”

[Exception Info 1]

Top-level Exception
Type: System.DivideByZeroException
Message: Attempted to divide by zero.
Source: mscorlib
Stack Trace: at System.Decimal.FCallDivide(Decimal& d1, Decimal& d2)
at System.Decimal.op_Division(Decimal d1, Decimal d2)
at Samba.Services.Implementations.InventoryModule.ConsumptionBuilder.UpdateConsumption(PeriodicConsumption pc, Int32 warehouseId, IEnumerable1 tickets, IList1 recipes) in C:\Users\vehbi\Source\Repos\sambapos-v5-pro\Samba.Services\Implementations\InventoryModule\ConsumptionBuilder.cs:line 149
at Samba.Services.Implementations.InventoryModule.ConsumptionBuilder.BuildPeriodicConsumption() in C:\Users\vehbi\Source\Repos\sambapos-v5-pro\Samba.Services\Implementations\InventoryModule\ConsumptionBuilder.cs:line 68
at Samba.Services.Implementations.InventoryModule.InventoryService.DoWorkPeriodEnd(WorkPeriod currentWorkPeriod, WorkPeriod previousWorkPeriod) in C:\Users\vehbi\Source\Repos\sambapos-v5-pro\Samba.Services\Implementations\InventoryModule\InventoryService.cs:line 191
at Samba.Services.Implementations.InventoryModule.InventoryWorkperiodProcessor.ProcessWorkPeriodEnd(WorkPeriod currentWorkPeriod, WorkPeriod previousWorkperiod) in C:\Users\vehbi\Source\Repos\sambapos-v5-pro\Samba.Services\Implementations\InventoryModule\InventoryWorkperiodProcessor.cs:line 25
at Samba.Presentation.Services.Implementations.WorkPeriodModule.WorkperiodClient.StopWorkPeriod(String description)

[Assembly Info]

mscorlib, Version=4.0.0.0
PresentationFramework, Version=4.0.0.0
PresentationCore, Version=4.0.0.0
System, Version=4.0.0.0
WindowsBase, Version=4.0.0.0
Samba.Services, Version=1.0.0.0
System.ComponentModel.Composition, Version=4.0.0.0
System.Configuration, Version=4.0.0.0
DevExpress.Xpf.Core.v16.2, Version=16.2.13.0
System.Xaml, Version=4.0.0.0
Microsoft.Practices.Prism.MefExtensions, Version=4.0.0.0
Samba.Presentation.Services, Version=1.0.0.0
Samba.Presentation.Common, Version=1.0.0.0
Samba.Domain, Version=1.0.0.0
Microsoft.Practices.Prism, Version=4.0.0.0
System.Core, Version=4.0.0.0
Samba.Infrastructure, Version=1.0.0.0
DevExpress.Data.v16.2, Version=16.2.13.0
Microsoft.Practices.ServiceLocation, Version=1.0.0.0
Samba.Localization, Version=1.0.0.0
Samba.Persistance, Version=1.0.0.0
FastButton, Version=1.0.0.0

[System Info]

Operating System
-Microsoft Windows 10 Pro
–CodeSet = 1252
–CSDVersion =
–CurrentTimeZone = 480
–FreePhysicalMemory = 8071240
–OSArchitecture = 64-bit
–OSLanguage = 2057
–ServicePackMajorVersion = 0
–ServicePackMinorVersion = 0
–Version = 10.0.18362

** Machine info removed, happens on any terminal **

######################### E N D #########################

error
error3840×2160 161 KB

ticket
ticket3840×2160 354 KB

2

This not an issue but a mistake by either automation or staff.

As a programmer you learn that you should NEVER EVER have calculations that are divided by 0.

You must have made this division and saved it in a ticket one way or another, you will have to find it and delete it. Follow up on where and why is this happening and remove it from the automation or ticket/order options.

1 Like
3

Thanks for the reply but this isn’t very helpful and it is pretty condescending really.

There is nothing in the automation code that is dividing by zero. It only happens when ending the work period and it is occuring in SambaPOS code.

I believe it is because there is a +1 and a -1 of the same product on the ticket but I can’t confirm this without help from an actual SambaPOS developer.

4

+1 -1 pretty sure wouldn’t be it.
I use -1 for my refund and not had this issue.

Divide by 0 is typically going to be a calculation or tax issue or posibly other automation where your using a math type calculation.

The issue is sambas flexibility allows for such custom flows it’s hard to just make blind sugestions.

Saying that, looking closer at you pasted log it looks to be inventory related in your case.
I am not very familier with inventory system to be able to offer quick advice, but I would start by checking inventory config and recipes.
Since that’s the case I retract the -1 rule out as dont have inventory configured on my main system which uses -qty refund.

5

Thanks for that. I have also used -1 in the past for refunds so I wasn’t completely sure. I do know that removing those two orders from this specific ticket fixes the problem.

We haven’t actually used SambaPOS inventory tracking for years but there are a few old recipes in there from when we did and there is one related to the “Kolsch” on this ticket so that may well be it.

I’ll go through and remove inventory stuff that we’re not using. As far as I can remember there’s nothing custom in there but it would have originally been done on a much older version of SambaPOS.

Strange though that the inventory settings wouldn’t have been touched in at least 4 years but we’ve only had this problem in the past month or two (and only twice).

Anyway, thanks for your help. Will see how we go.

6

I had no intention in being condescending…

I can also see from your screenshot that your submitted orders have a status New, even when the ticket is Paid your orders have a wrong status.

Wrong default states can cause many issues, maybe thats something you should look into too?

7 
  1 Mixed Carton
 -1 Mixed Carton
 ----------------------
  0 Mixed Carton

It could be that a inventory calculation could take the 0 and cause the error. Maybe calculating cost?

8

Thanks. It does look like there’s something strange with states there. I believe it might be to do with whatever staff did to try and fix the problem on the day but I’ll take another look.

9

I agree that this looks like where the problem is coming from.

We don’t have any custom code on our end that’s doing calculations based off this though which if why I’m worried it may be a bug inside SambaPOS itself.

I’ll be removing all the inventory tracking configuration that we’re not using and that will probably stop this happening to us again but if possible I’d like to somehow locate the source of the problem. If it’s something specific to our configuration that’s fine no big deal but if it’s a SambaPOS issue I’d like to help provide whatever details are needed to get it fixed.

10

I have client where they have inventory count in minus of tens of thousands because they have stopped using it, so your stock going into (-) shouldn’t be an issue.

1 - 1 = 0 or 0 - 1 = -1 is not dividing by 0.

I can imagine wrong state in a ticket could cause a ‘null’ order though.