Ok I think I might see what your getting at now. Your using Preorder tickets?
I understand now whats going on. I should have read the entire post first. Maybe we should discuss how to implement a Lay-Away system?
Walmart used to have the largest most complex Lay-Away known to man so I am fairly comfortable with a process that works very well as far as accounts, etc goes. Bottom line is I think you should create a separate logging system for payments strictly for tracking… it should not affect accounting other than a specific account that holds payments.
Yes new work period each day.
Staff manager prints off work period report. Deposits all cash to bank. I automatically get e-mailed work period report. Check that days, total payments taken and make sure my bank account matches up.
In summary I’ve suggested adding Preorder = False filter for payment reports so they won’t appear on work period reports until ticket becomes a real ticket. They can be reported separately under a separate WPR table with Preorder = True. While converting ticket to a real ticket we have a chance to change ticket date to today’s date so payments will appear fine in today’s work period report (with original dates they’ve settled).
Yes he should not be reporting it in a Work Period other than maybe a specific flow to show payment logs and maybe a specific account created to hold those payments. Let me think about it a while and I might suggest a route to take.
Are we dealing with food preorders or is this something else? It makes a difference.
Creating a different payment type like Deposit Payments for such payments is also possible but it might not be needed as they’re already tied to a pre-order ticket so we can report them separately.
Sorry yes a retail environment. I understand Samba was not developed for this but I’m after having good success setting it up to suit my requirements. When I was testing the setup it was always in the one work period so I never noticed a discrepency. A couple of days ago I noticed one Layaway still open and settled it, had a quick glance at the reports and that’s when I noticed this.
Heres a copy of what I have done. Layaway.zip (1.4 KB)
@silentbob you should always reference Accounting and related reports for tracking Cash & Bank transactions. Work period report designed to report daily operations.
For example if you give $50 from Cash to your children it won’t appear in work period report. You should prepare your own cash report designed for your account plan. I’ve linked a sample cash report on my previous post.
Yes do not get the two confused. If your depositing to bank etc you should use Accounting for that or create specific reports that helps you with that process. Work Period report is different and also it was designed around food business so likely you need to rework it entirely.
I will share with you some ideas on how to create a retail Lay-Away system. You will need to do some research and design it but I can help guide you with ideas.
In fact thinking about it the default work period report is horrible for retail. You really should study up on reports and build custom reports that align more with retail For example in retail we dont really use Work Period reports for daily operations at all we look at them maybe weekly etc but typically we just track accounts and we balance drawers.
Sorry for multiple posts but I wanted to separate this discussion. What you need is a retail oriented Lay-Away system with its own accounting and reporting system. You will need to incorporate a way to reconcile that accounting into regular store accounts when Lay-Away accounts are paid in full. We also need to design specific reports for your needs.
SambaPOS5 can handle retail MUCH better than any previous version. In fact I know its not meant for it but its actually probably the best for retail atm. The downside is we will need to virtually custom setup almost every aspect to make it retail friendly so you should really start doing some homework.
If given the time Emre could convert SambaPOS 5 to retail default install without changing much actual code at all, probably none. I am not suggesting he do that I am simply sharing that we have potential here.
For now you can slowly start changing it over to more retail friendly. Dont try to do it all at once but first thing we need to do is discuss a flow you want for Lay-Away. It should include its own accounting and reporting process.
Some suggestions are using Entities and Entity Accounts as Lay-Away accounts. We should link specific tickets to the accounts and probably use specific fields to designate multiple lay aways per entity. We should probably use Pre-Order tickets for Lay-Away and only convert to real ticket once its paid out in full.
Bottom line is to get a true retail Lay-Away setup its going to involve some fairly advanced custom work. You can piece something together but dont expect it to work properly unless its setup properly from beginning. SambaPOS works fine for retail but to get a true retail system you have to be willing to extensively customize it.
You can piece it together and use the food setup similar to retail but dont expect it to operate exactly how you want. The only way to get it to operate exactly like retail is to customize it for retail so it involves lots of time and thinking to redo accounting etc.
Default setup of accounting and reports is for restaurant and its really not good enough for retail. You need to customize it.
Even If I modify/create new accounts. Am I still not going to have the issue of the payment transaction passing the Ticket date to the accounts instead of the Payment date.
@emre Is it possible to modify the Payment transaction to pass the Payment date to the accounts??
It seems like you implemented what I’m looking for here but decided against it.
Is it possilble to add maybe a check box to enable/disable this modification?
No we would need to create a custom solution so it works correctly how you want. It would need custom accounting and you would need to use specific document types for account transactions that would show payment dates etc using the descriptions fields
I have tried as you suggested Ticket date change. Payments still show up under the original date in accounts. but that’s not really too important.
Basically when I update the ticket date it is not showing in the work period because the time defaults to 00:00.
I have tried {date}{time} in the action parameter but it gives an error and samba closes.
Is it even possible to update the ticket time using the Update ticket date action?
What I plan to do is update the ticket date at every transaction.
Then filter out the payments that were not made on that date so they do not show in the Work Period Report.
I tried this but its not working.
{REPORT PAYMENT DETAILS:P.Name,P.Date,P.Time,P.Amount.Sum:(TY=$1) and P.Date == T.Date}}
I understand that If i recall an old report it will be incorrect, but these will be emailed to me when work period ends and also printed every day so there shouldn’t be an issue.
silentbob report tags are useful to create reports without dealing with SQL but you are not limited to report tags. Instead of trying to match it to what reporting tag offers you can use SQL to prepare your reports as exactly you want. I’ve prepared an example about how to filter payments by payment date instead of ticket date.
Create a new script. You can access that script inside reports via @@Payments handler.
Select Payments.Name as PaymentName,
Payments.Date as PaymentDate,
Tickets.Date as TicketDate,
Tickets.TicketNumber as TicketNumer,
PaymentTypes.Name as PaymentTypeName,
Amount,
TenderedAmount,
Users.Name as UserName from Payments
inner join Tickets on Payments.TicketId = Tickets.Id
inner join PaymentTypes on Payments.PaymentTypeId = PaymentTypes.Id
inner join Users on Payments.UserId = Users.Id
where Payments.Date > '{Start}' and Payments.Date < '{End}'
Create a new report as follows or you can include it as a report section in WPR.
[Payments:1,1,1,1,1,1,1,1]
>Payment|Date|Ticket Date|Ticket Number|Type|Amount|Tendered Amount|User Name
@@Payments
What I’ve tried to explain to you is how you want SambaPOS to operate may lead to issues. If you know exactly what you need you can implement your own way.
SELECT Payments.Name,SUM(TenderedAmount) AS TenderedAmount FROM Payments
INNER JOIN PaymentTypes
ON Payments.PaymentTypeId = PaymentTypes.Id
where Payments.Date > '{Start}' and Payments.Date < '{End}'
GROUP BY Payments.Name;
