Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 02/07/2015 in all areas

  1. Im abit behind on my schedule on my modules due to other paid projects but will see if i push time to clean up my modified GoGetSSL module & include a renew will try to do this week will PM you or post to this thread.
    2 points
  2. NickP

    Module Overhaul [Paid]

    Other requests where maybe a simple "renewal" button that will lead them to the order page for the same product.
    1 point
  3. jwogrady

    Virtual Memory Exceeded

    You make a good point.... It's actually a cloudlinux machine and I think it auto-updated recently. The good news is I figured out it's probably not malicious because the alerts corresponded with the normal cron schedule. I'm using Blesta 3.3 too... probably time to update.
    1 point
  4. Yep it is and I get a few visitors from Google for the articles, I think a Knowledge base is amazing because that's how I got visitors on my old brand
    1 point
  5. @Paul: Simplifying things Pro-forma invoices should always have sequential not reused numbering. Final invoice should always have the date of creation/converted (im not talking paid date), and should always have for tracking/search propose the pro-forma old number and also all client details saved (simple way as an array) to not be changed ever. Resolving this will be all good
    1 point
  6. you could tell to your hosting company or consider changing?
    1 point
  7. fixed now , updated to 2.1.1 2.1.1 + fixed logo design 2.0.1 + added link to return to client view + remove language difinition from invoiceinfo function output .
    1 point
  8. @Paul , can you ate least make the admin template selectable like the client one, and let the rest for us (the developpers) .
    1 point
  9. lol OFF TOPIC, but real facts in this buisness, related with the OP question: vacation???? what is that name? LOL I personaly dont know what is a real vacation in almost 17 years (before I openned my buisness) never rest more than 2 days, and I cant shutdown my smartphone to check emails or check if servers are ok more than 30 minuts LOL its an habit, a really bad habit but i cant stop doing it And now that im a father since 2012, my child complets my rest by playing with im lol
    1 point
  10. The 6 hours lock from Blesta can be found here, Line 1909 in : /app/controllers/cron.php : ----------- if (strtotime($last_run->start_date) < strtotime(date("c") . "-6 hours")) --------- so it's does make sense to lock still runing cron task, but what will be the chance they end if there are not done in a couple of mins, I think, even in case of hundred of thousand of operations that should never be very long ? 6 hours is maybe excessive in my opinions, I will be more confortable with something like very max 1 hours or even 40 mins seem still to me very very fine.
    1 point
  11. Backdating any type of document is indeed fraud. Also keep in mind that in countries that use accrual accounting, VAT becomes due on the invoice date, and has to be paid at the end of the reporting period. So if you do were to write out an invoice backdated to December 2014 today, the VAT on the invoice should have been paid at the end of Q4 2014, and you are late.... Invoice date = date the (real) invoice is created. Which as naja already pointed out, can be later than the date the payment was received by your bank, in case of wire transfers and manual payment processing. Note that -when there is advance payment, which is the case here- you are required to mention the date the payment was received on the invoice as well, but separately, and not as invoice date. Invoices typically only have a due date and additional payment instructions ("if paying by bank transfer, use invoice number 1234 as description") if they have to be paid. If the invoice was paid in advance, it shouldn't have a due date, as nothing is due.
    1 point
  12. I also experienced this reported bug before. All of this is coming because 2 differents documents type (unpaid invoice and paid invoice) are sharing at some point same sequential numbering in a single column "id_value" at Table "invoices" in database. 1/ Proforma (unpaid invoice or quote by the way) Are not really sequential number by now in Blesta because it's re-use old previous number that was existing before (before the switch at payment "date_closed"), so at different time, you can send to different customers , proforma using an old used sequence number "id_value" that was again released. So, it's a traceability & commercial issue. All proforma should be related to an unique content/proposal. 2/Paid invoice should have their very own sequential numbering, created from the payment date (this sequential number column is now missing in Blesta, this new column could be "id_paid") What accountability request in EU (but not only there), is Paid invoice number are sequential and without numbering interruption (missing number between paid invoices), and the more easy is just to base the number sequence on the payment date, and not like now from proforma sequence, because not all proforma will be paid... ----------- Unpaid vs paid are 2 separate "documents" type for the sequencing number UNPAID: sequencing is based on creation of the document itself ("date_billed" in table "invoices"), it's ever "id_value", but it's should be persistent (never be changed when invoice is closed) PAID: sequencing number should be based on payment date more exactly "date_closed" in Table "invoices", so it will be more suitable to have a new column "id_paid" in Table "invoices" In place of: like Blesta is working now by only sharing "id_value" for both type (unpaid & paid). So my proposal to solve the issue, will be easy to implement as it's do not change a lot the way Blesta work and for old data, it's will be easy to create the missing paid invoice sequencial "id_paid" number with an Blesta upgrade & SQL query, as "date_closed" is ever know in the database. I past here bellow more detail I given in this post: http://www.blesta.com/forums/index.php?/topic/3306-pro-forma-invoices-numbering-are-not-sequential/page-3
    1 point
  13. I have looked at this case in profound , because is something trivial and critical and cant be wrong , because it could try trouble with fiscalite . The only good solution that can be good enough for almost all case (maybe theee case i have not rhough in it) is to make the invoice date in date of creation (changing from proforma to invoice) , with that We are sure no invoice with old date . Waiting the other for thier remark . So for me -1 for payment date . +1 for convertion date from proforma to invoice .
    1 point
  14. Domain manager is a top priority along with mass mailer, and affiliate system. It's also the most complex, and is in the process of being spec'd out. I don't have a precise ETA on it yet, but a 3.5 or 3.6 is likely.
    1 point
×
×
  • Create New...