The vendor bill sequence is reset every month. For example, BILL/YEAR/MONTH/xxxx (BILL/2022/01/0001). The next month would reset the sequence BILL/2022/02/0001.
However, the sequence of invoice is reset yearly, INV/2021/0001, INV/2021/0002, ... ,INV/2022/0001
So I want the invoice sequence to have the same format as vendor bill. I tried to go to Technical -> Sequence, but got no clue. I expect there would be a sequence that have prefix BILL and prefix INV but I dont see anything like that.
I see a 'Resequence' server action on the invoice, somehow it works, but I want something more flexible, the 'Resequence' I feel like you are hoping the AI figure out the pattern
Related
I am very new to E-Commerce World.
I have a use case scenario that I want to Implement in Oracle NetSuite.
But I am not sure how to move forward with it.
Use-Case Scenario:
A Sales Order has a few Line Items & Among them, a few are out of stock.
The 3PL currently I am dealing with accepts only one Unique Sales Order ID as an Identifier.
I want to fulfill the items that are currently in stock and Later on, when the Inventory gets updated I want to fulfill the remaining Items back-ordered in the Sales Order.
But the fulfillment should happen only after the customer has paid for the Items.
Can anyone let me know? How can I achieve this?
Thank you.
You will probably need some customisation to achieve this. I don't know the full set of processes you're working with, but as a general approach, I would suggest the following:
Set up a payment term that says the customer must prepay.
Set up a script to run on your fulfilments, handle "prepay" customers.
You'll also want to check your settings in Setup > Accounting > Accounting Preferences > Order Management. Look for the option on sales orders and fulfilment. You'll probably want to default your fulfilment to available quantity only. You may want to prevent overage on your fulfilments.
When the script executes on your fulfilment, it should execute "before load". The script will need to check the sales order it's fulfilling. If the term is "prepay", the script should then check if a payment has been made against the sales order. You'll potentially need to consider deposits and paid invoices. If the script finds no payments, then it should block the fulfilment.
I'm working on the assumption that you will create a fulfilment with a "Picked" status to send to your warehouse. When they confirm the "goods-out", you will want some sort of feedback loop from your 3PL to set the fulfilment to "Shipped" and update your tracking numbers.
I hope this helps.
Mark
I have a table named minibar_bill and i use it for keeping evidence of client's expenditure. I'm trying to build a hotel/pension system management.
I thought that i could make a table
Minibar_bill with (id_bill, id_minibar_product, id_client)
And i would like to add those info on an invoice based on bill_id...
How should i do it ?
I mean i want to have something like that:
Id_bill(1)
id_minibar_product(1,2,3)
id_client(123)
So first 3 records will be :
1, 1, 123
1, 2, 123
1, 3, 123
And i want the id_bill to be on invoice ... maybe i could switch id_product with id_bill
Where id_bill(1) - would be the first bill record in database
id_minibar_product(1,2,3) - would be product 1,2,3 which has been consumed by client
id_client(123) - client id which we use on invoice to collect data from Client table in order to print them on invoice( i will use C# for UI ).
What I have tried:
I've tried to make a db with field id_bill and id_product but i think it's a wrong approach since i made them a composed primary key and i cannot add them to foreign key in Invoice table.
Here are some suggestions for your design:
It's a good idea to name things descriptively, but if you create a table called Minibar_bill, that's going to be inconsistent and short sighted if you want to start charging in-room movies and in-room dining, services etc. to the room. I suggest you call it something more generic - remove Minibar from all of your table names.
You must never put comma separated values into a single field.
There are a million sales data models online, including, as already suggested, templates in MS Access. There's no point reinventing the wheel
I suggest you have something like this
Client A list of clients
Products A list of products you can be billed for (not just minibar)
Bill A client has zero or more bills (usually one)
BillLine A bill has zero ore more lines. Each line represents
One product being charged for on a bll
So Bill is the header. It's up to you whether you add a column indicating when / if it is invoiced, paid etc., or whether you want to create a seperate invoicing module.
With regards to this comment:
What i wish for is to link Invoice to minibar_bill in order to have the status on a single Invoice of all products from minibar which have been bought by a customer.
If you have a seperate invoice table you can write the BillID to it to link it.
I'm not sure if you understand that all this info exists across different tables, and when, for example, you print an invoice, you go and collect all the info from across the tables at that time.
i want to do a autoshop software... where they keep up the cars they have and what they need(engine and other parts for example) but i dont know how to do the database to accept multiple items at once
example:
a car needs on one visit to the auto shop:
left frontal door
tires
oil change
filters
how to i add this in one go to the database(with prices included) so that i can see it all after and print a bill wheer it shows all... but my main priority is being able to insert all in one go and in one table
Hard to tell without any idea about your db strucutre. Lets assume db isn't constructed yet, you don't want to decrease parts stock or keep any track of wich exact part (i mean with serial etc.) was used. You want it quite simple, just a table with a car bought some parts.
In this case i woulde use a table looking like this : id|date|car_id|parts_used
where parts_used is a string containing parts and prices with separators. For example : "left frontal door=500+tires=100+oil=10" and then split the string when reading db.
I'm not sure it's what you want but your question isn't quite precise :)
I have a 2 access 2007 tables with the following fields:
Table 1: Loan Release Table
ReleaseDate as Date
Maturity as Date
MemberName as Text
MemberNo as Text
Term (in months) as Number
Mode (M/Q/Semi-Monthly) as Text
LoanType as Text
LoanAmount as Currency
LoanCode as Text
Table 2: Payments Table
ReceiptNo as Text
DatePaid as Date
MemberName as Text
MemberNo as Text
LoanCode as Text
LoanReceivable as Currency
InterestPaid as Currency
I would like to ask on how to use Query to create a temporary table that will display Members that should pay on current date or a specified date base on their Term, Mode of Payment and Loan Type (Regular Loans every 30 days to pay, Special Loans every 45 days to pay) and their remaining balance.
Here's my First Attempted Query: I tried to subtract 30 days from Current Date and it obviously gave me just the transactions last month. I would like it to list all transactions including those for example Member with Regular Loan 12 month term on their 3rd monthly payment, Member with Special Loan that is due today.
I am thinking of creating another table that contains the schedule of payments of every Loan released and then go from there.
Is there another way than this? Like a Query that can be run everyday without the need for a bulky ScheduleOfPayments table?
I'm an office clerk who 'graduated' from Excel and a novice using Access at worst and I'm not afraid of VBA codes if that is necessary.
If you know of a better way of doing this, please do tell me or point me in the right direction. I'm all for learning new things and having read and learned a lot from stackoverflow before, I am sure that with your help, my question is as good as solved.
Thank you guys for reading my inquiry.
You have here two solutions:
You can write a procedure that will, when needed, calculate\generate a matrix containing payment schedule for each loan and compare it to payment done.
You can write a procedure that will, when a loan is created, generate corresponding records in a payment schedule table. further comparison will be done between the ScheduledPayment table and the Payment table.
So basically you have to manage a similar set of data, either as a calculated/on the fly matrix or as a permanent set of data kept in a table.
The second version is by very very far the most effective one. You think of it as bulky but it is exactly the opposite, and indeed what is done every time you get a loan from a bank, where your banker will let you sign the reimbursement schedule.
The table solution will allow you to make use of all querying facilities, while the calculated solution will force you to write specific procedures each time you'll want to do some data mining. Just think about a question like "What are the expected reimbursements for the month of April 2014?". Answering this question with the ScheduledPayment table will be as easy as getting a cafe out of your nespresso machine. The same answer without the ScheduledPayment table will be like having to do the whole coffee production process before getting your cup ready.
Hi everyone I'm working on a school project, and for my project I chose to create an ecommerce system that can process recurring orders. This is for my final project, I'll be graduating in May with an associates in computer science.
Keep in mind this is no where a final solution and it's basically a jumping off point for this database design.
A little background on the business processes.
- Customer will order a product, and will specify during checkout whether it is a one time order or a weekly/monthly order.
- Customer will specify a location in which to pick up their order (this location is specific only to the order)
- If the value of the order > 25.00 then it is accepted otherwise it is rejected.
- This will populate the orders_test and order_products_test tables respectively
Person on the back end will have a report generated for deliveries for the day based on these two tables.
They will be able to print it off and it will generate a list of what items go to what location.
Based on the following criteria.
date_of_next_scheduled_delivery = current date
remaining_deliveries > 0
Once they are satisfied with the delivery list they will press "Process Deliveries" button.
This will adjust the order_products_test table as follows
Subtract 1 from remaining_deliveries
Insert current date into date_of_last_delivery_processed
Based on delivery_frequency (i.e. once, weekly, monthly) it will change the date_of_next_scheduled_delivery
status values in the order_products_test table can either be active, hold, or canceled, expired
I just would like some opinions if I am approaching this correctly or if I should scratch this approach and start over again.
A few thoughts, though not necessarily complete (there's a lot to your question, but hopefully these points help):
I don't think you need to keep track of remaining deliveries. You only have 2 options - a one time order, or a recurring order. In both cases, there's no sense in calculating remaining deliveries. It's never leveraged.
In terms of tracking the next delivery date, you can just keep track of the day of the order. If it's recurring -- monthly or weekly, regardless -- everything is calculable from that first date. Most DB systems (MySQL, SQL Server, Oracle, etc) support more than enough date computation flexibility so that you can calculate this on the fly, as opposed to maintaining such a known schedule.
If the delivery location is only specific to the order, I see no use in creating a separate table for it -- it's functionally dependent on the order, you should keep it in the same table as the order. For most e-commerce systems, this is not the case because they tend to associate a list of delivery locations with accounts, which they prompt you about when you order more than once (e.g., Amazon).
Given the above, I bet you can just get away with 2 of your 4 tables above -- Account and Order. But again, if delivery locations are associated with Accounts, I would indeed break that out. (but your question above doesn't suggest that)
Do not name your tables with a "_test" suffix -- it's confusing.