生成发票

发布于 2024-07-26 02:11:15 字数 314 浏览 6 评论 0原文

我需要大批量生成发票,并将其转换为 EDI 并传输到我们的总部。 有一个订单表,其中包含所有收到的订单。在一天中的某个时刻,我必须拿一套(大约 1k)并生成发票。

  1. 生成发票号码的最佳位置在哪里? 在 SQL Server 后端? 或者将批次抓取到 .NET 应用程序中,然后在那里生成发票号码? 发票号码可以是随机的,但不得重复(3-4 年)。 我最多可以使用 12 位数字,并且可以是字母数字。 在哪里可以找到有关生成发票号码的信息。

注意:在生成发票时,我需要计算订单总额和税费。

我将感谢您的意见。

I need to generate invoices in large batch which will be transformed to EDI and transported to our HQ. There is an order table with all the orders coming in. At some point in the day I have to grab a set (about 1k) and generate the invoices.

  1. Where would be the best place to generate the invoice numbers? On SQL Server backend? Or grab the batch into a .NET application and then generate the invoice numbers there? The invoice numbers can be random but must not repeat (for 3-4 years). I have a max of 12 digits to play with and can be alpha numeric. Where can I find information on generating invoice numbers.

Note: While I am generating the invoices I need to compute the order totals and tax.

I would appreciate your input.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

红墙和绿瓦 2024-08-02 02:11:15

发票号码可能会受到法律要求的限制(在我居住的地方,发票号码需要按顺序排列,而且我认为顺序中可能不会有间隙)。

您经常会看到数字包含一个可以及时确定其范围的元素(例如年份:200903472)。 这样您就可以最大程度地减少两次使用同一号码的风险。

您说您每天大约有 1K 张发票。 这意味着 6 位数的发票号码将满足您的需求。 因此,4 位数年份后跟零填充的 6 位数发票号码可能应该可以帮助您完成操作。

我可能会让数据库生成它们以确保它们是唯一的。

Invoice numbers may be regulated by legal demands (where I live they need to be in sequence, and I don't think that there may be gaps in the sequence).

You often see that the numbers include an element that will scope them in time (such as the year: 200903472). That way you minimize the risk of using the same number twice.

You say you have ~1K invoices a day. That means that 6-figure invoice number will cover your needs. So 4-digit year followed by zero-padded 6-figure invoice number should probably get you going.

I would probably have the database generate them to ensure that they are unique.

清欢 2024-08-02 02:11:15

将一个表添加到数据库中,该表存储最后使用的发票编号的值,并添加一个存储过程来递增该值并将新值返回给您以在创建发票时使用。

当您保存新发票时,请调用 SP 以获取下一个发票编号,这是您所做的最后一件事之一 - 在验证通过之后但在写入磁盘之前 - 为了尽量减少“漏洞”的风险你的编号顺序。

Add a table to your database which stores the value of the last Invoice Number used, and a stored procedure to increment this value and return the new value to you to use in the creation of your Invoice.

When you save your new Invoice, make the call to the SP to get the next Invoice Number one of the last things you do - after validation passed but immdiately before writing to disk - in order to try to minimise the risk of "holes" in your numbering sequence.

橘味果▽酱 2024-08-02 02:11:15

使用顺序 ID 可能是最好的,除非您出于某种原因希望它们是随机的(例如因为客户不应该能够猜测大致同一时间段内另一个订单的订单 ID)。 使用顺序 ID 允许您读取当前的最大值,然后在从批处理进程提交订单之前检查您要写入的范围内是否没有写入任何内容。

如果您不想承担检查数据库的负担,并且可以确保其他进程不会干扰,则可以利用 DateTime.UtcNow 和 Base64 转换。 一个非常笨重的插图可能类似于:

Convert.ToBase64String(new byte[] { (byte)DateTime.UtcNow.Year, 
                                    (byte)DateTime.UtcNow.Month,
                                    (byte)DateTime.UtcNow.Day,
                                    (byte)DateTime.UtcNow.Hour,
                                    (byte)DateTime.UtcNow.Minute,
                                    (byte)DateTime.UtcNow.Second,
                                    (byte)DateTime.UtcNow.Millisecond })

或者

Convert.ToBase64String(new byte[] { (byte)DateTime.UtcNow.Ticks })

您可能对 Base32 更感兴趣转换(它使用字母 AZ 和数字 2-7),尽管没有本机 .Net 转换,因此您必须搜索一个。

Using sequential ids is probably best unless you want them to be random for some reason (like because customers shouldn't be able to guess the order id of another order from roughly the same time period). Using sequential ids allows you to read the current max and then check that none have been written in the range you are going to write just before you commit orders from your batch process.

If you don't want the burden of checking the database and can be sure that other processes aren't going to interfere, you might be able to leverage DateTime.UtcNow and a Base64 conversion. A really clunky illustration might be something like:

Convert.ToBase64String(new byte[] { (byte)DateTime.UtcNow.Year, 
                                    (byte)DateTime.UtcNow.Month,
                                    (byte)DateTime.UtcNow.Day,
                                    (byte)DateTime.UtcNow.Hour,
                                    (byte)DateTime.UtcNow.Minute,
                                    (byte)DateTime.UtcNow.Second,
                                    (byte)DateTime.UtcNow.Millisecond })

Or

Convert.ToBase64String(new byte[] { (byte)DateTime.UtcNow.Ticks })

You'd probably be more interested in a Base32 conversion (it uses letters A-Z and digits 2-7), though there's no native .Net conversion so you'd have to search one out.

深者入戏 2024-08-02 02:11:15

我认为如果没有法律限制生成发票id的规则,它可以是任何你想要的。

现在我有一个很好的例子:

实际上,我正在编写一个发票系统,我已经按顺序生成了我的 ID 代码,但我遇到了一些空白,因为当客户取消与公司的合同时,我之前已经生成过12张发票了。

(因为我们是一家 ISP 公司,合同必须是 6、12 或 24 个月)

我的数据库出现了空白,因为系统用户删除了已取消的发票。 如果我真的需要一个序列号,我就会遇到法律问题。 我这里还有很多其他情况导致我的连续发票号码出现空白。

我真的不知道如何避免这种问题,因为有很多情况会发生这种情况。 任何想法?

I think if there are no laws to restrict the rules about generate the invoice id, it can be whatever you want to be.

Now I have a good example about:

Actually I'm programming a invoice system and I had generate my id code sequentially, and I got some gaps, because when the customer for example cancel the contract with the company, and I had already generate 12 invoices once before.

(because here we are an ISP company and the contract must be 6, 12 or 24 months)

I got the gap in my database, because the users of the system deleted the canceled invoices. If I really needs a sequential number I got a problem with the law. And I have many other situations here that gave me a gap in my sequential invoice number.

I really don't know how to avoid this kind of problem cause there are numerous situation where it happen. Any Idea?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文