From: Fernando L. <fer...@fa...> - 2012-03-08 18:37:29
|
Ricardo: Posso estar enganado, mas lá no primeiro e-mail que enviei com a sugestão eu coloquei o seguinte: *===================* *Competência* *===================* *Fatura Principal*: DR: Transitória Duplicatas a Receber <- Conta Transitória CR: Receita de Vendas <- Valor total da fatura *Faturas Vinculadas:* CR: Transitoria Duplicatas a Receber <- Conta Transitória DR: Duplicatas a Receber *Alocação*: CR: Duplicatas a Receber DR: Banco Qual a diferença real contábil no final as contas no caso do regime de competência? No meu ponto de vista, trabalhar com a InvoicePaySchedule não é mais uma opção, mas estou aberto para uma explicação de como seria isso.. Lembrando que os objetivos destas modificações são: - Controlar Atraso de Clientes (Permitir entender o atraso médio, juros cobrados, etc.) - Permitir trabalhar com diferentes tipos de sistemas de financiamento - Permitir o pagamento ANTECIPADO das últimas parcelas de um financiamento, de acordo com a regra de mercado. - Permitir o calculo de juros por atraso e a cobrança de forma correta deste juro, contabilizando o valor pago a maior em uma conta contábil correta - Agilidade ao usuário, ou seja, não ter que ficar ativando 30 processos para conseguir calcular os juros por atraso de uma parcela, e sim ter a informação na mão na hora, inclusive o valor atualizado em todas as views de pesquisa. Att, Fernando Lucktemberg Faire Consultoria em Tecnologia & Gestão - Mais soluções para os seus desafios! fer...@fa... +55 66 34972004 2012/3/8 Ricardo Alexsander Santana <ral...@gm...> > Fernando, eu acho que temos que achar uma solução, mas não acho que esta > solução seja genérica para ser usada para todos os cenários. > > Neste caso, eu acho um problema modificarmos a MPeriod para fazer um > by-pass nestes casos, pois isso foge a regra de todas as outras janelas. Eu > acho que podemos chegar numa solução usando a Invoice Pay Schedule, mas se > isso não for possível, este recurso deverá ser opcional, pois fica fora da > "convenção". > > Sobre a contabilidade eu ainda não entendi como vai funcionar, vou > explicar como funciona hoje: > > *===================* > *Competência* > *===================* > *Fatura*: > DR: Duplicatas a Receber > CR: Receita de Vendas <- Valor total da fatura > > *Alocação*: > CR: Duplicatas a Receber > DR: Banco > > *===================* > *Caixa* > *===================* > *Alocação*: > DR: Banco > CR: Receita de Vendas <- Valor do pagamento, podendo ser parcial > > Ou seja você tem os 2 cenários, que já são tratados por padrão no > Adempiere. Se você mudar isso da forma que você falou, você passa a ter não > ter mais o regime de competência, pois as faturas serão lançadas com as > datas futuras. > > Você não acha que poderíamos tentar melhorar a InvoicePaySchedule, fazendo > assim uma função que possa ser usado em todos os cenários? > > Eu acho que isso não interessa ao projeto upstream, porém podemos uma > pequena coisa que talvez interesse a eles, a forma com que as condições de > pagamento são tratadas, eu acho que independente de ser 1 parcela ou N, > tudo deve entrar na InvoicePaySchedule. Se conseguirmos mudar apenas isso > no projeto upstream, eu acho que o restante conseguimos fazer no LBR de > forma não intrusiva. > > Att. > -- > Ricardo Alexsander Santana > ral...@gm... > > > Em 8 de março de 2012 11:53, Fernando Lucktemberg <fer...@fa...>escreveu: > > Claudemir: >> Na minha opnião, modificar o core de invoicing não é uma opção tão boa do >> ponto de vista do projeto oficial.. Mas eu posso estar enganado. As poucas >> vezes que levantei o assunto com os amigos que trabalham mais no projeto >> oficial, eles foram "contra" a idéia de mexer nisso.. Até sugeriram usar >> uma função que está meio implementada no adempiere para fazer isso. Mas >> aqui, pelo menos para meus clientes, não vira. Por isso a idéia deste novo >> desenvolvimento. >> Contabilmente, fica tranquilo, pois como a fatura tem um valor fixo, que >> é somente o valor daquela parcela lançada como uma despesa, o valor pago a >> maior ou a menor é automaticamente contabilizado pelo Adempiere, na hora em >> que o Pagamento é completado. >> >> Pablo: >> Minha idéia é ter uma aba a mais na tela de fatura listando as faturas >> vinculadas. E não mostrar faturas vinculadas na aba principal da janela. >> Quanto a deixar os campos de produto e despesa em branco, somente o de >> produto, pois o de despesa indicará para qual conta contábil deverá ser >> feito o abatimento da transitória. >> Não acho prudente criar uma estrutura nova para essas faturas vinculadas, >> a mudança é muito grande. >> >> Att, >> >> Faire Consultoria em Tecnologia & Gestão - Mais soluções para os seus >> desafios! >> fer...@fa... >> +55 66 34972004 >> >> >> 2012/3/8 Pablo Boff Pigozzo <pab...@gm...> >> >>> Fernando, >>> >>> estou animado com a solução, não será fácil de implementar, mas ficará >>> bacana demais. >>> >>> Quanto a questão da diferenciação das faturas, é prudente separarmos as >>> referenciadas da sua fatura "base", colocar em telas diferentes por >>> exemplo, acho que irá diminuir a complexidade e melhorar a questão de >>> manipulação, chamando essa nova tela de parcelas ou coisa assim, tornando >>> mais amigavel ao usuário. Se formos analisar, precisaremos de 15% dos >>> campos que temos hoje na fatura, para uma fatura referencia, basicamente, >>> será as infos da fatura base, mais PN e valores. >>> >>> Sobre a criação da linha da Fatura Referenciada, podemos deixar o campo >>> Produto e também Despesa em branco, entramos somente com o valor, porém >>> precisa avaliar como ficará a contabilidade disso. >>> >>> Outra solução é separar em outra tabela, pois devido a necessidade de >>> poucos campos poderiamos economizar espaço em banco. Só que neste caso >>> envolme mais customizações, pois precisará tratar o financeiro e o contabil >>> disso tudo novamente, gerando retrabalho em relação a C_Invoice, mas fica a >>> dica. >>> >>> Att. >>> -- >>> Pablo Boff Pigozzo >>> Analista / Programador >>> Tel.: +55 55 8435-0197 >>> E-mail: pab...@gm... >>> >>> On 08/03/2012, at 11:18, Fernando Lucktemberg wrote: >>> >>> Olá Leonardo, bons pontos. Vamos a eles. >>> >>> Não entendo muito desta área mas como ficaria para um cliente que tenha >>>> como negócio o financiamento e todo dia ele gerasse entre 10 e 15 >>>> financiamentos de 10,20,30 anos, não seria muita informação? >>>> Pergunto por questões de pesquisa e relatórios, tenho medo que o >>>> usuário se perca no meio da informação. >>> >>> O Volume de informações vai sim ser grande, mas daí parte a separação >>> destas faturas vinculadas das faturas principais.. Note que o volume >>> "dados" em banco não deve ser um agravante.. >>> >>> Outra coisa, como seria tratado a questão do valor da entrada (acredito >>>> que apenas no caso de um financiamento)? >>> >>> Nós vamos montar um módulo de negociação para resolver isso.. Aonde o >>> pagamento será dividido em 3 partes, entrada, parcelas e intermediárias (ou >>> balões). >>> >>> E tentando explicar a pergunta do Ricardo (se foi isso que entendi), >>>> como ficaria a questão dos períodos para gerar faturas futuras, para não >>>> ter problema de período fechado? >>> >>> Podemos alterar a MPeriod para resolver esse problema. >>> >>> Att, >>> >>> Fernando Lucktemberg >>> Faire Consultoria em Tecnologia & Gestão - Mais soluções para os seus >>> desafios! >>> fer...@fa... >>> +55 66 34972004 >>> >>> >>> 2012/3/8 Leonardo (Vectory) <lv...@ve...> >>> >>>> Olá Fernando, >>>> >>>> Não entendo muito desta área mas como ficaria para um cliente que tenha >>>> como negócio o financiamento e todo dia ele gerasse entre 10 e 15 >>>> financiamentos de 10,20,30 anos, não seria muita informação? >>>> Pergunto por questões de pesquisa e relatórios, tenho medo que o >>>> usuário se perca no meio da informação. >>>> >>>> Outra coisa, como seria tratado a questão do valor da entrada (acredito >>>> que apenas no caso de um financiamento)? >>>> >>>> E tentando explicar a pergunta do Ricardo (se foi isso que entendi), >>>> como ficaria a questão dos períodos para gerar faturas futuras, para não >>>> ter problema de período fechado? >>>> >>>> Abraços, >>>> Leonardo Seiji De Vitro >>>> Vectory Treinamento e Desenvolvimento >>>> 11 7293-9522 >>>> >>>> Em 08-03-2012 09:53, Fernando Lucktemberg escreveu: >>>> >>>> Bom dia meus caros! Continuando.. >>>> >>>> Ricardo: >>>> >>>>> Cada fatura vinculada fica com a data de cada parcela? ex: 21/03 - >>>>> 21/04 - 21/05 - etc? >>>> >>>> Exato, note que a Fatura principal teria o flag de Pago marcado, ou >>>> seja, você não vai "pagar" a fatura principal, vc vai pagar a fatura >>>> vinculada à aquela principal. >>>> >>>> >>>>> Se sim, como você iria tratar isso no regime de competência? como >>>>> ficaria para completar os documentos com datas futuras? >>>> >>>> Acredito que o maior problema seja como tratar isso no regime de caixa, >>>> já que no de regime competência o imposto é recolhido de acordo com o >>>> Faturamento mensal independente do recebimento ou não. Talvez possamos >>>> fazer uma transitória de impostos no caso do regime de caixa, o que acha? >>>> Acredito que seja isso mesmo. Ou não entendi a pergunta? >>>> >>>> Claudemir: >>>> >>>>> A minha ideia era implementar um (ou talvez alguns) campos na tabela >>>>> da programação de pagamentos para indicar que uma parcela foi paga (e possivelmente >>>>> uma referência ao pagamento alocado). Sei que para que funcionassem >>>>> bem os relatórios e as alocações algumas views e processos precisariam >>>>> ser alterados, mas se isso for possível, o impacto no banco é mínimo. >>>> >>>> Claudemir, não querendo te desapontar, mas é a pior opção possível para >>>> tratar nossos problemas. Hoje nós fazemos assim em alguns clientes que >>>> precisam deste cálculo, não funciona direito.. Um agravante ainda em >>>> relação ao que nós não temos hoje, é a parte de pagamento da última parcela >>>> adiantado, por exemplo. Ainda tem a questão das tabelas de juros, que se vc >>>> adianta vai abatendo dos juros cobrados. Ou seja, é complicado. Mas explica >>>> com mais detalhes como vc pensa em fazer, para ver se conseguimos achar um >>>> meio termo. >>>> >>>> Fixando mais uma vez a minha opnião, eu já tive esse problema com >>>> Clientes, já desenvolvemos uma solução que não ficou legal. Até agora, esta >>>> forma que eu citei antes, foi a melhor que conseguimos encontrar. >>>> >>>> Att, >>>> >>>> Fernando Lucktemberg >>>> Faire Consultoria em Tecnologia & Gestão - Mais soluções para os seus >>>> desafios! >>>> fer...@fa... >>>> +55 66 34972004 >>>> >>>> >>>> 2012/3/7 Claudemir Todo Bom <cla...@to...> >>>> >>>>> Boa noite a todos >>>>> >>>>> Da mesma forma como o Ricardo disse, por favor me perdoem se eu falar >>>>> bobeira, apenas quero contribuir para o brainstorm. >>>>> >>>>> A minha ideia era implementar um (ou talvez alguns) campos na tabela da >>>>> programação de pagamentos para indicar que uma parcela foi paga (e >>>>> possivelmente uma referência ao pagamento alocado). Sei que para que >>>>> funcionassem bem os relatórios e as alocações algumas views e processos >>>>> precisariam ser alterados, mas se isso for possível, o impacto no banco >>>>> é mínimo. >>>>> >>>>> Não sei qual é a extensão de uma mudança dessas, esse é o meu ¢1 (o >>>>> outro ainda está faltando), aguardo comentários sobre esta ideia. >>>>> >>>>> Fora isso, a ideia do Fernando me pareceu bem elaborada e imagino que >>>>> ele pesquisou isso bem a fundo, estou acompanhando as respostas às >>>>> questões que já foram levantadas sobre ela. >>>>> >>>>> Abraços, >>>>> Claudemir >>>>> >>>>> Em Ter, 2012-03-06 às 08:26 -0400, Fernando Lucktemberg escreveu: >>>>> > Bom dia a todos! >>>>> > Bem, como já é de conhecimento de todos, hoje temos uma série de >>>>> > dificuldades quando tratamos o famoso "Contas a Receber" dentro do >>>>> > Adempiere. Só para listar alguns: >>>>> > >>>>> > >>>>> > Acompanhamento de parcelas em atraso; >>>>> > Pagamento de parcelas antecipadamente (No caso de financiamentos em >>>>> > médio/longo prazo); >>>>> > Cálculo de juros e multa por atraso de parcelas; >>>>> > Cálculo de índice médio de atraso de parcelas; >>>>> > Renegociação de parcelas em atraso; >>>>> > Controle dos impostos a recolher nos diferentes regimes de apuração >>>>> > (competência / caixa) >>>>> > entre outros... >>>>> > >>>>> > >>>>> > O que nós da Faire estamos pensando em fazer para resolver este >>>>> > problema é efetuar uma modificação no Fluxo contábil das Faturas de >>>>> > Venda. >>>>> > >>>>> > >>>>> > Hoje nós temos o seguinte Fluxo: >>>>> > >>>>> > >>>>> > Fatura Principal >>>>> > Fluxo Padrão: CR: receita de vendas / DB: Duplicatas a Receber >>>>> > >>>>> > >>>>> > No caso do Fluxo normal, esta fatura gerará o número de linhas >>>>> > necessárias na C_InvoicePaySchedule para condizer com o termo de >>>>> > pagamento escolhido na ordem, sendo que a cada alocação, é efetuado >>>>> um >>>>> > Crédito na conta de Duplicatas a Receber, desta forma baixando o >>>>> valor >>>>> > daquela conta. >>>>> > >>>>> > >>>>> > O que vamos fazer é, trabalhar com um Fluxo alternativo que usará >>>>> > faturas vinculadas, e deixar de trabalhar com o fluxo normal. Este >>>>> > fluxo funcionará da seguinte forma: >>>>> > >>>>> > >>>>> > Fatura Principal >>>>> > Novo Fluxo: CR: receita de vendas / DB: Transitoria Duplicatas a >>>>> > Receber >>>>> > Faturas Vinculadas (Vinculadas às faturas principais usando um campo >>>>> > na tabela C_Invoice) >>>>> > Novo Fluxo: CR: Transitoria Duplicatas a Receber / DB: Duplicatas a >>>>> > Receber >>>>> > >>>>> > >>>>> > Neste caso, a fatura principal apenas servirá como referência em >>>>> > relação ao que foi vendido, e para contabilizar a receita de vendas. >>>>> > A(s) fatura(s) vinculada(s) será(ão) então gerada(s), de acordo com o >>>>> > termo de pagamento escolhido na ordem, se tivermos 1 pagamento, >>>>> gerará >>>>> > uma fatura vinculada, se tivermos 360 pagamentos (financiamento de 30 >>>>> > anos), teremos 360 faturas vinculadas. >>>>> > >>>>> > >>>>> > O que acham? Alguém mais precisando resolver este problema? Alguma >>>>> > outra sugestão? Algum problema maior em relação a este >>>>> > desenvolvimento? >>>>> > >>>>> > >>>>> > Att, >>>>> > >>>>> > Fernando Lucktemberg >>>>> > Faire Consultoria em Tecnologia & Gestão - Mais soluções para os seus >>>>> > desafios! >>>>> > fer...@fa... >>>>> > +55 66 34972004 >>>>> > >>>>> ------------------------------------------------------------------------------ >>>>> > Keep Your Developer Skills Current with LearnDevNow! >>>>> > The most comprehensive online learning library for Microsoft >>>>> developers >>>>> > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, >>>>> MVC3, >>>>> > Metro Style Apps, more. Free future releases when you subscribe now! >>>>> > http://p.sf.net/sfu/learndevnow-d2d >>>>> > _______________________________________________ >>>>> Adempiere-lbr-devel mailing list >>>>> Ade...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------------------------------------------------------ >>>>> Virtualization & Cloud Management Using Capacity Planning >>>>> Cloud computing makes use of virtualization - but cloud computing >>>>> also focuses on allowing computing to be delivered as a service. >>>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>>> _______________________________________________ >>>>> Adempiere-lbr-devel mailing list >>>>> Ade...@li... >>>>> https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >>>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service.http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> >>>> >>>> >>>> _______________________________________________ >>>> Adempiere-lbr-devel mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >>>> >>>> >>>> -- >>>> Atenciosamente, >>>> Leonardo Seiji De Vitro >>>> Vectory Treinamento e Desenvolvimento11 7293-9522 >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Virtualization & Cloud Management Using Capacity Planning >>>> Cloud computing makes use of virtualization - but cloud computing >>>> also focuses on allowing computing to be delivered as a service. >>>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>>> _______________________________________________ >>>> Adempiere-lbr-devel mailing list >>>> Ade...@li... >>>> https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >>>> >>>> >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/_______________________________________________ >>> Adempiere-lbr-devel mailing list >>> Ade...@li... >>> https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Virtualization & Cloud Management Using Capacity Planning >>> Cloud computing makes use of virtualization - but cloud computing >>> also focuses on allowing computing to be delivered as a service. >>> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >>> _______________________________________________ >>> Adempiere-lbr-devel mailing list >>> Ade...@li... >>> https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Virtualization & Cloud Management Using Capacity Planning >> Cloud computing makes use of virtualization - but cloud computing >> also focuses on allowing computing to be delivered as a service. >> http://www.accelacomm.com/jaw/sfnl/114/51521223/ >> _______________________________________________ >> Adempiere-lbr-devel mailing list >> Ade...@li... >> https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel >> >> > > > ------------------------------------------------------------------------------ > Virtualization & Cloud Management Using Capacity Planning > Cloud computing makes use of virtualization - but cloud computing > also focuses on allowing computing to be delivered as a service. > http://www.accelacomm.com/jaw/sfnl/114/51521223/ > _______________________________________________ > Adempiere-lbr-devel mailing list > Ade...@li... > https://lists.sourceforge.net/lists/listinfo/adempiere-lbr-devel > > |